1 files changed, 130 insertions, 0 deletions
diff --git a/wiki/Chat_log/20211202-core-chatlog b/wiki/Chat_log/20211202-core-chatlog
new file mode 100644
index 0000000..ad3ed18
--- /dev/null
+++ b/wiki/Chat_log/20211202-core-chatlog
@@ -0,0 +1,130 @@
+09:30 < geertu> Welcome to today's Core Group Chat Meeting!
+09:30 < geertu> Agenda:
+09:30 < geertu> 1. Status Updates
+09:30 < geertu> 2. Discussion Topics
+09:30 < geertu> A) What have we done since last time:
+09:30 < geertu> Marek work on U-Boot (v3 of GD non-relocation fix, v2 of LMB reservation
+09:30 < geertu> in loads command, SCIF upload mode SPL build and SD/eMMC pinmux
+09:30 < geertu> testing), ATF (WUPMSKCA5x fixes), and Linux (v3/v4 of PCIe L1 clock
+09:30 < geertu> fix).
+09:30 < geertu> Morimoto-san got Gen5 HW requests from PeriPeri, and created Renesas
+09:30 < geertu> Yocto/Android maker, and Rom Writer.
+09:30 < geertu> Shimoda-san investigated memory corruption on R-Car S4 (fixed), and
+09:30 < geertu> submitted initial R-Car S4 support patches.
+09:30 < geertu> Geert investigated merge window regressions, tried to shrink
+09:30 < geertu> of_device_id, tried improving drivers using new bitfield helpers,
+09:30 < geertu> reviewed RZ/G2L and R-Car S4 patches, and updated bsp41x and bsp51x
+09:30 < geertu> requests in periject.
+09:31 < geertu> B) What we plan to do till next time:
+09:31 < geertu> Kieran wants to test INTC-EX on Falcon again.
+09:31 < geertu> Marek plans to revisit PCIe issues.
+09:31 < geertu> Shimoda-san plans to continue working on R_Car S4 support (base, PFC,
+09:31 < geertu> SYS-DMAC, IPMMU).
+09:31 < geertu> Geert plans to send pull requests for v5.17, review more RZ/G2L and
+09:31 < geertu> R-Car S4 patches, make more periject bsp51x updates, review FOSDEM
+09:31 < geertu> submissions, refactor the growing clock codebase, and post more pinctrl
+09:31 < geertu> validation code.
+09:31 < geertu> C) Problems we have currently:
+09:31 < geertu> Kieran thinks linux-input doesn't want our test switches or even test
+09:31 < geertu> buttons to be supportable.
+09:31 < geertu> Shimoda-san is waiting for paperwork completion to send R-Car S4 boards
+09:31 < geertu> to Magnus and Europe.
+09:31 < geertu> ---EOT---
+09:31 < geertu> Anything I missed?
+09:32 < moriperi> geertu: I missed. S4 schematic is still under export paper work
+09:32 < geertu> moriperi: Thanks for your tools! Perhaps you can add links to these on the elinux wiki?
+09:33 < moriperi> geertu: Goda san has plan
+09:33 < geertu> moriperi: OK, we'll wait and see
+09:33 < moriperi> ULCB / Salvator Uboot writing should be easy, I hope
+09:33 < wsa> will be back in some minutes
+09:35 < moriperi> creating Yocto BSP should be easy, too
+09:35 < geertu> kbingham: (if you're back) So we have to leave out the slide switches?
+09:36 < marex> moriperi: please use yocto-check-layer and oelint-adv on OE BSP layers
+09:37 < geertu> Topic 2. Discussion Topics
+09:37 < geertu> A) What are you feeling about *current* BSP ?
+09:37 < geertu> How to improve upstream base BSP ?
+09:38 < moriperi> marex: thank for your advice
+09:39 < moriperi> geertu: thank you about this topic
+09:39 < geertu> About 'Thus BSP team can't use "git-rebase"'
+09:39 < geertu> There are already plenty of reverts in the BSP, so commits can be reverted, and replaced by cherry-picked upstream solutions when needed/
+09:40 < moriperi> This is still under "I guess"
+09:40 < moriperi> I will ask detail to BSP team next meeting time
+09:40 < marex> moriperi: sure
+09:41 < moriperi> Current our issue is that it is difficult to check the situation
+09:41 < moriperi> which patch was already upsteamed, which is not.
+09:41 < pinchartl> reverts are manageable I think
+09:42 < pinchartl> as long as they're real reverts, we can identify them easily
+09:42 < moriperi> I know that we are using periject for it, but BSP team is not
+09:42 < pinchartl> the annoying situation is when a change is reverted as part of a patch that performs other modifications
+09:43 < pinchartl> one area where I think we could improve the process is integration of upstream commits in the BSP
+09:44 < pinchartl> when I upport changes, or perform development in general, I have no idea how/when it will be consumed in the BSP, if ever
+09:44 < pinchartl> sometimes upstream commit sget integrated in the BSP
+09:44 < pinchartl> and bugs are fixes on top
+09:44 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has quit [Remote host closed the connection]
+09:44 < pinchartl> we only learn about those bugs when we check new BSP releases
+09:44 < geertu> Another approach is to maintain two branches: one that is never rebased (only reverts), and another one that is rebased. The heads of both branches should always be identical. This makes it easy to detect e.g. bad reverts.
+09:44 < pinchartl> it would be nice if we could have more feedback on problems
+09:45 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has joined #periperi
+09:45 < pinchartl> geertu: personally, I look at BSP commits, but I also diff the BSP head against upstream (on a per-driver basis) to see if I missed anything
+09:46 < moriperi> geertu: yeah I had same idea. but question is who work for it
+09:47 < geertu> If the BSP wants to upgrade to a later stable release (from vX.Y.Z to vX.Y.(Z+n), the non-rebasing branch merges vX.Y.(Z+n), the rebasing branch is rebased on top of vX.Y.(Z+n).
+09:48 < moriperi> geertu: yeah, it is easy to know the situation
+09:48 < wsa> back
+09:49 < wsa> BTW I think our upstream annotation in periject is not optimal
+09:49 < wsa> we don't have a link from the BSP commit to the upstream commit
+09:49 < wsa> it works if a task only contains one BSP commit, but they may include more of them
+09:51 < wsa> I think we could also detect unneeded commits better if we have that mapping correct, or?
+09:51 < kbingham> geertu, sorry - here now
+09:52 < moriperi> geertu: one note is that if BSP was very local patch, and we upported it as smart patch, the rebase vs non-rebase will have diff.
+09:52 < geertu> moriperi: true
+09:52 < neg> My feedback to BSP is to ask for more descriptive commit messages. Sometimes it's good but sometimes you have no idea why a patch was created in the BSP.
+09:54 < wsa> neg: are the questionable patches maybe old?
+09:54 < moriperi> neg: it is never-ending-topic :) I'm not sure detail but it seems BSP member was updated, and some (many?) of them don't understand how commit log is important
+09:54 < wsa> I think the BSP team has really got better in that area
+09:54 < moriperi> I want to ask it to them at the meeting
+09:55 < moriperi> Yes, it becoming better, indeed.
+09:55 < neg> wsa: I agree it have gotten better
+09:57 < wsa> moriperi: in general, I agree that the current BSP looks much better than earlier ones. There is this one big black box called UIO, however.
+09:58 < wsa> I am not sure if all the "dirty" stuff is now somewhere maintained as userspace code with UIO
+09:58 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has quit [Remote host closed the connection]
+09:58 < moriperi> wsa: yes, UIO is very dirty.
+09:58 < wsa> but the upstream drivers for IO look in a relatively good shape
+09:58 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has joined #periperi
+09:58 < moriperi> It seems they are planing to sync with other OS
+09:59 < wsa> even SDHI :D
+10:00 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has quit [Remote host closed the connection]
+10:00 < geertu> moriperi: I hope we provided good feedback for your meeting tomorrow? Do you have other questions?
+10:00 < moriperi> I think improve situation is having more close connection with BSP team, but headache is that we have small budget for Gen4 generation.
+10:00 < wsa> geertu: I have another question beside BSP
+10:01 < moriperi> Thus it will be "enough information, but no time to work for it" ?
+10:01 < geertu> wsa: ok
+10:01 < wsa> geertu: there is a hwspinlock driver in the BSP, don't we want to upstream it?
+10:01 < pinchartl> moriperi: I can see that being a problem indeed :-)
+10:01 < wsa> we talked about it in 2017, but reading the chatlogs, I assume it was in a differen state then?
+10:02 < geertu> wsa: That's MFIS?
+10:02 < geertu> Julien (iot.bzh) might work on that, given his work on remoteproc
+10:03 < wsa> commit: 66894ac410328509e3e2e23da63ec74bed383fb0
+10:03 < geertu> In fact he already sent patches to add the MFIS clock, and said he was going to look into the mailbox driver
+10:04 < wsa> ah, okay
+10:04 -!- damm [~damm@s214090.ppp.asahi-net.or.jp] has joined #periperi
+10:04 < wsa> iot.bzh is still around?
+10:05 < geertu> wsa: Yes they are ;-)
+10:05 < wsa> cool, okay, let's see then what they do with the MFIS driver
+10:06 < geertu> Anything else to discuss?
+10:06 < pinchartl> there's a discussion point from Kieran about DT validation issues
+10:06 < pinchartl> should it be discussed now, or as part of the MM meeting ?
+10:06 < shimoday> next meeting?
+10:07 < kbingham> that can be mm too ;)
+10:07 < geertu> pinchartl: I think that should be discussed with Rob
+10:07 < geertu> Jan 6?
+10:07 < shimoday> Jan 6 is OK to me
+10:08 < wsa> works for me as well
+10:08 < neg> Me too
+10:08 < uli> same
+10:08 < pinchartl> geertu: I've read your answer on the list, I agree
+10:08 < pinchartl> January the 6th is fine
+10:08 < geertu> Where the Three kings of I/O, MM, and Core come to visit the japeri kings?
+10:09 < pinchartl> geertu: given my religious beliefs, I think blasphemy would be involved :-)
+10:09 < pinchartl> I have more respect than that for your Japanese friends
+10:09 < geertu> pinchartl: don't you like pie? ;-)
+10:09 < geertu> Thanks for joining, and have a nice continued day!