backlight - chicken and egg challenge

backlight - chicken and egg challenge

[Sam Ravnborg]

Hi all.

When working on the DRM driver for Atmel LCDC the first approach
was to use a MFD driver, that had two sub-drivers:
- PWM dirver
- DRM driver

Feedback was that the PWM feature was too small to warrant a MFD driver.
(There was no consencus on this, but I anyway went ahead).

So the new approch is much simpler (from a code point of view):
DRM Driver that has one sub-driver
- PWM driver
  The PWM driver uses registers in the same memory
  range as the DRM driver, so the two drivers uses
  the same regmap.

  The PWM driver is located in pwm/
  The DRM driver is located in gpu/drm/atmel
    The DRM driver uses platform_device_register_data() to
    register the sub-device/driver.
    I have yet to see it work, but I think this is the right way
    to do it.

This all looked fine until reality kicked in.


There is the following dependency chain (=> depends on):
DRM Driver => Panel => Backlight => PWM => DRM Driver

The DRM Driver rely indirectly on the DRM driver, which it not OK.

So the open question is how to fix this dependency challenge?

1) Drop the generic backlight driver and implement all pwm/backlight
   handling in the driver.
2) Re-introduce the MFD driver.
3) ?

Any good ideas?

	Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: backlight - chicken and egg challenge

[Daniel Vetter]

On Sat, Sep 8, 2018 at 10:17 PM, Sam Ravnborg <sam@ravnborg.org> wrote:
> Hi all.
>
> When working on the DRM driver for Atmel LCDC the first approach
> was to use a MFD driver, that had two sub-drivers:
> - PWM dirver
> - DRM driver
>
> Feedback was that the PWM feature was too small to warrant a MFD driver.
> (There was no consencus on this, but I anyway went ahead).
>
> So the new approch is much simpler (from a code point of view):
> DRM Driver that has one sub-driver
> - PWM driver
>   The PWM driver uses registers in the same memory
>   range as the DRM driver, so the two drivers uses
>   the same regmap.
>
>   The PWM driver is located in pwm/
>   The DRM driver is located in gpu/drm/atmel
>     The DRM driver uses platform_device_register_data() to
>     register the sub-device/driver.
>     I have yet to see it work, but I think this is the right way
>     to do it.
>
> This all looked fine until reality kicked in.
>
>
> There is the following dependency chain (=> depends on):
> DRM Driver => Panel => Backlight => PWM => DRM Driver
>
> The DRM Driver rely indirectly on the DRM driver, which it not OK.
>
> So the open question is how to fix this dependency challenge?
>
> 1) Drop the generic backlight driver and implement all pwm/backlight
>    handling in the driver.
> 2) Re-introduce the MFD driver.
> 3) ?
>
> Any good ideas?

component.c should be able to cope. The driver that matches for the
physical/platform device register the pwm thing, plus a component (for
the drm driver, you can start with initializing the drm_device
already, except for the panel). The panel registers the other
component. the component master then does the final step of
registering the overall drm_device.

Should all work, only bit you might need is a bit of
drm_panel/component.c integration. Iirc there's been discussions about
that, but no idea where they are stuck.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: backlight - chicken and egg challenge

[Sam Ravnborg]

> >
> > So the open question is how to fix this dependency challenge?
> >
> > 1) Drop the generic backlight driver and implement all pwm/backlight
> >    handling in the driver.
> > 2) Re-introduce the MFD driver.
> > 3) ?
> >
> > Any good ideas?
> 
> component.c should be able to cope. The driver that matches for the
> physical/platform device register the pwm thing, plus a component (for
> the drm driver, you can start with initializing the drm_device
> already, except for the panel). The panel registers the other
> component. the component master then does the final step of
> registering the overall drm_device.
> 
> Should all work, only bit you might need is a bit of
> drm_panel/component.c integration. Iirc there's been discussions about
> that, but no idea where they are stuck.

Sound reasonable, I will try to look into this.
If anyone have pointers to the drm_panel/component.c integration
discussions I expect this would be a good help.

	Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: backlight - chicken and egg challenge

[Boris Brezillon]

Hi Sam,

On Sat, 8 Sep 2018 22:17:55 +0200
Sam Ravnborg <sam@ravnborg.org> wrote:

