summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20160519-io-chatlog
blob: 4e181a4473de30229787fb537d4c09fa0572a868 (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
--- Log opened Thu May 19 09:59:57 2016
09:59 -!- wsa_ [~wsa@dslb-178-008-079-154.178.008.pools.vodafone-ip.de] has joined #periperi-io
09:59 -!- Irssi: #periperi-io: Total of 5 nicks [1 ops, 0 halfops, 0 voices, 4 normal]
09:59 -!- Irssi: Join to #periperi-io was synced in 1 secs
10:00 < wsa_> hiya
10:00 < shimoda> hi
10:00 <@neg> hello
10:00 < wsa_> nice to see you all despite having forgotten the reminder mail
10:00 < wsa_> :)
10:01 < horms> hi
10:01 < geertu> hi
10:02 < wsa_> so, let's start the meeting
10:02 < wsa_> i'd like to start with status updates per person
10:02 < wsa_> driven by an honest sort -R (random)
10:03 < wsa_> ;)
10:03 < wsa_> shimoda: you are first
10:03 < wsa_> what is new on your side?
10:03 < shimoda> wsa_: yes
10:04 < shimoda> about USBPHY,v4.7,public,shimoda,add extcon support, it is merged
10:04 < wsa_> great!
10:05 < shimoda> into linux-phy , next branch
10:05 < shimoda> so, perhaps it is merged in v4.7 linus branch
10:06 < wsa_> let's hope so
10:06 < shimoda> about other 2 tasks (usb3-host and USBPHY OTG support), no update
10:07 < wsa_> ok
10:07 < shimoda> and now, I'm investigate IPMMU + USB2.0 issue
10:07 < shimoda> on Gen3
10:07 < shimoda> other devices (xhci and ohci) seem work correctly, but ehci doesn't work...
10:08 < wsa_> is this a new task?
10:08 < shimoda> yes, it is a new task
10:08 < wsa_> USB2-Host,v4.8,plan,shimoda,IPMMU issues on Gen
10:09 < wsa_> USB2-Host,v4.8,plan,shimoda,IPMMU issues on Gen3
10:09 < shimoda> yes, thanks!
10:09 < shimoda> about i/o, these are my current status
10:10 < wsa_> thank you!
10:10 < wsa_> I'm next
10:10 < wsa_> about the SDIO task:
10:10 < wsa_> somehow done since I got the KS7010 card working here
10:11 < wsa_> however, without the card this cannot be reproduced in Japan :(
10:11 < shimoda> great!
10:11 < wsa_> Magnus has set up 2 other cards remotely for me
10:11 < wsa_> i will check them
10:12 < shimoda> yes... but to avoid export paper work, i don't want to get the card from you :)
10:12 < shimoda> sorry. I forgot to reply on your email
10:12 < wsa_> however, if there are WLAN driver issues, there is no time to debug those...
10:13 < wsa_> OK. I will bring one in July and then we can talk what to do with it
10:13 < wsa_> skipping paperwork
10:13 < shimoda> I also tried to a sdio card that Magnus-san has (mwifiex / 88W8887), it doesn't work correctly.
10:14 < wsa_> there might be a follow-up task SDIO+UHS, but we need to discuss that
10:14 < shimoda> JFYI, the card also doesn't work correctly on gen2 bsp :)
10:14 < wsa_> and we should have one WIFI card specified for that, surely
10:14 < wsa_> shimoda: thanks, that is interesting
10:14 < wsa_> BTW the KS7010 cards do NOT work on Gen2 :(
10:15 < wsa_> looks like interrupt delivery problems
10:15 < horms> i think the gen2 bsp or at least the ltsi it is based on was tested with the sdio card that I have at some point. But it was a long time ago so I don't recall the details.
10:16 < wsa_> i think we should play some SDIO card game in Japan
10:16 < horms> ok
10:16 < horms> i'm happy to loan my card to the cause
10:16 < horms> Jinso have or at least had the same card
10:16 < wsa_> thanks
10:16 < wsa_> that sounds likely ;)
10:16 < horms> I'm pretty sure I arranged for them to order some
10:17 < horms> back in the day
10:17 < horms> ...
10:17 < wsa_> they are hard to get today
10:17 < horms> probably
10:18 < wsa_> so, despite the KS7010 working fine on Gen3, I guess SDIO topics will be around for some more time
10:18 < wsa_> my other task is watchdog pretimeout support
10:18 < wsa_> I picked up the old patches
10:18 < wsa_> and am currently simplifying them
10:19 < horms> n.b. possibly one of the cards magnus has made available to you is the same as the one I have
10:19 < wsa_> watchdog core has significantly changed, so they don't work as is
10:19 < wsa_> horms: i think so
10:20 < wsa_> horms: but for debugging, a real card may be the solution
10:20 < horms> i can post mine if the need arises, just let me know :)
10:20 < wsa_> so i remove the IMO over-engineered parts from the pretimeout patches
10:21 < wsa_> i hope it makes them easier to be applied upstream
10:21 < wsa_> horms: thanks
10:22 < wsa_> other than that: basic SDHI maintenance
10:22 < wsa_> not much more
10:22 < wsa_> lots of time spending on designing additional tasks and doing additional reviews
10:22 < wsa_> that's from my side
10:23 < wsa_> geertu: your turn now
10:23 < horms> wsa_: I send you an email about task:i2c did you see it? If its pending thats fine.
10:23 < geertu> SCIF,v4.7,public,geert,Extend subsystem with GPIO-based software handling and hardware flow control
10:23 < geertu> I've sent v2
10:23 < geertu> which received some acks
10:23 < geertu> and a question, which I refuted.
10:23 < geertu> Will resend with the acks after the merge window has closed.
10:24 < geertu> SCIF,v4.8,plan,geert,SCIF FIFO flushing
10:24 < geertu> I'm currently working on that one
10:24 < wsa_> any new insights?
10:25 < wsa_> or still data collection phase?
10:25 < geertu> Data collection phase ;-)
10:26 < geertu> That's it from my side
10:27 < wsa_> ok, thanks
10:27 < wsa_> horms: your updates?
10:28 < horms> sure
10:28 < horms> I have been working on adding sdr104 support to sdhi
10:28 < horms> I posted an initial patch set, based on what is present in the BSP
10:28 < horms> It recieved review from many of the people present here: thanks for that
10:29 < horms> I've significantly reworked things accordingly
10:29 < horms> And things look better
10:29 < wsa_> cool
10:29 < horms> Currently I'm seeing some timeouts which may be related somehow
10:29 < horms> I'm also unsure of how exactly to handle that different sdhi blocks present support different speeds
10:30 < horms> Probably that can bet discussed after i post v2
10:30 < horms> Lastly, I'm not entirely convinced that the tuning actually does anything with regards to improving throughput
10:30 < horms> this may be because its not being performed correctly.
10:30 < wsa_> did you get more information about this undocumented SCC clock?
10:30 < horms> e.g. the BSP implementation does not seem to reflect the spec with respect to selecting a tap
10:31 < horms> no, that slipped my mind
10:31 < horms> In short, I'm working towards v2 but there are a few loose ends
10:32 < wsa_> do you have time left for this task after v2?
10:32 < horms> I expect to have time for v3 :)
10:32 < wsa_> great
10:32 < horms> But perhaps not the DMA investigation you were hoping for
10:32 < wsa_> i anticipated that
10:32 < wsa_> let's make sure to get the prototype proper
10:33 < horms> I anticipate v3 may spill over into next month, techincally after the deadline
10:33 < wsa_> the issue about selecting tap sounds interesting
10:33 < horms> hopefully that won't be a problem
10:33 < horms> Right
10:33 < horms> so if you look at the SCC document (which you have iirc)
10:33 < horms> it says to select the tap when 3 successive tests succede
10:33 < horms> not so complex
10:34 < horms> I implemented that
10:34 < wsa_> well, I assume V2 will qualify as prototype for the report
10:34 < horms> the BSP does something else
10:34 < horms> wsa_: yes, that is my assumption too
10:35 < wsa_> and besides that I still think we have DMA throughput problems :)
10:35 < horms> I believe there will be several unsolved issues :)
10:35 < wsa_> SDR50 doesn't need tuning and is already not as fast as I'd like
10:35 < horms> Or loose ends if you prefer
10:35 < horms> Fyi I think tuning has to not be done on the sdhi for SDR50
10:36 < wsa_> so I don't expect SDR104 to have huge gains because of that
10:36 < horms> right
10:36 < wsa_> but SDR104 was a priority for this month
10:36 < horms> as i mentioned to you elsewhere I can get 40Mbit/s
10:36 < horms> or slightly less
10:36 < horms> I tried a few different cards
10:36 < horms> their speeds vary
10:36 < horms> but that is the best one, the sandisk one
10:37 < wsa_> same here
10:37 < horms> (I boght some more cards after the last time we spoke about this)
10:37 < wsa_> should complain to samsung somewhen
10:37 < horms> I can
10:37 < horms> but perhaps there are better things to spend time on
10:37 < wsa_> that may be true
10:37 < horms> the most expensive card performed the worst, btw
10:37 < wsa_> ;)
10:38 < wsa_> ok, looking forward to v2
10:38 < horms> thats probably all from my side
10:38 < horms> I hoped to have it out for this meeting
10:38 < horms> but no such luck
10:39 < wsa_> horms: can we chat a little after this meeting about the next additional tasks?
10:39 < horms> sure
10:39 < wsa_> thanks
10:40 < wsa_> so, neg is next
10:40 <@neg> Gen3 I2C DMA support is public
10:40 < horms> neg: is that the patch I applied?
10:40 <@neg> yes thats the DT part of it
10:41 < horms> ok
10:41 <@neg> and I think wsa_ have picked up the driver patch
10:41 < wsa_> yes
10:41 <@neg> and I just sentout a incremental patch adressing Arnds comment on the driver
10:41 < wsa_> it is marked "merged" in the todo file :)
10:42 <@neg> so I hope that is it for that task :-)
10:42 < wsa_> thanks for the work!
10:42 <@neg> and that is all for me I have no other i/o task
10:42 < wsa_> any time left for IO base task?
10:43 < wsa_> not that i have something now
10:43 <@neg> hum in base no, rest of time is for core work. But if you have something small need doing I can try to squeeze it in
10:44 < wsa_> ok
10:44 < wsa_> yeah, i asked because of distribution of small things (if there is one)
10:44 < wsa_> wanted to know where we are
10:45 < wsa_> but since we fixed the r8a7740 SDHI regression, I don't see anything left there
10:45 <@neg> ofc, if you think of something let me know and I see what I can do
10:45 < wsa_> please speak up if i am wrong
10:46 < wsa_> so, neg is basically done with IO for Q2 and will (probably) have some more days in Q3
10:47 < wsa_> so, ulrich is not here and will do the CAN driver review once he is back
10:47 < wsa_> morimoto-san is also not here but doesn't have any tasks assigned anyhow
10:48 < wsa_> so, in general i think we are on track
10:48 < wsa_> thanks guys!
10:48 < wsa_> it would be nice to have more IO time for geert, though
10:48 < shimoda> thank you!
10:50 < wsa_> ok, anything more to discuss?
10:50 <@neg> If task list is done I have a IO question
10:50 < wsa_> sure
10:51 <@neg> during boot of Salvator-X it is deleayed for ~20 sec and then i get this 'xhci-hcd ee000000.usb: can't setup: -110'
10:51 <@neg> i use the arm64_defconfig and was just wondering if this is known
10:51 < shimoda> oh, sorry it's xhci driver problem
10:52 < wsa_> there are mails about it on renesas-soc
10:52 <@neg> ok thanks
10:53 < wsa_> in short: a Kconfig dependecy needs to be set up
10:53 < shimoda> in v4.6, it should be fixed by f879fc32aa0c96fbac261b3d857a1239d554ad01
10:54 <@neg> shimoda: great, thanks
10:55 < shimoda> neg: you're welcome!
11:04 < wsa_> ok, if no more questions...
11:04 < wsa_> ...then thanks for this meeting!
11:05 < shimoda> thank you! bye!
11:05 <@neg> thanks all
11:05 -!- shimoda [~shimoda@relprex3.renesas.com] has quit Quit: WeeChat 0.4.2
11:06 < geertu> Data collection phase ;-)bye
11:06 < wsa_> good luck geertu !
11:06 < geertu> Seems I have a problem with my IRC FIFO, too ;-)
--- Log closed Thu May 19 11:16:26 2016