[RFC] Allwinner T536 initial support & pinctrl register layout redesign

[RFC] Allwinner T536 initial support & pinctrl register layout redesign

[qianfanguijin]

Hi everyone,

I'm reaching out to see if there's any interest in supporting the Allwinner T536, an industrial-grade SoC featuring a quad-core Cortex-A55. I'm currently working on an upstream Linux kernel port for this chip.

Progress so far:

    Basic CCU support
    pinctrl (GPIO and IRQ)
    UART console
    Successfully boots a minimal initramfs

The T536 introduces a redesigned GPIO register layout that is incompatible with the register mapping used by currently supported Allwinner SoCs. To accommodate this, I've refactored relevant register-related information into the pinctrl ops structure.

Andre, I heavily referenced your recent work on the A523 during development. Could you confirm whether GPIO interrupts are currently functional on A523? In my testing on the T536, I noticed that when irq_read_needs_mux is configured, the IRQ multiplexing mode is incorrectly set to 6, which breaks interrupt handling. I don't have access to A523 hardware for verification, but it appears this logic may need adjustment. Any insights or testing feedback would be greatly appreciated.

Due to the GPIO subsystem redesign, I've made several modifications to the sunxi-pinctrl driver. A work-in-progress tree is available for review here: https://github.com/qianfan-Zhao/linux/tree/t536

I would appreciate your review and guidance on the upstreaming strategy:

    Should the pinctrl/register layout changes be submitted and merged first as a foundation?
    Or is it preferred to hold off until broader T536 support is complete?

Any feedback on the code structure, IRQ handling, or submission workflow would be extremely helpful. I'll format and send proper patches via git send-email once the direction is confirmed.

Thanks in advance for your time and guidance.

Re: [RFC] Allwinner T536 initial support & pinctrl register layout redesign

[Andre Przywara]

On Thu, 16 Apr 2026 18:57:20 +0800
qianfanguijin <qianfanguijin@163.com> wrote:

Hi,

> Hi everyone,
> 
> I'm reaching out to see if there's any interest in supporting the Allwinner T536, an industrial-grade SoC featuring a quad-core Cortex-A55. I'm currently working on an upstream Linux kernel port for this chip.

Many thanks for doing this and reaching out!

> Progress so far:
> 
>     Basic CCU support
>     pinctrl (GPIO and IRQ)
>     UART console
>     Successfully boots a minimal initramfs
> 
> The T536 introduces a redesigned GPIO register layout that is incompatible with the register mapping used by currently supported Allwinner SoCs. To accommodate this, I've refactored relevant register-related information into the pinctrl ops structure.

I have just skimmed over this, but I guess that's the same new layout
as the A733? PortA starts at 0x80, there are set/clear registers after
the data register, other registers move, IRQ register inside each GPIO
bank and so on? If so, you should just piggy back on my patches, that
already introduce support for this new layout:
https://lore.kernel.org/linux-sunxi/20250821004232.8134-1-andre.przywara@arm.com/

This uses a different approach than you, please have a look and see how
you like this. If you think yours is better, please let me know.

> Andre, I heavily referenced your recent work on the A523 during development. Could you confirm whether GPIO interrupts are currently functional on A523? In my testing on the T536, I noticed that when irq_read_needs_mux is configured, the IRQ multiplexing mode is incorrectly set to 6, which breaks interrupt handling. I don't have access to A523 hardware for verification, but it appears this logic may need adjustment. Any insights or testing feedback would be greatly appreciated.

Yes, this is indeed broken, which was recently discovered. I tried to
fix this for v7.0 still, but this didn't happen :-(
The quick fix for the A523 is here:
https://lore.kernel.org/linux-sunxi/20260327113006.3135663-1-andre.przywara@arm.com/T/#u
There is a more elaborate version, but this has some issues and needs
more work:
https://lore.kernel.org/linux-sunxi/20260323110151.2352832-1-andre.przywara@arm.com/T/#u

