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

1 files changed, 371 insertions, 0 deletions

diff --git a/wiki/Chat_log/20160901-io-chatlog b/wiki/Chat_log/20160901-io-chatlog
new file mode 100644
index 0000000..5623d34
--- /dev/null
+++ b/wiki/Chat_log/20160901-io-chatlog
@@ -0,0 +1,371 @@
+--- Log opened Thu Sep 01 09:57:26 2016
+09:57 -!- wsa_ [~wsa@dslb-178-008-071-018.178.008.pools.vodafone-ip.de] has joined #periperi-io
+09:57 -!- Irssi: #periperi-io: Total of 3 nicks [1 ops, 0 halfops, 0 voices, 2 normal]
+09:57 -!- Irssi: Join to #periperi-io was synced in 0 secs
+09:58 -!- khiemnguyen_ [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi-io
+09:58 -!- neg_ [~neg@unaffiliated/neg] has joined #periperi-io
+09:58 < neg_> morning all
+09:58 -!- neg_ is now known as neg
+09:59 < wsa_> hi!
+09:59 <@uli___> hello
+09:59 < khiemnguyen_> hello
+10:00 < geertu> Hi all
+10:00 < wsa_> simon said he has another meeting right now
+10:00 < wsa_> let's wait a little for our japanese fellows
+10:01 -!- horms [~horms@217.111.208.18] has joined #periperi-io
+10:01 -!- morimoto [~user@relprex1.renesas.com] has joined #periperi-io
+10:02 < wsa_> hi
+10:02 < morimoto> hi
+10:02 < horms> wsa_: I am able to attend this meeting after all. But I need to leave at 11
+10:03 < wsa_> horms: great
+10:03 < wsa_> so i might need to tweak 'sort -R' a bit
+10:03 < horms> sorry for the mix up. my life is crazy-special-busy at the moment
+10:03 < horms> I can just go last if it helps
+10:03 < horms> (assuming we don't go for too long)
+10:04 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has joined #periperi-io
+10:04 < wsa_> horms: if you have to leave at 11, i think you should be first?
+10:04 < horms> sure
+10:05 < wsa_> hi magnus
+10:05 < dammsan> hi guys
+10:05 < dammsan> i just want to hijack this space and briefly mention about next quarter additional task timing
+10:05 < wsa_> ok, let's start then
+10:05 -!- shimoda [~shimoda@relprex3.renesas.com] has joined #periperi-io
+10:06 < dammsan> let me know when is good for you
+10:06 < shimoda> hi, sorry for late joinning
+10:06 < wsa_> dammsan: let's start with that, now all people are here (simon has to leave at 11)
+10:07 < wsa_> shimoda: hi, no problem
+10:07 < wsa_> and then simon
+10:07 < wsa_> and then sort -R
+10:07 < dammsan> ok thanks
+10:08 < dammsan> the upcoming quarter schedule is going to resemble this one
+10:08 < dammsan> however we are going to be more firm when creating the additional tasks
+10:08 < dammsan> this to make the due dates follow same pattern for everyone
+10:08 < dammsan> so, the due dates will be 11/M for first batch and 12/M for the second batch
+10:09 < dammsan> the first batch needs to be decided in the middle of this month at 9/M
+10:09 < dammsan> while the second batch can be decided after meeting f2f in berlin at 10/M
+10:10 < dammsan> i would like the mighty group leader to come with a proposal for the first batch
+10:10 < dammsan> please discuss among yourselves =)
+10:10 < wsa_> base task assignments are also like this quarter?
+10:10 < dammsan> yep
+10:11 < dammsan> some things like invoice frequency might change
+10:11 < horms> will there be any other "firmness" adjustments other than aligning the dates as you describe above?
+10:11 < dammsan> but it should be about the same
+10:11 < dammsan> good question
+10:11 < dammsan> there is no plan to implement anything special for next quarter
+10:12 < horms> ok.
+10:12 < dammsan> we may however refuse payment if some particular task is not finished
+10:12 < horms> Are tests etc... due with the reports at the dates described above: there was some talk of chaning that
+10:12 < dammsan> not sure what that was
+10:12 < horms> ok, in that case, probably not
+10:12 < horms> thanks for answering my questions
+10:13 < dammsan> maybe we can go through those ideas in berlin?
+10:13 < dammsan> and work to improve first quarter next year?
+10:13 < horms> ok, berlin is going ahead? I am at best confused about that plan
+10:13 < dammsan> we are running late for the upcoming quarter i think
+10:13 < dammsan> i am also confuse
+10:13 < horms> time is always against us :^)
+10:13 < dammsan> d
+10:13 < horms> ok
+10:13 < dammsan> but both morimoto-san and i will be there
+10:14 < dammsan> in between the conferences
+10:14 < dammsan> i hope we can arrange something
+10:14 < horms> i will try to be there: as I mentinoed I have visa fun. But I'd say its about 80% that it will be ok
+10:14 < wsa_> are you both there for LinuxCon, too? Or just ELC-E?
+10:14 < wsa_> both = Magnus & Morimoto
+10:14 < dammsan> we will be on both conferences
+10:14 < wsa_> cool
+10:14 < dammsan> both = LC and ELC =)
+10:15 < dammsan> before handing over
+10:15 < dammsan> i'd just like to clarify one pattern of handling failure to deliver when it comes to additional tasks
+10:15 < dammsan> in case a certain feature is lagging behind
+10:16 < dammsan> or say it does not implement all the features described in the task description
+10:16 < dammsan> then we may softly refuse to pay, and instead ask to schedule a new task
+10:16 < dammsan> the new task should cover the time spent plus new time needed to complete the task
+10:17 < dammsan> so payment will be delayed
+10:18 < dammsan> to avoid such situation please work to come up with accurate time estimates =)
+10:18 < dammsan> if you have any questions please let me know
+10:18 < wsa_> how do I (as a group leader) if that happened? from the developer?
+10:18 < dammsan> otherwise we can deal with it when it happens
+10:19 < dammsan> yeah, i believe the deverloper is going to tell you about the slip
+10:19 < dammsan> so you can adjust your TODO list
+10:20 < wsa_> because I don't know what has been reported to you
+10:20 < dammsan> and then a new-but-similar-and-longer additional task will come up
+10:21 < wsa_> i see
+10:21 < dammsan> when sending reports and invoices you will get feedback if something needs more work
+10:21 < dammsan> that's how the individual engineer notices this
+10:22 < wsa_> ok
+10:22 < dammsan> does it make sense?
+10:23 < wsa_> let's find out :)
+10:23 < dammsan> yes!
+10:23 < dammsan> thanks for your efforts
+10:23 < dammsan> i'll leave you to the meeting now =)
+10:24 < dammsan> geertu: yes
+10:24 < wsa_> thanks magnus!
+10:24 < dammsan> i recommend you to draw and think about it
+10:24 < dammsan> thanks guys
+10:25 < dammsan> lets talk more and clarify in berlin
+10:25 < dammsan> wsa_: can we chat next week about the new tasks for slot 1?
+10:25 < wsa_> dammsan: sure
+10:25 < dammsan> please get back to me over email
+10:25 < wsa_> will do
+10:25 < dammsan> i wish you a nice continued day and evening =)
+10:25 < dammsan> bye bye
+10:25 -!- dammsan [~dammsan@s214090.ppp.asahi-net.or.jp] has quit Remote host closed the connection
+10:26 < wsa_> off he goes
+10:26 < wsa_> simon, your turn now
+10:26 < horms>   a) what have I worked on since last time
+10:26 < horms>      * SDR104
+10:26 < horms>        - Addressed Ulf's review of v4
+10:26 < horms>        - Enabled H3 in v5
+10:26 < horms>   b) what will I work on until next time
+10:26 < horms>      * Work on merge of above
+10:26 < horms>        - Need to add code to used saved tap values as per Ulf's request:
+10:26 < horms>          but I am unsure how to exercise it
+10:26 < horms>      * Extend SDR104 coverage to other boards
+10:26 < horms>      * Follow up on timeout problem on H2 reported by Magnus
+10:26 < horms>      * Update test wiki patge as suggested by Magnus
+10:26 < horms>        - Test 512Mb rather than 64Mb transfers
+10:26 < horms>        - Include CID info of cards tested
+10:26 < horms>        - Make present control data more clearly
+10:26 < horms>   c) I have the following problems (or not)
+10:26 < horms>      * SDR104 timeout reported by Magnus on H2
+10:27 < horms>      * susspend resume seems unreliable:
+10:27 < horms>        - need to investigate
+10:27 < horms>        - may not be related to SDR104 work
+10:27 < horms> -- end prepared statement --
+10:27 < wsa_> what card did Magnus have doing the timeouts?
+10:28 < horms> I am confirming that
+10:28 < khiemnguyen_> horms: susspend resume seems unreliable <--- what is the problem ?
+10:28 < wsa_> he didn't write his test results publicly, did he?
+10:28 < horms> khiemnguyen_: sometimes I get an error (-84) from the mmc subsystem on resume
+10:29 < horms> my test results are public
+10:29 < horms> magnus's result was in a private email: he reported sdr104 is not working on h3 due to timeouts
+10:29 < wsa_> and as I wrote a few minutes ago, ejecting a SDR104 card on H3 stall the interface
+10:29 < horms> It did work when I tested it in my environment. I will re-test
+10:30 < horms> ok, how does a stall manifiest?
+10:31 < wsa_> if i insert a new card, nothing happens
+10:31 < horms> ok
+10:31 < wsa_> not even card detection triggers
+10:31 < horms> that is a bit hard for me to test :(
+10:32 < horms> With regards to Ulf's suspsend/resume rquest
+10:32 < horms> I do not undertand how to exersise using saved tap values
+10:32 < horms> as the condition he suggests for using them is always false on resume
+10:32 < wsa_> ask him?
+10:32 < khiemnguyen_> horms: before your new patches for SDR104, did you see same phenomenon ?
+10:33 < horms> khiemnguyen_: its hard to say because it doesn't always occur
+10:33 < horms> no I haven't observed it
+10:33 < horms> but I'm not sure that means anything
+10:33 < wsa_> suspend/resume issues might be a seperate task?
+10:34 < khiemnguyen_> -84 = EILSEQ error, illegal byte sequence.
+10:34 < wsa_> if not caused by a SDR104 regression
+10:36 < horms> that is my feeling
+10:36 < horms> I will try harder to reproduce the problem in a way that we can see where the cause is: or at least if it is in SDR104 or not
+10:37 < wsa_> i wonder if you should focus on the timeout problems?
+10:38 < wsa_> maybe we can ask someone (niklas?) to research if the problem exists with/without SDR104 patches?
+10:38 < horms> can do if that is your recommendation
+10:38 < horms> I would be very happy for someone else to look into that problem
+10:38 < horms> I am observing it on H3
+10:39 < wsa_> neg: have any free time for a base task for IO?
+10:39 < neg> not for this Q
+10:39 < wsa_> :(
+10:40 < wsa_> uli___: ?
+10:40 <@uli___> not if it's urgent. :) around end of the month?
+10:40 < neg> but next Q is just around the corner, so after the 15/9 I have time
+10:40 < wsa_> ok
+10:41 < wsa_> I'll think about it
+10:41 < wsa_> for now, i think the priority should be the timeouts
+10:41 < horms> ok
+10:41 < horms> but for now i can't reproduce the problem
+10:42 < wsa_> i mean this is even in the header of your task description
+10:43 < wsa_> try some more cards?
+10:44 < horms> ok, i feel like the temmprature is turning up on me here
+10:44 < horms> I want to clarify that I had some test cases where timeouts where a big problem.
+10:44 < horms> And I worked to resolve those.
+10:44 < horms> Which is the case.
+10:44 < horms> This morning I found that Magnus has found a new case which I will investigate.
+10:44 < wsa_> uli___: did you try SDR104 with the DMA bottleneck task?
+10:45 <@uli___> i checked the performance, but that is about as far as i got
+10:45 < wsa_> horms: don't want to heat up, really
+10:45 <@uli___> i get some 51 mb/s
+10:45 <@uli___> with sandisk ultra 32gb
+10:45 < wsa_> uli___: so SDR104 worked for you
+10:45 <@uli___> yes
+10:46 < wsa_> horms: just wanted to explain why I choose "timeout" over "suspend/resume" as prioritized
+10:47 < wsa_> uli___: good
+10:47 < horms> wsa_: ok, understood
+10:48 < horms> I think i may know which card magnus used: SDSDQXP-032G-G46A
+10:48 < horms> this is not a card I have tested
+10:48 < horms> I will try to confirm that is the card and test it
+10:49 < wsa_> great
+10:49 < wsa_> sorry about my misleading communication before
+10:50 < wsa_> let's move on, shall we?
+10:50 < wsa_> morimoto: you are next
+10:51 < wsa_> horms: and thanks for the work!
+10:53 < wsa_> am I lagging?
+10:54 < horms> wsa_: sorry about this unexpected developmen with sdr104
+10:54 <@uli___> [CTCP] Received CTCP-PING reply from wsa_: 1 second.
+10:55 < wsa_> okay, until morimoto reacts...
+10:55 < wsa_> khiemnguyen_: can you go next
+10:55 < khiemnguyen_> ok
+10:56 < khiemnguyen_> a) nothing yet.
+10:56 < khiemnguyen_> b) try to catch v4.9 for R-Car Gen3 Thermal
+10:56 < khiemnguyen_> I will push the updated patches within today.
+10:56 < khiemnguyen_> It seems I still have this week and next week. It's my last chance.
+10:57 < khiemnguyen_> c) I have been assigned some additional tasks.
+10:57 < khiemnguyen_> Now, I'm struggling to find time for upstream work
+10:57 < khiemnguyen_> September will be easier for me. I try to catch up now.
+10:57 < khiemnguyen_> That's all for my current status.
+10:58 < wsa_> are you still waiting for data for the thermal driver?
+10:58 < morimoto> wsa_: sorry I was busy.
+10:58  * horms drops off
+10:58 -!- Netsplit *.net <-> *.split quits: shimoda
+10:58 < khiemnguyen_> I think it's enough for 1st version of Gen3 thermal driver.
+10:59 <@uli___> horms: bye
+10:59 -!- Netsplit over, joins: shimoda
+11:00 < wsa_> good
+11:00 < wsa_> will you be in berlin for ELCE?
+11:01 < khiemnguyen_> nope. I have not planned for this. So, my manager could not accept it.
+11:01 < khiemnguyen_> I will plan for next year.
+11:01 < wsa_> ok
+11:02 < wsa_> would be really great to have the driver in 4.9
+11:02 < wsa_> good luck! :)
+11:03 < wsa_> thanks!
+11:03 -!- horms [~horms@217.111.208.18] has quit Ping timeout: 252 seconds
+11:03 < wsa_> morimoto: your turn now
+11:03 < khiemnguyen_> yeah, will try my best with Morimoto-san support :)
+11:03 < morimoto> OK,
+11:03 < morimoto> But I have no I/O task :)
+11:03 < morimoto> I shipped M3 board for you guys
+11:04 < wsa_> and it looks like you support khiem :)
+11:04 < wsa_> i will test my M3 today
+11:04 < shimoda> oh, morimoto-san is calling with someone now
+11:05 < wsa_> ok
+11:05 < wsa_> neg: your turn
+11:05 < morimoto> I'm back, sorry
+11:05 < morimoto> that's it from me. nothing for report
+11:06 < neg> a) Found the problem with OHCI-PCI + CONFIG_DMA_CMA=y
+11:06 < neg> b) Noting, no IO tasks for me
+11:06 < neg> c) None
+11:06 < neg> geertu: do you feel happy about the solution to OHCI-PCI + CONFIG_DMA_CMA=y ?
+11:06 < wsa_> i think that should be:
+11:07 < wsa_> c) not enough base time task for IO ;)
+11:07 < neg> there is never enough time :-)
+11:07 < geertu> neg: Yes. Still have to update my  U-Boot. Don't want to risk bricking my Koelsch now (add. task due soon :-)
+11:08 < neg> should I send a patch enabiling CMA in shmobilde_defconfig?
+11:09 < geertu> neg: I'll happily reassign that task (from Laurent) to you ;-)
+11:09 < neg> ohh I do not want to steal his tasks :-)
+11:09 < geertu> Yes, we need CMA for graphics
+11:11 < wsa_> play junkenpon for this task :D
+11:11 < wsa_> okay, i am next
+11:12 < geertu> "Google says: Did you mean: jankenpon?"
+11:12 < wsa_> yes
+11:12 < wsa_> A) since last time:
+11:12 < wsa_> * fixed IP core switcher issue
+11:12 < wsa_> * fixed flaw in DA9xxx interrupt storm handling on Gen2
+11:12 < wsa_> * re-animated pretimeout topic upstream and reviewed new patches
+11:12 < wsa_> * fixed SDHI regression on r8a73a4
+11:12 < wsa_> * fixed DMA-API warning in Renesas i2c drivers (thanks Geert for the pointer!)
+11:12 < wsa_> B) until next time:
+11:12 < wsa_> * enable 8 bit eMMC mode on Gen3
+11:12 < wsa_> * test new SDR104 series
+11:12 < wsa_> C) problems I have:
+11:12 < wsa_> * getting results of tasks
+11:13 < wsa_> with C) I mean
+11:13 < wsa_> i got to know about magnus sdr104 problems from simon
+11:13 < wsa_> that should have been public
+11:14 < wsa_> or at least me cc'ed, I'd think
+11:14 < wsa_> or I just got to know here that uli___ did test DMA with SDR104 already
+11:15 < wsa_> I'd like to know such things asap
+11:15 < wsa_> because this affects planning additional tasks etc
+11:15 < wsa_> need to communicate this better
+11:15 < wsa_> first step just taken :)
+11:15 < geertu> If you test something, either provide a Tested-by on success, or a (public, if not confidential) email on failure
+11:16 < geertu> There's still value in providing a Tested-By after a patch was applied (googleable mailing list archive)
+11:16 < wsa_> yup
+11:17 < wsa_> that's all from my side
+11:17 < wsa_> shimoda: you are next
+11:17 < shimoda> a) what have I worked on since last time
+11:17 < shimoda> - investigate USB EHCI + IPMMU issue with hardware guy.
+11:17 < shimoda> - merged my patch about avoiding skb_reserved() in u_ether for USB-DMAC.
+11:17 < shimoda> b) what will I work on until next time
+11:17 < shimoda> - continue to investigate USB EHCI + IPMMU issue
+11:17 < shimoda> c) I have the following problems (or not)
+11:17 < shimoda> - about USB EHCI + IPMMU issue
+11:17 < shimoda> EOF
+11:17 < shimoda> s/EOF/EOT/
+11:20 < wsa_> so could the HW guy say if it also could be a HW issue?
+11:20 < wsa_> or is it definately a software issue?
+11:20 < wsa_> or are you still investigating that?
+11:20 < wsa_> :)
+11:21 < shimoda> HW guy didn't say this is a HW issue because non-IPPMU environment doesn't have any issue
+11:21 < shimoda> so I should investigate this more
+11:24 < wsa_> ok
+11:24 < wsa_> good luck!
+11:24 < wsa_> nasty one
+11:24 < wsa_> nasty issue i mean
+11:24 < wsa_> thank you!
+11:24 < wsa_> uli___: your turn please
+11:25 <@uli___> a)
+11:25 <@uli___> sdr 104 performance: see above
+11:25 <@uli___> sd over msiof: see below, after c) :)
+11:25 < shimoda> wsa_: i think so. and thank you!
+11:25 <@uli___> b) i2c integration for m3-w (need that for my core task)
+11:25 <@uli___> c) none
+11:25 <@uli___> so about msiof:
+11:26 <@uli___> i was going to check if geertu's invalid clock patch fixes anything
+11:26 <@uli___> so i recreated the test setup that did not work before
+11:26 <@uli___> same kernel, same config, same DT
+11:26 <@uli___> same board, same firmware
+11:26 <@uli___> same connectors with the same wires soldered to the same pins
+11:26 <@uli___> i turn it on, and it works
+11:26 <@uli___> consistently
+11:26 <@uli___> without explanation or apology
+11:26 <@uli___> mind that before
+11:27 <@uli___> it did not work consistently with msiof, but it did work consistently with gpio
+11:27 <@uli___> now it always works for both
+11:27 <@uli___> no idea
+11:27 <@uli___> i'll just remove the paragraph on elinux that says it fails, and call it a day :)
+11:27 <@uli___> end of story
+11:27 < geertu> Great to hear it works!
+11:28 < wsa_> so, it can now be marked as complete, cool
+11:28 < wsa_> when did you find that out?
+11:28 <@uli___> yesterday
+11:28 < wsa_> heh
+11:29 < wsa_> good, both tasks cleared, thanks!
+11:29 < wsa_> geertu: last but not least
+11:30 < geertu> A) Nothing
+11:30 < geertu> B) SPI slave prototype
+11:30 < geertu> C) Visteon reported a difference in behavior between hardware-assisted flow control and GPIO flow control. This may either be due to a bug in the sh-sci driver, or a bug in the serial core, or perhaps both. To be investigated... Cfr. the thread "[PATCH] sh-sci: fix transition from noflow to HW flow control".
+11:31 < wsa_> i made a new task out of the last one
+11:31 < geertu> OK
+11:31 < wsa_> SCIF,?,noplan,?,difference in behavior between hardware-assisted flow control and GPIO flow control
+11:32 < geertu> Thx!
+11:33 < wsa_> thanks geert, looking forward to the spi slave implementation
+11:33 < wsa_> any other news?
+11:33 < geertu> Not from my side
+11:34 < wsa_> then, thank you guys!
+11:35 < geertu> thx & bye
+11:35 < shimoda> thank you!
+11:35 < neg> thanks all
+11:35 < wsa_> have a great rest of the week!
+11:35 < morimoto> wsa_: I remembered that I'm asking SDHI datasheet to HW guys, It has 1) finding HW guys, 2) export paper work
+11:35 < khiemnguyen_> thx. bye. :)
+11:35 < morimoto> So, it will takes more time
+11:35 <@uli___> bye
+11:35 < morimoto> sorry for late
+11:40 -!- shimoda [~shimoda@relprex3.renesas.com] has quit Quit: WeeChat 0.4.2
+11:43 < wsa_> morimoto: it is not super urgent
+11:43 < wsa_> morimoto: we solved the current issue
+11:43 < wsa_> morimoto: but we never know if something else comes up
+11:44 < morimoto> Yes, anyway I will continue to asking
+11:44 < wsa_> thank you!
+11:44 < morimoto> np
+11:45 < wsa_> I am happy to invite my paper-work-hero for a curry-sausage in Berlin :D
+11:47 < morimoto> Hehehe :)
+11:48 < morimoto> I think he will be happy for it :)
+11:48 < morimoto> I will go there 10/3 - 10/14
+11:54 < wsa_> cool
+11:56 < wsa_> let's explore Berlin :D
+11:56 < wsa_> now gotta go
+11:56 < wsa_> cya!
+--- Log closed Thu Sep 01 11:56:42 2016