[PATCH] arm64: dts: allwinner: Add cache information to the SoC dtsi for H6

[Dragan Simic]

Hello Andre,

On 2024-05-01 11:30, Andre Przywara wrote:
> On Tue, 30 Apr 2024 13:10:41 +0200
> Dragan Simic <dsimic at manjaro.org> wrote:
>> On 2024-04-30 12:46, Andre Przywara wrote:
>> > On Tue, 30 Apr 2024 02:01:42 +0200
>> > Dragan Simic <dsimic at manjaro.org> wrote:
>> >> Thank you very much for reviewing my patch in such a detailed way!
>> >> It's good to know that the values in the Allwinner datasheets match
>> >> with the observed reality, so to speak. :)
>> >
>> > YW, and yes, I like to double check things when it comes to Allwinner
>> > documentation ;-) And it was comparably easy for this problem.
>> 
>> Double checking is always good, IMHO. :)
>> 
>> > Out of curiosity: what triggered that patch? Trying to get rid of false
>> > warning/error messages?
>> 
>> Yes, one of the motivators was to get rid of the false kernel warning,
>> and the other was to have the cache information nicely available 
>> through
>> lscpu(1).  I already did the same for a few Rockchip SoCs, [1][2][3] 
>> so
>> a couple of Allwinner SoCs were the next on my mental TODO list. :)
> 
> Thanks for doing this!

I'm glad that you like all these patches. :)

>>> And do you plan to address the H616 as well? It's a bit more tricky 
>>> there,
>>> since there are two die revisions out: one with 256(?)KB of L2, one 
>>> with
>>> 1MB(!). We know how to tell them apart, so I could provide some TF-A 
>>> code
>>> to patch that up in the DT. The kernel DT copy could go with 256KB 
>>> then.
>> 
>> I have no boards based on the Allwinner H616, so it wasn't on my 
>> radar.
>> Though, I'd be happy to prepare and submit a similar kernel patch for
>> the H616, if you'd then take it further and submit a TF-A patch that
>> fixes the DT according to the detected die revision?  Did I understand
>> the plan right?
> 
> Yes, that was the idea. I have a working version of that TF-A patch 
> now,
> just need to figure out some details about the best way to only build 
> this
> for the H616 port.

Nice, the kernel patch for the H616 SoC dtsi is now on the list, [4]
please have a look.  Please let me know when your follow-up TF-A patch
gets submitted upstream, so I can watch it.

> Neither the data sheet nor the user manual mention the cache sizes for 
> the
> H616, but I checked the CSSIDR_EL1 register readouts on both an old 
> H616
> and a new H618, and they confirm that the former has 256 KB L2, and the
> latter 1MB.

Oh wow, 1 MB of L2 cache is quite a lot for such an SoC, which is
actually very nice to see.  Thumbs up for Allwinner not skimping on
the L2 cache in that H616 die revision. :)

> Also I ran tinymembench on two boards to confirm this,
> community benchmarks results are available here:
> https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md
> The OrangePi Zero2 and OrangePi Zero3 are good examples, respectively.
> Associativity and cache line size are dictated by the Arm Cortex cores,
> and the L1I & L1D sizes are the same as in the other SoCs.

I've included the most important benchmark results in the H616 SoC
dtsi patch, [4] which actually now serves as an additional reference
for the cache sizes.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=67a6a98575974416834c2294853b3814376a7ce7
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=8612169a05c5e979af033868b7a9b177e0f9fcdf
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=b72633ba5cfa932405832de25d0f0a11716903b4
[4] 
https://lore.kernel.org/linux-sunxi/9d52e6d338a059618d894abb0764015043330c2b.1714727227.git.dsimic@manjaro.org/