--- 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 ig for GR-PEACH? 10:41 < horms> hmmm.... 10:41 < geertu> For arm64, that issue is still unresolved 10:41 < horms> I think Arnd would have a cow 10:41 < geertu> cow? 10:42 < horms> I mean, I think Arnd would reject it 10:42 < horms> I think I'd want to at least talk to him about it first 10:42 < horms> For many years he asked us often to reduce to one defconfig, which we eventually did 10:42 < geertu> Would it be easier to convince him once we have XIP support? That can never work with multi_v7_defconfig 10:43 < jmondi> horms: geertu: I've got some XIP and non-XIP configs for peach I can share 10:43 < horms> geertu: yes, i think the conversation need to happen in the context of XIP 10:43 < geertu> IIRC, Arnd was on the "good" side of the discussion about XIP support 10:45 < horms> I think in Arnds opinion in-tree defconfigs are mainly there for the convenience of him and build bots, and that real users use out-of tree defconfigs. I do not share this opinion. 10:45 < horms> But it does imply that more defconfigs = bad 10:45 < dammsan> Does that mean more boards = bad? =) 10:46 < horms> To me that is a natural extension of the argument, but I'd be surprised if Arnd sees it that way 10:46 < geertu> For XIP and memory-constrained boards, there's no other solution than a separate defconfig 10:46 < dammsan> hehe 10:46 < geertu> or defconfig snippet 10:46 < horms> To be clear, I am not against this. I'm just making recomendations based on my experiences (with Arnd) 10:47 < horms> I think discussing a snippet would be worthwhile 10:49 < geertu> For arm64, no other defconfigs are allowed 10:50 < morimoto> Does previous topic was finished ? if so I have 1 topic 10:50 < horms> see comment above :) 10:50 < geertu> So I think we need an rcar3_defconfig in Simon's repo 10:50 < geertu> In a separate branch (which people can merge), also merged into the devel branch 10:50 < geertu> s/rcar3_defconfig/renesas_defconfig/ 10:51 < horms> we can try that if you think its worthwhile. but i think its unfortunate that upstream policy leads to out-of-tree patches 10:51 < geertu> That's an interesting point of view 10:52 < pinchartl> geertu: merging such branches is always a bit painful 10:52 < pinchartl> for instance when bisecting 10:52 < geertu> True 10:53 < pinchartl> by the way, is there a way to tell git bisect to cherry-pick a set of patches at each bisection point ? 10:53 < geertu> However, when bisecting, you want to keep more or less the config you're bisecting 10:53 < pinchartl> that could be DT patches when bisecting driver changes for instance 10:53 < horms> pinchartl: i usually write a script; it would nice if there was such an option 10:54 < geertu> git bisect run? 10:54 < geertu> I usualy stash the local changes I need, and stash apply them after each step 10:54 < geertu> sometimes there are conflicts 10:55 < pinchartl> I guess the run script could spawn a console, yes 10:55 < horms> anyway, these kind of problems are some of the reasons i object to out of tree code 10:55 < pinchartl> s/console/shell/ 10:55 < horms> but I also agree it should be managable for a defconfig 10:56 < pinchartl> I believe there's value in keeping a defconfig (or a set of defconfigs) *somewhere* 10:56 < horms> that i can agree with 10:56 < pinchartl> I've stopped counting the number of times Jinso reported failure to test deliverables due to their kernel config being bad 10:56 < horms> and i am not objecting to storing them in my tree if there is a value to doing so 10:56 < geertu> Well, bisecting an issue is sometimes similar to out-of-tree patches, as the bug may only show up when merging the driver and DT branches 10:57 < geertu> As defconfigs evolve over time, storing them in a VCS is the most sensible thing to do 10:57 < horms> i'm more objecting to upstream belligerence 10:57 < pinchartl> geertu: would it make sense to store the defconfigs in a repository to which we all have commit rights ? 10:58 < geertu> pinchartl: Really? 10:58 < pinchartl> just asking ;-) 10:58 < geertu> Should renesas-drivers pull requests include defconfig updates, too? 10:59 < pinchartl> you'll have fun with the conflicts :-) 10:59 < geertu> Exactly 11:00 < geertu> Maintaining defconfigs that are to be updated regularly is a real task 11:01 < geertu> Perhaps we should continue offline (on periperi-ml), as this affects I/O and MM, too? And Morimoto-san has another small topic to discuss 11:01 < pinchartl> sure 11:02 < morimoto> geertu: can I start my topic ? 11:03 < wsa_> i have a small question, too. 11:03 < wsa_> (after morimoto-san) 11:04 < geertu> morimoto: sure, please go ahead 11:04 < morimoto> Thanks 11:04 < morimoto> it is about Salvator-XS board shipping. 11:04 < morimoto> I will ship XS board to Geert/Marek/Laurent/Niklas as 1st shipping, other guys will receive it as 2nd shipping. 11:04 < morimoto> I can ship it this week in best case. 11:04 < morimoto> pinchartl: I think I need to keep it until 6/M for you ? Because you stay in Japan until 17th ? I can bring it meeting room if you want. 11:04 < morimoto> marex-cloud: neg: you will come to Japan, but I will ship it to OpensourceAB, So I can ship it soon ? 11:04 < morimoto> dammsan: I think OpensourceAB can keep it until after OSS Japan ? 11:04 < morimoto> geertu: you will not come to Japan, so you can receive it without receive trouble? 11:05 < geertu> morimoto: yes I can. Thanks! 11:05 < dammsan> morimoto: correct 11:05 < morimoto> geertu: dammsan: OK, thanks. and pinchartl ? 11:06 < morimoto> marex-cloud: neg: please discuss how to receive it with dammsan 11:06 < neg> morimoto: will do thanks 11:08 < pinchartl> morimoto: please. if you ship it now it will arrive when I'm away, and that will be difficult to handle 11:08 < morimoto> pinchartl: OK. will ship it around 6/ 11:08 < morimoto> 11:08 < morimoto> 6/M 11:08 < pinchartl> you could ship it on the 13th or 14th, then it should arrive when I'll be back 11:09 < morimoto> OK. geertu: thats it from me. thanks 11:10 < geertu> Thank you, Morimoto-san 11:10 < geertu> wsa_: You have a question? 11:11 < wsa_> yup, about a possible renesas-cpg-mssr and i2c-sh_mobile dependency? 11:11 < wsa_> bsp has a commit saying: 11:11 < wsa_> Since renesas-cpg-mssr clk driver has changed its initial function to subsys_initcall, so change the initial function of this module to lower level. 11:11 < wsa_> I may be totally missing something, but I don't see the connection 11:12 < wsa_> and I don't want i2c drivers to be subsys_initcall unless it is utterly necessary 11:15 < wsa_> any idea? 11:16 < wsa_> If it needs digging, we can do that by mail; but I thought it might be obvious for you guys :) 11:17 < shimoda> wsa_: i think we should ask bsp team about this patch "i2c: sh_mobile: Change driver init level(Dien Pham) " 11:17 < wsa_> yes, we can do that as well 11:17 < geertu> They want to avoid probe deferral, which would put it at the end of the list again 11:18 < wsa_> but then maybe, I should collect all the questions I have :) 11:18 < shimoda> I guess this patch is related to power management because Dien-san is a member of power management team. anyway I will ask bsp team later 11:18 < geertu> While they want the i2c bus serving the PMIC initialized early 11:18 < shimoda> ask both bsp team and power management team 11:19 < wsa_> i see 11:19 < wsa_> so this saves a cycle of deferred probing 11:20 < wsa_> and the patch description is a little misleading 11:21 < wsa_> ok, thanks! 11:21 < wsa_> jmondi: do you have a minute after the meeting? 11:21 < jmondi> wsa_: yup 11:22 < geertu> wsa_: I find this patch description less misleading than some others ;-) 11:22 < wsa_> true, "a little" meant to express that :) 11:24 < shimoda> wsa_: geertu: if the description is correct, this patch is reasonable? 11:24 < shimoda> I mean, the patch should revise the description 11:24 < shimoda> and after revised it, should the patch go to upstream? 11:25 < wsa_> I wouldn't like to upstream it if it is not really needed to get the machine alive 11:25 < geertu> A good patch description talks about current state, wy that's a problem, and how to fix it. 11:25 < geertu> wsa_: Note that it's already subsys_initcall() in upstream 11:25 < geertu> subsys_initcall_sync() is _later_ 11:26 < wsa_> It is more a hackish workaround about missing device dependencies 11:26 < wsa_> I see! 11:26 < shimoda> thanks, so I should ask bsp team why they don't want to deffer the driver 11:26 < wsa_> shimoda: wait, geertu has a point there 11:27 < wsa_> but it is still trying to describe a dependency via init levels :/ 11:27 < wsa_> I'll have a closer look 11:28 < geertu> shimoda: If the driver is deferred, it's moved to the end of the list, hence retried after all other drivers have been initialized 11:28 < geertu> Probing really should start taking into account phandles 11:29 < geertu> But that would break circular dependencies... 11:29 < geertu> (doh, not as in "break the circle", but as in "break operation if there are circles" 11:29 < geertu> ) 11:31 < wsa_> It is a tough problem, but it needs to be tackled properly somewhen 11:31 < wsa_> As a maintainer, I am very conservative when people try work around this via init levels 11:32 < wsa_> As I said, only if it is utterly needed 11:32 < wsa_> Sadly, there is already cruft in my subsystem, and it causes hazzles once in a while 11:32 < wsa_> one platform needs it like this the other like that 11:32 < wsa_> but i'll check this patch again 11:34 < shimoda> wsa_: ok, so i'm waiting for wolfram-san. no ask some teams. is it ok? 11:34 < wsa_> yes 11:35 < shimoda> wsa_: i got it 11:35 < wsa_> thank you shimoda-san 11:35 < shimoda> wsa_: you're welcome :) 11:37 < geertu> Anything else to discuss? 11:37 < geertu> Else we can finish 11:38 * Marex is back from outside 11:39 < Marex> dammsan: will handle the email from you tomorrow-ish , OK ? 11:42 < Marex> morimoto: jupp, I'll come to Japan (looking forward to it!!), will discuss with dammsan 11:42 < Marex> morimoto: I'll be back on June 15th (doing a trip of Hokkaido this time), so there's no need to hurry 11:43 < morimoto> Marex: OK, but XS shipping for Marex/neg will be happen in the same time 11:44 < Marex> morimoto: got it :) 11:44 < morimoto> Because it goes to OpensourceAB first 11:44 < morimoto> And OpensourceAB will forward it to you guys 11:44 < morimoto> OpensourceAB can keep it for you. 11:44 < morimoto> You can talk it to dammsan in Japan 11:45 < Marex> morimoto: jupp :) 11:45 < Marex> morimoto: pardon my ignorance, XS is r8a7795 or 7796 ? 11:45 < geertu> r8a7795 ES2.0 11:45 < Marex> ooooh, super ! 11:47 * neg needs to goaway for ~2 min 11:50 * neg is back 11:50 < geertu> Let's finish 11:50 < horms> thanks everyone 11:50 < shimoda> thanks! 11:50 < geertu> Thanks for joining, and have a nice continued day!
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-02 16:26:19 +0000