wiki: Add I/O chatlog for 20210902

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

1 files changed, 149 insertions, 0 deletions

diff --git a/wiki/Chat_log/20210902-io-chatlog b/wiki/Chat_log/20210902-io-chatlog
new file mode 100644
index 0000000..e74d7e9
--- /dev/null
+++ b/wiki/Chat_log/20210902-io-chatlog
@@ -0,0 +1,149 @@
+09:05 < wsa> so, welcome to the IO-meeting
+09:05 -!- moriperi [~user@fs76eeeb6d.tkyc601.ap.nuro.jp] has joined #periperi
+09:05 < wsa> here are the collected status updates:
+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> : reviewed more RZ/G2L patches, worked on fixing Ethernet after kexec/rebind on all boards
+09:05 < wsa> Kieran
+09:05 < wsa> : assisted Wolfram with remote access and wiring for the V3U
+09:05 < wsa> Marek
+09:05 < wsa> : sent next version of Gen2 PCIe L1 mode fix and got it applied now
+09:05 < wsa> Niklas
+09:05 < wsa> : added support for thermal trip points
+09:05 < wsa> Shimoda-san
+09:05 < wsa> : refactored the probe function of the SDHI driver to avoid whitelisting, fixed a USB issue with firmware loading, continued to improve R-Car S4 Ethernet driver, investigated an issue where the sh_eth driver on V3H triggered NETDEV WATCHDOG, discussed how to abort tuning for SD card, investigated a regression when loading the USB audio gadget with v5.14-rc1
+09:05 < wsa> Ulrich
+09:05 < wsa> : sent a patch to fix break and SysRq handling for SCIF
+09:05 < wsa> Wolfram
+09:05 < wsa> : got stale MMC patches discussed or applied, fixed SDHI regression on some Gen2 instances caused by the new hard reset mechanism, started internal and external discussion how to abort tuning for SD card, sketched design of an upstream compatible way to fix the critical RPC-IF bug, sent out new version of the sloppy GPIO logic analyzer, updated my scripts to support differently working
+09:05 < wsa>  remote labs, enabled TPU on M3-W+ and V3U, patch review
+09:05 < wsa> B - what I want to do until next time
+09:05 < wsa> -------------------------------------
+09:05 < wsa> Geert
+09:05 < wsa> : wants to continue fixing Ethernet after kexec/rebind on all boards
+09:05 < wsa> Shimoda-san
+09:05 < wsa> : wants to continue to investigate the issue of sh_eth on V3H, continue to improve R-Car S4 Ethernet driver, continue to make more eLinux articles
+09:05 < wsa> Ulrich
+09:05 < wsa> : wants to upport CAN driver additions and enable it for V3U
+09:05 < wsa> Wolfram
+09:05 < wsa> : wants to test Uli's SCIF patch for SysRq, create a safe test case for the RPC-IF bug, implement and send out the proper bugfix for RPC-IF, handle responses to the GPIO logic analyzer, pick up "seperate SDHn clock" again
+09:05 < wsa> C - problems I currently have
+09:05 < wsa> -----------------------------
+09:05 < wsa> none reported
+09:06 < wsa> please let me know any mistakes or missed items
+09:06 < wsa> geertu: the ethernet fixes are still WIP? I was looking for patches but couldn't find one, or did I just miss them?
+09:08 < wsa> uli_: the break fixes you sent, do they fix it with DMA, or were they needed even for non-DMA transfers?
+09:08 < geertu> wsa: They're still WIP
+09:08 < uli_> it was broken in both cases
+09:09 < geertu> -WTOOMANYBOARDS ;-)
+09:09 < geertu> W.r.t. that, I should be receving schematics for the Beacon boards soon.
+09:09 < wsa> uli_: I assumed so. And are the patches enough to enable SysRq with DMA now, or do we still need to re-enable interrupts with DMA
+09:10 < uli_> error interrupts are not disabled with dma
+09:10 < uli_> don't know where that came from
+09:10 < wsa> geertu: why does it need to be fixed per board?
+09:10 < geertu> wsa: The fix involves adding compatible values to identify all Ethernet PHYs
+09:11 < wsa> geertu: Uh, I see
+09:11 < wsa> uli_: so the task is done now?
+09:11 < uli_> i would say so
+09:12 < geertu> The issue is that if no compatible values are present, the MDIO core reads the PHY ID from the PHY, which fails if reset is still asserted.
+09:12 < wsa> uli_: cool
+09:12 < geertu> You could say that's a bug in the Linux MDIO/PHY code, but the PHY people don't want to fix it, and recommended using compatible values instead.
+09:12 < wsa> geertu: and we can't deassert the reset before reading?
+09:13 < geertu> wsa: in theory we can. People posted patches to do that before, which were rejected.
+09:13 < wsa> moriperi: you just wrote "Add new board for Renesas Remote Access System" Is this a Renesas internal system or also accesible for, let's say, EuroPeri? ;)
+09:13 < wsa> geertu: with a valid reason?
+09:14 < wsa> damm: by any chance, any news about the Condor board which failed last time we wanted to access it?
+09:14 < geertu> wsa: I think it broke something else.
+09:14 < marex> geertu: compatible = "ethernet-phy-id0007.c0f0", "ethernet-phy-ieee802.3-c22"; does not work ?
+09:15 < damm> wsa: sorry i did not proceed looking into that. will do next time i visit the remote access location. you did get eagle going at least right?
+09:15 < geertu> marex: that's exactly what I'm doing ;)
+09:15 < marex> geertu: ok
+09:15 < marex> geertu: yep, that issue is nasty
+09:16 < damm> marex: i guess "c0f0" is the CRC?
+09:16 < marex> nope
+09:16 < marex> lan8710 PHY ID
+09:16 < wsa> damm: yes, eagle worked and this will help enough already. condor might be nice for better testing, but it is not essential
+09:16 < damm> sorry for poor joke. but i'm not sure if that is any better.
+09:16 < geertu> damm: two 16-bits values separated by dot
+09:16 < marex> that's where you fill in the two PHY ID register values of your PHY instead
+09:17 < damm> haha
+09:17 < damm> now the only thing missing is some sort of JIT machine interpreting opcodes
+09:17 < marex> geertu: they could've just used the dot product (heh)
+09:18 < geertu> marex: network people like separates (dots, colons, ...)
+09:18 < geertu> separators
+09:18 < marex> damm: like lua in dt ?
+09:18 < wsa> okay, i have no more questions
+09:18 < wsa> anything from your side?
+09:19 < wsa> but I still want to get out some sparkling wine
+09:19 < damm> which group would OpenOCD be assigned to?
+09:19 < geertu> wsa: and the Renesas Remote Access System?
+09:19 < wsa> for the first useful remote scoping of the GPIO logic analyzer \o/
+09:19 < geertu> damm: core
+09:20 < wsa> geertu: I'm sure moriperi will answer it once he gets back to IRC
+09:20 < wsa> he is probably still busy understanding Renesas problems ;)
+09:21 < geertu> wsa: congrats, and cheers!
+09:22 < damm> wsa: are the latest SDHI fixed included in renesas-drivers?
+09:22 < wsa> uli_: for enabling PWM on V3U, I will probably need to use your "sample-the-GPIO-input-register" approach. Already looking forward to that :D
+09:22 < uli_> always happy to help with a horrible hack :)
+09:23 < damm> wsa: i remember running into some issue and i want to retest on some kernel version but i'm not sure which
+09:23 < wsa> damm: The lastest one not. Usually they come back via linux-next because Ulf applies them kinda fast
+09:23 < wsa> but the latest one is only Gen2, with non SDR104 instances
+09:23 < kbingham> wsa, Are there any pictures of the scope traces?
+09:23 < geertu> damm: and one Ulf has applied them, they'll end uo in next renesas-drivers automagically.
+09:23 < damm> wsa: can you let me know when we have a supposedly fixed kernel that i can test?
+09:23 < geertu> s/one/once/
+09:24 < damm> so i guess next renesas-drivers release then perhaps?
+09:24 < kbingham> Was the data visibly noisy/lossy from tracing on the same CPU? or was the resolution such that it didn't matter?
+09:24 < wsa> kbingham: not from the TPU yesterday, but from I2C which I scoped for testing: https://elinux.org/Kernel_GPIO_Logic_analyzer
+09:25 < wsa> damm: let me check latest renesas-drivers. My gut feeling is that it is good to go on non-Gen2
+09:25 < damm> wsa: no need, i think i saw the issue on Gen2 actually
+09:25 < damm> probably Koelsch
+09:26 < moriperi> was: sorry for my late response. I'm now e-meeting with Renesas too :(
+09:26 < wsa> then it is likely fixed by the patch Ulf still needs to apply
+09:26 < damm> ok cool. thanks.
+09:26 < moriperi> Sorry, Renesas Remote System is only for Renesas member, it needs to access Renesas internal net.
+09:26 < wsa> kbingham: I measured 1 and 2kHz with a sampling speed of 1MHz.
+09:27 < kbingham> wsa, Oh ... plenty of excess there then ;-)
+09:27 < moriperi> s/was/wsa/
+09:27 < wsa> kbingham: the V3U with non-SMP gave me a maximum speed of 1.4MHz. M3-N with an isolated bigCore gave 3.8Mhz.
+09:27 < geertu> wsa: Nyquist and Shannon will be happy to improve on that ;-)
+09:27 < marex> wsa: I hate to be a FS, but ... did you consider wiring the cortexR to the JTAG port of the RCar3 and using BST to precisely sample your pins without any GPIO nonsense involved in it ?
+09:28 < marex> wsa: that works even for debugging DDR2/3 DRAM on certain chips
+09:28 < marex> the CA5x will suffer from horrid jitter between samples
+09:28 < wsa> marex: nope. The aim is here a simple setup
+09:29 < marex> well if it doesn't return reliable results, what's the point
+09:29 < kbingham> marex, It showed that the device was operating....
+09:29 < wsa> I had a 4% error rate. Of course, I can't say if it is my analyzer or the TPU driver using this approach
+09:30 < wsa> But for finding out that the PWM is in the 1kHz or 2kHz range, it is good enough
+09:30 < damm> it is cool that you can hook it up to sigrok. i think the saleae logic devices are supposed to be supported there too, but i have not yet tested.
+09:30 < marex> wsa: yeah, that's why you use FPGA for logic analyzers, with precise sample spacing implemented in hardware
+09:30 < kbingham> wsa, If you need an accurate pulse measurement, I can hook the scope up and get some timings
+09:30 < wsa> damm: yep, they are. They are even recommended by sigrok devs
+09:30 < wsa> kbingham: I don't need accurate
+09:30 < wsa> I could do this locally
+09:31 < wsa> I just wanted to know if enabling TPU on V3U worked
+09:31 < geertu> marex: yep, "does it blink slow or fast?" is sometimes good enough.
+09:31 < wsa> marex: come on, we had this before. I don't need "precise" for this task
+09:31 < marex> geertu: the report here would be "yeah, it kinda blinks every once in a while, the interval is a bit wobbly though"
+09:31 < wsa> marex: I am fully aware of the limitations
+09:32 < wsa> marex: and all for you, I named it "sloppy" everywhere :)
+09:32 < damm> if anyone needs it i can probably hook up a saleae logig 16 or 8 via USBIP for remote access
+09:32 < marex> damm: is that cypress based or fpga based ?
+09:33 < damm> not sure but it works out of the box
+09:33 < marex> I think they did use cypress cortexM in it , with USB and custom firmware
+09:33 < damm> the logic 8 pro is nicer than the 16 that i bought many years ago. it also has support for analogue channels which i don't really neeed.
+09:33 < geertu> wsa: Is PWM clocked by a spread spectrum source?
+09:34 < marex> https://www.asix.net/dbg_sigma.htm works with sigrok just fine, FPGA based
+09:34 < wsa> It is clocked by S1D8
+09:34 < marex> triggers need work
+09:34 < wsa> that is all i know
+09:35 < damm> marex: looks nice, but the peeing contest with respect to sampling rate is won by logic 8 with 500 MS/s
+09:36 < wsa> can we switch to core now?
+09:36 < wsa> geertu: you ready?
+09:37 < geertu> wsa: I am
+09:37 < damm> wsa: any chance the logic analyzer will work with sharing GPIOs with other devices somehow? =)
+09:37 < wsa> damm: that might actually be possible, but probably so hacky that I can't upstream it :D
+09:37 < wsa> geertu: have fun!