wiki: Add Core chatlog for 2022-02-10

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

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!