Re: [PATCH v1 6/6] pwm: tegra: Implement .get_state()

"Ola Chr. Vaage" <[email protected]> Wed, 15 Jul 2026 14:28:48 +0200
Newsgroups org.kernel.vger.linux-pwm,org.kernel.vger.linux-tegra
Message-ID <[email protected]>
Hello Uwe,

On Tue, Jul 14, 2026 at 02:02:40PM +0200, Uwe Kleine-König wrote:
> Subject: [PATCH v1 6/6] pwm: tegra: Implement .get_state()

I tested this on a Jetson Orin NX (Tegra234), the board from my
divider truncation report, driving a fan on the 32a0000 PWM instance.

The board runs NVIDIA's L4T 5.15 kernel, so I backported the patch
onto that tree: .get_state() returns void there, pwmchip_parent(chip)
becomes the driver's device pointer, and the per-SoC enable_reg /
scale_width indirection collapses to the fixed CSR layout (that tree
predates the Tegra264 restructure). The decode logic is unchanged from
your patch. The tree also carries my divider change from the other
thread, which is why the achieved periods in the table differ from
what your base would program.

Procedure: apply a state through the pwm sysfs interface, read the CSR
register and the clock rate independently (/dev/mem and clk_summary),
then unexport/re-export the channel so pwm_device_request() invokes
.get_state(), and compare the reported state against values computed
from the raw register:

  applied period/duty/enabled  readback         computed from CSR+clk
  45334/20000/1                46432/20496/1    46432/20496/1
  500000/250000/1              481883/240942/1  481883/240942/1
  5000/2500/1                  5020/2510/1      5020/2510/1
  45334/45334/1 (100% duty)    46432/46432/1    46432/46432/1
  45334/20000/0                enabled=0        enabled=0

The clock rate varied across the cases (3.19, 11.03 and 102 MHz), so
the scale field was exercised at several values, and the 100% duty
case reads the full 9-bit duty field (pwm0 = 256). The readback
consistently reports the achieved hardware state rather than the
requested one.

One limitation of my backport, not your code: in the disabled case I
only set state->enabled = false instead of zeroing the whole struct,
so I did not verify the period/duty values your version reports for a
disabled channel.

Tested-by: Ola Chr. Vaage <[email protected]>

Best regards
Ola