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