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

Core-chat-meeting-2016-12-20

09:05 < geertu> Welcome to today's core group chat!
09:06 < geertu> I had hoped for the meeting to be short, but Shimoda-san seems to have a different idea ;-)
09:07 < shimoda> oops ;)
09:08 < shimoda> about the power management discusstion, japan side should discus internally I think.
09:08 < geertu> AH, just looked at the URLs, they're not that controversial. Good.
09:08 < shimoda> especially, magnus-san doesn't know this for now
09:08 < geertu> I guess Magnus is learning Japanese now?
09:09 < shimoda> geertu: i guess so
09:09 < morimoto> He learned how to escape chat meeting
09:09 < geertu> Let's start
09:09 < geertu> Agenda:
09:09 < geertu> 1. Status updates
09:09 < geertu> 2. Power Management implementation on Upstream for R-Car (especially Gen3)
09:09 < geertu> 3. Holidays
09:10 < geertu> Topic 1. Status updates
09:10 < geertu>   A) What have I done since last time
09:10 < geertu>   B) What I plan to do till next time
09:10 < geertu>   C) Problems I have currently
09:10 < geertu> Simon is first
09:11 < horms> --- start ---
09:11 < horms> todo file update is NULL for me
09:11 < horms> Status:
09:11 < horms> A) What have I done since last time
09:11 < horms> * Analysed device tree binding status
09:11 < horms>   - Presence and use of SoC-specific and fallback compatibility strings
09:11 < horms>   - Posted some fixups
09:11 < horms>   - Posted analysis here: http://elinux.org/Bindings:Renesas
09:11 < horms> B) What I plan to do till next time
09:11 < horms> * Continue above
09:11 < horms> C) Problems I have currently
09:11 < horms> * None
09:11 < horms> --- end ---
09:12 < horms> Sorry one Q for later: >4G mem on M3-W
09:12 < geertu> OK. Noted down
09:13 < geertu> Thank you, Simon
09:13 < geertu> Next is Shimoda-san
09:13 < shimoda> yes
09:13 < shimoda> A)
09:13 < shimoda>  The core/todo doesn't have such a task but I am thinking of the workaround of IPMMU issue on Gen3 with Magnus-san.
09:13 < shimoda>   - I will make complex patches
09:14 < shimoda>   - Magnus-san will make simple patches.
09:14 < shimoda> B)
09:14 < shimoda>  Continue to make the workaround of IPMMU issue with Magnus-san.
09:14 < shimoda> C)
09:14 < shimoda>  None.
09:14 < shimoda> -- end --
09:14 < geertu> Having a workaround is definitely good to have, thanks!
09:14 < geertu> Next is Niklas
09:15 < neg> a) Posted patches for Fix Runtime PM with GPIO interrupts (depends on irqchip PM).
09:15 < neg> b) Vacation and recreate my for-renesas-drivers branch on top of v4.10-rc1 to ease integration.
09:15 < neg> c) I won't bring any Renesas hardware to the caribbean so will have a hard time testing patches.
09:15 < neg> EOT
09:16 < geertu> neg: Remote access is not fully set up yet? ;-)
09:16 < geertu> Thanks Niklas!
09:16 < geertu> Next is Morimoto-san
09:17 < neg> geertu: it's I can trun on power but not always off :-(
09:17 < morimoto> I have now asked about sound + IPMMU from BSP (?) team on Virtual OS.
09:17 < morimoto> But, not related to upsteam/ (I think)
09:17 < morimoto> A) = B) = C) = NULL
09:17 < morimoto> s/upsteam/upsteam+PeriPeri/
09:18 < morimoto> --END--
09:19 < geertu> Thank you, Morimoto-san
09:19 < geertu> Next is Geert
09:19 < geertu> --- start ---
09:19 < geertu> A)
09:19 < geertu>   - Resent memory enablement and RAVB for r8a7796/salvator-x
09:19 < geertu>   - Sent v2 of swiotlb=noforce, to disable the use of bounce buffers for
09:19 < geertu>     debugging
09:19 < geertu>   - Prepared 2017Q1 phase1 Core Additional Tasks
09:19 < geertu>       - Fix Runtime PM with GPIO interrupts (Niklas)
09:19 < geertu>       - ARM64 DMA attributes (Geert)
09:19 < geertu>       - MSTP Reset feature (Geert)
09:19 < geertu>   - Reviewed http://elinux.org/Bindings:Renesas
09:19 < geertu> B)
09:19 < geertu>   - Provide feedback about http://elinux.org/Bindings:Renesas (paper review
09:19 < geertu>     -> email conversion)
09:19 < geertu>   - Book meeting room Friday before FOSDEM
09:19 < geertu>   - ARM64 DMA attributes
09:19 < geertu>   - MSTP Reset feature
09:20 < geertu> C) None
09:20 < horms> geertu: sorry, I had not noticed that email
09:20 < geertu> --- end ---
09:20 < geertu> horms: You missed B) ;-)
09:20 < horms> oh, ok
09:20 < horms> silly me
09:21 < geertu> Sorry, it was confusing
09:22 < geertu> All other core members are absent...
09:22 < geertu> Topic 2. Power Management implementation on Upstream for R-Car (especially Gen3)
09:23 < geertu> From Shimoda-san:
09:23 < geertu> --- start ---
09:23 < geertu> I would like to make a plan about Power Management implementation on 
09:23 < geertu> Upstream for R-Car (especially Gen3).  I didn't know the detail but BSP
09:23 < geertu> power management team has 130 local patches (wow!) to support power
09:23 < geertu> management for Gen3 BSP. So, I would like to do upstreaming about power
09:23 < geertu> management related code as well to reduce the local patches somehow.
09:23 < geertu> Morimoto-san suggested me that we have to integrate i2c_dvfs node at first.
09:23 < geertu> And then, we can implement each driver to support suspend/resume.
09:23 < geertu> ---
09:24 < geertu> (Ah, Khiem is replying to the email)
09:24 < geertu> If my memory serves me well, most patches for suspend are about saving/restoring register contents in each driver.
09:25 < shimoda> geertu: yes, the local patches have such code
09:25 < geertu> I'm afraid the way it's done in the BSP (hardcoded lists of devices in each driver) are not suitable for upstream.
09:26 < shimoda> geertu: i agree with you.
09:26 < morimoto> Yeah, no sense
09:26 < geertu> However, drivers that are also used on older (SH/SH-Mobile) SoCs may already have code upstream to save/restore or reinit registers during resume.
09:27 < geertu> E.g. sh-sci.c reinits registers, which is needed on SH/R-Mobile (removing the reinit breaks the port, I checked that a while ago)
09:29 < geertu> horms: Do you know if the BSP upport task classification project covered the suspend/resume patches in the BSP?
09:30 < horms> it does to the extent that I have tried to consistently mark them as the "Gen3 suspend to RAM" feature
09:30 < horms> I'm happy to refine that if it would be helpful
09:30 < geertu> Right, and they're called "Support DDR backup"
09:30 < horms> many are, yes
09:31 < shimoda> I asked Ito-san of a maneger about power management about this, he would like to do upstream some power management related code. thermal driver, cpu freq, cpu idle and cpu hotplug
09:31 < horms> I could provide a list in .csv file of just those patches. e.g. here or via email. it should be a single grep command away
09:32 < geertu> shimoda: According to Khiem's comments cpu freq, cpu idle, and cpu hotplug should be easy to complete.
09:32 < shimoda> and he are thinking that baylibre can do such upstreaming as well or not
09:32 < geertu> And Niklas is handling thermal
09:32 < shimoda> geertu: oh, i didn't read khiem san's email yet
09:33 < geertu> So the biggest hurdle is suspend to RAM. And we may want to try suspend-to-idle, too.
09:33 < geertu> s/suspend to RAM/non-standard suspend to RAM/
09:34 < horms> Are Batlibre doing upstream work for us these days?
09:34 < neg> FWIW I plan to post v6 themral tomorrow
09:34 < horms> neg: does the thermal work include ESR? Yet?
09:35 < shimoda> neg: good news to me! thank you for this.
09:35 < neg> horms: ESR?
09:35 < horms> Emergency Shutdown
09:35 < shimoda> horms: yes, i think. (about Baylibre)
09:36 < horms> shimoda: thanks
09:36 < neg> horms: no, don't we need interrupt support first to support that? (new to thermal framework)
09:36 < morimoto> horms: We can forward some taks to Baylibre if PeriPeri can indicate it
09:37 < horms> neg: ok. EMS is the correct acronym. I only as as I see code for it in the BSP.
09:37 < horms> morimoto: ok, great!
09:38 < neg> I have nothing planed or in the pipeline for my base contract Q1 so if approprite I can help out here
09:39 < neg> horms: cool did not know about EMS and that it was in BSP, will have a look
09:39 < horms> neg: drivers/soc/renesas/rcar_ems_ctrl.c might be a good place to start looking
09:39 < horms> I have not inspected its contents
09:43 < geertu> I guess we cann hanle the remainder offline, cfr. the email thread?
09:44 < horms> sounds reasonable as Khiem-san is not present
09:44 < shimoda> I think so
09:45 < geertu> OK, thx
09:45 < geertu> Topic 3. >4G mem on M3-W
09:46 < horms> This seems to be going around in circles.
09:46 < horms> from my pov
09:46 < horms> We tried to manage things nicely
09:47 < horms> but due to unforseen circimatances we are no longer in control
09:47 < horms> i.e. the firmware enables the memory anyway
09:47 < geertu> Correct
09:47 < horms> Can we get closure on this by simply enabling things in DT - which should introduce no run-time change?
09:47 < geertu> Indeed. It behaves the same before and after
09:48 < horms> All currently enabled devices work, or at least have not been reported to be broken, right?
09:48 < geertu> (Linux handles the duplicates, as we add a second memory node, while u-boot adds a second reg set to the first memory node)
09:48 < geertu> Correct.
09:49 < geertu> DMA is impacted by swiotlb, using bounce buffers as rcar-dmac doesn't set the 40-bit DMA mask yet
09:49 < geertu> But that's the case with and without the >4G mem enablement patch, as it's enabled anyway
09:49 < horms> ok, so there is no change
09:50 < horms> do we have a channel where we can discuss this with Magnus? He has shown a paricular interest in this issue.
09:50 < geertu> Email?
09:50 < horms> sounds reasonable
09:50 < horms> do you wish to handle this?
09:52 < geertu> We already discussed this before with him.
09:52 < geertu> Can't find the email thread...
09:54 < horms> ok, perhaps we can follow up on this latter.
09:54 < horms> It would be nice to get some closure on this one
09:54 < geertu> OK, thread was "[PATCH 3/4] arm64: dts: renesas: r8a7796: Add DU device to DT" (sic)
09:54 < geertu> Let's just apply ;-)
09:55 < geertu> Topic 4. Holidays
09:55 < geertu> I'll be going in "quiet mode" soon, until Jan 8. But I will make a renesas-drivers release shortly after v4.10-rc1.
09:56 < pinchartl> should we post out holiday schedule somewhere ? in the wiki ?
09:57 < geertu> Hi Laurent ;-)
09:57 < geertu> Good idea!
09:57 < geertu> (I mean the wiki)
09:57 < shimoda> geertu: i got it. so about the power management discusstion we can restart after Jan 8?
09:58 < geertu> Yes, I think so
09:58 < neg> I will be out of the country 27 Dec -- 7 Jan will have email at house but might spend more time at the beach then the house...
09:59 < horms> I plan to be in quiet mode from the 23rd - 2nd (inclisive)
09:59 < horms> geertu: do you need any renesas-devel releases from me in that timeframe: if so I can make it so
10:00 < geertu> horms: It's not really needed. If none of the for-next branches already have v4.10-rc1 (usually net-next does), I'll just merge it in myself.
10:00 < horms> ok, thanks
10:01 < horms> in that case I'll make releases on a best-effort basis
10:04 < geertu> I think we have everything covered?
10:05 < geertu> Any other topics?
10:05 < geertu> For the people wondering about Berlin: it happened on the place in front of the building where we met for the meeting on Monday.
10:06 < horms> lovely
10:06 < horms> Fortunately my excursion to German Christmas markets yesterday was in a different city.
10:06 < horms> Has anyone heard from Wolfram?
10:07 < geertu> He sent a pull request 5 minutes ago
10:07 < horms> A healthy sign :)
10:07 < geertu> I guess he's not using "at"
10:09 < geertu> I think we can conclude.
10:09 < geertu> Thanks for joining, and have a nice continued day!