[PATCH 0/2] Add SID and THS calibration for Allwinner R40

[PATCH 0/2] Add SID and THS calibration for Allwinner R40

[Otavio Salvador]

The R40 thermal sensor node has no calibration data. The THS driver
then keeps the calibration registers at their reset value (0x800), and
the reported temperatures have a chip-dependent offset.

This series adds the R40 SID (eFuse) controller and connects the THS
node to its factory calibration at eFuse offset 0x40.

Patch 1 adds the R40 compatible to the SID binding, with the A64
compatible as fallback. The SID driver needs no change.

Patch 2 adds the SID node to sun8i-r40.dtsi and the nvmem cell for the
THS calibration.

Checked with dt_binding_check, and with dtbs_check on all R40, V40 and
T3 board DTBs. No warnings. Tested on two Boardcon EMA40i (A40i) boards.

Otavio Salvador (2):
  dt-bindings: nvmem: SID: Add binding for R40 SID controller
  ARM: dts: sun8i-r40: Add SID node and THS calibration

 .../bindings/nvmem/allwinner,sun4i-a10-sid.yaml   |  1 +
 arch/arm/boot/dts/allwinner/sun8i-r40.dtsi        | 15 ++++++++++++++-
 2 files changed, 15 insertions(+), 1 deletion(-)


base-commit: ff47652a4b66c067c765a7ad464d930b5a9367cc
-- 
2.55.0

[PATCH 1/2] dt-bindings: nvmem: SID: Add binding for R40 SID controller

[Otavio Salvador]

The Allwinner R40 SID exposes its 2Kbit eFuse at offset 0x200 of the
controller, readable directly from MMIO like on the A64. Add the R40
compatible with the A64 one as fallback, as done for the A100, H616 and
A523.

On an A40i, all 64 eFuse words read through the MMIO window match the
words read through the SID_PRCTL/SID_RDKEY registers, so the R40 does
not need the register-based readout of the H3.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
 .../devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml       | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml
index f67470b8a2ed2..a4960b0ef8cbe 100644
--- a/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml
+++ b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml
@@ -25,6 +25,7 @@ properties:
       - const: allwinner,sun50i-a64-sid
       - items:
           - enum:
+              - allwinner,sun8i-r40-sid
               - allwinner,sun50i-a100-sid
               - allwinner,sun50i-h616-sid
               - allwinner,sun55i-a523-sid
-- 
2.55.0

[PATCH 2/2] ARM: dts: sun8i-r40: Add SID node and THS calibration

[Otavio Salvador]

Without the calibration cell, the THS driver leaves the sensor
calibration registers at their reset value (0x800) and the reported
temperatures drift from the real die temperature by a chip-dependent
offset.

Add the SID node at 0x01c1b000 and wire the thermal sensor to its
factory calibration at eFuse offset 0x40, one 16-bit word for each of
the two sensors.

The R40 user manual gives the size of the thermal sensor key (32 bits)
but not its offset. The vendor SDK key map names 0x48 "thermal_sensor",
but that word is zero on all the boards checked. On an A40i running the
Boardcon vendor kernel, the THS_0_1_CDATA register holds exactly the
eFuse word at 0x40 (0x08780875), which confirms the location.

Tested on two Boardcon EMA40i (A40i) boards: THS_0_1_CDATA now holds
the eFuse word at 0x40 of each chip (0x082d0822 and 0x083d0838) instead
of the reset value 0x08000800.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
 arch/arm/boot/dts/allwinner/sun8i-r40.dtsi | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/allwinner/sun8i-r40.dtsi b/arch/arm/boot/dts/allwinner/sun8i-r40.dtsi
index f0ed802a9d08e..c7c9cad695ca4 100644
--- a/arch/arm/boot/dts/allwinner/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/allwinner/sun8i-r40.dtsi
@@ -485,6 +485,18 @@ ohci1: usb@1c19400 {
 			status = "disabled";
 		};
 