For a new SoC it's simple to address: just don't use
irq_read_needs_mux (it's not needed anyway), and make sure the IRQs are
correct, including potentially non-implemented banks.
 
> Due to the GPIO subsystem redesign, I've made several modifications
> to the sunxi-pinctrl driver. A work-in-progress tree is available for
> review here: https://github.com/qianfan-Zhao/linux/tree/t536
> 
> I would appreciate your review and guidance on the upstreaming
> strategy:
> 
>     Should the pinctrl/register layout changes be submitted and
> merged first as a foundation?

Well, they should be part of the series. While refactoring is indeed
somewhat independent from the full SoC support, and could be
upstreamed separately, the motivation for the refactor needs to be
there, so we need to see the full picture. Compare my A733 pinctrl
series referenced above: you do the refactoring first, then add support
for the new SoC on top. But all within one series.
Also splitting this up in independent series creates nasty and
confusing dependencies, which are also a moving target. So keep things
in one series.

>     Or is it preferred to hold off until broader T536 support is complete?

I tend to do the following splitup:
- One series with pinctrl support. Contains binding patch(es),
  potentially refactoring, then the SoC specific driver boilerplate.
  Basically what you have, but just the pinctrl parts.
- One series with clock support. I understand it's tempting to do this
  with just a few clocks, but in the past we always did the full clock
  tree. You can split this up by clock types, purely for review
  reasons. Compare the current A733 clock series:
https://lore.kernel.org/linux-sunxi/20260310-a733-clk-v1-0-36b4e9b24457@pigmoral.tech/
- One series with new PMIC support, if needed. The PMIC is needed to
  keep the kernel forwards and backwards compatible with new DTs. If say
  Linux v7.2 contains basic driver support, but not the PMIC, then
  future DT, now referencing the PMIC, would no longer boot on v7.2,
  since that doesn't know the PMIC. Which is a regression. So we need
  PMIC support from the very start. If T536 boards use already
  supported PMIC, there wouldn't be anything to do here.
- The same is true for RTC support. The actual calendar functionality
  doesn't matter, but on Allwinner the RTC provides essential clocks.
  Again if older kernels wouldn't know about the RTC, then newer DTs
  might break the boot on older kernel, thus introducing a regression.
  So we need the RTC from day one.
- The final series with the DT support. Introduce the trivial bindings
  for the new SoC names, otherwise relying on the driver bindings
  introduced with the series above. This would be the series really
  adding support, even though it typically contains no code.

> Any feedback on the code structure, IRQ handling, or submission workflow would be extremely helpful. I'll format and send proper patches via git send-email once the direction is confirmed.

So yes, I'd say try to rebase the pinctrl part on top of my A733
pinctrl series. I will try to send an updated version after -rc1,
incorporating the A523 IRQ fixes. Ideally your submission would be
just the DT binding, plus the per-SoC "driver file", which is now rather
simple.

Then check the PMIC and RTC situation, maybe you are lucky and it's
simple. The nasty and tedious part is the clock support, and I am afraid
there is no easy way out there. Some things are just complicated and
complex. ;-)
Good thing is those series can go in parallel, since there are no
dependencies between them. It's just that the final DT support
series needs to wait for everything else to land, before it can be
merged.

Cheers,
Andre

> Thanks in advance for your time and guidance.
> 
> 
> 
> 
> 

Re: Re: [RFC] Allwinner T536 initial support & pinctrl register layout redesign

[qianfanguijin]

>On Thu, 16 Apr 2026 18:57:20 +0800



>qianfanguijin <qianfanguijin@163.com> wrote:



>



>Hi,



>



>> Hi everyone,



>> 



>> I'm reaching out to see if there's any interest in supporting the Allwinner T536, an industrial-grade SoC featuring a quad-core Cortex-A55. I'm currently working on an upstream Linux kernel port for this chip.



>



>Many thanks for doing this and reaching out!



>



>> Progress so far:



>> 



>>     Basic CCU support



>>     pinctrl (GPIO and IRQ)



>>     UART console



>>     Successfully boots a minimal initramfs



>> 



>> The T536 introduces a redesigned GPIO register layout that is incompatible with the register mapping used by currently supported Allwinner SoCs. To accommodate this, I've refactored relevant register-related information into the pinctrl ops structure.



>



>I have just skimmed over this, but I guess that's the same new layout



>as the A733? PortA starts at 0x80, there are set/clear registers after



>the data register, other registers move, IRQ register inside each GPIO



>bank and so on? If so, you should just piggy back on my patches, that



>already introduce support for this new layout:



>https://lore.kernel.org/linux-sunxi/20250821004232.8134-1-andre.przywara@arm.com/



>



>This uses a different approach than you, please have a look and see how



>you like this. If you think yours is better, please let me know.



>
I had also weighed using `ops` versus `flags` when designing this. Initially, 
I leaned toward `ops` for the flexibility it offers. However, I ran into a 
structural issue: if I define the ops struct in `pinctrl-t536.c`, 
other compatible SoCs (like the A733 you mentioned) won't be able to access 
it cleanly. Moving it to the shared `pinctrl-sunxi.c` would work, 
but that would break the per-SoC modularity.

After reviewing your latest patch, I agree that the `flags` approach is 
much cleaner and more elegant. I'll rebase my series on top of your commit 
and adapt my changes accordingly.

Just a minor suggestion: when reviewing the code, `SUNXI_PINCTRL_ELEVEN_BANKS` 
initially appeared to indicate that the SoC has 11 GPIO banks (A through K). 
In practice, it actually denotes that bank PK uses a non-contiguous register 
address space relative to the other banks. The current name might be slightly 
misleading.



