Merge remote-tracking branch 'gitlab/wiki' into HEAD

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!