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!