path: root/wiki/Chat_log/20150804-io-chatlog

--- Log opened Tue Aug 04 10:42:04 2015
10:42 -!- wsa_ [~wsa@p4FE2576E.dip0.t-ipconnect.de] has joined #periperi
10:42 -!- Irssi: #periperi: Total of 4 nicks [0 ops, 0 halfops, 0 voices, 4 normal]
10:42 -!- Irssi: Join to #periperi was synced in 1 secs
10:43 < wsa_> konnichi wa
10:45 < morimoto> konnichi wa
10:46 < wsa_> hiya morimoto-san
10:46 < wsa_> how is copy/pasting windows code? ;)
10:47 < morimoto> Hehe :) it works very well for me (at this point)
10:48 -!- shimoda [~shimoda@relprex1.renesas.com] has joined #periperi
10:48 < wsa_> hello shimoda-san
10:48 < shimoda> hello wolfram-san!
10:49 -!- geertu [~geert@188.188.25.36] has joined #periperi
10:50 < geertu> Woops, I lost all networking (Internet/TV) at home ca, 30 minutes ago.
10:51 < geertu> Back online through 3G and Wifi-hotspot, but 3G coverage inside the house is really bad (and too much rain outside)
10:51 < wsa_> hi geert
10:52 < wsa_> i'll send some of the sunshine here towards you
10:52 < geertu> thx!
10:52 < geertu> Don't forget to keep some sunshine for your holidays next week ;-)
10:52 < wsa_> (and the plants could need a bit of rain, too)
10:52 < wsa_> :)
10:53 < wsa_> luckily, i am not so weather-dependent
10:53 < wsa_> the area is nice in any case
10:56 < morimoto> In these days, Japan is super very hot days. you can bring it
10:57 < geertu> yesterday it was super very hot in Belgium too.
10:57 < geertu> Today it's 10 degrees colder, and rainy
10:57 < wsa_> 33 degrees here, today
10:58 < morimoto> not so different ? Japan-Tokyo is 34 - 35 degrees
10:59 < wsa_> but probably a lot more humid
10:59 < morimoto> YES !!
10:59 < wsa_> :)))
10:59 < geertu> yeah... but not sufficiently humid to enjoy it (-> swimming pool)
11:00 -!- horms [~horms@121-80-222-183f1.hyg1.eonet.ne.jp] has joined #periperi
11:00 < wsa_> hello simon
11:00 < horms> wsa_: are we having an I/O group meeting about now?
11:00 < wsa_> yes, you got perfect timing
11:00 -!- geertu_ [~geert@d54C15D57.access.telenet.be] has joined #periperi
11:01 < horms> excellent
11:01 < wsa_> geert has lagging problems?
11:02 < geertu> Yeah, dah Internet is back
11:02  * geertu switches back to broadband
11:02 -!- geertu [~geert@188.188.25.36] has quit Quit: leaving
11:02 < wsa_> \o/
11:02 < geertu_> hi
11:02 -!- geertu_ is now known as geertu
11:03 < wsa_> so, i guess we can start now
11:03 < geertu> Doh, and the 3G just managed to pull in drm/du/vsp1-kms...
11:03 < wsa_> thanks for coming to this very first IO Group IRC Chat Meeting
11:03 < wsa_> let's make history!
11:03 < wsa_> ahem
11:03 < wsa_> :)
11:04 < wsa_> the topics and order i'd propose are:
11:04 < wsa_> 1) Needed steps for Gen3 (should be easily dealt with)
11:05 < wsa_> 2) status of SCIF (DMA...)
11:05 < wsa_> 3) discuss the current list of tasks
11:05 < wsa_> the last one will probably evolve into questions like "tracking the BSP" and "reproducing issues"
11:06 < geertu> git log
11:06  * geertu sorry wrong window
11:06 < wsa_> any comments to that? any additions?
11:06 < horms> I have one more, small item: scif patches in Rcar-Gen2 BSP 1.9.5
11:07 < horms> if we have time
11:07 < geertu> Doesn't that fall under 2)?
11:07 < horms> probably :)
11:07 < wsa_> I'd think so, too
11:07 < horms> ok, that is fine by me
11:08 < wsa_> so, let's start with 1)
11:09 < wsa_> by mail, shimoda-san said that I2C enablement patches for Gen3 are needed, prototypes will do
11:09 < wsa_> I can do this before I go on vacation
11:09 < morimoto> very good !
11:09 < wsa_> the cores have additions, but should be (tm) backwards compatible
11:09 < horms> ok, iirc that was around the 11th
11:10 < wsa_> it will be a matter of adding compatibles, I can do this today
11:10 < horms> ok, sounds good from my pv
11:11 < horms> ok, sounds good from my pov
11:11 < wsa_> anything else for Gen3?
11:11 < wsa_> some news since yesterday? :)
11:11 < shimoda> about etheravb
11:11 < shimoda> it needs until 25th august
11:12 < shimoda> yesterday?
11:13 < horms> is driver work required for etheravb, over what is queued up for v4.3 in net-next
11:13 < horms> ?
11:13 < wsa_> shimoda: sorry, not yesterday, but since your mail
11:14 < morimoto> horms: do you mean for Gen3 BSP ?
11:14 < horms> yes
11:14 < wsa_> horms: have you checked the Gen3 docs if EtherAVB is the same as Gen2?
11:15 < horms> wsa_: ah, not as much as i should have
11:15 < horms> is that an ai for me?
11:15 < wsa_> can you do this please?
11:15 < horms> sure
11:16 < morimoto> for BSP, we need EtherAVB but no one is listed inhouse Renesas.
11:16 < horms> ok, i guess it defaults to cogent
11:17 < wsa_> still, will be nice to know if the IP cores are the same or how they differ
11:17 < morimoto> I guess integration is not a big deal (if it has compatible)
11:17 < horms> wsa_: agreed
11:17 < morimoto> If it needs driver update, then Cogent ?
11:18 < horms> morimoto: I don't know. But they have handled the driver so far.
11:18 < morimoto> yes
11:18 < wsa_> hmmm, who knows this answer?
11:18 < horms> If we have to rely on Cogent for driver updates for the Gen3 BSP then I think we have a problem
11:19 < horms> wsa_: probably Munakata-san, but my feeling is it would be best to talk to Magnus.
11:19 < wsa_> okay
11:19 < horms> in any case, i don't think we can resolve it here
11:20 < wsa_> yes
11:20 < wsa_> I'd think, let's check the IP cores, find out responsibilities and let's see from there...
11:20 < shimoda> at the moment, bsp team is debugging etheravb
11:20 < horms> good plan
11:21 < horms> shimoda: on gen2 hw?
11:21 < wsa_> shimoda: gen2 or gen3?
11:21 < wsa_> :D
11:21 < shimoda> sorry, on gen3
11:22 < wsa_> so, it might even be a moving target
11:22 < shimoda> according to his email, gen3 needs some additional setting in avb and phy
11:23 < shimoda> so, for upstreaming, we need his help
11:23 < horms> komatsu-san?
11:24 < shimoda> His name is Nagai-san, sometimes he sent email to net ML
11:24 < horms> oh ok
11:25 < horms> should I/we talk to him?
11:25 < horms> He may be aware of some issues that are outside of what is described in the documentation we have
11:26 < shimoda> yes, i\I will talk to him about gen3 avb
11:26 < horms> excellent, thanks
11:26 < wsa_> thank you
11:26 < wsa_> i will talk to magnus about the responsibility
11:27 < wsa_> and simon will have a look at the docs
11:27 < wsa_> so, last call for Gen3 topics
11:28 < morimoto> 1 question about I2C
11:28 < morimoto> I guess Gen3 has 2 type of I2C ?
11:28 < wsa_> yes, 7x I2C and 1x IIC
11:28 < morimoto> which I2C do you enable before your vacation ?
11:29 < wsa_> both
11:29 < morimoto> Cool !! Thanks
11:29 < wsa_> it is just compatibles
11:29 < wsa_> :)
11:29 < shimoda> for gen3, we need some code of "SPI" until 1st Sept.
11:30 < shimoda> maybe MSIOF
11:30 < geertu> The real MSIOF or the "slave-only" MSIOF?
11:30 < shimoda> it is the real MSIOF
11:32 < geertu> (from "Gen3 work") MSIOF: Looks identical to Gen2
11:32 < geertu> (from "Gen3 work" email) MSIOF: Looks identical to Gen2
11:32 < wsa_> okay, so another compatible update
11:32 < wsa_> geert: can you do this till Sep, 1st? ;)
11:32 < geertu> RPC (2x QSPI) needs a new driver
11:32 < geertu> Sure, but currently I cannot test it
11:33 < wsa_> i know
11:33 < wsa_> let's see how the hardware status is 3 weeks
11:34 < wsa_> if there is no HW, then we do the prototypes again
11:34 < wsa_> OK, I'd like to move on to the next topic
11:34 < horms> i would guess it wiil be similar to now :^)
11:35 < wsa_> i wouldn't bet much against it ;)
11:35 < geertu> I guess they will produce hardware during the Renesas Summer Holiday Week?
11:35  * geertu wonders if that needs a smiley or not...
11:35 < morimoto> In our plan we will have 1 H3 board tomorrow
11:35 < wsa_> so, SCIF
11:36 < geertu> Great!
11:36 < morimoto> and Magnus will setup it on his remote access machine
11:36 < wsa_> WOW!
11:36 < geertu> Great! (x2)
11:36 < morimoto> (If we can have board)
11:36 < shimoda> sorry, about RPC, I'm not sure but BSP team doesn't support it because secure
11:36 < geertu> Just before I left for holidays, I posted a big patch series for SCIF DMA
11:37 < wsa_> (so, I will wait a few days before posting the I2C Gen3 patches, maybe i can test after all)
11:37 < geertu> It's sort of working now
11:37 < geertu> But it needs more rework and cleanup
11:37 < horms> excellent
11:37 < wsa_> great
11:37 < morimoto> cool
11:37 < horms> I believe the state of scif in the gen2 BSP is a point of concern
11:38 < wsa_> does the rework need DMA framework changes?
11:38 < geertu> I think half of the patches in that series can be sent out for integration, but I didn't have time to do the split when I sent the whole series.
11:38 < geertu> Good question!
11:39 < geertu> It relies on "modern" residu handling, which the shdmac driver doesn't provide (do we care? I posted an RFC patch)
11:40 < geertu> And I had to change the SCIF driver to not resubmit DMA descriptors, as rcar-dmac doesn't support that
11:40 < geertu> Still waiting for Laurent's response to my rcar-dmac emails...
11:40 < horms> which hardware do we use shdma on?
11:41 < geertu> "sh-dma-engine" (sh, legacy shmobile)
11:41 < geertu> "renesas,shdma-r8a73a4" (r8a73a4)
11:41 < geertu> "hpb-dma-engine" (legacy r8a777x)
11:41 < geertu> "sudmac" (unused, referred to by r8a66597_udc on ecovec24/kfr2r09/se)
11:42 < geertu> That was the long answer
11:42 < horms> ok
11:42 < geertu> The short answer is: nothing that uses DT and multi-platform
11:42 < horms> so my feeling is that if we aren't using it on multiplatform gen2 (or 3) then its not so important
11:42 < geertu> "renesas,shdma-r8a73a4" is not really used
11:43 < wsa_> does the BSP use rcar-dmac meanwhile?
11:43 < horms> good question
11:43 < horms> they are using multiplatform (i believe)
11:43 < horms> and they only care about gen2
11:43 < horms> so it seems likely
11:43 < horms> but i don't know for sure
11:44 < geertu> renesas-backports/bsp/v3.10.31-ltsi/rcar-gen2-1.9.5:drivers/tty/serial/sh-sci.c still has
11:44 < horms> my feeling about the relationship between this work and the bsp is
11:44 < geertu>                 struct shdma_desc *sh_desc = container_of(desc,
11:44 < geertu>                                         struct shdma_desc, async_tx);
11:44 < horms> that they have been doing some work to try to stablalise sh-sci
11:44 < geertu> Now, you can still do the container_of() on an rcar-dmac dma_desc object, and get bogus results :-)
11:45 < horms> and i see they have some fixes in the latest v1.9.5 bsp
11:45 < geertu> So I don't think they use rcar-dmac.
11:45 < horms> now, if we can provide them a nice set of fixes to solve their problems then that would be great
11:45 < wsa_> horms: they seem to do, there is even a patch for it in the BSP (which is already upstream, too)
11:45 < horms> but if its invasive, touching all sorts of code, then its not really appropriate for the gen2 bsp
11:46 < shimoda> they use rcar-dmac for audio and some customers uses it for sdhi/mmc
11:46 < shimoda> they = BSP team
11:46 < geertu> #define r8a7791_register_sys_dmac(id)                           \
11:46 < geertu>         platform_device_register_resndata(                      \
11:46 < geertu>                 &platform_bus, "sh-dma-engine", 2 + id,         \
11:46 < geertu>                 &r8a7791_sys_dmac_resources[id * 3],    id * 1 + 3,     \
11:46 < geertu>                 &r8a7791_sys_dmac_platform_data,                \
11:46 < geertu>                 sizeof(r8a7791_sys_dmac_platform_data))
11:47 < geertu> So they use shdmac with hardcoded chabnnels in board code
11:47 < horms> with multiplatform boots?
11:47 < wsa_> so, if they use rcar-dmac already, it would be a technically wise decision if they would use rcar-dmac for serial, too, no?
11:48 < horms> it might be wise
11:48 < shimoda> sorry, they use both rcar-dmac and shdmac
11:48 < horms> but feature-wise the tree is frozen
11:48 < geertu> I once asked Kaneko-san explicitly with which dmac driver his sh-sci patches were tested, as IMHO the patch couldn't work with rcar-dmac (don't remember why, though)
11:48 < horms> geertu: just to clarify, those would be BSP-team patches, he isn't on the team
11:49 < wsa_> horms: is switching to rcar-dmac a feature or a bugfix?
11:49 < horms> i guess it might be either
11:49 < wsa_> if it was a feature, then the bugfix would be to keep on hacking on shdma
11:50 < wsa_> which is not what we really want being the upstram focused team, or?
11:50 < wsa_> (I might be wrong, but I recall Laurent not being very happy with shdma)
11:50 < horms> well, i think that this is one area where there has been some divergence between upstream and the BSP
11:50 < horms> and in my opinion that is not ideal
11:51 < horms> but i wonder what the best way forwards is
11:51 < geertu> r8a7791.dtsi has no "dmas" properties, except in the rcar_sound node
11:51 < horms> i beliwve we have trouble in both mainline and bsp
11:51 < geertu> yes
11:51 < horms> and obviously we wish to fix the former properly
11:51 < geertu> sh-sci needs more care.
11:52 < horms> and ideally take that to the bsp, but i think the devil is in the details
11:52 < horms> regarding how risky the bsp changes might be in terms of stability
11:52 < horms> an unfortunate side effect of this situation is that
11:52 < wsa_> if we would be able to fix it upstream by largely modifying the serial driver only, my hope would be that we could then convince the BSP team to switch over?
11:52 < geertu> the SCIF DNA code is still so complex that there are no obvious deficiencies (I prefer: so simple that there are obviously no deficiencies)
11:52 < horms> its not entirely obvious when a fix for mainline or the BSP is applicable to the other
11:53 < wsa_> horms: true
11:53 < wsa_> there might be side effects
11:53 < geertu> The BSP has several fixes for race conditions, but I don't think they fix the root cause.
11:54 < horms> that would not surprise me
11:54 < geertu> (The same is true for my last RFC series, though)
11:54 < wsa_> but if those side effects come from bugs, then fixing them obviously will change behaviour of the driver
11:54 < horms> they could be positive behavoural changes :^)
11:55 < wsa_> so far, geert's series is completely self contained to the scif driver
11:55 < geertu> Most changes don't look like real behavior changes. Just fixes for rcae conditions.
11:56 < geertu> wsa_: yes
11:56 < shimoda> by the way, I tested geert-san's scif-dma-v2 patch set last week
11:56 < shimoda> and I sent some patches to the ML :)
11:56 < geertu> Thanks for testing, and for the patches.
11:57 < geertu> Which SCI variant(s) did you test?
11:57 < shimoda> i tested on Lager (SCIFA) and koelsch (SCIF)
11:58 < geertu> Good, thanks!
11:58 < horms> ok, i guess we could look at providing some fixes to the bsp team
11:58 < wsa_> my feeling is that it would be worthwhile fixing the remaining issues until we understand what was going wrong and then "sell" our fixes to the BSP team
11:58 < horms> if so i'd like some co-ordination between your changes (and mainine in general) and what is in BSP 1.9.5
11:58 < geertu> I think it's too early for that
11:59 < horms> i guess you and i could co-ordinate that when the timing is right
11:59 < geertu> Yes, I want to fix the remaining issues first
11:59 < horms> ok, no problem regarding waiting
11:59 < geertu> Ater that I can created a "nicer" series.
11:59 < horms> could you take a look at the new bsp (i pushed it on Saturday) on the off chance any of the scif patches there are of use to you
11:59 < geertu> The current one has too many fixes here, fixes there, ... some of them may not be needed inthe end
11:59 < wsa_> that would hopefully also reduce the gap between BSP & mainline
12:00 < horms> i think you only need to look back as far as v1.9.4 as kaneko-san has already fed the older ones to the ml
12:00 < geertu> I already had a quick look, and none of them looked that exciting
12:00 < horms> thanks
12:00 < horms> that was my expectation
12:00 < horms> I will tell Kaneko-san not to bother posting them to the ml
12:02 < wsa_> ok
12:02 < wsa_> so, geert will push out a nicer series
12:02 < geertu> horms: Thanks, sometimes I'm afraid Greg would apply them ;-)
12:02 < horms> haha
12:02 < wsa_> that can happen
12:02 < wsa_> :)
12:03 < horms> as a precaution i already told him not to post them unless he hears otherwise from me :^)
12:03 < wsa_> and hopefully after the new series, we know a bit more how to deal with the issues
12:04 < horms> sounds reasonable to me
12:04 < wsa_> and then we can have a look what would be best for BSP
12:04 < horms> yes, that can come last
12:04 < horms> imho
12:05 < geertu> I hope scif work will become a bit easier now it's at least working a bit
12:05 < horms> hopefully...
12:05 < geertu> Before it was really frustrating, as any small failure somewhere would lead to one out of many possible crashes due to race conditions
12:05 < horms> ouch
12:05 < geertu> On every retry, I had a different crash ;-)
12:06 < wsa_> yes, working on old serial drivers always deserves a "braveness medal"
12:06 < geertu> I'm wondering how SCIF DMA ever worked. I guess SMP=n helped a lot...
12:07 < wsa_> ok, so much about scif?
12:07 < geertu> Does SCIF DMA work on e.g. Ecovec?
12:07 < horms> i may have one if you really want to find out
12:08 < shimoda> geert-san: I don't know
12:08 < geertu> we never wired up scif dma on e.g. armadillo and kzm9g legacy
12:09 < geertu> wsa_ scif EOF
12:09 < wsa_> :)
12:10 < wsa_> so 3) task list
12:10 < wsa_> I sent it around by mail
12:10 < wsa_> I guess you would have replied if you really missed an item there
12:10 < geertu> Sorry, one more SCIF DMA thing
12:10 < wsa_> ok
12:11 < geertu> The people from Visteon contacted me, as they're interested in it for their product.
12:11 < geertu> For a 4 Mbps link to Bluetooth on SCIFA
12:12 < geertu> Just wanted to let you know...
12:12 < wsa_> set them up for testing ;)
12:13 < wsa_> ok, other comments regarding the io group todo list?
12:13 < geertu> the list looks fine to me
12:14 < morimoto> Sorry, is this "todo list" this ? https://osdr.renesas.com/projects/linux-kernel-development/wiki/Io-todo-list
12:14 < wsa_> yes
12:16 < wsa_> so, when looking for further tasks to keep an eye on, I tried to scan through the BSP
12:16 < wsa_> I concentrated on I2C and MMC for starters
12:17 < wsa_> Conclusion: most patches would already need some investigation to simply understand the problem :)
12:18 < wsa_> and in most cases it is very difficult because there is not enough information to reproduce the issue
12:18 < wsa_> so while "scanning the BSP" sounds good in general
12:18 < wsa_> I am afraid we won't have the bandwidth to do it in general
12:19 < horms> i can get the BSP scanned if you like
12:19 < horms> but my feeling is that its already been scanned up until v1.9.4 (and v1.9.5 but not posted yet)
12:21 < horms> of course you are also welcome to look over it as much as you like
12:22 < wsa_> who scans it?
12:22 < wsa_> kaneko-san?
12:22 < horms> Kaneko-san and I
12:22 < wsa_> ok
12:23 < horms> To be honest I think we got all the fat last year
12:23 < wsa_> I wondered about some MMC related patches
12:24 < wsa_> but my suggestion was anyhow: we bring it to this table here
12:24 < horms> anything in particular
12:24 < horms> i recall some relating to timeouts
12:24 < horms> ok
12:25 < wsa_> if there is something easy, we just pick it
12:25 < horms> as i mentioned earlier the BSP is sort of frozen now
12:25 < wsa_> if there is something "interesting", we can discuss it here or by mail
12:25 < horms> so the reate of patches being added has dropped of significantly since... i guess the begninnging of the year
12:25 < wsa_> ok
12:25 < horms> so there isn't such a large crop of changes to pick from
12:25 < wsa_> "bugfix only" mode?
12:26 < horms> something like that
12:26 < horms> i'm not sure of their exact criteria
12:26 < horms> but its mostly if not exclusively bug fixes from my observations
12:27 < horms> there are a few changes waiting feedback from the BSP team
12:27 < horms> i can try chasing them up
12:27 < horms> which may yeild a few more fixes for mainline
12:27 < wsa_> do you know if there will be another "major version" somewhen or is that "the" BSP foreverß
12:27 < wsa_> ?
12:27 < horms> of course for gen3, yes
12:28 < horms> and probably that will support gen2 in some way (perhaps not officually, but it should boot the boards)
12:28 < wsa_> i understand
12:28 < horms> but for gen2 bsp, i believe the plan is no more major updates
12:28 < horms> actually, i think the plan was no more updates at all: but then some bugs turned up...
12:29 < wsa_> damn software ;)
12:29 < horms> yeah, its like that sometimes
12:31 < wsa_> okay, I think we are done with the planned topics
12:31 < wsa_> anything else which needs to be said now?
12:31 < horms> right on time!
12:32 < shimoda> I have no topic at the moment :)
12:33 < wsa_> cool
12:33 < wsa_> so, next meeting probably the week after my holiday
12:33 < wsa_> I will send out a mail
12:33 < horms> enjoy your break
12:34 < wsa_> oh, i will
12:34 < wsa_> but until then, there is another week of work left
12:34 < wsa_> ;)
12:34 < wsa_> thank you guys!
12:34 < morimoto> BTW, Renesas will have summer vacation 10th - 14th Aug
12:34 < shimoda> thank you!
12:34 < wsa_> have a great day/evening!
12:34 < wsa_> morimoto: thanks, noted
12:35 < morimoto> Please let me know if you need something. this week is good for me
12:35 < geertu> Bye!
12:35 < horms> BTW, I will have vacation 10th, 11th (but i can release topic branches as required)
12:35 < shimoda> byebye!
12:35 < morimoto> horms: ok
12:36 < morimoto> bye ! thank you
12:36 -!- morimoto [~user@relprex3.renesas.com] has left #periperi ["ERC Version 5.3 (IRC client for Emacs)"]
12:36 -!- shimoda [~shimoda@relprex1.renesas.com] has quit Quit: WeeChat 0.4.2
12:36 < horms> geertu: will you be sending v4 a little later?
12:37 < horms> if not i won't poll for it :)
12:37 < geertu> horms: yes, I was a bit delayed by the Internet link breakdown
12:37 < horms> understandable
12:38  * geertu has released renesas-drivers-2015-08-04-v4.2-rc5
12:38 < horms> anyway no particular rush here
12:38 < horms> i'll check my email a bit later
12:38 < geertu> will do v4 after lunch
12:38 < horms> good plan
12:38 < horms> i'll disappear for a bit
12:42 < wsa_> me too
--- Log closed Tue Aug 04 12:42:40 2015