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