From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752504AbdBMKyd (ORCPT ); Mon, 13 Feb 2017 05:54:33 -0500 Received: from mail.free-electrons.com ([62.4.15.54]:50230 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751831AbdBMKy3 (ORCPT ); Mon, 13 Feb 2017 05:54:29 -0500 Date: Mon, 13 Feb 2017 11:54:22 +0100 From: Maxime Ripard To: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org, Daniel Vetter , David Airlie , Jani Nikula , Sean Paul , Stefan Christ , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev Message-ID: <20170213105422.2cfr7av6ha2vzdlk@lukather> References: <9b4f80f213b50959d168e6f22b21ee784fe26da5.1486031436.git-series.maxime.ripard@free-electrons.com> <2662533.Ps9k37FiVM@avalon> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2pk32sm47dwwtri3" Content-Disposition: inline In-Reply-To: <2662533.Ps9k37FiVM@avalon> 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 --2pk32sm47dwwtri3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Laurent, On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > Hi Maxime, >=20 > Thank you for the patch. >=20 > On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > > From: Xinliang Liu > >=20 > > This patch add a config to support to create multi buffer for cma fbdev. > > Such as double buffer and triple buffer. > >=20 > > 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 multi > > buffer for fbdev is needed. >=20 > How exactly do we expect Android to move away from fbdev if we add featur= es to=20 > the fbdev compat layer ? I'd much rather make it clear to them that fbdev= is a=20 > 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. 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. I guess a much better strategy would be to provide an incentive to moving to KMS. And I truely think there's one already, so it's just a matter of time before people switch over. Fbdev emulation or not. Ma --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --2pk32sm47dwwtri3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYoZBZAAoJEBx+YmzsjxAg4qUP/i0qSWJXMnfYu88SzMIrmhxv sUDvQsy891tiDj4Om0GJmTa7Y2MIcZZzFQrktW9MbA1dcH7SiM6oLh4PtY0jTv1Z fJls1dBVx02OMC6YA/Kt/7NYYxcVZ2YvA8KsRoKupYj76M6CmIs3rBBAWY1bOM2E Zc5frj5wCTrd9ZG+8fvapjBj51czGBDaWvVxYtBUzMXGUENSz+tGkty9lieFJiME M+X9UWfbvx6tdh3lWMFz1P2yUgXHO4D9mFb/tpvp0g6Eb8+w5Iwi3fOoCDMabxFB VEfo/EFU11K3I6yS3PvXPL7PH7NIb5KVN5GwO0uyaKCbybHqOHmhmqMJvJCxtRgB PJDiNT/fJPzZ8Cvzn064nT9CbOyxgqQ7UVGe+ceRbUf/3+KpZnnGJg/ZZaHtZctR vpTItDDMBRDwTH/u3o0BzQyXAp4nrPchJoX63IIwjwyfWRlyOCnrUvCtiFq1RoSw SG/mIm8jLgedxtrvjIiiqGPNd9PrxeZLWU1EMGmeP74vsdxBwN1YshvERc5IPti2 2Ycp/WNamhIrOCzFnhBWmC+kce/ANqwS4c2JgAWe78yqF1xaJhhcgSGGPfUXCAnI osgizj7preqDZbyFV0PmNQ2U6mJzIUygVDmZYA1EkjCvVCCYu/PsoXj/vVAw14s4 XMWr13iN6RkLRmAV5CUT =Wz/B -----END PGP SIGNATURE----- --2pk32sm47dwwtri3-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Ripard Subject: Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev Date: Mon, 13 Feb 2017 11:54:22 +0100 Message-ID: <20170213105422.2cfr7av6ha2vzdlk@lukather> References: <9b4f80f213b50959d168e6f22b21ee784fe26da5.1486031436.git-series.maxime.ripard@free-electrons.com> <2662533.Ps9k37FiVM@avalon> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1887207137==" Return-path: Received: from mail.free-electrons.com (mail.free-electrons.com [62.4.15.54]) by gabe.freedesktop.org (Postfix) with ESMTP id 497066E001 for ; Mon, 13 Feb 2017 10:54:23 +0000 (UTC) In-Reply-To: <2662533.Ps9k37FiVM@avalon> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Laurent Pinchart Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Daniel Vetter , Stefan Christ List-Id: dri-devel@lists.freedesktop.org --===============1887207137== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2pk32sm47dwwtri3" Content-Disposition: inline --2pk32sm47dwwtri3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Laurent, On Sun, Feb 12, 2017 at 02:28:11PM +0200, Laurent Pinchart wrote: > Hi Maxime, >=20 > Thank you for the patch. >=20 > On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote: > > From: Xinliang Liu > >=20 > > This patch add a config to support to create multi buffer for cma fbdev. > > Such as double buffer and triple buffer. > >=20 > > 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 multi > > buffer for fbdev is needed. >=20 > How exactly do we expect Android to move away from fbdev if we add featur= es to=20 > the fbdev compat layer ? I'd much rather make it clear to them that fbdev= is a=20 > 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. 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. I guess a much better strategy would be to provide an incentive to moving to KMS. And I truely think there's one already, so it's just a matter of time before people switch over. Fbdev emulation or not. Ma --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --2pk32sm47dwwtri3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYoZBZAAoJEBx+YmzsjxAg4qUP/i0qSWJXMnfYu88SzMIrmhxv sUDvQsy891tiDj4Om0GJmTa7Y2MIcZZzFQrktW9MbA1dcH7SiM6oLh4PtY0jTv1Z fJls1dBVx02OMC6YA/Kt/7NYYxcVZ2YvA8KsRoKupYj76M6CmIs3rBBAWY1bOM2E Zc5frj5wCTrd9ZG+8fvapjBj51czGBDaWvVxYtBUzMXGUENSz+tGkty9lieFJiME M+X9UWfbvx6tdh3lWMFz1P2yUgXHO4D9mFb/tpvp0g6Eb8+w5Iwi3fOoCDMabxFB VEfo/EFU11K3I6yS3PvXPL7PH7NIb5KVN5GwO0uyaKCbybHqOHmhmqMJvJCxtRgB PJDiNT/fJPzZ8Cvzn064nT9CbOyxgqQ7UVGe+ceRbUf/3+KpZnnGJg/ZZaHtZctR vpTItDDMBRDwTH/u3o0BzQyXAp4nrPchJoX63IIwjwyfWRlyOCnrUvCtiFq1RoSw SG/mIm8jLgedxtrvjIiiqGPNd9PrxeZLWU1EMGmeP74vsdxBwN1YshvERc5IPti2 2Ycp/WNamhIrOCzFnhBWmC+kce/ANqwS4c2JgAWe78yqF1xaJhhcgSGGPfUXCAnI osgizj7preqDZbyFV0PmNQ2U6mJzIUygVDmZYA1EkjCvVCCYu/PsoXj/vVAw14s4 XMWr13iN6RkLRmAV5CUT =Wz/B -----END PGP SIGNATURE----- --2pk32sm47dwwtri3-- --===============1887207137== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1887207137==--