From 55e3b2f45880faaf06f3c660ca9e8a6d9aa14bce Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Mon, 9 Dec 2019 15:29:52 +0900 Subject: wiki: Porting wiki: Porting Chat Log Signed-off-by: Kuninori Morimoto --- wiki/Chat_log/20160524-core-chatlog | 255 ++++++++++++++++++++++++++++++++++++ 1 file changed, 255 insertions(+) create mode 100644 wiki/Chat_log/20160524-core-chatlog (limited to 'wiki/Chat_log/20160524-core-chatlog') 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 + -- cgit v1.2.3