Core-chat-meeting-2016-10-25

10:05 < geertu> Welcome to todays Core Group Meeting
10:05 < geertu> Agenda:
10:05 < geertu> 1. Status updates
10:05 < geertu> 2. Inquiries from Tokyo
10:06 < geertu> Topic 1. Status updates
10:06 < geertu> A) What have I done since last time
10:06 < geertu>   B) What I plan to do till next time
10:06 < geertu>   C) Problems I have currently
10:06 < geertu> First is Uli
10:06 < uli___> a) sent sys-dmac, i2c, and scif for r8a7796
10:07 < uli___> b) fix up sys-dmac, i2c, and scif as far as people have considered it offensive :)
10:07 < uli___> c) none
10:07 < geertu> Thank you Uli
10:07 < geertu> Next is Simon
10:07 < horms> A) What have I done since last time
10:07 < horms> * No core tasks at this time
10:07 < horms> B) What I plan to do till next time
10:07 < horms> * See above
10:07 < horms> C) Problems I have currently
10:07 < horms> * 16Mbyte kernels: Is a solution being worked on by Renesas?
10:07 < horms> * Gen2 Suspend 2 Ram: What are the next steps
10:08 -!- shimoda [~shimoda@relprex3.renesas.com] has joined #periperi
10:08 < geertu> Mronin' Shimoda-san
10:08 < geertu> horms: Gen2, right?
10:08 < shimoda> sorry for the delayed!
10:09 < horms> silly me. I mean Gen3
10:10 < geertu> horms: The current implementation (with SW23 and PMIC) doesn't really keep in mind how suspend works on Linux
10:10 < geertu> I've tried on H3, where we do have bias support, and GPIO wake-up doesn't work
10:11 < geertu> So the only wake-up source we have is SW23?
10:11 < horms> Did you also test on M3-W?
10:11 < khiemnguyen> yes, in suspended state, the board are powered down.
10:11 < geertu> M3-W doesn't have bias support yet
10:11 < khiemnguyen> only SW23 can signal to PMIC and trigger the resume.
10:11 < horms> My assumption is that the SW23 situation is a work around.
10:11 < geertu> khiemnguyen: What if the user wants a different wake-up source?
10:12 < horms> Can we confirm what the plans of the firmware team are in this regards?
10:12 < geertu> E.g. wake-on-LAN?
10:12 < khiemnguyen> geertu: we will need different board ;)
10:13 < geertu> Alternative, if extra wake-up sources are enabled, can we do it like on Gen2?
10:14 < geertu> I.e. keep the SoC powered, so it will receive and act on interrupts?
10:14 < khiemnguyen> for Gen3, it's target to not only SoC, but board power down.
10:15 < khiemnguyen> if SoC is power down only, like Core-Standby, L2 shutdown, we can use other wakeup sources, like interrupts.
10:16 < horms> I wonder how this aligns with customer expectations.
10:16 < geertu> khiemnguyen: It depends on the use case. Some users may want Wake-on-LAN or Wake-on-GPIO
10:18 < khiemnguyen> geertu: so, we can let them use SoC power down only. We can able to achieve it.
10:18 < horms> I think that would be more in keeping with how S2RAM works on Gen2.
10:19 < geertu> khiemnguyen: OK.
10:19 < horms> Which may also me aligned with users's expectations
10:19 < geertu> khiemnguyen: I was also considering future use cases (cfr. RZ/G)
10:19 < horms> But I assume that this would involve more power consumption.
10:20 < khiemnguyen> geertu: RZ/G is similar to Gen2.
10:20 < geertu> horms: One question is if we can do this in the kernel without touching arm64 core code, which may be hardwired to call into PSCI anyway
10:20 < horms> true
10:20 < khiemnguyen> geertu: for armv8, we need to use PSCI.
10:21 < geertu> khiemnguyen: I know. And RZ/G targets a different market than cars, which may have different requirements w.r.t. wake-up sources
10:21 < khiemnguyen> ARM maintainer will reject all code which do not use PSCI, AFAIK.
10:21  * pinchartl wonder how long it will take before support for bypassing PSCI will be merged in the kernel
10:21 < geertu> khiemnguyen: I don't know much about the PSCI API. Can Linux pass parameters to specify suspend mode?
10:22 < khiemnguyen> in the history, Qualcomm or other companies submitted the code, and all have been rejected.
10:23 < khiemnguyen> they want a unified solution in arm64 arch.
10:23 < geertu> Let's see... More investigation needed...
10:23 < geertu> Next?
10:23 < geertu> Next is Shimoda-san
10:24 < shimoda> yes
10:24 < shimoda> a) nothing for core group
10:24 < shimoda> b) need lossy info into eLinux...
10:24 < shimoda> c) nothing for core group
10:24 < shimoda> --- end ---
10:24 < geertu> Thanks you, Shimoda-san
10:24 < geertu> Next is Niklas
10:25 < neg> A) Noting for core (multimedia consumed all my time with feedback from ELCE)
10:25 < neg> B) Fix review comments on H3 PFC drive-strengh patches and start on M3-W PFC work.
10:25 < neg> C) None.
10:25 < neg> EOT
10:26 < geertu> Thank you
10:26 < geertu> Next is Morimoto-san
10:26 < morimoto> A) No Core Task
10:26 < morimoto> B) No Core Task (but have 2 questions)
10:26 < morimoto> C) None
10:27 < morimoto> Questions are Next Topics
10:27 < morimoto> EOT
10:27 < geertu> Thank you, Morimoto-san
10:27 < geertu> Next is Magnus
10:27 < geertu> (AWOL)
10:27 < geertu> Next is Laurent
10:28  * pinchartl is just a lurker here
10:29 < geertu> Thanks for lurking
10:29 < geertu> Next is Khiem
10:29 < pinchartl> you're welcome
10:29 < pinchartl> (I've just checked, the PSCI system suspend call doesn't take a mode argument. suspend to ram is suspend to ram, the same way wine is wine)
10:30 < khiemnguyen> a) no progress.
10:30 < khiemnguyen> b) to complete Z-clk changing (for CPUFreq)
10:30 < khiemnguyen> c) to solve issue of my email account. Then, come back to Z-clk changing.
10:30 < geertu> pinchartl: Thanks for checking. So no way to pass wake-up-source information
10:30 < khiemnguyen> perhaps, I will send the email to periperi list for review first.
10:31 < khiemnguyen> that's all.
10:31 < geertu> Thanks, Khiem!
10:31 < geertu> Next is Geert
10:31 < pinchartl> geertu: no. the firmware could check whether peripherals have been configured as a wake up source, but that's really a heuristic and is error-prone
10:31 < geertu> A)- Investigated serial console issue in v4.9-rc1
10:31 < geertu>   - Reviewed Niklas' drive strength patches
10:31 < geertu>   - Reviewed lots of RZ/G patches
10:31 < geertu>   - Sent out v1 of SoC identifaction and ESx.y handling
10:31 < geertu>   - Sent out R-Car H3 ES2.0 CPG/MSSR prototype and PFC proof-of-concept
10:31 < geertu>   - Coerced Sergei into using CPG/MSSR for RZ/G1M, which we can reuse for
10:31 < geertu>     R-Car Gen2 later,
10:31 < geertu>   - Sent out v4 of R-Car RST driver
10:31 < geertu>   - Started 64-bit memory with M3-W Ethernet
10:32 < geertu> pinchartl: How does the firmware check that?
10:32 < geertu> B)- Prepare v2 of SoC identifaction and ESx.y handling
10:32 < geertu>       - I think soc_device_match() itself needs to be in v4.9
10:32 < geertu>       - 1G support for RAVB depends on it, too (only H3 ES1.0 is limited
10:32 < geertu>         too 100M)
10:32 < geertu>   - Coerce Simon into taking all MODEMR related patches
10:32 < pinchartl> geertu: by reading hardware registers :-)
10:32 < pinchartl> PSCI explicitly states that it does *not* cover peripherals, only CPU cores
10:33 < horms> I'm happy to take patches if there is consensus on them
10:33 < geertu> C)- Too many dependencies between patches and patch series
10:34 < geertu> pinchartl: Aha, that means the kernel is not allowed to call PSCI suspend if peripherals are wake-up sources
10:34 < geertu> Anyone who recently ran renesas-drivers on R-Car H2 ES1.0, with SW4-8 toggling?
10:34 < pinchartl> it means it's a badly defined interface like all firmware interfaces ;-)
10:36 < geertu> EOT
10:36 < geertu> horms: Have to ping Mike/Stephen, so allow Sergei to repost R-car Gen2 CPG/MSSR support using a proper MODEMR API
10:37 < geertu> s/so/to/
10:37 < horms> perfect. If I need to be involved in coordinating things just let me know
10:38 < geertu> Topic 2. Inquiries from Tokyo
10:38 < geertu> horms: thx!
10:38 < geertu> A. Subject: [periperi] SH-SCI spin/mutex lock issue
10:38 < geertu>   - Fixed in v4.5 with commit ff1cab374ad98f4b ("serial: sh-sci: Remove cpufreq
10:38 < geertu>     notifier to fix crash/deadlock")
10:38 < geertu>   - Backported to v3.2.80, v3.12.60, v3.14.68, v3.16.35, and v4.4.9.
10:39 < geertu> morimoto: Does that answer your question?
10:39 < morimoto> let me check
10:40 < morimoto> Thanks. I will report it ot BSP team
10:40 < geertu> OK
10:41 < geertu> B) "Re: [periperi] 2016-03-15 Renesas Core Group Chat Invitation" (2016-03-22)
10:41 < geertu> This is about the patch "[PATCH 119/124] arm64: dts: Add multi-cluster to r8a7795 dtsi" (from the BSP? It's not present in any of rcar-3.0.0..rcar-3.3.3.rc2?)
10:41 < geertu> Cfr. Documentation/devicetree/bindings/arm/topology.txt
10:42 < geertu> Example 2 is basically what's added
10:42 < geertu> However, this depends on the presence of the CA53 nodes, which we haven't added yet deliberately
10:43 < morimoto> Does this mean upsteam still can't have it, right ?
10:44 < geertu> Indeed.
10:44 < morimoto> Do you have some plan ?
10:45 < geertu> Note that our firmware (at least H3 latest from wiki) enables the CA57 cores only
10:46 < horms> There are other versions of the firmware, right?
10:46 < geertu> The plan was to add support for CA53 as soon as the scheduler is big.LITTLE aware
10:46 < horms> oh, that would be... never, right?
10:47 < geertu> Good question...
10:48 < horms> I mean. big.LITTLE has been floating around for some time now. As have out-of-tree solutions. But is in-tree support going anywhere?
10:48 < geertu> horms: No idea.
10:48 < horms> It remember having this exact conversation at Linux Con in New Orleans, whenever that was.
10:49 < horms> So I must say that I am very skeptical
10:49 < horms> Not that I want to bring down the mood of the conversation.
10:50 < geertu> I have the same feeling (wasn't in New Orleans)
10:51 < geertu> morimoto: If the BSP team wants the patch, I think they can just add it to the BSP.
10:52 < morimoto> geertu: Thanks. I (and shimoda-san) will explain it to BSP team
10:52 < geertu> morimoto: There's no issue with the patch itself, so when upstream is ready, it can be submitted as-is
10:53 < geertu> morimoto: Does the BSP team use an out-of-tree big.LITTLE patch?
10:55 < morimoto> geertu: It seems big.LITTLE team (= not BSP team) want this patch
10:55 < morimoto> But I don't know detail of their situation. shimoda-san do you know ?
10:56 < horms> morimoto: I think the point is that its hard to have partial support for big.LITTLE in mainline and so a more holistic approach is required.
10:56 < shimoda> morimoto: i also don't know the detail but the big.LITTLE team wants to use it and suggest it to out customer somewhat
10:57 < shimoda> s/somewhat/something/
10:58 < morimoto> horms: thank
10:59 < morimoto> geertu: thanks, I will explain above
10:59 < geertu> shimoda: It would be good to know what other big.LITTLE patches they suggest to the customer
11:00 < horms> And what customers's use cases are
11:01 < geertu> THanks all
11:01 < geertu>   C) __alloc_iova()???
11:01 < geertu> THis was more a question for Magnus?
11:02 < shimoda> I am asking Magnus-san about the API for Gen3 SDHI+DMAC+IPMMU
11:03 < pinchartl> what's the problem with __alloc_iova ?
11:03 < shimoda> in dma-iommu.c, the __alloc_iova() calls alloc_iova() as size-alligned
11:04 < shimoda> however I would like to avoid the size-alligned for Gen3 SDHI-DMAC + IPMMU because the DMAC doesn't have descripter mode
11:05 < pinchartl> there's a comment in the __alloc_iova() function that states
11:06 < pinchartl>          * Enforce size-alignment to be safe - there could perhaps be an
11:06 < pinchartl>          * attribute to control this per-device, or at least per-domain...
11:06 < shimoda> yes, so I asked Magnus-san how to improve this frameword somehow
11:06 < shimoda> s/frameword/framework/
11:07 < pinchartl> adding a DMA mapping attribute could be one option
11:07 < pinchartl> it should be discussed with the author of the code
11:08 < shimoda> and Magnus-san will do it somehow
11:08 < shimoda> pinchartl: thank you for the suggestion!
11:09 -!- horms [~horms@91.126.38.165] has quit [Ping timeout: 252 seconds]
11:12 < geertu> OK, let Magnus handle that ;-)
11:12 < geertu> Any other topics?
11:12 -!- horms [~horms@cli-5b7e26a5.wholesale.adamo.es] has joined #periperi
11:13 < geertu> shimoda-san: Do your have more information about the R-car hwspinlock driver?
11:14 < shimoda> geertu: no more information from BSP team
11:14 < shimoda> i'll ask him
11:15 < geertu> shimoda: OK, thx
11:15 < geertu> No more topics?
11:15 < khiemnguyen> geertu: we don't know the user of R-car hwspinlock driver ?
11:16 < horms> shimoda-san: do you have any idea if there is activity going on regarding kernels larger than 16Mb?
11:17 < shimoda> horms: bsp team has a plan for it.
11:17 < horms> ok, perhaps we can disucss that some time?
11:17 < shimoda> now 0x49000000, in near the future 0x50000000
11:17 < geertu> shimoda: Does it also apply to Gen2?
11:17 < geertu> Or RZ/G?
11:18 < shimoda> geertu: i don't know the plan for Gen2. I will ask BSP team. do you also need to be large on gen2?
11:18 < horms> From my pov it should be much less of an issue on Gen2 as we have defconfig_shmobile in mainline
11:19 < geertu> But CONFIG_PROVE_LOCKING=y no longer boots on Gen2
11:19 < shimoda> oops, the addresses means the u-boot text base address
11:19 < shimoda> s/means/mean/
11:19 < horms> shimoda: is the idea to use a different region. If so, does that involve a uboot update?
11:20 < geertu> CONFIG_PROVE_LOCKING still works for me on ape6evm, armadillo, bock-w, kzm9g, and marzen (I use separate .configs for each board)
11:21 < shimoda> horms: on gen3, we need to update both IPL (firmware) and uboot
11:21 < horms> ok. how large is the new reagion? and when might we expect to be able to use these updates on our boards?
11:23 < shimoda> horms: maybe we can use up to 128Mb imange and i heard the bsp comes in 11/E but maybe I can modify v2.12.0 IPL base if needed :)
11:23 < horms> ok, 128Mb sounds good to me. And I think the group that met in Berlin also thought so.
11:24 < horms> 11/E should be fine for me
11:24 < horms> Currently arm64/defconfig + (small) initrd is still small enough to boot
11:24 < horms> Corrently = v4.9-rc2
11:25 < horms> Thanks for the update
11:25 < geertu> Thanks all, I think we're finished?
11:25 < horms> Nothing more from me
11:25 < geertu> s/Mb/MiB??
11:25 < horms> I think we are talking about bytes
11:26 < horms> and M being 1024^2 - alpha
11:26 < horms> and M being 1024^2
11:26 < geertu> Nah, M = 1E6
11:26 < horms> ok!
11:26 < geertu> Mi = 2^20
11:27 < geertu> Ah, about next meeting
11:27 < geertu> We go for 09:00 GMT / 10:00 CET / 11:00 EET / 18:00 JST, like Multimedia, too?
11:28 < geertu> Or 08:00 GMT / 09:00 CET / 10:00 EET / 17:00 JST?
11:28 < horms> which day?
11:28 < geertu> Tue Nov 8
11:29 < geertu> I'm mainly asking because of CEST - DST = CET
11:29 < horms> Yes, I understand
11:29 < horms> I suggest the Tokyo based members prefernce counts here
11:29 < geertu> horms: So you get to sleep one more hour on Sunday morning ;-)
11:29 < horms> Yes
11:29 < geertu> Agreeed
11:30 < horms> Perhaps confirm over email?
11:30 < horms> I need to drop off now
11:31 < geertu> OK, let's use email
11:31 < geertu> Thanks for joining!