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
|
Core-chat-meeting-2017-10-05
09:48 < geertu> Welcome to today's core group meeting.
09:48 < kbingham> and various people leave the room :D
09:48 * pinchartl has to go for one hour
09:48 * kbingham hides
09:48 < geertu> Given the small amount of time left, OK if I just summarize the copy-and-paste received status reports?
09:49 < geertu> A) What have I done since last time:
09:49 < geertu>
09:49 < geertu> Geert:
09:49 < geertu> - Sent patch to fix new unwind warnings with CONFIG_DEBUG_LOCK_ALLOC=y,
09:49 < geertu> - Sent v1 of sh-pfc suspend/resume,
09:49 < geertu> - Sent first pull requests for clk and pfc for v4.15,
09:49 < geertu> Jacopo:
09:49 < geertu> - Some small patches for Gr-Peach
09:49 < geertu> Marek (U-Boot):
09:49 < geertu> - Got more patches applied to u-boot-sh/rmobile, PR pending
09:49 < geertu> http://git.denx.de/?p=u-boot/u-boot-sh.git;a=shortlog;h=refs/heads/rmobile
09:49 < geertu> - Worked on the SDIF SDR104/HS200 support based on out-of-tree
09:49 < geertu> patchset (for now):
09:49 < geertu> - added support for the SDR104/HS200 calibration to the uniphier-sd
09:49 < geertu> driver
09:49 < geertu> - added support for pin voltage switching to PFC driver (POCCTRL)
09:49 < geertu> - added proper regulator handling to uniphier-sd
09:49 < geertu> - Worked on HS400, but that's still not ready
09:49 < geertu> Morimoto:
09:49 < geertu> - V3M/D3 shipping paper work
09:49 < geertu> Shimoda:
09:49 < geertu> - Submitted the following patches:
09:49 < geertu> * Add PWM entries of PFC for r8a77995.
09:49 < geertu> * Add USB3.0 entries of PFC for r8a7795{-es1} and merged.
09:49 < geertu> * Fix avb_pins for salvator-common, ulcb and draak.
09:49 < geertu> Remarks: "*" means merged into the subsystem repo.
09:49 < geertu> - I obtained a R-Car M3-N SiP, but I don't got bootloader yet.
09:49 < geertu> Simon:
09:49 < geertu> - Continued addressing review of CPUFreq patches
09:50 < geertu> B) What I plan to do till next time
09:50 < geertu> Geert:
09:50 < geertu> - v3 of cpg-mssr suspend/resume,
09:50 < geertu> - Fix genpd for wake-up devices.
09:50 < geertu> Marek (U-Boot):
09:50 < geertu> - Finish HS400 support
09:50 < geertu> - Finish sorting up remaining PCIe patches from the BSP (mostly
09:50 < geertu> suspend/resume support)
09:50 < geertu> Morimoto:
09:50 < geertu> - continue V3M/D3 paper work
09:50 < geertu> Niklas:
09:50 < geertu> - Send v2 of 'rcar_gen3_thermal: fix initialization sequence for H3 ES2.0'
09:50 < geertu> Shimoda:
09:50 < geertu> - Add usb3.0 phy device node for r8a779[56].dtsi after the usb3 peri
09:50 < geertu> supported a generic phy.
09:50 < geertu> - Prepare M3-N Salvator-X board for remote access if I obtain the
09:50 < geertu> bootloader.
09:50 < geertu> Simon:
09:50 < geertu> - Finalise addressing review of CPUFreq patches and repost
09:50 < geertu> C) Problems I have currently
09:50 < geertu> [Here I'll add breaks, in case people want to discuss]
09:51 < geertu> Jacopo:
09:51 < geertu> - Not really an issue to discuss with the whole group, but I keep seeing
09:51 < geertu> the GR-Peach hanging on sleeps longer than 1ms. I suspect this is also
09:51 < geertu> why ETHER is not working, and I had to substitute all sleep functions in
09:51 < geertu> the image sensor driver I am currently using to develop CEU with for
09:51 < geertu> loops of udelay(10). I blame XIP for this, but I'm currently not sure.
09:51 < geertu> Suggestions on how to debug and prove this are welcome :)
09:51 < geertu> jacopo: ?
09:51 < dammsan> use migo-r =)
09:51 < geertu> Does it work on Genmai?
09:51 < dammsan> (i don't dislike gr-peach support though)
09:52 < jmondi> geertu: here I am
09:52 < jmondi> never seen anything like this on genmai
09:52 < jmondi> but seems like sleeps longer than 1ms hang the board
09:53 < dammsan> which timer do you use?
09:53 < geertu> Peach doesn't have rtc_x1_clk in the DTS?
09:53 < jmondi> dammsan: as system clock?
09:53 < jmondi> geertu: no, no RTC
09:54 < geertu> The dmesg should tell you (compare genmai and peach)
09:54 < jmondi> not just in dts, not RTC at all on the board
09:54 < dammsan> rtc != clockevent != clocksource
09:55 < wsa_> marex-cloud: the PCIE patches you mentioned, are these for U-Boot or Linux?
09:55 < jmondi> let me look through dmesg
09:55 < dammsan> a single clockevent used to be enough to run the kernel
09:55 < Marex> wsa_: Linux, mostly suspend support
09:55 < dammsan> but the twd on CA9 used to exist only in case of multi-core
09:55 < dammsan> so instead of local timer i'm not sure what is used
09:56 < geertu> rskrza1 and genmai enable mtu2, peach doesn't
09:56 < dammsan> there you go
09:56 < wsa_> Marex: nice! did you send out patches already? I don't see any on the renesas-soc list.
09:56 < Marex> wsa_: I have them rebased to -next since a few days ago, I need to understand what some of them are doing
09:56 < geertu> rskrza1 enables ostm[01], peach and genmai don't
09:56 < wsa_> Marex: I can imagine :)
09:57 < geertu> Ok, issue assumed fixed until proven otherwise soon :-)
09:57 < Marex> wsa_: there's one which digs in the PCIe core , but not much details in the commit message
09:57 < geertu> Marek:
09:57 < geertu> - HS400 calibration doesn't pass on Salvator-XS for me in U-Boot,
09:57 < geertu> but that's because I'm doing something wrong, it works in Linux
09:57 < jmondi> geertu: dammsan: I lost you two
09:57 < jmondi> I'm so ignorant on this
09:57 < geertu> Marex: if you want to discuss this, I think I/O is more appropriate
09:58 < dammsan> jmondi: your timer configuration on gr-peach is incomplete
09:58 < geertu> jmondi: seacrh for mtu and ostm in the varipus r7s72100 DTS
09:58 < Marex> geertu: ACK, I have feedback from wsa_ , need to check it on real board
09:58 < geertu> Marex: OK
09:58 < geertu> Shimoda:
09:58 < geertu> - I got a request from BSP team about upstreaming of MFIS hwspinlock
09:58 < geertu> feature.
09:58 < geertu> - But, the current implementation is not good for upstreaming, I think.
09:58 < geertu> I have 3 concerns:
09:58 < geertu> 1) The device nodes ("mfis" and "mfis-lock") are duplicated like
09:58 < geertu> below...
09:58 < geertu> https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git/tree/arch/arm64/boot/dts/renesas/r8a7795.dtsi?h=v4.9/rcar-3.5.8#n875
09:58 < geertu> 2) The BSP team would like to support "MFIS lock register 8" in
09:58 < geertu> the future, but the register area is separated from "MFIS lock
09:58 < geertu> register [0-7]".
09:58 < geertu> 3) The "mfis" driver for rpmsg (Remote Processor Messaging) will
09:58 < geertu> be not upstreaming for now.
09:58 < geertu> - This module has two (or more) features and BSP supports the following
09:58 < geertu> features:
09:58 < geertu> 1) hwspinlock
09:58 < geertu> 2) rpmsg (Remote Processor Messaging)
09:58 < geertu> - My concern point is how to make the device node for it.
09:58 < geertu> - In my opinion, it should be a mfd driver like below:
09:58 < geertu> mfis {
09:58 < geertu> reg = <0 0xe6260000 0 0x1000>;
09:58 < geertu> hwspinlock {
09:58 < geertu> ...
09:58 < geertu> };
09:58 < geertu> rpmsg {
09:58 < geertu> ...
09:58 < geertu> };
09:58 < geertu> };
09:58 < geertu> - But, what do you think?
09:58 < geertu> shimoda: I had a quick look at the DTS patch
09:59 < geertu> mfis-lock covers lock registers 0-7
09:59 < geertu> The mfis node covers all registers in the first 0x200 byts, but the only registers there are the same lock registers?
09:59 < jmondi> dammsan: geert: will do.. in the meantime fyi: https://paste.debian.net/989118/
10:00 < wsa_> Marex: and don't hesitate to forward questions to the BSP team via Shimoda-san or Morimoto-san
10:00 < shimoda> geertu: the mfis node is for rpmsg
10:00 < geertu> shimoda: Using the same lock registers? Or are there undocumented registers in that block?
10:01 < geertu> You can have multiple register blocks in a single reg property, cfr. the gic nodes
10:01 < Marex> wsa_: will do if anything pops up
10:01 < shimoda> the out of tree driver of mfis driver for rpmsg will not use the same lock registers. Yes, there is undocumented registers for now
10:01 < geertu> You can just have a single one, too (cfr. your "reg = <0 0xe6260000 0 0x1000>")
10:02 < Marex> wsa_: the HS400 was just a quick test bolted on top of HS200
10:02 < geertu> A single driver can be both a hwspinlock and and rpcmsg provider, without using MFD, I think.
10:03 < geertu> Cfr. the CPG/MSSR driver, which is clk provider (for the clocks), genpd provider (for the clock domain), and reset controller (for module resets)
10:05 < shimoda> geertu: but, they make two drivers (hwspinlock and rpmsg) and two device nodes now
10:05 < geertu> shimoda: Two overlapping device nodes is a definite no-go
10:06 < shimoda> geertu: yes, I know. but bsp team doesn't know...
10:06 < geertu> shimoda: So you should tell them, so they know ;-)
10:07 < shimoda> geertu: yes, I should do so :)
10:07 < geertu> jmondi: timer_probe: no matching timers found
10:07 < geertu> jmondi: while my last boot on genmai of v4.9 said:
10:07 < geertu> sh_mtu2 fcff0000.timer: ch0: used for clock events
10:07 < geertu> sh_mtu2 fcff0000.timer: ch0: used for periodic clock events
10:08 < jmondi> geertu: yes... If I got this right, without MTU2 all clock events used for wake ups are not generated
10:08 < jmondi> so the only working methof for sleeping is busy waiting, as udelay does
10:09 < shimoda> about this mfis topic, bsp team don't want to make a single driver to support a hwspinlock and rpmsg, especially rpmsg. But, I'll forward this infor and discuss how do we do. Thanks!
10:09 < geertu> shimoda: Do you need any special properties in the hwspinlock and rpmsg nodes from your proposal?
10:09 < jmondi> I'm now testing it, just need to remove my workarounds in sensor driver code
10:10 < dammsan> shimoda: isn't hwspinlock vs rpmsg assignment software policy?
10:11 < shimoda> geertu: I don't need any special properties, I think. But, BSP team concern, M3-W and H3 ES1.x has only 8 locks, but other SoCs has 64 locks
10:11 < shimoda> s/BSP team concern/BSP team has concern/
10:11 < geertu> That can be handled by the driver based on the renesas,mfis-<soctype> compatible value, right?
10:12 < geertu> (no, "renesas,<soctype>-mfis")
10:12 < shimoda> dammsan: I think so, BSP team wants hwspinlock to go to upstream, but rpmsg is no-go because this is related to undocumented
10:13 < jmondi> geertu: damsan: no more hangs... trying yout ETHER now... thank you both so far :)
10:13 < dammsan> i see. i think mfis has existed even on mobile platforms
10:13 < geertu> dammsan: Indeed, on all SoCs we still support, I think.
10:13 < dammsan> register layout in such case seemed similar to msiof but it was used for mailbox communication between cou coes
10:14 < dammsan> i mean cpu cores
10:14 < shimoda> geertu: i think so. but also need soc_device_match for H3 ES2.0
10:14 < dammsan> but anyway, good with hwspinlock
10:14 < geertu> We're running out of time. Anything else related to this topic?
10:14 < geertu> Simon:
10:14 < geertu> - Correct handling of PLL dividor for CPUFreq
10:15 < geertu> horms: Do you want to discuss this here?
10:15 < horms> I think I should do some more investigation. Perhaps we can chat about it on this channel some time?
10:16 < geertu> OK.
10:16 < dammsan> FYI, i'm adding a silk board for remote access now
10:16 < geertu> Anything I missed in the status reports?
10:16 * Marex steals a bit of time, OK?
10:17 < horms> dammsan: great, can you give me access if its not already oversubscribed?
10:17 < dammsan> sure
10:17 < dammsan> i'll announce the reshuffled boards via email, lets take it from there
10:17 < geertu> Marex: Core related? I should hand over the mic to Wolfram...
10:17 < Marex> shimoda: I sent out the xhci patch I plan to submit to the U-Boot list to the periperi list first, the license grant should be OK, can you double-check please ?
10:18 < Marex> geertu: well it's inbetween, U-Boot is core and xhci is IO
10:18 < shimoda> Marex: sure, I will check it
10:18 < Marex> shimoda: thank you !
10:18 < Marex> shimoda: it'd be convenient if this worked out, since now I can just type "usb reset" and it works :)
10:19 < Marex> shimoda: it's hassle-free
10:19 < shimoda> Marex: nice! :)
10:20 < wsa_> geertu: don't worry, I am fine
10:20 < Marex> shimoda: btw re HS200/400 and SDR104, I am a bit blocked by the SD/MMC maintainer in U-Boot, sorry about that
10:20 < Marex> shimoda: he's not picking patches as fast as I'd like him to
10:20 < Marex> shimoda: I'm looking for ways to ... uh ... expedite that process
10:21 < shimoda> Marex: i got it. thanks!
10:21 < Marex> shimoda: you're welcome, I'll keep you updated
10:22 < wsa_> Marex: is yamada-san working on this, too?
10:22 < Marex> wsa_: Masahiro Yamada-san ?
10:22 < wsa_> hai
10:22 < Marex> wsa_: he works for socionext, although he did implement the uniphier-sd which I now use on RCar Gen3
10:22 * neg brb 2 min
10:22 < Marex> wsa_: their block doesn't support the HS200/400/SDR104 modes though, that's renesas specific
10:23 < Marex> wsa_: so he just reviews my uniphier-sd patches (which is nice) and makes sure they work on both
10:23 < wsa_> I see
10:24 < Marex> wsa_: the blocker really is the SD/MMC subsystem maintainer, he just doesn't respond much
10:24 < Marex> wsa_: some not long time ago I was really tempted to just replace him and start handling the SDMMC stuff myself
10:25 < Marex> wsa_: but then he came back, at like 5 mins to 12 and rolled out a PR ...
10:25 < wsa_> how about co-maintaining?
10:25 < Marex> wsa_: I feel like I'm hoarding functions ;-)
10:26 < wsa_> I see
10:26 < wsa_> that happens easily, yes
10:26 < Marex> wsa_: right
10:26 * neg back
10:26 < Marex> wsa_: and since U-Boot isn't as prestigeous as linux, maintainers don't really queue up to do it
10:27 < wsa_> okay
10:27 < Marex> wsa_: anyway ... maybe we should continue rather than complain about lack of manpower all over the place ? :)
10:27 < wsa_> ack
|
