wiki: Porting wiki: Porting Chat Log

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

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