+		sid: efuse@1c1b000 {
+			compatible = "allwinner,sun8i-r40-sid",
+				     "allwinner,sun50i-a64-sid";
+			reg = <0x01c1b000 0x400>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			ths_calibration: thermal-sensor-calibration@40 {
+				reg = <0x40 0x4>;
+			};
+		};
+
 		ehci2: usb@1c1c000 {
 			compatible = "allwinner,sun8i-r40-ehci", "generic-ehci";
 			reg = <0x01c1c000 0x100>;
@@ -832,7 +844,8 @@ ths: thermal-sensor@1c24c00 {
 			clock-names = "bus", "mod";
 			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
 			resets = <&ccu RST_BUS_THS>;
-			/* TODO: add nvmem-cells for calibration */
+			nvmem-cells = <&ths_calibration>;
+			nvmem-cell-names = "calibration";
 			#thermal-sensor-cells = <1>;
 		};
 
-- 
2.55.0

Re: [PATCH 2/2] ARM: dts: sun8i-r40: Add SID node and THS calibration

[Andre Przywara]

Hi Otavio,

thanks for sending the patch!

On 10/3/26 03:25, Otavio Salvador wrote:
> Without the calibration cell, the THS driver leaves the sensor
> calibration registers at their reset value (0x800) and the reported
> temperatures drift from the real die temperature by a chip-dependent
> offset.
> 
> Add the SID node at 0x01c1b000 and wire the thermal sensor to its
> factory calibration at eFuse offset 0x40, one 16-bit word for each of
> the two sensors.
> 
> The R40 user manual gives the size of the thermal sensor key (32 bits)
> but not its offset. The vendor SDK key map names 0x48 "thermal_sensor",
> but that word is zero on all the boards checked. On an A40i running the
> Boardcon vendor kernel, the THS_0_1_CDATA register holds exactly the
> eFuse word at 0x40 (0x08780875), which confirms the location.

So in some U-Boot BSP sources on github I see 
arch/arm/include/asm/arch-sun8iw11p1/sid.h putting the sensor at 0x34 
(like the H3 or A64).
Can you check the values there? I see that Tina-Linux puts them at 0x40, 
as you reported, and it's probably more reliable there than in the 
U-Boot sources, but it's worth double checking.

The rest looks alright (checked the manual and how the compatible string 
is handled in the driver), so if you can confirm that it's 0x40:

Reviewed-by: Andre Przywara <andre.przywara@arm.com>

Thanks,
Andre

> 
> Tested on two Boardcon EMA40i (A40i) boards: THS_0_1_CDATA now holds
> the eFuse word at 0x40 of each chip (0x082d0822 and 0x083d0838) instead
> of the reset value 0x08000800.
> 
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
> ---
>   arch/arm/boot/dts/allwinner/sun8i-r40.dtsi | 15 ++++++++++++++-
>   1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/allwinner/sun8i-r40.dtsi b/arch/arm/boot/dts/allwinner/sun8i-r40.dtsi
> index f0ed802a9d08e..c7c9cad695ca4 100644
> --- a/arch/arm/boot/dts/allwinner/sun8i-r40.dtsi
> +++ b/arch/arm/boot/dts/allwinner/sun8i-r40.dtsi
> @@ -485,6 +485,18 @@ ohci1: usb@1c19400 {
>   			status = "disabled";
>   		};
>   
> +		sid: efuse@1c1b000 {
> +			compatible = "allwinner,sun8i-r40-sid",
> +				     "allwinner,sun50i-a64-sid";
> +			reg = <0x01c1b000 0x400>;
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +
> +			ths_calibration: thermal-sensor-calibration@40 {
> +				reg = <0x40 0x4>;
> +			};
> +		};
> +
>   		ehci2: usb@1c1c000 {
>   			compatible = "allwinner,sun8i-r40-ehci", "generic-ehci";
>   			reg = <0x01c1c000 0x100>;
> @@ -832,7 +844,8 @@ ths: thermal-sensor@1c24c00 {
>   			clock-names = "bus", "mod";
>   			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
>   			resets = <&ccu RST_BUS_THS>;
> -			/* TODO: add nvmem-cells for calibration */
> +			nvmem-cells = <&ths_calibration>;
> +			nvmem-cell-names = "calibration";
>   			#thermal-sensor-cells = <1>;
>   		};
>   

Re: [PATCH 2/2] ARM: dts: sun8i-r40: Add SID node and THS calibration

[Otavio Salvador]

Hi Andre,

Thanks for the review.

Em seg., 5 de out. de 2026 às 06:02, Andre Przywara
<andre.przywara@arm.com> escreveu:
>
> Hi Otavio,
>
> thanks for sending the patch!
>
> On 10/3/26 03:25, Otavio Salvador wrote:
> > Without the calibration cell, the THS driver leaves the sensor
> > calibration registers at their reset value (0x800) and the reported
> > temperatures drift from the real die temperature by a chip-dependent
> > offset.
> >
> > Add the SID node at 0x01c1b000 and wire the thermal sensor to its
> > factory calibration at eFuse offset 0x40, one 16-bit word for each of
> > the two sensors.
> >
> > The R40 user manual gives the size of the thermal sensor key (32 bits)
> > but not its offset. The vendor SDK key map names 0x48 "thermal_sensor",
> > but that word is zero on all the boards checked. On an A40i running the
> > Boardcon vendor kernel, the THS_0_1_CDATA register holds exactly the
> > eFuse word at 0x40 (0x08780875), which confirms the location.
>
> So in some U-Boot BSP sources on github I see
> arch/arm/include/asm/arch-sun8iw11p1/sid.h putting the sensor at 0x34
> (like the H3 or A64).
> Can you check the values there? I see that Tina-Linux puts them at 0x40,
> as you reported, and it's probably more reliable there than in the
> U-Boot sources, but it's worth double checking.
>
> The rest looks alright (checked the manual and how the compatible string
> is handled in the driver), so if you can confirm that it's 0x40:
>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>

Yes, I checked 0x34. The BPI U-Boot sid.h for sun8iw11p1 puts the
thermal key there, but that word is zero on every A40i I dumped: three
boards on mainline with this patch, and the Boardcon board on its
vendor kernel. 0x48 is zero too. Only 0x40 holds two plausible 12-bit
values:

  board 1: 0x08780875 (vendor kernel, THS_0_1_CDATA = 0x08780875)
  board 2: 0x082d0822
  board 3: 0x083d0838

The value differs per board, and on the vendor kernel THS_0_1_CDATA
holds exactly the word at 0x40. With this patch, CDATA on boards 2 and
3 also matches their word at 0x40. So 0x40 it is, matching Tina Linux.

I also compared the MMIO window at SID + 0x200 with the register-based
readout (the H3 method) across several boots. All 64 words matched, so
the R40 doesn't seem to have the H3 readout problem.

Best regards,
Otavio

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854

Re: [PATCH 2/2] ARM: dts: sun8i-r40: Add SID node and THS calibration

[Andre Przywara]

On Mon, 5 Oct 2026 12:49:57 -0300
Otavio Salvador <otavio.salvador@ossystems.com.br> wrote:

Hi Otavio,

> Thanks for the review.
> 
> Em seg., 5 de out. de 2026 às 06:02, Andre Przywara
> <andre.przywara@arm.com> escreveu:
> >
> > Hi Otavio,
> >
> > thanks for sending the patch!
> >
> > On 10/3/26 03:25, Otavio Salvador wrote:
> > > Without the calibration cell, the THS driver leaves the sensor
> > > calibration registers at their reset value (0x800) and the reported
> > > temperatures drift from the real die temperature by a chip-dependent
> > > offset.
> > >
> > > Add the SID node at 0x01c1b000 and wire the thermal sensor to its
> > > factory calibration at eFuse offset 0x40, one 16-bit word for each of
> > > the two sensors.
> > >
> > > The R40 user manual gives the size of the thermal sensor key (32 bits)
> > > but not its offset. The vendor SDK key map names 0x48 "thermal_sensor",
> > > but that word is zero on all the boards checked. On an A40i running the
> > > Boardcon vendor kernel, the THS_0_1_CDATA register holds exactly the
> > > eFuse word at 0x40 (0x08780875), which confirms the location.
> >
> > So in some U-Boot BSP sources on github I see
> > arch/arm/include/asm/arch-sun8iw11p1/sid.h putting the sensor at 0x34
> > (like the H3 or A64).
> > Can you check the values there? I see that Tina-Linux puts them at 0x40,
> > as you reported, and it's probably more reliable there than in the
> > U-Boot sources, but it's worth double checking.
> >
> > The rest looks alright (checked the manual and how the compatible string
> > is handled in the driver), so if you can confirm that it's 0x40:
> >
> > Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> 
> Yes, I checked 0x34. The BPI U-Boot sid.h for sun8iw11p1 puts the
> thermal key there, but that word is zero on every A40i I dumped: three
> boards on mainline with this patch, and the Boardcon board on its
> vendor kernel. 0x48 is zero too. Only 0x40 holds two plausible 12-bit
> values:

Yes, I found my BananaPi-M2 Berry, and can confirm that 0x34 holds 0,
and 0x40 reads 0x085a0857.

So all fine, 0x40 it is.

Thanks for checking, and my tag of course stands.

> 
>   board 1: 0x08780875 (vendor kernel, THS_0_1_CDATA = 0x08780875)
>   board 2: 0x082d0822
>   board 3: 0x083d0838
> 
> The value differs per board, and on the vendor kernel THS_0_1_CDATA
> holds exactly the word at 0x40. With this patch, CDATA on boards 2 and
> 3 also matches their word at 0x40. So 0x40 it is, matching Tina Linux.
> 
> I also compared the MMIO window at SID + 0x200 with the register-based
> readout (the H3 method) across several boots. All 64 words matched, so
> the R40 doesn't seem to have the H3 readout problem.

Yes, we have never seen this issue again, it seems to have been a
one-off bug.

Cheers,
Andre