From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH v3 12/32] drm/exynos: Split manager/display/subdrv Date: Fri, 29 Nov 2013 11:16:16 +0100 Message-ID: <20131129101615.GE22771@ulmo.nvidia.com> References: <1383063198-10526-1-git-send-email-seanpaul@chromium.org> <4061745.g28d5eBJHS@flatron> <1782082.tZWATq3Lue@flatron> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2088755081==" 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 C5C85FAE67 for ; Fri, 29 Nov 2013 02:17:04 -0800 (PST) Received: by mail-bk0-f52.google.com with SMTP id u14so4184745bkz.39 for ; Fri, 29 Nov 2013 02:17:03 -0800 (PST) In-Reply-To: <1782082.tZWATq3Lue@flatron> 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: Tomasz Figa Cc: =?utf-8?B?U3TDqXBoYW5l?= Marchesin , Laurent Pinchart , dri-devel List-Id: dri-devel@lists.freedesktop.org --===============2088755081== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WBsA/oQW3eTA3LlM" Content-Disposition: inline --WBsA/oQW3eTA3LlM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 29, 2013 at 12:04:04AM +0100, Tomasz Figa wrote: > On Tuesday 26 of November 2013 10:00:13 Olof Johansson wrote: > > On Tue, Nov 12, 2013 at 10:35 AM, Tomasz Figa w= rote: [...] > > > Sorry, this might have been a bit too harsh, but just imagine myself = doing > > > my regular patch review round, hoping (as usual) to see only code tha= t is > > > not less than great, while suddenly stumbling upon a line of code that > > > I would expect at most in some vendor tree or maybe several years ago= in > > > sources of a 2.4 kernel. > >=20 > > More like code written in the same style as x86 DRM stuff, where > > they're not used to overabstracting things from day one to make things > > generic instead of supporting the only known chip combination to date. >=20 > No, not really. They don't have any modularity on x86. Just a graphics > card with everything on it, so they can freely do such things, as they > don't have to account for all we need to account for on ARM platforms. I don't think there's such a clear difference. A particular GPU on x86 is equally modular as a specific GPU on an ARM SoC. The problem is that on x86 there's much less mix-and-matching going on. So theoretically they do need to account for the same craziness. That's not done, however, because there's no need for it. It doesn't happen in practice. > Also, I wouldn't call making a driver usable and useful for more than > just one fixed platform "overabstracting"... It is if there's never more than the single fixed platform. Since none of us can predict the future I think it's entirely reasonable if we do concentrate on solving the problems that we have now. It doesn't mean that we should write code in a way that makes future enhancements unnecessarily difficult, but I very much prefer to see code merged that supports one specific use-case that we have now rather than working on the code for years on end in an attempt to make it generic enough to support everything that the future can possibly hold. Chances are pretty good that we won't be able to predict one specific use-case and then rewrite everything anyway. Linux has been pretty successful so far in a large part because it has evolved organically. We're not doing ourselves any good by requiring everything to be perfect =66rom the beginning. We all know what a disaster DT has been and still is. It makes it very difficult to get new features supported because we now have a component that we can no longer change at will and that cannot evolve organically anymore. That impedes progress. For this particular issue no DT is involved. There's no need for ABI stability because it's just in-tree code and we can change it to our heart's content. We can refactor things when an actual need arises. By then chances are pretty good we'll have a much better understanding of what exactly we need and therefore we can come up with a much better solution than at this point in time. Thierry --WBsA/oQW3eTA3LlM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSmGlvAAoJEN0jrNd/PrOhzp4QAI7rBTPEWc/ENiSu5KlbX5eD 0w1yd+WSoqg5OfOhQkmAZglv0tSW0J+WuRNj3DAxQ+WfMhPJLZvtBsOHLkIdLhmA LVdLE2vb+pnmFZqTS+WzeY0Gfy5ci99JrwS8NPyqTGMODjS2XAAhA1Y+KBkYaskQ 5tXwOKRP13vOGZN4NDRIr+EyyFfLlNvfmNrYIG8vh59gutKm0f8cz+49nRJ3oj0I t/mF8dOMX8FjlUinFheWzEOaRsmkRVLvgS84V6VwfRL8dDLxdDCVUzCGMGUJuYUj MlBKQiVlM75N15FIgUREysJtFLhyiOu7eRHbaEmH3szhBsf8zo1BY6bW99GRL65X 94wMR3GpM/lmzrRr6j+odwFu1hyDaIcXTmMzHbXst/6dJ653fEK7pwDNVWyhQRur qQXpGQiT210M7fa5YJiyXK8dXkBZU5+efe4XxPpCL4LjZ6PP8RY+xTnK6csXVPEO UEF0YtBukqZQY9exFfBsZLWfVeYfF5FKJpBK75HlNCXo3n2rdzNmaVKHB9nGwJMz H4+ka7NhzrViXPx+Knw0aajS82GVNFdyPuBlL6P/sOR3rAUwE3m3BpxFSw7ByH58 Jl32S05vt0iIlzUVm9DBujiTwKC/cYkNzi000p7/IV/sGNkyLTtdUm4QRlfkWz0l gvpoNja39v9mmNLNoggY =Bhk/ -----END PGP SIGNATURE----- --WBsA/oQW3eTA3LlM-- --===============2088755081== 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 --===============2088755081==--