path: root/wiki/Chat_log/20160901-io-chatlog

--- 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