Multimedia-chat-meeting-2017-04-12 good morning [15:55] morning hi hello [15:56] let's wait a few minutes for Jacopo and Magnus to join [15:57] Morning all 'morning now only Magnus is missing :-) [15:58] while we wait [16:00] *** dammsan (~dammsan@s214090.ppp.asahi-net.or.jp) has joined channel #periperi [16:01] morimoto: is it enugho infomrmation about 'VIN issues on H3 ES2.0 and M3 ES1x/M3W' to talk about it today or should we postpon it? * morimoto Renesas talk now hi Magnus neg: I think we should at least mention it let's get started topics for today Topic 1. Status check for the multimedia tasks [16:02] Topic 2. VIN issues on H3 ES2.0 and M3 ES1x/M3W Topic 3. Upstream V4L2 development anything else ? ok, let's start with status updates [16:03] maybe a check up on travel plans for OSS? jmondi: good point Stamp of approvel for Tokyo dates, the mail thread is dead and time to buy tickets ;-) Ack with those :) ^ Kieran has to run away in the middle of the meeting, so he will get started kbingham: the stage is yours Why thankyou maestro :-) * morimoto back [16:04] So I'm now back on RCar developments and I've commenced looking at the ADV7482 work I have had some difficulty capturing frames through VIN so far, getting the links set up to capture. neg: we have no W/A at this point, so, nothing to discuss today. it is just information sharing [16:05] (I have tried to capture using the existing code base, using HDMI in ) - and a RPi to generate HDMI data But the issue is getting the formats to propogate - checking the formats shows 'unknown' in the FMT field .. and things aren't propogating through media ctl. [16:06] kbingham: do you have further things to try, or are you completely blocked ? if it's a format propagation issue I assume you can try to debug it I'll have more things to try - like getting some prints in to see why the formats aren't there [16:07] yes - It's just a debug issue really. But will help me walk the code base anyway ok kbingham: did you try h3-compliance.sh from vin-tests? neg: Yup ! Same issue neg: And I set my RPi dev to 640x480 as you suggested - still no avail - so I just need to dig and understand the issue hum that is strange, guess I need to buy a RPI today :-) If needed, I'll talk to (neg) later about that if possible. [16:08] you can also ask me not that I have tried it but I can guide you through the format propagation process and code pinchartl: Thankyou :D Anyway - otherwise- Once that issue is resolved, I have started looking at how to create the subdevs, as per our disucussions and once I have established a baseline - I should be comfortable hacking away at that. [16:09] ok, thank you first guess is it's EDID related since the ADV7482 have no EDID support I do all my testing using a Xbox as source so I assume it fallback to something the ADV7482 likes that is the ADV7482 driver have no EDID support By default, the source is coming up as [fmt:unknown/1920x1080 field:none] [16:10] Anyway, we can go through that later :D [16:11] kbingham: the ADV7482 prototype should autodetect the formats, I would like to see the fill media graphyou get if possible, but maybe you and I can hash this out after the meeting :-) jmondi: you're next in resumed alpbabetical order :-) I agree - we'll go through this after the meeting rather than in the meeting :) fine... [16:12] so, I started looking at moving the CEU driver away from soc_camera I'm still evaluating if it is better to rewrite it or patch the existing what's your opinion at this point ? [16:13] I'm a bit more inclined to patch the existing, because at the moment it seems to me the driver could be implemented without sub-devices, just with a single video device also, I saw there is a VEU driver, which seems simple enough to use as "inspiration" [16:14] even if it is a mem2mem device that sounds good to me you need a subdev for the camera sensor but you don't need to expose it to userspace [16:15] yeah, camera sensor apart... because the CEU has a format conversion unit, that can be modeled as sub-device visibile to userspace the atmel/atmel-isc.c driver seems to be a good example but I guess it can be left out for now [16:16] you don't need to, you can implement format conversion internally yes, also pinchartl: thanks, I would have asked you suggestions on which driver to look at and that's all I would have to clarify if OF support only is enough because the remote mingor board we should start with, has no OF support if I'm not wrong, right Magnus? [16:17] pxa_camera should also be an option pinchartl: I gave a look at pxa camera, mostly for OF parsing correct, no OF support in Migor [16:18] you need to use platform data :-/ that's bad, it means I have to implement both :/ you can start with platform data, and implement OF support later [16:19] we should also discuss about hw setup.. but it can be post-poned after mingor has been made at least booting mainline sounds good to me [16:20] how about the next two weeks ? do you plan to continue working on this ? I'm still intrigued byt the idea of starting with an RZ device from day 0 pinchartl: yes, now that my other 2 tasks for IO/core are almost done, I'll be fully on multimedia ok [16:21] I'll stop here, not to steal the stage to all the others :) one more thing, could you please remember to send your status report by e-mail before the meeting next time ? [16:22] jmondi: yes there is no OF support for migor pinchartl: uh, I'll do this right away sorry about that jmondi: no need to for today, I'll include it in the report but it helps if I get them in advance and, pinchartl, I'll ping you a bit more often in next days, hope you won't mind ;) no problem with that :-) [16:23] (I'll be away from tomorrow to Tues. since we're speaking) ok, done with me next, me I've mostly worked on code review and various discussions, internally and upstream as well as additional tasks negotiation [16:24] from a code point of view, I've tried to get the VSP rotation and histogram support merged upstream in v4.12 it resulted in yet another fight with Mauro up to a point where I can't take his abusive behaviour anymore [16:25] I took a few days to think this over among the various options most of them seemed unreasonable to me such as challenging him publicly for V4L2 maintainership for instance Hans Verkuil proposed to me to act as an interface between Mauro and me [16:26] to avoid all direct interactions I don't really think this would work, but I might give it a try in any case, I saw no other option that stepping out from upstream V4L2 development, at least temporarily I will reconsider that decision if the situation changes [16:27] (or if I find a better idea) in effect, this means I can continue reviewing code and driving discussions internally including architecture discussions but I'll remain silent publicly for now it also means I will likely need to refrain to author any V4L2 patch [16:28] I still need to discuss this with Hans today, after this meeting sounds good to me for the next two weeks, I plan to work on the multi-camera setup and try to get it working VSP fences support is effectively on hold, I can't work on that [16:29] you can also consider putting mauro on fire I've considered that, but I don't think it will help he will fight back, and it would just create a bit mess, most likely without any concrete improvement he looks like he may burn well probably dammsan: let's not resort to personal non-technical attacks [16:30] that's it for me for today if any of you wants to discuss this further let's do so after the status updates [16:31] next, dammsan quick question, 'reviewing code internally' means no public review of patches? no update from my side, currently installing migor in the remote access rack neg: correct. let's discuss the implications after the status update [16:32] dammsan: thank you I assume you'll now try to get Migor to boot mainline ? once it is installed yes [16:33] thank you thanks next, Morimoto-san A) What have I done since last time continue OF-graph posting. I got response from Rob, but he mentions small details which is related to ALSA SoC, not to OF-graph. BSP team reported Sound issue. Almost all bugs are fixed. But some noise issue was not yet solved. I'm thinking this is related to board specific clk issue (L/R clock gets interference from Bit clock) 8ch camera datasheet export paper work created periupport script shared H3/M3 VIN issue to you guys ;P B) What I plan to do till next time [16:34] continue OF-graph posting continue sound noise issue fix 8ch camera board check by using demo program with BSP team C) Problems I have currently OF-graph stalling --EOT-- thank you when do you think you will be able to verify the multi-camera setup with the demo program ? [16:35] According to BSP team, I and Magnus will check it on this Fri huh, good to know =) [16:36] :-D dammsan: this means you need to bring it to Renesas Office on Fri :P I'll wait until this weekend before working on it then could you post a status update when you will be done on Friday ? [16:37] Of course I will check 2 board which will be ship to Laurent/Niklas after May and Magnus, will you be able to reinstall it in your remote access setup after your done, to allow me to work on it during the weekend ? pinchartl: sure thank you [16:39] pinchartl: not sure about when i will get time to do that I think all needed 8ch camera datasheet/information exist on Wiki now. do we still missing something ? dammsan: could you at least send me an e-mail when you will be done ? and also notify me if you get delayed ? it depends on how long time is needed in the renesas office [16:40] morimoto: I still don't know what the small microcontroller inside the cameras does exactly. do you have any information about that ? it's connected to the I2C control bus, and controls the sensor power down signal once it is working i will reinstall it in the remote access rack [16:41] dammsan: you don't have to work around the clock obviously :-) but for planning purposes, it would help if you could let me know at the end of Friday if there will be delays pinchartl: do you mean U402 ? and I think you are asking it to IMI guys ? [16:42] morimoto: yes, U402. I've asked the IMI person who sent me the schematics, but haven't received any answer i highly doubt things will start workin on friday OK, I will push him and we have meetings most of the afternoon so i think you can assume you will not get it this weekend [16:43] dammsan: ok. let me know if that changes then will let you know oCore-chat-meeting-2017-05-23 10:05 < geertu> Welcome to today's Core Group Chat 10:05 < geertu> Agenda: 10:05 < geertu> 1. Status updates 10:05 < geertu> Topic 1. Status updates 10:05 < geertu> A) What have I done since last time 10:05 < geertu> B) What I plan to do till next time 10:05 < geertu> C) Problems I have currently 10:05 < geertu> D) Posted/Accepted bugfix patches 10:06 < geertu> sort -R says Magnus is first 10:06 < horms> geertu: it turns out I am here now 10:07 < geertu> horms: Great! 10:07 < neg> Hi all 10:08 < dammsan> hi 10:08 < neg> Sorry for beeing late, contractors who are to change my frontdoor (which where schdeuled for this afternoon just turned up...) 10:08 < dammsan> A) i sent IPMMU multiarch series and some minor cosmetic fix 10:09 < dammsan> B) send out r8a7795 series for IPMMU 10:09 < dammsan> C) Nothing in particular 10:09 < dammsan> D) Nada 10:10 < geertu> Thank you, Magnus 10:10 < geertu> Next is Laurent (lurking?) 10:11 < geertu> Next is Marek 10:11 < marex-cloud> ACD=NULL B=try to get as many remaining peripheral patches into uboot mainline (gpio,sdmmc,ravb eth), start phase2 which is conversion of r8a779x to DT in uboot 10:12 < pinchartl> geertu: sorry, lurking, yes 10:12 < pinchartl> although I debugged IOMMU issues last week, which can be considered as core group work 10:12 < pinchartl> Sricharan has posted patches that should hopefully reach v4.12-rc soon 10:12 < pinchartl> nothing else to report 10:13 < marex-cloud> first part I hope to land in 2017.07 , second part later (I'll also have to coordinate with Iwamatsu-san, the rmobile maintainer in uboot on that) 10:13 < marex-cloud> EOF 10:13 < geertu> Thanks Laurent 10:13 < geertu> Thanks Marek 10:13 < geertu> Next is Shimoda-san 10:13 < shimoda> a) 10:13 < shimoda> - I submitted a bugfix patch of usb-dmac and applied it. 10:13 < shimoda> b) 10:13 < shimoda> - nothing for core 10:13 < shimoda> c) 10:13 < shimoda> - nothing for core 10:14 < shimoda> d) 10:14 < shimoda> - [PATCH] dmaengine: usb-dmac: Fix DMAOR AE bit definition 10:14 < shimoda> EOT 10:14 < geertu> Thank you, Shimoda-san 10:14 < geertu> Next is Niklas 10:15 < neg> A) 10:15 < neg> - Talked to Vinod about '[PATCH v2 0/3] dmaengine: rcar-dmac: fix resource freeing synchronization' and he agreed to pickig it up now. 10:15 < neg> - Formed a plan on how to improve the freeing of channels for rcar-dmac and how we can verify the Renesas test-case which is the root of this work. 10:15 < neg> B) 10:15 < neg> - No core task ATM if I get bored on the plane to Tokyo I might start to look at how to add a WARN to dmaengine if one is trying to free a none idle channel. 10:15 < neg> C) 10:15 < neg> - None 10:15 < neg> D) 10:15 < neg> - None 10:15 < neg> EOT 10:16 < geertu> Thank you, Niklas 10:16 < geertu> Next is Jacopo 10:16 < jmondi> a) not really a core task but had mainline run on GRPeach: 10:17 < jmondi> http://elinux.org/RZ-A/Boards/GR-PEACH-mainline 10:18 < jmondi> b) let's see how the RZ/A pin controller discussion evolve now that guys from NXP have been submitting similar proposal for our generic properties 10:18 < jmondi> c) nothing for core 10:18 < jmondi> d) iio: adc: max9611: Fix attribute measure unit 10:18 < jmondi> but that's IO, not core :) 10:18 < jmondi> -- eot -- 10:19 < geertu> If we use the max9611 for DVFS, it's core ;-) 10:19 < geertu> Thank you, Jacopo 10:19 < geertu> Next is Geert 10:19 < geertu> A) 10:19 < geertu> - Implemented R-Car H3 ES2.0 CPG/MSSR errata 10:19 < geertu> - Published v2 drivers/{clk,soc}/renesas/Kconfig rework 10:19 < geertu> - Published v2 of R-Car Gen2 CPG/MSSR, incl. DTS updates 10:19 < geertu> - Published v2, v3, and v4 of H3 ES2.0 DTS 10:20 < geertu> B) 10:20 < geertu> - Look into suspend/resume for CPG/MSSR and PFC 10:20 < geertu> - Mark periupport priority < H commits that are in linux-next 10:20 < geertu> C) 10:20 < geertu> - None 10:20 < geertu> D) 10:20 < geertu> - [PATCH v2 0/4] sh: sh7722/sh7757i/sh7264/sh7269: Fix pinctrl registration 10:20 < geertu> - [PATCH v2 1/4] sh: sh7722: Remove nonexistent GPIO_PTQ7 to fix pinctrl registration 10:20 < geertu> - [PATCH v2 2/4] sh: sh7757: Remove nonexistent GPIO_PT[JLNQ]7_RESV to fix pinctrl registration 10:20 < geertu> - [PATCH v2 3/4] sh: sh7264: Remove nonexistent GPIO_PH[0-7] to fix pinctrl registration 10:20 < geertu> - [PATCH v2 4/4] sh: sh7269: Remove nonexistent GPIO_PH[0-7] to fix pinctrl registration 10:20 < geertu> - [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral 10:20 < geertu> -- eot -- 10:20 < dammsan> quick question, seems that GR-PEACH support is missing from mainline? 10:20 < geertu> Next is Morimoto-san 10:20 < dammsan> thanks for your efforts Geert!! 10:21 < morimoto> A) What have I done since last time 10:21 < morimoto> D) Posted/Accepted bugfix patch 10:21 < morimoto> I posted rcar-dmac descriptor mode residue calculation bugfix patch today. 10:21 < morimoto> Without this patch, Audio DMAC (= descriptor mode user) can't get correct residue. I'm happy if you can review it 10:21 < morimoto> B) What I plan to do till next time 10:21 < morimoto> C) Problems I have currently 10:21 < morimoto> No task, sir 10:21 < morimoto> --EOT-- 10:21 < geertu> Thank you, Morimoto-san 10:21 < geertu> Next is Simon 10:21 < jmondi> dammsan: let's discuss that later maybe 10:23 < horms> Todo Update 10:23 < horms> NULL 10:23 < horms> A) What have I done since last time 10:23 < horms> B) What I plan to do till next time 10:23 < horms> No Core task at this time 10:23 < horms> C) Problems I have currently 10:23 < horms> D) Posted/Accepted bugfix patch 10:23 < horms> None 10:23 < horms> It seems that I will be able to attend from 10am after all, see you then. 10:24 < geertu> Thank you, Simon 10:25 < horms> I have a question for morimoto-san: what is Premium Friday? 10:25 < geertu> So far for the status updates 10:25 < geertu> dammsan: jmondi: You want to talk about GR-PEACH? 10:26 < wsa_> i have one small question, too 10:26 < jmondi> "golden week" "premium Friday"... I love Japanes holiday names :) 10:27 < jmondi> geertu: sure, it's quite quick from my point of view: does anyone care about that small board? It can boot from SRAM only a very minimal kernel, otherwise it requires XIP 10:27 < jmondi> and we're not allowed to enable XIP without a small patch that has been rejected multiple times (according to Chris) 10:27 < morimoto> horms: in these days, japanese government created such day which is located on last Friday on this month 10:27 < horms> jmondi: there is also Lucky Monday - a holiday moved to Monday to give a long weekend 10:28 < horms> morimoto: thanks, enjoy your Friday :) 10:28 < morimoto> This month, it is 26th. They recommend to early quiting from office :) 10:29 < horms> oh ok, its not a whole day off, just encoragement to go home early? 10:29 < jmondi> horms: it would have been Lucky Friday otherwise... 10:30 < dammsan> jmondi: i dont think the question is if anyone cares. the question is why we wouldn't upstream it? =) 10:30 < morimoto> horms: Yes. But on this month, Renesas union's recommend is take a day off :P 10:30 < horms> I like your union 10:30 < dammsan> that makes one of us 10:31 < jmondi> dammsan: yes, I've said "does anyone care" because of the XIP thing 10:32 < geertu> What's missing is a DTS for GR-PEACH, right? 10:32 < jmondi> if we upstream that, without XIP support available, only a very minimal kernel image can be booted... 10:32 < jmondi> geertu: yes, that, and RZ pin controller ;) 10:32 < geertu> Well, it's a first step 10:32 < morimoto> horms: it is "Happy Monday", not "Lucky Monday" :) 10:32 < jmondi> geertu: http://jmondi.org/git/linux/commit/f38567427d2db4a8d14001f8aba860a307b41186 10:32 < geertu> jmondi: That's true for genmai and RSK, too 10:32 < horms> morimoto: sorry, my bad 10:33 < jmondi> geertu: true indeed 10:34 < geertu> jmondi: Does the GR-PEACH work without the pinctrl driver? 10:34 < jmondi> geertu: I have not tried tbh... 10:35 < jmondi> I don't see why not, if pins are configured properly in u-boot... And they should be 10:37 < geertu> OK, so you can submit the GR-PEACH DTS without the pinctrl props now 10:37 < jmondi> I'll test and send 10:40 < dammsan> thanks guys 10:40 < geertu> The XIP and config issues can be solved later 10:40 < horms> nice. fwiw its common (perhaps usual) to add a board without pinctrl support 10:41 < geertu> horms: I guess we can provide a minimal defconfig 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-28 12:22:23 +0000