Merge remote-tracking branch 'gitlab/wiki' into HEAD

1 files changed, 127 insertions, 0 deletions

diff --git a/wiki/Chat_log/20180920-io-chatlog b/wiki/Chat_log/20180920-io-chatlog
new file mode 100644
index 0000000..8451871
--- /dev/null
+++ b/wiki/Chat_log/20180920-io-chatlog
@@ -0,0 +1,127 @@
+09:03 < wsa> Welcome everyone to the IO meeting
+09:03 < wsa> No surprises today, status updates, and topics
+09:03 < wsa> Here are the status updates:
+09:03 < wsa> A - what have I done since last time
+09:03 < wsa> ------------------------------------
+09:03 < wsa> Kaneko-san
+09:03 < wsa> : added MSIOF to D3 PFC
+09:03 < wsa> Marek
+09:03 < wsa> : continued to deeply investigate the PCIE L1 link state handling
+09:03 < wsa> Shimoda-san
+09:03 < wsa> : sent add reset_control and multiple clocks support for USBHS, and made patches
+09:03 < wsa>   for USB2.0 (host and peripheral) support for R-Car E3/D3.
+09:03 < wsa> Simon
+09:03 < wsa> : sent out RAVB patches on not writing reserved bits and removing an alignment
+09:03 < wsa>   restriction for Gen3, and helped tracking down a RAVB PHY link regression
+09:03 < wsa> Ulrich
+09:03 < wsa> : revisited patches about SCIF RPM improvements
+09:03 < wsa> Wolfram
+09:03 < wsa> : sent prototypes to handle dangling pointers in the DMA subsystem, sent
+09:03 < wsa>   patches to set dma_parms for some R-Car DMA controllers, implemented core
+09:03 < wsa>   part of irqless I2C transfer prototype, update new bsp370 ticket file with
+09:03 < wsa>   comments from old ticket file and so far overlooked already upstream commits,
+09:03 < wsa>   and did reviews of SDHI patches
+09:03 < wsa> B - what I want to do until next time
+09:03 < wsa> -------------------------------------
+09:03 < wsa> Kaneko-san
+09:03 < wsa> : wants to enable SYS-DMAC support for E3 MSIOF
+09:03 < wsa> Marek
+09:03 < wsa> : wants to continue to investigate the PCIE L1 link state handling and revisit
+09:03 < wsa>   a new upstream patch series dealing with the 32-bit bus limitation
+09:03 < wsa> Niklas
+09:03 < wsa> : wants to work on the SDHI reset patch series and on the handling of '4TAP
+09:03 < wsa>   only' devices
+09:03 < wsa> Shimoda-san
+09:03 < wsa> : wants to update patches renesas_usbhs and phy-rcar-gen3-usb2 for R-Car E3/D3,
+09:03 < wsa>   continue to investigate the eMMC suspend issue, and continue with KVM on Gen3
+09:03 < wsa>   and document findings on the elinux wiki.
+09:03 < wsa> Simon
+09:03 < wsa> : wants to follow up on the link regression and alignment patches as well as
+09:03 < wsa>   checking the BSP for more RAVB patches
+09:03 < wsa> Ulrich
+09:03 < wsa> : wants to continue with SCIF RPM upporting
+09:03 < wsa> Wolfram
+09:03 < wsa> : wants to find and backport patches to fix suspend with SDHI, work on I2C
+09:03 < wsa>   core PM improvements, and upport I2C/SDHI patches from new BSP release
+09:03 < wsa> C - problems I currently have
+09:03 < wsa> -----------------------------
+09:03 < wsa> Marek
+09:03 < wsa> : with the limitations of the PCIE controller
+09:03 < wsa> Niklas
+09:03 < wsa> : might have less time assigned for SDHI work
+09:04 < wsa> please fire away questions you have
+09:04 < wsa> I have the following ones:
+09:04 -!- morimoto [~user@relprex2.renesas.com] has joined #periperi
+09:05 < wsa> shimoda: I guess the usb-dmac driver could also benefit from the dma_parms update I did for the SYS-DMAC?
+09:05 < wsa> shimoda: do you want to have a look at this or shall I add it for USB-DMAC, too?
+09:05 < wsa> any other DMACs I missed?
+09:07 < wsa> shimoda: should I pause with finding the SDHI commits which make resume on eMMC possible because you and Renesas Vietnam are working on it?
+09:07 < geertu> usb-dmac is a separate driver, audio-dmac is just rcar-dmac
+09:07 < shimoda> wsa: i think so, but I'd like to confirm first the usb-dmac also has the same issue :)
+09:07 < wsa> or does it make sense working on that in parallel?
+09:08 < geertu> We should find that commit by Sep 28, to get the fix in v4.14-ltsi-rc2
+09:09 < wsa> shimoda: ok, sure, then I will wait
+09:09 < shimoda> wsa: about SDHI/eMMC suspend/resume issue, since Renesas vietnam is focusing on LTSI testing, they cannot find the commits until 28th Sep.
+09:09 < wsa> neg: 
+09:10 < wsa> shimoda: understood, I'll give it a priority boost then to make it until sep, 28th
+09:10 < shimoda> wsa: thanks!
+09:11 < neg> wsa: ?
+09:11 < wsa> neg: (sorry, I hit enter to early, real question coming up)
+09:12 < neg> :-)
+09:12 < wsa> neg: I wonder a bit about no A) being NULL for the last two weeks although I thought this was the month with more SDHI time reserved?
+09:13 < horms> On the subject of LTSI-4.14. I have one fix that is more or less ready to post. I'm unsure if its best to do so or wait, say until early next week, to see if any more fixes emerge.
+09:13 < wsa> were there unforseen issues? or do you need assistance?
+09:14 < wsa> or urgent m/m stuff?
+09:15 < wsa> I don't want to blame you, I just wonder if we as groupleaders can do better planning
+09:15 < neg> wsa: no it was mor or less planed as I spent most of the the previous two weeks segment on IO. 5.5 days/month on base is thin to spread around sometime
+09:15 < wsa> I see
+09:15 < wsa> Sorry, I thought you had more time assigned
+09:16 < neg> wsa: I try to focus on one IP at a time to not waste time context switching :-)
+09:16 < wsa> That sounds good
+09:17 < wsa> OK, I learn from this that we (as groupleaders) maybe should talk more about absolute numbers
+09:17 < neg> wsa: I do it's 6.6 not 5.5 days :-P
+09:18 < wsa> can I cheer for you getting more days? :D
+09:18 < wsa> you are probably fine as is this way, I assume
+09:19 < wsa> ok, but with you having less time for SDHI in the future, I need to add another C) item for myself
+09:19 < wsa> C)
+09:20 < wsa> * developer time for SDHI is scarce
+09:21 < wsa> (with developer time being scarce is nothing new :/)
+09:21 < wsa> okay, other questions?
+09:23 < wsa> well, seems core can have an early start today?
+09:23 < wsa> geertu: are you up for it?
+09:24 < Marex> wsa: besides the news that I finally managed to extract all the relevant info out of Lorenzo ...
+09:24 < Marex> wsa: yet still, there's one last bit which he didn't answer fully and I have to read the PCIe spec for that
+09:24 < Marex> wsa: that is, can a register other than PMCSR put a card into D3hot and thus link into L1 ?
+09:24 < geertu> Marex: PCIe is core?
+09:24 < Marex> wsa: and if so, is that PCIe compliant configuration
+09:25 < Marex> geertu: PCIe is a bus :-)
+09:25 < geertu> wsa: I'll wait 5 more minutes?
+09:26 < wsa> Marex: I see. Thanks for keeping at it and diving into it.
+09:26 < wsa> geertu: ok
+09:26 < Marex> thing is, if PMCSR is the only register which can put a card into D3hot state, we can intercept such accesses in the PCIe code
+09:26 < Marex> if not, we're doomed and need the ATF fixup
+09:26 < wsa> understood
+09:26 < Marex> I am afraid it's the later ...
+09:26 < Marex> I mean, I can cook such a setup in an FPGA
+09:27 < Marex> the question really is, does PCIe spec permit this
+09:27 < Marex> and that neither me nor Lorenzo know ... and thus I need to read the spec again
+09:27 < wsa> and what does hardware in reality really do
+09:28 < Marex> wsa: what do you mean ? you can use setpci to write any register you want pretty much :)
+09:28 < Marex> wsa: I don't know if such a card with custom register to enter D3hot exists, but I know it can be created with relative ease ...
+09:28 < wsa> i mean specs are one thing, reality is another
+09:28 < wsa> not more than that...
+09:29 < Marex> wsa: there's too much hardware to know whether PMCSR is the only reg ever used to enter D3hot
+09:30 < Marex> wsa: but if the spec says it is, then the certification checks it and we only support certified PCIe hardware
+09:31 < wsa> we can do that
+09:31 < Marex> wsa: ... and we can ignore hardware which doesn't use PMCSR to enter the D3hot as non-compliant
+09:32 < damm> maybe non-compliant + non-compliant = success?
+09:32 < damm> its like xor
+09:32 < wsa> we only support non-compliant HW :D
+09:32 < damm> =)
+09:32 < geertu> damm: nah, it's like a CMOS gate with a floating input ;-)
+09:33 < Marex> damm: isn't that more multiplicative operation ?
+09:33 < wsa> Well, our HW semms broken, so if this is the best we can do, then OK
+09:34 < wsa> but once we got more information about what to do (ATF or not), we should report again to the HW team
+09:34 < damm> geertu: reminds me of sh7751 PCI power management
+09:34 < damm> Marex: you are right
+09:34 < wsa> ok, so now we are 5 minutes over time again :D