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

09:04 < wsa> yeah, let's move on with the IO-meeting
09:04 < moriperi> neg: :)
09:04 < pinchartl> moriperi: maybe you could get the Kuril islands at the same time ?
09:05 < wsa> here are the 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> : retried PCIe s2ram on Koelsch which now works fine with Marek's fix,
09:05 < wsa>   started enabling HyperFLASH on Salvator-X(S) and Ebisu
09:05 < wsa> Shimoda-san
09:05 < wsa> : investigated R-Car S4 UFS and made it work witj 300MB/sec (read performance),
09:05 < wsa>   added gPTP support for R-Car S4 Linux BSP
09:05 < wsa> Ulrich
09:05 < wsa> : sent next version of CANFD enablement for V3U, looked at reviewer's concerns
09:05 < wsa>   about our TPU improvements
09:05 < wsa> Wolfram
09:05 < wsa> : handled I2C core updates from upstream, reviewed patches for I2C, RIIC,
09:05 < wsa>   periject, SDHI, watchdog, continued to work on cgroups_v2 for the GPIO sloppy
09:05 < wsa>   logic analyzer, collected the KingFisher board from Laurent for upporting
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 enabling HyperFLASH on Salvator-X(S) and Ebisu
09:05 < wsa> Shimoda-san
09:05 < wsa> : wants to submit R-Car UFS patch (as RFC because of missing RC21012 driver),
09:05 < wsa>   continue R-Car S4 support (Ethernet Switch as a NIC driver, PCIe), I2C support
09:05 < wsa>   of V3[HMU] on U-Boot
09:05 < wsa> Ulrich
09:05 < wsa> : wants to keep at CANFD enablement for V3U
09:05 < wsa> Wolfram
09:05 < wsa> : wants to send out next version of the GPIO sloppy logic analyzer, find out 
09:05 < wsa>  the proper solution for faulty SanDisk cards with SDHI, upport SDHI patches
09:05 < wsa> C - problems I currently have
09:05 < wsa> -----------------------------
09:05 < wsa> Geert
09:05 < wsa> : notices that RPC HyperFLASH seems to have become broken
09:05 < wsa> Shimoda
09:05 < wsa> : mentions that on V4H, only the new TSN hardware has gPTP support. RAVB doesn't have gPTP but can use the TSN gPTP. We need to find a way how to enable this in the RAVB driver
09:05 < wsa> Wolfram
09:05 < wsa> : had a slowdown of work because of a quarantine in his family. He was not infected, though, and everyone is healthy again.
09:06 -!- damm [~damm@g1-27-253-251-139.bmobile.ne.jp] has quit Remote host closed the connection
09:07 < wsa> shimoday: so, you managed to speed up UFS from 300kb/s to 300mb/s? Cool, what was the culprit?
09:07 -!- damm [~damm@g1-27-253-251-139.bmobile.ne.jp] has joined #periperi
09:08 < wsa> uli: within the TPU mails, Uwe also mentioned something about a calculation with a double division leading to imprecise values. Did you have a look at that as well?
09:08 < uli> not in detail yet
09:08 < marex> geertu: wsa: is GPU core or IO ? :)
09:08 < shimoday> wsa: there are two things, 1) mismatch UFS mode between host controller and device (called SERIES), 2) host controller doesn't seem to support hibernate mode.
09:08 < geertu> marex: MM?
09:09 < wsa> shimoday: also, with "board assignments", does it mean that Spider boards might be available for EuroPERI?
09:09 < shimoday> I'm asking HW team about hibernate mode.
09:09 < pinchartl> marex: you're welcome in MM :-)
09:09 < wsa> marex: GPU is MM?
09:09 < marex> ugh
09:10 < pinchartl> you seem thrilled by the idea of working with MM people :-D
09:10 < wsa> uli: do you have time to check his other comments as well? I agree with your reasoning for the small values, we just have to see what is consistent in the PWM subsystem
09:10 < shimoday> wsa: My plan was 2 boards to EuroPERI, but other team also wants the board, so I have to discuss the assignment with my boss
09:10 < wsa> if there is a consistency in the PWM subsystem
09:11 < neg> marex: We have tea and cookies
09:11 < shimoday> I hope I could ship a board to EuroPERI at least...
09:11 < uli> wsa: i'm inclined to agree with uwe's comments that it might not be a good idea to change the behavior of an existing driver
09:11 < uli> even if the other drivers behave differently
09:12 < wsa> uli: ok, but then it would maybe be good to add comments=
09:12 < wsa> ?
09:12 < uli> might be
09:13 < wsa> shimoday: well, one board is better than zero, of course :)
09:13 < shimoday> wsa: yes :)
09:14 < geertu> And V4H is at zero, currently?
09:14 < wsa> shimoday: about I2C in U-Boot von V3[HMU]: is it only adding the platforms or is there something wrong which works on other Gen3?
09:15 < wsa> moriperi: can you reveal something about this "Renesas Linux" here now or do we have to wait a little more?
09:16 < moriperi> I'm preparing about it. I hope +1 month I can show you
09:16 < wsa> moriperi: ok, thanks
09:17 < wsa> uli: with the review-tag for v4, it looks good that the CAN series will now be accepted. Very good
09:18 < shimoday> wsa: I realized BSP tead shared the patches today :) I checked them and then add i2c nodes and config "CONFIG_SYS_I2C_RCAR_I2C" only.
09:18 < shimoday> so, it seems easy to upport, IIUC.
09:19 < wsa> shimoday: good.
09:19 < shimoday> s/tead/team/
09:20 < shimoday> geertu: yes, V3H is at zero, currently. (however, BSP team seems to have a few boards though..)
09:20 < wsa> we have this patch, though, for V3U, don't know if this also needs to be addressed for U-Boot
09:20 < wsa> 9c975c432bc0 ("i2c: rcar: protect against supurious interrupts on V3U")
09:20 < shimoday> s/V3H/V4H/
09:21 < shimoday> I heard a V4H board for our team is available in April.
09:22 < pinchartl> shimoday: any info about availability of V4H documentation ?
09:22 < wsa> dunno if the spuriuos bits also affect the U-Boot handler but I though I mention it
09:22 < wsa> so, this was it from my side, is there anything from your side?
09:23 < marex> wsa: u-boot doesn't use interrupts, mind you
09:23 < shimoday> pinchartl: I asked in-charge person about V4H documentation, and then they are preparing now. For now, they only prepared a document under NDA of IMP.
09:24 < wsa> marex: yeah, I know, but a reason for the interrupts might be flaky status bits
09:24 < pinchartl> what's IMP ?
09:24 < shimoday> But, we don't have such NDA with Jinzai solution...
09:24 < marex> wsa: right
09:25 < shimoday> Image Processing Unit
09:25 < pinchartl> ah yes that one
09:25 < pinchartl> we would love to have documentation about all that, and upstream drivers :-)
09:27 -!- damm [~damm@g1-27-253-251-139.bmobile.ne.jp] has quit Remote host closed the connection
09:27 < geertu> Renesas Upstream First!
09:27 -!- damm [~damm@g1-27-253-251-139.bmobile.ne.jp] has joined #periperi
09:27 < marex> pinchartl: I can get powervr firmware blob sources while at it ?
09:27 < neg> There was a guy in #renesas-soc the other day talking abut the ISP software running on one of the Cortex-A53 (on rz/v2m) is that the IMP?
09:27 < shimoday> pinchartl: yes :) However, Renesas other team doesn't seem to have such a plan... I'm not sure though...
09:28 < pinchartl> marex: if it was just up to me, I'd give you the GPU RTL
09:29 < geertu> neg: "a guy" == Phil Edworthy
09:29 < geertu> ISP != IMP, AFAIK
09:29 < pinchartl> geertu: I don' mind getting both :-)
09:30 < wsa> ok, I guess this is it for the IO meeting
09:30 < pinchartl> shimoday: I know. I wasn't seriously hoping it would happen any time soon. it's a bit of a shame though, there's an increasing interest for open-source drivers for image-processing IP cores. other vendors (such as NXP with their ISP and dewarp engine) are moving in that direction, and I think it would be beneficial for Renesas to do so too. but what do I know :-)
09:30 < neg> geertu: Ahh thanks. He had left the channel before I had the change to ask him about it, and if I could have the code :-)
09:30 < wsa> let's see if we can get the switch from MM to core now ;)
09:30 < wsa> geertu: enjoy!
09:30 < geertu> wsa: Thx!