From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev Date: Fri, 17 Feb 2017 13:23:49 +0200 Message-ID: <1600256.gsfUMW7C6z@avalon> References: <20170215123844.o6ey7widifnq2hud@lukather> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from galahad.ideasonboard.com (galahad.ideasonboard.com [185.26.127.97]) by gabe.freedesktop.org (Postfix) with ESMTPS id CA9A26E5C4 for ; Fri, 17 Feb 2017 11:23:20 +0000 (UTC) In-Reply-To: <20170215123844.o6ey7widifnq2hud@lukather> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Maxime Ripard Cc: Daniel Vetter , dri-devel , Stefan Christ , Linux Kernel Mailing List List-Id: dri-devel@lists.freedesktop.org SGkgTWF4aW1lLAoKT24gV2VkbmVzZGF5IDE1IEZlYiAyMDE3IDEzOjM4OjQ0IE1heGltZSBSaXBh cmQgd3JvdGU6Cj4gT24gTW9uLCBGZWIgMTMsIDIwMTcgYXQgMTE6MjA6NTFBTSArMDAwMCwgRGFu aWVsIFN0b25lIHdyb3RlOgo+ID4gT24gMTMgRmVicnVhcnkgMjAxNyBhdCAxMDo1NCwgTWF4aW1l IFJpcGFyZCB3cm90ZToKPiA+PiBPbiBTdW4sIEZlYiAxMiwgMjAxNyBhdCAwMjoyODoxMVBNICsw MjAwLCBMYXVyZW50IFBpbmNoYXJ0IHdyb3RlOgo+ID4+PiBPbiBUaHVyc2RheSAwMiBGZWIgMjAx NyAxMTozMTo1NiBNYXhpbWUgUmlwYXJkIHdyb3RlOgo+ID4+Pj4gVGhpcyBwYXRjaCBhZGQgYSBj b25maWcgdG8gc3VwcG9ydCB0byBjcmVhdGUgbXVsdGkgYnVmZmVyIGZvciBjbWEKPiA+Pj4+IGZi ZGV2LiBTdWNoIGFzIGRvdWJsZSBidWZmZXIgYW5kIHRyaXBsZSBidWZmZXIuCj4gPj4+PiAKPiA+ Pj4+IENtYSBmYmRldiBpcyBjb252aWVudCB0byBhZGQgYSBsZWdlbmN5IGZiZGV2LiBBbmQgc3Rp bGwgbWFueSBBbmRyb2lkCj4gPj4+PiBkZXZpY2VzIHVzZSBmYmRldiBub3cgYW5kIGF0IGxlYXN0 IGRvdWJsZSBidWZmZXIgaXMgbmVlZGVkIGZvciB0aGVzZQo+ID4+Pj4gQW5kcm9pZCBkZXZpY2Vz LCBzbyB0aGF0IGEgYnVmZmVyIGZsaXAgY2FuIGJlIG9wZXJhdGVkLiBJdCB3aWxsIG5lZWQKPiA+ Pj4+IHNvbWUgdGltZSBmb3IgQW5kcm9pZCBkZXZpY2UgdmVuZG9ycyB0byBhYm9uZG9uIGxlZ2Vu Y3kgZmJkZXYuIFNvCj4gPj4+PiBtdWx0aSBidWZmZXIgZm9yIGZiZGV2IGlzIG5lZWRlZC4KPiA+ Pj4gCj4gPj4+IEhvdyBleGFjdGx5IGRvIHdlIGV4cGVjdCBBbmRyb2lkIHRvIG1vdmUgYXdheSBm cm9tIGZiZGV2IGlmIHdlIGFkZAo+ID4+PiBmZWF0dXJlcyB0byB0aGUgZmJkZXYgY29tcGF0IGxh eWVyID8gSSdkIG11Y2ggcmF0aGVyIG1ha2UgaXQgY2xlYXIgdG8KPiA+Pj4gdGhlbSB0aGF0IGZi ZGV2IGlzIGEgdGhpbmcgZnJvbSB0aGUgcGFzdCBhbmQgdGhhdCB0aGV5J2QgYmV0dGVyCj4gPj4+ IG1pZ3JhdGUgbm93Lgo+ID4+IAo+ID4+IElmIHlvdXIgcG9pbnQgaXMgdGhhdCBtZXJnaW5nIHRo aXMgcGF0Y2ggd2lsbCBzbG93IGRvd24gdGhlIEFuZHJvaWQKPiA+PiBtb3ZlIGF3YXkgZnJvbSBm YmRldiwgSSBkaXNhZ3JlZSB3aXRoIHRoYXQgKG9idmlvdXNseSkuCj4gPj4gCj4gPj4gSSBkb24n dCBjYXJlIGF0IGFsbCBhYm91dCBBbmRyb2lkIG9uIG15IHBsYXRmb3JtIG9mIGNob2ljZSwgYnV0 IGRvbid0Cj4gPj4gc2VlIGhvdyB0aGF0IG1lcmdpbmcgdGhpcyBwYXRjaCB3aWxsIGNoYW5nZSBh bnl0aGluZy4KPiA+PiAKPiA+PiBMZXQncyBiZSBob25lc3QsIEFuZHJvaWQgdHJlZXMgdHlwaWNh bGx5IGhhdmUgdGhvdXNhbmRzIG9mIHBhdGNoZXMgb24KPiA+PiB0b3Agb2YgbWFpbmxpbmUuIERv IHlvdSB0aGluayBhIHNpbXBsZSwgMTUgTG9DLCBwYXRjaCB3aWxsIG1ha2UgYW55Cj4gPj4gZGlm ZmVyZW5jZSB0byB2ZW5kb3JzPyBJZiB0aGV5IHdhbnQgdG8gc3RheSBvbiBmYmRldiBhbmQgaGF2 ZSB0aGF0Cj4gPj4gZmVhdHVyZSwgdGhleSdsbCBqdXN0IG1lcmdlIHRoaXMgcGF0Y2gsIGRvbmUu Cj4gPiAKPiA+IFNvLCBpbiB0aGF0IGNhc2UsIHdoeSBub3QganVzdCBsZXQgdGhlbSBkbyB0aGF0 PyBUaGV5J2QgYWxyZWFkeSBoYXZlCj4gPiB0byBhZGQgcGF0Y2hlcyB0byB1c2UgdGhpcywgc3Vy ZWx5OyB3ZSBkb24ndCBoYXZlIGFueXRoaW5nIGluIG1haW5saW5lCj4gPiBrZXJuZWxzIHdoaWNo IGFsbG93cyBwZW9wbGUgdG8gYWN0dWFsbHkgdXNlIHRoaXMgbGFyZ2VyIGFsbG9jYXRpb24uCj4g PiBBcGFydCBmcm9tIHNvZnR3YXJlIG1tYXAoKSBhbmQgdXNpbmcgcGFubmluZyB0byBkbyBmbGlw cywgYnV0IEknbQo+ID4gdGFraW5nIGl0IGFzIGEgZ2l2ZW4gdGhhdCBwZW9wbGUgc2hpcHBpbmcg QW5kcm9pZCBvbiB0aGVpciBkZXZpY2VzCj4gPiBhcmVuJ3QgdXNpbmcgc29mdHdhcmUgcmVuZGVy aW5nLgo+IAo+IE15IHBvaW50IHdhcyB0aGF0IHlvdSdyZSBub3QgZG9pbmcgaXQgbW9yZSBkaWZm aWN1bHQgZm9yIHBlb3BsZSBub3QKPiB3aWxsaW5nIHRvIGNvbnRyaWJ1dGUgdXBzdHJlYW0sIHlv dSdyZSBqdXN0IG1ha2luZyBpdCBtb3JlIGRpZmZpY3VsdAo+IGZvciBwZW9wbGUgd2hvIHdhbnQg dG8gY29udHJpYnV0ZS4KPiAKPiBUaGUgd2hvbGUgYXJndW1lbnQgdG8gZW5nYWdlIHZlbmRvcnMg dXBzdHJlYW0gaXMgdGhhdCB3ZSBzZWxsIHRoZW0KPiB0aGF0IGV2ZW50dWFsbHkgdGhleSB3aWxs IGJlIGFibGUgdG8ganVzdCB1c2Ugd2hhdGV2ZXIga2VybmVsIHJlbGVhc2UKPiBpcyBvbiBrZXJu ZWwub3JnIG9yIGluIHRoZWlyIGRpc3RybyBvZiBjaG9pY2UuCj4gCj4gSWYgdGhvc2UgcGVvcGxl IGRlcGVuZCBvbiBhIGZlYXR1cmUgdGhhdCBpcyBlbnRpcmVseSByZWplY3RlZAo+IHVwc3RyZWFt LCB0aGVuIHRoZXknbGwgaGF2ZSB0byBjYXJyeSB0aGF0IHBhdGNoIGluIHRoZWlyIHRyZWUsCj4g Y3JlYXRpbmcgYSBCU1AgaW4gdGhlIHByb2Nlc3MuIEFuZCB0aGF0IHJlZHVjZXMgZ3JlYXRseSB0 aGUgc3RyZW5ndGgKPiBvZiB0aGUgInlvdSBzaG91bGQgY29udHJpYnV0ZSIgYXJndW1lbnQsIG1h a2luZyB0aGVtIGxlc3MgaW52b2x2ZWQuCgpObywgdGhleSBzaG91bGQgbm90IGNhcnJ5IGFuIG91 dC1vZi10cmVlIHBhdGNoLCB0aGV5IHNob3VsZCBub3QgdXNlIHRoYXQgCmZlYXR1cmUgaW4gdGhl IGZpcnN0IHBsYWNlLiBmYmRldiBpcyBhIGRlYWQtZW5kLCBMaW51eCBoYXMgY2xlYXJseSBkZWNp ZGVkIHRvIAptb3ZlIHRvIERSTS9LTVMuIEFueSB2ZW5kb3Igd2hvIHdhbnRzIHRvIGtlZXAgdXNp bmcgZmJkZXYgaXMgc2hvb3RpbmcgCnRoZW1zZWx2ZXMgaW4gdGhlIGZvb3QsIGFzIHRoZSBtb3Jl IHRoZXkgZGVwZW5kIG9uIGZiZGV2LCB0aGUgbW9yZSBwYWluZnVsIGl0IAp3aWxsIGJlIHRvIHN3 aXRjaCBsYXRlciB3aGVuIHRoZXkgd2lsbCBoYXZlIG5vIGNob2ljZS4gU3dpdGNoaW5nIHNvb25l ciB0aGFuIApsYXRlciBpcyB0aGUgYmVzdCBkZWNpc2lvbiwgYW5kIEknZCBhcmd1ZSB0aGF0IGJ5 IG1ha2luZyBpdCBlYXNpZXIgdG8gc3RheSBvbiAKZmJkZXYgd2Ugd291bGQgYWN0dWFsbHkgaHVy dCB0aG9zZSB2ZW5kb3JzIGluIHRoZSBsb25nZXIgdGVybS4KCj4gPj4gSG93ZXZlciwgd2hhdCBJ IGRvIHNlZSBpcyB0aGF0IHRocmVlIGRpZmZlcmVudCBwZW9wbGUvb3JnYW5pc2F0aW9ucwo+ID4+ IGhhdmUgbm93IGV4cHJlc3NlZCBpbnRlcmVzdCBpbiB0aGF0IGZlYXR1cmUsIG9uIHRocmVlIGRp ZmZlcmVudAo+ID4+IFNvQ3MuIElmIHRoYXQgcGF0Y2ggbmVlZGVkIGEgc2lnbmlmaWNhbnQgcmV3 b3JrIG9mIHRoZSBmYmRldiBsYXllciwKPiA+PiB0aGVuIHllcywgSSBtaWdodCBhZ3JlZSB0aGF0 IGl0J3Mgbm90IHdvcnRoIGl0LiBCdXQgaW4gdGhpcyBjYXNlLCBpdCdzCj4gPj4gcHJldHR5IHRy aXZpYWwuCj4gPj4gCj4gPj4gVGhlIG9ubHkgcGVvcGxlIHlvdSdyZSAicHVuaXNoaW5nIiBoZXJl IHdpdGggdGhhdCBraW5kIG9mIGNvbmNlcm4gYXJlCj4gPj4gdGhlIHBlb3BsZSB3aG8gYWN0dWFs bHkgcGxheSBmYWlyIGFuZCB3YW50IG5vdCB0byBoYXZlIGFueSBwYXRjaGVzIGFuZAo+ID4+IGV2 ZXJ5dGhpbmcgdXBzdHJlYW0uCj4gPiAKPiA+IEkgd291bGQgaGF6YXJkIGEgZ3Vlc3MgdGhhdCBt b3N0IHVzZXJzIG9mIHRoaXMgaGF2ZSBvdXQtb2YtdHJlZSBHUFUKPiA+IGRyaXZlcnMuCj4gCj4g T3V0IG9mIHRyZWUgR1BVIGRyaXZlcnMsIHRoYXQgY2FuIGJlIGRpc3RyaWJ1dGVkIHNlcGFyYXRl bHkgZnJvbSB0aGUKPiBrZXJuZWwsIGp1c3QgbGlrZSBhbnkgb3V0IG9mIHRyZWUgbW9kdWxlIGNh bi4gVGhpcyBkb2Vzbid0IHJlcXVpcmUgYW55Cj4ga2VybmVsIHBhdGNoZXMgYXQgYWxsLgoKVGhh dCBtaWdodCBiZSB0cnVlIGluIHNvbWUgY2FzZXMsIGJ1dCB1c3VhbGx5IHRob3NlIEdQVSBkcml2 ZXJzIHJlcXVpcmUgaGVhdnkgCnBhdGNoaW5nIG9mIGF0IGxlYXN0IHRoZSBkaXNwbGF5IGNvbnRy b2xsZXIgZHJpdmVyLgoKLS0gClJlZ2FyZHMsCgpMYXVyZW50IFBpbmNoYXJ0CgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBs aXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVz a3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933446AbdBQLXX (ORCPT ); Fri, 17 Feb 2017 06:23:23 -0500 Received: from galahad.ideasonboard.com ([185.26.127.97]:55015 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932505AbdBQLXV (ORCPT ); Fri, 17 Feb 2017 06:23:21 -0500 From: Laurent Pinchart To: Maxime Ripard Cc: Daniel Stone , 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 Date: Fri, 17 Feb 2017 13:23:49 +0200 Message-ID: <1600256.gsfUMW7C6z@avalon> User-Agent: KMail/4.14.10 (Linux/4.9.6-gentoo-r1; KDE/4.14.28; x86_64; ; ) In-Reply-To: <20170215123844.o6ey7widifnq2hud@lukather> References: <20170215123844.o6ey7widifnq2hud@lukather> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Maxime, On Wednesday 15 Feb 2017 13:38:44 Maxime Ripard wrote: > On Mon, Feb 13, 2017 at 11:20:51AM +0000, Daniel Stone wrote: > > 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 > >>>> fbdev. 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 > >>>> multi buffer for fbdev is needed. > >>> > >>> How exactly do we expect Android to move away from fbdev if we add > >>> features to the fbdev compat layer ? I'd much rather make it clear to > >>> them that fbdev 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. > > > > 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. No, they should not carry an out-of-tree patch, they should not use that feature in the first place. fbdev is a dead-end, Linux has clearly decided to move to DRM/KMS. Any vendor who wants to keep using fbdev is shooting themselves in the foot, as the more they depend on fbdev, the more painful it will be to switch later when they will have no choice. Switching sooner than later is the best decision, and I'd argue that by making it easier to stay on fbdev we would actually hurt those vendors in the longer term. > >> 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 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. That might be true in some cases, but usually those GPU drivers require heavy patching of at least the display controller driver. -- Regards, Laurent Pinchart