From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Date: Fri, 09 Dec 2016 11:48:07 +0000 Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers Message-Id: <1481284087.27965.13.camel@kernel.crashing.org> List-Id: References: <20161208101005.6ufl3d4qvwprosju@phenom.ffwll.local> <20161208140210.rfyjf2265flsfpfj@phenom.ffwll.local> <20161208153735.74d7d350@free-electrons.com> <20161208152134.wnv4j4i6m5xpoycp@phenom.ffwll.local> <1481232877.26959.52.camel@kernel.crashing.org> <1481234249.26959.55.camel@kernel.crashing.org> <20161209083442.peoriqsto2llvl2t@phenom.ffwll.local> <20161209084154.rp4wqzv46tuvf3jv@phenom.ffwll.local> In-Reply-To: <20161209084154.rp4wqzv46tuvf3jv@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Daniel Vetter , Geert Uytterhoeven , Thomas Petazzoni , Tomi Valkeinen , Greg Kroah-Hartman , Noralf =?ISO-8859-1?Q?Tr=F8nnes?= , Sudip Mukherjee , Teddy Wang , Arnaud Patard , DRI Development , Linux Fbdev development list , "linux-kernel@vger.kernel.org" On Fri, 2016-12-09 at 09:41 +0100, Daniel Vetter wrote: > > And since I failed to make this clear: There's not really a > fundamental > reason ast and cirrus use the dirty tracking for fbdev. It's just that > doing it that way was the fastest way to get those servers booting, and > ever since no one cared. It's a bit tricky to do right because fbdev > assumes it always own the framebuffer and that it never moves, That can be worked around from my memories of hacking fbdev many years ago. Basically fbdev only owns it if it's the current VT and you can make it release it if the user switches to KD_GRAPHICS which userspace should always do before taking over. As for multi userspace client, well, swapping an mmap between HW and memory backing store is a somewhat solved problem already. > whereas drm has a multi-master model and proper isolation. IIrc we've hacked up > something once, and if there's indeed more interest into vram dumb buffer > drivers I'm pretty sure we can grow some nice ttm fb helpers (like the cma > fb helpers we have) to make it all pretty and nice and fast and > essentially plug-in-and-forget from a driver authors pov. That would be nice. I don't have the bandwidth to swap-in enough understanding of TTM guts right now but I might look into it some time next  year if nobody beats me to it. > Cheers, Daniel > > > The massive pile of dumb framebuffers we all merged over the past 2 years > > all use system/dma memory for scanout, and for those we have the very nice > > cma helpers that take care of everything for you. So it is possible, only > > reason vram dumb buffers look worse is that there's only 3 and no one > > cares about them, vs about 20 and a very active community of contributors > > (also for core drm improvements) for the other case. > > > > Althought the MXSFB driver that just landed does use ttm and vram, so > > maybe that's now improving too. > > -Daniel > > --  > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers Date: Fri, 09 Dec 2016 22:48:07 +1100 Message-ID: <1481284087.27965.13.camel@kernel.crashing.org> References: <20161208101005.6ufl3d4qvwprosju@phenom.ffwll.local> <20161208140210.rfyjf2265flsfpfj@phenom.ffwll.local> <20161208153735.74d7d350@free-electrons.com> <20161208152134.wnv4j4i6m5xpoycp@phenom.ffwll.local> <1481232877.26959.52.camel@kernel.crashing.org> <1481234249.26959.55.camel@kernel.crashing.org> <20161209083442.peoriqsto2llvl2t@phenom.ffwll.local> <20161209084154.rp4wqzv46tuvf3jv@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8EF1F6E991 for ; Fri, 9 Dec 2016 11:48:30 +0000 (UTC) In-Reply-To: <20161209084154.rp4wqzv46tuvf3jv@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter , Geert Uytterhoeven , Thomas Petazzoni , Tomi Valkeinen , Greg Kroah-Hartman , Noralf =?ISO-8859-1?Q?Tr=F8nnes?= , Sudip Mukherjee , Teddy Wang , Arnaud Patard , DRI Development , Linux Fbdev development list , "linux-kernel@vger.kernel.org" List-Id: dri-devel@lists.freedesktop.org T24gRnJpLCAyMDE2LTEyLTA5IGF0IDA5OjQxICswMTAwLCBEYW5pZWwgVmV0dGVyIHdyb3RlOgo+ IAo+IEFuZCBzaW5jZSBJIGZhaWxlZCB0byBtYWtlIHRoaXMgY2xlYXI6IFRoZXJlJ3Mgbm90IHJl YWxseSBhCj4gZnVuZGFtZW50YWwKPiByZWFzb24gYXN0IGFuZCBjaXJydXMgdXNlIHRoZSBkaXJ0 eSB0cmFja2luZyBmb3IgZmJkZXYuIEl0J3MganVzdCB0aGF0Cj4gZG9pbmcgaXQgdGhhdCB3YXkg d2FzIHRoZSBmYXN0ZXN0IHdheSB0byBnZXQgdGhvc2Ugc2VydmVycyBib290aW5nLCBhbmQKPiBl dmVyIHNpbmNlIG5vIG9uZSBjYXJlZC4gSXQncyBhIGJpdCB0cmlja3kgdG8gZG8gcmlnaHQgYmVj YXVzZSBmYmRldgo+IGFzc3VtZXMgaXQgYWx3YXlzIG93biB0aGUgZnJhbWVidWZmZXIgYW5kIHRo YXQgaXQgbmV2ZXIgbW92ZXMsIAoKVGhhdCBjYW4gYmUgd29ya2VkIGFyb3VuZCBmcm9tIG15IG1l bW9yaWVzIG9mIGhhY2tpbmcgZmJkZXYgbWFueSB5ZWFycwphZ28uIEJhc2ljYWxseSBmYmRldiBv bmx5IG93bnMgaXQgaWYgaXQncyB0aGUgY3VycmVudCBWVCBhbmQgeW91IGNhbgptYWtlIGl0IHJl bGVhc2UgaXQgaWYgdGhlIHVzZXIgc3dpdGNoZXMgdG8gS0RfR1JBUEhJQ1Mgd2hpY2ggdXNlcnNw YWNlCnNob3VsZCBhbHdheXMgZG8gYmVmb3JlIHRha2luZyBvdmVyLgoKQXMgZm9yIG11bHRpIHVz ZXJzcGFjZSBjbGllbnQsIHdlbGwsIHN3YXBwaW5nIGFuIG1tYXAgYmV0d2VlbiBIVyBhbmQKbWVt b3J5IGJhY2tpbmcgc3RvcmUgaXMgYSBzb21ld2hhdCBzb2x2ZWQgcHJvYmxlbSBhbHJlYWR5LgoK PiB3aGVyZWFzIGRybSBoYXMgYSBtdWx0aS1tYXN0ZXIgbW9kZWwgYW5kIHByb3BlciBpc29sYXRp b24uIElJcmMgd2UndmUgaGFja2VkIHVwCj4gc29tZXRoaW5nIG9uY2UsIGFuZCBpZiB0aGVyZSdz IGluZGVlZCBtb3JlIGludGVyZXN0IGludG8gdnJhbSBkdW1iIGJ1ZmZlcgo+IGRyaXZlcnMgSSdt IHByZXR0eSBzdXJlIHdlIGNhbiBncm93IHNvbWUgbmljZSB0dG0gZmIgaGVscGVycyAobGlrZSB0 aGUgY21hCj4gZmIgaGVscGVycyB3ZSBoYXZlKSB0byBtYWtlIGl0IGFsbCBwcmV0dHkgYW5kIG5p Y2UgYW5kIGZhc3QgYW5kCj4gZXNzZW50aWFsbHkgcGx1Zy1pbi1hbmQtZm9yZ2V0IGZyb20gYSBk cml2ZXIgYXV0aG9ycyBwb3YuCgpUaGF0IHdvdWxkIGJlIG5pY2UuIEkgZG9uJ3QgaGF2ZSB0aGUg YmFuZHdpZHRoIHRvIHN3YXAtaW4gZW5vdWdoCnVuZGVyc3RhbmRpbmcgb2YgVFRNIGd1dHMgcmln aHQgbm93IGJ1dCBJIG1pZ2h0IGxvb2sgaW50byBpdCBzb21lIHRpbWUgbmV4dMKgCnllYXIgaWYg bm9ib2R5IGJlYXRzIG1lIHRvIGl0LgoKPiBDaGVlcnMsIERhbmllbAo+IAo+ID4gVGhlIG1hc3Np dmUgcGlsZSBvZiBkdW1iIGZyYW1lYnVmZmVycyB3ZSBhbGwgbWVyZ2VkIG92ZXIgdGhlIHBhc3Qg MiB5ZWFycwo+ID4gYWxsIHVzZSBzeXN0ZW0vZG1hIG1lbW9yeSBmb3Igc2Nhbm91dCwgYW5kIGZv ciB0aG9zZSB3ZSBoYXZlIHRoZSB2ZXJ5IG5pY2UKPiA+IGNtYSBoZWxwZXJzIHRoYXQgdGFrZSBj YXJlIG9mIGV2ZXJ5dGhpbmcgZm9yIHlvdS4gU28gaXQgaXMgcG9zc2libGUsIG9ubHkKPiA+IHJl YXNvbiB2cmFtIGR1bWIgYnVmZmVycyBsb29rIHdvcnNlIGlzIHRoYXQgdGhlcmUncyBvbmx5IDMg YW5kIG5vIG9uZQo+ID4gY2FyZXMgYWJvdXQgdGhlbSwgdnMgYWJvdXQgMjAgYW5kIGEgdmVyeSBh Y3RpdmUgY29tbXVuaXR5IG9mIGNvbnRyaWJ1dG9ycwo+ID4gKGFsc28gZm9yIGNvcmUgZHJtIGlt cHJvdmVtZW50cykgZm9yIHRoZSBvdGhlciBjYXNlLgo+ID4gCj4gPiBBbHRob3VnaHQgdGhlIE1Y U0ZCIGRyaXZlciB0aGF0IGp1c3QgbGFuZGVkIGRvZXMgdXNlIHR0bSBhbmQgdnJhbSwgc28KPiA+ IG1heWJlIHRoYXQncyBub3cgaW1wcm92aW5nIHRvby4KPiA+IC1EYW5pZWwKPiA+IC0twqAKPiA+ IERhbmllbCBWZXR0ZXIKPiA+IFNvZnR3YXJlIEVuZ2luZWVyLCBJbnRlbCBDb3Jwb3JhdGlvbgo+ ID4gaHR0cDovL2Jsb2cuZmZ3bGwuY2gKPiAKPiAKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlz dHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4v bGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933357AbcLILtJ (ORCPT ); Fri, 9 Dec 2016 06:49:09 -0500 Received: from gate.crashing.org ([63.228.1.57]:42016 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932876AbcLILtH (ORCPT ); Fri, 9 Dec 2016 06:49:07 -0500 Message-ID: <1481284087.27965.13.camel@kernel.crashing.org> Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers From: Benjamin Herrenschmidt To: Daniel Vetter , Geert Uytterhoeven , Thomas Petazzoni , Tomi Valkeinen , Greg Kroah-Hartman , Noralf =?ISO-8859-1?Q?Tr=F8nnes?= , Sudip Mukherjee , Teddy Wang , Arnaud Patard , DRI Development , Linux Fbdev development list , "linux-kernel@vger.kernel.org" Date: Fri, 09 Dec 2016 22:48:07 +1100 In-Reply-To: <20161209084154.rp4wqzv46tuvf3jv@phenom.ffwll.local> References: <20161208101005.6ufl3d4qvwprosju@phenom.ffwll.local> <20161208140210.rfyjf2265flsfpfj@phenom.ffwll.local> <20161208153735.74d7d350@free-electrons.com> <20161208152134.wnv4j4i6m5xpoycp@phenom.ffwll.local> <1481232877.26959.52.camel@kernel.crashing.org> <1481234249.26959.55.camel@kernel.crashing.org> <20161209083442.peoriqsto2llvl2t@phenom.ffwll.local> <20161209084154.rp4wqzv46tuvf3jv@phenom.ffwll.local> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.2 (3.22.2-1.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2016-12-09 at 09:41 +0100, Daniel Vetter wrote: > > And since I failed to make this clear: There's not really a > fundamental > reason ast and cirrus use the dirty tracking for fbdev. It's just that > doing it that way was the fastest way to get those servers booting, and > ever since no one cared. It's a bit tricky to do right because fbdev > assumes it always own the framebuffer and that it never moves, That can be worked around from my memories of hacking fbdev many years ago. Basically fbdev only owns it if it's the current VT and you can make it release it if the user switches to KD_GRAPHICS which userspace should always do before taking over. As for multi userspace client, well, swapping an mmap between HW and memory backing store is a somewhat solved problem already. > whereas drm has a multi-master model and proper isolation. IIrc we've hacked up > something once, and if there's indeed more interest into vram dumb buffer > drivers I'm pretty sure we can grow some nice ttm fb helpers (like the cma > fb helpers we have) to make it all pretty and nice and fast and > essentially plug-in-and-forget from a driver authors pov. That would be nice. I don't have the bandwidth to swap-in enough understanding of TTM guts right now but I might look into it some time next  year if nobody beats me to it. > Cheers, Daniel > > > The massive pile of dumb framebuffers we all merged over the past 2 years > > all use system/dma memory for scanout, and for those we have the very nice > > cma helpers that take care of everything for you. So it is possible, only > > reason vram dumb buffers look worse is that there's only 3 and no one > > cares about them, vs about 20 and a very active community of contributors > > (also for core drm improvements) for the other case. > > > > Althought the MXSFB driver that just landed does use ttm and vram, so > > maybe that's now improving too. > > -Daniel > > --  > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > >