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

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