1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
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!
|