> Hi all.
> 
> When working on the DRM driver for Atmel LCDC the first approach
> was to use a MFD driver, that had two sub-drivers:
> - PWM dirver
> - DRM driver
> 
> Feedback was that the PWM feature was too small to warrant a MFD driver.
> (There was no consencus on this, but I anyway went ahead).
> 
> So the new approch is much simpler (from a code point of view):
> DRM Driver that has one sub-driver
> - PWM driver
>   The PWM driver uses registers in the same memory
>   range as the DRM driver, so the two drivers uses
>   the same regmap.
> 
>   The PWM driver is located in pwm/
>   The DRM driver is located in gpu/drm/atmel
>     The DRM driver uses platform_device_register_data() to
>     register the sub-device/driver.
>     I have yet to see it work, but I think this is the right way
>     to do it.
> 
> This all looked fine until reality kicked in.
> 
> 
> There is the following dependency chain (=> depends on):
> DRM Driver => Panel => Backlight => PWM => DRM Driver
> 
> The DRM Driver rely indirectly on the DRM driver, which it not OK.
> 
> So the open question is how to fix this dependency challenge?
> 
> 1) Drop the generic backlight driver and implement all pwm/backlight
>    handling in the driver.
> 2) Re-introduce the MFD driver.
> 3) ?
> 
> Any good ideas?

I keep thinking #2 is the cleanest option. The fact is, the LCDC IP is
actually providing 2 functionalities: a PWM (most of the time driving a
backlight) and a display controller. Really, I don't see why
representing this IP as an MFD is not appropriate, especially since the
HLCDC MFD driver is already in place and can easily be re-used.

What should be adjusted though, is the need for 2 sub-nodes: I think you
can just use a single node and declare #pwm-cells at the top level.

Regards,

Boris

Regards,

Boris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: backlight - chicken and egg challenge

[Liviu Dudau]

On Mon, Sep 10, 2018 at 09:27:24AM +0200, Boris Brezillon wrote:
> Hi Sam,
> 
> On Sat, 8 Sep 2018 22:17:55 +0200
> Sam Ravnborg <sam@ravnborg.org> wrote:
> 
> > Hi all.
> > 
> > When working on the DRM driver for Atmel LCDC the first approach
> > was to use a MFD driver, that had two sub-drivers:
> > - PWM dirver
> > - DRM driver
> > 
> > Feedback was that the PWM feature was too small to warrant a MFD driver.
> > (There was no consencus on this, but I anyway went ahead).
> > 
> > So the new approch is much simpler (from a code point of view):
> > DRM Driver that has one sub-driver
> > - PWM driver
> >   The PWM driver uses registers in the same memory
> >   range as the DRM driver, so the two drivers uses
> >   the same regmap.
> > 
> >   The PWM driver is located in pwm/
> >   The DRM driver is located in gpu/drm/atmel
> >     The DRM driver uses platform_device_register_data() to
> >     register the sub-device/driver.
> >     I have yet to see it work, but I think this is the right way
> >     to do it.
> > 
> > This all looked fine until reality kicked in.
> > 
> > 
> > There is the following dependency chain (=> depends on):
> > DRM Driver => Panel => Backlight => PWM => DRM Driver
> > 
> > The DRM Driver rely indirectly on the DRM driver, which it not OK.
> > 
> > So the open question is how to fix this dependency challenge?
> > 
> > 1) Drop the generic backlight driver and implement all pwm/backlight
> >    handling in the driver.
> > 2) Re-introduce the MFD driver.
> > 3) ?
> > 
> > Any good ideas?
> 
> I keep thinking #2 is the cleanest option. The fact is, the LCDC IP is
> actually providing 2 functionalities: a PWM (most of the time driving a
> backlight) and a display controller. Really, I don't see why
> representing this IP as an MFD is not appropriate, especially since the
> HLCDC MFD driver is already in place and can easily be re-used.

But can you enable the PWM functionality without the DRM mode? If yes, then
I do agree that a PWM driver should be re-introduced (MFD is a bit of a stretch,
to me that means "the driver there can do several things on its own", rather than
"this is the remaining functionality out of a different driver").

Best regards,
Liviu


> 
> What should be adjusted though, is the need for 2 sub-nodes: I think you
> can just use a single node and declare #pwm-cells at the top level.
> 
> Regards,
> 
> Boris
> 
> Regards,
> 
> Boris
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel