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
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
|
Core-chat-meeting-2018-08-23
09:35 < geertu> Welcome to today's Core Group Meeting!
09:35 < geertu> Agenda:
09:35 < geertu> 1. Status Updates
09:35 < geertu> 2. Discussion Topics
09:35 < geertu> Topic 1. Status updates
09:35 < geertu> A) What have we done since last time:
09:35 < geertu> Kaneko-san upported M3-N CPUFreq upport.
09:35 < geertu> Marek worked on U-Boot (discussing PCI DT parsing, and Gen2 USB PHY) and
09:35 < geertu> Linux (PCIe link L0/L1 switching on Gen3).
09:35 < geertu> Morimoto-san worked on PeriJect and Ebisu-4D export (Laurent/Simon/Geert).
09:35 < geertu> Shimoda-san says the RVC test team will test the new LTSI v4.14 snapshot.
09:35 < geertu> Simon tested M3-N CPUFreq, and submitted backports for LTSI-4.14.
09:35 < geertu> Ulrich sent H3/M3-W cpuidle support.
09:35 < geertu> Geert tested Simon's 4.14.61-based backport.
09:36 < geertu> B) What we plan to do till next time:
09:36 < geertu> Marek will continue Linux PCIe L0/L1 switching and U-Boot PCI DT parsing
09:36 < geertu> discussions.
09:36 < geertu> Morimoto-san will continue PeriJect development and Ebisu-4D export
09:36 < geertu> (Magnus).
09:36 < geertu> Shimoda-san will check the new LTSI v4.14 snapshot test results from the
09:36 < geertu> RVC test team, and will pave the way forward for IPMMU.
09:36 < geertu> Simon will continue testing M3-N CPUFreq.
09:36 < geertu> Geert will continue QEMU GPIO virtualization, handle SYSC and PFC errata,
09:36 < geertu> and review LTSI submissions during the merge window.
09:38 < geertu> C) Problems we have currently:
09:38 < geertu> Marek needs feedback from HW team on the PCI L0/L1 switching.
09:38 < geertu> Anything I missed?
09:38 < Marex> shimoda: OK, email sent, please let me know if I can tweak it somehow to get useful feedback from the HW team soon :)
09:39 < geertu> Topic 2. Discussion Topics
09:39 < geertu> Anything to discuss?
09:40 < damm> memory auto detect!
09:40 < damm> how to proceed
09:40 < pinchartl> I'd like to discuss handling of BSP patches, in relation with periject
09:40 < pinchartl> damm: you can go first
09:41 < geertu> uli___: Any update?
09:41 < damm> thankssssssssssssssssssss
09:41 < uli___> not from me
09:41 < shimoda> Marex: Thank you for the email! by the way, what's your envirnoment? H3 ES1.x?
09:41 < damm> so whats the next step forward with the memory detection i wonder?
09:42 < Marex> shimoda: H3 ES2
09:43 < shimoda> Marex: Thanks!
09:43 < geertu> Marex: You had some feedback from the generic U-Boot side?
09:43 < Marex> shimoda: the latest greatest is H3 ES3, right ? :)
09:43 < Marex> shimoda: you're welcome
09:43 < damm> i suppose this topic is related to ATF
09:43 < Marex> geertu: generic u-boot side of ... what ?
09:43 < geertu> memory detection
09:43 < Marex> geertu: oh that
09:43 < Marex> geertu: nope, nothing
09:44 < Marex> geertu: I can just implement the decoder for the ATF memory layout tables and put it in ...
09:44 < damm> we have no ATF code in upstream yet, right?
09:44 < shimoda> Marex: you're right :)
09:44 < damm> but i recall Marex doing some work somewhere
09:44 < Marex> damm: not yet, sorry
09:44 < Marex> damm: I upported the D3/V3M ATF to 1.0.22r2 (latest)
09:45 < Marex> damm: I didnt start feeding it upstream yet
09:45 < damm> to have at least one known working system with autodetection, perhaps we can upstream ATF support for one board/SoC and complete upstreaming of the u-boot portion too?
09:45 < Marex> damm: the U-Boot portion is easy I think
09:46 < Marex> damm: from what pinchartl told me, the ATF just puts memory layout tables in RAM, so U-Boot can parse that and fill linux DT with that information
09:46 < damm> i suppose we want something robust so in case ATF doesn't support memory detection we still have working upstream u-boot
09:47 < Marex> damm: fall back to small amount of memory that's always present ?
09:47 < damm> sure
09:47 < damm> i suppose we want to disconnect the upstreaming/upgrade path of u-boot from ATF
09:47 < geertu> Seems like there's also an H3ULCB with 8 GiB of RAM?
09:48 < Marex> damm: yes, those things should be separate
09:48 < damm> but starting with ATF must make sense so we don't implement code in u-boot that can't be merged
09:48 < Marex> damm: there should be a minimum version requirement for ATF on which U-Boot and Linux works fine, but that's about it
09:49 < Marex> damm: start with ATF how ? by patching it support passing some more sane memory info to the upper layers ?
09:50 < damm> i guess since everything is out of tree when it comes to ATF we don't want to make it more difficult than necessary to adopt upstream code
09:50 < damm> i would say upstreaming of ATF for one platform
09:50 < Marex> damm: sure
09:51 < damm> some basic minimal support level
09:51 < damm> and then add that auto-detection bit
09:51 < damm> that would make sense to me at least
09:51 < Marex> damm: the autodetection can be implemented with current ATF already, the question is whether that (those tables that ATF populates) can be considered an ABI
09:52 < damm> then we can handle features and other SoCs/board incrementally after that
09:52 < damm> out of tree ABIs are not exactly smelling good in my book
09:52 < Marex> damm: right
09:53 < damm> so shall we get Renesas to approve upstreaming of H3 ATF for instance?
09:53 < damm> would anyone including Marex and Uli be interested in that kind of work?
09:54 < geertu> damm: Yes please (for upstreaming)
09:54 < Marex> damm: I have upstreaming of the ATF for D3/V3M on my list I wrote in Japan
09:55 < damm> ok so lets check with Renesas about preferred platform out of D3/V3M/H3
09:55 < damm> I suppose we can make use of memory autodetect on H3 mainly
09:55 < Marex> :-)
09:55 < damm> but hey, this is just an ordering problem really
09:56 < geertu> For H3/M3-W/M3-N, the memory is on the SiP (for M3-N that may not be true for production SoCs)
09:56 < geertu> Is there any ID on the SiP that can be read?
09:57 < damm> that would indeed be nice
09:57 < geertu> Which brings us to [PATCH 0/8] arm64: dts: renesas: Break out R-Car H3 and M3-W SiP"[PATCH 0/8] arm64: dts: renesas: Break out R-Car H3 and M3-W SiP" (https://www.spinics.net/lists/devicetree/msg173820.html) again ;-)
09:58 < geertu> No, we don't want _more_ DTS files to maintain...
09:58 < Marex> geertu: but if it's SiP, someone can populate pretty much random DRAM chip on it, right ?
09:58 < Marex> geertu: it's just a matter of soldering it on
09:59 < geertu> Marex: the same is true for boards with an SoC instead of an SiP
09:59 < geertu> Although soldering the SiP may be a tiny bit harder ;-)
10:00 < geertu> Anyway, we're deviating.
10:00 < geertu> So:
10:00 < geertu> 1) upstream ATF for one R-Car Gen3 SoCs
10:00 < geertu> 2) update ATF for memory auto-detected
10:00 < geertu> 3) update U-Boot for memory auto-detect
10:00 < geertu> Sounds good?
10:00 < damm> yeah perfect
10:00 < damm> thanks
10:01 < Marex> geertu: sounds good
10:01 < damm> oh one thing
10:01 < Marex> geertu: so we just need the approval for H3/M3x or get me a physical D3/V3M :-)
10:01 < damm> will uli simply hand over stuff to Marex then?
10:02 < uli___> i would prefer that
10:02 < damm> lets do that then
10:02 < shimoda> damm: about ATF upstreaming, does it need Renesas side help? or, we can upport from in-house code anyway?
10:02 < damm> shimoda: maybe q&a is needed
10:03 < damm> shimoda: but apart from that i don't expect much help is needed
10:03 < Marex> shimoda: I think the goal would be to move in-house code (after cleanup and maybe rewrite) to upstream ... and then there would be no more inhouse code :)
10:03 < damm> Marex: what do you think?
10:05 < shimoda> damm: i see... I heard BayLibre tried upstreaming ATF but they have many questions to Ito-san, but since Ito-san and renesas ATF team are very busy, so no progress now... ;)
10:05 < Marex> damm: I might have a few questions if there are registers which are not in the documentation or weird things happening, but in general from what I saw, not much help would be needed
10:05 < damm> so letting Marex use the in-house code as sample and then he can decide by himself how to handle upstreaming?
10:05 < damm> shimoda: maybe our friends at BL will be happy with some assistance then
10:05 < geertu> Any political conflict with BayLibre?
10:06 < damm> don't think so
10:06 < damm> so lets see how Marex will accelerate this activity =)
10:06 < geertu> Great!
10:07 < shimoda> damm: should I ask Ito-san about who is trying to upstream in BayLibre?
10:07 < geertu> Last(?) topic: BSP and periject?
10:07 < damm> shimoda: sure, and please ask about what target platform they focus on
10:07 < Marex> damm: can I get a go/no-go when you check with BayLibre and input on which SoC I should use for upstreaming (H3/M3x/D3/V3x) ?
10:08 < damm> sure
10:08 * pinchartl takees the microphone
10:08 < damm> will let you know
10:08 < Marex> damm: thanks, so in the meantime I'll keep haggling about the PCI
10:08 * geertu releases
10:08 < shimoda> damm: i got it
10:08 < pinchartl> I attended the "periperi process meeting yesterday"
10:08 < Marex> on both U-Boot and Linux front no less , sigh
10:08 < Marex> damm: thanks
10:08 < pinchartl> which turned out to be a discussion between Magnus and I :-)
10:09 < pinchartl> we spent two hours going around many topics
10:09 < morimoto> wow
10:09 < jmondi> I missed it was yesterday, my bad
10:09 < pinchartl> no worries
10:10 < pinchartl> we decided to segment the problem, as handling everything in one go would be a too large task
10:10 < pinchartl> so the topic I'd like to discuss today is handling of the BSP patches
10:10 < pinchartl> today's situation is as follows (in a very summarized form)
10:10 < morimoto> This is good timing, we got new upport list from BSP team
10:11 < pinchartl> we, the upstreaming team, work on the upstream kernel
10:11 < pinchartl> Renesas consumes the result of our work, through renesas-drivers, and creates BSPs
10:11 < pinchartl> there are several layers there, as not all kernel code is in the public BSP (I'm thinking about codec drivers for instance)
10:11 < pinchartl> and I'm sure there are customer trees as well
10:12 < pinchartl> but in a nutshell, we get a BSP
10:12 < damm> (or a bucket of mud as i referred to it)
10:12 < pinchartl> the BSP is the result of a process that takes the upstream kernel, identifies issues (bugs, performance problems, missing features...), and fixes those issues
10:13 < pinchartl> that process, internally, uses various means of bug tracking (including lots of excell spreadsheets from what I've been told), to which we have no access externally
10:13 < wsa> all Japanese, too, probably?
10:13 < neg> damm: :-)
10:14 < pinchartl> as an upstreaming team, we strive for feature completeness, stability and performances
10:14 < pinchartl> so it is of value to us to know about the issues that have been identified
10:14 < pinchartl> we have started efforts to implement automated tests ourselves to catch regressions and other problems
10:15 < pinchartl> but given that we are resource-constrained, we can't match for now all the testing effort done internally by Renesas
10:15 < pinchartl> and by Renesas' customers (I've been told that customers are the best source of bug reports)
10:15 < pinchartl> wsa: and yes, lots of information is in Japanese
10:15 < pinchartl> so that's the current situation
10:15 < pinchartl> now, where do we want to go ?
10:15 < pinchartl> *ideally*
10:16 < pinchartl> we should get access to a common issue tracker, with all the information available for all identified issues
10:16 < pinchartl> that's something I'd like to happen, but it's a very long term project
10:16 < pinchartl> we can't expect that in the short or mid term
10:17 < pinchartl> so today, our largest source of information about issues in the upstream kernel is the BSP
10:17 < pinchartl> as most BSP commits fix an issue (alleged or real)
10:18 < pinchartl> for that reason, Magnus and I agreed that we need to base our process to achieve feature completeness, stability and performances partly at least on the BSP commits
10:19 < pinchartl> furthermore, we are, at least partly, evaluated on how we reduce the delta between the BSP and upstream
10:19 < pinchartl> and thus on the amount of BSP code that we "upport"
10:19 < pinchartl> "upporting" here means either direct upporting, or development of equivalent fixes
10:19 < pinchartl> so it's often more about superseding the BSP commits than really uppporting them
10:20 < pinchartl> it's thus useful internally for Renesas, at least if my understanding is correct, to track how BSP commits are replaced
10:20 < pinchartl> we thus need a list of BSP commit, associated with a status, in order to track our progress
10:21 < pinchartl> both on our side, to make sure no BSP commit falls through the cracks, and on Renesas' side, to evaluate progress
10:21 < pinchartl> we have such a list, in a shared git tree
10:21 < pinchartl> but there's one issue that I haven't mentioned yet
10:21 < pinchartl> BSP commits come with very little information
10:21 < pinchartl> there's often no commit message
10:21 < pinchartl> and when there's a message, it's usually terse
10:22 < pinchartl> there's usually no information about which platforms are affected by the issue
10:22 < pinchartl> or how to reproduce it
10:22 < wsa> ^ that!
10:22 < pinchartl> or the userspace use cases
10:22 < pinchartl> we are thus often left in the dark
10:23 < pinchartl> and we randomly send e-mails to Morimoto-san, sometimes CC'ing the author of the BSP commit, asking for clarifications
10:23 < pinchartl> that's not a very efficient process
10:23 < pinchartl> as information gets lost somewhere in mailing list archives
10:23 < pinchartl> or in private e-mails
10:24 < pinchartl> so Magnus and I are proposing storing additional information in the database of BSP commits
10:24 < pinchartl> which would become, in a way, an interface with the BSP team
10:24 < pinchartl> when a new BSP is released, the BSP team will add commits to the database (they already do today)
10:25 < pinchartl> and our proposal is to add a way for the BSP team to add a description for each commit
10:25 < pinchartl> ideally that wouldn't be needed
10:25 < pinchartl> as all information we need should be in the commit messages
10:26 < pinchartl> but realistically that won't happen
10:26 < pinchartl> we should try to get there gradually, but things will never be perfect anyway
10:26 < pinchartl> so, the idea is to have, for each BSP commit, a status, and a description
10:26 < pinchartl> if we need more information we can just mark the commit as requiring information
10:27 < pinchartl> all that would still be stored in a git tree, as it is today
10:27 < pinchartl> and both us and the BSP team would have access to that tree
10:27 < pinchartl> we need to extend the storage format used today for the BSP commits
10:28 < pinchartl> and, on top of that, tools could also be developed
10:28 < pinchartl> as long as the storage format is defined, we could even have multiple tools, command-line-based, GUI, web-based, if someone has time to spend :-)
10:29 < geertu> Sounds good to me. thx!
10:29 < pinchartl> to conclude on the topic, what we'd like to agree on, is the data storage format, and the process to handle BSP commits
10:29 < kbingham> Another git-backed-information-storage tool I came across lately might be of interest on this topic: https://github.com/sit-fyi/sit
10:29 < pinchartl> (who adds them, who updates them, how, ...)
10:29 < pinchartl> now the mic is yours, we take questions :-)
10:30 < pinchartl> kbingham: thanks for the link
10:30 < damm> may i raise two points from my side?
10:31 < pinchartl> sure
10:31 < damm> thanks for sharing the details very well
10:31 < damm> i just wanted to mention two things
10:31 < damm> 1. we should remember that BSP is one source of issues
10:32 < damm> issues may come from a mailing list too for instance
10:32 < damm> 2. we will have multiple buckets in progress at any given time
10:32 < kbingham> Or issues /we/ find in our testing :)
10:32 < pinchartl> damm: regarding the first item
10:32 < pinchartl> sure
10:33 < pinchartl> we also get requests or bug reports by e-mail
10:33 < wsa> we also find bugs by ourselves :)
10:33 < pinchartl> (both e-mails from Renesas and from third-parties, in public or private e-mails)
10:33 < pinchartl> possibly on IRC
10:33 < damm> yeah, so no need to keep a too bsp-upport centric view
10:33 < pinchartl> and there are bugs we find ourselves, yes :-)
10:33 < pinchartl> so yesterday we also discussed the need to have an issue tracker
10:34 < pinchartl> which would be at a level just above the BSP commit tracker
10:34 < pinchartl> but that's a second step, I don't want to try and solve all problems in one go as I explained in the beginning
10:34 < damm> totall agree, thanks!
10:34 < pinchartl> tracking BSP commits is the low-hanging fruit in my opinion
10:34 < pinchartl> as we know it's useful and needed
10:34 < pinchartl> (both for us and Renesas)
10:35 < pinchartl> the information we need to track are limited, the workflow is simple
10:35 < pinchartl> so it can be implemented in a relatively simple way
10:35 < pinchartl> once we get there I'd like to move to issue tracking
10:35 < pinchartl> of course if someone has too much free time, we can work in parallel :-)
10:36 < jmondi> one question: instead of going in the "BSP -> issue tracker" direction, shouldn't it be smarter to setup an issue tracker and ask BSP to use it? so that it's there already for us to use if we have bugs to list too
10:36 < geertu> Public bug reports (email, irc) are usually fixed quicker, mostly because there's a direct link with the reporter, leading to more accurate bug information.
10:36 < jmondi> it would also force BSP to reason in terms of "issue -> patch series" not the other way around
10:36 < pinchartl> jmondi: that's a very good question
10:37 < pinchartl> and I think the answer is yes
10:37 < pinchartl> but I'm concerned about how to get there
10:37 < pinchartl> I'd like to tell the BSP team today that we'll stop taking BSP commit directly, and that they should file proper issue reports
10:37 < pinchartl> but I doubt they will
10:38 < pinchartl> my hope is that, but creating a BSP commit tracker that they feed as they do today
10:38 < wsa> I'd think our possibilty to "force" something onto the BSP team is limited
10:38 < jmondi> run a $BUGZILLA hosted by renesas?
10:38 < jmondi> I'm sure it might take a long time, but...
10:38 < wsa> I think we should aim for cooperation
10:38 < pinchartl> with an additional feature of having a description they can fill as well
10:38 < pinchartl> will let us push them to fill descriptions
10:38 < pinchartl> once they get used to that
10:38 < wsa> They probably have lots of other issues/people to deal with
10:39 < jmondi> wsa: as well as we do
10:39 < pinchartl> we could get better commit messages in the first place
10:39 < pinchartl> and it might be easier to ask them to transition from BSP commit tracking to issue tracking too
10:39 < pinchartl> maybe I'm too optimistic though
10:39 < jmondi> wsa: I just don't think it's efficient we go through the process "Oh look a series, who knows what it tries to solve"
10:39 < wsa> it isn't
10:39 < pinchartl> but the only way I see to get better information is to make it more painful for them when they don't provide the information :-)
10:40 < pinchartl> if a commit has no commit message, we just send it back, asking for information
|
