diff options
Diffstat (limited to 'wiki/Chat_log/20170523-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20170523-core-chatlog | 300 |
1 files changed, 300 insertions, 0 deletions
diff --git a/wiki/Chat_log/20170523-core-chatlog b/wiki/Chat_log/20170523-core-chatlog new file mode 100644 index 0000000..05b56b0 --- /dev/null +++ b/wiki/Chat_log/20170523-core-chatlog @@ -0,0 +1,300 @@ +Core-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! |