diff options
Diffstat (limited to 'wiki/Chat_log/20160628-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20160628-core-chatlog | 287 |
1 files changed, 287 insertions, 0 deletions
diff --git a/wiki/Chat_log/20160628-core-chatlog b/wiki/Chat_log/20160628-core-chatlog new file mode 100644 index 0000000..68be471 --- /dev/null +++ b/wiki/Chat_log/20160628-core-chatlog @@ -0,0 +1,287 @@ +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 |