Re: [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@xxxxxxxxxxx> wrote:
> > On 2024-04-30 12:46, Andre Przywara wrote:
> > > On Tue, 30 Apr 2024 02:01:42 +0200
> > > Dragan Simic <dsimic@xxxxxxxxxxx> 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@xxxxxxxxxxx/