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 13:52:33 +0100 Message-ID: <20131104125232.GA3265@ulmo.nvidia.com> References: <1381951616-12548-1-git-send-email-seanpaul@chromium.org> <2834877.XsF26J0SyF@flatron> <34583649.XFd5ZiQISl@flatron> <20131104101026.GI27445@ulmo.nvidia.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0119645359==" Return-path: Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by gabe.freedesktop.org (Postfix) with ESMTP id 8D5A3131A3C for ; Mon, 4 Nov 2013 04:52:38 -0800 (PST) Received: by mail-bk0-f52.google.com with SMTP id u14so1932776bkz.25 for ; Mon, 04 Nov 2013 04:52:37 -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: Rob Clark Cc: =?utf-8?B?U3TDqXBoYW5l?= Marchesin , Sylwester Nawrocki , dri-devel , Laurent Pinchart List-Id: dri-devel@lists.freedesktop.org --===============0119645359== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 04, 2013 at 07:14:27AM -0500, Rob Clark wrote: > On Mon, Nov 4, 2013 at 5:10 AM, Thierry Reding = 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 w= rote: > > [...] > >> > 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. >=20 > 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 --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSd5iQAAoJEN0jrNd/PrOhQloP/2MaZgF5MYH/NhLeV04TfqTI AoalQhQU1x5dEw1h5r0X9SUjDVd8Ruen5+35zz368ueUSPmL1tJYZFysA+/UbADE 6rGnxLujMxuFjhyWZiAdHLCzCsYfCPiTfx1gy57YQu/uFddyZQgjSt6wFd+1elVE PIwbcRbjC8Qi3QmIOCOSXzpquYFOs3Qz3iKoqM8weo5Qr2f3taxFmv25eOmuL2o5 pdholJjh9ww227myFCcnZUrIP/szTZSpyu3FqoSWS2IasVxa5oxSt9J5eCoBQ1I4 JwPd3uf5DipDbm1VamhULLiiQ+0KZo0nOUkjNFELpX+GrQXjLdA/1yAWrLf6dbgM EGpBaAHWW5OlNkO4DOjP+9AAuVL4vtyFwPjDwCjJv1zgKyMUE6rZ8OLWMZOCMALI P24+FVpvUvFJF+/udUhrgbQ7l78VNQUGmrdfpBOkNQGTKhDoUNe3TDVFiI4LweOk IX+k74SRqbhH9TF6xdKJLGwt6o4YcugwI4UH4850t2ra7dO9sz0msnzyRS+1hvIu y5L8ZZfeWhRpNgoFRRcUaYBr9m9IonYtTVjUMKswnWUOwIjY+XoKFEWsNoz9pa98 Dm5fbIIQn12wiHE+umYIGtwIYwWN5R1q/Es53+ZXLAUImV7QhMCk7xFU8LD8vmEg AkaJIT3iFVGU+2fctJmT =OVkF -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l-- --===============0119645359== 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 --===============0119645359==--