>> Andre, I heavily referenced your recent work on the A523 during development. Could you confirm whether GPIO interrupts are currently functional on A523? In my testing on the T536, I noticed that when irq_read_needs_mux is configured, the IRQ multiplexing mode is incorrectly set to 6, which breaks interrupt handling. I don't have access to A523 hardware for verification, but it appears this logic may need adjustment. Any insights or testing feedback would be greatly appreciated.



>



>Yes, this is indeed broken, which was recently discovered. I tried to



>fix this for v7.0 still, but this didn't happen :-(



>The quick fix for the A523 is here:



>https://lore.kernel.org/linux-sunxi/20260327113006.3135663-1-andre.przywara@arm.com/T/#u



>There is a more elaborate version, but this has some issues and needs



>more work:



>https://lore.kernel.org/linux-sunxi/20260323110151.2352832-1-andre.przywara@arm.com/T/#u



>



>For a new SoC it's simple to address: just don't use



>irq_read_needs_mux (it's not needed anyway), and make sure the IRQs are



>correct, including potentially non-implemented banks.



> 
I've learned the patch. Saving the register value and restoring it later 
indeed resolves the issue. With this change, we no longer depend on the
 `SUN4I_FUNC_IRQ` definition. 



>> Due to the GPIO subsystem redesign, I've made several modifications



>> to the sunxi-pinctrl driver. A work-in-progress tree is available for



>> review here: https://github.com/qianfan-Zhao/linux/tree/t536



>> 



>> I would appreciate your review and guidance on the upstreaming



>> strategy:



>> 



>>     Should the pinctrl/register layout changes be submitted and



>> merged first as a foundation?



>



>Well, they should be part of the series. While refactoring is indeed



>somewhat independent from the full SoC support, and could be



>upstreamed separately, the motivation for the refactor needs to be



>there, so we need to see the full picture. Compare my A733 pinctrl



>series referenced above: you do the refactoring first, then add support



>for the new SoC on top. But all within one series.



>Also splitting this up in independent series creates nasty and



>confusing dependencies, which are also a moving target. So keep things



>in one series.



>



>>     Or is it preferred to hold off until broader T536 support is complete?



>



>I tend to do the following splitup:



>- One series with pinctrl support. Contains binding patch(es),



>  potentially refactoring, then the SoC specific driver boilerplate.



>  Basically what you have, but just the pinctrl parts.



>- One series with clock support. I understand it's tempting to do this



>  with just a few clocks, but in the past we always did the full clock



>  tree. You can split this up by clock types, purely for review



>  reasons. Compare the current A733 clock series:



>https://lore.kernel.org/linux-sunxi/20260310-a733-clk-v1-0-36b4e9b24457@pigmoral.tech/



>- One series with new PMIC support, if needed. The PMIC is needed to



>  keep the kernel forwards and backwards compatible with new DTs. If say



>  Linux v7.2 contains basic driver support, but not the PMIC, then



>  future DT, now referencing the PMIC, would no longer boot on v7.2,



>  since that doesn't know the PMIC. Which is a regression. So we need



>  PMIC support from the very start. If T536 boards use already



>  supported PMIC, there wouldn't be anything to do here.



>- The same is true for RTC support. The actual calendar functionality



>  doesn't matter, but on Allwinner the RTC provides essential clocks.



>  Again if older kernels wouldn't know about the RTC, then newer DTs



>  might break the boot on older kernel, thus introducing a regression.



>  So we need the RTC from day one.



>- The final series with the DT support. Introduce the trivial bindings



>  for the new SoC names, otherwise relying on the driver bindings



>  introduced with the series above. This would be the series really



>  adding support, even though it typically contains no code.



>



>> Any feedback on the code structure, IRQ handling, or submission workflow would be extremely helpful. I'll format and send proper patches via git send-email once the direction is confirmed.



>



>So yes, I'd say try to rebase the pinctrl part on top of my A733



>pinctrl series. I will try to send an updated version after -rc1,



>incorporating the A523 IRQ fixes. Ideally your submission would be



>just the DT binding, plus the per-SoC "driver file", which is now rather



>simple.



>



>Then check the PMIC and RTC situation, maybe you are lucky and it's



>simple. The nasty and tedious part is the clock support, and I am afraid



>there is no easy way out there. Some things are just complicated and



>complex. ;-)



>Good thing is those series can go in parallel, since there are no



>dependencies between them. It's just that the final DT support



>series needs to wait for everything else to land, before it can be



>merged.

Thanks for the guidance. I'll rebase my T536 series on top of your A733 patches 
and continue working on T536 support. The GPIO part is much simpler now. 
In the meantime, I'll focus on getting MMC and GMAC working. 
Once those two are functional, the rest of the bring-up process will be easier. 
I'm currently still heavily reliant on a ramdisk, which makes debugging 
a bit tedious.



>



>Cheers,



>Andre



>



>> Thanks in advance for your time and guidance.



>> 



>> 



>> 



>> 



>>