diff options
| -rw-r--r-- | wiki/Chat_log/20220210-core-chatlog | 111 |
1 files changed, 111 insertions, 0 deletions
diff --git a/wiki/Chat_log/20220210-core-chatlog b/wiki/Chat_log/20220210-core-chatlog new file mode 100644 index 0000000..90975a2 --- /dev/null +++ b/wiki/Chat_log/20220210-core-chatlog @@ -0,0 +1,111 @@ +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! |