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
|
09:04 < wsa> welcome everyone. I hope you and the ones close to you are all well
09:04 < geertu> wsa: thank you, same to you
09:05 < wsa> yes, luckily, all is fine here
09:05 < wsa> thanks for the status updates which I collected like this:
09:05 < wsa> Status updates
09:05 < wsa> ==============
09:05 < wsa> A - what have I done since last time
09:05 < wsa> ------------------------------------
09:05 < wsa> Geert
09:05 < wsa> : upported HSCIF bugfix from BSP, DT binding fixes including conversions to json-schema for iic-emev2, mmcif, rcar-can, rcar-canfd, rcar-gen3-pcie-phy, rcar-i2c, riic, rmobile-iic, rzn1-spi, tpu
09:05 < wsa> Niklas
09:05 < wsa> : upported BSP patch fixing a locking issue with the timers
09:05 < wsa> Shimoda-san
09:05 < wsa> : fixed and discussed stuck issue when a lot of frames are received with RAVB, reviewed SDHI and SCIF patches, continued to improve R-Car S4 Ethernet driver, got information about R-Car Gen3e, inspecting V4H spec, debugged renesas_usb3 udc driver which sometimes kernel panic happens
09:05 < wsa> Ulrich
09:05 < wsa> : researched and sent a patch for fixing then always-enabled clock on Gen3 SDHI controllers by increasing allowable suspend/resume
09:05 < wsa> Wolfram
09:05 < wsa> : sent next version of the GPIO logic analyzer, sent cleanup series for debugfs, finalized moving BSP commits to seperate tasks for IO, investigated IIC core revisions with Geert to create proper bindings, created and sent eMMC fix for Condor, tested Ulrich's SDHI RPM patch
09:05 < wsa> B - what I want to do until next time
09:05 < wsa> -------------------------------------
09:05 < wsa> Geert
09:05 < wsa> : wants to check IIC automatic transmission with a logic analyzer on Koelsch, conversion to json-schema of non-Renesas DT bindings used on Renesas boards
09:05 < wsa> Niklas
09:05 < wsa> : wants to check and enable Thermal interrupt mode
09:05 < wsa> Shimoda-san
09:05 < wsa> : wants to continue to, investigate SDHI driver's issues, discuss Sergei about ravb NAPI patch, improve R-Car S4 Ethernet driver, inspect V4H spec, debug renesas_usb3 udc driver
09:05 < wsa> Ulrich
09:05 < wsa> : wants to find out if/why the the SDHI suspend/resume patch introduces a regression when removing UHS cards
09:05 < wsa> Wolfram
09:05 < wsa> : wants to refactor SDHn to be a seperate clock, review Geert's json-schema conversions, continue with extended RECV_LEN and its R-Car support for I2C
09:05 < wsa> C - problems I currently have
09:05 < wsa> -----------------------------
09:05 < wsa> Geert
09:05 < wsa> : wonders who will do the remaining Gen2 json-schema conversions for PCI and PHY
09:06 < wsa> uli__: have you tested your patches with UHS cards as well? I don't think it is card dependent but we should clearly rule it out
09:06 < uli__> not yet
09:06 < wsa> my cards were Samsung and SanDisk, more details available on request ;)
09:06 < uli__> i'm going to do that, though
09:07 < wsa> yes, good!
09:07 < wsa> my gut feeling is that when RPM reactivates the clock, the retune is triggered automatically
09:08 < wsa> probably we need a check if a card is present there
09:08 < marex> wsa: you missed my PCIe L1 V6 , which is hopefully the final one
09:08 < wsa> marex: yes, I will add it
09:08 < wsa> it was not in your report, though
09:09 < wsa> thanks for keeping an eye on this issue for so long
09:09 < geertu> wsa: Did you say my report about SDHI breakage on Koelsch due to "mmc: renesas_sdhi: do hard reset if possible"?
09:09 < geertu> s/say/see/
09:10 < geertu> https://lore.kernel.org/r/CAMuHMdU6=rTHjvcgK8GBzd3OL_9YFqV77=KsAEGJvAVapnhsOQ@mail.gmail.com/
09:10 < marex> wsa: oh, dang, I did miss it
09:11 < wsa> geertu: oops, no, that slipped through the cracks, sorry
09:11 < wsa> I hope I can reproduce it with Lager and my SanDisk card
09:12 < geertu> wsa: let's hope so
09:12 < wsa> I will put it on my todo
09:12 < neg> wsa: I have a local Koelsch in case you need it
09:12 < geertu> I don't test SDHI that often, usually only when I have to prepare a file system on (u)SD for a new board
09:12 < wsa> however, your conclusion makes sense, so it may be good enough to work on that
09:13 < wsa> neg: right, you have one. Cool! Another excuse to meet :D
09:14 < wsa> geertu: again, thanks for all the conversions from txt-to-YAML!
09:14 < wsa> that was quite a lot, only Gen2 is left now
09:15 < marex> wsa: since you bring it up, is there finally some tool to "render" the yaml bindings so they are human-readable like the text ones ?
09:15 < geertu> wsa: You're welcome. "make dtbs_check" started to complaining about them.
09:15 < wsa> marex: I'd like that as well, was it discussed somewhere?
09:17 < marex> wsa: not that I know of
09:17 < geertu> patersonc: Anyone in your team interested in converting Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt and Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt to json-schema?
09:17 < wsa> so, as you maybe saw, the next version of my in-kernel sloppy logic analyzer is out
09:18 < geertu> wsa: I'm not aware of that. Should ask Rob?
09:18 < wsa> while it already is quite daring, uli__ was even braver
09:19 < wsa> so, even if the pins are muxed to e.g. I2C0, you can still read the levels in the GPIOin register
09:19 < marex> wsa: that works on one specific hardware though, right ?
09:20 < wsa> he hacked the code to read the register directly and also got the signals scoped
09:20 < wsa> marex: for sure, I'd keep this a local hack
09:20 < wsa> but for us, this could mean we could even test some things without wiring
09:20 < neg> cool :-)
09:20 < marex> since we're apparently in the discussion part, I might as well ask ... did any of you find a suitable oculink test device for the falcon ?
09:21 < marex> shimoday: ^
09:21 < wsa> and it might the most enjoyable part of an upcoming talk :D
09:21 < marex> I've seen OCuLink to NVMe from supermicro, might as well buy one
09:22 < shimoday> marex: about v3u pcie?
09:22 < marex> shimoday: yes
09:22 < marex> shimoday: also, I didn't forget about the reserved memory node, I will reply to you once I debug it
09:23 < wsa> one could even take this further to DMA-read the register to be scoped to achieve much higher speeds :D
09:23 < shimoday> marex: about v3u pcie, this has a critical issue so that BSP team is using 2 falcon board between RC mode and EP mode, IIUC
09:23 < wsa> so much fun
09:23 < wsa> but let's leave this for now
09:24 < shimoday> marex: thank you for your support of U-Boot topics!
09:24 < marex> wsa: that would fail on equal spacing of the sampling, since AXI is packet based and arbitrated
09:25 < marex> shimoday: so the PCIe cannot be currently tested with real hardware after all, no hope there ?
09:25 < marex> shimoday: as for u-boot, of course, sorry for the slower replies
09:26 < shimoday> marex: you're correct about v3u pcie
09:26 < wsa> marex: true, at higher speeds the equal spacing becomes more relevant
09:26 < shimoday> marex: no warries! (about u-boot)
09:27 < wsa> shimoday: will there be V3U ES2.0?
09:27 < wsa> shimoday: or will Gen4 the next SoC with a working PCIe?
09:27 < marex> wsa: please go buy iMX8M Mini hardware, you will see how even memtester can starve LCD controller DMA to the point of unusability :-)
09:27 < marex> wsa: at which point, sadly, the whole DMA approach totally falls apart ... and that is the default configuration of a hardware too
09:28 < wsa> marex: \o/
09:28 < marex> wsa: more like :-(
09:28 < shimoday> wsa: was planed before. but, perhaps renesas doesn't release V3U ES2.0
09:28 < wsa> yeah, the DMA things was not really serious
09:28 < wsa> it mainly reminded me how people reverse-engineered the polynom of the white noise generator in the C64
09:29 < wsa> DMAing 16MB of data into the memory expansion
09:29 < shimoday> wsa: ah, rcar gen4 pcie should works
09:29 -!- damm [~damm@68.183.84.28] has joined #periperi
09:29 < marex> shimoday: nice :)
09:30 < wsa> shimoday: good news :)
09:30 < wsa> this is all from my side. anything else from your side?
09:30 < wsa> JapaPERI is happy?
09:31 < shimoday> wsa: yes :) thank you for your support!
09:32 < wsa> shimoday: you are very welcome!
09:32 < wsa> okay then, if there is nothing left, let's move to the core meeting
09:32 < wsa> geertu: here is the mic!
|
