1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
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
|
