wiki: Add Core chatlog for 2021-11-04

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

1 files changed, 72 insertions, 0 deletions

diff --git a/wiki/Chat_log/20211104-core-chatlog b/wiki/Chat_log/20211104-core-chatlog
new file mode 100644
index 0000000..dbcb72b
--- /dev/null
+++ b/wiki/Chat_log/20211104-core-chatlog
@@ -0,0 +1,72 @@
+09:38 < geertu> Welcome to today's Core Group Chat Meeting!
+09:38 < geertu> Agenda:
+09:38 < geertu> 1. Status Updates
+09:38 < geertu> 2. Discussion Topics
+09:38 < geertu> Topic 1. Status updates
+09:38 < geertu> A) What have we done since last time:
+09:38 < geertu> Kieran sent out v2 of Falcon switch support, and is waiting for input
+09:38 < geertu> from the input maintainer.
+09:38 < geertu> Marek worked on U-Boot (reloc and LMB), ATF (cache fixes), and Linux
+09:38 < geertu> (PCIe L1 clock fix).
+09:38 < geertu> Morimoto-san did Renesas Work.
+09:38 < geertu> Shimoda-san Investigated R-Car S4 issues.
+09:38 < geertu> Geert enabled 2 GHz on R-Car Gen3e-2G, sent more pull requests for
+09:38 < geertu> v5.16, reviewed more RZ/G2L patches, and posted more pinctrl validation
+09:38 < geertu> code.
+09:39 < geertu> B) What we plan to do till next time:
+09:39 < geertu> Kieran wants to test INTC-EX on Falcon again.
+09:39 < geertu> Marex plans to work on U-Boot (more LMB reservation) and ATF (upstream
+09:39 < geertu> remaining patches).
+09:39 < geertu> Shimoda-san plans to continue investigating R-Car S4 issues, and pepare
+09:39 < geertu> initial R-Car S4 support.
+09:39 < geertu> Geert plans to review more RZ/G2L patches, refactor the growing
+09:39 < geertu> clock codebase, and post more pinctrl validation code.
+09:39 < geertu> C) Problems we have currently:
+09:39 < geertu> None.
+09:40 < geertu> (but we're missing Morimoto-san)
+09:40 < geertu> ---EOT---
+09:40 < geertu> Anything I missed?
+09:40 < geertu> Topic 2. Discussion Topics
+09:41 < geertu> Are there plans for PSCI for R-Car V3U? Will R-Car S4 have PSCI?
+09:42 < wsa> geertu: what are your ideas for refactoring the clock codebase?
+09:43 < geertu> wsa: there's still some duplication left that could be factored out
+09:43 < geertu> And I was thinking about switching to unions for the various core clock types
+09:44 < wsa> you mean between all the SoC families?
+09:44 < geertu> Yes
+09:44 < wsa> I can imagine
+09:44 < shimoday> geertu: perhaps, I should ask renesas people about R-Car S4's PSCI plan at least
+09:45 < geertu> wsa: Not sure I can fit all of that in the next month, there are always other small issues popping up here and there
+09:45 < geertu> shimoday: Thanks, we will need that for SMP
+09:47 < shimoday> geertu: i got it. I'll ask BSP team or related team about this topic
+09:49 < wsa> away for some minutes
+09:51 < geertu> Anything else to discuss? (besides next meeting date, for which we have to wait for wsa to return)
+09:52 < kbingham> geertu,
+09:52 < geertu> kbingham: yes?
+09:52 < kbingham> Do you think there's merit in submitting a 'dummy' key to handle the input keys on the board?
+09:53 < kbingham> I haven't heard back from linux-input - but perhaps a patch would help
+09:53 < geertu> kbingham: a dummy key or a switch?
+09:53 < kbingham> (switch)
+09:53 < kbingham> I dislike putting switches in states that mean the system could be affected in some defined but obtuse way.
+09:53 < kbingham> So for a non-assigned, but testable switch it needs something that won't be handled by some system configuration
+09:54 < kbingham> I think that was my only real concern with those input patches.
+09:54 < kbingham> So I think I've sold it to myself - if I haven't heard anything from the input guys in a couple of weeks, I'll just add a fake switch type ... that might then push someone to discuss it anyway
+09:55 < geertu> Perhaps make it a user switch? And add a few of them (SW_USERn)?
+09:56 < kbingham> Weary of 'a few of them' because then someone will need 'one more' ;-)
+09:56 < kbingham> But perhaps 3 would be enough ;-)
+09:56 < geertu> How many do we need?
+09:56 < kbingham> two
+09:57 < kbingham> So I guess we add USER0, USER1 ;-)
+09:57 < geertu> Or #define SW_USER 0x80000000 /* user switches start here */, and use <SW_USER +0>, <SW_USWER + 1> in DTS?
+09:57 < kbingham> (or 1-based, USER1, USER2 ... that would match sw-1 and sw-2 then)
+09:58 < kbingham> Aha - ok that works for me ;-)
+09:58 < geertu> (or are they 16-bit? then use 0x8000)
+09:58 < kbingham> I'll sift through the details - thanks, that's enough to spin a patch out of it
+09:58 < geertu> I hope there's no array of size SW_CNT somewhere in the kernel ;-)
+09:59 < kbingham> I'll check that too then ;-)
+09:59 < geertu> IMHO it definitely makes sense to have user switches. Unlike the keys, (most of) the defined switch types are kind of dangerous.
+09:59 < kbingham> ^ yup - that was my concern.
+10:00 < kbingham> Thanks ;-)
+10:02 < kbingham> Ok - any more Core discussions? or MM time?
+10:02 < geertu> Nothing from my side. We can handle the next meeeting data when wsa is back/
+10:02 < kbingham> ack
+10:03 < geertu> Thanks for joining, and have a nice continued day!