On Tue, 30 Apr 2024 02:01:42 +0200 Dragan Simic <dsimic@xxxxxxxxxxx> wrote: Hi Dragan, > Hello Andre, > > On 2024-04-30 01:10, Andre Przywara wrote: > > On Sun, 28 Apr 2024 13:40:36 +0200 > > Dragan Simic <dsimic@xxxxxxxxxxx> wrote: > > > >> Add missing cache information to the Allwinner H6 SoC dtsi, to allow > >> the userspace, which includes lscpu(1) that uses the virtual files > >> provided > >> by the kernel under the /sys/devices/system/cpu directory, to display > >> the > >> proper H6 cache information. > >> > >> Adding the cache information to the H6 SoC dtsi also makes the > >> following > >> warning message in the kernel log go away: > >> > >> cacheinfo: Unable to detect cache hierarchy for CPU 0 > >> > >> The cache parameters for the H6 dtsi were obtained and partially > >> derived > >> by hand from the cache size and layout specifications found in the > >> following > >> datasheets and technical reference manuals: > >> > >> - Allwinner H6 V200 datasheet, version 1.1 > >> - ARM Cortex-A53 revision r0p3 TRM, version E > >> > >> For future reference, here's a brief summary of the documentation: > >> > >> - All caches employ the 64-byte cache line length > >> - Each Cortex-A53 core has 32 KB of L1 2-way, set-associative > >> instruction > >> cache and 32 KB of L1 4-way, set-associative data cache > >> - The entire SoC has 512 KB of unified L2 16-way, set-associative > >> cache > >> > >> Signed-off-by: Dragan Simic <dsimic@xxxxxxxxxxx> > > > > I can confirm that the data below matches the manuals, but also the > > decoding of the architectural cache type registers (CCSIDR_EL1): > > L1D: 32 KB: 128 sets, 4 way associative, 64 bytes/line > > L1I: 32 KB: 256 sets, 2 way associative, 64 bytes/line > > L2: 512 KB: 512 sets, 16 way associative, 64 bytes/line > > 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. Out of curiosity: what triggered that patch? Trying to get rid of false warning/error messages? 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. Cheers, Andre.
