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
|
09:04 < wsa> welcome back, morimoto-san!
09:04 < wsa> so, here are the status updates
09:04 < wsa> Status updates
09:04 < wsa> ==============
09:04 < wsa> A - what have I done since last time
09:04 < wsa> ------------------------------------
09:04 < wsa> Geert
09:04 < wsa> : did DT binding doc conversion to json-schema for CMT, OSTM, TMU, WDT, and fixed the DMA boundary mask for SATA
09:04 < wsa> Marek
09:04 < wsa> : fixed bugs in R-Car PCIe suspend/resume path
09:04 < wsa> Niklas
09:04 < wsa> : did DT binding doc conversion to json-schema for Thermal, also a cleanup for the thermal driver
09:04 < wsa> Shimoda-san
09:04 < wsa> : submitted patches to enable PWM and PCIE on R8A77961, reviewed PCIe endpoint support
09:04 < wsa> Ulrich
09:04 < wsa> : sent a new version of the never-disable-WDT-clock series, and worked on atomic_xfer support for i2c-sh_mobile
09:04 < wsa> Wolfram
09:04 < wsa> : upported SDHI patch to avoid bad TAPs with HS400, debugged an SDHI clock imbalance regression found by Geert and sent a fix and another clock related improvement, pushed the final changes of I2C API conversion, guided a bit of discussions about blocked I2C devices and refactored the documentation for generic I2C bindings as a preparation, minor changes to SDHI, CSI2, DRM, I2C,
09:04 < wsa> reviewed upstream changes to the i2c-slave interface
09:04 < wsa> B - what I want to do until next time
09:04 < wsa> -------------------------------------
09:04 < wsa> Geert
09:04 < wsa> : wants to do more DT binding doc conversions to json-schema, and check for RSPI improvements
09:04 < wsa> Shimoda-san
09:04 < wsa> : wants to check a BSP team's report about dma map/unmap unbalance in the error path of the SDHI driver, continue to collect information about "R-Car Gen4" hardware IPs, continue to make a plan how to implement the Gen4 Ethernet HW IP driver, and update renesas_sdhi_sys_dmac patches if possible
09:04 < wsa> Ulrich
09:04 < wsa> : wants to finish i2c-sh_mobile and implement i2c-rcar atomic_xfer support
09:04 < wsa> Wolfram
09:04 < wsa> : wants to debug OOPSes when NON_REMOVABLE workaround for SDHI is removed, get the series about blocked I2C devices in DT applied, review Ulrich's new WDT clock patches
09:04 < morimoto> geertu: thanks. Yes, Now I'm OK
09:05 < wsa> C - problems I currently have
09:05 < wsa> -----------------------------
09:05 < wsa> everyone
09:05 < wsa> : covid19 restrictions everywhere
09:05 < wsa> questions I have
09:06 < wsa> uli__: was it possible to kind of reuse the non-atomic xfer function for the atomic one? Or does it need a seperate function?
09:06 < uli__> for sh_mobile, it's possible to reuse what is there
09:06 < uli__> rcar is a bit more convoluted, i still have to look into that
09:06 < wsa> shimoda: I forgot, "update renesas_sdhi_sys_dmac patches if possible", what kind of issue is fixed by these patches?
09:07 < wsa> uli__: well, still, a good start for sh_mobile then. Good news!
09:08 < wsa> shimoda: also looking forward to the new DMA imbalance thing for SDHI ;)
09:08 < shimoda> wsa: this is related to performance problem. but, today, i don't have any compline from a reporter. so, we can postpone I think :)
09:09 < wsa> shimoda: okay
09:09 < shimoda> wsa: yes, i got this imbalance report on 12th May, but this report is in Japanese. I cannot forward it to EuroPeri now...
09:10 < wsa> After the clk and RPM updates to the SDHI driver (posted yesterday), I know get interesting OOPSes when I try to revert the NON_REMOVABLE workaround we still have in the driver
09:10 < wsa> s/know/now/
09:10 < wsa> which is nice because I always suspected them to be RPM related
09:11 < geertu> wsa: you mean they might be DMA related?
09:11 < wsa> geertu: DMA?
09:12 < geertu> wsa: ^ DMA imbalance
09:12 < shimoda> imbalance issue seems to be possible to happen. but, there is difficult to reproduce, i guess.
09:12 < wsa> nope, the DMA imbalance seems to be in the error path of probe
09:12 < geertu> wsa: I agree it's good to have a reliable reproducer
09:13 < wsa> yeah, I will have a close look the next days
09:14 < wsa> i think this is it from my side...
09:14 < wsa> anything to discuss on your side?
09:14 < wsa> like people volunteering to do more DT binding conversions? ;)
09:15 < neg> :-)
09:15 < geertu> wsa: I'll give your SDHI patches a try on the other platforms
09:15 < wsa> geertu: much appreciated, thanks!
09:15 < geertu> The _noidle one looks like a nice catch
09:16 < geertu> wsa: Just wondering, why do you still need renesas_sdhi_clk_{en,di}sable()?
09:16 < wsa> yes, well hidden within all these RPM calls
09:16 < wsa> the TMIO core calls it
09:17 < shimoda> ah, btw, do you know whether ethernet driver causes tx watchdog timeout?
09:17 < shimoda> s/whether/how to cause/
09:17 < geertu> wsa: Let me rephrase: why didn't you make renesas_sdhi_clk_{en,di}sable() empty?
09:18 < shimoda> https://marc.info/?l=linux-renesas-soc&m=158641874314353&w=2
09:18 < geertu> shimoda: Doesn't that mean the packet couldn't be sent, e.g. due to bad cable, or corrupted TX ring buffer?
09:19 < wsa> geertu: I don't get what you mean. It is needed when the TMIO core calls suspend/resume
09:20 < wsa> geertu: both runtime and system
09:20 < geertu> wsa: Shouldn't RPM take care of the actual clocks?
09:20 < geertu> shimoda: That email doesn't mention tx watchdog timeout, is it related?
09:21 < wsa> shimoda: maybe we can ask him how he got this panic?
09:23 < wsa> geertu: the RPM stuff for TMIO is from 2011. So, I don't know if all drivers using the TMIO core have their clocks managed via RPM
09:23 < shimoda> geertu: ravb e6800000.ethernet ethernet: transmit timed out, status 00000000, resetting... is related to tx watchdog timeout
09:25 < geertu> shimoda: thx, missed that. I believe last time I wrote an Ethernet driver, it still included "watchdog" in the error message ;-)
09:25 < shimoda> wsa: you're right. but, renesas internal support team also got this report internaly. But, they doesn't have such information..
09:25 < geertu> wsa: But renesas_sdhi_clk_{en,di}sable() is not core mmio, so we can do whatever we want in that function
09:26 < geertu> incl. not touching clocks directly
09:26 < wsa> I can check
09:26 < shimoda> anyway, ask how to reproduce is better.
09:26 < shimoda> thanks!
09:27 < wsa> shimoda: let's hope he can provide an answer then
09:27 < wsa> okay, I guess this was it for today?
09:27 < wsa> last call
09:28 < wsa> so, thank you for the meeting today!
09:28 < wsa> and have a nice continued day
|
