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
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
|
<wsa> welcome everyone, hope you are fine
<wsa> here are the collected status updates
<wsa> Status updates
<wsa> ==============
<wsa> A - what have I done since last time
<wsa> ------------------------------------
<wsa> Geert
<wsa> : did regression tests for SCIF with SH4 based hardware, fixed a few
other issues on the way, tested suspend/resume with PCIe and
investigated the problems, reposted RSPI bit rate improvements, posted
v3 of generic bindings for Ethernet MAC explicit internal delay setting,
implemented by RAVB, posted a revert for linkwatch after some more
investigation
<wsa> Niklas
<wsa> : unsuccessfully tested SDIO WiFi with Koelsch on Gen2. Probably because
of a too long cable. He will try a shorter one.
<wsa> Shimoda-san
<wsa> : sent a patch fixing the suspend handling of the USB serial gadget,
reviewed and tested Wolfram's SDHI patches about the stalled SCC and the
reset refactoring and the card reset after IP reset, also reviewed lots
of bindings for r8a774...- SoCs as well as USB bindings
<wsa> Ulrich
<wsa> : sent "watchdog: da9063: wake up parent ahead of reboot" to enable late
atomic transfers with IIC [16:01]
<wsa> Wolfram
<wsa> : refactored SDHI driver to use 'reset' and 'hw_reset' as intended by
the MMC subsystem, sent out a fix to reset the card after the IP core
was reset (needs follow up), finally was able to reproduce and inject
the stalled SCC case, reworked series 'fix stalled SCC' and 'implement
manual calibration' for SDHI and sent out, tried to add bus recovery to
the IIC module based on
<wsa> generic pinctrl bus recovery, refactored timeout handling in the I2C
driver, both for bus recovery and when resetting the IP core, sent patch
to correctly handle FNA bit of the I2C module, updated i2ctransfer to
support I2C_M_RECV_LEN, sent minor fixes along the way all over the
place
<wsa> B - what I want to do until next time
<wsa> -------------------------------------
<wsa> Shimoda-san
<wsa> : wants to convert rcar-pci dt doc to json-schema, and ping the serial
gadget patch I have submitted
<wsa> Ulrich
<wsa> : wants to address feedback for "watchdog: da9063: wake up parent ahead
of reboot", and implement atomic transfers for i2c-rcar
<wsa> Wolfram
<wsa> : wants to upstream SMBus emulation binding, core HostNotify support,
and R-Car support for HostNotify, upstream I2C slave testunit, guide the
increase of I2C_M_RECV_LEN length to 255 and upstream R-Car support for
it
<wsa> C - problems I currently have
<wsa> -----------------------------
<wsa> Geert
<wsa> : wonders how to avoid PCIe s2ram crash on R-Car Gen2
<wsa> Wolfram
<wsa> : found out that adding bus recovery to IIC not possible at the moment
because we cannot switch to/from GPIO state using
pinctrl_set_state(). Might be a task for the core group because PWM
could use it, too, for zero duty-cycles. However, for IIC it is low
priority because bus recovery is mostly useful on Gen2. Another issue is
that there is no response from Rob about the SMBus emulation binding
<wsa> If you have questions or comments, please fire away
<wsa> I'll start with asking geertu a one-line summary for the PCIe crash? Is
there something in the s2ram which gets lost during suspend? [16:02]
<marex> I was about to ask the same
<geertu> wsa: marex: It's the same issue as on R-Car Gen3.
<geertu> But on arm64, it was fixed in ATF (by marex-san)
<marex> geertu: thats on RZ then ?
<geertu> marex: No, R-Car Gen2 (koelsch). But RZ/G1 should be affected, too.
[16:03]
<marex> ah sigh
<geertu>
https://github.com/ARM-software/arm-trusted-firmware/commit/0969397f295621aa26b3d14b76dd397d22be58bf
[16:04]
<geertu> On arm32, we need to hook up something into the exception handling in
Linux?
<marex> geertu: so is linux able to get the fault and fix it up ?
<geertu> marex: Currently not [16:05]
<marex> geertu: I suspect you might just need to do as iMX6 does
<marex> geertu: that one did generate some faults when PCIe went nuts too
<marex> geertu: and there both U-Boot and Linux hooked the fault handler
<wsa> geertu: what is missing for Linux? [16:06]
<marex> wsa: the same workaround as in TFA apparently
<geertu> marex: Sounds like a good job for the PCI DRIVER FOR RENESAS R-CAR
maintainer? ;-)
<marex> wsa: except implemented via the fault hooks [16:07]
<marex> wsa: that is , IFF , the gen2 generates such a fault instead of
locking up
<marex> needs to be checked
<geertu> marex: It generates such a fault
<wsa> ok, that's sounds doable? I understood Geert's comment that way that
Linux is missing some prerequisite to handle it [16:08]
<marex> wsa: nope
<wsa> So, on Gen3, why did we chose the ATF way instead of pure Linux?
<marex> wsa: the stuff should be all there
<marex> wsa: because on Gen3, you get a fault in EL3 [16:09]
<geertu> Unhandled fault: asynchronous external abort (0x1211) at 0x00000000
<wsa> ok
<geertu> (that line is from M2-W)
<marex> geertu: hold on, I need some coffee first
<wsa> ok, I'll wait for Marex to get some coffee and _then_ ask him if he is
interested in tackling it ;) [16:11]
<wsa> shimoda: thanks for the quick testing of my SDHI patches
<wsa> I really hope we have no more stalled SCC problems anymore
<shimoda> wsa: you're welcome! i'll review manual calib patches later [16:12]
<wsa> Though, the fact that it stalled when switching the divider was
interesting, but as said, I don't fully get it from the documentation I
have
<wsa> shimoda: Awesome, thanks! [16:13]
<marex> geertu: drivers/pci/controller/dwc/pci-imx6.c
<marex> 1300 hook_fault_code(8, imx6q_pcie_abort_handler, SIGBUS, 0,
<marex> 1301 "external abort on non-linefetch");
<marex> look ^
<marex> so we'll need similar "workaround"
<wsa> geertu: the 77961-io todo mentions adding cmt and sh-msiof. Is there a
chance to get this added via remote access? Didn't damm have some SPI
device to connect or am I remembering wrong? [16:15]
<geertu> wsa: No SPI devices, AFAIK
<wsa> uli___: seems that Guenter missed that there is no RPM that late, or?
<wsa> geertu: ah, okay. well, you would have known if there are any ;) [16:16]
<damm> i don't mind hooking up stuff if needed
<geertu> wsa: I think he doesn't know much about RPM in general
<uli___> wsa: just needs a little explaining, I guess [16:17]
<wsa> damm: that's great! next one will be the CAN devices ;)
<geertu> damm: Perhaps just a wire? Then we can do SPI loopback tests
<wsa> damm: so, get your car close to the lab
<damm> great! I need an extension cable to be able to reach all the way to the
car =)
<wsa> :)
<damm> send me an email with details please [16:18]
<damm> if you do it today EU time then I can finish it this week
<damm> otherwise it will have to wait for a couple of weeks
<wsa> magnus is going to okinawa? [16:19]
<damm> just leaving the remote access location for a while [16:20]
<marex> damm: would you still be able to reinstate and/or install ssh keys ?
<damm> yeah that i can do remotely
<geertu> marex: As you're mostly familiar with the PCIe issue, can you please
handle it?
<damm> cables are more difficult =)
<wsa> marex: that would be great, in deed [16:21]
<marex> yeah
<wsa> awesome, thanks! [16:22]
<wsa> this is all from my side, any question left?
<wsa> not the case [16:23]
<wsa> geertu: ready for core?
<geertu> wsa: But but... it's not yet hh:30?
<wsa> IO group is in HS400 mode [16:24]
<geertu> please retune now ;-)
<wsa> uh oh [16:25]
<moriperi> wsa: 1 thing from me
<marex> geertu: downshift to MMC52 is hard, dont torture them
<wsa> geertu triggerd a halted system again, great! ;)
<wsa> moriperi: what is it?
<moriperi> Now BSP team is tring to enable I2C on V3U board, but has timeout
error.
<moriperi> But, it started works if some delay was added, they said. [16:26]
<moriperi> 1 concern is that V3U is *almost* same as previous SoC, but in my
understanding, previous SoC needed some workaround.
<moriperi> If V3U was fixed around I2C, workaround might be not needed
anymore.
<moriperi> Now BSP team is investigating / confirming.
<moriperi> So nothing to do today, but just information for you.
<wsa> OK
<moriperi> We will ask something to you if V3U board was ready
<moriperi> that's all from me, thanks [16:27]
<wsa> I'll just wait
<wsa> I can't recall any workaround or additional delay from the top of my
head, but we will see...
<marex> real shame there's no OSSJ this year, we could've done V3U peripericon
and bring it all up
<geertu> marex: virtual peripericon? [16:28]
<geertu> Time to launch core?
<marex> geertu: someone would have to write a qemulation of v3u
<marex> oh ...
<wsa> can't we go to Japan just for V3U bringup
<wsa> :)
|
