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
|
09:03 < wsa> OK, let's get started with the IO meeting
09:03 < wsa> welcome everyone, hope you are fine
09:03 < wsa> here are the collected status updates
09:03 < wsa> Status updates
09:03 < wsa> ==============
09:03 < wsa> A - what have I done since last time
09:03 < wsa> ------------------------------------
09:03 < wsa> Geert
09:03 < 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
09:03 < wsa> Niklas
09:03 < wsa> : unsuccessfully tested SDIO WiFi with Koelsch on Gen2. Probably because of a too long cable. He will try a shorter one.
09:03 < wsa> Shimoda-san
09:03 < 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
09:03 < wsa> Ulrich
09:03 < wsa> : sent "watchdog: da9063: wake up parent ahead of reboot" to enable late atomic transfers with IIC
09:03 < wsa> Wolfram
09:03 < 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
09:03 < 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
09:03 < wsa> B - what I want to do until next time
09:03 < wsa> -------------------------------------
09:03 < wsa> Shimoda-san
09:03 < wsa> : wants to convert rcar-pci dt doc to json-schema, and ping the serial gadget patch I have submitted
09:03 < wsa> Ulrich
09:03 < wsa> : wants to address feedback for "watchdog: da9063: wake up parent ahead of reboot", and implement atomic transfers for i2c-rcar
09:03 < wsa> Wolfram
09:03 < 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
09:03 < wsa> C - problems I currently have
09:03 < wsa> -----------------------------
09:03 < wsa> Geert
09:03 < wsa> : wonders how to avoid PCIe s2ram crash on R-Car Gen2
09:03 < wsa> Wolfram
09:03 < 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
09:04 < wsa> If you have questions or comments, please fire away
09:04 < 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?
09:05 < marex> I was about to ask the same
09:05 < geertu> wsa: marex: It's the same issue as on R-Car Gen3.
09:05 < geertu> But on arm64, it was fixed in ATF (by marex-san)
09:05 < marex> geertu: thats on RZ then ?
09:06 < geertu> marex: No, R-Car Gen2 (koelsch). But RZ/G1 should be affected, too.
09:06 < marex> ah sigh
09:07 < geertu> https://github.com/ARM-software/arm-trusted-firmware/commit/0969397f295621aa26b3d14b76dd397d22be58bf
09:07 < geertu> On arm32, we need to hook up something into the exception handling in Linux?
09:07 < marex> geertu: so is linux able to get the fault and fix it up ?
09:07 < geertu> marex: Currently not
09:08 < marex> geertu: I suspect you might just need to do as iMX6 does
09:08 < marex> geertu: that one did generate some faults when PCIe went nuts too
09:08 < marex> geertu: and there both U-Boot and Linux hooked the fault handler
09:09 < wsa> geertu: what is missing for Linux?
09:09 < marex> wsa: the same workaround as in TFA apparently
09:09 < geertu> marex: Sounds like a good job for the PCI DRIVER FOR RENESAS R-CAR maintainer? ;-)
09:09 < marex> wsa: except implemented via the fault hooks
09:10 < marex> wsa: that is , IFF , the gen2 generates such a fault instead of locking up
09:10 < marex> needs to be checked
09:10 < geertu> marex: It generates such a fault
09:11 < wsa> ok, that's sounds doable? I understood Geert's comment that way that Linux is missing some prerequisite to handle it
09:11 < marex> wsa: nope
09:11 < wsa> So, on Gen3, why did we chose the ATF way instead of pure Linux?
09:11 < marex> wsa: the stuff should be all there
09:11 < marex> wsa: because on Gen3, you get a fault in EL3
09:11 < geertu> Unhandled fault: asynchronous external abort (0x1211) at 0x00000000
09:12 < wsa> ok
09:12 < geertu> (that line is from M2-W)
09:12 < marex> geertu: hold on, I need some coffee first
09:13 < wsa> ok, I'll wait for Marex to get some coffee and _then_ ask him if he is interested in tackling it ;)
09:14 < wsa> shimoda: thanks for the quick testing of my SDHI patches
09:14 < wsa> I really hope we have no more stalled SCC problems anymore
09:15 < shimoda> wsa: you're welcome! i'll review manual calib patches later
09:15 < 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
09:15 < wsa> shimoda: Awesome, thanks!
09:16 < marex> geertu: drivers/pci/controller/dwc/pci-imx6.c
09:16 < marex> 1300 hook_fault_code(8, imx6q_pcie_abort_handler, SIGBUS, 0,
09:16 < marex> 1301 "external abort on non-linefetch");
09:16 < marex> look ^
09:16 < marex> so we'll need similar "workaround"
09:18 < 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?
09:18 < geertu> wsa: No SPI devices, AFAIK
09:18 < wsa> uli___: seems that Guenter missed that there is no RPM that late, or?
09:19 < wsa> geertu: ah, okay. well, you would have known if there are any ;)
09:19 < damm> i don't mind hooking up stuff if needed
09:19 < geertu> wsa: I think he doesn't know much about RPM in general
09:20 < uli___> wsa: just needs a little explaining, I guess
09:20 < wsa> damm: that's great! next one will be the CAN devices ;)
09:20 < geertu> damm: Perhaps just a wire? Then we can do SPI loopback tests
09:20 < wsa> damm: so, get your car close to the lab
09:20 < damm> great! I need an extension cable to be able to reach all the way to the car =)
09:20 < wsa> :)
09:21 < damm> send me an email with details please
09:21 < damm> if you do it today EU time then I can finish it this week
09:21 < damm> otherwise it will have to wait for a couple of weeks
09:22 < wsa> magnus is going to okinawa?
09:22 < damm> just leaving the remote access location for a while
09:23 < marex> damm: would you still be able to reinstate and/or install ssh keys ?
09:23 < damm> yeah that i can do remotely
09:23 < geertu> marex: As you're mostly familiar with the PCIe issue, can you please handle it?
09:23 < damm> cables are more difficult =)
09:24 < wsa> marex: that would be great, in deed
09:24 < marex> yeah
09:24 < wsa> awesome, thanks!
09:25 < wsa> this is all from my side, any question left?
09:26 < wsa> not the case
09:26 < wsa> geertu: ready for core?
09:26 < geertu> wsa: But but... it's not yet hh:30?
09:27 < wsa> IO group is in HS400 mode
09:27 < geertu> please retune now ;-)
09:27 < wsa> uh oh
09:28 < moriperi> wsa: 1 thing from me
09:28 < marex> geertu: downshift to MMC52 is hard, dont torture them
09:28 < wsa> geertu triggerd a halted system again, great! ;)
09:28 < wsa> moriperi: what is it?
09:28 < moriperi> Now BSP team is tring to enable I2C on V3U board, but has timeout error.
09:28 < moriperi> But, it started works if some delay was added, they said.
09:28 < moriperi> 1 concern is that V3U is *almost* same as previous SoC, but in my understanding, previous SoC needed some workaround.
09:29 < moriperi> If V3U was fixed around I2C, workaround might be not needed anymore.
09:29 < moriperi> Now BSP team is investigating / confirming.
09:29 < moriperi> So nothing to do today, but just information for you.
09:29 < wsa> OK
09:29 < moriperi> We will ask something to you if V3U board was ready
09:30 < moriperi> that's all from me, thanks
09:30 < wsa> I'll just wait
09:30 < wsa> I can't recall any workaround or additional delay from the top of my head, but we will see...
09:30 < marex> real shame there's no OSSJ this year, we could've done V3U peripericon and bring it all up
09:30 < geertu> marex: virtual peripericon?
09:30 < geertu> Time to launch core?
|
