[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv
Thierry Reding
thierry.reding at gmail.com
Mon Nov 4 04:52:33 PST 2013
On Mon, Nov 04, 2013 at 07:14:27AM -0500, Rob Clark wrote:
> On Mon, Nov 4, 2013 at 5:10 AM, Thierry Reding <thierry.reding at gmail.com> wrote:
> > On Tue, Oct 29, 2013 at 05:29:55PM -0400, Rob Clark wrote:
> >> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa <tomasz.figa at gmail.com> wrote:
> > [...]
> >> > I believe this is a huge step backwards from current kernel design
> >> > standards, which prefer modularity.
> >>
> >> But it makes things behave in the way that userspace expects, which is
> >> more important.
> >
> > Why would userspace care about the modularity of kernel drivers? The
> > only thing that userspace should care about is whether there's a DRM
> > device or not. How the kernel makes that happen should be completely
> > irrelevant to userspace.
>
> What I was referring to was userspace not expecting parts of the drm
> (crtcs/encoders/connectors) driver to show up incrementally. You can
> avoid that, but it is more of a hassle currently (ie. most drivers
> that need to do this, including a few that I've written, end up
> needing some form of
> stuff-devices-in-global-variables-that-main-driver-checks-for).
I must have misunderstood then. I don't think adding hotplug of DRM
subdevices is something we would want. And I don't think there's a
requirement for that, either. Embedded devices usually have well-defined
use-cases, so the configuration is rather static at runtime.
As for the global variables, you can do it properly. Granted, it might
be more work than global variables, but keeping drivers separated does
have advantages. Especially when the devices have completely separated
register ranges or clocks or other resources, it's very natural to use
one driver per device and glue them together with a composite device
construct.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131104/c42c2f1c/attachment-0001.pgp>
More information about the dri-devel
mailing list