Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 22 Mar 2021 09:53:08 +0100
From:   Thierry Reding <thierry.reding@gmail.com>
To:     Clemens Gruber <clemens.gruber@pqgruber.com>
Cc:     Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= 
        <u.kleine-koenig@pengutronix.de>,
        Sven Van Asbroeck <thesven73@gmail.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-pwm@vger.kernel.org
Subject: Re: [PATCH v5 2/7] pwm: pca9685: Support hardware readout
Message-ID: <YFha9H+6ATFbb/VA@orome.fritz.box>
References: <20201216125320.5277-1-clemens.gruber@pqgruber.com>
 <20201216125320.5277-2-clemens.gruber@pqgruber.com>
 <CAGngYiWkKZGkQ4TTTy8bQYvnGBK45V0A0JCe_+M5V+vuVU+zkQ@mail.gmail.com>
 <X9uYqGboZg5DuEtf@workstation.tuxnet>
 <20210111203532.m3yvq6e5bcpjs7mc@pengutronix.de>
 <YAB8ZmtOxRV1QN4l@workstation.tuxnet>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="clyIA7PyjV+ubgbt"
Content-Disposition: inline
In-Reply-To: <YAB8ZmtOxRV1QN4l@workstation.tuxnet>
User-Agent: Mutt/2.0.6 (98f8cb83) (2021-03-06)
Precedence: bulk


--clyIA7PyjV+ubgbt
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 14, 2021 at 06:16:22PM +0100, Clemens Gruber wrote:
> Hi,
>=20
> On Mon, Jan 11, 2021 at 09:35:32PM +0100, Uwe Kleine-K=C3=B6nig wrote:
> > Hello,
> >=20
> > On Thu, Dec 17, 2020 at 06:43:04PM +0100, Clemens Gruber wrote:
> > > On Wed, Dec 16, 2020 at 11:00:59PM -0500, Sven Van Asbroeck wrote:
> > > > On Wed, Dec 16, 2020 at 7:53 AM Clemens Gruber
> > > > <clemens.gruber@pqgruber.com> wrote:
> > > > >
> > > > > Implements .get_state to read-out the current hardware state.
> > > > >
> > > >=20
> > > > I am not convinced that we actually need this.
> > > >=20
> > > > Looking at the pwm core, .get_state() is only called right after .r=
equest(),
> > > > to initialize the cached value of the state. The core then uses the=
 cached
> > > > value throughout, it'll never read out the h/w again, until the nex=
t .request().
> > > >=20
> > > > In our case, we know that the state right after request is always d=
isabled,
> > > > because:
> > > > - we disable all pwm channels on probe (in PATCH v5 4/7)
> > > > - .free() disables the pwm channel
> > > >=20
> > > > Conclusion: .get_state() will always return "pwm disabled", so why =
do we
> > > > bother reading out the h/w?
> > >=20
> > > If there are no plans for the PWM core to call .get_state more often =
in
> > > the future, we could just read out the period and return 0 duty and
> > > disabled.
> > >=20
> > > Thierry, Uwe, what's your take on this?
> >=20
> > I have some plans here. In the past I tried to implement them (see
> > commit 01ccf903edd65f6421612321648fa5a7f4b7cb10), but this failed
> > (commit 40a6b9a00930fd6b59aa2eb6135abc2efe5440c3).
> >=20
> > > > Of course, if we choose to leave the pwm enabled after .free(), then
> > > > .get_state() can even be left out! Do we want that? Genuine questio=
n, I do
> > > > not know the answer.
> > >=20
> > > I do not think we should leave it enabled after free. It is less
> > > complicated if we know that unrequested channels are not in use.
> >=20
> > My position here is: A consumer should disable a PWM before calling
> > pwm_put. The driver should however not enforce this and so should not
> > modify the hardware state in .free().
> >=20
> > Also .probe should not change the PWM configuration.
>=20
> I see. This would also allow PWMs initialized in the bootloader (e.g.
> backlights) to stay on between the bootloader and Linux and avoid
> flickering.

Yes, that's precisely one of the reasons why we introduced the atomic
API. One of the use-cases that led to the current design was that the
kernel pwm-regulator on some platforms was causing devices to crash
because the driver would reprogram the PWM and cause a glitch on the
power supply for the CPUs.

So it's crucial in some cases that the PWM driver don't touch the
hardware state in ->probe(). If some drivers currently do so, that's
something we should eventually change, but given that there haven't been
any complaints yet, it likely means nothing breaks because of this, so
we do have the luxury of not having to rush things.

> If no one objects, I would then no longer reset period and duty cycles
> in the driver (and for our projects, reset them in the bootloader code
> to avoid leaving PWMs on after a kernel panic and watchdog reset, etc.)

This isn't strictly necessary, but it's obviously something that's up to
board designers/maintainers to decide.

Thierry

--clyIA7PyjV+ubgbt
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmBYWvQACgkQ3SOs138+
s6FcJg//ZR0zAocR/x8CX247pgq0Sjcn5fZGy46F2tlxas6t34qvHPh8FYMALIvw
5W5EXkYsGpItoByvgtz/sKIZFaNSPnzHHdF9EQ4m/Y+4J6+stUBGTVBVNM3SvAl9
WnSEzFs0Xin8zXi6ocFRCAJnX4yto4Su5F87lBK8hpJaEZjmP3e2GHuohvV78uSm
0pcdaZBlmpnCSGI87YiQJeNTLAaR5RnZUEUinnda2Nxe0OXhek2olAEh5+BjfW6w
tLLJjuGbGOAJRsE6WMrAywncLnptVKu69dB3TQXDBQW1f+BESe0B/TGJcPD9el84
Nqd3I+IeEfsEcGGFJgG40UsqHAnOLo2uuKEDeEMzJxJh+8U6hkPok5RIrq+Z5h/e
4rkRRCCcXUa86wBOGzFXWnNnpxPzWOgSFT9klagyGaWnMZ+av+p8bWfecx4mPSQK
NxQH1x2sNd8Y1XdQMKt5nkU3+dix06gr44keheEUL+qHDe2rbgK0sk7Uo0aXsbgr
KflNTTma7J/Ux9+UQqzEGmVivYeXrPBU67Tq/Th2Bxcv168an+MT2S95+CdTD2f9
t36t+bKefy54LqPaFELYCkkAf1phPbWl67637WVls5WADNmf5Bg6N4Lt/rJzj/wd
TOfXw0pwPiBRo3/gOs9Jm5Ak6LfcCTtuZP9tMw7DgxugDAZdTWs=
=BSxS
-----END PGP SIGNATURE-----

--clyIA7PyjV+ubgbt--