wiki/Chat_log/20150901-core-chatlog


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
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454

11:02 #periperi: < geertu> Welcome to the Core Group Chat Session!
11:02 #periperi: < uli___> good morning
11:02 #periperi: < horms> Thanks, nice to be back
11:02 #periperi: < geertu> Today's agenda:
11:02 -!- Irssi: Pasting 5 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
11:02 #periperi: < geertu> 1. Upcoming Gen3 development for the Core group,
11:02 #periperi: < geertu> 2. Topic/branch/merge organization of Gen3 work,
11:02 #periperi: < geertu> 3. DMA topology,
11:02 #periperi: < geertu> 4. CPG and boot mode via syscon (or not),
11:02 #periperi: < geertu> 5. Status check for tasks from last meeting - what is remaining?
11:03 #periperi: < morimoto> dammsan: which port is bock-w ?
11:04 #periperi: < dammsan> morimoto: 8004
11:04 #periperi: < morimoto> # this is not core topic, but now we have 2 board, and I will send it to Europe engineer
11:05 #periperi: < morimoto> # but because of papwer work, it will be next week
11:05 #periperi: < morimoto> dammsan: thanks
11:06 #periperi: < horms> morimoto: i use bockw sometimes, so lets co-ordinate here if you want to use the board
11:06 #periperi: < horms> uli___:
11:06 #periperi: < horms> uli___ also uses it, but usually while we are ase
11:06 #periperi: < horms> uli___ also uses it, but usually while we are ase
11:06 #periperi: < horms> uli___ also uses it, but usually while we are asleep
11:06 #periperi: < uli___> indeed
11:06 #periperi: < horms> (typing disaster!)
11:06 #periperi: < geertu> Topic 1. Upcoming Gen3 development for the Core group,
11:07 #periperi: < dammsan> geertu: right
11:07 #periperi: < dammsan> i intend to update the cpg series and the integration series
11:08 #periperi: < dammsan> and also work on irqc
11:08 #periperi: < dammsan> but i hope to keep the integration series small until we can stabilize the cpg and the pfc
11:08 #periperi: < dammsan> so focus must be on stabilizing pfc and cpg
11:09 #periperi: < geertu> Integration is the hardest w.r.t. merge conflicts (but that's actually topic 2)
11:09 #periperi: < horms> I plan to put integration series's into topic branches as they appear; only addrssing apply and build time dependencies
11:09 #periperi: < horms> (sorry, lets talk about that in topic2)
11:10 #periperi: < dammsan> (yeah, sorry, so what shall we talk about for topic1?)
11:10 #periperi: < geertu> Stabilize CPG and PFC
11:10 #periperi: < dammsan> ok =)
11:10 #periperi: < geertu> It seems dropping clock-output-names was not such a good idea...
11:10 #periperi: < dammsan> i did it because it seemed that mike turquette wanted us to do so
11:10 #periperi: < dammsan> but perhaps i misunderstood
11:11 #periperi: < geertu> No respnse from Mike yet (although he's alive, sent pull request, and replied to me in other personal email)
11:11 #periperi: < horms> I saw him last week; he was also alive then!
11:11 #periperi: < dammsan> i think we can work around things by registering names using in-driver generated names
11:11 #periperi: < dammsan> not exposing names in DT seems like a fine idea to me
11:12 #periperi: < geertu> Nope, all fixed-factor-clocks rely on clock-output-names in the parent clocks
11:12 #periperi: < dammsan> geertu: sure
11:12 #periperi: < dammsan> but can't we work around that somehow?
11:12 #periperi: < dammsan> by providing clock-output-name equivalent but from the driver?
11:12 #periperi: < geertu> the scif driver "works" (for scif2) as it assumes 115200 baud and doesn't program registers
11:13 #periperi: < dammsan> sure, i think that is the state of the entire CPG series
11:13 #periperi: < geertu> clk_of_get_parent_clock_name() looks in DT, it doesn't follow in-kernel clock topology
11:13 #periperi: < dammsan> maybe it should?
11:13 #periperi: < geertu> That's one option.
11:14 #periperi: < dammsan> so say it would work, then isn't omitting that parameter from DT a good idea?
11:14 #periperi: < geertu> I think "no clock-output-names" is meant for clocks with a single output, where the node name can be used instead
11:14 #periperi: < dammsan> ok i see
11:14 #periperi: < dammsan> so we could have one node per clock instead
11:14 #periperi: < geertu> It may be a good idea if the driver knows (like cpg)
11:14 #periperi: < dammsan> or perhaps we should extend the core to support index?
11:15 #periperi: < geertu> For mstp the driver doesn't know, so it comes up with mstp3.10
11:15 #periperi: < geertu> I'd like to wait for the clock people's response
11:15 #periperi: < dammsan> the cpg driver could do the same
11:15 #periperi: < dammsan> since we have the strings there anyway
11:15 #periperi: < geertu> Clocks work again just by re-adding clock-output-names to the dtsi only (no driver update needed)
11:16 #periperi: < dammsan> waiting for maintainer feedback is of course a good plan
11:16 #periperi: < dammsan> but is there something we could do in the meantime?
11:16 #periperi: < dammsan> we could re-add clock-output-names like you say
11:16 #periperi: < dammsan> or just fix the code in the cpg driver
11:16 #periperi: < geertu> It's not a problem in the cpg driver
11:16 #periperi: < geertu> and it can't be fixed there
11:17 #periperi: < geertu> only in core clock code
11:17 #periperi: < dammsan> oh, but this only triggers in the case of CPG and not in MSTP, right?
11:17 #periperi: < geertu> It doesn't trigger in mstp, because the only users of mstp clocks are devices, where clk_get() will do the right thing.
11:18 #periperi: < geertu> If you register e.g. a fixed-factor-clock as a child of an mstp clock, it will fail, too
11:18 #periperi: < dammsan> ok then consider me convinced =)
11:18 #periperi: < horms> +1
11:19 #periperi: < geertu> Basically it fails for every clock in DT where the parent has multiple clock outputs
11:19 #periperi: < dammsan> so we should wait for feedback?
11:20 #periperi: < dammsan> or does anyone feel like cooking up some core CCF code? =)
11:20 #periperi: < dammsan> maybe i simply misunderstood mike turquette
11:20 #periperi: < geertu> Not me, because I think the "no clock-output-names rule" is flawed
11:22 #periperi: < geertu> Any other upcoming gen3 work (irqc is already in the task list)?
11:22 #periperi: < shimoda> we should prepare thermal driver in Sep.
11:22 #periperi: < dammsan> does it make sense to pick up the GPIO stuff?
11:23 #periperi: < geertu> I have it included in today's renesas-drivers
11:23 #periperi: < dammsan> i think i prefer to keep the integration patch set small (and that's topic2 sorry)
11:23 #periperi: < shimoda> gen3 thermal seems not compatible with gen2 :)
11:23 #periperi: < geertu> Indeed, but thermal is I/O, not Core?
11:25 #periperi: < dammsan> geertu: how shall we split the core work then?
11:25 #periperi: < horms> possibly but the next I/O group meeting is not for 2 weeks, there won't be much September left then
11:25 #periperi: < horms> perhaps it is a topic for email?
11:25 #periperi: < shimoda> oops, my sheet is written as core
11:25 #periperi: < geertu> gpio lacks power-domains properties, but for now that works due to an obsolete CONFIG_ARCH_SHMOBILE_MULTI check in drivers/sh/pm_runtime.c
11:26 #periperi: < geertu> dammsan: what do you mean with "how shall we split the core work then?"
11:27 #periperi: < shimoda> horms: I will send thermal topic to periperi ml
11:27 #periperi: < geertu> I have PFC and CPG in renesas-drivers#topic/...
11:27 #periperi: < dammsan> i can deal with igeertu: i meant how to handle development of PFC and CPG
11:28 #periperi: < dammsan> morimoto: are you doing ok with PFC?
11:28 #periperi: < dammsan> do you need any help?
11:28 #periperi: < geertu> Simon has integration in renesas#topic/...
11:28 #periperi: < morimoto> I think I can send next version of PFC tommorrow
11:28 #periperi: < morimoto> I need to check PFC macro on BockW
11:28 #periperi: < dammsan> morimoto: why don't you reorder things to add your cleanup as incremental patch?
11:29 #periperi: < dammsan> or does the code become better if you make the cleanup first?
11:29 #periperi: < geertu> TOpic 2. Topic/branch/merge organization of Gen3 work,
11:29 #periperi: < dammsan> i guess i don't understand the need for the dependency
11:29 #periperi: < dammsan> geertu: can we discuss CPG development later?
11:29 #periperi: < geertu> The cleanup changes the name of a macro
11:30 #periperi: < geertu> sure
11:30 #periperi: < geertu> (in topic 4?)
11:30 #periperi: < dammsan> sure, sorry!!
11:31 #periperi: < dammsan> it is of course up to morimoto-san to decide about his cleanups
11:31 #periperi: < geertu> Apart from the macro cleanup, I think PFC should switch to an incremental model, at least for inclusion in renesas-drivers
11:31 #periperi: < geertu> same for integration
11:32 #periperi: < horms> geertu: can you clarify what you mean by incremental?
11:32 #periperi: < dammsan> geertu: from when?
11:32 #periperi: < geertu> What's ultimately submitted would be an interactive rebase result of the initial patches and the incrementals
11:32 #periperi: < dammsan> that means you consider it stable enough soon?
11:32 #periperi: < geertu> It doesn't make sense to keep on resubmitting (almost) the same series to the list, with a few pingroup entries (pfc) or device nodes (dtsi) added
11:33 #periperi: < horms> true
11:33 #periperi: < geertu> No one's gonna take patches before rc1 is released
11:33 #periperi: < horms> from my pov a small(ish) base patch is a good start that can be reviewed
11:33 #periperi: < geertu> while we want to keep developing, not rebasing and resubmitting
11:33 #periperi: < horms> as can any incremental patches that add needed support
11:34 #periperi: < horms> that way we review what we are using (which is probably smaller than everything)
11:34 #periperi: < horms> and by implication deffer reviewing the rest
11:34 #periperi: < geertu> So I'm happy seeing e.g. topic/gen3-cpg-v5
11:34 #periperi: < horms> in my opinion that makes sense particularly at this busy time
11:35 #periperi: < dammsan> i'm confused
11:35 #periperi: < dammsan> =)
11:35 #periperi: < dammsan> so what would you prefer? can you repeat please?
11:35 #periperi: < geertu> Of course we must make sure to have the base (refferred to by device nodes) covered, which is interrupts, clocks, and dmas
11:36 #periperi: < dammsan> geertu: but the base is not yet stable right?
11:36 #periperi: < geertu> It more or less is.
11:36 #periperi: < geertu> Except for the pesky clock-output-names
11:36 #periperi: < dammsan> yes, and that is used by every node =)
11:36 #periperi: < geertu> if we have to re-add them to the mstp nodes, that means it affects many patches
11:37 #periperi: < dammsan> right
11:37 #periperi: < dammsan> PFC seems much close at this point
11:37 #periperi: < geertu> indeed
11:38 #periperi: < geertu> For supporting other devices, there are usually two parts:
11:38 #periperi: < geertu> a. driver update (can be just a new DT compatible value added to the bindings)
11:38 #periperi: < geertu> b. integration (dtsi and defconfig)
11:38 #periperi: < geertu> a. is fairly independent, and I can take that in renesas-drivers#topic/...
11:39 #periperi: < geertu> b. is for Simon's renesas#topic/...
11:39 #periperi: < dammsan> b probably needs to be ordered right?
11:39 #periperi: < geertu> but usually each new patch depends contextually on the previous one
11:39 #periperi: < horms> yes, that seems likely
11:39 #periperi: < geertu> which means it must be "correct" when Simon applies it.
11:40 #periperi: < geertu> While a. I can easily update/replace
11:41 #periperi: < dammsan> we need to expose both a and b to a larger audience IMO
11:41 #periperi: < geertu> Right now the b.'s are stuck on clock-output-names
11:41 #periperi: < dammsan> yes
11:41 #periperi: < geertu> so all of them may need rework
11:41 #periperi: < dammsan> i agree with that observation
11:42 #periperi: < dammsan> but upstreaming of "a" can happen independently anyway
11:42 #periperi: < geertu> The a.'s can follow the standard patch submission rules to maintainers when deemed stable
11:42 #periperi: < geertu> yep
11:42 #periperi: < dammsan> so where are we with the core driver bits ("a")?
11:42 #periperi: < geertu> The b.'s have to go in through Simon's tree, right
11:43 #periperi: < horms> that is their upstream path
11:43 #periperi: < horms> for topic branches things are less fixed imho
11:43 #periperi: < geertu> scif just needs a vinding update
11:43 #periperi: < geertu> s/vinding/binding/
11:43 #periperi: < geertu> so that can go upstream after rc1
11:43 #periperi: < dammsan> geertu: the silliness of SCIF2 is that included in that summary? =)
11:44 #periperi: < geertu> same for gpio
11:44 #periperi: < shimoda> dammsan: some timers and dmaengnie?
11:44 #periperi: < dammsan> shimoda: sure
11:44 #periperi: < horms> is scif2 secret; if so should it be omitted from mainline?
11:44 #periperi: < dammsan> secred irda, haha, what is this, 1984?
11:44 #periperi: < geertu> it's the console. So we have a secret black box the user is interacting with :-)
11:45 #periperi: < horms> figures
11:45 #periperi: < dammsan> but seriously, how do we handle DT in case of SCIF2?
11:45 #periperi: < dammsan> is that a I/O group problem perhaps? =)
11:45 #periperi: < geertu> We have the missing interrupt from an older datasheet, and the driver needs it
11:46 #periperi: < geertu> DT is integration, not I/O ;-)
11:46 #periperi: < geertu> so byebye secrecy
11:46 #periperi: < horms> sounds awkward
11:46 #periperi: < dammsan> hm, i thought every per-driver DT binding doc was part of driver development
11:47 #periperi: < dammsan> i was also hoping geert to make sure the r8a7795 SCIF DT binding doc went upstream
11:47 #periperi: < dammsan> together with the DMA bits
11:47 #periperi: < geertu> sure, after rc1
11:47 #periperi: < dammsan> sure, no stress
11:47 #periperi: < geertu> GregKH may already take scif-misc-v3, but only after rc1
11:48 #periperi: < dammsan> ok
11:48 #periperi: < horms> so this secreat irq, would be described in dt
11:48 #periperi: < geertu> What special DT binding is there for SCIF2?
11:48 #periperi: < geertu> The driver needs an IRQ
11:48 #periperi: < dammsan> so we don't have any particular devices to focus on now except the CPG and PFC?
11:48 #periperi: < horms> was that circulated publicly before we found out it was secret?
11:48 #periperi: < horms> (we can punt this topic if you like)
11:48 #periperi: < dammsan> geertu: i meant that we may have to special case it
11:49 #periperi: < dammsan> in the DT binding doc
11:49 #periperi: < dammsan> if it is special somehow
11:49 #periperi: < dammsan> (reminds me that i have to resend that CMT series)
11:49 #periperi: < geertu> v0.50 is from end of July, right?
11:49 #periperi: < horms> yes, iirc
11:49 #periperi: < horms> 21st July iirc
11:50 #periperi: < geertu> First public scif2 in r8a7795.dtsi is from Aug 6
11:50 #periperi: < dammsan> isn't it easy just to omit SCIF2?
11:50 #periperi: < geertu> So Morimoto-san should have known ;-)
11:50 #periperi: < dammsan> we can use HSCIF instead?
11:50 #periperi: < geertu> It's the console
11:50 #periperi: < dammsan> sometimes we can use other SCIF block on same pins
11:51 #periperi: < geertu> No, serial-0 only does scif2, I think
11:51 #periperi: < dammsan> wtf
11:51 #periperi: < dammsan> so shall we aim for DEBUG1 then? =)
11:52 #periperi: < dammsan> but seriously, what a mess
11:52 #periperi: < geertu> we can bitbang SDHI2 WP/CD on those lines
11:52 #periperi: < geertu> or GPIO ;-)
11:52 #periperi: < geertu> U-boot uses scif2
11:52 #periperi: < dammsan> hehe, must be better
11:52 #periperi: < dammsan> but u-boot is not interrupt driven =)
11:53 #periperi: < geertu> Obviously the interrupt is working
11:53 #periperi: < horms> if a patch can already be found by google then it ain't no secret anymore
11:53 #periperi: < dammsan> maybe we should just ask for update for the SCIF2 interrupt
11:53 #periperi: < dammsan> update for the deocumentation
11:53 #periperi: < dammsan> shimoda: morimoto: can we request update?
11:53 #periperi: < dammsan> this is silly
11:54 #periperi: < geertu> Are we actually using scif2, or are we using irda?
11:54 #periperi: < geertu> The MSTP clock indicates irda
11:54 #periperi: < geertu> and irda usually is scif-compatible
11:54 #periperi: < dammsan> we have non-SCIF compatible IRDA as well
11:54 #periperi: < shimoda> dammsan: sure, I or Morimoto-san request it
11:55 #periperi: < dammsan> shimoda: thanks please check about SCIF2 interrupt
11:55 #periperi: < dammsan> so it seems that the integration series is blocked on both CPG and SCIF2
11:56 #periperi: < geertu> hurray
11:56 #periperi: < geertu> Hence incrementals for now
11:56 #periperi: < dammsan> at least we have hardware now
11:56 #periperi: < geertu> BTW, who's "Europe engineer"?
11:56 #periperi: < dammsan> geertu: i think i should do one major resend in v9
11:57 #periperi: < dammsan> to fix up the things you requested
11:57 #periperi: < horms> we just meed sw to complete the set
11:57 #periperi: < dammsan> or do you prefer to get individual patches?
11:57 #periperi: < dammsan> i mean incremental ones?
11:58 #periperi: < geertu> v9 is integration, so that's up to Simon ;-)
11:58 #periperi: < dammsan> ok, about CPG you prefer incremental then?
11:58 #periperi: < horms> i prefer a fresh patchset if existing patches need updating
11:58 #periperi: < dammsan> ok, fresh patchset it will be then
11:58 #periperi: < horms> incremental is fine for new stuff
11:59 #periperi: < horms> thanks
11:59 #periperi: < geertu> For CPG, you would only update 2/5 clk: shmobile: Add Renesas R-Car Gen3 CPG support?
11:59 #periperi: < geertu> I don't mind if you just send that one
11:59 #periperi: < dammsan> sure, but i think i also missed your comment about 4/5 or something
11:59 #periperi: < dammsan> so > 1 patch -> resend series
12:00 #periperi: < geertu> yep
12:00 #periperi: < geertu> sounds fine
12:00 #periperi: < geertu> Next topic?
12:00 #periperi: < dammsan> if <=1 patch - resend individual patch
12:01 #periperi: < dammsan> sure
12:01 #periperi: < geertu> Topic 3. DMA topology,
12:02 #periperi: < geertu> we have dummy dma nodes now, so "dmas" can be added (albeit untested)
12:02 -!- Irssi: Pasting 8 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
12:02 #periperi: < geertu> R-Car Gen2 had two DMA controllers, which were equivalent.
12:02 #periperi: < geertu> As we dropped the shdma dma-multiplexer when implementing rcar-dmac,
12:02 #periperi: < geertu> DMA slaves were tied to a single DMA controller in .dtsi only.
12:02 #periperi: < geertu> On R-Car Gen3 the three DMA controllers are not equivalent: some DMA slaves
12:02 #periperi: < geertu> can be tied to channels 0-15 (the first instance) only, others can be tied to
12:02 #periperi: < geertu> channels 16-47 (i.e. the second or third instance) only.
12:02 #periperi: < geertu> For the latter, I used the second instance in .dtsi.
12:03 #periperi: < geertu> Do we have a plan to use the third dmac (on Gen3), or the second dmac (on Gen2)
12:03 #periperi: < geertu> ?
12:03 #periperi: < geertu> Is Laurent here?
12:03 #periperi: < dammsan> i have no special policy setting plan, but i'd like to describe the hardware via DT
12:04 #periperi: < geertu> Which means "dmas" should link to all relevant dmac nodes
12:04 #periperi: < geertu> and not just the first one
12:04 #periperi: < dammsan> yes, isn't that what we said during the montpellier peripericon?
12:04 #periperi: < dammsan> hurray for another unstable DTS bit! =)
12:05 #periperi: < geertu> In Montpellier, we said we'd start with links to one dmac, and see how to resolve the rest later
12:05 #periperi: < dammsan> now seems like a great time then
12:06 #periperi: < dammsan> adding more links to DT without driver support does not hurt, does it?
12:06 #periperi: < geertu> How?
12:06 #periperi: < geertu> Now we have
12:06 #periperi: < geertu> dmas = <&dmac1 0x31>, <&dmac1 0x30>;
12:06 #periperi: < geertu> dma-names = "tx", "rx";
12:07 #periperi: < geertu> We can't easily extend that
12:07 #periperi: < geertu> Would this actually work?
12:07 #periperi: < dammsan> we can not have multiple identical dma-names?
12:07 #periperi: < geertu> dmas = <&dmac1 0x31>, <&dmac1 0x30>, <&dmac2 0x31>, <&dmac2 0x30>;
12:07 #periperi: < geertu> dma-names = "tx", "rx", "tx", "rx";
12:07 #periperi: < geertu> I'm afraid not
12:07 #periperi: < dammsan> that's how i pictured it
12:08 #periperi: < geertu> It's also related to DMA load balancing
12:08 #periperi: < geertu> And the third dmac may be secret on Gen3 ;-)
12:08 #periperi: < dammsan> we could add some "dma-peer" property to the dma controller to point to the peers
12:08 #periperi: < geertu> Yes, that was one of the options we discussed in Montpellier
12:09 #periperi: < geertu> Perhaps the only sane one
12:09 #periperi: < geertu> Let's hope there are no "evil" DMA slaves that can be tied to the first and second dmac on gen3
12:09 #periperi: < geertu> while all others tie to second and third
12:10 #periperi: < geertu> or the the first exclusively
12:10 #periperi: < geertu> Anyway, without Laurent I think we should postpone this?
12:10 #periperi: < dammsan> the identical-dma-name proposal would support anything, right?
12:10 #periperi: < geertu> Yes
12:11 #periperi: < geertu> Probably needs updates the core DMA framework
12:11 #periperi: < dammsan> probably yes
12:12 #periperi: < geertu> Topic 4. CPG and boot mode via syscon (or not),
12:12 #periperi: < geertu> Laurent wanted to have a generic (also for non-shmobile) framework to obtain a boot mode value
12:13 #periperi: < geertu> instead
12:14 #periperi: < dammsan> that could perhaps be in gen4 if we have done that upfront
12:14 #periperi: < geertu> yeah
12:14 #periperi: < dammsan> i thought your syscon idea was great
12:15 #periperi: < geertu> The major disadvantage of the syscon idea is that we don't know yet how else we'll use the RST module
12:15 #periperi: < dammsan> but this may slightly overlap with the ES revision bits
12:15 #periperi: < geertu> w.r.t. CPU core management
12:15 #periperi: < dammsan> right
12:15 #periperi: < geertu> THE es bits in a different register on Gen3?
12:15 #periperi: < dammsan> i'm also concerned about RST of I/O devices
12:16 #periperi: < geertu> That's in the MSTP module?
12:16 #periperi: < dammsan> maybe so
12:16 #periperi: < geertu> i.e. more registers for each MSTP node
12:16 #periperi: < dammsan> but how do we perform actual reset?
12:17 #periperi: < dammsan> it is more of a question about how to perform reset instead of DT hardware description
12:17 #periperi: < dammsan> and i think that is similar to the boot mode discussion
12:17 #periperi: < dammsan> we need to figure out how to let the driver get the information
12:17 #periperi: < dammsan> and separate from that
12:17 #periperi: < dammsan> also need to figure out how to describe the hardware in DT
12:17 #periperi: < geertu> You mean resetting individual I/O devices, not the whole system?
12:17 #periperi: < dammsan> yes
12:18 #periperi: < geertu> What's the use case for that?
12:18 #periperi: < dammsan> similar to power domain, but without power savings
12:18 #periperi: < dammsan> it may be nice to get a clean start before probe() =)
12:19 #periperi: < dammsan> no special use case apart from that
12:19 #periperi: < geertu> So each device would have a power-domains property linking to the (generalized) MSTPx.y, not only for clock, but also for reset handling?
12:19 #periperi: < dammsan> at least for boot mode we have a need =)
12:19 #periperi: < dammsan> reset-domains
12:20 #periperi: < geertu> Actually we can have that in power-domains
12:20 #periperi: < dammsan> there is certainly overlap
12:20 #periperi: < geertu> Actually each MSTP clock has a corresponding module reset bit
12:20 #periperi: < dammsan> maybe the MSTP driver an hook up a notifier if there are reset registers present
12:21 #periperi: < geertu> perhaps
12:21 #periperi: < geertu> Sounds like for Gen-4
12:21 #periperi: < dammsan> and do stuff on BIND and UNBIND or similar
12:21 #periperi: < dammsan> sure
12:21 #periperi: < dammsan> but not _that_ difficult
12:21 #periperi: < dammsan> so about boot mode
12:21 #periperi: < dammsan> what do we do?
12:22 #periperi: < geertu> We can do the syscon way now.
12:22 #periperi: < geertu> Patches are available, need a small update for Gen3
12:22 #periperi: < geertu> It's easy to decide, in the absence of Laurent
12:22 #periperi: < geertu> ;-)
12:22 #periperi: < dammsan> so with the ES version we decided to go with DT compat string suffix
12:22 #periperi: < dammsan> to handle workarounds for special ES versions
12:23 #periperi: < dammsan> we never got around to runtime modify the DT bits based on ES version though
12:23 #periperi: < geertu> We haven't implemented changing the DT compat string based on probed ES version yet
12:23 #periperi: < dammsan> bingo
12:23 #periperi: < dammsan> =)
12:23 #periperi: < geertu> Do we have a need for ES now?
12:24 #periperi: < dammsan> so if we do that, then can we just deal with the boot mode there instead?
12:24 #periperi: < dammsan> but using syscon may be better
12:24 #periperi: < dammsan> no need for ES handling right now, but it may come up
12:25 #periperi: < dammsan> i'm totally fine with syscon, especially if we use SoC specific compat strings
12:25 #periperi: < geertu> "boot mode there" means purely in C, no DT update needed?
12:25 #periperi: < dammsan> yeah, detecting boot mode from C and stashing it in DT while modifying for ES anyway
12:25 #periperi: < geertu> I can update my syscon patch for Gen3, and resend?
12:26 #periperi: < dammsan> sounds good!
12:26 #periperi: < dammsan> so what is the risk for going the syscon route?
12:26 #periperi: < dammsan> apart from ticking off laurent =)
12:26 #periperi: < dammsan> you mentioned CPU reset
12:27 #periperi: < geertu> +	rst: reset-controller@e616000 {
12:27 #periperi: < geertu> +		compatible = "renesas,rst-r8a7790", "syscon";
12:27 #periperi: < geertu> +		reg = <0 0xe6160000 0 0x0100>;
12:27 #periperi: < geertu> +	};
12:27 #periperi: < dammsan> looking good!!
12:27 #periperi: < geertu> Does that pose a risk?
12:27 #periperi: < geertu> for future RST use?
12:28 #periperi: < dammsan> not what i can tell
12:28 #periperi: < geertu> cpg node needs
12:28 #periperi: < geertu> renesas,modemr = <&rst 0x60>;
12:29 #periperi: < geertu> Will cook up an incremental patch
12:29 #periperi: < dammsan> seems good to me
12:29 #periperi: < dammsan> thanks!
12:30 #periperi: < geertu> One minute left for
12:30 #periperi: < geertu> Topic 5. Status check for tasks from last meeting - what is remaining?
12:30 #periperi: < dammsan> thanks for uli___ and horms help with GPIO
12:30 #periperi: < horms> i did little
12:30 #periperi: < geertu> Add full (H)SCIF nodes to DT is partially done (need to re-add HSCIF pfc bits to make it work again)
12:30 #periperi: < horms> but its nice to see it moving forwards
12:30 #periperi: < geertu> Add gpio nodes to DT is done, modulo power-domains
12:31 #periperi: < uli___> should i resend that with clock-output-names restored now? :)
12:31 #periperi: < geertu> pfc Add r8a7795 support is wip
12:31 #periperi: < geertu> uli___: please wait, unless you want to game mailing list statistics
12:31 #periperi: < geertu> No changes for other tasks?
12:32 #periperi: < geertu> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Core-todo-list
12:33 #periperi: < dammsan> not from me
12:34 #periperi: < shimoda> no update from me
12:36 #periperi: < geertu> OK, thanks for joining!
12:36 #periperi: < morimoto> geertu: my "Europe engineer" was 1st attack : for Laurent, Geert. 2nd attack Ulirch Wolfram
12:36 #periperi: < morimoto> We can send one board to Simon, but there is no paper work for him :)
12:37 #periperi: < dammsan> geertu: about CPG, i wonder what the next step really is
12:37 #periperi: < geertu> No paperwork means no fun, less earned value ;-)
12:37 #periperi: < geertu> dammsan: submit to clock maintainers?
12:38 #periperi: < morimoto> No paperwork No life :P
12:38 #periperi: < geertu> morimoto So Simon can just take a board on a plane?
12:38 #periperi: < dammsan> geertu: about the clks array handling, i think a static array is just fine
12:38 #periperi: < dammsan> in my mind apart from removing a spinlock
12:39 #periperi: < dammsan> it is just about figuring out how to deal with(out) clock-output-names
12:39 #periperi: < geertu> yeah, initially I though it was an array of "struct clk", not pointers
12:39 #periperi: < geertu> s/though/thought/
12:39 #periperi: < geertu> Wasting a few pointers isn't that important.
12:39 #periperi: < dammsan> we will expand NR if needed on new SoCs ight?
12:39 #periperi: < geertu> I also thought about dropping clock-indices, like Laurent suggested.
12:39 #periperi: < dammsan> and may use a subset of the indices
12:40 #periperi: < geertu> But the reason for them is future expansion, right?
12:40 #periperi: < dammsan> i like having them there
12:40 #periperi: < dammsan> yes
12:40 #periperi: < geertu> Time for lunch here...
12:40 #periperi: < geertu> Bye!
12:40 #periperi: < dammsan> and i also like being able to search in DT files to figure out how things are connected
12:40 #periperi: < dammsan> ok bye bye
12:41 #periperi: < morimoto> geertu: Simon can get board from delivery car
12:41 #periperi: < shimoda> bye!
12:41 #periperi: < morimoto> bye
12:41 -!- morimoto [~user@relprex2.renesas.com] has left #periperi ["ERC Version 5.3 (IRC client for Emacs)"]
12:41 #periperi: < uli___> bye
12:54 #periperi: < horms> sorry to miss the last few minutes of the meeting: i had a minor baby crisis to attend to
13:46 -!- horms [~horms@121-80-213-238f1.hyg1.eonet.ne.jp] has quit [Quit: Leaving]
13:58 #periperi: < pinchartl> geertu: what bothers me with syscon for boot mode handling is that the register isn't part of the syscon IP core
13:59 #periperi:  * pinchartl is back in Finland now
14:17 #periperi: < geertu> Welcome back (sort of)!
14:22 #periperi: < pinchartl> sorry for missing today's meeting
14:36 #periperi: < geertu> pinchartl: It is according to Figure 11.1   Block Diagram of RST (Gen3)
14:36 #periperi: < geertu> And 11.1.1 11.1.1 Features
14:36 #periperi: < geertu> The following functions are implemented by RST.
14:36 #periperi: < geertu> Latching of the levels on mode pins when PRESET# is negated
14:36 #periperi: < geertu> Mode monitoring register
14:40 #periperi:  * geertu mutex_lock(salvator-x)
14:42 -!- shimoda [~shimoda@relprex3.renesas.com] has quit [Quit: WeeChat 0.4.2]
14:49 #periperi: < pinchartl> geertu: is RST a "syscon" ?
14:49 #periperi: < pinchartl> we have a SYSC IP core
14:49 #periperi: < pinchartl> that one is documented as system controller :-)
14:50 #periperi: < pinchartl> although it looks like a power controller
14:51 #periperi: < pinchartl> syscon is really a mean to stuff all kind of miscellaneous stuff in a catch-all API when standardizing an API would be difficult due to very system-specific features
14:51 #periperi: < geertu> Documentation/devicetree/bindings/mfd/syscon.txt
14:51 -!- Irssi: Pasting 8 lines to #periperi. Press Ctrl-K if you wish to do this or Ctrl-C to cancel.
14:51 #periperi: < geertu> System controller node represents a register region containing a set
14:51 #periperi: < geertu> of miscellaneous registers. The registers are not cohesive enough to
14:51 #periperi: < geertu> represent as any specific type of device. The typical use-case is for
14:51 #periperi: < geertu> some other node's driver, or platform-specific code, to acquire a
14:51 #periperi: < geertu> reference to the syscon node (e.g. by phandle, node path, or search
14:51 #periperi: < geertu> using a specific compatible value), interrogate the node (or associated
14:51 #periperi: < geertu> OS driver) to determine the location of the registers, and access the
14:51 #periperi: < geertu> registers directly.
14:51 #periperi: < pinchartl> the boot mode pins, on the other hand, seems like a quite well-defined function to me
14:51 #periperi: < pinchartl> yes, exactly
14:51 #periperi: < geertu> The watchdog will need alink to one of the RST registers, too
14:52 #periperi: < pinchartl> syscon is really a hack to access registers in unrelated IP cores when creating an API isn't worth it