diff options
Diffstat (limited to 'wiki/Chat_log/20150804-io-chatlog')
| -rw-r--r-- | wiki/Chat_log/20150804-io-chatlog | 382 |
1 files changed, 382 insertions, 0 deletions
diff --git a/wiki/Chat_log/20150804-io-chatlog b/wiki/Chat_log/20150804-io-chatlog new file mode 100644 index 0000000..39f0222 --- /dev/null +++ b/wiki/Chat_log/20150804-io-chatlog @@ -0,0 +1,382 @@ +--- 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 |