Core-chat-meeting-report 2016-06-28 ----------------------------------------- Topic 1. Upcoming Gen3 development for the Core group - Geert: - Updated APMU patch series - r8a7796 SYSC has been pulled by Simon - r8a7796 CPG/MSSR is still in clk limbo - Simon: Basic integration for r8a7796 is done - Ulrich will test his r8a7796 patches on hardware soon - Khiem will send v2 of the CPUFreq patches in early July ----------------------------------------- Topic 2. CPG DTS clean up ("clock-output-names", CPG/MSSR, ...) 1. Can we do something to clean up the 32-bit ARM SoCs? 2. Can we make new SoC support slightly cleaner? 3. Shall we jump directly to CPG-MSSR for new SoCs and clean up the rest of the R-Car Gen2 family? Moving to CPG-MSSR is an option, but needs cleanup of MODEMR handking first. Related questions from Morimoto-san, with discussed answers: 1. How to handle MODEMR register on rcar-gen3-cpg.c ? It has fixed address on C code. We would like to know its plan [PATCH/RFC v3 00/22] soc: renesas: Add R-Car RST driver for obtaining mode pin state (http://www.spinics.net/lists/linux-renesas-soc/msg04289.html) 2. ESx.y handling. Some device needs to care about its ESx.y number, and (unfortunately) we need it on upstream. We already agreed about this handling by using "compatible" string on DT in previous (?) PeriPeriCon. And according to Magnus, Geert already has a patch to expend "compatible" strings when boot time automatically ? We would like to know its plan [PATCH/RFC 0/1] soc: renesas: Add DT fixup code for backwards compatibility (https://lkml.org/lkml/2016/6/1/742) Development of those two patch series will continue... ----------------------------------------- Topic 3. Status check for tasks from last meeting - what is remaining? - Simoda-san will document Gen3 firmware requirements on the eLinux wiki - Niklas sent out v8 of DMAC+IPMMU, waiting for ack from Russell ----------------------------------------- Core-chat-meeting-2016-06-28 ----------------------------------------- 10:01 < geertu> Welcome to today's Renesas Core Group Meeting 10:02 < horms> I need to take a break from ~11:00 - ~11:15 as I'm at a conference. Apologies for any inconvenience that may cause. 10:02 < geertu> I'm also at a remote place, due to planned work on the powerline infrastructure in my street. 10:02 < geertu> Agenda: 10:02 < geertu> 1. Upcoming Gen3 development for the Core group, 10:02 < geertu> 2. CPG DTS clean up ("clock-output-names", CPG/MSSR, ...) 10:02 < geertu> 3. Status check for tasks from last meeting - what is remaining? 10:03 < geertu> I want to repost the slightly updated APMU series. 10:03 < geertu> I wanted to give the ARM people one more day to ack the enable method binding, but in the mean time Simon closed his tree :-( 10:04 < geertu> horms: Can you still make an exception, or does it have to wait for v4.9? 10:04 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi 10:04 < horms> actually i announced I will close it tomorrow 10:05 < horms> and this seems to be a worthy exception in any case 10:05 < horms> If you could finalise the patches today that would be great 10:05 < horms> Is that possible? 10:05 < geertu> horms: Oh cool, right you are in my time zone ;-) 10:05 < horms> sorry for not making that clearer 10:05 < horms> yes, i'm in your zone this week and next 10:05 < geertu> I'll do my best (once the power is back etc.) 10:06 < horms> will there be soc changes that are dependencies for DT changes (sorry, its a while since I looked over the patches) 10:06 < morimoto> horms: can you send email to us about your new address / phone ? 10:07 < geertu> horms: Of course, there are always such dependencies when moving functionality from C to DT :-( 10:07 < geertu> horms: BTW, any feedback on "[PATCH v2 0/5] ARM: dts: renesas: Update console parameters"? 10:07 < horms> morimoto: sure, i have an address now. I assume you want both the address in Amsterdam and the one in Kobe 10:07 < horms> geertu: sorry for sitting on those console changes 10:07 < morimoto> horms: Yes please 10:08 < horms> basically I am ok with them because they don't touch any important SoCs from a BSP/customer PoV 10:08 < geertu> horms: And we made the same change for the important SoCs anyway 10:08 < horms> I will see about queuing them up unless there are objections - e.g. right now 10:08 < geertu> OK, thx. 10:09 < horms> geertu: yes, I know. Those changes were more carefully planned than is obvious from examining git log 10:09 < horms> with regards to SoC->DT changes. Thanks, I will mentally prepare for that. 10:10 < geertu> Any other Upcoming Gen3 development for the Core group? 10:11 < horms> Is r8a7796 PFC core? 10:11 < geertu> (shall I write a script for random interrogation, like Wolfram did?) 10:11 < geertu> Yes, PFC is core 10:12 < horms> From me the Basic integration I had scheduled seems to be done. I anticipate more integration in the near future. But the details are under discussion (with you :) 10:12 < horms> uli___: are you handling PFC for r8a7796 these days? 10:12 < uli___> yes 10:12 < geertu> I'm afraid it's gonna miss today's renesas-drivers 10:13 < uli___> i have to wait to get remote access to m3-w to try it, at least once :) 10:14 < horms> ok, what is the hold-up there? 10:14 < uli___> i only asked for it an hour ago :( 10:14 < horms> ok 10:15 < dammsan> actually 25 minutes ago according to my email 10:15 < geertu> r8a7796 SYSC has been pulled by Simon 10:15 < geertu> r8a7796 CPG/MSSR is still in clk limbo 10:16 < geertu> dammsan: Are you travelling close to light speed? ;-) 10:17 < dammsan> well, i usually track days and not minutes =) 10:19 < geertu> Any other Upcoming Gen3 development for the Core group? 10:20 -!- 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] 10:20 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi 10:21 < dammsan> I wonder what happened with that timer issue simon was debugging with the JTAG 10:22 < dammsan> and if it is the same thing that Geert is chasing RCU with? 10:22 < horms> I reached a dead end with my investigation there 10:22 < geertu> Was that emev2/kzm9d? 10:22 < horms> At this point I still have the JTAG (2) but no board. 10:22 < horms> yes, it was 10:22 < geertu> neg: Do you have JTAG? 10:24 < neg> I have a cheep clone not sure how good it is 10:24 < geertu> sheep or cheap? 10:24 < neg> used it for Cortex-M3 work so not sure if it works for Renesas boards, but if there is work I will buy one that works 10:24 < dammsan> neg: i can bring one to you if you happen to be in sweden 10:25 < dammsan> or you may as well get a new one 10:25 < geertu> Paul had some more suggestions to try, but I haven't found time for that yet. 10:25 < dammsan> geertu: can it be related to shared-override cache handling? 10:25 < geertu> And for me the board is remote. And doesn't do earlycon. 10:25 < neg> dammsan: yes I'm in Stockholm until it's time to go to Tokyo 10:26 < dammsan> neg: i'll bring one then 10:26 < dammsan> i'm leaving here on thursday 10:26 < geertu> dammsan: There's no pl310 cache controller 10:26 < geertu> But you do remind me that I should try with more errata config options enabled. 10:27 < dammsan> only l1? 10:27 < geertu> I think so. There's no L2 in DT. 10:27 < dammsan> hm... 10:27 < dammsan> but it should only affect things if we have bus mastering drivers 10:28 < dammsan> which we dont i think 10:28 < dammsan> only PIO 10:28 < geertu> Yes 10:28 < neg> dammsan: sure name a time and place and I can come and pick it up 10:28 < dammsan> adding earlycon may be rather simple 10:28 < dammsan> neg: thanks will do 10:29 < geertu> Next topic? 10:29 < geertu> Topic 2. CPG DTS clean up ("clock-output-names", CPG/MSSR, ...) 10:29 < geertu> 1. Can we do something to clean up the 32-bit ARM SoCs? 10:29 < geertu> 2. Can we make new SoC support slightly cleaner? 10:29 < geertu> 3. Shall we jump directly to CPG-MSSR for new SoCs and clean up the rest of 10:29 < geertu> the R-Car Gen2 family? 10:30 < geertu> This was proposed by Magnus for last meeting, but we didn't cover it due to lack of time, and lack of Magnus 10:30 < dammsan> =) 10:31 < geertu> We can definitely move to CPG-MSSR. The conversion is not that difficult, and easy to verify using /sys/kernel/debug/clk/clk_summary 10:31 < geertu> It does depend on sorting out the MODEMR accesses. 10:31 < geertu> One of them (arch timer frequency) has been removed. 10:32 < dammsan> geertu: we can keep old CPG + MSTP drivers around too for DT compatibility, right? 10:32 < geertu> dammsan: Yes we can. 10:33 < geertu> It's just that the current scheme of calling into the CPG driver from arch/arm/mach-shmobile to pass the mode pin state doesn't fly when you have two possible drivers to call into. 10:33 < dammsan> yeah 10:33 < dammsan> i never liked that one 10:33 < dammsan> and i tried to encourage people to do something else 10:33 < geertu> Yeah, we should have called into platform code from the clk driver instead. 10:34 < geertu> The second user of the mode pins is MD21 checking for SMP bringup. 10:34 < dammsan> yeah 10:34 < geertu> Which we should be able to remove soon too, thanks to Sergei diving into BSP codde. 10:34 < dammsan> uhm... 10:34 < geertu> According to the datasheet, these bits can be written to regardless of debug mode, so there's no need to check M21 10:35 < geertu> (in theory) 10:35 < dammsan> this kind of discussion would take some time i think 10:35 < dammsan> for the SMP bits 10:35 < dammsan> but i wish sergey the best of luck 10:35 < geertu> morimoto-san: Do you know why the BSP writes into the undocumented bits of CA7DBGRCR? 10:35 < dammsan> but regardless 10:36 < dammsan> we do need some mode pin handling, no? 10:36 < geertu> Sure. 10:36 < geertu> [PATCH/RFC v3 00/22] soc: renesas: Add R-Car RST driver for obtaining mode pin state 10:36 < dammsan> what's the latest state with that? 10:36 < geertu> http://www.spinics.net/lists/linux-renesas-soc/msg04289.html 10:36 < morimoto> geertu: I'm not sure. Do you want me to ask BSP team ? 10:36 < geertu> Got some acks from people (all renesas-soc related only) 10:37 < geertu> morimoto: Yes, BSP and hardware people. 10:37 < dammsan> does it cover the product register too? 10:37 < dammsan> or will that be a different driver? 10:38 < geertu> ESx.y is something different. Albeit related, as it involves modifying the passed device tree. 10:38 < horms> geertu: is the missing piece and Ack from Mark Rutland 10:38 < dammsan> geertu: sure, just wonderig if the ESx.y detection register is in the RST range 10:38 < dammsan> hopefully not 10:38 < geertu> horms: No, from the reset maintainer. Which probably doesn't feel much involved, as the driver doesn't implement reset functionality 10:39 < geertu> dammsan: No, PRR is a completely different register. 10:39 < dammsan> geertu: ok good 10:39 < horms> ok. should we try to get that ack 10:39 < horms> or do we need more discussion 10:39 < horms> this issue seems to have been going around for a while 10:39 < horms> I for one had a go at it 10:39 < horms> I think this is your second attempt 10:40 < geertu> To make backward compatibility easier, I want to modify the device tree and add RST, SYSC, and APMU nodes if they're missing. 10:40 < geertu> Which brings us to 10:40 < geertu> [PATCH/RFC 0/1] soc: renesas: Add DT fixup code for backwards compatibility 10:40 < geertu> https://lkml.org/lkml/2016/6/1/742 10:40 < geertu> That one implements adding the RST node only, but it can be extended for ESx.y handling. 10:40 < dammsan> geertu: can't you merge those in -staging to begin with? 10:40 < geertu> Then the PRR is hidden there. 10:41 < dammsan> geertu: thanks, i understand 10:42 < geertu> dammsan: staging? Lately Greg refused adding a new driver to staging, as he was wondering about a plan to get it out of staging 10:42 < dammsan> geertu: then plan would be to get it out once the reset maintainer agrees 10:42 < dammsan> or something =) 10:42 < geertu> Yes. Unless someone disagrees. 10:42 < dammsan> so do we need to add more reset functionality ? 10:43 < geertu> I don't think so. 10:44 < dammsan> ok fine with me =) 10:44 < geertu> It's called "reset controller", but it seems to differ from what Linux expects. 10:44 < morimoto> geertu: can I confirm ? what is your question about CA7DBGRCR ? 10:44 < horms> I'd vote for trying to get it merged not in staging unless we see a difficulty in achieving that 10:45 < geertu> renesas-backports/bsp/v3.10.31-ltsi/rcar-gen2-1.9.7:arch/arm/mach-shmobile/:smp-r8a7790.c: writel_relaxed((val | 0x01f83330), p + CA7DBGRCR); 10:45 < geertu> renesas-backports/bsp/v3.10.31-ltsi/rcar-gen2-1.9.7:arch/arm/mach-shmobile/:smp-r8a7794.c: writel_relaxed((val | 0x01f83330), p + CA7DBGRCR); 10:45 < geertu> morimoto: The 0x3330 part writes to undocumented bits 10:47 < morimoto> geertu: OK thanks. will ask 10:47 < geertu> morimoto: Thank you 10:48 < geertu> OK, I will refresh the RST series and resend (for v4.9) 10:48 < geertu> For the DT fixup, there were some review comments. 10:48 < dammsan> geertu: does it make sense to change the "old" CPG driver to use the new RST driver? 10:48 < geertu> And it will need changes to modify the DT before SMP bringup. 10:49 < dammsan> or is it better to jump to CPG-MSSR directly? 10:49 < geertu> dammsan: If we want to support old DT, the old CPG driver has to stay alive. 10:49 < dammsan> yes 10:50 < dammsan> but adding more dependencies to the old code may be just pure pain 10:50 < geertu> dammsan: Either it has to absorb the code to read MODEMR itself, or call into the RST driver. 10:50 < dammsan> (regarding adding some plink to the reset controller) 10:50 < geertu> There won't be a plink. 10:50 < geertu> plink = phandle? 10:50 < dammsan> gotcha 10:50 < dammsan> yeah 10:51 < dammsan> i meant phandle 10:51 < geertu> It calls rcar_rst_read_mode_pins() 10:51 < geertu> which either uses the RST node in DT, or falls back to hardcoded MODEM for backward compatbility code. 10:51 < geertu> The latter can be dropped again once we do DT fixup. 10:52 < geertu> s/MODEM/MODEMR/ 10:52 < dammsan> makes sense. reducing cross-tree symbol dependencies is always nice if possible 10:53 < dammsan> in my old mode pin hack i tried to store the mode pin setting in DT 10:53 < dammsan> by modifying it duringggggggg runtime 10:53 < dammsan> but it is a bit unholy 10:53 < dammsan> at the same time bordering to your run time patching 10:53 < geertu> Ah, you just added a property with the value? 10:53 < dammsan> yep 10:54 < dammsan> no special symbols needed 10:54 < geertu> Did you add it to the FDT or the unflatted one? 10:54 < geertu> s/unflatted/unflattened/ 10:56 < dammsan> don't recall, but i used of_property_read_u32(node, "cpg-mode", &cpg_mode) in my prototype 10:57 < dammsan> see "[PATCH/RFC] clk: shmobile: DT property SoC <-> CCF interface prototype" 10:58 < dammsan> the idea was to use of_update_property() 10:58 < dammsan> not sure if that applies anymore 10:58 < dammsan> much has changed in 3 years i guess 10:59 < geertu> I think it will work 10:59 < geertu> morimoto: As you coined the MODEMR and ESx.y handling topics, do you have more questions? 11:00 < dammsan> i like removing symbol dependencies myself 11:01 < morimoto> geertu: thanks. it was not urgent. but something process happen, that is enough for me 11:02 < geertu> morimoto-san: Thanks 11:02 < geertu> Topic 3. Status check for tasks from last meeting - what is remaining? 11:03 < geertu> About "Gen3 firmware plan for special memory allocation control" 11:03 < geertu> has this been documented on the eLinux wiki? 11:04 < morimoto> Who has its ball ? 11:04 < shimoda> it's me 11:05 < shimoda> but sorry i don't write it yet 11:05 < shimoda> I will try to do it by next week... 11:06 < geertu> ok, thx 11:06 < neg> I sent out v8 of DMAC+IPMMU 3 weeks ago after Russell King had a good review comment about v7. Pinged Russell ~2 weeks ago but still no response from him. I he still have not responded early next week I will ping him again. Anyone got tips on how to get his attention? I need his Ack on the ARM part of the series to take the series to the dmaengine tree. 11:07 < neg> Vinod spoke in favor of the dmanegine bits so I'm hoping with Russells Ack this can finaly be taken upstream 11:10 < geertu> neg: Did you get any feedback on the other rcar-dmac series? 11:12 < neg> yes Russell had feedback on v7 11:14 < geertu> neg: I mean the other series, which I collected in topic/rcar-dmac-niklas 11:14 < neg> or are you talking abut the dmac cleanups? If so Laurent Acked all with a cosmetic missing blank line 11:14 < geertu> OK 11:15 < neg> is on my list to send a v2 collecting his Acks and adding the missing blank line for tomorrow, been focusing to get other work done 11:21 < horms> neg: In general the procedure with Russell is to get his approval then, if the patch is for him to accept, put it in his patch tracker 11:22 < horms> But in general I would suggest politely reposting the series and asking him to help move it forwards 11:22 < geertu> horms: In this case it's for approval, as the patch should go in through vinod 11:22 < horms> ok 11:23 < horms> I think Russell is genearlly quite busy, but reasonable when handled with care 11:23 < neg> horms: so it's better to repost the series then to send a ping to the old thread? 11:23 < horms> I guess its up to you. 11:23 < horms> But I feel a repost might be more likely to get his attention 11:24 < horms> I merged some kexec-tools patches of his recently 11:24 < horms> so hopefully we are in his good books at this time 11:24 < neg> ok thanks then I will repost the series early next week if no response by then 11:28 < geertu> Anything else to report, ask or discuss? 11:28 < horms> Not from here 11:29 < khiemnguyen> About CPUFreq patchset, I will try to send v2 in early July. Sorry for delay... 11:29 < horms> Ok, will that be targeted at v4.9? (its too late for v4.8) 11:30 < khiemnguyen> Yeah, v4.9 is good for me, if no objections. 11:31 < geertu> OK 11:32 < geertu> Thanks for joining, and C (most of) U in Tokyo