Re: [PATCH v3 0/4] Introduce Allwinner H616 PWM controller

[Richard GENOUD]

Le 23/02/2026 à 21:14, John Stultz a écrit :
> On Fri, Jan 23, 2026 at 1:33 AM Richard Genoud
> <richard.genoud@xxxxxxxxxxx> wrote:
> > Allwinner H616 PWM controller is quite different from the A10 one.
> >
> > It can drive 6 PWM channels, and like for the A10, each channel has a
> > bypass that permits to output a clock, bypassing the PWM logic, when
> > enabled.
> >
> > But, the channels are paired 2 by 2, sharing a first set of
> > MUX/prescaler/gate.
> > Then, for each channel, there's another prescaler (that will be bypassed
> > if the bypass is enabled for this channel).
> >
> > It looks like that:
> >              _____      ______      ________
> > OSC24M --->|     |    |      |    |        |
> > APB1 ----->| Mux |--->| Gate |--->| /div_m |-----> PWM_clock_src_xy
> >             |_____|    |______|    |________|
> >                            ________
> >                           |        |
> >                        +->| /div_k |---> PWM_clock_x
> >                        |  |________|
> >                        |    ______
> >                        |   |      |
> >                        +-->| Gate |----> PWM_bypass_clock_x
> >                        |   |______|
> > PWM_clock_src_xy -----+   ________
> >                        |  |        |
> >                        +->| /div_k |---> PWM_clock_y
> >                        |  |________|
> >                        |    ______
> >                        |   |      |
> >                        +-->| Gate |----> PWM_bypass_clock_y
> >                            |______|
> >
> > Where xy can be 0/1, 2/3, 4/5
> >
> > PWM_clock_x/y serve for the PWM purpose.
> > PWM_bypass_clock_x/y serve for the clock-provider purpose.
> > The common clock framework has been used to manage those clocks.
> >
> > This PWM driver serves as a clock-provider for PWM_bypass_clocks.
> > This is needed for example by the embedded AC300 PHY which clock comes
> > from PMW5 pin (PB12).
> >
> > Usually, to get a clock from a PWM driver, we use the pwm-clock driver
> > so that the PWM driver doesn't need to be a clk-provider itself.
> > While this works in most cases, here it just doesn't.
> > That's because the pwm-clock request a period from the PWM driver,
> > without any clue that it actually wants a clock at a specific frequency,
> > and not a PWM signal with duty cycle capability.
> > So, the PWM driver doesn't know if it can use the bypass or not, it
> > doesn't even have the real accurate frequency information (23809524 Hz
> > instead of 24MHz) because PWM drivers only deal with periods.
> >
> > With pwm-clock, we loose a precious information along the way (that we
> > actually want a clock and not a PWM signal).
> > That's ok with simple PWM drivers that don't have multiple input clocks,
> > but in this case, without this information, we can't know for sure which
> > clock to use.
> > And here, for instance, if we ask for a 24MHz clock, pwm-clock will
> > requests 42ns (assigned-clocks doesn't help for that matter). The logic
> > is to select the highest clock (100MHz) with no prescaler and a duty
> > cycle value of 2/4 => we have 25MHz instead of 24MHz.
> > And that's a perfectly fine choice for a PMW, because we still can
> > change the duty cycle in the range [0-4]/4.
> > But obviously for a clock, we don't care about the duty cycle, but more
> > about the clock accuracy.
> >
> > And actually, this PWM is really a PWM AND a real clock when the bypass
> > is set.
>
> During my free/personal time this weekend I was tinkering with Orange
> Pi Zero 2w and was able to use this patch series (along with an
> hdmi-phy patch and some dts changes) to get HDMI working on the
> device.
> I'm eager to see these land!
>
> Tested-by: John Stultz <jstultz@xxxxxxxxxx>

That's great, thanks for testing!

> thanks
> -john


--
Richard Genoud, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com