path: root/wiki/Chat_log/20211202-io-chatlog

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!