From: Andre Przywara <andre.przywara@arm.com>
To: Michal Piekos <michal.piekos@mmpsystems.pl>
Cc: Daniel Lezcano <daniel.lezcano@kernel.org>,
Thomas Gleixner <tglx@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Chen-Yu Tsai <wens@kernel.org>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Samuel Holland <samuel@sholland.org>,
Maxime Ripard <mripard@kernel.org>,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev
Subject: Re: [PATCH 0/4] Add hstimer support for H616 and T113-S3
Date: Wed, 22 Apr 2026 15:38:47 +0200 [thread overview]
Message-ID: <44aab543-a200-49bd-81e5-70d77ebe1c85@arm.com> (raw)
In-Reply-To: <h4b3xluygfptee3ej4gbr3hctgjk6q4oytkisk66saii4uyvl3@lw4qdtfuyoz5>
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,
>>>>
>>>>
>>
>>
prev parent reply other threads:[~2026-04-22 13:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-19 12:46 [PATCH 0/4] Add hstimer support for H616 and T113-S3 Michal Piekos
2026-04-19 12:46 ` [PATCH 1/4] dt-bindings: timer: allwinner,sun5i-a13-hstimer: add " Michal Piekos
2026-04-19 21:21 ` Andre Przywara
2026-04-19 12:46 ` [PATCH 2/4] clocksource/drivers/sun5i: add H616 hstimer support Michal Piekos
2026-04-19 22:39 ` Andre Przywara
2026-04-19 12:46 ` [PATCH 3/4] arm64: dts: allwinner: h616: add hstimer node Michal Piekos
2026-04-19 12:46 ` [PATCH 4/4] arm: dts: allwinner: t113s: " Michal Piekos
2026-04-19 20:55 ` [PATCH 0/4] Add hstimer support for H616 and T113-S3 Andre Przywara
2026-04-20 11:27 ` Michal Piekos
2026-04-20 14:14 ` Andre Przywara
2026-04-21 14:05 ` Michal Piekos
2026-04-22 13:38 ` Andre Przywara [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44aab543-a200-49bd-81e5-70d77ebe1c85@arm.com \
--to=andre.przywara@arm.com \
--cc=conor+dt@kernel.org \
--cc=daniel.lezcano@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jernej.skrabec@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=michal.piekos@mmpsystems.pl \
--cc=mripard@kernel.org \
--cc=robh@kernel.org \
--cc=samuel@sholland.org \
--cc=tglx@kernel.org \
--cc=wens@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox