From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: backlight - chicken and egg challenge
Date: Mon, 10 Sep 2018 09:27:24 +0200 [thread overview]
Message-ID: <20180910092724.4caa91de@bbrezillon> (raw)
In-Reply-To: <20180908201755.GA15354@ravnborg.org>
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
next prev parent reply other threads:[~2018-09-10 7:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2018-09-11 12:48 ` Liviu Dudau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180910092724.4caa91de@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=sam@ravnborg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.