Merge remote-tracking branch 'gitlab/wiki' into HEAD

1 files changed, 207 insertions, 0 deletions

diff --git a/wiki/Chat_log/20160519-io-chatlog b/wiki/Chat_log/20160519-io-chatlog
new file mode 100644
index 0000000..4e181a4
--- /dev/null
+++ b/wiki/Chat_log/20160519-io-chatlog
@@ -0,0 +1,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