[PATCH 0/4] Add hstimer support for H616 and T113-S3

[PATCH 0/4] Add hstimer support for H616 and T113-S3

[Michal Piekos]

Add support for Allwinner H616 high speed timer in sun5i hstimer driver
and describe corresponding nodes in dts for H616 and T113-S3.

H616 uses same model as existing driver except register shift compared
to older variants. 

Added register layout abstraction in the driver, extended the binding
with new compatibles and wired up dts nodes for H616 and T113-S3 which
uses H616 as fallback compatible.

Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
---
Michal Piekos (4):
      dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3
      clocksource/drivers/sun5i: add H616 hstimer support
      arm64: dts: allwinner: h616: add hstimer node
      arm: dts: allwinner: t113s: add hstimer node

 .../timer/allwinner,sun5i-a13-hstimer.yaml         |  8 +++-
 arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi       | 12 +++++
 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi     |  9 ++++
 drivers/clocksource/timer-sun5i.c                  | 56 +++++++++++++++++++---
 4 files changed, 78 insertions(+), 7 deletions(-)
---
base-commit: faeab166167f5787719eb8683661fd41a3bb1514
change-id: 20260413-h616-t113s-hstimer-62939948f91c

Best regards,
-- 
Michal Piekos <michal.piekos@mmpsystems.pl>

[PATCH 1/4] dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3

[Michal Piekos]

H616 is compatible with the existing sun5i binding, but
require its own compatible string to differentiate register offsets.
T113-S3 uses same offsets as H616.

Add allwinner,sun50i-h616-hstimer
Add allwinner,sun8i-t113s-hstimer with fallback to
allwinner,sun50i-h616-hstimer
Extend schema condition for interrupts to cover H616 compatible variant.

Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
---
 .../devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml    | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
index f1853daec2f9..bb60a85dc34b 100644
--- a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
+++ b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
@@ -15,9 +15,13 @@ properties:
     oneOf:
       - const: allwinner,sun5i-a13-hstimer
       - const: allwinner,sun7i-a20-hstimer
+      - const: allwinner,sun50i-h616-hstimer
       - items:
           - const: allwinner,sun6i-a31-hstimer
           - const: allwinner,sun7i-a20-hstimer
+      - items:
+          - const: allwinner,sun8i-t113s-hstimer
+          - const: allwinner,sun50i-h616-hstimer
 
   reg:
     maxItems: 1
@@ -45,7 +49,9 @@ required:
 if:
   properties:
     compatible:
-      const: allwinner,sun5i-a13-hstimer
+      enum:
+        - allwinner,sun5i-a13-hstimer
+        - allwinner,sun50i-h616-hstimer
 
 then:
   properties:

-- 
2.43.0

Re: [PATCH 1/4] dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3

[Andre Przywara]

On Sun, 19 Apr 2026 14:46:07 +0200
Michal Piekos <michal.piekos@mmpsystems.pl> wrote:

> H616 is compatible with the existing sun5i binding, but
> require its own compatible string to differentiate register offsets.

Just a nit: if the register offsets are different, then it's not
compatible, not even with the binding. So just say something like "they
are similar, but with different register offsets".

> T113-S3 uses same offsets as H616.

So it looks like (somewhat naturally) this is true for D1 as well? And
since that SoC was the first, we use "sun20i-d1" as the compatible
string prefix for this SoC's devices. I think we should follow suit
here and name that similarly.

> 
> Add allwinner,sun50i-h616-hstimer
> Add allwinner,sun8i-t113s-hstimer with fallback to
> allwinner,sun50i-h616-hstimer
> Extend schema condition for interrupts to cover H616 compatible variant.
> 
> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> ---
>  .../devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml    | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
> index f1853daec2f9..bb60a85dc34b 100644
> --- a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
> +++ b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
> @@ -15,9 +15,13 @@ properties:
>      oneOf:
>        - const: allwinner,sun5i-a13-hstimer
>        - const: allwinner,sun7i-a20-hstimer
> +      - const: allwinner,sun50i-h616-hstimer
>        - items:
>            - const: allwinner,sun6i-a31-hstimer
>            - const: allwinner,sun7i-a20-hstimer
> +      - items:
> +          - const: allwinner,sun8i-t113s-hstimer
> +          - const: allwinner,sun50i-h616-hstimer
>  
>    reg:
>      maxItems: 1
> @@ -45,7 +49,9 @@ required:
>  if:
>    properties:
>      compatible:
> -      const: allwinner,sun5i-a13-hstimer
> +      enum:
> +        - allwinner,sun5i-a13-hstimer
> +        - allwinner,sun50i-h616-hstimer

