Re: [PATCH v2 3/3] pwm: tegra: Implement .get_state()

[Mikko Perttunen]

On Friday, October 2, 2026 5:51 PM Uwe Kleine-König wrote:
> Hello Thierry,
> 
> On Wed, Sep 30, 2026 at 12:29:42PM +0200, Thierry Reding wrote:
> > On Wed, Sep 30, 2026 at 11:54:03AM +0200, Uwe Kleine-König wrote:
> > > On Tue, Sep 22, 2026 at 12:07:26PM +0200, Thierry Reding wrote:
> > > > On Mon, Sep 21, 2026 at 04:26:03PM +0200, Uwe Kleine-König wrote:
> > > > > As long as .apply() also hardcodes TEGRA_PWM_DEPTH, it's IMO fine that
> > > > > .get_state() does so, too.
> > > > 
> > > > Okay, fair enough.
> > > 
> > > Is that an Ack then?
> > 
> > I've been thinking about this some more and I don't know if it really
> > makes sense to keep hard-coding TEGRA_PWM_DEPTH.
> 
> Full ack, ideally this implementation gap would be closed. Compared to
> implementing .get_state() I don't feel confident to do that without
> testing though. (Though I could make the driver return an error code if
> the register setting doesn't match.)
> 
> > If only .apply() uses it, then it's mostly fine, I suppose, because we
> > don't care what the current (or initial) state is/was. So we either
> > don't use the device or we overwrite it with a custom set of values.
> 
> I don't agree here. If the TEGRA_PWM_DEPTH setting is different in
> hardware than the driver assumes, I'd say .apply() being wrong is worse
> than .get_state() being wrong. So I'd either go with .get_state() as it
> is now, or rely on someone with hardware to correct the depth setting
> first.
> 
> Best regards
> Uwe

My state of mind when posting the Tegra264 support series was that the 
driver -- for the time being -- intentionally relies on the DEPTH 
register being at reset value. As such I think it's fine to rely on that 
everywhere for now. Once we add support for setting the register at 
runtime, I think it makes sense to update all code paths at that time.

(Of course, I had intended to follow up with those patches sooner, but 
..)

Mikko