Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 6 Apr 2023 16:30:23 +0200
From:   Thierry Reding <thierry.reding@gmail.com>
To:     Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= <u.kleine-koenig@pengutronix.de>
Cc:     Lorenz Brun <lorenz@brun.one>,
        Matthias Brugger <matthias.bgg@gmail.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@collabora.com>,
        linux-pwm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        linux-mediatek@lists.infradead.org
Subject: Re: [PATCH v2] pwm: mediatek: support inverted polarity
Message-ID: <ZC7Xf8Wy1x9gnaAY@orome>
References: <20230309010410.2106525-1-lorenz@brun.one>
 <ZC7LaC19YjNwTIi1@orome>
 <20230406135358.x3et6gvvxqsknfn6@pengutronix.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="vTrnEci5s8VqfSaD"
Content-Disposition: inline
In-Reply-To: <20230406135358.x3et6gvvxqsknfn6@pengutronix.de>
User-Agent: Mutt/2.2.10 (2023-03-25)
Precedence: bulk


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

On Thu, Apr 06, 2023 at 03:53:58PM +0200, Uwe Kleine-K=C3=B6nig wrote:
> Hello Thierry,
>=20
> On Thu, Apr 06, 2023 at 03:38:48PM +0200, Thierry Reding wrote:
> > On Thu, Mar 09, 2023 at 02:04:10AM +0100, Lorenz Brun wrote:
> > > +	 * appear to have the capability to invert the output.
> > > +	 * This means that inverted mode can not be fully supported as the
> > > +	 * waveform will always start with the low period and end with the =
high
> > > +	 * period. Thus reject non-normal polarity if the shape of the wave=
form
> > > +	 * matters, i.e. usage_power is not set.
> > > +	 */
> > > +	if (state->polarity !=3D PWM_POLARITY_NORMAL && !state->usage_power)
> > >  		return -EINVAL;
> > > =20
> > >  	if (!state->enabled) {
> > > @@ -213,7 +221,11 @@ static int pwm_mediatek_apply(struct pwm_chip *c=
hip, struct pwm_device *pwm,
> > >  		return 0;
> > >  	}
> > > =20
> > > -	err =3D pwm_mediatek_config(pwm->chip, pwm, state->duty_cycle, stat=
e->period);
> > > +	duty_cycle =3D state->duty_cycle;
> > > +	if (state->polarity =3D=3D PWM_POLARITY_INVERSED)
> > > +		duty_cycle =3D state->period - state->duty_cycle;
> >=20
> > That's not really what state->usage_power was meant to address.
>=20
> I don't understand your concern here. I don't like .usage_power, but
> AFAICT this is a legitimite use. With .usage_power =3D true, the lowlevel
> driver is free to shift the phase_offset and even modify the period size
> and the goal is just that the average power-output matches.
>=20
> Lorenz's patch does exactly this: It even keeps the period and only
> shifts the phase (by period - duty_cycle). If you consider this not
> legitmate, I think we have to improve the docs about .usage_power.

I realize that I'm being nitpicky here. Setting usage_power =3D true and
duty =3D period - duty is a lazy way of achieving what you can easily do
by adjusting the input duty cycle.

If you all really want this, then it should go into the core, because
it's something that can be implemented on basically every single PWM
controller.

Thierry

--vTrnEci5s8VqfSaD
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmQu134ACgkQ3SOs138+
s6HdEg//QB1RbC+b2D1fyJp2a/878DZw0Noui4uzQ9hqOvjkcUvly2m9Nt/YPMG3
LK8yJ8Zmxkytm6YqFHgYwaYZk7vnRL6Cvoo5gVdxlAvsgG+Go/UAEgvMpq5dgnP+
FO8mZa4P7LKgJe/5sGuZanDrwVt7Xh6Y12RsmiBYcaMkC4fkpyKutR0VRy31KIE4
qNJP0DozI7wHDyJcdV+AW+2saARDEt+5IRFn/fKjpxx5hp2pIg04OUcelAJEgF6E
pg16Vs9BAqUYfN+LnqdGqph3+tJR6pvcXLG+uU6o/FgQLTqf3ic1oQca7stRfAH9
BbqhkkoTzlpOiLvp0S4bzxqOiaFioRnROBppZvNIl85j3NIOSm7NTAzUE3rh/Z9I
qkn06FT3+Y1R3/NsOKZoQfH0ygm97RdjtQhwWscm0VHIneh165fW8e++dcrBLYCY
NyYA01We7VONe4m05ycsWzXq3xckZj7T4225MOK/NA2AK2KTNhMUhSqA3T41IEto
iWBzS9J8azku8jAYj0My5RO7obpymkVX0+ymixsmFVvBW4V7Hd7fPR43eI805Rg9
OMuh92K+e1XBvgq8nUUuA8pJxmBBkG+Qpz9t1zta55X1hu9LBtSdocZcJtaBr746
ELWDyZxNNGBTfbmchrp5SIP1zphRDVY3o3wzoKVY4XQewLaDL5g=
=rBYM
-----END PGP SIGNATURE-----

--vTrnEci5s8VqfSaD--