wiki: Add I/O chatlog for 20211202

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

1 files changed, 108 insertions, 0 deletions

diff --git a/wiki/Chat_log/20211202-io-chatlog b/wiki/Chat_log/20211202-io-chatlog
new file mode 100644
index 0000000..39d0396
--- /dev/null
+++ b/wiki/Chat_log/20211202-io-chatlog
@@ -0,0 +1,108 @@
+09:02 < wsa> welcome to the IO meeting, everyone
+09:02 < wsa> here are the status updates
+09:02 < wsa> Status updates
+09:02 < wsa> ==============
+09:02 < wsa> A - what have I done since last time
+09:02 < wsa> ------------------------------------
+09:02 < wsa> Geert
+09:02 < wsa> : assisted Wolfram with the SDnH DT binding addition, tried enabling Ethernet-AVB1-5 on Falcon, investigated PCIe lock-ups during resume with E1000E
+09:02 < wsa> Marek
+09:02 < wsa> : submitted two more versions of the PCIe L1 clock fix
+09:02 < wsa> Niklas
+09:02 < wsa> : fixed definition of cooling-maps contribution property for thermal
+09:02 < wsa> Shimoda-san
+09:02 < wsa> : handled requests between the BSP team and the upstream team
+09:02 < wsa> Ulrich
+09:02 < wsa> : wrote CAN test script and regression-tested V3U-enabled CANFD driver on D3
+09:02 < wsa> Wolfram
+09:02 < wsa> : sent next revision of SDnH separation patches, sent next revision of GPIO sloppy logic analyzer, sent fix for usage of undocumented bits in RPC-IF driver, started efforts to handle bus-recovery consistently in the I2C subsystem, sent fix for an upstream bug report for the SDHI driver, updated bsp41x list and started working on bsp51x list for periject, wanted to upstream BSP patches which turned
+09:02 < wsa>  out to be upstream already, minor cleanups for the RPC and SDHI driver
+09:02 < wsa> B - what I want to do until next time
+09:02 < wsa> -------------------------------------
+09:02 < wsa> Geert
+09:02 < wsa> : wants to fix double key events with interrupt-driven gpio-keys
+09:02 < wsa> Marek
+09:02 < wsa> : wants to revisit PCIe emails from Geert
+09:02 < wsa> Shimoda-san
+09:02 < wsa> : wants to continue R-Car S4 support if the initial patches are reviewed (Ethernet switch, PCIe)
+09:02 < wsa> Ulrich
+09:02 < wsa> : wants to post tested v2 of CANFD for V3U
+09:02 < wsa> Wolfram
+09:02 < wsa> : wants to send out yet another version of the GPIO sloppy logic analyzer, continue consolidation of bus recovery in I2C subsystem, find out the proper solution for faulty SanDisk cards with SDHI, upport SDHI and/or TPU patches
+09:02 < wsa> C - problems I currently have
+09:02 < wsa> -----------------------------
+09:02 < wsa> Wolfram
+09:02 < wsa> : is unsure if he can scope the I2C bus for investigating suspend/resume on Ebisu
+09:04 < wsa> so, about V3U CAN testing
+09:04 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has joined #periperi
+09:04 < wsa> Kieran has the script and is expected to check all(?) channels once he got the kernel to boot?
+09:04 < uli> imo two channels are enough
+09:04 < wsa> once this works, uli will send the updated patches?
+09:04 < uli> that's my plan
+09:05 < geertu> wsa: I/O expander in TSSOP-16 package with 0.65 mm pitch is too hard to probe?
+09:06 < wsa> uli: will it take long to check all channels? To prevent typos in the reg properties in DT etc...
+09:06 < marex> I heart https://www.sunhayato.co.jp/material2/jtp01/item_936
+09:06 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has quit Remote host closed the connection
+09:06 < uli> you'd have to rewire the loopback every time, but other than that, no
+09:07 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has joined #periperi
+09:07 < wsa> the loopback is a RS232 style cable, no?
+09:07 < marex> https://sg.rs-online.com/web/p/ic-test-clips/6328893/ and these
+09:07 < uli> iirc kbingham used jumper wires
+09:07 < geertu> Or https://www.elektor.com/sensepeek-pcbite-kit-incl-4x-sp10-probe-and-test-wires
+09:08 < marex> geertu: I was looking at those, but for TSOP16 it is overkill and way too expensive
+09:09 < geertu> marex: The two other links you posted are more expensive ;-)
+09:10 < marex> geertu: the FP ones are indeed effing expensive and they tend to wear after a while , but damn you can attach to TQFP144 with those
+09:10 < marex> the HP ones are real nice for bigger components, and they just hold in place even if you pull at them
+09:11 < wsa> I think my current clips are not for .65mm
+09:11 < wsa> kbingham: you there?
+09:11 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has quit Ping timeout: 256 seconds
+09:12 < wsa> okay, let's wait for Kieran...
+09:13 < wsa> well, we postpone this question until Kieran is awake, I mean :)
+09:13 < marex> geertu: or buy SOIC pomona clip, obv
+09:13 < marex> https://www.tme.eu/cz/details/pom-5253/merici-svorky/pomona/5253/?brutto=1&currency=CZK&gclid=EAIaIQobChMIt8ue79XE9AIVuQIGAB0-QAB2EAQYASABEgL6wfD_BwE
+09:14 < geertu> marex: SOIC is 1.27mm
+09:14 < marex> geertu: I'm sure you can use search engine to find a suitable clip ? :)
+09:15 < wsa> thanks for the links, guys, I'll check them in detail later
+09:15 < wsa> so, the topic I have is enabling RPC on Salvator boards?
+09:15 < wsa> do we want that?
+09:15 < wsa> One could argue that it is HW description
+09:15 < marex> wsa: no because platform security decision at renesas ?
+09:15 < wsa> One could also argue it is not needed because ATF disables it
+09:15 < geertu> We do have it on RZ/G2. Are these protected, too?
+09:16 < marex> upstream ATF already passes a DT fragment to U-Boot which can be used to patch status into RPC node in U-Boot, so you can pass that to Linux as well
+09:16 < marex> if ATF unblocked RPC -> status = "okay" , else status = "disabled"
+09:16 < geertu> marex: But who fills in the initial RPC device node, without status?
+09:16 < marex> geertu: the one who builds the ATF blob
+09:17 < wsa> shimoday: Thanks for forwarding the information, but you already did forward this :)
+09:18 < wsa> shimoday: My next question was if my 'udelay(100)' workaround was working for them as well?
+09:18 < shimoday> wsa: oops, i see :)
+09:19 < wsa> shimoday: if it is not working for them, then I don't need to investigate further
+09:19 < wsa> shimoday: (but I think it will)
+09:19 < shimoday> wsa: OK. I'll ask BSP team about udelay(100)
+09:19 < wsa> shimoday: thanks!
+09:20 < wsa> I'd think that Renesas Europe has different policies than Renesas Japan
+09:20 < wsa> so, I'd prefer to stick what Renesas Japan wants
+09:21 < wsa> to me, it seems they don't want RPC on Salvator boards, or?
+09:21 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has joined #periperi
+09:22 < geertu> We can still add the rpc nodes to the SoC .dtsi files only.
+09:22 < wsa> shimoday, moriperi: anything you could comment on this? I know the question comes a bit out of the blue...
+09:22 < shimoday> wsa: I have the same opinion about RPC
+09:22 < geertu> That way Renesas' customers can enable it easily, depending on their product policy.
+09:22 < wsa> I'd agree to that
+09:23 < shimoday> I guess product level system will use RPC on secure world (maybe OP-TEE?)
+09:23 < wsa> just add the RPC nodes to DTSI
+09:24 < wsa> shimoday: could you agree to that?
+09:25 < shimoday> wsa: yes, I agree
+09:25 < wsa> cool
+09:26 < wsa> we have an agreement :)
+09:26 < shimoday> (i didn't realized r8a7795 DTSI don't have RPC node
+09:27 < wsa> that's all of the topics I have (at least for IO)
+09:27 < wsa> anything from your side?
+09:27 < wsa> if Kieran is busy now, we just continue the discussion by email, of course
+09:28 < shimoday> nothing from my side
+09:28 < wsa> geertu: ready for takeoff?
+09:29 < geertu> wsa: almost
+09:29 < geertu> 30s to go...
+09:29 < wsa> have fun!
+09:29 < wsa> thanks for this meeting!
+09:29 < geertu> thx!