From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751904AbdBOMiy (ORCPT ); Wed, 15 Feb 2017 07:38:54 -0500 Received: from mail.free-electrons.com ([62.4.15.54]:41814 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751478AbdBOMix (ORCPT ); Wed, 15 Feb 2017 07:38:53 -0500 Date: Wed, 15 Feb 2017 13:38:44 +0100 From: Maxime Ripard To: Daniel Stone Cc: Laurent Pinchart , Linux Kernel Mailing List , dri-devel , Daniel Vetter , Stefan Christ Subject: Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev Message-ID: <20170215123844.o6ey7widifnq2hud@lukather> References: <9b4f80f213b50959d168e6f22b21ee784fe26da5.1486031436.git-series.maxime.ripard@free-electrons.com> <2662533.Ps9k37FiVM@avalon> <20170213105422.2cfr7av6ha2vzdlk@lukather> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yzslvkatelh2fa2i" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2-neo (2016-08-21) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --yzslvkatelh2fa2i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Feb 13, 2017 at 11:20:51AM +0000, Daniel Stone wrote: > Hi Maxime, >=20 > On 13 February 2017 at 10:54, Maxime Ripard > wrote: > > On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > >> On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > >> > This patch add a config to support to create multi buffer for cma fb= dev. > >> > Such as double buffer and triple buffer. > >> > > >> > Cma fbdev is convient to add a legency fbdev. And still many Android > >> > devices use fbdev now and at least double buffer is needed for these > >> > Android devices, so that a buffer flip can be operated. It will need > >> > some time for Android device vendors to abondon legency fbdev. So mu= lti > >> > buffer for fbdev is needed. > >> > >> How exactly do we expect Android to move away from fbdev if we add fea= tures to > >> the fbdev compat layer ? I'd much rather make it clear to them that fb= dev is a > >> thing from the past and that they'd better migrate now. > > > > If your point is that merging this patch will slow down the Android > > move away from fbdev, I disagree with that (obviously). > > > > I don't care at all about Android on my platform of choice, but don't > > see how that merging this patch will change anything. > > > > Let's be honest, Android trees typically have thousands of patches on > > top of mainline. Do you think a simple, 15 LoC, patch will make any > > difference to vendors? If they want to stay on fbdev and have that > > feature, they'll just merge this patch, done. >=20 > So, in that case, why not just let them do that? They'd already have > to add patches to use this, surely; we don't have anything in mainline > kernels which allows people to actually use this larger allocation. > Apart from software mmap() and using panning to do flips, but I'm > taking it as a given that people shipping Android on their devices > aren't using software rendering. My point was that you're not doing it more difficult for people not willing to contribute upstream, you're just making it more difficult for people who want to contribute. The whole argument to engage vendors upstream is that we sell them that eventually they will be able to just use whatever kernel release is on kernel.org or in their distro of choice. If those people depend on a feature that is entirely rejected upstream, then they'll have to carry that patch in their tree, creating a BSP in the process. And that reduces greatly the strength of the "you should contribute" argument, making them less involved. > > However, what I do see is that three different people/organisations > > have now expressed interest in that feature, on three different > > SoCs. If that patch needed a significant rework of the fbdev layer, > > then yes, I might agree that it's not worth it. But in this case, it's > > pretty trivial. > > > > The only people you're "punishing" here with that kind of concern are > > the people who actually play fair and want not to have any patches and > > everything upstream. >=20 > I would hazard a guess that most users of this have out-of-tree GPU > drivers. Out of tree GPU drivers, that can be distributed separately from the kernel, just like any out of tree module can. This doesn't require any kernel patches at all. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --yzslvkatelh2fa2i Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYpEvQAAoJEBx+YmzsjxAg4XcP/2aYptUbNT5S2hxDv+BdBl9j uptvkuv+A850LbWXekByW4aLWwOIIt4X68p0IXOHS9eMkHi+HGD+T7qx2meaV5Q2 z9CQi9g2TEVIM8P0bMUMH/JeCziFBKFJm2wIsXybwds5cDSEI9y55e0Bvy43chaq fvjFBS1xsCX1NgBOg36YOqb0fNrVd1h2Z4JxutHNr5B3j4YVyezkaJ4Wb9y7fwqH hb8pmiLjq3uiJNTbQCEocpqzhrEuWn3z6RD2NK+iFsE+MSK062JiIvz0MlauwOyD R6J+y59xOWYyyv+WmWfuG4zDJbaF2H5O6QStSKt1OAYY2cH/4BiPv9KUat1Tq5Q0 FeoNHfStJuwIa+CRBQmZ3r2BywSzEMRoZiQOsxBzdUm2GWA9lUq7Lh5anM1Avnhm +5SW+3pm6RBYVikNXedNiMOEZGci4ChiqGXRrQIeu24MZcGmjE9zQIR9g7ZEfrfE /obpgXJp8gggfS2ZPYxSINo6BYzwLnQaSGSfiPpNUBOplFIOhKFv3qsduLLYlj9T QswQJEbOmyg4pQBUkZNYIwVoenrlYGty0QZovL/bQsurTnH0Cg7DZgpGjPs4nIfx NF+140uOISQQfNh+UC/NSe+tFpKgp2Wb9cC8MS45NOSM6rGbZzr7bpBzWffUqmW4 SvjKNTYSOo5cTj1H3mP/ =+A6t -----END PGP SIGNATURE----- --yzslvkatelh2fa2i--