* backlight - chicken and egg challenge
@ 2018-09-08 20:17 Sam Ravnborg
2018-09-08 21:23 ` Daniel Vetter
2018-09-10 7:27 ` Boris Brezillon
0 siblings, 2 replies; 5+ messages in thread
From: Sam Ravnborg @ 2018-09-08 20:17 UTC (permalink / raw)
To: dri-devel; +Cc: Boris Brezillon
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: backlight - chicken and egg challenge 2018-09-08 20:17 backlight - chicken and egg challenge Sam Ravnborg @ 2018-09-08 21:23 ` Daniel Vetter 2018-09-08 22:38 ` Sam Ravnborg 2018-09-10 7:27 ` Boris Brezillon 1 sibling, 1 reply; 5+ messages in thread From: Daniel Vetter @ 2018-09-08 21:23 UTC (permalink / raw) To: Sam Ravnborg; +Cc: Boris Brezillon, dri-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: backlight - chicken and egg challenge 2018-09-08 21:23 ` Daniel Vetter @ 2018-09-08 22:38 ` Sam Ravnborg 0 siblings, 0 replies; 5+ messages in thread From: Sam Ravnborg @ 2018-09-08 22:38 UTC (permalink / raw) To: Daniel Vetter; +Cc: Boris Brezillon, dri-devel > > > > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: backlight - chicken and egg challenge 2018-09-08 20:17 backlight - chicken and egg challenge Sam Ravnborg 2018-09-08 21:23 ` Daniel Vetter @ 2018-09-10 7:27 ` Boris Brezillon 2018-09-11 12:48 ` Liviu Dudau 1 sibling, 1 reply; 5+ messages in thread From: Boris Brezillon @ 2018-09-10 7:27 UTC (permalink / raw) To: Sam Ravnborg; +Cc: dri-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: backlight - chicken and egg challenge 2018-09-10 7:27 ` Boris Brezillon @ 2018-09-11 12:48 ` Liviu Dudau 0 siblings, 0 replies; 5+ messages in thread From: Liviu Dudau @ 2018-09-11 12:48 UTC (permalink / raw) To: Boris Brezillon; +Cc: Sam Ravnborg, dri-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-09-11 12:56 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-09-08 20:17 backlight - chicken and egg challenge Sam Ravnborg 2018-09-08 21:23 ` Daniel Vetter 2018-09-08 22:38 ` Sam Ravnborg 2018-09-10 7:27 ` Boris Brezillon 2018-09-11 12:48 ` Liviu Dudau
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.