summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20151015-io-chatlog
blob: 610141617e8d8685e8610ca6142dcd0f551f854e (plain)
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
--- Log opened Thu Oct 15 10:58:29 2015
10:58 -!- wsa_ [~wsa@p4FE25555.dip0.t-ipconnect.de] has joined #periperi
10:58 -!- Irssi: #periperi: Total of 7 nicks [0 ops, 0 halfops, 0 voices, 7 normal]
10:58 -!- Irssi: Join to #periperi was synced in 1 secs
10:58 < pinchartl> can I let you handle it internally to book a time and place ?
10:58 < dammsan> yes
10:58 < wsa_> hi there!
10:58 < pinchartl> or do you expect me to do anything ?
10:58 < pinchartl> hi Wolfram
10:58 < dammsan> no, it will be on the 4th
10:58 < dammsan> more details to follow over email
10:59 < dammsan> bye bye!
10:59 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has quit Remote host closed the connection
10:59 < wsa_> bye magnus
10:59 < pinchartl> bye bye too :-)
10:59 < wsa_> bye!
11:00 -!- Irssi: #periperi: Total of 6 nicks [0 ops, 0 halfops, 0 voices, 6 normal]
11:01 -!- horms [~horms@121-80-213-238f1.hyg1.eonet.ne.jp] has joined #periperi
11:01 < wsa_> \o/
11:01 < wsa_> hi simon
11:01 < geertu> Hi Wolfram
11:01 < wsa_> hi geert
11:02 < horms> hi!
11:02 < wsa_> morimoto-san, shimoda-san: you there?
11:02 < morimoto> hi
11:02 < shimoda> hi!
11:02 < wsa_> \o/
11:02 < geertu> Hi all
11:03 < morimoto> geertu: about Koelsh, it seems there is ES1.0/ES2.0/ES3.0 in this world
11:03 < morimoto> but I (and shimoda-san) only have ES1.0 board
11:03 < wsa_> good starting point
11:04 < geertu> Good to know.
11:04 < wsa_> what about having a wiki page stating who has which board with which ES  number
11:04 < geertu> Let's wait for bug reports ;-)
11:04 < geertu> Yeah, that's long overdue
11:06 < wsa_> I would start it, but it might be that I forgot my wiki pwd :/ will try again after this meeting
11:06 < geertu> My Salvator-X has H3 ES1.0
11:06 < geertu> Bummer, no access to https://osdr.renesas.com/projects/linux-kernel-development/wiki/Io-todo-list?
11:08 < wsa_> so, the other topics for today I have: todo list updates, SCIF status, Who does SDHI, Watchdog plans
11:08 < wsa_> more topics from your side?
11:09 < horms> i would like to ask shimoda san about etheravb. but i can ask him tomorrow when i visit his office if there is no time here today
11:09 < wsa_> ok, so we put this to the end of the list
11:10 < shimoda> horms: i got it :)
11:10 < wsa_> so, let's start with todo list updates:
11:10 < wsa_> I have
11:10 < wsa_> PWM driver upstream \o/
11:11 < wsa_> Thermal driver still needs the docs
11:11 < wsa_> PCIE patches appeared on ML, will check them when my board arrives
11:11 < wsa_> (according to UPS should be today)
11:11 < wsa_> EtherAVB basic support upstream \o/
11:12 < wsa_> SATA driver: BSP team works on it
11:12 < wsa_> I2C: runtime core switch postponed to 4.5. too late in the cycle for DT bindings
11:12 < wsa_> I2C: DMA task added until End of May
11:13 < wsa_> not sure about this one:
11:13 < wsa_> SPI slave support wanted until End of May
11:13 < wsa_> ?
11:13 < wsa_> shimoda: is this final? or is it still a request only?
11:13 < geertu> I'll have to look at the other SPI Ethernet driver, and do some more research for a good use case.
11:14 < geertu> Shimoda-san: Do you have more info about the customer's use case?
11:14 < shimoda> geertu: unfortunately I don't have more info
11:15 < geertu> At ELCE, I talked to Mark Brown (SPI maintainer), and he's open for SPI slave support.
11:15 < geertu> Shimoda-san: Would it be possible to ask somewhere to obtain more info?
11:16 < shimoda> geertu: i will try to ask
11:16 < wsa_> geertu: what is the status of this large SCIF series?
11:16 < wsa_> needs ping? needs review? already upstream?
11:17 < shimoda> wsa_: about thermal driver, I heard bsp team is developing it. So, I will get information from them later
11:17 < geertu> SCIF DMA is in -next
11:17 < geertu> So it will be in v4.4
11:17 < wsa_> \o/
11:18 < wsa_> didn't notice from the mails in linux-sh
11:18 < wsa_> so i can remove
11:18 < wsa_> SCIF,4.4,Upstream improved DMA support for R-Car Gen2
11:18 < wsa_> from the todo list
11:18 < wsa_> ?
11:19 < geertu> GregKH's bot didn't CC linux-sh
11:19 < geertu> Yes (assumed in -next == will be in v4.4)
11:19 < wsa_> shimoda: ok, will update the info about thermal driver
11:20 < wsa_> geertu: and you will be working on baudrate generators for 4.5, correct?
11:20 < geertu> that's correct
11:20 < geertu> I'm a bit delayed by the Gen3 CPG rework
11:21 < wsa_> I can imagine
11:22 < wsa_> geertu: anything else you are planned to work on IO wise?
11:22 < morimoto> I asked about SPI slave use case to BSP team
11:22 < wsa_> I have this baudrate generator and random SPI stuff in the list :)
11:23 < geertu> Yeah, I plan to test MSIOF on Gen3, if possible (read: available on EXIO)
11:23 < wsa_> same questions to the others
11:23 < wsa_> shimoda: I assume you will be busy doing USB stuff?
11:24 < wsa_> morimoto: any IO related task you have assigned? (except using I2C for sound ;))
11:24 < morimoto> Ahh... no I/O I have
11:24 < wsa_> simon: I guess you'll work in improving EtherAVB support?
11:25 < shimoda> wsa_: yes, but bsp team needs USB stuff (expect USB2 host) until end of May
11:25 < shimoda> so, i have some space
11:25 < wsa_> oh, that sounds good
11:25 < morimoto> wsa_: About Thermal driver lacking docs, do you mean 10A.3.1.2 ?
11:25 < horms> EtherAVB is the only i/o related item i'm working on directly
11:25 < shimoda> however, sometimes I have a lot of paper works though :)
11:26 < wsa_> oh, that sounds not good
11:26 < wsa_> :)
11:27 < wsa_> horms: anything specific? I have only PTP support until End of November in the list
11:27 < horms> so my question for shimoda-san is about that
11:27 < horms> is now a good time?
11:28 < wsa_> morimoto: yes, and 10.A.3.1.4
11:30 < shimoda> horms: sorry I don't understand your question
11:30 < shimoda> you are talking about PTP support?
11:31 < horms> my quesion is as follows
11:32 < morimoto> wsa_: OK, according to datasheet team, about 10A.3.1.2, it depends on real measured data.
11:32 < morimoto> but, there is not such data at this point. So, it will be other explanation in next datasheet
11:32 < morimoto> if they still doesn't have it
11:33 < horms> I see some PTP support present in the ravb driver. It looks like it handles timestamps. Is that what is required for r8a7795 by mid-November?
11:33 < wsa_> morimoto: I assumed so. Anyhow, looks like BSP team took this over. They will probably have better access to such data
11:36 < shimoda> horms: thank you for the detail. I will ask bsp team about this
11:36 < horms> shimoda: thanks. if they want to explain things in patches that is fine by me :)
11:37 < wsa_> good
11:38 < wsa_> can we move to SDHI topic?
11:38 < horms> i think so
11:38 < shimoda> i think so
11:39 < wsa_> fine
11:39 < wsa_> It seems that BSP team also wants to do the initial support?
11:39 < wsa_> And then wants to work on DMA support?
11:40 < shimoda> I think they want to work on DMA support if possible
11:40 < wsa_> And they need some assistance from us how to do it
11:41 < shimoda> I think so
11:43 < wsa_> do they have patches for initial support already?
11:43 < shimoda> tmio driver is using dmaengine. but I don't know gen3 SDHI should use it or not
11:44 < shimoda> wsa_: for PIO, yes
11:44 < shimoda> let me check some repositories
11:47 < shimoda> in renesas-bsp.git, 91e3cc719def606e049861d4f9fc02bd90f126be, arm64: dts: salvator-x: Add sdhi-rcar support
11:48 < shimoda> 09a0662a2b6073bb2237b5d28a354a406b4b640b, arm64: dts: r8a7795: Add sdhi-rcar support
11:49 < wsa_> got them
11:50 < wsa_> and some more patches to look at
11:50 < shimoda> about driver side, they are submitted some local patches...
11:50 < horms> wsa_: btw renesas-bsp is on kernel.org
11:52 < wsa_> yes, that's good
11:53 < wsa_> well, the makefile from mmc/hosts says:
11:53 < wsa_> tmio_mmc_core-$(subst m,y,$(CONFIG_MMC_SDHI))   += tmio_mmc_dma.o
11:53 < wsa_> so, the DMA module is only compiled in for SDHI?
11:54 < wsa_> ah, sure. the todo list only marks "DMA on Gen3" as a todo
11:55 < shimoda> wsa_: yes, on gen3, DMAC is internal in the SHDI device instead of SYS-DMAC
11:57 < wsa_> is this internal DMAC reused in other IP cores?
11:57 < wsa_> it doesn't look SDHI specific to me
11:58 < shimoda> I don't think this internal DMAC is reused
12:01 < wsa_> ok
12:02 < morimoto> About makefile, tmio_mmc_dma.o is used only from CONFIG_MMC_SDHI is correct
12:02 < morimoto> this is because historical reason
12:02 < morimoto> About Gen3 internal DMAC, this is Gen3 new feature
12:02 < morimoto> Gen3 DMAC != tmio_mmc_dma
12:02 < wsa_> I'd think a new file 'tmio_mmc_dma_gen3.c' or similar would be the way to go, but I need to double check
12:03 < wsa_> I can investigate
12:03 < wsa_> Is it "as soon as possible" or will next week be enough?
12:03 < morimoto> I think it is not "tmio", "sh_mobile_sdhi_dma" is better ?
12:04 < horms> can we rename tmio_mmc_dma while we are at it?
12:04 < wsa_> to?
12:04 < horms> I suspect it doesn't relate to tmio at all
12:04 < horms> but just to sdhi
12:05 < horms> i could be wrong
12:05 < wsa_> i will dig into that and post my findings on the list
12:05 < morimoto> unfortunately, not good idea
12:05 < morimoto> because tmio_mmc_pio calls tmio_mmc_dma function
12:06 < horms> ok
12:06 < morimoto> But, we can create new sub-framework for DMA?
12:06 < morimoto> real TMIO doesn't need DMA (?), we need 2type of DMA
12:07 < morimoto> and tmio_dma naming is not good match now ?
12:07 < horms> probably that will lead to a nice clean result
12:07 < horms> but is gen3 dma on the critical path?
12:08 < horms> If so it would be nice to arrange things so new frameworks come after hw support, imho
12:08 < wsa_> agreed
12:08 < shimoda> horms: on the critical path or not, let us ask BSP team tomorrow :)
12:09 < horms> good plan
12:09 < wsa_> anything more for SDHI?
12:09 < wsa_> otherwise let's move on to watchdog
12:11 < morimoto> ok
12:11 < wsa_> ok, my idea there is to implement the missing SET_TIMEOUT feature and repost as RFC
12:12 < wsa_> we can then test this one on Gen2/3 and see if it works with the reset controllers
12:12 < wsa_> (it obviously doesn't on r8a7790 ES1)
12:12 < wsa_> if all fails, I could try to add r7s72100 support and get at least the driver upstream vis this path
12:13 < wsa_> so we don't have to carry around this one
12:13 < wsa_> OK plan?
12:13 < shimoda> wsa_: if we use not SMP, watchdog should work even if r8a7790 ES1
12:14 < geertu> The watchdog is not limited to R-Car Gen2/3 and RZ
12:15 < wsa_> shimoda: Yes, then it works
12:15 < wsa_> I can confirm that
12:15 < geertu> it's also present on older SH-Mobile and R-Mobile
12:16 < wsa_> geertu: like with r7s or even another register layout?
12:17 < geertu> BTW, the issue with the syscon driver I mentined in "Re: [RFC 4/5] ARM: shmobile: r8a7790: let rst module allow watchdog resets if desired" (http://www.spinics.net/lists/linux-sh/msg39799.html) is gone
12:19 < wsa_> how come?
12:20 < geertu> At that time, you couldn't have both syscon and a regular driver bind to the same device node
12:20 < geertu> that has been fixed
12:20 < geertu> the APE6 RWDT looks the same as Gen2
12:21 < geertu> The RZ one is different
12:22 < geertu> A1/AG5 uses an 8-bit version of APE6/Gen2
12:22 < geertu> So there are 3 versions
12:23 < wsa_> ah, okay, so we still need the "syscon" property somewhen
12:23 < geertu> But "It's slightly more complicated there, as we already have a driver for the
12:23 < geertu> SYSC on R-Mobile (rmobile-reset), and a device node can't be bound
12:23 < geertu> by both the syscon and the rmobile-reset driver.
12:23 < geertu> " is no longer true
12:25 < geertu> From a chat with Magnus a long time ago: "
12:25 < geertu> Looking at datasheets, it seems the RWDT has a long history.
12:25 < geertu> R-Car Gen2: 32-bit registers, using RST
12:25 < geertu> R-Mobile APE6: 32-bit registers, using SYSC (APE6 has no RST block)
12:25 < geertu> SH-Mobile AP4/AG5, R-Mobile A1: 16-bit registers with 8-bit (instead of 16-bit) watchdog counter
12:25 < geertu> But the core is similar.
12:25 < geertu> And of course AP4 and A1 are single-core"
12:25 < geertu> RZ has a different control register layout
12:26 < wsa_> ok, i have datasheets for all of them
12:27 < wsa_> well, then, i'll do as I said before
12:27 < geertu> I can test A1/AG5/APE6
12:27 < wsa_> since there were no complaints ;)
12:27 < geertu> and M2 and H3, of course
12:27 < wsa_> geertu: \o/
12:28 < wsa_> I ran out of topics
12:28 < shimoda> About H3, as I wrote periperi ML, we can not write RST
12:28 < shimoda> :)
12:28 < wsa_> :)
12:28 < wsa_> anything from your side left?
12:30 < morimoto> nope
12:30 < geertu> nope
12:30 < horms> not here either
12:31 < shimoda> no
12:31 < wsa_> then we are done
12:31 < wsa_> \o/
12:31 < wsa_> thanks all!
12:31 < horms> thanks!
12:31 < morimoto> thanks
12:31 < shimoda> thank you!
12:31 < wsa_> have a great rest of the day
12:31 < geertu> thx, cu
12:31 < geertu> bye
12:31 < shimoda> bye!
--- Log closed Thu Oct 15 12:34:05 2015