Messages in this thread | | | Date | Fri, 03 May 2024 11:13:28 +0200 | From | Dragan Simic <> | Subject | Re: [PATCH] arm64: dts: allwinner: Add cache information to the SoC dtsi for H6 |
| |
Hello Andre,
On 2024-05-01 11:30, Andre Przywara wrote: > On Tue, 30 Apr 2024 13:10:41 +0200 > Dragan Simic <dsimic@manjaro.org> wrote: >> On 2024-04-30 12:46, Andre Przywara wrote: >> > On Tue, 30 Apr 2024 02:01:42 +0200 >> > Dragan Simic <dsimic@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/
| |