[v4,0/8] cpufreq: sun50i: Add Allwinner H616 support

This series adds cpufreq support to the Allwinner H616 SoC.
v4 allows compilation outside of arm/arm64, by making the SMCCC call
optional, the rest of the changes are added tags and cosmetic fixes.
This is based on Martin's original series from about half a year ago[1].
Thanks for the comments on the list!
See below for a changelog.

=================
The various H616 chips seem to be qualified by production batches, and
there is a table that translates from some efuses values to actual speed
bin indexes. Also the die revision has a say here: we can derive this
from the SoC ID, already provided by TF-A through the SMCCC SoC ID
interface.
So while the H6 had explicit speed bin indexes in the efuses, this is
conceptually not that different, and after refactoring patch 4/8 this
can be neatly integrated into the existing (H6) sun50i-cpufreq-nvmem
driver.
On top of that, not all chips are qualified to reach the full 1.5GHz,
and the BSP kernel describes different OPPs for each speedbin. This
requires to add support for the opp-supported-hw DT property, to be
able to describe those requirements properly.

Patch 1/8 exports the SoC ID function, so that we can call it from our
driver. Patch 2/8 blocks the affected SoCs from the generic DT cpufreq
driver, patch 3/8 adds the DT binding documentation.
Patch 4/8 refactors the existing speedbin determination for the H6, to
be able to plug in the H616 version later more easily.
Patch 5/8 adds support for the opp-supported-hw property. This is done
in a generic way, so it's usable for other SoCs as well, and the code
will figure out if the current DT requires use of this feature.
Patch 6/8 then eventually adds the H616 bits to the driver, and ties
that to the new compatible string.
Patch 7/8 add the CPU OPP table as a .dtsi to the DT directory, the
values in there were taken from the BSP source.
Patch 8/8 then enables the OPPs for all boards we have DTs for.

Based on v6.9-rc1.

Please have a look!

Cheers,
Andre

[1] https://lore.kernel.org/linux-sunxi/20230904-cpufreq-h616-v1-0-b8842e525c43@somainline.org/T/#u

Changelog v3 .. v4:
- add Review and Ack tags
- allow to compile without CONFIG_HAVE_ARM_SMCCC_DISCOVERY
- limit opp-supported-hw array length to 1
- drop unneeded pipe after description in binding
- reorder variables in reverse christmas tree in refactor patch

Changelog v2 .. v3:
- rebased on top of v6.9-rc1
- drop node name suffix from DT bindings
- drop multiple nodes per frequency in DT bindings example
- add H700 nvmem value and OPPs
- print warning for unknown nvmem values
- add #cooling-cells properties to CPU DT nodes
- use one DT node per frequency for OPP table entries
- include OPP table for newly added Longan board

Changelog v1 .. v2:
- extend commit messages
- add H618/H700 SoC IDs
- fix binding compatible enum
- fix binding documentation
- allow additional suffix to OPP node name
- shorten existing DT binding example
- add another (opp-supported-hw) binding example
- move speed bin decoding refactoring to separate patch (Brandon)
- move opp-supported-hw support to separate patch
- merge opp-supported-hw and microvolt suffix handling
- rewrite OPP tables without opp-microvolt-speed suffix


Andre Przywara (2):
  cpufreq: sun50i: Add support for opp_supported_hw
  arm64: dts: allwinner: h616: enable DVFS for all boards

Brandon Cheo Fusi (1):
  cpufreq: sun50i: Refactor speed bin decoding

Martin Botka (5):
  firmware: smccc: Export revision soc_id function
  cpufreq: dt-platdev: Blocklist Allwinner H616/618 SoCs
  dt-bindings: opp: Describe H616 OPPs and opp-supported-hw
  cpufreq: sun50i: Add H616 support
  arm64: dts: allwinner: h616: Add CPU OPPs table

 .../allwinner,sun50i-h6-operating-points.yaml |  87 ++++----
 .../sun50i-h616-bigtreetech-cb1.dtsi          |   5 +
 .../dts/allwinner/sun50i-h616-cpu-opp.dtsi    | 125 +++++++++++
 .../allwinner/sun50i-h616-orangepi-zero2.dts  |   5 +
 .../dts/allwinner/sun50i-h616-x96-mate.dts    |   5 +
 .../arm64/boot/dts/allwinner/sun50i-h616.dtsi |   8 +
 .../sun50i-h618-longan-module-3h.dtsi         |   5 +
 .../allwinner/sun50i-h618-orangepi-zero2w.dts |   5 +
 .../allwinner/sun50i-h618-orangepi-zero3.dts  |   5 +
 .../sun50i-h618-transpeed-8k618-t.dts         |   5 +
 drivers/cpufreq/cpufreq-dt-platdev.c          |   3 +
 drivers/cpufreq/sun50i-cpufreq-nvmem.c        | 206 +++++++++++++++---
 drivers/firmware/smccc/smccc.c                |   1 +
 13 files changed, 388 insertions(+), 77 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-cpu-opp.dtsi

On Thu, 4 Apr 2024, at 7:40 PM, Viresh Kumar wrote:
> Is it okay to merge all the changes via the cpufreq tree ?

I have tested this series with an H700-based board, and have at least one speed-bin (1.032GHz) is not supported although the governor attempts to enable it based on the opp-supported-hw bitmask, and I am unable to reach the 1.5GHz bin at 1.16v (or higher) despite it working on the vendor BSP (kernel panic at boot if enabled), so this may need some slight rework.

I have reached out to Andre on IRC to debug.

Ryan

On Thu, 04 Apr 2024 20:44:02 +1300
"Ryan Walklin" <ryan@testtoast.com> wrote:

Hi Viresh, Ryan,

> On Thu, 4 Apr 2024, at 7:40 PM, Viresh Kumar wrote:
> > Is it okay to merge all the changes via the cpufreq tree ?  
> 
> I have tested this series with an H700-based board, and have at least one speed-bin (1.032GHz) is not supported although the governor attempts to enable it based on the opp-supported-hw bitmask, and I am unable to reach the 1.5GHz bin at 1.16v (or higher) despite it working on the vendor BSP (kernel panic at boot if enabled), so this may need some slight rework.
> 
> I have reached out to Andre on IRC to debug.

So those test results look odd, especially since it seems to work on the
BSP. I don't want to jeopardise this series over the oddity on this
variant, so I am dropping the H700 specific speed bin for now. Not
directly matching any known SoC variant now, it will fall back to bin 0,
which gives us some safe values. We lose the highest OPP (1.5 GHz),
but this was exactly the problematic one in the testing, so it's not a
great loss.
Once we have worked out what's really going on there, we can easily add a
well tested OPP set later, to get the 1.5 GHz back.

Will send a v5 shortly.

Cheers,
Andre