ARM Sunxi Platform Development
 help / color / mirror / Atom feed
From: Richard GENOUD <richard.genoud@bootlin.com>
To: John Stultz <jstultz@google.com>
Cc: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Chen-Yu Tsai" <wens@csie.org>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"Samuel Holland" <samuel@sholland.org>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Paul Kocialkowski" <paulk@sys-base.io>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/4] Introduce Allwinner H616 PWM controller
Date: Thu, 26 Feb 2026 09:52:43 +0100	[thread overview]
Message-ID: <11efec54-6d13-4ca1-a11b-f91da9e1306b@bootlin.com> (raw)
In-Reply-To: <CANDhNCrSjp1F0PifJXmxrAbRiTC=d_ZXeiiT5kGuM=gNke7ebA@mail.gmail.com>

Le 23/02/2026 à 21:14, John Stultz a écrit :
> On Fri, Jan 23, 2026 at 1:33 AM Richard Genoud
> <richard.genoud@bootlin.com> 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@google.com>

That's great, thanks for testing!

> 
> thanks
> -john
> 


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

      reply	other threads:[~2026-02-26  8:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-23  9:33 [PATCH v3 0/4] Introduce Allwinner H616 PWM controller Richard Genoud
2026-01-23  9:33 ` [PATCH v3 1/4] dt-bindings: pwm: allwinner: add h616 pwm compatible Richard Genoud
2026-01-23 17:16   ` Conor Dooley
2026-01-23  9:33 ` [PATCH v3 2/4] pwm: sun50i: Add H616 PWM support Richard Genoud
2026-01-23 19:56   ` kernel test robot
2026-02-26 14:12   ` Philipp Zabel
2026-02-27 16:22     ` Richard GENOUD
2026-01-23  9:33 ` [PATCH v3 3/4] arm64: dts: allwinner: h616: add PWM controller Richard Genoud
2026-01-23  9:33 ` [PATCH v3 4/4] MAINTAINERS: Add entry on Allwinner H616 PWM driver Richard Genoud
2026-02-23 20:14 ` [PATCH v3 0/4] Introduce Allwinner H616 PWM controller John Stultz
2026-02-26  8:52   ` Richard GENOUD [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=11efec54-6d13-4ca1-a11b-f91da9e1306b@bootlin.com \
    --to=richard.genoud@bootlin.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=jstultz@google.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=p.zabel@pengutronix.de \
    --cc=paulk@sys-base.io \
    --cc=robh@kernel.org \
    --cc=samuel@sholland.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=u.kleine-koenig@baylibre.com \
    --cc=wens@csie.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