2016-09-27 Renesas Core Group Chat Invitation Time: Tuesday, September 27, 17h00-18h30 JST / 10h00-11h30 CEST Location: #periperi @ chat.freenode.net Agenda: 1. Status updates 2. PFC and CPG codes of R-Car H3 ES2.0. 3. R-Car hwspinlock driver -------------------------------------------------------------------------------- Topic 1. Status updates A) What have I done since last time Geert: - Resumed SoC identification and ESx.y handling Khiem: - Nothing yet Still struggle to solve issue of git-send-emails via company proxy. Magnus: - Updated boot loader, IPMMU and audio hacking, accidentally boot tested IPMMU and EtherAVB with new boot loader. Updated IPMMU patches. Morimoto: - Basically no Core task. - Checking V3 patch permission. - Checking about RZ/G ID Niklas: - Solved my issue for PFC drive strength on H3 and posted the patches Ulrich: - Submitted SYS-DMAC enablement for M3-W, plus I2C and (H)SCIF to actually have something to enable it for... B) What I plan to do till next time Geert: - Review Niklas' drive strength patches - Continue RST, MODEMR, ES-handling, ... - 64-bit memory with M3-W Ethernet Khiem: - Complete CPUFreq (Z-clock change) I will make sure the patches are available and send out during this weekend. Magnus: - Focus on upstreaming of IPMMU code. Morimoto: - Clarify V3 patch permission - Clarify RZ/G ID Niklas: - Fix Sergei's minor comment on PFC and wait for more comments/Acks - Post v2, if there is time start on PFC work for M3-W Shimoda: - Describe lossy infor into eLinux... Simon: - Verify Suspend-to-RAM on M3-W using 2.12 firmware C) Problems I have currently Magnus: - Lack of time. Morimoto: - Berlin trip wrapping -------------------------------------------------------------------------------- Topic 2. PFC and CPG codes of R-Car H3 ES2.0. The BSP team asked me about PFC and CPG codes of R-Car H3 ES2.0. They would like to know the policy of upstream team until mid of October because they will start ES2.0 development from this timing. - How to create the R-Car H3 ES2.0's PFC and CPG codes? - Do we add the ES2.0 code to pfc-r8a7795.c and r8a7795-cpg-mssr.c? Or, do we make new files for the ES2.0? - Or, other ideas? a. CPG/MSSR - Add ES2.0 clocks to end of include/dt-bindings/clock/r8a7795-cpg-mssr.h - Use soc_device_match() to detect r8a7795 ES1.* and - select r8a7795_es1 tables instead of r8a7795 (= latest) tables, - OR modify r8a7795 tables (TBD). b. PFC - r8a7795 ES2.0 PFC is (almost) identical to r8a7796 PFC. Can it be merged? - Similar to CPG/MSSR: - sh_pfc_soc_operations.init() uses soc_device_match() to detect r8a7795 ES1.* and select r8a7795_es1 or r8a7795 tables - Needs ordering change. Current ordering is: 1. soc_bus_register is core_initcall 2. sh_pfc_init is postcore_initcall (drivers/pinctrl < drivers/soc) 3. renesas_soc_init is postcore_initcall (cannot be core_initcall because drivers/soc < drivers/base) Note: Do we want to make ES1.x support configurable? If yes, it may make sense to use separate source files. -------------------------------------------------------------------------------- Topic 3. R-car hwspinlock driver BSP team would like to do upstream about the hwspinlock driver for R-Car. The driver is already merged into the latest Gen3 BSP: https://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git/commit/drivers/hwspinlock?h=rcar-3.3.2&id=22d88d4eddb5a0fec485e717a65f218275f6b26b I don't know the spec of this driver. But, they have concerns about the driver. - The driver uses "core_initcall" to control PFC driver. Is it acceptable in Upstream? - This topic is not related to upstreaming, but the driver cannot handle the CPG driver because this driver also need the CPG. Do you think we can upport this driver as well? Or, do we need an additional task for it anyway? I checked this BSP patch roughly, and the patch should have a DT doc. (commit e4d2c3213280a6985395970cbf26e7ef381dd1d5) - The driver uses platform_driver_register() from a core_initcall(). As the CPG/MSSR driver uses subsys_initcall(), the hwspinlock driver probe will be deferred. - No current users of hwspin? What's the plan? - Shimoda-san will ask the BSP team - Used for synchronisation with CR7 core -------------------------------------------------------------------------------- Core-chat-meeting-2016-09-27 -------------------------------------------------------------------------------- 10:03 < geertu> Welcome to today's Core Group Chat! 10:04 < geertu> Magnus is excused (Japanese > Core Work) 10:04 < geertu> Khiem seems to be stuck in Outlook without IRC capability? 10:05 * geertu sort -R members 10:05 < geertu> Oops, first is Khiem 10:05 < geertu> Next is Simon 10:06 < horms> --- start --- 10:06 < horms> A) What have I done since last time 10:06 < horms> * No core tasks at this time 10:06 < horms> B) What I plan to do till next time 10:06 < horms> * Verify Suspend-to-RAM on M3-W using 2.12 firmware 10:06 < horms> C) Problems I have currently 10:06 < horms> * None 10:06 < horms> --- end --- 10:06 < geertu> Thanks Simon 10:06 < geertu> Next is Morimoto-san 10:06 < morimoto> Basically I have no Core task. About RZ/G series, it is mass production version of R-Car chip. The reason why it has different naming is business paper work reason (R-Car consortium, etc). So, basically, R-Car and RZ/G can have same ID, but I'm confirming about this. 10:06 < morimoto> About "V3". 10:06 < morimoto> H3/M3 are under AIS team's (= our main group) product chip. This means WE can control H3/M3. Now we already have "M3" on upstream, even though, M3 press release was not yet happen. But "V3" is not our (= AIS team) product chip. And V3 might not use Linux on it. Don't know detail at this point. So now, we don't know how we control it. Now Munakata-san is considering about it. 10:06 < morimoto> --end-- 10:07 < geertu> Oops, forgot the agenda 10:07 < geertu> Agenda: 10:07 < geertu> 1. Status updates 10:07 < geertu> 2. PFC and CPG codes of R-Car H3 ES2.0. 10:07 < geertu> 3. R-Car hwspinlock driver 10:07 < geertu> ;-) 10:07 < geertu> Thanks, Morimoto-san 10:08 < horms> thanks Moriomoto-san, can I ask what "same id" means? 10:08 < geertu> Next is Ulrich 10:08 < geertu> Same ID in PRR register 10:08 < uli___> A) Submitted SYS-DMAC enablement for M3-W, plus I2C and (H)SCIF to 10:08 < geertu> I.e. we cannot distinguish between RZ/G and R-Car Gen2 at runtime 10:08 < uli___> actually have something to enable it for... 10:08 < horms> thanks 10:08 < uli___> B) Nothing so far. 10:08 < uli___> C) None. 10:09 < geertu> Thanks Ulrich 10:09 < geertu> Next is Laurent 10:09 < morimoto> horms: it means, form Product ID point of view, RZ/G and R-Car are same. (and maybe HW is same) 10:09 < pinchartl> nothing for me, no core task 10:09 < horms> 承知致します。 10:09 -!- khiemnguyen [d2a0fca8@gateway/web/cgi-irc/kiwiirc.com/ip.210.160.252.168] has joined #periperi 10:10 < geertu> Thanks Laurent 10:10 < geertu> Welcome Khiem! 10:10 < khiemnguyen> Hello all 10:10 < geertu> khiem: We're into status updates. 10:10 < geertu> Next is Khiem 10:11 < khiemnguyen> ok 10:11 < khiemnguyen> a) Nothing yet. 10:11 < khiemnguyen> Still struggle to solve issue of git-send-emails via company proxy. 10:11 < khiemnguyen> b) Complete CPUFreq (Z-clock change) 10:11 < khiemnguyen> I will make sure the patches are available and send out during this weekend. 10:11 < khiemnguyen> c) None. 10:12 < geertu> Thanks Khiem 10:12 < geertu> Next is Shimoda-san 10:12 < shimoda> A) What have I done since last time: 10:12 < shimoda> - Nothing for core group task. 10:12 < shimoda> B) What I plan to do till next time: 10:12 < shimoda> - describe lossy infor into eLinux... 10:12 < shimoda> C) Problems I have currently: 10:12 < shimoda> - Nothing for core group task. 10:12 < shimoda> --- end --- 10:13 < geertu> Thanks Shimoda-san 10:13 < geertu> Next is Geert 10:13 < geertu> A) - Resumed SoC identification and ESx.y handling 10:13 < geertu> B) - Review Niklas' drive strength patches 10:13 < geertu> - Continue RST, MODEMR, ES-handling, ... 10:13 < geertu> - 64-bit memory with M3-W Ethernet 10:13 < geertu> C) - Nothing 10:13 < geertu> --- end --- 10:14 < geertu> Next is Niklas 10:14 < neg> a) Solved my issue for PFC drive strength on H3 and posted the patches 10:14 < neg> b) Fix Sergis minor comment on PFC and wait for more comments/Acks post v2, if there is time start on PFC work for M3-W 10:14 < neg> c) None 10:14 < neg> --- end --- 10:15 < geertu> Thanks Niklas 10:15 < geertu> Topic 2. PFC and CPG codes of R-Car H3 ES2.0. 10:15 < geertu> From Shimoda-san: 10:15 < geertu> The BSP team asked me about PFC and CPG codes of R-Car H3 ES2.0. 10:15 < geertu> They would like to know the policy of upstream team until mid of October 10:15 < geertu> because they will start ES2.0 development from this timing. 10:15 < geertu> - How to create the R-Car H3 ES2.0's PFC and CPG codes? 10:15 < geertu> - Do we add the ES2.0 code to pfc-r8a7795.c and r8a7795-cpg-mssr.c? 10:15 < geertu> Or, do we make new files for the ES2.0? 10:15 < geertu> - Or, other ideas? 10:15 < geertu> ---end--- 10:16 < geertu> I had already given this some thought 10:16 < geertu> a. CPG/MSSR 10:16 < geertu> - Add ES2.0 clocks to end of include/dt-bindings/clock/r8a7795-cpg-mssr.h 10:16 < geertu> - Use soc_device_match() to detect r8a7795 ES1.* and 10:16 < geertu> - select r8a7795_es1 tables instead of r8a7795 (= latest) tables, 10:16 < geertu> - OR modify r8a7795 tables (TBD). 10:16 < geertu> Does that make sense? 10:17 < pinchartl> that sounds good to me 10:17 < pinchartl> how big is the diff between ES1.* and ES2.0 when it comes to CPG ? 10:18 < geertu> I haven't gone through all changes, but for CPG, I think it's just a few additional clocks 10:18 < geertu> For MSTP, some modules changed their parent clocks 10:18 < geertu> Other modules disappeared (e.g. VSP) 10:19 -!- horms [~horms@217.111.208.18] has quit [Read error: Connection reset by peer] 10:19 < geertu> For CPG, it may even become identical to r8a7796. But as the defines are different, we can't just reuse the table. 10:20 < pinchartl> ok 10:20 -!- horms [~horms@217.111.208.18] has joined #periperi 10:21 < geertu> b. PFC 10:21 < geertu> - r8a7795 ES2.0 PFC is (almost) identical to r8a7796 PFC. 10:21 < geertu> Can it be merged? 10:21 < geertu> - Similar to CPG/MSSR: 10:21 < geertu> - sh_pfc_soc_operations.init() uses soc_device_match() to detect 10:21 < geertu> r8a7795 ES1.* and select r8a7795_es1 or r8a7795 tables 10:21 < geertu> - Needs ordering change. Current ordering is: 10:21 < geertu> 1. soc_bus_register is core_initcall 10:21 < geertu> 2. sh_pfc_init is postcore_initcall 10:21 < geertu> (drivers/pinctrl < drivers/soc) 10:21 < geertu> 3. renesas_soc_init is postcore_initcall 10:21 < geertu> (cannot be core_initcall because drivers/soc < drivers/base) 10:22 < geertu> Does that make sense? 10:23 < pinchartl> what are the new initcalls you're proposing there ? 10:23 < horms> Sorry, could you repost what came before b? I am suffering from post-brexit wifi trauma 10:24 < morimoto> horms: I will send it by email, OK ? 10:24 < horms> morimoto: I got it from geert, thanks 10:24 < morimoto> OK 10:25 < morimoto> Is it possible to exchange initcall order ? I got NAK from maintainer before... 10:26 < geertu> As changing initcalls and order in drivers/Makefile is always very complicated, I'm thinking of making renesas_soc_init() a core_initcall anyway, and letting soc_device_register() initialize the soc_bus if that hasn't been done yet. 10:27 < pinchartl> anything that touches initcall ordering seems hacky to me, but I'll let others complain this time :-) 10:27 < geertu> If you just call soc_device_register() before soc_bus_register() has happened, it crashes with a nice NULL pointer dereference 10:28 < geertu> Does it still sound reasonable? 10:29 < pinchartl> I've seen worse :-) 10:29 < geertu> One other thing: Do we want to make ES1.x support configurable? 10:30 < geertu> If yes, it may make sense to use separate source files. 10:30 < shimoda> geertu: BSP team wants to be single binary 10:31 < morimoto> single binary, but support ES1.x and ES2.0. correct ? 10:31 < shimoda> if separate source files, we can build a single binary to support both es1 and 2? 10:31 < geertu> shimoda: of course 10:31 < shimoda> morimoto: yes 10:31 < horms> Single binary is a hard requirement from my pov :) 10:31 < geertu> shimoda: I meant, do we want CONFIG_ARCH_R8A7795_ES1? 10:31 < pinchartl> geertu: I believe our long term goal should be to remove it, so I'd like to see the code developed in a way that wouldn't make that too difficult. it doesn't need to be in seperate files for me though 10:32 < geertu> pinchartl: I agree 10:32 < pinchartl> and I'd actually like to consider the opposite of your question as well: do we want to remove CONFIG_ARCH_R8A7795 at some point ? 10:32 < pinchartl> but that's another topic 10:33 < horms> what would be the motivation for removing it? 10:33 < geertu> pinchartl: You mean make it unconditional, hence enabling CONFIG_ARCH_RENESAS enables all Renesas arm64 SoCs? 10:34 < pinchartl> geertu: correct 10:34 < geertu> pinchartl: That's what the arm64 maintainers would like, right? 10:34 < pinchartl> yes 10:34 < horms> probably the current arrangment is partly due to historical reasons 10:34 < horms> i wonder if there is an advantage to keeping the current arrangment 10:34 < pinchartl> I'm not advocating for that, but I believe we should at least consider the option 10:35 < horms> e.g. to allow not carring so many pfc tables in the kernel binary if desired 10:35 < geertu> So your kernel will always include full PFC tables for r8a7795_es1, r8a7795, r8a7796, r8a7797 (I predict that'll be the name of V3M ;-)? 10:35 < pinchartl> kernel bloat is my concern too 10:38 < geertu> OK, let's see later 10:39 < geertu> shimoda: Are H3 ES2.0 boards already available? 10:39 < shimoda> shimoda: not yet, perhaps end of this year or ealry next year 10:40 < morimoto> It will goes to Magnus's remote machine. 10:40 < geertu> shimoda: You said the BSP team will start working on it Oct/M 10:40 < morimoto> Your available board will be next Feb or later ? 10:40 < geertu> So by then we should have something basic ready? But we can't test it? 10:41 < shimoda> geertu: yes. they will start it without actual board :) 10:41 < morimoto> Renesas magic! 10:42 < horms> Do they also code with their eyes shut? 10:43 < geertu> touch typing 10:43 < horms> of course 10:45 < geertu> shimoda: Are you happy with the answer so far? 10:46 < shimoda> geertu: about CPG, i understood it, but about PFC, i don't understand yet 10:47 < shimoda> separate file or into the exist file? 10:48 < shimoda> or we need more discusstion? 10:48 < geertu> shimoda: As the PFC data is quite big, I think separate files are OK 10:48 < geertu> Except if we can actually just use the r8a7796 tables. I have to check if that would cause ill effects. 10:49 < shimoda> geertu: OK. I also think of that. So, I will fowared this infor to the BSP team. Thanks! 10:49 < geertu> Thanks! 10:49 < geertu> Topic 3. R-car hwspinlock driver 10:49 < geertu> Also from Shimoda-san: 10:50 < geertu> BSP team would like to do upstream about the hwspinlock driver for R-Car. 10:50 < geertu> The driver is already merged into the latest Gen3 BSP: 10:50 < geertu> https://git.kernel.org/cgit/linux/kernel/git/horms/renesas-bsp.git/commit/drivers/hwspinlock?h=rcar-3.3.2&id=22d88d4eddb5a0fec485e717a65f218275f6b26b 10:50 < geertu> I don't know the spec of this driver. But, they have concerns about the driver. 10:50 < geertu> - The driver uses "core_initcall" to control PFC driver. 10:50 < geertu> Is it acceptable in Upstream? 10:50 < geertu> - This topic is not related to upstreaming, but the driver cannot handle the CPG driver 10:50 < geertu> because this driver also need the CPG. 10:50 < geertu> Do you think we can upport this driver as well? 10:50 < geertu> Or, do we need an additional task for it anyway? 10:50 < geertu> I checked this BSP patch roughly, and the patch should have a DT doc. 10:50 < geertu> ---end--- 10:50 < geertu> DT doc is commit e4d2c3213280a6985395970cbf26e7ef381dd1d5 10:50 < geertu> I have two comments here: 10:50 < geertu> 1. The driver uses platform_driver_register() from a core_initcall(). 10:50 < geertu> As the CPG/MSSR driver uses subsys_initcall(), the hwspinlock driver probe will be deferred. 10:51 < geertu> So it will probably be initialized earlier (without deferred probe), if it would use another initcall 10:51 < geertu> it = hwspinlock driver 10:52 < geertu> 2. There are no current users of hwspin in the BSP? What's the plan? 10:53 < shimoda> geertu: about the plan, i don't know. So, I will ask the BSP team later 10:54 < geertu> "the driver cannot handle the CPG driver because this driver also need the CPG/" 10:54 < geertu> Does that mean they woild like to use hwspinlock in the CPG driver? 10:55 < geertu> s/woild/would/ 10:56 -!- horms [~horms@217.111.208.18] has quit [Ping timeout: 244 seconds] 10:58 < shimoda> geertu: this means the hwspin driver calls pm_runtime APIs 10:58 < shimoda> about the driver, I asked BSP team now 10:59 < geertu> OK, thanks! 10:59 < shimoda> this driver will be used if other CPU core (CR7) also runs 10:59 < geertu> IC 11:00 < geertu> Any other topics people want to discuss? 11:00 < shimoda> but, a plan is not clear, they would like to skip upporting of this driver for now 11:02 < geertu> Next meeting will be in Berlin 11:02 < geertu> If you have topics for the meeting, please let me (and periperi) now! 11:02 -!- horms [~horms@217.111.208.18] has joined #periperi 11:02 < geertu> There are already some topics listed at https://osdr.renesas.com/projects/linux-kernel-development/wiki/Miniperi-2016-10 11:05 < geertu> Nothing to add? 11:06 < geertu> Thanks for joining, and have a nice continued day!