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

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,
  

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,
  

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,
> 
>
  

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,
>>
>>
  

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,
> > > 
> > > 
> 
>
  

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,
>>>>
>>>>
>>
>>