wiki: Porting wiki: Porting Chat Log

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

1 files changed, 255 insertions, 0 deletions

diff --git a/wiki/Chat_log/20160524-core-chatlog b/wiki/Chat_log/20160524-core-chatlog
new file mode 100644
index 0000000..de77a2c
--- /dev/null
+++ b/wiki/Chat_log/20160524-core-chatlog
@@ -0,0 +1,255 @@
+Core-chat-meeting-2016-05-24
+
+10:02 < geertu> Welcome to today's Core Group Chat Meeting
+10:02 < geertu> Laurent will join later
+10:02 < geertu> Magnus will have a fluctuating presence
+10:03 < morimoto> I will quit 1hour later
+10:03 < geertu> Agenda:
+10:03 < geertu> 1. Upcoming Gen3 development for the Core group,
+10:03 < geertu> 2. Revisiting the mode pins
+10:03 < geertu> 3. Status check for tasks from last meeting - what is remaining?
+10:03 < geertu> Topic 1. Upcoming Gen3 development for the Core group
+10:04 < geertu> Any takers?
+10:04 < horms> I have a few things to mention
+10:05 < geertu> Please go ahead
+10:06 < horms> Kaneko-san has been working on classifing the patches present in the v3.2.x BSP. v3.2.1 is mostly done. I can share what we have so far if it is of interest to the group. Mainly it covers r8a7795. And probaly we can tease some new tasks out of that.
+10:06 < geertu> ok
+10:06 < horms> I have asked him to start looking over the v3.2.3 BSP. I expect that to include rather a lot of r8a7796 code when compared to v3.2.1
+10:07 < horms> I mainly raise this because I'm not entirely sure how to make the information available here. Or indeed if it is of much interest at all.
+10:08 < geertu> As this affects all groups, perhaps it should be emailed to periperi instead?
+10:08 < horms> That is all I have to raise for this topic.
+10:08 < shimoda> horms: perhaps, you mean v3.2.2 BSP, not v3.2.3 :)
+10:09 < horms> Sorry, I mixed up the versions.
+10:09 < horms> We have looked over v3.2.0.
+10:09 < horms> We are starting to look over v3.2.2.
+10:10 < horms> There is also a v3.2.1 but we are planning to skip from v3.2.0 to v3.2.2.
+10:10 < horms> geertu: sure, good suggestion.
+10:11 < shimoda> I agree with geert-san. this topic is related to all groups. and I would like to share information about bsp sdhi driver later :)
+10:12 < shimoda> because the bsp sdhi driver has some workaround code, and i don't think we upport it
+10:13 < horms> Ok. I'll make the raw information I have available on periperi ML. And we can decide what are some good next steps there.
+10:14 < shimoda> thanks!
+10:14 < horms> off topic. but I would value any insights/testing of timeouts during tuning in my sdr104 patch set.
+10:14 < khiemnguyen> horms: Please add me to periperi ML.
+10:15 < horms> khiemnguyen: I will send the BSP analys there. Is that what you were requesting?
+10:15 < khiemnguyen> horms: I just wonder whether my email address is included or not :)
+10:16 < horms> I can fix that. Lets discuss in private.
+10:16 < horms> geertu: I think we cam move on
+10:17 < geertu> Yes. any more upcoming development?
+10:17 < geertu> I'm mostly fighting^H^H^H^H^H^H^H^Hbusy with my IO task right now
+10:18 < horms> Oh, sorry. There is one more thing I thought of.
+10:18 < horms> Sharing DT betweek Gen3 SoCs. Dirk raised this on the ML.
+10:18 < horms> It seems like a good idea in principle.
+10:19 < horms> But it doesn't seem to work well with our per-soc compatibility strings.
+10:19 < geertu> Indeed
+10:19 < horms> So I wonder if the number of nodes that can be shared via an #include scheme is quite small
+10:19 < geertu> But nothing some smart (obfuscated?) cpp macros can't solve...
+10:19 < horms> I was thinking of responding along those lines.
+10:19 < horms> Basically if we can come up with a scheme that is great.
+10:20 < horms> But I'm inclined to think that is an effort to be done in parallel
+10:20 < horms> rather than a dependency for adding M3-W
+10:20 < geertu> Yes, in parallel, not as a dependency
+10:20 < horms> Ok, I'll respond unless you wish to (I won't get to it until at least tomorrow)
+10:21 < geertu> OK, will see whether I find some time to write a reply.
+10:22 < horms> Thanks
+10:22 < horms> khiemnguyen: you are now subscribed to the periperi ML
+10:25 < horms> geertu: shall we move on?
+10:25 < geertu> yes please
+10:26 < horms> I guess its mode pin time :)
+10:26 < geertu> Yeah, again!
+10:26 < horms> But perhaps we should defer that to after Laurent arrives_
+10:26 < horms> ?
+10:26 < geertu> Indeed. Unless Morimoto-san has a srong opnion?
+10:27 < geertu> s/srong opnion/strong opinion/
+10:28 < morimoto> sorry, what was "mode pin" ?
+10:28 < geertu> morimoto: Read the MODEMR register to obtain the status of the mode pins.
+10:29 < geertu> Needed for CPG on Gen2/3
+10:30 < morimoto> I have no opinion about that (at this point)
+10:30 < geertu> OK
+10:30 < geertu> Let's continue when Laurent has (re)arrived.
+10:30 < geertu> 3. Status check for tasks from last meeting - what is remaining?
+10:30 < geertu> We have a few tasks with deadline v4.6 in core/todo
+10:31 < geertu> IPMMU,v4.6,plan,niklas,Discuss API changes on the dma-engine mailing list
+10:31 < geertu> neg: I assume this is now completed?
+10:32 < neg> yes
+10:32 < neg> or sorry. no
+10:33 < geertu> I'll uodate it for v4.7?
+10:33 < geertu> s/uodate/update/
+10:34 < neg> thanks. I have sent out a patch addresig Hellwigs concerns 2 weeks ago but have not yeat heard back from him about it
+10:35 < geertu> ok
+10:35 < geertu> IPMMU,v4.6,noplan,?,Finally get feedback from the hardware developers regarding the IPMMU + DMAC channel 0 issue
+10:35 < geertu> Did we hear anything back?
+10:35 < geertu> If not, I'll change it to v4.x
+10:36 < geertu> (or is "?" accepted as a version?)
+10:37 < shimoda> i have no update, so lets ? as a version
+10:37 < geertu> ok
+10:37 < geertu> SMP,v4.6,public,magnus,Discuss SMP DT bindings with ARM SoC maintainers
+10:37 < geertu> dammsan: there?
+10:41 < geertu> OK, let's check when he's back
+10:41 < geertu> r8a7795,v4.7,prototype,shimoda,Investigate SYS-DMAC2
+10:41 < geertu> shimoda: Do you know if the firmware fixing this has been released?
+10:42 < morimoto> (he is now talikng with our boss, please wait)
+10:46 < khiemnguyen> geertu: shimoda: FYI, I saw that secure firmware of 2.8.0 has some updated for SYS-DMAC2. Any test cases to confirm SYS-DMAC2 ?
+10:49 < geertu> khiemnguyen: If you change (both) dmac1 to dmac2 for the scif1 node in r8a7795.dtsi, does debug serial 1 still work?
+10:50 < khiemnguyen> geertu: OK. Let me try it and inform you the result.
+10:50 < shimoda> sorry for the late. as khiem-san mentioned, the firmware 2.8.0 has update for SYS-DMAC2. and bsp team confirmed the dmac work correctly.
+10:50 < geertu> khiemnguyen: thx
+10:51 < geertu> shimoda: Great!
+10:51 < geertu> So we can start adding dmas pointing to dmac2 where appropriate
+10:52 < geertu> I'll add a task for that
+10:52 < dammsan> geertu: no update from my side
+10:53 < geertu> dammsan: Do you plan to have more discussions (and I will s/v4.6/v4.7/), or are we finished discussing SMP DT bindings (and I will mark it completed)?
+10:54 < dammsan> good question
+10:54 < shimoda> by the way, v2.8.0 also enables data conversion feature though :) as we discussed before, for short term, we should disable the feature
+10:54 < morimoto> (unfortunately, I will go to next meeting)
+10:55 < dammsan> i think keeping it for a while is good
+10:55 < geertu> morimoto: thanks, and have a nice continued day!
+10:57 < geertu> W.r.t. SYS-DMAC2, the wiki doesn't have boot loader v280 yet (latest is v270)
+10:58 < geertu> Which brings us to another interesting question.
+10:58 < geertu> When do we update the DTS with features that depend on firmware versions?
+11:00 < horms> I gather the issue here is about backwards copmatibility. I.e. new DT with old FW.
+11:01 < geertu> Yes
+11:01 < geertu> Which is also relvant for "compatible = "arm,psci-1.0";
+11:01 < geertu> s/relvant/relevant/
+11:01 < geertu> whicb BTW, can be detected at run-time...
+11:02 < horms> ok, if it can be detected at run time then perhaps it should be :)
+11:02 < dammsan> run-time detection must be best if possible
+11:02 < geertu> Yeah, DT describes the hardware bla bla bla
+11:02 < horms> but I guess in the general case we may have to document minumum FW revisions
+11:03 < geertu> Yes, add a comment at the top of r8a7795.dtsi?
+11:03 < horms> That might be a good start.
+11:05 < khiemnguyen> geertu: horms: psci-1.0 can be detected at runtime. I have replied the thread.
+11:05 < horms> excellent, thanks
+11:07 < geertu> OK, let's move on
+11:07 < geertu> DMAEngine,v4.7,prototype,?,Implement proper solution with IPMMU
+11:08 < geertu> Should the "?" be "magnus"?
+11:08 < geertu> Update to v4.8?
+11:09 < neg> how is this task different from 'Discuss API changes on the dma-engine mailing list' ?
+11:09 < geertu> discuss vs. implement?
+11:11 < neg> hum OK, the patches I try to get Hellwigs attentinon on have one implementation for this, if it is proper or not I do not know :-)
+11:12 < geertu> OK, I'll keep the "?" for now
+11:12 < horms> I wonder how we can get Christoph's attention
+11:12 < geertu> Beer?
+11:12 < horms> Probably
+11:13 < horms> If I see him I will give him some. But perhaps that shouldn't be our plan A :)
+11:13 < geertu> Will he be at LCJ? The LCJ schedule hasn't been announced yet
+11:13 < neg> My plan is to resend the patch later this week, I got feedback from Robin Murphy so I need to fix onething in it
+11:15  * pinchartl is back
+11:15 < geertu> Ok. It's still the merge window, so people may be busy with that
+11:15 < geertu> pinchartl: Welcome!
+11:16 < geertu> Back to the mode pins...
+11:16 < geertu> So Dirk Behme is more or less pushing us to pick a solution
+11:16 < pinchartl> (quick comment about sharing DT sources between H3 and M3: maybe we shouldn't have per-soc compat strings ;-))
+11:16 < horms> pinchartl: i knew you would say that :^)
+11:17 < geertu> pinchartl: We can add them dynamically with an early DT fixup?
+11:17 < geertu> Oh well...
+11:18 < geertu> Back to the mode pins...
+11:18 < pinchartl> yes
+11:18 < pinchartl> so what's the status there ?
+11:18 < geertu> Dirk has posted updated versions of both Simon's and my proposals
+11:19 < geertu> I.e. rebased and extended to r8a7796
+11:19 < pinchartl> nice
+11:19 < pinchartl> do they both work ?
+11:19 < horms> FWIW I felt that geert's approach was cleaner.
+11:19 < geertu> He claims they do, and I don't see a reason why not.
+11:20 < pinchartl> horms: that's using syscon, right ?
+11:21 < horms> yes
+11:23 < pinchartl> I still don't like it. not such much because of the C implementation, but because referencing modemr in DT isn't a hardware description
+11:25 < pinchartl> feel free to voice your disagreement with that opinion :-)
+11:25 < geertu> The CPG hardware must have a link to the mode pins though
+11:27 < pinchartl> yes
+11:27 < pinchartl> that's for sure
+11:27 < pinchartl> both the CPG and RST chapters of the datasheet list the MD pins in their external pins section
+11:28 < geertu> But the RST is responsible for latching them ("Latching of the levels on mode pins when PRESET# is negated")
+11:31 < pinchartl> yes, but that's not related to the modemr register per-se
+11:32 < pinchartl> if the values of the MD pins were scattered across several registers
+11:32 < pinchartl> or made accessible in an even more complex way to software
+11:32 < pinchartl> would you still put the access logic in each driver that needs to know the value of the modemr pins ?
+11:33 < pinchartl> that's what bothers me, boot mode configuration should be a system service, not something that is hacked by each driver
+11:33 < pinchartl> of course in this case accessing the register is simple
+11:33 < geertu> No, we'd provide an API.
+11:33 < horms> So the way that I see things is this: On the one hand pushing things out to DT seems to lead to a cleaner implementation in software. But on the other hand it might be cleaner from a design point of view not to have this information in DT at all.
+11:33 < pinchartl> but what if you needed to enable clocks to access that register ?
+11:33 < pinchartl> or power domains ?
+11:34 < pinchartl> we could argue that accessing the information is simple and that we don't need an API now
+11:34 < pinchartl> we could implement an API later
+11:34 < pinchartl> but we'd be stuck with the syscon method for all existing socs
+11:34 < geertu> Let's stick the API in include/linux/soc/renesas/rcar-rst.h for now?
+11:35 < pinchartl> horms: yes, for our current use cases, it's easier to use rst,modemr than designing a new API
+11:35 < geertu> And the driver in drivers/soc/renesas/rcar-rst.c?
+11:35 < pinchartl> geertu: I'd be fine with that
+11:35 < pinchartl> that can be changed later if needed without any DT ABi breakage
+11:36 < geertu> A generic API for all SoCs and architectures can still be done on top of that later
+11:37 < pinchartl> if that's fine with everybody it's fine with me
+11:38 < horms> I think I am fine with it
+11:38 < geertu> Yep
+11:38 < pinchartl> we would (at least temporarly) lose the ability to use the CPG on a non-Renesas platform, but I doubt that's a problem :-)
+11:38 < geertu> I'll write it down in the meeting minutes, and we can let the idea cook for a few more days
+11:39 < horms> good plan
+11:39 < horms> pinchartl: i don't think that is a problem either :)
+11:39 < geertu> OK, case closed... Finally...
+11:40 < pinchartl> :-)
+11:40 < geertu> pinchartl: I have a few more questions about core tasks
+11:41 < geertu> RCAR-DMAC,v4.7,plan,laurent,Fix atomic DMA memory pool exhaustion
+11:41 < geertu> RCAR-DMAC,v4.7,plan,laurent,Pick up the patches, fix the DMA engine API and save the world
+11:42 < geertu> Given you don't have a core task this quarter, that's gonna be v4.8/v4.9?
+11:42 < pinchartl> let me check
+11:44 < pinchartl> for the first task, Vinod has picked the patch
+11:44 < pinchartl> it hasn't been merged in mainline yet though but I assume it will before the end of the merge window
+11:44 < pinchartl> let me check linux-next
+11:45 < pinchartl> it's not in linux-next either :-/
+11:45 < geertu> pinchartl: Indeed, that's what I thought too
+11:46 < horms> Vinodっぽい
+11:46 < geertu> And, wasn't this an improvement, not a complete fix?
+11:47 < pinchartl> I can't see the patch in Vinod's tree either
+11:48 < pinchartl> it depends what you mean by complete fix
+11:48 < geertu> Vinod did say "applied"
+11:49 < pinchartl> I'd still like to improve the DMA engine API to allow reusing requests
+11:49 < pinchartl> but that's a major change
+11:49 < pinchartl> without changing the API, that patch is the best we can do
+11:49 < pinchartl> yes, Vinod said applied
+11:51 < geertu> ok
+11:51 < geertu> Will you kick him, or shall I do?
+11:51 < pinchartl> I've just did
+11:51 < geertu> OK
+11:52 < pinchartl> for the second task, please move it to v4.8/v4.9
+11:52 < geertu> ok
+11:52 < geertu> shmobile_defconfig,v4.7,public,laurent,Enable CONFIG_CMA=y
+11:52 < geertu> This one is interesting, it started for v4.4, and I can't seem to find it was ever sent?
+11:53 < pinchartl> I had completely forgotten about it
+11:54 < pinchartl> I can't even remember I've posted a patch for that :-)
+11:54 < geertu> It entered with status "public" in peripelist
+11:54 < geertu> However, OHCI-PCI doesn't seem to work with CONFIG_DMA_CMA=y
+11:55 < horms> "CMA" draws a blank in patchwork
+11:56 < geertu> I'll change it to shmobile_defconfig,v4.8,plan,laurent,Enable CONFIG_CMA=y
+11:56 < geertu> SMP,v4.7,documented,laurent,Add DT SMP/APMU support for new SoCs (r8a7793/r8a7794)
+11:57 < geertu> Shall I take this over? Magnus posted patches for that, and I have updated versions in my local tree.
+11:57 < pinchartl> please do
+11:57 < geertu> OK
+11:58 < pinchartl> for CONFIG_CMA, can you point me to the e-mail thread ?
+11:58 < geertu> which e-mail thread?
+11:59 < geertu> "[Bug]:Koelsch: DU, Could not show an image or picture on HDMI display."?
+11:59 < pinchartl> well, you said I've submitted a patch ?
+12:00 < geertu> IIRC this was originally an action item from the meeting in Dublin after ELCE
+12:00 < geertu> No, peripelist says "public", but I think that was a mistake during the initial peripelist creation
+12:00 < pinchartl> ah ok
+12:01 < pinchartl> that makes more sense
+12:01 < pinchartl> so the only issue is that OHCI-PCI breaks with CMA ?
+12:01 < geertu> That's what I noticed when looking into Hiep-san's report
+12:03 < pinchartl> ok
+12:03 < pinchartl> isn't that an I/O task then ? :-)
+12:03 < geertu> Yep, will kick Wolfram
+12:05 < geertu> I think we're done (and overdue)?
+12:06 < pinchartl> yes
+12:06 < horms> Only update from my side is that basic M3-W support is progressing. I expect to accept my own patches soon.
+12:06 < shimoda> yes
+12:07 < geertu> Thanks for your attention span!
+12:07 < geertu> Have a nice continued day!
+12:07 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
+12:07 < horms> bye
+12:07 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi
+12:08 < uli___> bye
+12:08 < shimoda> bye!
+12:09 < khiemnguyen> nice day. bye.
+12:09 -!- shimoda [~shimoda@relprex2.renesas.com] has quit [Quit: WeeChat 0.4.2]
+12:09 < neg> thanks, bye
+