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
|
Core-chat-meeting-2017-03-14
09:20 < geertu> Welcome to today's Renesas Core Group Chat (\pi-day Edition)
09:20 < geertu> Agenda:
09:20 < geertu> 1. Status updates
09:20 < geertu> 2. Additional tasks for 2017/Q2 phase 1
09:20 < geertu> Topic 1. Status updates
09:20 < geertu> A) What have I done since last time
09:20 < geertu> B) What I plan to do till next time
09:20 < geertu> C) Problems I have currently
09:20 < geertu> D) Posted/Accepted bugfix patches
09:21 < geertu> Shimoda-san is first
09:21 < shimoda> yes
09:21 < shimoda> A)
09:21 < shimoda> - In last month, I reported about SYS-DMAC descriptor mode on-chip RAM support.
09:21 < shimoda> But, I should have reported it in detail.
09:21 < shimoda> - The HW restriction is we cannot use "Built-in memory is used" mode (= DMADPBASE_n.SEL = 0)
09:21 < shimoda> - We can use its own descriptor memory via DMADPBASE_n.SEL = 1 with DPBASE[31:4].
09:21 < shimoda> - I tried new IPMMU patch set. And, it could boot correctly. (Magnus-san, Thank you!)
09:21 < shimoda> - The patch sets seem update later, I will make a workaround patch for SDHI after new patch sets are submitted.
09:21 < shimoda> B)
09:21 < shimoda> - After new patch sets of IPMMU are available, I will make a workaround patch.
09:21 < shimoda> C)
09:21 < shimoda> - Nothing for core.
09:21 < shimoda> D)
09:21 < shimoda> - Nothing for core.
09:21 < shimoda> -- EOT --
09:22 < geertu> shimoda: What does "its own descriptor memory" mean? How does it differ from "Built-in memory"?
09:22 < shimoda> geertu: oops, it mean the same as its own descriptor memory and Built-in memory
09:24 < shimoda> if we would like to use SYS-DMAC0's built-in memory,
09:24 < geertu> shimoda: The documentation for DMADPBASE_n.SEL says "0: Setting Prohibited"
09:25 < geertu> Ah, only for Gen3. For Gen2 the bit chooses betwen Built-in and external memory
09:25 < shimoda> geertu: ahh, that's correct, I looked old doc (rev.0.50) X(
09:26 < geertu> s/betwen/between/
09:26 < shimoda> rev.0.53 is avoiding the restriction :)
09:27 < shimoda> geertu: For gen2, I heard it has the same issue
09:27 < shimoda> with gen3
09:27 < shimoda> Maybe for gen2, hardware team will issue errata info??
09:28 < shimoda> i will confirm it (for gen2's tu)
09:28 < geertu> OK, thx
09:28 < shimoda> s/tu/errata info/
09:29 < geertu> Thank you, Shimoda-san
09:29 < geertu> Next is Niklas
09:29 < neg> A) Nothing for Core
09:29 < neg> B) Pickup core task(s) as part of base, suggestions on whats needed is welcome. What I can think of at the top of my head
09:29 < neg> - Pickup work on Magnus 'dmaengine: rcar-dmac: Priority and slow mode prototypes' series, Magnus once told me he might want me to do that not sure about how he feels today.
09:29 < neg> - Implement synchronize() for rcar-dmac for https://patchwork.kernel.org/patch/9557691/
09:29 < neg> C) None
09:29 < neg> D) None
09:29 < neg> EOT
09:30 < dammsan> neg: i think we should wait for feedback from Laurent
09:30 < neg> sounds like a good idea
09:30 < geertu> Laurent is away for the next 10 days
09:31 < geertu> synchronize() is definitely a good thing to do
09:31 < geertu> Thanks Niklas
09:31 < geertu> Next is Morimoto-san
09:32 < morimoto> OK
09:32 < morimoto> A) What have I done since last time:
09:32 < morimoto> - posted SYS-DMAC 40bit + Descriptor mode patch (no response)
09:32 < morimoto> - posted video logo init syscall exchange patch (no response)
09:32 < morimoto> B) What I plan to do till next time:
09:32 < morimoto> - follow above 2 patches
09:32 < morimoto> C) Problems I have currently:
09:32 < morimoto> - No problems
09:32 < morimoto> D) Posted/Accepted bugfix patches:
09:32 < morimoto> - No patches
09:32 < morimoto> X) Question from me
09:32 < morimoto> - could you receive new 0.51/0.52/0.53 datasheet ?
09:32 < morimoto> - 0.52 seems have both ES1.x and ES2.0
09:32 < morimoto>
09:32 < morimoto> --EOF--
09:33 < geertu> morimoto: I've downloaded the files, but haven't verified them, or looked at the contents
09:33 < geertu> morimoto: Thanks a lot!
09:33 < dammsan> morimoto: i will redistribute later today
09:33 < morimoto> OK, nice to know !
09:34 < morimoto> Basically 0.52 is for ES2.0, but it has ES1.x folder
09:34 < morimoto> I don't know why
09:36 < geertu> morimoto: Perhaps 0.51 is for H3 ES1.0? And 0.52 is for H3 ES1.x?
09:36 * geertu sha256sum OK
09:36 < morimoto> My understanding is that 0.51 is for ES1.x, 0.52 and later is for ES2.0
09:36 < morimoto> shimoda: my understanding is correct ?
09:37 < shimoda> morimoto: yes.
09:38 < geertu> So 0.52 is not useful, as it's superceded for H3 ES2.0 and M3-W ES1.1 by 0.53?
09:39 < geertu> And which one is for H3 ES1.0? rev. 0.20? ;-)
09:40 < morimoto> Actually, 0.52 was updated in these days, and we don't know what happen on it :(
09:41 < morimoto> 1st version to 0.51 was for ES1.x
09:41 < morimoto> If my understanding was correct
09:42 < morimoto> geertu: you question is which is for ES1.0, and which is ES1.x ?
09:42 < morimoto> But in our understanding, datasheet has no difference for ES1.x
09:42 < geertu> morimoto: yes. OK.
09:43 < shimoda> according to the manual team's redmine, rev.0.50 is H3 ES1.1. 0.51 is M3. 0.52 is V3M. 0.53 is V3H. and 0.54 (will be released on end of Apr) is M3N, D3 and E3
09:44 < geertu> OK, thx
09:45 < geertu> Thank you, Morimoto-san
09:45 < geertu> Next is Magnus
09:49 < dammsan> ok, i've been working on IPMMU and DMAC, nothing else to report =)
09:49 < geertu> Thanks, Magnus
09:49 < geertu> Next is Jacopo
09:50 < jmondi> here I am, so..
09:50 < jmondi> A) Nothing: no core work since last time we met
09:50 < jmondi> B) I have now received a considerable amount of reviews on RZ/A1 pin controller, I will send v2 possibily this week
09:51 < jmondi> C) not really a task, but I still have to work on Peach, and I'm waiting for digikey to deliver me some stuff
09:51 < jmondi> D) none
09:51 < jmondi> --- eot ---
09:51 < geertu> Thank you, Jacopo
09:52 < geertu> Next is Geert
09:52 < geertu> A) What have I done since last time
09:52 < geertu> - v2 of R-Car H3 ES2.0 support (clk/pfc/sysc)
09:52 < geertu> - v2 of INTC-SYS clock addition
09:52 < geertu> - v2 of R-Car M3-W secondary CPU
09:52 < geertu> - v5 of DMA_ATTR_FORCE_CONTIGUOUS
09:52 < geertu> - DT binding update to add resets to rcar-du
09:52 < geertu> - DT binding and identification of RZ/G1H and RZ/G1N
09:52 < geertu> - Posted "long story" summary for Suspend-to-Idle to periperi
09:52 < geertu> - DT cleanups
09:52 < geertu> B) What I plan to do till next time
09:52 < geertu> - v2 of resets for R-Car H3 and M3-W DTS
09:52 < geertu> C) Problems I have currently
09:52 < geertu> - None
09:52 < geertu> D) Posted/Accepted bugfix patches
09:52 < geertu> - Nothing important
09:52 < geertu> EOT
09:53 < geertu> laurent and Marek are excused, Ulrich and Simon are absent, so no updates from them
09:53 < geertu> Topic 2. Additional tasks for 2017/Q2 phase 1
09:54 < geertu> What's important? What do we want to do next?
09:54 < geertu> Who's interested in doing some core work?
09:55 < neg> I'm interested in core work :-)
09:55 < geertu> So far I haven't received new requests from other groups (I/O, MultiMedia)
09:55 < jmondi> I will defintely need some core work after April, yes
09:55 < dammsan> geertu: i think we should continue to improve the SYS-DMAC driver with priority support and such
09:55 < dammsan> it may require more deeper investigation to make sure RX is prioritized over TX
09:56 < dammsan> and then there is PM for a whole bunch of drivers
09:56 < geertu> neg: Want to do "RCAR-DMAC,?,noplan,?,Add transfer termination synchronization"
09:56 < geertu> ?
09:56 -!- horms [~horms@penelope.horms.nl] has joined #periperi
09:56 < geertu> Hi SImon
09:57 < geertu> I guess I confused you with my silly CEST email?
09:57 < horms> Sorry, I got the updated time. But I had shuffled another appointment into the 9am slot (to free up 10am)
09:57 < neg> geertu: I need to lookin to exactly what that is, but sure I be more than happy to look into it
09:58 < horms> I should also have realised we are not in CEST for another 12 days :)
09:58 < dammsan> geertu: the versaclock driver that marek wrote may need an update
09:58 < horms> and i see my email is stuck on my laptop
09:58 < geertu> dammsan: Ah, what's missing?
09:58 < dammsan> geertu: apparently the versaclock part number is changing when salvator-xs board will be introduced
09:59 < geertu> dammsan: Do you know the new part number?
09:59 < dammsan> geertu: no, but I think Morimoto-san and/or Shimoda-san knows
10:00 < dammsan> never mind i found it in an old weekly report
10:01 < dammsan> apparently current board is using 5P49V5923A
10:01 < dammsan> new board will be using 5P49V6901A
10:02 < dammsan> so we want to make sure the driver supports that chip
10:03 < geertu> Ah, that's a VersaClock 6
10:03 < dammsan> oh...
10:03 < dammsan> good that we start early then
10:03 < geertu> To be seen how much different that is
10:04 < dammsan> for sure
10:04 < dammsan> then there is PMIC with all that means
10:04 < geertu> Could be just a two line change, or a completely new and different driver
10:04 < dammsan> indeed
10:05 < dammsan> do we have upstream driver support for PMIC on Gen2 boards?
10:06 < dammsan> if not then we can perhaps do that in parallel with PMIC on Gen3
10:07 < shimoda> about PMIC on Gen2 board, I think it already finished
10:08 < shimoda> commit ids = 46dd8a809effdc7ebe6ec760e3e421d5ac2a40f1 and a6b422664597d7b9ca6cf441bc48cfe1a707cd3a
10:08 < geertu> There are upstream drivers for da9063 and da9210, but we only have regulator properties in DT for da9210
10:09 < geertu> Those commits are the da9063 nodes, used for system restart only
10:10 < geertu> commit 1d41f36a68c0f4e9b01d563ce33bab5201858b54 is for da9210 with dvfs
10:10 < dammsan> i highly doubt that all gen2 boards have the same status
10:11 < dammsan> including gose/alt/blanche
10:11 < geertu> Only Lager and Koelsch have the da9210 in DT
10:12 < dammsan> seems we have some stuff to do then =)
10:12 < shimoda> how about DTS sharing?
10:12 < dammsan> also perhaps internal watchdog workaround is needed
10:13 < dammsan> shimoda: good idea
10:13 < geertu> Like "generic,?,noplan,?,DTS sharing on H3 ES1.x/ES2.0, Salvator-X/ULCB
10:13 < geertu> "?
10:13 < shimoda> geertu: i meant yes
10:14 < geertu> "internal watchdog workaround"?
10:14 < dammsan> geertu: eventually i think we should consider virtualisation and perhaps extend virtio with dmaengine support
10:15 * geertu added "generic,?,noplan,?,VersaClock 5P49V6901A clock generator driver"
10:15 * geertu added "Gen2,?,noplan,?,Uniform PMIC support on all boards"
10:15 < dammsan> geertu: yeah about internal watchdog, i've heard some gen2 use case for soc without external pmic reset exists
10:16 < dammsan> so it may be time to start untangling the mess also known as gen2 reset handling
10:16 < geertu> DTS sharing means we'll become less conservative: when adding new features to one board/SoC combo, it'll appear on other combos, too
10:16 < shimoda> about gen2 watchdog to reset, just bsp team has a trouble :)
10:16 < geertu> dammsan: I can imagine the use case exists ;-)
10:17 < dammsan> shimoda: but last time i checked watchdog reset on gen2 is filled with errata issues
10:17 < shimoda> gen2 has CA15BAR and it doesn't reset by WDT X(
10:17 < dammsan> right there you go
10:18 < shimoda> dammsan: i don't know about the errata. I will ask BSP team
10:18 < dammsan> another topic for virtualization can be getting KVM going with a paravirtualized guest
10:18 < shimoda> later
10:18 < dammsan> shimoda: thanks
10:20 < dammsan> geertu: if anyone want to hack PSCI code then fixing the high power consumption in the firmware would be great
10:21 < dammsan> geertu: for the power off case that you kindly pointed out
10:22 < geertu> 5P49V6901A looks very similar to 5P49V5923A
10:24 < geertu> dammsan: According to the latest list of areas covered by the Core group, PSCI is not on the list ;-)
10:24 < dammsan> geertu: ok lets wait and see what marek says
10:24 < geertu> Anyway, someone may like to play with it ...
10:24 < dammsan> geertu: the psci stuff needs to be coordinated with internal renesas team to avoid duplication
10:25 * geertu added PSCI,?,noplan,?,Reduce power consumption in suspend/poweroff states
10:25 < geertu> Surew
10:25 < geertu> s/Surew/Sure/
10:25 < dammsan> thanks
10:26 < geertu> horms: So we skipped your status update, but you did send it to the list. Want to duplicate it here?
10:27 < horms> Sure
10:27 < horms> Task update: none
10:27 < horms> A) No activity (no core tasks)
10:27 < horms> B) None
10:27 < horms> B) No problems
10:27 < horms> D) No fixes posted/queued up
10:27 < horms> Fwiw, I have been working on LTSI-4.9 backports (an add-on task for this quarter I asked to be canceled due to illness)
10:28 < horms> I also plan to address the integration tasks which were similarly cancelled
10:28 < horms> but perhaps not until next month
10:29 < geertu> Thanks Simon
10:31 < geertu> http://www.digikey.be/product-detail/en/idt-integrated-device-technology-inc/EVKVC6-6901ALL/800-3138-ND/5419197
10:31 < geertu> bit more expensive (175€) than the VC5 counterpart
10:31 < geertu> I guess we can sort out the (wild list of) additional tasks on periperi ML?
10:32 < geertu> Is there anything else you want to discuss, tell, ask?
10:32 < horms> I'd day the hexagonal form factor is worth the extra money
10:32 < dammsan> nothing from me!
10:33 < geertu> It's a rare item: out-of-stock, lead time 18 weeks...
10:33 < horms> octagonal even!
10:34 < geertu> What's the lead time of Salvator-XS?
10:34 < shimoda> maybe mid May...
10:34 < geertu> That's less than 18 weeks
10:35 < geertu> Let's finish.
10:35 < geertu> Oh, one thing.
10:35 < geertu> Shall we reduce core group chat frequency to 1/month, like for I/O?
10:36 < geertu> Or keep 1/fortnight?
10:36 < neg> I like the 1/fortnight
10:37 < neg> but if it creates much overhead for you I'm open to change it :-)
10:37 < geertu> I don't mind. It just depends on the amount of work that's done/todo
10:38 < geertu> Let's keep next meeting at March 28, OK?
10:38 < neg> Yes
10:38 < geertu> Thanks for joining, and have a nice continued day!
10:38 < shimoda> yes. i booked it
10:39 < neg> thanks all
10:39 < morimoto> I have MultiMedia cat meeting on March 28
10:39 < morimoto> I'm soory
10:39 < morimoto> s/soory/sorry
10:39 < geertu> Really?
10:40 < geertu> Ah, Laurent will have the meeting in Winter Time
10:40 < neg> Ahh me too, I thought we would do the two meetings one day thing :-)
10:40 < dammsan> right, collides with m/m
10:40 < geertu> So we can have it in Summer Time, i.e. one hour later ;-)
10:41 < geertu> Unfortunately the Tokyo side will have two parallel meetings, as they don't do Daylight Savings Time ;-)
10:41 < dammsan> geertu: at that time, shall we aim at having titles for the additional tasks fixed?
10:41 < geertu> dammsan: Yes
10:41 < dammsan> good thanks
10:41 < geertu> Would Wed March 29 fit?
10:42 < jmondi> works for me...
10:42 < neg> also works for me
10:42 < dammsan> me too
10:42 < shimoda> works for me
10:43 < geertu> So for people in a DST zone, it will be one hour later. JST time slot doesn't change.
10:43 < morimoto> works for me
10:43 < geertu> OK, thanks!
10:44 < geertu> Have a nice continued day!
10:44 < morimoto> Thanks all
10:44 < shimoda> Thanks! bye!
10:44 < jmondi> thank you.. will talk soon on periperi list then... bye
10:45 < dammsan> thanks!!
|