[PATCH 1/2] dt-bindings: drm/bridge: ti-sn65dsi86: Replace #pwm-cells

[Bjorn Andersson]

On Fri 02 Oct 15:42 CDT 2020, Doug Anderson wrote:

> Hi,
> 
> On Wed, Sep 30, 2020 at 3:40 PM Bjorn Andersson
> <bjorn.andersson at linaro.org> wrote:
> >
> > While the signal on GPIO4 to drive the backlight controller indeed is
> > pulse width modulated its purpose is specifically to control the
> > brightness of a backlight.
> 
> I'm a bit on the fence about this.  I guess you're doing this because
> it avoids some -EPROBE_DEFER cycles in Linux?  It does seem to have a
> few downsides, though.
> 

No, the reason for exposing a backlight is that while the thing
certainly is a PWM signal, the description of it and the registers
available to control it surely seems "backlight" to me.

In particular No, the reason for exposing a backlight is that while
while the thing certainly is a PWM signal, the description of it and the
registers available to control it surely seems "backlight" to me.

> 1. It means a bit of re-inventing the wheel.  It's not a very big
> wheel, though, I'll give you.  ...but it's still something.
> 

The main problem I saw with exposing this as a PWM was the fact that we
have both period and frequency to control...

> 2. I'm not sure why you'd want to, but in theory one could use this
> PWM for some other purposes.  It really is just a generic PWM.  Your
> change prevents that.
> 

...and in the even that you use it as a "generic" PWM I'd expect that
the specified period is related to the frequency of the signal. But the
period is documented to be related to the number of brightness steps of
the panel.

> 
> 
> > Drop the #pwm-cells and instead expose a new property to configure the
> > granularity of the backlight PWM signal.
> >
> > Signed-off-by: Bjorn Andersson <bjorn.andersson at linaro.org>
> > ---
> >  .../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml | 9 ++++++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
> > index f8622bd0f61e..e380218b4646 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
> > @@ -66,9 +66,12 @@ properties:
> >        1-based to match the datasheet.  See ../../gpio/gpio.txt for more
> >        information.
> >
> > -  '#pwm-cells':
> > -    const: 1
> > -    description: See ../../pwm/pwm.yaml for description of the cell formats.
> > +  ti,backlight-scale:
> > +    description:
> > +      The granularity of brightness for the PWM signal provided on GPIO4, if
> > +      this property is specified.
> > +    minimum: 0
> > +    maximum: 65535
> 
> A few issues here:
> 
> 1. Maybe call this "num-steps" instead of backlight-scale.  That's
> essentially what it is, right?  Saying how many discrete steps you're
> allowing in your backlight?
> 

That would work, I had it as "max-brightness" for a while as well. But I
reverted to backlight-scale, because that's the name used in the
datasheet.

I'm fine with whatever color of the shed though :)

> 2. IMO you need the PWM frequency specified, since it can actually
> matter.  NOTE: once you have the PWM frequency specified, you could
> imagine automatically figuring out what "num-steps" was.  Really you'd
> want it to be the largest possible value you could achieve with your
> hardware at the specified frequency.  There's no advantage (is there?)
> of providing fewer steps to the backlight client.
> 

I guess there's no problem in having a "num-steps" that is unrelated to
the number of brightness steps of the panel - but I did distinguish them
because the datasheet clearly does so.

> 3. Some backlights are specified inverted.  It looks like this maps
> nicely to the bridge chip, which has a bit for it.  Probably nice to
> expose this?
> 

Yes, that should be covered.

> Of course, if we were just exposing the PWM directly to Linux we could
> just use the PWM backlight driver and it'd all magically work.  ;-)
> 

Please help me figure out how to properly expose this in the PWM api and
I'll be happy to respin it using this - as you say my wheel does look
pretty similar...

Regards,
Bjorn