diff options
Diffstat (limited to 'wiki/Chat_log/20160927-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20160927-core-chatlog | 341 |
1 files changed, 341 insertions, 0 deletions
diff --git a/wiki/Chat_log/20160927-core-chatlog b/wiki/Chat_log/20160927-core-chatlog new file mode 100644 index 0000000..7164c8b --- /dev/null +++ b/wiki/Chat_log/20160927-core-chatlog @@ -0,0 +1,341 @@ +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! |