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
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
|
<wsa> so, welcome to the io meeting and here are the status updates: [16:54]
<jmondi> 'morning everyone
*** damm (~damm@l193216.ppp.asahi-net.or.jp) has joined channel #periperi
<wsa> A - what have I done since last time
<wsa> ------------------------------------
<wsa> Geert
<wsa> : fixed PHY Runtime PM in SH-ETH and related improvements for SMSC911X,
added Falcon I2C EEPROM support
<wsa> Niklas
<wsa> : resent Gen3 timer patches, discussed V3U timer support
<wsa> Shimoda-san
<wsa> : added mmc aliases to Gen2/3 board files, investigated RPC-IF driver
issues with BSP team, got some information about Gen3e
<wsa> Ulrich
<wsa> : sent atomic xfer support for i2c-rcar
<wsa> Wolfram
<wsa> : upstreamed V3U support for WDT, I2C, AVB0, SDHI, (H)SCIF for 5.12,
investigated issues of AVB1-5 and RPC-IF on the V3U Falcon board, sent
I2C core preparations for extended RECV_LEN sizes, improved I2C testunit
with RECV_LEN testcase, moved already rejected patches from new BSP list
to the non-target list, enabled WAIT_WHILE_BUSY and removed
NON_REMOVABLE workaround for SDHI
<wsa> B - what I want to do until next time
<wsa> -------------------------------------
<wsa> Geert
<wsa> : wants to revise Falcon I2C EEPROM support
<wsa> Niklas
<wsa> : wants to figure out number of TSC nodes on V3U
<wsa> Shimoda-san
<wsa> : wants to continue to investigate SDHI driver's issues, collect more
information about R-Car Gen3e, continue to develop R-Car S4 Ethernet
driver [16:55]
<wsa> Wolfram
<wsa> : wants to pick up "logic analyzer via isolated CPU" work again,
upstream CMT and TMU support for V3U, continue with extended RECV_LEN
and its R-Car support, keep working on SDHI issues
<wsa> C - problems I currently have
<wsa> -----------------------------
<wsa> None reported.
<wsa> uli__: is this audio task a big one? Because I wanted to talk about a
(hopefully) small RAVB task and am curious when I can get back to you?
<uli__> that's not a problem
<wsa> marex: what can we do to push the PCI L1 issue? Resend the patch?
[16:56]
<marex> wsa: probably disable L1 altogether
<wsa> uli__: okay. so, i'll send you a mail with the details later. [16:57]
<marex> wsa: and if someone needs it in the BSP, then there can be a
downstream BSP patch which enables it for special cases where it might
work OK
<wsa> unconditionally? or just for some devices?
<uli__> ok, thx
<marex> wsa: but it seems for the generic case, which maintainers seems to
care about, L1 is unusable
<wsa> caring for the generic case sounds OK to me [16:58]
<wsa> so we should disable it?
<marex> the question is whether it is OK to just disable L1 altogether [16:59]
<marex> right
<marex> I guess we are out of options anyway
<geertu> FTR, I got the interupt crash during PCIe resume on M3-W again
earlier this week
<wsa> shimoday: do you want to discuss this with the BSP team? [17:00]
<marex> geertu: with what PCIe card and on which CPU core ?
<geertu> As it's not easy to reproduce, it might be hard to see if disabling
L1 helps
<wsa> shimoday: if we should disable L1 on PCIe upstream because that's what
the maintainers prefer
<wsa> geertu: neg: thanks for testing the SDHI workaround removal patch. Much
appreciated! [17:01]
<geertu> marex: e1000e: Intel(R) PRO/1000 Network Driver
<neg> I'm happy to see that quirk gone ;-)
<wsa> neg: hopefully it will stay "gone" this time [17:02]
<marex> wsa: BSP team can keep the patch which handles the link resume [17:03]
<geertu> marex: No idea which CPU core
<marex> wsa: although maybe it is just safer to turn off the L1 states in the
BSP too
<marex> geertu: do you have the backtrace ?
<wsa> marex: exactly, maybe they want to support the generic case, too ;)
[17:04]
<wsa> okay, are there questions / comments from your side?
<shimoday> wsa: i think we don't need to discus with BSP team because it's the
maintainers prefer so BSP team will have no objection, i guess
<wsa> i have one periject topic but I want this last
<wsa> marex: can you prepare a patch then? [17:05]
<marex> shimoday: do you happen to have customers that might need L1 link
states ?
<marex> for whatever reason
<moriperi> geertu: sorry for my late response. Haha :) it is interesting way
to increase for me :) [17:06]
<geertu> marex: It's the same/similar one as
https://lore.kernel.org/linux-pci/CAMuHMdX_ksY_AnaGyL0Z4HjUv72ndRM7XsRHkSKaBP7J-xmN1A@mail.gmail.com/
[17:08]
<marex> geertu: makes me wonder whether the spinlock in atf doesn't quite
lock, uh [17:09]
<geertu> marex: oh right, could be a bug in atf ;-)
<marex> the entire gen3 L1->L0 code should be serialized
<geertu> or better :-(
<marex> hopefully not in such fundamental primitives [17:10]
<shimoday> marex: hmm, it's a difficut thing. I don't have any idea how way is
better for now...
<wsa> I guess, at least for upstream, we should disable L1 [17:12]
<wsa> BSP team then can decide if they want to pick it
<wsa> so, for my periject topic [17:13]
<shimoday> wsa: i agree
<marex> wsa: I guess we have no other options anyway
<wsa> let's wake some MM members first: kbingham[m] jmondi pinchartl neg :)
<marex> and if BSP team needs the patch, it was posted [17:14]
<kbingham> wsa, Hey I felt that
<kbingham> :-)
<wsa> some ppl said they want to add patches to the new "non-target" list
<wsa> kbingham: good \o/
<neg> zZzZ ;-) [17:15]
<wsa> I propose that we add the reason in brackets '()' for now
<wsa> Otherwise we start looking at the same patches again for patches which
won't make it upstream but are still kept in the BSP [17:16]
<wsa> I couldn't think of a better way to maintain this information for now
<wsa> (please shoot if you can think of one)
<shimoday> g [17:17]
<shimoday> sorry, my dauther typed this 'g' ;)
<geertu> wsa: You mean like
<geertu> + - d8c1fb49de142298c345bd112fbad2b26cac9013 # arm64: dts: r8a77990:
Change IPMMU-MM and IPMMU-caches order in DT (These are provisional
patches. Please refer to https
//patchwork.kernel.org/patch/10157459/)
<wsa> It needed some yes
<wsa> argh
<wsa> yes
<geertu> shimoday: Good. next important keys are "e", "e", "r", and "t" ;-)
[17:18]
<wsa> It needed some AWK scripts to port this information from good old
periupport, but it moved quite some patches away
<pinchartl> wsa: I don't wake up before 11:00 :-)
<shimoday> geertu: :) [17:19]
<wsa> pinchartl: This is why we discuss all important things before 11:00 ;)
<geertu> wsa: What exactly do you mean by "add patches ... to the list"?
<kbingham> is this for understanding why patches are rejected too? [17:20]
<wsa> geertu: basically, if you add an entry to the non-target list
<kbingham> in MM, we have rejected patches in the past, but of course BSP team
still 'need/want' them, so they are there again in this latest bsp
ticket.
<geertu> wsa: patched moved from upport request, or also for random other
patches we discover in the bsp?
<wsa> kbingham: Right. And sometimes for years, so it may be forgotten if this
could be upported or was already rejected. [17:22]
<wsa> I had this with some RAVB patches which Simon back then already tried
upstreaming but they were rejected upstream
<shimoday> kbingham: sorry for lack information. the current bsp-41x list is
from just the bsp, not thier want/need because
<wsa> But I had to find this out digging through mail threads
<shimoday> they are busy to make such "need/want" list for bsp-410...
<shimoday> so, we need re-reject such patches again [17:23]
<geertu> shimoday: Do they also plan to take our comments into account? E.g.
[17:24]
<geertu> spi: sh-msiof: Add MSIOF module clock changing processing for R-Car
Gen3 (Proposing 'N' Should use "assigned-clocks" and
"assigned-clock-rates" in board DTS file that actually uses MSIOF)
<wsa> and to avoid digging through old mails, I'd like to collect the
information somehow
<wsa> geertu: that might be another benefit [17:25]
<geertu> wsa: OK, I'll update the recent changes I made to
bsp-41x-non-target.yaml
<wsa> It may not be the best format; I guess updating from one BSP list to the
next one is probably still some strange scripting [17:26]
<shimoday> geertu: what is "into account" mean?
* jmondi catches up with the discussion
<wsa> but as people want to start filling the "non-target" list, it might be a
start at least
<geertu> shimoday: replace the BSP way by the suggestion in the comment
<jmondi> wsa: geertu: was the sweep you made to the ticket a manual process or
do you have scripts that identify patches that were rejected and
re-purposed in the new ticket ? [17:27]
<geertu> jmondi: the one marked (patch-id) and (summary) where done by some
half-baked scripting [17:28]
<wsa> jmondi: for porting the comments from periupport, I wrote scripts to
identify patches based on $subject
<geertu> run "git path-id --stable" and "git log --oneline" on all commits
upstream and in the BSP, and look for matches
<geertu> s/path-id/patch-id/ [17:29]
<geertu> s/where/were/
<jmondi> wsa: geert: I see, everyone has its own method it seems [17:30]
<geertu> jmondi: It was similar to what I do for my regular "Auto-update
sweep", which considers patch-id and lore link
<wsa> jmondi: well, the port from periupport is done now [17:31]
<wsa> now it is about porting from one bsp-list to the next
<jmondi> yeah sure, I was thinking about moving to one BSP list to anther, and
mostly for future tickets
<jmondi> anyway, thanks, it's not a huge number of patches, and some scripting
+ some manual verification should do [17:32]
<wsa> hopefully so
<wsa> when backporting upstream patches, BSP team adds lines like
"cherry-picked from: ..." to the description [17:33]
<wsa> that would be nice for cherry-picking old BSP patches, too, I'd think
[17:34]
<wsa> if the BSP team is up for it
<wsa> that said, matching on $subject worked quite well
<wsa> OK, I think we can close this now? [17:35]
<wsa> and move to core?
<jmondi> wsa: so we can match on the 'cherry-picked from' ?
<geertu> wsa: Indeed, Shimoda-san did that in 4d75bd75ef222375 ("linux:
bsp-41x: Move cherry picked commits to non target")
<jmondi> between tickets I mean
<wsa> jmondi: yes
<geertu> jmondi: If the cherry-picked points to a commit in upstream or
stable.
<geertu> I.e. if "git tag --contains <sha1> v5.11" prints v5.11 [17:36]
<geertu> (stable needs more checks, as there are more trees) [17:37]
<jmondi> oh I thought wolfram was suggesting, in case the patch has not been
upstreamed, to point to the commit id in the previous bsp ticket
<jmondi> so we can easy get to the status assigned to the patch in the
previous ticket [17:38]
<geertu> Oops, I missed that detail
<jmondi> anyway, please move to core, I don't want to continue interrupting
the meeting
<geertu> So yes, then we have to look at what cherry-picked points to for
sure!
<wsa> geertu: ready? [17:39]
<geertu> wsa: it can point to a commit in upstream, stable, or another BSP
version.
<wsa> geertu: right [17:40]
<geertu> I believe a new BSP is created by rebasing, not by cherry-picking?
(yes, technically, it's the same)
<wsa> I wouldn't want to solely rely on "cherry-picked from" anyhow [17:42]
<geertu> agreed
<wsa> It is nice if the BSP teams helps
<wsa> but we should be able to act independently from that IMO [17:43]
<wsa> so, core now? [17:44]
|
