Linux Tegra architecture development
 help / color / mirror / Atom feed
From: "Ola Chr. Vaage" <o.c.vage@gmail.com>
To: "Uwe Kleine-König" <ukleinek@kernel.org>
Cc: Thierry Reding <thierry.reding@kernel.org>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Mikko Perttunen <mperttunen@nvidia.com>,
	linux-pwm@vger.kernel.org, linux-tegra@vger.kernel.org,
	"Ola Chr . Vaage" <o.c.vage@gmail.com>,
	"Ola Chr. Vaage" <ola.christoffer.vage@scoutdi.com>
Subject: Re: [PATCH v1 6/6] pwm: tegra: Implement .get_state()
Date: Wed, 15 Jul 2026 14:28:48 +0200	[thread overview]
Message-ID: <20260715122914.2815081-1-o.c.vage@gmail.com> (raw)
In-Reply-To: <33b13f17d7135923d08e2ff40c867803e19609b9.1784030076.git.ukleinek@kernel.org>

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 <ola.christoffer.vage@scoutdi.com>

Best regards
Ola

      parent reply	other threads:[~2026-07-15 12:29 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-14 12:02 [PATCH v1 0/6] pwm: tegra: Cleanups and .get_state() Uwe Kleine-König
2026-07-14 12:02 ` [PATCH v1 1/6] pwm: tegra: Check for match_data being NULL Uwe Kleine-König
2026-07-15  4:11   ` Mikko Perttunen
2026-07-15 14:20     ` Uwe Kleine-König
2026-07-14 12:02 ` [PATCH v1 2/6] pwm: tegra: Make use of dev_err_probe() Uwe Kleine-König
2026-07-15  4:17   ` Mikko Perttunen
2026-07-14 12:02 ` [PATCH v1 3/6] pwm: tegra: Use devm function for pm_runtime_enable() Uwe Kleine-König
2026-07-15  4:31   ` Mikko Perttunen
2026-07-14 12:02 ` [PATCH v1 4/6] pwm: tegra: Simplify using devm_reset_control_get_exclusive_deasserted() Uwe Kleine-König
2026-07-14 12:12   ` Philipp Zabel
2026-07-14 14:07     ` Uwe Kleine-König
2026-07-15  4:50       ` Mikko Perttunen
2026-07-14 12:02 ` [PATCH v1 5/6] pwm: tegra: Simplify using devm_pwmchip_add() Uwe Kleine-König
2026-07-14 12:02 ` [PATCH v1 6/6] pwm: tegra: Implement .get_state() Uwe Kleine-König
2026-07-15  5:09   ` Mikko Perttunen
2026-07-15 12:28   ` Ola Chr. Vaage [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=20260715122914.2815081-1-o.c.vage@gmail.com \
    --to=o.c.vage@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-pwm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mperttunen@nvidia.com \
    --cc=ola.christoffer.vage@scoutdi.com \
    --cc=thierry.reding@kernel.org \
    --cc=ukleinek@kernel.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