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

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!