From 55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Mon, 9 Dec 2019 15:29:52 +0900 Subject: wiki: Porting wiki: Porting Chat Log Signed-off-by: Kuninori Morimoto --- wiki/Chat_log/20180906-io-chatlog | 145 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 145 insertions(+) create mode 100644 wiki/Chat_log/20180906-io-chatlog (limited to 'wiki/Chat_log/20180906-io-chatlog') 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 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 -- cgit v1.2.3