Re: [PATCH v5 0/7] Tegra264 PWM support

On Wednesday, July 1, 2026 2:39 AM Uwe Kleine-König wrote:
> Hello,
> 
> On Tue, Jun 30, 2026 at 02:54:51PM +0100, Jon Hunter wrote:
> > On 02/06/2026 10:16, Jon Hunter wrote:
> > > 
> > > On 29/05/2026 03:47, Mikko Perttunen wrote:
> > > > Hello,
> > > > 
> > > > this adds support for the PWM controller on Tegra264. The controller
> > > > is similar to previous generations, but the register fields are
> > > > widened, the depth is made configurable, and the enable bit moves
> > > > to a different spot.
> > > > 
> > > > This series adds only basic support with fixed depth -- configurable
> > > > depth will come later.
> > > > 
> > > > Patch 1 adds device tree bindings for Tegra264 PWM (compatible
> > > >    string).
> > > > 
> > > > Patch 2 prefixes driver-local macros and static helpers with
> > > >    tegra_/TEGRA_ to make their scoping clear.
> > > > 
> > > > Patches 3 to 6 contain the PWM driver changes for Tegra264.
> > > > 
> > > > Patch 7 adds device tree nodes for the PWM controllers on Tegra264.
> > > 
> > > ...
> > > 
> > > > Mikko Perttunen (4):
> > > >        pwm: tegra: Prefix driver-local macros and functions
> > > >        pwm: tegra: Modify read/write accessors for multi-register channel
> > > >        pwm: tegra: Parametrize duty and scale field widths
> > > >        pwm: tegra: Add support for Tegra264
> > > > 
> > > > Thierry Reding (2):
> > > >        dt-bindings: pwm: Document Tegra264 controller
> > > >        arm64: tegra: Add PWM controllers on Tegra264
> > > > 
> > > > Yi-Wei Wang (1):
> > > >        pwm: tegra: Avoid hard-coded max clock frequency
> > > > 
> > > >   .../bindings/pwm/nvidia,tegra20-pwm.yaml           |   1 +
> > > >   arch/arm64/boot/dts/nvidia/tegra264.dtsi           |  72 ++++++++++
> > > >   drivers/pwm/pwm-tegra.c                            | 155
> > > > +++++++++++ +++-------
> > > >   3 files changed, 176 insertions(+), 52 deletions(-)
> > > 
> > > 
> > > For the series ...
> > > 
> > > Tested-by: Jon Hunter <[email protected]>
> > > Reviewed-by: Jon Hunter <[email protected]>
> > > 
> > > Uwe, if you are OK with the version, we would like to get this into -next.
> > 
> > This still applies fine on next-20260629 and so unless you have any
> > objections could we get this into -next?
> 
> I dropped this patch series from my queue due to sashiko's replies. I
> just notice these were not sent to the linux-pwm list, otherwise I would
> have mentioned it. :-(

Sashiko replies are not sent to linux-tegra either, so I tend to miss
them. E-mail is hard :(

> 
> So check on either
> 
> 	https://lore.kernel.org/all/[email protected]/
> 
> or
> 
> 	https://sashiko.dev/#/patchset/20260529-t264-pwm-v5-0-7bf9e405a96a%40nvidia.com
> 
> .
> 
> I only invested a quick glance, but the feedback seems relevant. If you
> don't agree, please point out why it's wrong/irrelevant.
> 
> Best regards
> Uwe

Sashiko:
> Does setting the target frequency to ULONG_MAX work safely with OPP
> tables?

This is not a concern. The OPP tables are designed with top OPP at the
maximum clock frequency. Indeed, before this patch, the hardcoded max
frequency in the driver matches what ULONG_MAX gets rounded to so
there is no change in functionality.

Sashiko:
> Is it possible for pc->clk_rate to be less than 256 here?

I.e. is it possible for clk_get_rate to return 0 after we have
successfully requested a rate of ULONG_MAX. I suppose that's technically
possible -- maybe if the clock is virtualized and read-only and left
disabled by boot? I can add a sanity check for clk_rate == 0, though
we'll just have to fail the probe in that case, but at least it avoids a
division by zero.

Sashiko:
> Could this cause a regression where the PWM output is left in a
> broken state if the hardware resets the DEPTH field to 0?

The hardware reset value for the field is 256, so that is not the case.

The other item is a pre-existing issue. Worth fixing, but not
necessarily in the purview of this feature.

I can respin to add the clk_rate == 0 check.

Cheers
Mikko