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!