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