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

1 files changed, 145 insertions, 0 deletions

diff --git a/wiki/Chat_log/20180906-io-chatlog b/wiki/Chat_log/20180906-io-chatlog
new file mode 100644
index 0000000..5c0263c
--- /dev/null
+++ b/wiki/Chat_log/20180906-io-chatlog
@@ -0,0 +1,145 @@
+09:06 < wsa_> ok, let's start the IO meeting
+09:06 < Marex> morimoto: I hope even the quake tonight was OK for you all ?
+09:06 < shimoda> wsa_: Near tokyo area is OK. But, today I'm supprized Hokkaido had a big earthquake
+09:06 < ldts> hi horms morimoto , nice to meet you too
+09:06 < Marex> shimoda: 6 upper :(
+09:06 < morimoto> Marex: thanks. Yeah, arround
+09:07 < morimoto> arround tokyo is OK
+09:07 < wsa_> oh, wow. 6 upper is a lot!
+09:07 < shimoda> Marex: Yes :( my mother and my brother's family live in there, but all they are OK now
+09:07 < horms> I'm glad to hear that
+09:07 < Marex> shimoda: whew, glad to hear that
+09:07 < wsa_> really glad to hear that!
+09:08 < shimoda> horms: Marex: wsa_: Thanks!
+09:08 < morimoto> Thank you guys !
+09:08 < wsa_> sure thing
+09:09 < wsa_> with the good news in place, let's get back to our duty here
+09:09 < wsa_> status updates:
+09:09 < wsa_> A - what have I done since last time
+09:09 < wsa_> ------------------------------------
+09:09 < wsa_> Geert
+09:09 < wsa_> : fixed earlycon with SCIF, enabled MSIOF on R-Car E3/Ebisu, upported MSIOF
+09:09 < wsa_>   suspend/resume and reserved register bit patches, and fixed QSPI interruption
+09:09 < wsa_>   and suspend/resume bugs.
+09:09 < wsa_> Kaneko-san
+09:09 < wsa_> : did D3 and E3 MSIOF upporting
+09:09 < wsa_> Marek
+09:09 < wsa_> : retrieved more information about the PCIe L0/L1 transition handling
+09:09 < wsa_> Niklas
+09:09 < wsa_> : got SDHI SCC error patches merged, sent patches for DMA max_segment size,
+09:09 < wsa_>   worked on HS400 clocks differences on various H3 ES, tested SDIO on Koelsch.
+09:09 < wsa_> Shimoda-san
+09:09 < wsa_> : sent out reset_control and multiple clock to USBHS, designed USB2.0 (host and
+09:09 < wsa_>   peripheral) support for R-Car E3/D3, and investigated the eMMC suspend issue
+09:09 < wsa_> Simon
+09:09 < wsa_> : reviewed BSP RAVB patches
+09:09 < wsa_> Ulrich
+09:09 < wsa_> : resent "spi: sh-msiof: Document R-Car D3 support"
+09:09 < wsa_> Wolfram
+09:09 < wsa_> : worked on proper watchdog handling when removing the driver, implemented a
+09:09 < wsa_>   better I2C safe DMA buffer API, reviewed various versions of SDHI patches by
+09:09 < wsa_>   Niklas and Yamada-san, tried to reproduce SDHI suspend problems with mounted
+09:09 < wsa_>   filesystems on eMMC, discussed and sent RFC for I2C core regarding irqless
+09:09 < wsa_>   transfers at shutdown timeand did some SPDX updates
+09:09 < wsa_> B - what I want to do until next time
+09:09 < wsa_> -------------------------------------
+09:09 < wsa_> Kaneko-san
+09:09 < wsa_> : wants to address review comments of previous patches
+09:09 < wsa_> Marek
+09:09 < wsa_> : wants to check if changing the ATF can support Linux to handle the PCIe L0/L1
+09:09 < wsa_>   transition
+09:09 < wsa_> Niklas
+09:09 < wsa_> : wants to work on a solution to 4-tap clock issue.
+09:09 < wsa_> Shimoda-san
+09:09 < wsa_> : wants to continue with the USBHS patches, the E3/D3 USB integration, the eMMC
+09:09 < wsa_>   susped issue investigation, enable KVM on arm64 and update the elinux wiki about
+09:09 < wsa_>   QEMU + USB
+09:09 < wsa_> Simon
+09:09 < wsa_> : wants to revisit RAVB patch to avoid writing to reserved bits
+09:09 < wsa_> Ulrich
+09:09 < wsa_> : wants to send next version of "I2C0/3/5 pin control for H3 and M3-W"
+09:09 < wsa_> Wolfram
+09:09 < wsa_> : wants to reproduce SDHI eMMC suspend problems, implement generic helpers for DMA
+09:09 < wsa_>   properties, keep the 'I2C irqless transfers' development going, work on I2C core
+09:09 < wsa_>   PM improvements
+09:09 < wsa_> C - problems I currently have
+09:09 < wsa_> -----------------------------
+09:09 < wsa_> Wolfram
+09:09 < wsa_> : couldn't reproduce the eMMC suspend issue yet
+09:10 < wsa_> so, we have this interesting update to the eMMC problem that it might be fixed upstream already
+09:10 -!- damm [~damm@l193216.ppp.asahi-net.or.jp] has joined #periperi
+09:10 < wsa_> and we need to identify the good commit(s)
+09:11 < wsa_> Marex: thanks for your work in tackling the PCIE L0/L1 issue
+09:11 < wsa_> Marex: if you want something easy for a change, there is a super-simple E3 enablement patch in the BSP still to upport ;)
+09:12 < Marex> wsa_: oh ?
+09:12 < Marex> wsa_: let me guess, 32bit PCI limitation ?
+09:12 < wsa_> d38d4fc29e8cd71b2173443df9c057bea37624b6
+09:12 < Marex> wsa_: I spent quite a bit pestering lorenzo and catalin about this L0/L1 stuff, ultimatelly, we think there might juuust be a way to work around it in ATF
+09:13 < Marex> wsa_: but that's a thing to research in the upcoming week-ish
+09:13 < wsa_> As I understand it, the HW is not doing it right, or? Might be worth some feedback to the HW team?
+09:13 < Marex> wsa_: since it's a transient fault, it might just make sense to trap the SError in ATF and restart the instruction
+09:14 < geertu> Marex: So the issue happens when the arm64 core accesses the PCIe bus while a device sent a link status change?
+09:14 < Marex> wsa_: what happens is that <someone> may start transitioning the PCIe device to lower power state (think D3hot for simplicity) ... at one point, the device sends PM_Enter_L1 DLLP to the controller
+09:15 < geertu> And that's where "restart the instruction" comes into the picture?
+09:15 < Marex> that one triggers automatic PLL shutdown in the PCIe controller, but does not completely transition the link to L1 state from the PCIe controller side
+09:15 < Marex> at that point, you cannot trigger config accesses to the card anymore, it will trigger those SErrors
+09:15 < Marex> the software must at that point poke the controller PMCTRL register bit to finish the transition to L1 state
+09:16 < Marex> once that happens, everything is great again and you can do config accesses ; the config access will recover the link to L0 state etc etc
+09:17 < Marex> the problem is, IFF ie. a user decides to send config access with ie. setpci just at the right (or wrong?) time between the controller receiving PM_Enter_L1 DLLP from the card and the PMCTRL poke, the system crashes with unhandled SError
+09:17 < Marex> and I think it might just be possible to trap that SError in ATF and restart the instruction which caused it (it's a single register write, so that should be fine)
+09:17 < geertu> Thanks for explaining. I was always wondering where the instruction restart fit in the picture.
+09:18 < geertu> As long as it's not an imprecise external abort, you're fine ;-)
+09:18 < Marex> now there's another funky thing, but that's probably kinda ... hypothetical
+09:18 < Marex> IFF someone does config access from an interrupt handler , the CPU gets async SError and that's sort of the end
+09:19 < wsa_> horms: when could you start working on the 4byte RAVB alignment patch? I think ASAP would be cool, before LTSI becomes super big again? Does that make sense?
+09:19 < Marex> geertu: the async serror is a problem too ^
+09:19 < Marex> geertu: I still need to verify if this cannot happen outside of interrupt context somehow too
+09:19 < horms> wsa_: ASAP is fine :)
+09:19 < wsa_> horms: great!
+09:20 < wsa_> Marex: do the HW guys know the controller should do the L1 link properly on PLL shutdown?
+09:20 < wsa_> is it a known errata?
+09:20 < geertu> wsa_: Doesn't commit d38d4fc29e8cd71b ("PCI: rcar: Add compatible string for r8a77990") need actual testing? E.g. Magnus inserts PCIe card in Ebisu, and Marex dooms it?
+09:21 < Marex> wsa_: it should do it automatically, I don't know why they decided to require this register poke
+09:21 < shimoda> Marex: I'm not sure but, can we avoid to send PM_Enter_L1 DLLP from the card somehow?
+09:21 < wsa_> Marex: that's what we need to discuss IMHO
+09:21 < Marex> shimoda: I was thinking about the same, but the user can just use setpci to bypass it
+09:22 < Marex> shimoda: user can use setpci to set PM_CAP+4 register on the card or maybe some other funny register which is implementation defined by the card and that'd be it
+09:23 < Marex> wsa_: that's what needs to be fixed in the next generation of hardware I think
+09:23 < wsa_> Marex: I agree. That's why I want to make sure HW people are aware there is a problem
+09:23 < Marex> geertu: my question would rather be, why do we need another compatible which is not in the compat table of the controller driver ? Is the PCIe different on ebisu somehow ? maybe like the i2c ?
+09:24 < wsa_> it is just for DTS verification
+09:24 < Marex> wsa_: it's probably better to explicitly state it one more time then
+09:24 < geertu> Marex: We don't know. We may find out only later, so that's why we need the SoC-specific compaible values.
+09:25 < Marex> wsa_: but then. aren't we missing also 77980 and 77970 entries ?
+09:25 < wsa_> we want specific compatibles before the generic fallbacks just in case
+09:25 < wsa_> Marex: you can add them if you want
+09:25 < Marex> jupp, fine
+09:25 < wsa_> but usually, those SoCs are upstreamed by Cogent
+09:26 < Marex> shimoda: so do you think the HW team would be willing to fix this L1 transition issue in next HW cycle ?
+09:27 < Marex> shimoda: or could they maybe add a bit which says "do L1 transition automatically and if someone does config access during transition, stall the bus until transition completes" ?
+09:27 < wsa_> geertu: shall I update the MSIOF entries in periupport, or can you do it when you update core items?
+09:28 < Marex> wsa_: OK, the patch ^ is picked
+09:28 < geertu> wsa_: I will update them with the proper commit ID (broonie is fast)
+09:28 < shimoda> Marex: I don't know. But, I should ask them for next hw.
+09:29 < wsa_> geertu: thanks!
+09:29 < wsa_> are there any questions from your side?
+09:29 < wsa_> I'd guess neg's question about SDHI clocks could also be discussed in the core meeting?
+09:30 < geertu> yes
+09:31 < horms> I'd like to ask about coordinating / requests for upporting tasks for Kaneko-san.
+09:32 < horms> But perhaps that is best done in Core or elsewhere
+09:32 < wsa_> uli___: any news on the SCIF suspend/resume patches?
+09:32 < geertu> horms: Sorry for stepping on Kaneko-san's toes.
+09:32 < Marex> shimoda: yes please ! :)
+09:32 < geertu> But MSIOF is something you need to test with HW access.
+09:33 < horms> It happens, don't worry about it
+09:33 < uli___> wsa_: no, not yet
+09:34 < wsa_> uli___: any specific problems with it? or just too many tasks?
+09:34 < geertu> horms: Does Kaneko-san has access to periupport?
+09:34 < Marex> shimoda: I still have to wonder why they decided to insert this bit into PMCTRL and effectivelly stall the L1 enter state machine, all the controllers I know just do the transition fully automatically
+09:34 < uli___> wsa_: stuff unrelated to work lowered my productivity severely...
+09:34 < geertu> horms: "arm64: dts: r8a77995-draak: Add MSIOF ch2 pins support" is marked "Proposing 'N': MSIOF2 is unused on the Draak board"?
+09:35 < wsa_> uli___: oh, didn't know that. Hope things go well for you soon again!
+09:36 < horms> geertu: thanks, somehow I missed that
+09:37 < wsa_> ok, seems we can transition to core group now...
+09:37 < wsa_> geertu: here is the mic
+09:37 < wsa_> thank you everyone for this meeting