path: root/wiki/Chat_log/20160628-core-chatlog

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