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

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

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