Re: [PATCH 0/6] sunxi: A133: Add CPU speed grade detection and OPP table

[Andre Przywara <andre.przywara@arm.com>]

Hi Rajan,

many thanks for putting this together, especially for really going deep 
into the problem, and trying to sort out the messy ID scheme that 
Allwinner employs here.

Jumping straight to the questions you asked below:

On 11/5/26 05:40, Rajan Yadav via B4 Relay wrote:
> Andre asked [1], in his review of my A100 thermal trips patch [2], to
> look at the A133 speed bin selection and OPPs. Mainline treats the A133
> as an A100: it reads only the CPU bin field and picks one of three A100
> voltage tables. The vendor BSP for this family (sun50iw10, KickPi A133
> Linux SDK, linux-4.9) picks one of 11 grades from the chip marking ID,

[ ... ]>
> Questions:
> 
> 1. 1.6 GHz. Andre mentioned the nominal 1.6 GHz OPP. The SDK's code
>     and table select b2 for this chip and stop at 1512 MHz. The factory
>     kernel on this board (built January 2026) has a newer table: there
>     1608 MHz exists only for b0 and b1, the revision A-E high speed
>     grades, at the same voltage as their 1512 MHz OPP (1.18 V and
>     1.13 V), and 1416 MHz is added for a0-a2. That kernel selects b0 for
>     this revision F chip; its boot log suggests that its cpufreq code
>     does not read the revision (the revision is first read about 110 s
>     after boot). With the series' rules this board stays b2, so adding
>     1608 MHz for b0/b1 would not change it, and I have no revision A-E
>     part to test. With the b0 voltages forced by a test DTB (6.18), the
>     K5C was stable for an hour but sat at the 90 C trip, cycling between
>     1416 and 1608 MHz, with less than 1% more work than b2. The A133
>     datasheet says 1.6 GHz in V1.1 and 1.5 GHz in V1.5. Should 1608 MHz
>     be added for speed6/7 (b0/b1), as in the factory table?

So I read about the 1.6GHz somewhere, might just be a marketing claim 
about some max frequency. If the common speedbins do not support 1.6GHz, 
that's fine, but apparently some do, so I'd keep them in, for people who 
happen to have those SoC revisions.

> 2. A100. The BSP uses the same rules for the A100, and the mainline A100
>     table has the a0-a2 voltages, but at 1080 MHz where the BSP has
>     1008 MHz. U-Boot starts the CPU at 1008 MHz, so mainline now logs
>     "unlisted initial frequency". Should the A100 table move to
>     1008 MHz too, or the A100 board to the new compatible? I can only
>     test an A133.

I don't think we have ever seen A100s in the wild really, reportedly 
they got phased out very early in favour of the better performing A133. 
A100 is just used as a name because it was the only name back then when 
support was upstreamed, and in the kernel we tend to not care too much 
about vendors' marketing and naming strategies too much ... ;-)
I think if we can be sure that the current mainline OPPs still apply 
with this series, that's good enough.

Regarding 1008 MHz: This was just some frequency close to 1GHz picked by 
U-Boot, that should be low enough to not cause any trouble, even with 
the default voltage. How critical is this "unlisted initial frequency" 
message? If it causes trouble, we can add a made-up 1008MHz OPP with 
some safe voltage, otherwise I'd say we just leave it.

 > 3. SOC_ID. Would you rather have the driver read the revision from> 
   SYSCON+0x24 itself (the system controller is already in the DT)?
>     Then it would not depend on the firmware, and parts would never run
>     below the vendor voltage for lack of it. And do the Teclast P80 and
>     the Helperboard run a TF-A with SOC_ID?

We simply do not support non-mainline firmware, both TF-A and U-Boot, 
with a mainline kernel. For older SoCs they were just not compatible, 
but I don't know about the exact situation with newer parts.
So like for the H616, please just use the SoC ID call, that's a clean 
solution. Maybe just make sure that it can fail somewhat gracefully 
(read: not crash).

> 4. A133P. My SDK has no A133P data, and Andre expects it to go
>     higher. An A133P whose marking ID is in the BSP's high speed list
>     gets b grades with A133 voltages; otherwise it gets a grades (at
>     most 1464 MHz). If someone has a newer BSP (5.4) with A133P tables
>     and marking IDs, I can add them.

I have just read that the "P" allegedly stands for "performance", and 
this it can clock up to 1.8 GHz. So again, just use what the BSP OPP 
table tells us. We are in no position to qualify enough parts to make 
such a decision. And we can always extend the table later should new 
data appear.
I think some of those handheld gaming consoles use the A133P variant? 
Maybe there are some tables in "their" source code?

> 5. Testing. Patch 6 changes the Helperboard A133, Liontron H-A133L and
>     Teclast P80, which I cannot test. A boot log with
>     dyndbg="file sun50i-cpufreq-nvmem.c +p" on the kernel command line,
>     and the contents of
>     /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies,
>     from those boards would be very welcome; no fuse dump is needed. On
>     the P80 (secure boot), could someone also check SID bytes 0-1 (the
>     marking ID)? If they read as 0 from Linux, a high speed part is
>     treated as a normal one: it gets 1464 MHz instead of 1416 and
>     1512 MHz and, if its bin extension bit is set, up to 20 mV less than
>     its b grade would give.

Thanks, I will try to get those logs, I have the Liontron board and the 
Teclast tablet.

Thanks,
Andre

P.S. Since you mention the KickPi: can you please work with Paul (in 
CC:) to upstream the DT for this board? Seems to be one of the more sane 
and available devices with this SoC. I think Paul has plans to submit 
DTs upstream, but I guess he will be happy to have taken some load off 
his chest on this.