renesas/periject.git - Renesas periject clone

Age	Commit message (Expand)	Author
2021-01-29	project.schema: replace bsp-commits to bsp39x	Kuninori Morimoto
2019-10-04	Auto-update sweep for v5.4-rc1	Geert Uytterhoeven
2019-08-22	projects: linux: io: update tasks after meeting 20190822	Wolfram Sang

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