From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH v2 12/26] drm/exynos: Split manager/display/subdrv Date: Mon, 4 Nov 2013 11:25:44 +0100 Message-ID: <20131104102543.GK27445@ulmo.nvidia.com> References: <1381951616-12548-1-git-send-email-seanpaul@chromium.org> <2834877.XsF26J0SyF@flatron> <34583649.XFd5ZiQISl@flatron> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1519422606==" Return-path: Received: from mail-bk0-f51.google.com (mail-bk0-f51.google.com [209.85.214.51]) by gabe.freedesktop.org (Postfix) with ESMTP id 7625AEED38 for ; Mon, 4 Nov 2013 02:25:47 -0800 (PST) Received: by mail-bk0-f51.google.com with SMTP id my12so929427bkb.24 for ; Mon, 04 Nov 2013 02:25:46 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: =?utf-8?B?U3TDqXBoYW5l?= Marchesin Cc: =?utf-8?B?U3TDqXBoYW5l?= Marchesin , Sylwester Nawrocki , dri-devel , Laurent Pinchart List-Id: dri-devel@lists.freedesktop.org --===============1519422606== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kswDJesP0akhmDn8" Content-Disposition: inline --kswDJesP0akhmDn8 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 29, 2013 at 08:46:03PM -0700, St=C3=A9phane Marchesin wrote: > On Tue, Oct 29, 2013 at 1:50 PM, Tomasz Figa wrot= e: >=20 > > Hi Sean, > > > > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote: > > > On Mon, Oct 28, 2013 at 7:13 PM, Tomasz Figa > > wrote: > > > > Hi, > > > > > > > > On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote: > > > >> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie > > wrote: > > > >> >>>>> I think we need to start considering a framework where > > > >> >>>>> subdrivers > > > >> >>>>> just > > > >> >>>>> add drm objects themselves, then the toplevel node is > > > >> >>>>> responsible > > > >> >>>>> for > > > >> >>>>> knowing that everything for the current configuration is > > > >> >>>>> loaded. > > > >> >>>> > > > >> >>>> It would be nice to specify the various pieces in dt, then ha= ve > > > >> >>>> some > > > >> >>>> type of drm notifier to the toplevel node when everything has > > > >> >>>> been > > > >> >>>> probed. Doing it in the dt would allow standalone > > > >> >>>> drm_bridge/drm_panel > > > >> >>>> drivers to be transparent as far as the device's drm driver is > > > >> >>>> concerned. > > > >> >>>> > > > >> >>>> Sean > > > >> >>>> > > > >> >>>>> I realise we may need to make changes to the core drm to all= ow > > > >> >>>>> this > > > >> >>>>> but we should probably start to create a strategy for fixing > > > >> >>>>> the > > > >> >>>>> API > > > >> >>>>> issues that this throws up. > > > >> >>>>> > > > >> >>>>> Note I'm not yet advocating for dynamic addition of nodes on= ce > > > >> >>>>> the > > > >> >>>>> device is in use, or removing them. > > > >> >>> > > > >> >>> I do wonder if we had some sort of tag in the device tree for = any > > > >> >>> nodes > > > >> >>> involved in the display, and the core drm layer would read that > > > >> >>> list, > > > >> >>> and when every driver registers tick things off, and when the > > > >> >>> last > > > >> >>> one > > > >> >>> joins we get a callback and init the drm layer, we'd of course > > > >> >>> have > > > >> >>> the > > > >> >>> basic drm layer setup prior to that so we can add the objects = as > > > >> >>> the > > > >> >>> drivers load. It might make development a bit trickier as you'd > > > >> >>> need > > > >> >>> to make sure someone claimed ownership of all the bits for init > > > >> >>> to > > > >> >>> proceed.>> > > > >> >> > > > >> >> Yeah, that's basically what the strawman looked like in my head. > > > >> >> > > > >> >> Instead of a property in each node, I was thinking of having a > > > >> >> separate gfx pipe nodes that would have dt pointers to the vari= ous > > > >> >> pieces involved in that pipe. This would allow us to associate > > > >> >> standalone entities like bridges and panels with encoders in dt > > > >> >> w/o > > > >> >> doing it in the drm code. I *think* this should be Ok with the = dt > > > >> >> guys > > > >> >> since it is still describing the hardware, but I think we'd have > > > >> >> to > > > >> >> make sure it wasn't drm-specific. > > > >> > > > > >> > I suppose the question is how much dynamic pipeline construction > > > >> > there > > > >> > is, > > > >> > > > > >> > even on things like radeon and i915 we have dynamic clock genera= tor > > > >> > to > > > >> > crtc to encoder setups, so I worry about static lists per-pipe, = so > > > >> > I > > > >> > still think just stating all these devices are needed for display > > > >> > and > > > >> > a list of valid interconnections between them, then we can have = the > > > >> > generic code model drm crtc/encoders/connectors on that list, and > > > >> > construct the possible_crtcs /possible_clones etc at that stage. > > > >> > > > >> I'm, without excuse, hopeless at devicetree, so there are probably > > > >> some violations, but something like: > > > >> > > > >> display-pipelines { > > > >> > > > >> required-elements =3D <&bridge-a &panel-a &encoder-x &encoder-y > > > >> > > > >> &crtc-x &crtc-y>; > > > >> > > > >> pipe1 { > > > >> > > > >> bridge =3D <&bridge-a>; > > > >> encoder =3D <&encoder-x>; > > > >> crtc =3D <&crtc-y>; > > > >> > > > >> }; > > > >> pipe2 { > > > >> > > > >> encoder =3D <&encoder-x>; > > > >> crtc =3D <&crtc-x>; > > > >> > > > >> }; > > > >> pipe3 { > > > >> > > > >> panel =3D <&panel-a>; > > > >> encoder =3D <&encoder-y>; > > > >> crtc =3D <&crtc-y>; > > > >> > > > >> }; > > > >> > > > >> }; > > > >> > > > >> I'm tempted to add connector to the pipe nodes as well, so it's > > > >> obvious which connector should be used in cases where multiple > > > >> entities in the pipe implement drm_connector. However, I'm not sure > > > >> if > > > >> that would be NACKed by dt people. > > > >> > > > >> I'm also not sure if there are too many combinations for i915 and > > > >> radeon to make this unreasonable. I suppose those devices could ju= st > > > >> use required-elements and leave the pipe nodes out. > > > > > > > > Just to put my two cents in, as one of the people involved into "the > > > > device tree movement", I'd say that instead of creating artifical > > > > entities, such as display-pipelines and all of the pipeX'es, device > > > > tree should represent relations between nodes. > > > > > > > > According to the generic DT bindings we already have for > > > > video-interfaces > > > > [1] your example connection layout would look as follows: > > > Hi Tomasz > > > Thanks for sending this along. > > > > > > I think the general consensus is that each drm driver should be > > > implemented as a singular driver. That is, N:1 binding to driver > > > mapping, where there are N IP blocks. Optional devices (such as > > > bridges, panels) probably make sense to spin off as standalone > > > drivers. > > > > I believe this is a huge step backwards from current kernel design > > standards, which prefer modularity. > > > > Having multiple IPs being part of the DRM subsystem in a SoC, it would = be > > nice to have the possibility to compile just a subset of support for th= em > > into the kernel and load rest of them as modules. (e.g. basic LCD > > controller on a mobile phone compiled in and external connectors, like > > HDMI as modules) > > > > Not even saying that from development perspective, a huge single driver > > would be much more difficult to test and debug, than several smaller > > drivers, which could be developed separately. > > >=20 > This is the opposite of our experience, though. A series of small drivers > like what's in drm/exynos can become really tedious/difficult to > coordinate. If you have separate drivers, everything needs to be > synchronized, but also has to account for potentially different loading > order. >=20 > It seems you're only thinking about the basic case, where you only support > a single resolution, no dpms, no suspend to ram... But when you want full > fledged functionality, then the issues I described become much more > prevalent. I fail to see how this is relevant here. It's fairly clear that even if a DRM driver is composed of more than a single platform driver, there's still a single point of coordination (the DRM driver). How does that have any impact on what features the driver can support? All of the features will be exposed via DRM, whether you use multiple drivers or a single monolithic one underneath is completely irrelevant. Thierry --kswDJesP0akhmDn8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSd3YnAAoJEN0jrNd/PrOhmE0P/1rTxphzxBQTWhzt77OhiG/G ISAa2S/3OhmXqNGhA5+zVoD/krUPtSS9khfnZuMbQ+O5LNZAOv/BSEbqQ6WPn2L4 FemyZHgu8IF0YJ6VuHUCtrXhmu04fdpkN+Uo5DXQaE9pgkRTDSsBVvuZwy3E/gBc Vdj1kCOQc4ELrxH7l1HT1GLeEPaioHO6I70kLmLuLSwq3DIGHLQJq4x1fgyQIHuA tpuhyVGltYdWhUyffi1eCg0uuZnx0INNiBlQ+Q263M4ArrWje7GqIIdxj8dhPn9d 8vr5pronZv4d0geXOmuhUu274AWOt8cbJ/reJPiSinFHjmKJfTfV3xpzx/7IgO3K kQeEnLn8JXMi1cVhYhtW456aKUoJwa4EIFOtSqWtDYWgGsNhdw4dpgEiUxmtgvSB cb+A3q5T/6s6Y2uo7ogK+7y1IC2wD4QGWofEimRTXDt6QMC6BwnGGhZ3fKcOBKk6 h++uRrWnlApkXYQXd4j0dRI00rz2lU3iDVNkzhUQ4NqEC3YGG3mqJkslVyw6+L+o JDyuhxZGF6xWF0bNTpH12my/GQa6NohEsZPvyYbJyFG8f6Dkx6CqNm8QDKFrUusP mRZdnAJgA67WxG9nw7l83RqBPfIUInDQfxCwYWeuB51OFkbLhvSufKarHAXP1ckW er9LtJG73Qf1z2g7FHhW =oqCj -----END PGP SIGNATURE----- --kswDJesP0akhmDn8-- --===============1519422606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1519422606==--