From: Mark Brown <broonie@kernel.org>
To: Dave Airlie <airlied@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
ksummit-2013-discuss@lists.linuxfoundation.org,
Linux Fbdev development list <linux-fbdev@vger.kernel.org>
Subject: Re: outcome of DRM/KMS DT bindings session
Date: Fri, 01 Nov 2013 00:32:28 +0000 [thread overview]
Message-ID: <20131101003228.GM2493@sirena.org.uk> (raw)
In-Reply-To: <CAPM=9ty7+A=YjSbRLxmo9mXSQSkZsZngBvTsryZ8+tHppEMPyw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]
On Fri, Nov 01, 2013 at 10:10:41AM +1000, Dave Airlie wrote:
> > Still the different components can be multiple devices, just initialize
> > the drm device once all components are probed. Remove it again once a
> But why? why should we have separate drivers for each component of a
> tightly coupled SoC?
> it makes no sense, having a driver node per every block in the chip
> isn't an advantage, it complicates
> things for no advantage at all. If we don't have hotplug hw removing
> one device shouldn't be possible
> this idea that removing a sub-driver should teardown the drm is crazy as well.
One case where this may be required is for integration with SoC power
domains where the DRM components are split between multiple domains (and
it may be more idiomatic even if they aren't). If the SoC is using
power domains then it will expect to see at least one device within each
domain that gets used to reference count the activity for the domain.
This could just be a composite device per domain though.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-11-01 0:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-29 3:52 outcome of DRM/KMS DT bindings session Dave Airlie
2013-10-30 11:19 ` Thierry Reding
2013-10-30 12:02 ` Sascha Hauer
2013-10-30 18:26 ` Tomasz Figa
2013-11-01 0:10 ` Dave Airlie
2013-11-01 0:32 ` Mark Brown [this message]
2013-11-01 9:12 ` Thierry Reding
2013-11-01 15:28 ` Inki Dae
2014-02-28 12:44 ` Tomi Valkeinen
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=20131101003228.GM2493@sirena.org.uk \
--to=broonie@kernel.org \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ksummit-2013-discuss@lists.linuxfoundation.org \
--cc=linux-fbdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).