IIUC this just matches the H616, but wouldn't match the T113/D1? And
there is some construct with "contains" to match for fallback
compatibles?

Cheers,
Andre
>  
>  then:
>    properties:
> 

[PATCH 2/4] clocksource/drivers/sun5i: add H616 hstimer support

[Michal Piekos]

H616 high speed timer differs from existing timer-sun5i by register base
offset.

Add selectable register layout structures.
Add H616 compatible string to OF match table.

Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
---
 drivers/clocksource/timer-sun5i.c | 56 ++++++++++++++++++++++++++++++++++-----
 1 file changed, 50 insertions(+), 6 deletions(-)

diff --git a/drivers/clocksource/timer-sun5i.c b/drivers/clocksource/timer-sun5i.c
index f827d3f98f60..125abc11c3c3 100644
--- a/drivers/clocksource/timer-sun5i.c
+++ b/drivers/clocksource/timer-sun5i.c
@@ -21,18 +21,52 @@
 #define TIMER_IRQ_EN_REG		0x00
 #define TIMER_IRQ_EN(val)			BIT(val)
 #define TIMER_IRQ_ST_REG		0x04
-#define TIMER_CTL_REG(val)		(0x20 * (val) + 0x10)
 #define TIMER_CTL_ENABLE			BIT(0)
 #define TIMER_CTL_RELOAD			BIT(1)
-#define TIMER_CTL_CLK_PRES(val)			(((val) & 0x7) << 4)
 #define TIMER_CTL_ONESHOT			BIT(7)
-#define TIMER_INTVAL_LO_REG(val)	(0x20 * (val) + 0x14)
-#define TIMER_INTVAL_HI_REG(val)	(0x20 * (val) + 0x18)
-#define TIMER_CNTVAL_LO_REG(val)	(0x20 * (val) + 0x1c)
-#define TIMER_CNTVAL_HI_REG(val)	(0x20 * (val) + 0x20)
+#define TIMER_CTL_CLK_PRES(val)		(((val) & 0x7) << 4)
+#define TIMER_CTL_REG(val)		\
+	(soc_base->stride * (val) + soc_base->ctl_base)
+#define TIMER_INTVAL_LO_REG(val)	\
+	(soc_base->stride * (val) + soc_base->intval_lo_base)
+#define TIMER_INTVAL_HI_REG(val)	\
+	(soc_base->stride * (val) + soc_base->intval_hi_base)
+#define TIMER_CNTVAL_LO_REG(val)	\
+	(soc_base->stride * (val) + soc_base->cntval_lo_base)
+#define TIMER_CNTVAL_HI_REG(val)	\
+	(soc_base->stride * (val) + soc_base->cntval_hi_base)
 
 #define TIMER_SYNC_TICKS	3
 
