diff options
Diffstat (limited to 'wiki/Chat_log/20160921-io-chatlog')
| -rw-r--r-- | wiki/Chat_log/20160921-io-chatlog | 337 |
1 files changed, 337 insertions, 0 deletions
diff --git a/wiki/Chat_log/20160921-io-chatlog b/wiki/Chat_log/20160921-io-chatlog new file mode 100644 index 0000000..3b210f8 --- /dev/null +++ b/wiki/Chat_log/20160921-io-chatlog @@ -0,0 +1,337 @@ +--- Log opened Wed Sep 21 09:27:21 2016 +09:27 -!- wsa_ [~wsa@p5B384463.dip0.t-ipconnect.de] has joined #periperi-io +09:27 -!- Irssi: #periperi-io: Total of 4 nicks [0 ops, 0 halfops, 0 voices, 4 normal] +09:27 -!- Irssi: Join to #periperi-io was synced in 0 secs +09:27 < wsa_> hi guys! +09:29 < khiemnguyen_> hello +09:30 -!- shimoda [~shimoda@relprex3.renesas.com] has joined #periperi-io +09:30 -!- horms [~horms@217.111.208.18] has quit Quit: Leaving +09:30 -!- horms [~horms@217.111.208.18] has joined #periperi-io +09:31 -!- neg [~neg@unaffiliated/neg] has joined #periperi-io +09:32 < morimoto> hi +09:32 < neg> hello everyone +09:32 < shimoda> hi +09:33 < wsa_> morimoto: before we start, can you also keep an eye that either Magnus or you bring me a ZComex AC-180M SDIO card to Berlin? +09:34 < wsa_> I need it for an additional task +09:34 < wsa_> I think Shimoda-san used it for testing +09:35 < wsa_> I already asked Magnus. He recommended to ask you as well, so it will be less likely forgotten ;) +09:35 < morimoto> Magnus recommended to me ? +09:35 < morimoto> OK, will check +09:36 < morimoto> I will bring it to you on Berlin +09:36 < wsa_> well, if two people know about it, they can remind each other ;) +09:36 < wsa_> so, let's start +09:36 * wsa_ runs sort -R +09:37 -!- geertu [~geert@d54c189fd.access.telenet.be] has joined #periperi-io +09:37 < geertu> Hi +09:38 < wsa_> hi geert +09:38 < horms> nice to see you +09:38 < wsa_> shimoda: you won first place this time :) +09:39 < shimoda> yes +09:39 < shimoda> A) What have I done since last time: +09:39 < shimoda> - IPMMU issue on USB EHCI + Gen3. +09:39 < shimoda> B) What I plan to do till next time: +09:39 < shimoda> - IPMMU issue on USB EHCI + Gen3. +09:39 < shimoda> C) Problems I have currently: +09:39 < shimoda> - Nothing except the IPMMU issue. +09:39 < shimoda> i have trouble about the IPMMU :) +09:39 < shimoda> done +09:40 < wsa_> Yeah, that looks like a major one +09:40 < wsa_> any news from HW guys? +09:42 < wsa_> ah, i think you said last time that he didn't find anything +09:42 < shimoda> I got a little. but, they said it seems strorange behavior by usb EHCI hw. so, i would like to investigate EHCI SW or IPMMU HW/SW more +09:43 < wsa_> good luck with that!! +09:43 < wsa_> I am next +09:43 < wsa_> A) +09:43 < wsa_> added 8 bit eMMC bus width support for SDHI +09:43 < wsa_> tested SDR104 & enablement patches +09:43 < wsa_> worked on additional tasks and todo-lists +09:43 < wsa_> B) +09:43 < wsa_> organize meeting room in Berlin & IO meeting +09:43 < wsa_> some more SDR104 testing +09:43 < wsa_> start evaluating the BSP for IO patches +09:43 < wsa_> start playing with UHS SDIO cards +09:43 < wsa_> C) +09:43 < wsa_> (SDR104 is nasty) +09:43 < wsa_> c) is not really my part +09:43 < horms> I have an update on that +09:44 < wsa_> yeah, i read that :) +09:44 < horms> yes, SDR104 is a headache +09:45 < wsa_> but first morimoto +09:45 < horms> lets discuss it a bit later. either here of back on #periperi after this meeting +09:45 < wsa_> horms: sure +09:46 < wsa_> although, morimoto said he has nothing going for IO +09:46 < wsa_> khiemnguyen_: you are next +09:47 < wsa_> how is your load? do you have more time for upstreaming again? +09:47 < khiemnguyen_> wsa_: I have time for upstream, I think. +09:47 < khiemnguyen_> a) Sent updated patches for R-Car Gen3 Thermal +09:48 < khiemnguyen_> Got review from Morimoto-san and Geert. +09:48 < khiemnguyen_> Still, some comments have not been fixed yet. And failed to catch v4.9. +09:48 < khiemnguyen_> b) Continue R-Car Gen3 Thermal. It will be available before ELCE, I believe. +09:48 < khiemnguyen_> c) Still try to solve issue of my email account. Trying to use git-send-emails instead of MS Outlook email client. +09:48 < khiemnguyen_> that's all. +09:49 < wsa_> good news. i updated the todo and upstreaming thermal is now scheduled for v4.10 +09:49 < khiemnguyen_> wsa_: thanks +09:49 < morimoto> this is out-of-IO-topics. horms: can you update peripelist ? +09:50 < wsa_> good luck and I hope you can get git-send-email to run. will be much more convenient! +09:50 < wsa_> horms: you are next anyhow ;) +09:50 < horms> morimoto: I am confused. What would you like me to update? +09:50 < horms> --- start --- +09:51 < horms> A) What have I done since last time: +09:51 < horms> - Posted updated SDR104 Driver patches +09:51 < horms> - Posted updated SDR50/SDR104 enablement patches +09:51 < horms> - merged non-SDR104 portions +09:51 < horms> - Support patches for pfc, gpio, clks have been merged +09:51 < horms> B) What I plan to do till next time: +09:51 < horms> - Continue working on "Samsung SDR104 initialisation problem" +09:51 < horms> - Locally I seem to have a stack that resolves this problem, +09:51 < horms> I need to: +09:51 < horms> + Verify this and if it is so +09:51 < horms> + clean it up and isolate what needs to go upstream. +09:51 < horms> - Investigate why SDR50 can't be initialised on Gose SDHI1 +09:51 < horms> C) Problems I have currently: +09:51 < horms> - SDR headaches, see B) +09:51 < horms> --- end --- +09:51 < morimoto> horms: can you check email from me ? +09:51 < morimoto> Subject: Re: [periperi] PeriPelist fixup request 2016-09-13 for integration/upport +09:51 < morimoto> Date: Tue, 13 Sep 2016 01:54:57 +0000 +09:51 < morimoto> +09:52 < horms> sure, i will look at that +09:52 < wsa_> horms: yeah, let's talk about the technical details after this meeting here? +09:52 < horms> good plan +09:52 < wsa_> and maybe about Gose, this is a new issue, or? +09:53 < wsa_> I can't recall it at least +09:54 < geertu> Perhaps SDHI is wired differently on Gose? +09:54 < horms> i think we can regard it as a minor issue +09:54 < horms> its not so new to me +09:54 < geertu> We don't seem to have schematics... +09:54 < horms> but i may not have raised it to you before +09:54 < horms> I believe I do have them +09:54 < horms> The problem is that SDR%0 is not initialised on SDHI1 +09:54 < horms> I had magnus move the card to SDHI2 and it seems fine there +09:55 < horms> I think it is most likely there is an error in the code somewhere +09:55 < morimoto> geertu: I will send Gose schematics soon +09:55 < morimoto> It is under export paper work +09:55 < horms> Also, I wasn't entirely sure on some of the GPIOs, so a second pair of eyes on the schematic would help +09:55 < geertu> horms: it's not due to some silly SDHIx naming issue? Indices are different on H2 and M2-W. +09:55 < geertu> IIRC, we did it slightly different on M2-N? +09:55 < horms> I am aware of that +09:56 < horms> no I don't think that is the problem here +09:56 < geertu> morimoto: Thank you +09:56 < horms> the documentation is a little inconsistent with its usage of sd1/sd2 +09:56 < horms> but I think its clear enough given some context +09:57 < wsa_> ok? +09:58 < horms> I'm ok +09:58 < wsa_> good :) +09:58 < wsa_> neg: I know you don't have anyhthing IO related, but can you tell me if you have time for base task assignments in the near future? +09:59 < neg> I think I should have time for that +09:59 < neg> I do not yet have a base contract for Q4 but other than that it should be fine :-) +09:59 < wsa_> same here:D +10:00 < wsa_> ok, so then let's move on to Geert +10:00 < neg> any particular task you think I should get started on? +10:00 < wsa_> neg: I'll ask Geert in a second ;) +10:01 < wsa_> geertu: your turn +10:01 < geertu> A) What have I done since last time: - SPI slave support v2, http://elinux.org/Tests:MSIOF-SPI-Slave +10:01 < wsa_> (let's see if the alerting for irssi I sent him recently works ;)) +10:01 < geertu> B) What I plan to do till next time: +10:01 < geertu> - No I/O tasks scheduled, but core 64-bit Memory and Ethernet without +10:01 < geertu> Bounce Buffers Prototype, +10:01 < geertu> - Awaiting SPI slave feedback, +10:01 < geertu> - Verify MSIOF SPI functionality on M3-W, if time permits. +10:01 < geertu> C) Problems I have currently: - Nothing I/O related. +10:02 < geertu> First SPI slave feedback is from RobH, who seem to want to revert partly to v1, while I made the changes due to his request ;-) +10:02 < wsa_> heh +10:03 < wsa_> this task: +10:03 < wsa_> SCIF,?,noplan,?,difference in behavior between hardware-assisted flow control and GPIO flow control # Cfr. the thread "[PATCH] sh-sci: fix transition from noflow to HW flow control" +10:03 < wsa_> do you think this could be a investigation suited for a base task +10:03 < wsa_> or is it rather an additional task on its own? +10:03 < geertu> Perhaps I can look into that in the context of the (not yet confirmed) base task +10:04 < wsa_> if you have time... +10:04 < wsa_> ... this is the one where I wondered if neg could have a look if he had interest. +10:04 < geertu> I think it's to be investigated first, whether it's a bug in the driver, on in the serial core. +10:05 -!- horms [~horms@217.111.208.18] has quit Read error: Connection reset by peer +10:05 < geertu> s/on/or/ +10:05 -!- horms [~horms@217.111.208.18] has joined #periperi-io +10:06 < geertu> I have a hardware setup to test it, so perhaps I should just fine some time to bite the bullet +10:06 < geertu> s/fine/find/ +10:06 < wsa_> i see +10:06 < wsa_> makes sense +10:08 < wsa_> i think we are done now? +10:08 < wsa_> anything from you? +10:08 < wsa_> next meeting will be in Berlin +10:09 < wsa_> if you have topics for that please let me know +10:09 < wsa_> additional tasks will be an obvious one +10:10 < horms> Have we fixed the meeting schedule for Berlin? +10:10 < wsa_> i think so +10:11 < horms> Excellent +10:11 < wsa_> now that the core group decided to have their meeting in two parts... +10:11 < horms> I want to be sure to be there at the right time :) +10:11 < horms> Shall we talk SDR? +10:11 < wsa_> yes, I am very curious on that topic +10:12 < wsa_> but before +10:12 < wsa_> Thanks guys for the meeting! +10:12 < wsa_> Have a safe trip to Berlin! +10:12 < neg> thanks all +10:12 < khiemnguyen_> Please take a photo, as well. +10:13 < morimoto> thanks. +10:13 < shimoda> thanks. +10:13 < geertu> Has anyone found the big group photo taken at the closing of LCJ? +10:13 < horms> thanks +10:14 < morimoto> geertu: like this one ? +10:14 < morimoto> https://osdr.renesas.com/projects/linux-kernel-development/wiki/Miniperi-2016-07 +10:14 < khiemnguyen_> geertu: https://osdr.renesas.com/projects/linux-kernel-development/wiki/Miniperi-2016-07 +10:15 < morimoto> It is shrink version, I have original photo +10:15 < geertu> morimoto: No, the big one with +100 persons +10:15 < morimoto> Ahh, I don't have it. +10:16 < horms> wsa_: I think I am making some progress on the "Samsung problem" +10:16 < horms> as I mentioned in my email +10:16 < horms> but there have been so many false dawns on sdr104 I'd rather not push out v8 in a hurry, even though v4.9 is closing soon +10:17 < horms> what I was hoping was to get something clean toghether in the next day or so for you to test. +10:17 < wsa_> morimoto: haha, haven't seen those pictures before +10:17 < horms> or alternatively find out its not working after all (not unlikely given my experiences so far) +10:18 < wsa_> horms: yes, I agree we should test more internally before sending out a new version +10:18 < wsa_> horms: I'd also test unclean stuff ;) just to see if I can reproduce your findings +10:18 < horms> I at least have physical access to a system where I can reprocuce the current problem (The Samsung one) +10:18 < wsa_> anyway, I'm happy that you at least have a pointer +10:19 < horms> thanks, I'll see if I can get something semi-clean together +10:19 < horms> there is quite a bit of noise in my current stack +10:19 < wsa_> any high-level description of the suspect? +10:19 < horms> but one thing that stood out was the NO_SLEEP handling in the BSP +10:19 < horms> which skips sleeping for 10ms on GEN3 +10:20 < horms> Assuming we need such a thing, which at this point seems likely +10:20 < horms> I wonder how it should be handled +10:20 < horms> * Using a NO_SLEEP cap as per the BSP +10:20 < horms> * Using a (new) GEN3 cap (like the GEN2 cap in mainline - which is actually GEN2/3) +10:20 < horms> * Some other way +10:21 < wsa_> NO_SLEEP? gotta check +10:22 < horms> I also noticed that SH_MOBILE_SDHI_SCC_RVSCNTL_RVSEN should be BIT(0) rather than BIT(1). Which clearly should be fixed. But its not clear if it relates to the problem under discussion. +10:22 < horms> I also flagged the following as interesting but have not yet been able to confirm if they related to the problem in question: +10:23 < horms> * mmc: tmio: Add SDCLK enable after reset +10:24 < horms> * clk: renesas: rcar-gen3: Replace SD divider setting +10:24 < horms> From the BSP +10:24 < horms> The first patch seems like a mainline candidate +10:24 < horms> the second I am rather unsure about +10:25 < horms> Other than that my strategy has been to try to reduce differences between the BSP and mainline+sdr topic branch. +10:25 < horms> That seems to be working, I need to work out which of those changes, which are rather verbose, are of consequence +10:25 < wsa_> that's what I did to fix 8 bit eMMC support as well +10:25 < horms> thats the bit I'D like to clean up a bit +10:25 < horms> really its too noisy to give you right now +10:26 < wsa_> I think we have the same NO_SLEEP behaviour upstream as in the BSP? +10:26 < wsa_> that was at least my intention, let me double check +10:26 < horms> It didn't seem to be in the branch I was working against +10:26 < horms> I did see some differentiation between GEN2 and non-GEN2 for one of the timeouts +10:26 < horms> but nothing for others +10:27 < wsa_> bsp does: +10:27 < wsa_> 172 if (!(host->pdata->flags & TMIO_MMC_CLK_NO_SLEEP)) +10:27 < wsa_> 173 msleep(10); +10:28 < wsa_> upstream does +10:28 < wsa_> 160 msleep(host->pdata->flags & TMIO_MMC_MIN_RCAR2 ? 1 : 10); +10:28 < horms> ok, but the BSP does it in several places +10:28 < wsa_> so, the timeout is reduced from 10 to 1 ms +10:29 < wsa_> and bsp for gen3 does 0 +10:29 < horms> in any case, i can do some more testing of this +10:30 < horms> btw, which samsung card do you have. I have a "Pro+" 32Gb. I can look up the product id if you like. +10:31 < wsa_> let me check +10:33 < wsa_> it is labelled "32 pro" +10:33 < horms> http://www.samsung.com/de/consumer/memory-storage/memory-storage/memory-cards/MB-SD32D/EU +10:33 < horms> Is it grey and white? +10:34 < horms> A bit like this? https://www.amazon.co.jp/Samsung-SDXC%E3%82%AB%E3%83%BC%E3%83%89-SAMSUNG-Class10-%E6%9C%80%E5%A4%A7%E8%AA%AD%E5%87%BA%E9%80%9F%E5%BA%A690MB/dp/B019FKR6QQ +10:35 < wsa_> so, no "+" for me +10:35 < wsa_> http://www.samsung.com/de/consumer/memory-storage/memory-storage/memory-cards/MB-MG32E/EU +10:35 < wsa_> it is grey and white +10:35 < horms> Ok +10:35 < horms> I have some of them in Japan +10:36 < horms> I thought I sent one to my new home too, but I can't locate it +10:36 < horms> I noticed these things seem to be much more expsnsive here than in Japan +10:36 < horms> I might just post some to myself :) +10:37 < horms> But I digress +10:37 < horms> its good to know you have a different card +10:37 < horms> but I think for now we are seeing the same problem +10:37 < wsa_> so, the gen2 bsp does not use msleep as well +10:38 < wsa_> i decided to use 1 ms because the datasheet has +10:38 < wsa_> "After waiting for at least 1 ms since the SD clock supply was started , check that the DAT0 bit in +10:38 < wsa_> SD_INFO2 is 1." +10:38 < wsa_> in the Gen2 docs +10:38 < wsa_> checking gen3 docs +10:39 < horms> I just noticed that the NO_SLEEP change was added to the Gen3 BSP specifically for r8a7795 support (presumably r8a7796 was not on the todo list at the time) +10:39 < horms> Possibly 1ms is ok, possibly it is not +10:39 < horms> Lets try to get some sort of semi clean patch stack together that wrosk +10:39 < horms> works +10:39 < wsa_> yeah +10:39 < horms> and then we can invistigate this in more depth +10:40 < wsa_> but it is nice to know that this is a difference to the BSP +10:40 < wsa_> I wasn't aware of that +10:40 < horms> at this point I think we may have several issues to discuss +10:40 < wsa_> unlike this patch I am aware of: +10:41 < wsa_> mmc: tmio: Add SDCLK enable after reset +10:41 < horms> What is your thoguths on that one? +10:41 < horms> What are your thoughts on that one? +10:41 < wsa_> but I haven't seen making any difference on any issue I have seen so far +10:41 < wsa_> I don't know if this a angst-patch or a real one +10:41 < morimoto> bye +10:41 -!- morimoto [~user@relprex2.renesas.com] has left #periperi-io ["ERC Version 5.3 (IRC client for Emacs)"] +10:42 < wsa_> it is a good candidate to tell about the importance of commit messages +10:42 < wsa_> "not so much what but especially why" +10:43 < horms> ok +10:43 < horms> we/I can raise this with the bsp team +10:43 < horms> I'll check if it helps or not +10:43 < horms> it is in my stack at the moment +10:44 < horms> possibly we would get better commit messages if there was a policy to allow them to be partially in Japanese +10:44 < horms> but that could also backfire +10:45 < wsa_> stuff like +10:45 < wsa_> "fixes customer issue" vs "is more correct" already helps IMO +10:45 < horms> Ok, so this actually relates to the upporting tasks +10:45 < wsa_> or "do as described in docs" +10:45 < horms> which Magnus was discussing with us +10:46 < wsa_> yes +10:46 < horms> We could produce some guidelines to help get better information +10:46 < horms> probably part of the problem is who is the audience for the changelog +10:46 < horms> * The BSP team? +10:46 < horms> * The upstream team? +10:46 < horms> * Mainline iself? +10:46 < horms> * Customers? +10:47 < horms> * Other? +10:47 < horms> I would be interesting to see what the intended audience is: if any +10:47 < horms> but i think regardless it would be good to provide some guidance +10:47 < shimoda> sorry, time to go. bye! +10:47 -!- shimoda [~shimoda@relprex3.renesas.com] has quit Quit: WeeChat 0.4.2 +10:47 < wsa_> I dunno about customers, but BSP team and upporting team for sure +10:48 < wsa_> mainline not so much +10:48 < horms> I think they are the most important +10:48 < wsa_> I'd say +10:48 < wsa_> but for all of the groups, I'd think the "why" is pretty important +10:49 < horms> true +10:49 < wsa_> and the patch we just mentioned is a good example for that +10:49 < horms> ok +10:49 < horms> I think we can query specific patches by contactng their author +10:50 < horms> but in terms of a general request I'd shy away from specific examples: we don't want anyone in the BSP team to give less information for fear or being made an example of +10:50 < wsa_> i agree +10:50 < geertu> The "why" is very important. For several commits in the BSP, I'm completely puzzled by the rationale behind them. +10:50 < horms> i agree +10:51 < wsa_> luckily, it is pretty easy to cook an artifical example +10:51 -!- uli___ [~uli@gateway/vpn/privateinternetaccess/uli/x-17929268] has joined #periperi-io +10:51 < horms> So how about I try to bring this up with the BSP team at the meeting they invite me to sometimes. +10:51 < wsa_> hi uli___ +10:51 < uli___> hello +10:51 < wsa_> got internet again? :) +10:51 < uli___> figured out why my desktop keeps locking up +10:51 < uli___> turns out you can't turn off displayport devices in linux... +10:52 < uli___> switched to dvi -> works +10:52 < horms> good to know +10:52 < wsa_> horms: gotta run now +10:53 < horms> likewise +10:53 < wsa_> looking forward to your semi-cleaned up stack +10:53 < horms> thanks for your time +10:53 < wsa_> to test +10:53 < wsa_> you're welcome +10:53 < horms> i'll get that too you in the coming days: or some disapointed email explaining that its not working +10:53 < wsa_> oh, and I'll bring all my cards to Berlin, of course +10:53 < horms> oh. great +10:53 < wsa_> Magnus shall do the same +10:54 < wsa_> so, cya all! +10:54 < horms> bye +10:55 < uli___> bye +10:57 < wsa_> uli___: BTW can you respin the MSIOF chipselect patch? +10:58 < uli___> yes, that's on the todo +10:58 -!- horms [~horms@217.111.208.18] has quit Ping timeout: 244 seconds +11:05 < wsa_> cool +--- Log closed Wed Sep 21 11:05:52 2016 |