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¤cy=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!