diff options
author | Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> | 2019-12-09 15:29:52 +0900 |
---|---|---|
committer | Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> | 2019-12-09 16:23:07 +0900 |
commit | 55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce (patch) | |
tree | 6392fd201a51ff0f6dc0e474803e6f3b20919504 /wiki/Chat_log/20160901-io-chatlog | |
parent | 5d9e1b983faf7645ddc3d45d28e612d2ac4179c0 (diff) |
wiki: Porting wiki: Porting Chat Log
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Diffstat (limited to 'wiki/Chat_log/20160901-io-chatlog')
-rw-r--r-- | wiki/Chat_log/20160901-io-chatlog | 371 |
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 |