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