Re: [PATCH v5 1/2] pwm: Introduce single-PWM of_xlate function

From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Cc: Thierry Reding <thierry.reding@gmail.com>,
	Lee Jones <lee.jones@linaro.org>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Robert Foss <robert.foss@linaro.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	linux-pwm@vger.kernel.org, Doug Anderson <dianders@google.com>
Subject: Re: [PATCH v5 1/2] pwm: Introduce single-PWM of_xlate function
Date: Fri, 24 Sep 2021 07:30:19 -0700	[thread overview]
Message-ID: <YU3g+8Rwfyq3yp5S@ripper> (raw)
In-Reply-To: <20210924071652.skkx2jgeivg4uiht@pengutronix.de>

On Fri 24 Sep 00:16 PDT 2021, Uwe Kleine-K?nig wrote:

> On Thu, Sep 23, 2021 at 09:12:24PM -0500, Bjorn Andersson wrote:
> > The existing pxa driver and the upcoming addition of PWM support in the
> > TI sn565dsi86 DSI/eDP bridge driver both has a single PWM channel and
> > thereby a need for a of_xlate function with the period as its single
> > argument.
> > 
> > Introduce a common helper function in the core that can be used as
> > of_xlate by such drivers and migrate the pxa driver to use this.
> > 
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> > 
> > Changes since v4:
> > - None
> > 
> >  drivers/pwm/core.c    | 26 ++++++++++++++++++++++++++
> >  drivers/pwm/pwm-pxa.c | 16 +---------------
> >  include/linux/pwm.h   |  2 ++
> >  3 files changed, 29 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> > index 4527f09a5c50..2c6b155002a2 100644
> > --- a/drivers/pwm/core.c
> > +++ b/drivers/pwm/core.c
> > @@ -152,6 +152,32 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct of_phandle_args *args)
> >  }
> >  EXPORT_SYMBOL_GPL(of_pwm_xlate_with_flags);
> >  
> > +struct pwm_device *
> > +of_pwm_single_xlate(struct pwm_chip *pc, const struct of_phandle_args *args)
> > +{
> > +	struct pwm_device *pwm;
> > +
> > +	if (pc->of_pwm_n_cells < 1)
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	/* validate that one cell is specified, optionally with flags */
> > +	if (args->args_count != 1 && args->args_count != 2)
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	pwm = pwm_request_from_chip(pc, 0, NULL);
> > +	if (IS_ERR(pwm))
> > +		return pwm;
> > +
> > +	pwm->args.period = args->args[0];
> > +	pwm->args.polarity = PWM_POLARITY_NORMAL;
> > +
> > +	if (args->args_count == 2 && args->args[2] & PWM_POLARITY_INVERTED)
> > +		pwm->args.polarity = PWM_POLARITY_INVERSED;
> 
> of_pwm_xlate_with_flags is a bit more complicated. Translating
> accordingly this would yield:
> 
> 	if (pc->of_pwm_n_cells >= 2) {
> 		if (args->args_count > 1 && args->args[1] & PWM_POLARITY_INVERTED)
> 			pwm->args.polarity = PWM_POLARITY_INVERSED;
> 	}
> 
> Given that pc->of_pwm_n_cells isn't used when a phandle is parsed (in
> of_pwm_get()) I think your variant is fine.
> 

Right, the difference from of_pwm_xlate_with_flags is that this version
will pick up the flags even if the driver says it has n_cells = 1.

I didn't see a strong reason for doing the extra check and the drawback
with it is that if I then write in my dts that my channel should be
INVERTED the driver won't be able to bump the n_cells to 2, because that
would cause a regression.

Would you like me to add this extra check? Or perhaps ensure that the
commit message captures my reasoning here?

> So I think technically the patch is good, for me the question is if we
> want to make new drivers of_pwm_xlate_with_flags for consistency even
> though this would mean that the first argument has to be 0 for all
> phandles. Thierry? Lee?
> 

I find it typical for single entity providers to be defined with
#foo-cells = <0> (or 1 if you have flags) and not pass a "dummy" 0.

We did talk about this with Rob in a previous version of this patch and
came to the conclusion that this was the appropriate thing to do...

Thanks,
Bjorn