diff options
| -rw-r--r-- | wiki/Chat_log/20210520-io-chatlog | 111 |
1 files changed, 111 insertions, 0 deletions
diff --git a/wiki/Chat_log/20210520-io-chatlog b/wiki/Chat_log/20210520-io-chatlog new file mode 100644 index 0000000..336dedd --- /dev/null +++ b/wiki/Chat_log/20210520-io-chatlog @@ -0,0 +1,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! |