wiki: Porting wiki: Porting Chat Log

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

1 files changed, 191 insertions, 0 deletions

diff --git a/wiki/Chat_log/20161220-core-chatlog b/wiki/Chat_log/20161220-core-chatlog
new file mode 100644
index 0000000..160030d
--- /dev/null
+++ b/wiki/Chat_log/20161220-core-chatlog
@@ -0,0 +1,191 @@
+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!