diff options
Diffstat (limited to 'wiki/Chat_log/20211104-core-chatlog')
-rw-r--r-- | wiki/Chat_log/20211104-core-chatlog | 72 |
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! |