+struct sunxi_timer_base {
+	u32 ctl_base;
+	u32 intval_lo_base;
+	u32 intval_hi_base;
+	u32 cntval_lo_base;
+	u32 cntval_hi_base;
+	u32 stride;
+};
+
+static const struct sunxi_timer_base sun5i_base = {
+	.ctl_base = 0x10,
+	.intval_lo_base = 0x14,
+	.intval_hi_base = 0x18,
+	.cntval_lo_base = 0x1c,
+	.cntval_hi_base = 0x20,
+	.stride = 0x20
+};
+
+static const struct sunxi_timer_base sun50i_base = {
+	.ctl_base = 0x20,
+	.intval_lo_base = 0x24,
+	.intval_hi_base = 0x28,
+	.cntval_lo_base = 0x2c,
+	.cntval_hi_base = 0x30,
+	.stride = 0x20
+};
+
+static const struct sunxi_timer_base *soc_base;
+
 struct sun5i_timer {
 	void __iomem		*base;
 	struct clk		*clk;
@@ -238,6 +272,7 @@ static int sun5i_setup_clockevent(struct platform_device *pdev,
 static int sun5i_timer_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
+	struct device_node *node = dev_of_node(&pdev->dev);
 	struct sun5i_timer *st;
 	struct reset_control *rstc;
 	void __iomem *timer_base;
@@ -251,6 +286,14 @@ static int sun5i_timer_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, st);
 
+	if (!node)
+		return -EINVAL;
+
+	if (of_device_is_compatible(node, "allwinner,sun50i-h616-hstimer"))
+		soc_base = &sun50i_base;
+	else
+		soc_base = &sun5i_base;
+
 	timer_base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(timer_base)) {
 		dev_err(dev, "Can't map registers\n");
@@ -314,6 +357,7 @@ static void sun5i_timer_remove(struct platform_device *pdev)
 static const struct of_device_id sun5i_timer_of_match[] = {
 	{ .compatible = "allwinner,sun5i-a13-hstimer" },
 	{ .compatible = "allwinner,sun7i-a20-hstimer" },
+	{ .compatible = "allwinner,sun50i-h616-hstimer" },
 	{},
 };
 MODULE_DEVICE_TABLE(of, sun5i_timer_of_match);

-- 
2.43.0

Re: [PATCH 2/4] clocksource/drivers/sun5i: add H616 hstimer support

[Andre Przywara]

On Sun, 19 Apr 2026 14:46:08 +0200
Michal Piekos <michal.piekos@mmpsystems.pl> wrote:

Hi,

> H616 high speed timer differs from existing timer-sun5i by register base
> offset.
> 
> Add selectable register layout structures.
> Add H616 compatible string to OF match table.
> 
> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> ---
>  drivers/clocksource/timer-sun5i.c | 56 ++++++++++++++++++++++++++++++++++-----
>  1 file changed, 50 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/clocksource/timer-sun5i.c b/drivers/clocksource/timer-sun5i.c
> index f827d3f98f60..125abc11c3c3 100644
> --- a/drivers/clocksource/timer-sun5i.c
> +++ b/drivers/clocksource/timer-sun5i.c
> @@ -21,18 +21,52 @@
>  #define TIMER_IRQ_EN_REG		0x00
>  #define TIMER_IRQ_EN(val)			BIT(val)
>  #define TIMER_IRQ_ST_REG		0x04
> -#define TIMER_CTL_REG(val)		(0x20 * (val) + 0x10)
>  #define TIMER_CTL_ENABLE			BIT(0)
>  #define TIMER_CTL_RELOAD			BIT(1)
> -#define TIMER_CTL_CLK_PRES(val)			(((val) & 0x7) << 4)
>  #define TIMER_CTL_ONESHOT			BIT(7)
> -#define TIMER_INTVAL_LO_REG(val)	(0x20 * (val) + 0x14)
> -#define TIMER_INTVAL_HI_REG(val)	(0x20 * (val) + 0x18)
> -#define TIMER_CNTVAL_LO_REG(val)	(0x20 * (val) + 0x1c)
> -#define TIMER_CNTVAL_HI_REG(val)	(0x20 * (val) + 0x20)
> +#define TIMER_CTL_CLK_PRES(val)		(((val) & 0x7) << 4)
> +#define TIMER_CTL_REG(val)		\
> +	(soc_base->stride * (val) + soc_base->ctl_base)
> +#define TIMER_INTVAL_LO_REG(val)	\
> +	(soc_base->stride * (val) + soc_base->intval_lo_base)
> +#define TIMER_INTVAL_HI_REG(val)	\
> +	(soc_base->stride * (val) + soc_base->intval_hi_base)
> +#define TIMER_CNTVAL_LO_REG(val)	\
> +	(soc_base->stride * (val) + soc_base->cntval_lo_base)
> +#define TIMER_CNTVAL_HI_REG(val)	\
> +	(soc_base->stride * (val) + soc_base->cntval_hi_base)
>  
>  #define TIMER_SYNC_TICKS	3
>  
> +struct sunxi_timer_base {
> +	u32 ctl_base;
> +	u32 intval_lo_base;
> +	u32 intval_hi_base;
> +	u32 cntval_lo_base;
> +	u32 cntval_hi_base;
> +	u32 stride;
> +};
> +
> +static const struct sunxi_timer_base sun5i_base = {
> +	.ctl_base = 0x10,
> +	.intval_lo_base = 0x14,
> +	.intval_hi_base = 0x18,
> +	.cntval_lo_base = 0x1c,
> +	.cntval_hi_base = 0x20,

Mmmh, why all these members? Aren't those all the same, just offset by
0x10? So we just need a single value reg_offs, being either 0x0 or 0x10?

> +	.stride = 0x20

What it this about? It's the same stride for both versions, so why is
this a field?

> +};
> +
> +static const struct sunxi_timer_base sun50i_base = {
> +	.ctl_base = 0x20,
> +	.intval_lo_base = 0x24,
> +	.intval_hi_base = 0x28,
> +	.cntval_lo_base = 0x2c,
> +	.cntval_hi_base = 0x30,
> +	.stride = 0x20
> +};
> +
> +static const struct sunxi_timer_base *soc_base;

This doesn't look right. Differentiating between slightly different
hardware revision via the compatible string is a common pattern, look
at for instance drivers/media/rc/sunxi-cir.c and its usage of quirks for
an example how to handle this more nicely.

Cheers,
Andre

> +
>  struct sun5i_timer {
>  	void __iomem		*base;
>  	struct clk		*clk;
> @@ -238,6 +272,7 @@ static int sun5i_setup_clockevent(struct platform_device *pdev,
>  static int sun5i_timer_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
> +	struct device_node *node = dev_of_node(&pdev->dev);
>  	struct sun5i_timer *st;
>  	struct reset_control *rstc;
>  	void __iomem *timer_base;
> @@ -251,6 +286,14 @@ static int sun5i_timer_probe(struct platform_device *pdev)
>  
>  	platform_set_drvdata(pdev, st);
>  
> +	if (!node)
> +		return -EINVAL;
> +
> +	if (of_device_is_compatible(node, "allwinner,sun50i-h616-hstimer"))
> +		soc_base = &sun50i_base;
> +	else
> +		soc_base = &sun5i_base;
> +
>  	timer_base = devm_platform_ioremap_resource(pdev, 0);
>  	if (IS_ERR(timer_base)) {
>  		dev_err(dev, "Can't map registers\n");
> @@ -314,6 +357,7 @@ static void sun5i_timer_remove(struct platform_device *pdev)
>  static const struct of_device_id sun5i_timer_of_match[] = {
>  	{ .compatible = "allwinner,sun5i-a13-hstimer" },
>  	{ .compatible = "allwinner,sun7i-a20-hstimer" },
> +	{ .compatible = "allwinner,sun50i-h616-hstimer" },
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, sun5i_timer_of_match);
> 

[PATCH 3/4] arm64: dts: allwinner: h616: add hstimer node

[Michal Piekos]

Describe high speed timer block on Allwinner H616.

Tested on Orange Pi Zero 3:
- hstimer is registered as clocksource
- switching clocksource at runtime works
- after rating increase hstimer operates as a broadcast clockevent device

Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
---
 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
index bf054869e78b..0713a17264ec 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
@@ -237,6 +237,15 @@ timer0: timer@3009000 {
 			clocks = <&osc24M>;
 		};
 
+		hstimer@3005000 {
+			compatible = "allwinner,sun50i-h616-hstimer";
+			reg = <0x03005000 0x1000>;
+			interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&ccu CLK_BUS_HSTIMER>;
+			resets = <&ccu RST_BUS_HSTIMER>;
+		};
+
 		watchdog: watchdog@30090a0 {
 			compatible = "allwinner,sun50i-h616-wdt",
 				     "allwinner,sun6i-a31-wdt";

-- 
2.43.0

[PATCH 4/4] arm: dts: allwinner: t113s: add hstimer node

[Michal Piekos]

Describe high speed timer block on Allwinner T113-S3.

Tested on LCPI-PC-T113/F113:
- hstimer is registered as clocksource
- switching clocksource at runtime works
- after rating increase hstimer operates as a broadcast clockevent device

Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
---
 arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi b/arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
index 424f4a2487e2..f811ae0924d6 100644
--- a/arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
+++ b/arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi
@@ -34,6 +34,18 @@ cpu1: cpu@1 {
 		};
 	};
 
+	soc {
+		hstimer@3008000 {
+			compatible = "allwinner,sun8i-t113s-hstimer",
+				     "allwinner,sun50i-h616-hstimer";
+				reg = <0x03008000 0x1000>;
+				interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+				clocks = <&ccu CLK_BUS_HSTIMER>;
+				resets = <&ccu RST_BUS_HSTIMER>;
+		};
+	};
+
 	gic: interrupt-controller@1c81000 {
 		compatible = "arm,gic-400";
 		reg = <0x03021000 0x1000>,

-- 
2.43.0

Re: [PATCH 0/4] Add hstimer support for H616 and T113-S3

[Andre Przywara]

On Sun, 19 Apr 2026 14:46:06 +0200
Michal Piekos <michal.piekos@mmpsystems.pl> wrote:

Hi Michal,

> Add support for Allwinner H616 high speed timer in sun5i hstimer driver
> and describe corresponding nodes in dts for H616 and T113-S3.
> 
> H616 uses same model as existing driver except register shift compared
> to older variants. 
> 
> Added register layout abstraction in the driver, extended the binding
> with new compatibles and wired up dts nodes for H616 and T113-S3 which
> uses H616 as fallback compatible.

Can you say *why* we need this? IIUC Linux only ever uses one clock
source, and selects the (non-optional) Generic Timer (aka arch timer)
for that? So can you say what this hstimer clock source adds? I guess
higher resolution, but what is your use case, so why would you need the
200 MHz? And does this offset the higher access cost of an MMIO
access, compared to the arch timer's sysreg based access? Also, IIUC,
people would need to manually select this as the clocksource, why and
when would they do so? (Given they even know about it in the first
place).
Also the hstimer hasn't been used since the A20, so nobody seemed to
have missed it meanwhile?

Cheers,
Andre

> 
> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> ---
> Michal Piekos (4):
>       dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3
>       clocksource/drivers/sun5i: add H616 hstimer support
>       arm64: dts: allwinner: h616: add hstimer node
>       arm: dts: allwinner: t113s: add hstimer node
> 
>  .../timer/allwinner,sun5i-a13-hstimer.yaml         |  8 +++-
>  arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi       | 12 +++++
>  arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi     |  9 ++++
>  drivers/clocksource/timer-sun5i.c                  | 56 +++++++++++++++++++---
>  4 files changed, 78 insertions(+), 7 deletions(-)
> ---
> base-commit: faeab166167f5787719eb8683661fd41a3bb1514
> change-id: 20260413-h616-t113s-hstimer-62939948f91c
> 
> Best regards,

Re: [PATCH 0/4] Add hstimer support for H616 and T113-S3

[Michal Piekos]

On Sun, Apr 19, 2026 at 10:55:39PM +0200, Andre Przywara wrote:
> On Sun, 19 Apr 2026 14:46:06 +0200
> Michal Piekos <michal.piekos@mmpsystems.pl> wrote:
> 
> Hi Michal,
> 
> > Add support for Allwinner H616 high speed timer in sun5i hstimer driver
> > and describe corresponding nodes in dts for H616 and T113-S3.
> > 
> > H616 uses same model as existing driver except register shift compared
> > to older variants. 
> > 
> > Added register layout abstraction in the driver, extended the binding
> > with new compatibles and wired up dts nodes for H616 and T113-S3 which
> > uses H616 as fallback compatible.
> 
> Can you say *why* we need this? IIUC Linux only ever uses one clock
> source, and selects the (non-optional) Generic Timer (aka arch timer)
> for that? So can you say what this hstimer clock source adds? I guess
> higher resolution, but what is your use case, so why would you need the
> 200 MHz? And does this offset the higher access cost of an MMIO
> access, compared to the arch timer's sysreg based access? Also, IIUC,
> people would need to manually select this as the clocksource, why and
> when would they do so? (Given they even know about it in the first
> place).
> Also the hstimer hasn't been used since the A20, so nobody seemed to
> have missed it meanwhile?
> 
> Cheers,
> Andre
>
I took the table from https://linux-sunxi.org/Linux_mainlining_effort as
a todo list and wanted to help with it. I do not have own use case for
this timer. If it is not needed then I will spin v2 to include your
comments and abandon it.

Michal

> > 
> > Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> > ---
> > Michal Piekos (4):
> >       dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3
> >       clocksource/drivers/sun5i: add H616 hstimer support
> >       arm64: dts: allwinner: h616: add hstimer node
> >       arm: dts: allwinner: t113s: add hstimer node
> > 
> >  .../timer/allwinner,sun5i-a13-hstimer.yaml         |  8 +++-
> >  arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi       | 12 +++++
> >  arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi     |  9 ++++
> >  drivers/clocksource/timer-sun5i.c                  | 56 +++++++++++++++++++---
> >  4 files changed, 78 insertions(+), 7 deletions(-)
> > ---
> > base-commit: faeab166167f5787719eb8683661fd41a3bb1514
> > change-id: 20260413-h616-t113s-hstimer-62939948f91c
> > 
> > Best regards,
> 
> 

Re: [PATCH 0/4] Add hstimer support for H616 and T113-S3

[Andre Przywara]

Hi Michal,

On 4/20/26 13:27, Michal Piekos wrote:
> On Sun, Apr 19, 2026 at 10:55:39PM +0200, Andre Przywara wrote:
>> On Sun, 19 Apr 2026 14:46:06 +0200
>> Michal Piekos <michal.piekos@mmpsystems.pl> wrote:
>>
>> Hi Michal,
>>
>>> Add support for Allwinner H616 high speed timer in sun5i hstimer driver
>>> and describe corresponding nodes in dts for H616 and T113-S3.
>>>
>>> H616 uses same model as existing driver except register shift compared
>>> to older variants.
>>>
>>> Added register layout abstraction in the driver, extended the binding
>>> with new compatibles and wired up dts nodes for H616 and T113-S3 which
>>> uses H616 as fallback compatible.
>>
>> Can you say *why* we need this? IIUC Linux only ever uses one clock
>> source, and selects the (non-optional) Generic Timer (aka arch timer)
>> for that? So can you say what this hstimer clock source adds? I guess
>> higher resolution, but what is your use case, so why would you need the
>> 200 MHz? And does this offset the higher access cost of an MMIO
>> access, compared to the arch timer's sysreg based access? Also, IIUC,
>> people would need to manually select this as the clocksource, why and
>> when would they do so? (Given they even know about it in the first
>> place).
>> Also the hstimer hasn't been used since the A20, so nobody seemed to
>> have missed it meanwhile?
>>
>> Cheers,
>> Andre
>>
> I took the table from https://linux-sunxi.org/Linux_mainlining_effort as
> a todo list and wanted to help with it. I do not have own use case for
> this timer. If it is not needed then I will spin v2 to include your
> comments and abandon it.

Ah, that's good to know, and thanks for picking things from that list! I 
don't think there is a particular need to abandon your work, we could as 
well upstream it. At least the DT changes should be added, so that other 
DT users could make use of the timers - after all it's a Linux 
implementation choice to utilise just one timer. But please go ahead and 
post a complete v2, I don't think it hurts to have HSTIMER support in 
the kernel.
And while you are at it: can you figure out what the need is for using 
two timers? One is a clock source, the other is for clock events? And 
why do we limit the counters and timers to 32 bit? Even the A13 manual 
lists them as 56 bits, and a wraparound time of roughly 21 seconds (with 
32 bit counters) does not sound very long to me.


Not sure what your primary motivation for fixing Allwinner support is, 
but we could probably find more worthwhile targets. Do you have 
Allwinner boards other than the OrangePi Zero 3? There are not many low 
hanging fruits on the H616 left (MBUS and LDOs(?) maybe), but the A523 
has quite some missing drivers still, some of them probably more on the 
easy side.

If you are stuck with the OpiZero3, then you could just look and check 
the existing devices, and verify their operation. For instance I think 
USB-OTG is still broken - across most Allwinner SoCs actually, so it's a 
sunxi driver issue.

Thanks,
Andre

> 
> Michal
> 
>>>
>>> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
>>> ---
>>> Michal Piekos (4):
>>>        dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3
>>>        clocksource/drivers/sun5i: add H616 hstimer support
>>>        arm64: dts: allwinner: h616: add hstimer node
>>>        arm: dts: allwinner: t113s: add hstimer node
>>>
>>>   .../timer/allwinner,sun5i-a13-hstimer.yaml         |  8 +++-
>>>   arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi       | 12 +++++
>>>   arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi     |  9 ++++
>>>   drivers/clocksource/timer-sun5i.c                  | 56 +++++++++++++++++++---
>>>   4 files changed, 78 insertions(+), 7 deletions(-)
>>> ---
>>> base-commit: faeab166167f5787719eb8683661fd41a3bb1514
>>> change-id: 20260413-h616-t113s-hstimer-62939948f91c
>>>
>>> Best regards,
>>
>>

Re: [PATCH 0/4] Add hstimer support for H616 and T113-S3

[Michal Piekos]

On Mon, Apr 20, 2026 at 04:14:44PM +0200, Andre Przywara wrote:
> Hi Michal,
> 
> On 4/20/26 13:27, Michal Piekos wrote:
> > On Sun, Apr 19, 2026 at 10:55:39PM +0200, Andre Przywara wrote:
> > > On Sun, 19 Apr 2026 14:46:06 +0200
> > > Michal Piekos <michal.piekos@mmpsystems.pl> wrote:
> > > 
> > > Hi Michal,
> > > 
> > > > Add support for Allwinner H616 high speed timer in sun5i hstimer driver
> > > > and describe corresponding nodes in dts for H616 and T113-S3.
> > > > 
> > > > H616 uses same model as existing driver except register shift compared
> > > > to older variants.
> > > > 
> > > > Added register layout abstraction in the driver, extended the binding
> > > > with new compatibles and wired up dts nodes for H616 and T113-S3 which
> > > > uses H616 as fallback compatible.
> > > 
> > > Can you say *why* we need this? IIUC Linux only ever uses one clock
> > > source, and selects the (non-optional) Generic Timer (aka arch timer)
> > > for that? So can you say what this hstimer clock source adds? I guess
> > > higher resolution, but what is your use case, so why would you need the
> > > 200 MHz? And does this offset the higher access cost of an MMIO
> > > access, compared to the arch timer's sysreg based access? Also, IIUC,
> > > people would need to manually select this as the clocksource, why and
> > > when would they do so? (Given they even know about it in the first
> > > place).
> > > Also the hstimer hasn't been used since the A20, so nobody seemed to
> > > have missed it meanwhile?
> > > 
> > > Cheers,
> > > Andre
> > > 
> > I took the table from https://linux-sunxi.org/Linux_mainlining_effort as
> > a todo list and wanted to help with it. I do not have own use case for
> > this timer. If it is not needed then I will spin v2 to include your
> > comments and abandon it.
> 
> Ah, that's good to know, and thanks for picking things from that list! I
> don't think there is a particular need to abandon your work, we could as
> well upstream it. At least the DT changes should be added, so that other DT
> users could make use of the timers - after all it's a Linux implementation
> choice to utilise just one timer. But please go ahead and post a complete
> v2, I don't think it hurts to have HSTIMER support in the kernel.
> And while you are at it: can you figure out what the need is for using two
> timers? One is a clock source, the other is for clock events? And why do we
> limit the counters and timers to 32 bit? Even the A13 manual lists them as
> 56 bits, and a wraparound time of roughly 21 seconds (with 32 bit counters)
> does not sound very long to me.
> 
Yes. Channel 0 is clockevent and channel 1 is a clocksource and sync
reference for channel 0 disable timing. 

32 bit counters seems like implementation choice rather than limitation
but that would need to be implemented and tested. Would you suggest to
extend it to 56 bit in the following patch?

> 
> Not sure what your primary motivation for fixing Allwinner support is, but
> we could probably find more worthwhile targets. Do you have Allwinner boards
> other than the OrangePi Zero 3? There are not many low hanging fruits on the
> H616 left (MBUS and LDOs(?) maybe), but the A523 has quite some missing
> drivers still, some of them probably more on the easy side.
> 
I have boards with A733, A527, T113-S3, H616, H6, H3 and I
think some older stuff too. My motivation is mostly fun and learning.
I also use those boards in custom projects.

I will take up GPADC on A527 after finishing this as I worked with ADC's
a lot on MCU's. Unless other suggestions?

Thank you for comments.
Michal

> If you are stuck with the OpiZero3, then you could just look and check the
> existing devices, and verify their operation. For instance I think USB-OTG
> is still broken - across most Allwinner SoCs actually, so it's a sunxi
> driver issue.
> 
> Thanks,
> Andre
> 
> > 
> > Michal
> > 
> > > > 
> > > > Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> > > > ---
> > > > Michal Piekos (4):
> > > >        dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3
> > > >        clocksource/drivers/sun5i: add H616 hstimer support
> > > >        arm64: dts: allwinner: h616: add hstimer node
> > > >        arm: dts: allwinner: t113s: add hstimer node
> > > > 
> > > >   .../timer/allwinner,sun5i-a13-hstimer.yaml         |  8 +++-
> > > >   arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi       | 12 +++++
> > > >   arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi     |  9 ++++
> > > >   drivers/clocksource/timer-sun5i.c                  | 56 +++++++++++++++++++---
> > > >   4 files changed, 78 insertions(+), 7 deletions(-)
> > > > ---
> > > > base-commit: faeab166167f5787719eb8683661fd41a3bb1514
> > > > change-id: 20260413-h616-t113s-hstimer-62939948f91c
> > > > 
> > > > Best regards,
> > > 
> > > 
> 
> 

Re: [PATCH 0/4] Add hstimer support for H616 and T113-S3

[Andre Przywara]

Hi Michal,

On 4/21/26 16:05, Michal Piekos wrote:
> On Mon, Apr 20, 2026 at 04:14:44PM +0200, Andre Przywara wrote:
>> Hi Michal,
>>
>> On 4/20/26 13:27, Michal Piekos wrote:
>>> On Sun, Apr 19, 2026 at 10:55:39PM +0200, Andre Przywara wrote:
>>>> On Sun, 19 Apr 2026 14:46:06 +0200
>>>> Michal Piekos <michal.piekos@mmpsystems.pl> wrote:
>>>>
....

>>>>
>>> I took the table from https://linux-sunxi.org/Linux_mainlining_effort as
>>> a todo list and wanted to help with it. I do not have own use case for
>>> this timer. If it is not needed then I will spin v2 to include your
>>> comments and abandon it.
>>
>> Ah, that's good to know, and thanks for picking things from that list! I
>> don't think there is a particular need to abandon your work, we could as
>> well upstream it. At least the DT changes should be added, so that other DT
>> users could make use of the timers - after all it's a Linux implementation
>> choice to utilise just one timer. But please go ahead and post a complete
>> v2, I don't think it hurts to have HSTIMER support in the kernel.
>> And while you are at it: can you figure out what the need is for using two
>> timers? One is a clock source, the other is for clock events? And why do we
>> limit the counters and timers to 32 bit? Even the A13 manual lists them as
>> 56 bits, and a wraparound time of roughly 21 seconds (with 32 bit counters)
>> does not sound very long to me.
>>
> Yes. Channel 0 is clockevent and channel 1 is a clocksource and sync
> reference for channel 0 disable timing.
> 
> 32 bit counters seems like implementation choice rather than limitation
> but that would need to be implemented and tested. Would you suggest to
> extend it to 56 bit in the following patch?

Well, yes, I would assume we want as long an overflow period as 
possible. The tricky/interesting part is that the interface is still 
32-bit MMIO reads, so we need to find out how the consistency works. The 
manual recommends to read LO first, but not sure that means its latching 
HI upon the LO read. Otherwise we should read HI, LO, and HI again and 
compare both HI's. Probably needs some testing.

>> Not sure what your primary motivation for fixing Allwinner support is, but
>> we could probably find more worthwhile targets. Do you have Allwinner boards
>> other than the OrangePi Zero 3? There are not many low hanging fruits on the
>> H616 left (MBUS and LDOs(?) maybe), but the A523 has quite some missing
>> drivers still, some of them probably more on the easy side.
>>
> I have boards with A733, A527, T113-S3, H616, H6, H3 and I
> think some older stuff too. My motivation is mostly fun and learning.

That's great, and what I was hoping for! ;-)
Feel free to reach out on IRC if you have any questions or comments.

> I also use those boards in custom projects.
> 
> I will take up GPADC on A527 after finishing this as I worked with ADC's
> a lot on MCU's. Unless other suggestions?

Yes, LRADC and GPADC are good devices to start with. Also crypto comes 
to mind, the most useful there being the TRNG device, which helps the 
kernel to start its own RNG much quicker. Chances are those things are 
close to the existing SoCs, so there might be not too much to do here.

Cheers,
Andre

> 
> Thank you for comments.
> Michal
> 
>> If you are stuck with the OpiZero3, then you could just look and check the
>> existing devices, and verify their operation. For instance I think USB-OTG
>> is still broken - across most Allwinner SoCs actually, so it's a sunxi
>> driver issue.
>>
>> Thanks,
>> Andre
>>
>>>
>>> Michal
>>>
>>>>>
>>>>> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
>>>>> ---
>>>>> Michal Piekos (4):
>>>>>         dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3
>>>>>         clocksource/drivers/sun5i: add H616 hstimer support
>>>>>         arm64: dts: allwinner: h616: add hstimer node
>>>>>         arm: dts: allwinner: t113s: add hstimer node
>>>>>
>>>>>    .../timer/allwinner,sun5i-a13-hstimer.yaml         |  8 +++-
>>>>>    arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi       | 12 +++++
>>>>>    arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi     |  9 ++++
>>>>>    drivers/clocksource/timer-sun5i.c                  | 56 +++++++++++++++++++---
>>>>>    4 files changed, 78 insertions(+), 7 deletions(-)
>>>>> ---
>>>>> base-commit: faeab166167f5787719eb8683661fd41a3bb1514
>>>>> change-id: 20260413-h616-t113s-hstimer-62939948f91c
>>>>>
>>>>> Best regards,
>>>>
>>>>
>>
>>