1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
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!
|
