1 files changed, 204 insertions, 0 deletions
diff --git a/wiki/Chat_log/20160412-core-chatlog b/wiki/Chat_log/20160412-core-chatlog
new file mode 100644
index 0000000..1ad0e29
--- /dev/null
+++ b/wiki/Chat_log/20160412-core-chatlog
@@ -0,0 +1,204 @@
+Core-chat-meeting-2016-04-12
+
+10:10 < geertu> Agenda:
+10:10 < geertu> 1. Upcoming Gen3 development for the Core group,
+10:10 < geertu> 2. Firmware upgrade and consequences (hotplug, DDR, ...)
+10:10 < geertu> 3. Does it make sense to have "renesas,cpg = <&cpg_clocks>;" in the SYSC device node? Or do we want to avoid that at all cost?
+10:10 < geertu> 4. Status check for tasks from last meeting - what is remaining?
+10:10 < geertu> horms: So that would mostly by Topics 1 and 2?
+10:10 < geertu> s/1 and 2/2 and 3/?
+10:10 < geertu> Topic 2. Firmware upgrade and consequences (hotplug, DDR, ...)
+10:10 < geertu> horms: You've already tried v2.7.0?
+10:10 < horms> geertu: yes, i lightly tested it
+10:11 < horms> hotplug appears to work as per my email
+10:11 < khiemnguyen> For topic 2, what is current version that all are using ? Yocto v2.3.0 ?
+10:11 < horms> so that seems positive
+10:11 < geertu> v2.5.0, IIRC
+10:11 < geertu> Any known regressions?
+10:11 < khiemnguyen> yes, hotplug has been able to work from Yocto v2.4.0
+10:11 < horms> n.b. firmware version != yocto version
+10:12 < horms> I think geert was referring to the former
+10:12 < geertu> khiemnguyen: Only the first time. After hot-unplug, hot-plug no longer works in v2.5.0
+10:12 < horms> _I_ am not aware of any regressions
+10:12 < khiemnguyen> you tried with CPU0, right ?
+10:12 < horms> let me check
+10:12 < khiemnguyen> CPU0 has a limitation for CPU Hotplug, since the secure side will run some secure services in CPU0 all the time.
+10:13 < khiemnguyen> Please try CPU Hotplug with CPU1/2/3 only.
+10:13 < horms> I only tried CPU1
+10:13 < horms> What happens on CPU0?
+10:14 < khiemnguyen> the secure side will run some secure services in CPU0 all the time.
+10:14 < khiemnguyen> CPU0 should not be hotplug.
+10:14 < horms> ok
+10:15 < horms> so if it is unplugged we might see some problems? like undefinded behaviour?
+10:15 < khiemnguyen> so if it is unplugged we might see some problems? like undefinded behaviour?  --> yes.
+10:16 < geertu> Hmm...
+10:16 < geertu> It would be better if the operation just failed with an error code
+10:16 < horms> yes, i think we should disallow it somehow
+10:16 < geertu> Else we have to explicitly have a check to prevent the user from doing that
+10:17 < horms> oh, you mean the fimrware should return an error?
+10:17 < khiemnguyen> Yes. But the firmware has not supported that feature yet.
+10:18 < geertu> horms: Yes, I mean the firmware
+10:18 < khiemnguyen> Therefore, in in-house BSP, I have created a work-around patch to disable CPUHotplug request in CPU0.
+10:18 < pinchartl> as it's a firmware requirement that CPU0 can't be unplugged, it would make sense for the firmware to implement the check
+10:18 < horms> khiemnguyen: ok. good to know. do you know if that is planned?
+10:19 < khiemnguyen> as it's a firmware requirement that CPU0 can't be unplugged, it would make sense for the firmware to implement the check  ---> but they put it as low-priority now. since we also has a work-round patch in Linux kernel.
+10:19 < horms> ok. but from an upstream point of view it seems like a priority. could you pass that information on?
+10:19 < geertu> khiemnguyen: if we include the workaround in upstream, ideally it should check for the firmware version, to know when to apply it or not.
+10:20 < geertu> And the question remains where in the code to put the check (no board code)
+10:20 < khiemnguyen> do you know if that is planned?  ---> official support in firmware might be available by E/this year, I heard.
+10:20 < pinchartl> geertu: I'd keep the workaround away from upstream
+10:21 < pinchartl> upstreaming CPU hotplug would then require a firmware that supports hotplug properly
+10:21 < pinchartl> putting some pressure to implement that :-)
+10:21 < khiemnguyen> And the question remains where in the code to put the check (no board code)  ---> huhm..., to check firmware version, we need more than that, need optee linux driver to communicate with secure side.
+10:21 < geertu> pinchartl: Even better. Except that we alrady have hotplug in upstream/
+10:21 < horms> pinchartl: fwiw, CPU hotplug is already upstream
+10:22 < pinchartl> well, fixing it upstream then I suppose :-)
+10:22 < khiemnguyen> yeah, CPU Hotplug is already supported in usptream, for CPU1/2/3, given that the firmware is taken from Yocto v2.4.0 or later.
+10:24 < geertu> Things like CPU hotplug are enabled automagically once you have a PSCI platform.
+10:24 < geertu> Whether they work or not is a different issue...
+10:24 < shimoda> FYI, khiem-san's workaround is 9c910ad5a1e60b302e88ef394bcff84018e69adc in renesas-bsp.git
+10:25 < horms> khiemnguyen: is there any possibility we could ask for the feature to be in firmware sooner than later. it would really help things on the upstream side.
+10:26 < geertu> BTW, what's "DDR training"?
+10:26 < khiemnguyen> Let me know the feature, will try to confirm with secure team.
+10:27 < horms> khiemnguyen: thanks. I think the feature request is to return an error for a request to take CPU0 down.
+10:27 < horms> so long as doing so causes problems.
+10:27 < khiemnguyen> DDR training is rountine activity to check SDRAM operation and adjust SDRAM parameters for best performance.
+10:27 < pinchartl> geertu: it's automatic detection (and configuration) of the DDR memory controller to take into account board design
+10:27 < pinchartl> including traces length for instance
+10:28 < geertu> OK, thx
+10:28 < geertu> Another issue with the firmware upgrade was "secret" DDR clock frequency
+10:29 < geertu> which requires public changes in the r8a7795 CPG/MSSR driver.
+10:29 < pinchartl> "Typically, a data training sequence is performed at startup to find the optimum position for the DQS input buffer enable signal.  This can be accomplished by performing reads with deterministic patterns while sweeping through the possible system latency values."
+10:29 < pinchartl> (http://www.design-reuse.com/articles/13805/the-love-hate-relationship-with-ddr-sdram-controllers.html)
+10:30 < khiemnguyen> "secret" DDR clock frequency --> 2400 ?
+10:30 < horms> geertu: my understanding is that there are some hw bugs relating to DDR. and that a resolution is not at hand at this time. iirc only 2400 works at this time. (my memory may be entirely faulty on this topic)
+10:32 < geertu> khiemnguyen:yes, 2400, cfr.
+10:32 < geertu> BSP kernel
+10:32 < geertu>    MD19 MD17 : PLL3 mult
+10:32 < geertu>    -------------------------------
+10:32 < geertu>      1    0  : x144 (for DDR2400)
+10:32 < geertu>      1    1  : x192 (for DDR1600)
+10:32 < khiemnguyen> Currently, let's keep using DDR1600.
+10:32 < geertu> khiemnguyen: That's an option? Morimoto-san said 1600 didn't work with v2.7.0
+10:33 < khiemnguyen> geertu: I have no issues here.
+10:34 < geertu> OK
+10:34 < geertu> So we should upgrade to v2.7.0 now?
+10:34 < khiemnguyen> geertu: I think so. Any issues, please let me know, I will support.
+10:36 < khiemnguyen> Here, the boards are set with DDR1600, and we have already did many development in v2.7.0. Just to make sure to re-write all IPL, u-boot and rootfs from Yocto v2.7.0
+10:37 < geertu> update_salvator_bootloader_v270-4core.tar.bz2 or update_salvator_bootloader_v270-8core.tar.bz2?
+10:37 < horms> fwiw I used the 4core variant
+10:37 < horms> as i was unsure
+10:37 < khiemnguyen> 4core
+10:38 < geertu> what happens with 8core?
+10:38 < khiemnguyen> 8core support is in-progress. still need more work to stabilize 8core...
+10:38 < geertu> OK
+10:38 < geertu> Let's move on...
+10:38 < geertu> Topic 3. Does it make sense to have "renesas,cpg = <&cpg_clocks>;" in the SYSC device node? Or do we want to avoid that at all cost?
+10:39 < geertu> This is about getting the SYSC driver in ASAP, as it's a dependency for DU/VSP
+10:39 < pinchartl> geertu: as mentioned yesterday, I'd prefer not having it
+10:39 < geertu> pinchartl: The night brought me some advice.
+10:40 < geertu> BSP kernel
+10:40 < geertu>    MD19 MD17 : PLL3 mult
+10:40 < geertu>    -------------------------------
+10:40 < geertu>      1    0  : x144 (for DDR2400)
+10:40 < geertu> oops, wrong paste
+10:40 < geertu>   - compile-time:
+10:40 < geertu>       - #define cpg_mstp_attach_dev NULL if CPG/MSTP driver is not included
+10:40 < geertu>       - #define cpg_mssr_attach_dev NULL if CPG/MSSR driver is not included
+10:40 < geertu>     Either by:
+10:40 < geertu>       - #ifdef on all SoCs 
+10:40 < geertu>       - introduce Kconfig symbol that's selected by all SoCs that use it
+10:40 < geertu>   - run-time: Check for presence of "renesas,cpg-mstp-clocks" to select between
+10:40 < geertu>     cpg_mstp_attach_dev and cpg_mssr_attach_dev
+10:41 < geertu> That would more or less be the way it was done in v3 of my series
+10:41 < geertu> And it's backwards-compatible.
+10:41 < pinchartl> sounds good to me
+10:41 < geertu> It does require exporting cpg_mssr_attach_dev, like in v3
+10:42 < pinchartl> I'm fine with that
+10:43 < geertu> I would prefer not to introduce Kconfig symbols for MSTP and MSSR (currently it's handled in the Makefile), but as I'll have to duplicate the logic in both Makefile and header file, I think that's the best option
+10:44 < pinchartl> it would be internal Kconfig options only, right ?
+10:44 < pinchartl> nothing directly user-selectable ?
+10:45 < geertu> And with the -EPROBE_DEFER trick in cpg_mssr_attach_dev (cfr. v3), there can be a single point of initialization again, and I think we won't loose sound and SPI DMA due to wrong initialization order anymore.
+10:45 < geertu> Yes, internal symbols (default y if CONFIG_ARCH_<soc>)
+10:46 < geertu> OK, will go for it. Won't be in today's renesas-drivers, but I'll provide an integration branch including it
+10:47 < geertu> Topic 1. Upcoming Gen3 development for the Core group
+10:47 < pinchartl> thank you
+10:48 < geertu> Any updates for the discussion topics targeted at v4.6?
+10:48 < morimoto> BTW, geertu, thank you for your help about peripelist
+10:49 < geertu> morimoto: You're welcome
+10:52 < khiemnguyen> Any upcoming Power Management feature, beside CPUHotplug and RuntimePM ?
+10:54 < geertu> khiemnguyen: Is PSCI reboot supported/planned?
+10:54 < khiemnguyen> geertu: already supported.
+10:54 < khiemnguyen> Please try with Yocto v2.7.0
+10:54 < geertu> khiemnguyen: Do you know as of which version?
+10:54 < geertu> OK
+10:55 < khiemnguyen> Maybe, reboot has already able to work from Yocto v2.5.0.
+10:57 < geertu> Any other upcoming development?
+10:57 < pinchartl> I'll post a small rcar-dmac fix, nothing big
+10:57 < khiemnguyen> I prefer CPUFreq, changing CPU0/1/2/3 frequency.
+10:58 < morimoto> pinchartl: is it suspend/resume issue ? or list_add issue ?
+10:58 < geertu> OK
+11:00 < pinchartl> morimoto: list_add
+11:01 < pinchartl> morimoto: is there a suspend/resume issue with rcar-dmac ?
+11:03 < morimoto> pinchartl: I reported it to you before ;)
+11:03 < morimoto> let me check
+11:05 < morimoto> anyway pinchartl, geertu, can you add this issue to peripelist ?
+11:05 < morimoto> this issue -> list_add
+11:06 < geertu> morimoto: Do you have a better description than "rcar-dmac list_add issue"?
+11:07 < morimoto> pinchartl: can you do it ?
+11:07 < morimoto> it is related to rcar-dmac memory control
+11:07 < pinchartl> geertu: there's an atomic DMA memory pool exhaustion due to how DMA descriptors are reused
+11:08 < pinchartl> every DMA descriptor needs DMA memory for hardware descriptors
+11:08 < pinchartl> and the driver keeps that memory allocated until the channel is release for performance reason
+11:09 < pinchartl> when recycling a completed DMA descriptor, the driver puts it back at the end of the list of the free descriptors
+11:09 < pinchartl> and will thus end up allocating DMA memory for all of them, even if only a few are in flight at the same time
+11:10 < pinchartl> adding the descriptor to the front of the list will make it better
+11:10 < geertu> Adding "RCAR-DMAC,v4.7,plan,laurent,Fix atomic DMA memory pool exhaustion
+11:10 < morimoto> pinchartl: but it is for quick-hack verion, not formal fix ?
+11:10 -!- horms2 [~horms@g1-27-253-251-6.bmobile.ne.jp] has joined #periperi
+11:11 < horms> I have to wander off now. horms2 is me on my mobile. I may or may not be able to track the rest of the meeting there.
+11:12 < morimoto> pinchartl: sorry suspend/resume was vsp1 side issue
+11:12 < morimoto> geertu: thank you
+11:12 -!- horms [~horms@pd2fa4006.osaknt01.ap.so-net.ne.jp] has quit [Quit: Leaving]
+11:12 < geertu> horms2: OK, have a nice flight!
+11:13 < pinchartl> morimoto: it's a quick hack indeed, but I don't expect a long-term solution before, well, long :-)
+11:13 < pinchartl> morimoto: thought so about the suspend/resume issue :-)
+11:14 < geertu> Topic 4. Status check for tasks from last meeting - what is remaining?
+11:14 < geertu> "add r8a7795 drive-strength support" is public (and queued in sh-pfc-for-v4.7)
+11:16 < geertu> "Investigate SYS-DMAC2" is apparently a bootloader issue. 
+11:16 < geertu> shimoda: Do you know if this is fixed in v2.7.0?
+11:16 < shimoda> about "r8a7795,v4.7,prototype,shimoda,Investigate SYS-DMAC2", this will be fixed if we use the v2.8.0 firmware
+11:16 < geertu> OK (ah, typing concurrently ;-)
+11:16 < shimoda> v2.8.0 will be released by end of this month
+11:17 < shimoda> geertu: yes :)
+11:17 < geertu> Can we drop the "
+11:18 < geertu> Can we drop the "Add support for valuable devices to multi-platform r8a7778/9" tasks?
+11:18 < geertu> Any items left?
+11:18 < neg> thanks to a good talk with Laurent during ELC I have a way forward for DMAC+IPMMU
+11:18 < geertu> (i.e. mark as completed)
+11:19 < geertu> uli: I remember a pinctrl-single patch for BOCK-W FPGA that Laurent objected against but that was needed for Ethernet? Ethernet still works without it though?
+11:20 < uli___> i have not actually tried that, i think
+11:20 < shimoda> about Gen3 IPMMU, we also should use v2.8.0 because the default setting is not good for linux environment
+11:20 < shimoda> s/use v2.8.0/use v2.8.0 firmware/
+11:22 < neg> silly question, where can I find v2.8.0 firmware? Looked in the yocto repo I know of but that states BSP version 1.9.7
+11:22 < geertu> "< shimoda> v2.8.0 will be released by end of this month"
+11:22 < neg> ahh ok :)
+11:23 -!- khiemnguyen [d2a0fca9@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.169] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
+11:24 -!- khiemnguyen [d2a0fca9@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.169] has joined #periperi
+11:25 < horms2> geertu: I think they are also covered by some integration tasks. depending on your definition of interestingly they are not finished afaik
+11:27 < geertu> horms2: s/interestingly/valuable/, I assume?
+11:27 < horms2> yes, that is what I meant :)
+11:27 < morimoto> neg: not yet v2.8.0
+11:27 < geertu> Never trust spelling autocorrect on a mobile device ;-)
+11:28 < geertu> I think we're done? Anything I missed?
+11:28 < horms2> or my typing skills!
+11:29 < horms2> not from me. is dammsan still online?
+11:30 < geertu> He is, but he's quiet
+11:30 < horms2> ok. I will be quite too
+11:31 < geertu> Thanks for joining, and have a nice continued day/evening/morning!
+11:31 < geertu> or flight...
+11:31 < dammsan> thanks guys
+11:31 < neg> thanks all, bye
+11:32 < shimoda> thank you!, bye
+11:32 < uli___> bye
+11:32 < morimoto> bye