summaryrefslogtreecommitdiff
path: root/wiki/Chat_log/20190110-core-chatlog
diff options
context:
space:
mode:
Diffstat (limited to 'wiki/Chat_log/20190110-core-chatlog')
-rw-r--r--wiki/Chat_log/20190110-core-chatlog124
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!