renesas/periject.git - Renesas periject clone

diff options

author	Geert Uytterhoeven <geert+renesas@glider.be>	2021-03-01 11:56:56 +0100
committer	Geert Uytterhoeven <geert+renesas@glider.be>	2021-03-01 11:56:56 +0100
commit	19f33b56daa885c77142f03c72a698f6294e74b3 (patch)
tree	9ea0c39d129f99b2eaeed3cc1ffb1ddd51dfd580 /wiki/Chat_log/20200227-core-chatlog
parent	b988ed4c6507ef51c7e070d49f2eb3497edd89d5 (diff)

Auto-update sweep for v5.12-rc1

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Diffstat (limited to 'wiki/Chat_log/20200227-core-chatlog')

0 files changed, 0 insertions, 0 deletions

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


context:
space:
mode: