backlight - chicken and egg challenge
daniel at ffwll.ch
Sat Sep 8 21:23:13 UTC 2018
On Sat, Sep 8, 2018 at 10:17 PM, Sam Ravnborg <sam at 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.
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the dri-devel