diff options
Diffstat (limited to 'wiki/Chat_log/20190110-core-chatlog')
| -rw-r--r-- | wiki/Chat_log/20190110-core-chatlog | 124 |
1 files changed, 124 insertions, 0 deletions
diff --git a/wiki/Chat_log/20190110-core-chatlog b/wiki/Chat_log/20190110-core-chatlog new file mode 100644 index 0000000..b384199 --- /dev/null +++ b/wiki/Chat_log/20190110-core-chatlog @@ -0,0 +1,124 @@ +09:30 < geertu> Welcome to today's core group chat! +09:31 < geertu> damm: Yes, happy evening ;-) +09:31 < geertu> Agenda: +09:31 < geertu> 1. Status Updates +09:31 < geertu> 2. Discussion Topics +09:32 < geertu> Topic 1. Status updates +09:32 < geertu> A) What have we done since last time: +09:32 < geertu> Kaneko-san upported thermal zone IPA support. +09:32 < geertu> Marek worked on ATF (upstream Renesas patches, TravisCI, +09:32 < geertu> D3/Eagle/Condor), SPL and ATF BL2 integration for U-Boot, and fixed +09:32 < geertu> Ebisu eMMC breakage in Linux. +09:32 < geertu> Shimoda-san discovered dmatest issues. +09:32 < geertu> Simon enabled R-Car thermal support in the arm64 defconfig. +09:32 < geertu> Geert verified MOD_SEL bitfield order on E3, resubmitted the QEMU patch +09:32 < geertu> for instantiating generic devices from DT, and worked on fixing +09:32 < geertu> kselftest builds. +09:32 < geertu> B) What we plan to do till next time: +09:32 < geertu> Kaneko-san plans to add DRIF and TMU support to the E3 and M3-N PFC +09:32 < geertu> drivers. +09:32 < geertu> Marek plans to check the ATF patchset with Morimoto-san, debug eMMC +09:32 < geertu> issues in U-Boot, and will speak at LCA about U-Boot. +09:32 < geertu> Shimoda-san plans to continue to make an IPMMU driver's plan with +09:32 < geertu> Magnus-san. +09:32 < geertu> Simon will follow up Ebisu PMIC enablement. +09:32 < geertu> Ulrich will follow up on unmerged patches. +09:32 < geertu> Geert plans to submit kselftest fixes, improve pinctrl table validation, +09:32 < geertu> and may work on IPMMU suspend/resume. +09:34 < geertu> C) Problems we have currently: +09:34 < geertu> Kaneko-san is eagerly awaiting review of IPA patches. +09:34 < geertu> Geert wonders how to verify MOD_SEL bitfield order on D3. +09:34 < geertu> --- +09:34 < geertu> Anything I missed? +09:35 < geertu> Topic 2. Discussion Topics +09:35 < geertu> I'm open for topics +09:36 < shimoda> I have a topic. this is from BSP team question today. +09:36 < horms> Is it appropriate to discuss Z2 clock for or CPUIdle for R-Car Gen3 +09:37 < geertu> Sure. +09:37 < shimoda> this is not important for arm64, but bsp team wonder if how to handle more than 2GHz on .round_rate callback on 32-bit arch +09:37 < geertu> I think Shimoda-san was first +09:38 < shimoda> because .round_rate return type is just long ,not long long +09:38 < shimoda> on 32-bit arch, we don't have any 2GHz CPU ? :) +09:39 < shimoda> s/CPU/CPU and internal busses/ +09:39 < geertu> This is indeed a serious issue. I think it should be taken up with the clock maintainers. +09:40 < geertu> Usually the rate is unsigned long, but there are a few places where long is used. +09:40 < shimoda> why BSP team realized this topic because they used static analyses (QAC) +09:41 < geertu> If long is used, a negative value is used to indicate an error code. +09:41 < geertu> Since error codes are small negative numbers, one approach to solve this would be similar to IS_ERR(), which uses +09:41 < geertu> #define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO) +09:42 < geertu> with MAX_ERRNO = 4095, that would allow up to 4.2 GHz. +09:42 < geertu> Of course doing that would require many changes in code handling long rates, plus it's not a final solution. +09:43 < Marex> shimoda: maybe you can compile 32bit kernel and run it on H3 in 32bit mode ? +09:43 < Marex> shimoda: at least raspi3 is capable of running 32bit kernel on arm64 CPU, and H3 has some 3.2 GHz bus in it IIRC +09:43 < geertu> IIRC, the general census (hope?) was that high-rate clocks are contained on 64-bit architectures, where long is 64-bit +09:44 < shimoda> Marex: yes, but I never try it though. +09:44 < geertu> Marex: Even the old Cell Broadband Engine ran at 3.2 GHz +09:44 < Marex> geertu: the VC5 also has ~2.9GHz PLL and it can be well connected to 32bit CPU +09:45 < Marex> I guess there are many 32bit systems with > 2GHz clock +09:46 < geertu> [PATCH v2 00/34] change clk_ops->round_rate to scale past LONG_MAX +09:46 < geertu> https://lore.kernel.org/lkml/1514833681-30737-1-git-send-email-pure.logic@nexus-software.ie/ +09:47 < geertu> v1 did fave feedback +09:47 < geertu> https://lore.kernel.org/lkml/20180102190159.GH7997@codeaurora.org/ +09:47 < Marex> shimoda: I didn't try it either, I'd expect a few things to break there too +09:48 < geertu> implement the determine_rate op instead of the +09:48 < geertu> round_rate op +09:50 < geertu> None of the drivers/clk/renesas/ drivers implement that yet +09:50 < geertu> So that seems the way to go, for now. +09:51 < shimoda> geertu: oh, thank you for the information! so, now we can use up to 4GHz on 32bit arch if we add the determine_rate op on drivers/clk/renesas +09:51 < geertu> shimoda: Does that answe your question? +09:51 < shimoda> geertu: yes, thanks! +09:51 < Marex> geertu: isn't that more of a workaround ? +09:52 < geertu> Marex: More or less. I gains us a factor 2, until everything is 64-bit and Y2038-compliant +09:52 < geertu> s/I/It/ +09:53 < geertu> horms: Next topic? +09:53 < Marex> btw I think the realtime core in Gen3 is 32bit and can run Linux ? +09:53 < geertu> Marex: I guess it can. Same for the RT on older SoCs +09:53 < horms> geertu: uli___: is there a prospect of including Z2 support for R-Car Gen3? This came up for me while scaning BSP patches for E3 +09:54 < uli___> if that's desired, sure +09:54 < Marex> geertu: older SoCs don't have fast PLLs like the Gen3, so they clock code there won't fail +09:55 < Marex> shimoda: thank you for the M3W SDHI suggestion, I'll check it today-ish :-) +09:55 < geertu> uli___: IIRC, you posted Z (ZG?) patches that have review comments? +09:55 < uli___> zg, iirc +09:56 < uli___> as mentioned in the update, i'll review my unmerged patches next +09:56 < geertu> uli___: OK, thanks! +09:57 < horms> ok great. my main aim in bringing this up was to avoid duplication of effort +09:57 < horms> geertu: do we know anything about if CPUIdle can be enabled on R-Car Gen3. Again question generated by BSP hunting +09:58 < geertu> horms: You mean e.g. a2e020874a4ad69a ("arm64: dts: r8a7796-m3ulcb: Disable CPUIdle support for CA53") in the BSP? +09:58 < geertu> Which claims it;s not supported on ES1, but doesn't tell why? +09:59 < shimoda> Marex: you're welcome! :) +09:59 < horms> I was thinking more of: +09:59 < horms> $ git log --oneline --grep=CPUIdle master..rcar-3.9.2 +09:59 < horms> df0d0ecb5f8a arm64: dts: r8a7796-m3ulcb: Disable CPUIdle support for CA53 +09:59 < horms> b96175039caa arm64: dts: r8a77990: Add CPUIdle support for CA53 +09:59 < horms> c635f6a8ad20 arm64: dts: r8a77965: Add CPUIdle support for CA57 +09:59 < horms> 902ff7caa32d arm64: dts: r8a7796: Add CPUIdle support for all CPU core +09:59 < horms> 3c3b44c752c4 arm64: dts: r8a7795: Add CPUIdle support for all CPU core +10:01 < horms> Perhaps a way forward would be ask for clarification on which SoCs+ES versions the feature is supported +10:02 < geertu> df0d0ecb5f8a is the same (rebased bsp versus periupport) +10:03 < geertu> So yes, we need clarification +10:03 < horms> sorry, i meant to aknowledge that the patch is the same +10:03 < horms> shimoda: morimoto: could we ask for such clarification? +10:03 < geertu> Ah, uli___ seems to have submitted these before, in Aug +10:04 < horms> ok, my bad again for not having remembered that +10:04 < geertu> To which I replied (incl. Kihara-san, Diem-san, Khiem-san): +10:04 < geertu> Given many Salvator-X boards (incl. mine) also have M3-W ES1.0, and PSCI is +10:04 < geertu> involved, I have to ask: is this a hardware (M3-W ES1.0) or firmware (PSCI) +10:04 < geertu> issue? +10:05 < horms> I think the slightly bigger picture is that we are getting rather close to parity between upstream and the BSP in so far as features that are appropriate for upstream +10:05 < horms> That is, for E3 +10:05 < geertu> true +10:05 < geertu> s/Diem/Dien/ +10:05 < horms> I agree with your question +10:06 < horms> My assumption is that it is not addressed in the BSP because Slavator-X boards are assumed to have more recent SoCs than ES1 +10:06 < horms> s/1/1.0/ +10:06 < horms> But its just an assumption +10:06 < horms> so clarification seems very appropriate +10:07 < geertu> Commerically-available boards are ULCB +10:07 < horms> Perhaps we can just add this to the minutes +10:07 < geertu> and the first patch disables it on r8a7796-m3ulcb +10:07 < horms> Its not urgent +10:07 < geertu> OK, will do. +10:07 < horms> Also, I had no other topics +10:07 < geertu> Any other topics? +10:07 < geertu> If not, I'll pass the em-eye-see to pinchartl +10:08 < geertu> Thanks for joining, and have a nice continued day! |