From 55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Mon, 9 Dec 2019 15:29:52 +0900 Subject: wiki: Porting wiki: Porting Chat Log Signed-off-by: Kuninori Morimoto --- wiki/Chat_log/20180215-io-chatlog | 93 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 wiki/Chat_log/20180215-io-chatlog (limited to 'wiki/Chat_log/20180215-io-chatlog') diff --git a/wiki/Chat_log/20180215-io-chatlog b/wiki/Chat_log/20180215-io-chatlog new file mode 100644 index 0000000..ab4a855 --- /dev/null +++ b/wiki/Chat_log/20180215-io-chatlog @@ -0,0 +1,93 @@ +09:04 < wsa_> so, let's start the IO meeting +09:05 < wsa_> welcome everyone +09:05 < wsa_> let's start with the summary: +09:05 < wsa_> A) +09:05 < wsa_> Simon posted a new version of the HS400 patches addressing review comments and +09:05 < wsa_> started the virt+network task. Niklas sent out the first patch for variable +09:05 < wsa_> MTU size for RAVB. Shimoda-san got various USB-related bugfixes merged in +09:05 < wsa_> upstream. Ulrich fixed a SCIF lockup and converted the SCIF driver to use HR +09:05 < wsa_> timers. Wolfram reviewed a ton of patches all around, discussed some watchdog +09:05 < wsa_> isses, made preparations for OSS+AGLJ, got the IP core switcher series merged, and +09:05 < wsa_> worked on virt tasks, generic one and I2C specific one. +09:05 < wsa_> B) +09:05 < wsa_> Simon wants to look at the CLK changes needed for HS400 and will continue with +09:05 < wsa_> the virt task. Niklas wants to send out V2 of RAVB-MTU size patch and, if time +09:05 < wsa_> permits, look into his previous SDHI hack. Shimoda-san wants to work on USB3.0 +09:05 < wsa_> role swap, USBPHY GPIO support, M3-N USB enablement and the virt task. Ulricht +09:05 < wsa_> will send out patches to the solutions of the above SCIF tasks. Wolfram will +09:05 < wsa_> finish the IO virt task today and fully move to the virt+I2C task, continue +09:05 < wsa_> reviewing stuff, submit the talk proposal for AGL, keep at the watchdog issues, +09:05 < wsa_> and plans to talk with Kieran about reprogrammed I2C addresses. +09:05 < wsa_> C) +09:05 < wsa_> Geert noticed eMMC problems on resume. Simon needs a SDR104 card in the Porter +09:05 < wsa_> board of Magnus' farm. +09:05 < wsa_> Please check if I misunderstood something. And fire away questions if you have. +09:06 < wsa_> I have one +09:06 < wsa_> geertu: which branch showed the eMMC problem? linus or ren-drivers? +09:06 < geertu> wsa_: That was my dev branch, based on renesas-drivers. +09:07 < geertu> Haven't tried it on anything else. +09:07 < geertu> I recently started using the eMMC for native compilation of QEMU, as it's much faster than nfsroot +09:07 < wsa_> oh, and anothso, with HS400? +09:07 < geertu> Hence I don't know if it happened before. +09:07 < wsa_> with HS400? +09:08 < geertu> I guess you have experience with mounted SD cards and s2idle/s2ram? +09:08 < geertu> No HS400, AFAIK +09:08 < wsa_> Simon once reported suspend&resume problems with SDHI, too +09:08 < wsa_> don't recall the details anymore +09:09 < wsa_> there was never time to look into it :( +09:09 < wsa_> i'll boost priority on this one a bit +09:10 < wsa_> neg: what about the hack to increase the MTU size beyond 2k? Not tried or didn't work? +09:10 < geertu> I can do some more tests, after reporting +09:10 < wsa_> geertu: Thanks, much appreciated! +09:11 < wsa_> geertu: and doing native compiles, you would probably also like the HS400 patches :) +09:11 < horms> wsa_: those s2ram/sdhi problems were a long time ago +09:11 < neg> wsa_: it did not work out as I planed :-( Not sure if it can be done, not given up entierly on it, but won't presue it in the near future. Shimoda-san told me of this HW limitation at the beginning of the task but I tought I could break it :-) +09:11 < horms> I think they have been resolved though I don't recall how +09:12 < horms> On the porter/sdr104 front, there is a card present, but I think its in the wrong slot (not all slots support that speed) +09:13 < wsa_> neg: yeah, that's understandable. Well, maybe somewhen... +09:14 < wsa_> horms: that should be easily fixable ;) +09:14 < horms> yes, its not a large problem +09:14 < horms> nor an urgent one +09:14 < horms> my larger problem is the clk patch for HS400. I think you and I need to talk about that some time. +09:15 < wsa_> yes, we can do that +09:15 < horms> I suspect you have a different eMMC chip on hour H3 ES1.0 board +09:15 < wsa_> somewhen next week +09:15 < horms> sure, lets schedule a time (some time) +09:15 < wsa_> I can't check right now, but I recall something like this, yes +09:15 < horms> ok, i guess you need to go home first +09:15 < horms> let me know when the timing is good for you +09:16 < wsa_> monday should be good +09:16 < geertu> wsa_: How long before the eMMC will wear out? +09:17 < horms> ok, i should be around on monday. but if you want to schedule a time let me know +09:17 < horms> geertu: just before we confirm the bug fix +09:17 < wsa_> horms: let's try the ad-hoc method, I'd say +09:17 < horms> ok, sur +09:18 < horms> in general mornings are better for me, say from 9 to noon +09:18 < wsa_> geertu: so, tried to wear out a 64MB SD card once because I wanted to check if SDHI catches such errors well. +09:18 < horms> but mondays are pretty good in general +09:18 < wsa_> I wrote continously for days while hacking, no luck +09:19 < wsa_> but maybe that card was not MLC +09:20 < wsa_> so, do you guys have questions? +09:20 < wsa_> I am done, I think +09:21 < wsa_> JapaPERI is happy, too? +09:22 < shimoda> yes, but i cannot catch up the emmc issue though :) +09:23 < horms> shimoda: issue is that hs400 is working fine for me. but it involves patches that wsa_ has had trouble with before. next step if for wsa_ to verify the current patchset in his environment, then discuss +09:24 < horms> It seems likely his H3 1.0 and mine have different eMMC chips. but we should test before speculating more +09:25 < shimoda> horms: thanks! and geertu has other issue (doesn't work after resume) +09:27 < kbingham> wsa_: I'm happy to talk I2C addreses whenever you're free +09:27 < shimoda> about H3 1.0, i think it is very bad chip about clock thing +09:27 < kbingham> :) +09:27 < wsa_> kbingham: nice, we will see when. hopefully next week, but no promise yet +09:27 < kbingham> wsa_: Ack :) +09:28 < horms> shimoda: ok. so some boards have a chip that works badly with the clk fix? that would explain things +09:28 < horms> do you know which chip? +09:29 < wsa_> or maybe it is because some clks are running only at 50%? +09:29 < wsa_> we need to check, but keep in mind that ES1.0 is special regarding to clocks +09:30 < geertu> Yes, it has completely different handling for SD clocks, IIRC +09:31 < geertu> You may need to measure the actual clock signals... +09:31 < wsa_> heh +09:31 < horms> I suggest we take this offline and move onto Core +09:31 < wsa_> we will come back to this once I am back home +09:31 < wsa_> agreed +09:32 < wsa_> thanks for the meeting! +09:32 < wsa_> geertu: the stage is yours -- cgit v1.2.3