09:31 < geertu> Welcome to today's Core Group Chat Meeting! 09:31 < geertu> Agenda: 09:31 < geertu> 1. Status Updates 09:31 < geertu> 2. Discussion Topics 09:31 < geertu> Topic 1. Status updates 09:31 < geertu> A) What have we done since last time: 09:31 < geertu> Marek debugged R-Car PCIe power state change failures and created a 09:31 < geertu> better fix. 09:31 < geertu> Morimoto-san remade the Renesas ROM writer, added Yocto Maker v5.9.0 09:31 < geertu> support, and did Renesas work. 09:31 < geertu> Shimoda-san submitted R-Car S4 IPMMU patches, realized that the Spider 09:31 < geertu> board has a different UFS chip, and investigated R-Car S4 PFC/GPIO 09:31 < geertu> control domain impact. 09:31 < geertu> Geert posted R-Car S4-8 pinctrl and GPIO patches, reviewed lots of 09:31 < geertu> patches, updated bsp51x tasks in periject, and participated in FOSDEM. 09:31 < geertu> B) What we plan to do till next time: 09:31 < geertu> Marek plans to try the new PCIe power state change fix on R-Car Gen3 09:31 < geertu> without the old fix in ATF. 09:31 < geertu> Morimoto-san plans to do Renesas work. 09:31 < geertu> Shimoda-san plans to follow up R-Car S4 IPMMU and PWM, review R-Car S4 09:31 < geertu> PFC/GPIO patches, and prepare initial support for R-Car V4H. 09:31 < geertu> Geert plans to send pull requests for v5.18, review more patches, and do 09:31 < geertu> BSP mining. 09:32 < geertu> C) Problems we have currently: 09:32 < geertu> Shimoda-san is worried about board shipping. 09:32 < geertu> Geert cannot access R-Car S4 PFC/GPIO banks 4 and up. 09:32 < geertu> ---EOT--- 09:32 < geertu> Anything I missed? 09:33 < marex> I did re-push a small openocd sctlr handler, but that's not very important 09:33 < wsa> geertu: thanks for the periject updates! 09:33 < geertu> shimoday: I'm a bit confused about "pwm without a use case". Isn't it useful to have PWM support in general? 09:33 < marex> it's for when the soc starts in some odd mode and sctlr is misconfigured, that allows you to fix it up 09:35 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has quit [Remote host closed the connection] 09:35 < shimoday> geertu: I thought one of use cases about PWM is backlight 09:35 < shimoday> but, S4 doesn't have any display 09:35 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has joined #periperi 09:35 < geertu> Also, if PFC/GPIO banks 4 and up are blocked for Linux, we cannot use any of the functions on those pins (EtherAVB drive strength, CAN, MSPI) 09:36 < geertu> shimoday: display backlight is indeed one of the use cases 09:36 < shimoday> geertu: you're correct. About EtherAVB on control domain, I'm thinking it's difficult to use it on Cortex-A55 09:36 < shimoday> because the EtherAVB cannot use the DBSC directly IIUC 09:37 < shimoday> s/the DBSC/SDRAM of Cortex-A55/ 09:37 < shimoday> in other words, Linux on S4 should not use any control domain's hardware 09:38 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has quit [Remote host closed the connection] 09:38 < shimoday> this is in my opinion though... 09:38 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has joined #periperi 09:38 < geertu> OK, until someone wants to run Linux on the CR52 09:39 < geertu> So we have to two things: 09:40 < geertu> 1. GPIO: either (a) drop gpio and 4 up nodes from DT, or (b) keep them disabled 09:40 < geertu> s/and 4 up/4 and up/ 09:41 < geertu> 2. PFC: (a) drop banks 4 and up from the driver, or (b) keep them in the driver (they're not accessed unless DT has pin configuration referring to them) 09:42 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has quit [Remote host closed the connection] 09:42 < geertu> Do you have a preference? 09:42 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has joined #periperi 09:42 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has quit [Remote host closed the connection] 09:43 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has joined #periperi 09:43 < shimoday> geertu: (a) is easy implimantation than (B)? 09:44 < geertu> shimoday: yes it is. but the DTS and code have already been written ;-) 09:44 < shimoday> geertu: i see :) 09:45 < wsa> but why would we keep written code if we can't use it? 09:46 < geertu> The control domain protection can be disabled, right? 09:47 < wsa> I just read "Linux on S4 should not use any control domain's hardware" 09:47 -!- damm [~damm@m90-129-222-36.cust.tele2.se] has quit [Ping timeout: 256 seconds] 09:47 < geertu> wsa: Shimoda-san reported "So, BSP team used TAUD hardware of the control domain with releasing control domain protection." 09:48 < wsa> didn't he want the BSP team to stop using TAUD? 09:49 < geertu> wsa: yes he did 09:50 < shimoday> is it possible to choose (a) first, and change (b) if someone wants? 09:50 < geertu> Sure, we can always re-add the DTS/code later 09:51 < shimoday> in perfect world, I believe application domain should not use any control domain hardware 09:51 < shimoday> but, someone is possible to request us such a nich thing, I guess... 09:52 < geertu> shimoday: Do you know how to release the control domain protection? 09:53 < shimoday> geertu: I guess we have to use other IPL of ICUMX 09:53 < shimoday> but, i'm not sure such IPL exists though... 09:54 < shimoday> since we can re-add the DTS/code later, i prefer (a) now 09:55 < geertu> OK 09:55 < shimoday> geertu: thanks! 09:58 < geertu> shimoday: I have a question about IPMMU usage on R-Car S4. 09:58 < geertu> "mw eed01500 0xc0000000; mw eed41500 0xc0000000" changes IMSCTLR? 09:59 < shimoday> geertu: yes, these change IMSCTLR 10:00 < geertu> shimoday: So we cannot really use the IPMMU until we have updated the boot loader? 10:02 < shimoday> geertu: we can use the IPMMU now because current IPL/U-Boot seem not to enter non-secure mode. So, we can write the registers on U-Boot. 10:03 < geertu> shimoday: but we always have to do that. or it will fail (crash?) 10:03 < shimoday> geertu: yes we always have to do that. otherwise, data mismatch happens 10:04 < geertu> OK 10:04 < geertu> Anything else to discuss? 10:04 < geertu> Next meeting? 10:05 < geertu> March 10th? 10:05 < wsa> I'd suggest a regular meeting on march, 10th and a farewell-for-now-meeting on march 31st 10:05 < geertu> Fine for me 10:05 < pinchartl> should we combine the two ? :-) 10:06 < shimoday> 10th and 31st are good to me 10:06 < uli> +1 10:06 < moriperi> +1 10:06 < wsa> pinchartl: i thought about it but think our good collaboration deserves a celebrational meeting 10:07 < pinchartl> how does one celebrate on IRC ? 10:07 < kbingham> wine and beer at 8am ? ;-) 10:07 < wsa> pinchartl: you have a few weeks left to find your preferred ASCII-art site ;) 10:08 < geertu> pinchartl: You haven't learnt anything during the last 2 years? ;-) 10:08 < wsa> "wine and beer" - now kbingham woke up :D 10:08 < kbingham> I have kids, I've been woken up since early am ;-) 10:08 < moriperi> geertu: :) 10:08 < moriperi> wsa: :) 10:09 < wsa> kbingham: yes, I should have said "now we got your attention" 10:09 < pinchartl> if we want to celebrate, we could as well go all the way and make it a video meeting 10:10 < wsa> pinchartl: wow, elegant shift of topics to start the MM meeting 10:11 < pinchartl> can we ? 10:11 < marex> heh 10:11 < wsa> we do a video meeting with our clients all running on Renesas HW \o/ 10:11 < pinchartl> I'll have a hard stop today due to back-to-back meetings 10:11 < geertu> We can sit at a very large table, with a board with GSML cameras in the center? 10:11 < geertu> Doh, GMSL 10:12 < geertu> Thanks for joining, and have a nice continued day!