From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Date: Fri, 09 Dec 2016 20:27:03 +0000 Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers Message-Id: <1481315223.17253.15.camel@kernel.crashing.org> List-Id: References: <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> <1481284087.27965.13.camel@kernel.crashing.org> <20161209133512.nuohi42ho3rgghau@phenom.ffwll.local> In-Reply-To: <20161209133512.nuohi42ho3rgghau@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Daniel Vetter Cc: Thomas Petazzoni , Linux Fbdev development list , Teddy Wang , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , DRI Development , Tomi Valkeinen , Geert Uytterhoeven , Sudip Mukherjee , Arnaud Patard On Fri, 2016-12-09 at 14:35 +0100, Daniel Vetter wrote: > > As for multi userspace client, well, swapping an mmap between HW and > > memory backing store is a somewhat solved problem already. > > Hm, I didn't know that, but then all existing drm drivers have fairly > simplistic fbdev mmap implementations. Hrm, I though the TTM did it ... I remember talking with Thomas Hellstrom about that back in the day... you use unmap_mapping_range to unmap the existing mappings basically so you can take new faults and route them to a different page, but I can't see a call in there so maybe he ended up not doing it. We used to do that on Cell to "context switch" the local memory of the SPU engines between the real SPU and the backing store. It's not very hard to do. The main issue is that the mapping attributes change between cached and non-cached under the hood, so users have to be careful not to do things like use instructions that only work on one type of mapping (or do things like misaligned accesses). > > > 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. > > Probably best would be to first extract some helpers for ttm based vram > dumb buffer management, and then start to implement some of the > improvements so that all drivers can benefit. Like you've said it's not > rocket science, it just needs to be done ;-) Right :-) Though getting ones head around the infrastructure in the DRM does take time :-) There's a lot of stuff in there, between TTM, GEM etc... and not all of it completely "obvious" ... Cheers, Ben. > -Daniel > --  From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers Date: Sat, 10 Dec 2016 07:27:03 +1100 Message-ID: <1481315223.17253.15.camel@kernel.crashing.org> References: <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> <1481284087.27965.13.camel@kernel.crashing.org> <20161209133512.nuohi42ho3rgghau@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 739246EA98 for ; Fri, 9 Dec 2016 20:51:17 +0000 (UTC) In-Reply-To: <20161209133512.nuohi42ho3rgghau@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 Cc: Thomas Petazzoni , Linux Fbdev development list , Teddy Wang , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , DRI Development , Tomi Valkeinen , Geert Uytterhoeven , Sudip Mukherjee , Arnaud Patard List-Id: dri-devel@lists.freedesktop.org T24gRnJpLCAyMDE2LTEyLTA5IGF0IDE0OjM1ICswMTAwLCBEYW5pZWwgVmV0dGVyIHdyb3RlOgo+ ID4gQXMgZm9yIG11bHRpIHVzZXJzcGFjZSBjbGllbnQsIHdlbGwsIHN3YXBwaW5nIGFuIG1tYXAg YmV0d2VlbiBIVyBhbmQKPiA+IG1lbW9yeSBiYWNraW5nIHN0b3JlIGlzIGEgc29tZXdoYXQgc29s dmVkIHByb2JsZW0gYWxyZWFkeS4KPiAKPiBIbSwgSSBkaWRuJ3Qga25vdyB0aGF0LCBidXQgdGhl biBhbGwgZXhpc3RpbmcgZHJtIGRyaXZlcnMgaGF2ZSBmYWlybHkKPiBzaW1wbGlzdGljIGZiZGV2 IG1tYXAgaW1wbGVtZW50YXRpb25zLgoKSHJtLCBJIHRob3VnaCB0aGUgVFRNIGRpZCBpdCAuLi4g SSByZW1lbWJlciB0YWxraW5nIHdpdGggVGhvbWFzCkhlbGxzdHJvbSBhYm91dCB0aGF0IGJhY2sg aW4gdGhlIGRheS4uLiB5b3UgdXNlIHVubWFwX21hcHBpbmdfcmFuZ2UKdG8gdW5tYXAgdGhlIGV4 aXN0aW5nIG1hcHBpbmdzIGJhc2ljYWxseSBzbyB5b3UgY2FuIHRha2UgbmV3IGZhdWx0cwphbmQg cm91dGUgdGhlbSB0byBhIGRpZmZlcmVudCBwYWdlLCBidXQgSSBjYW4ndCBzZWUgYSBjYWxsIGlu IHRoZXJlCnNvIG1heWJlIGhlIGVuZGVkIHVwIG5vdCBkb2luZyBpdC4KCldlIHVzZWQgdG8gZG8g dGhhdCBvbiBDZWxsIHRvICJjb250ZXh0IHN3aXRjaCIgdGhlIGxvY2FsIG1lbW9yeSBvZgp0aGUg U1BVIGVuZ2luZXMgYmV0d2VlbiB0aGUgcmVhbCBTUFUgYW5kIHRoZSBiYWNraW5nIHN0b3JlLiBJ dCdzIG5vdAp2ZXJ5IGhhcmQgdG8gZG8uCiAKVGhlIG1haW4gaXNzdWUgaXMgdGhhdCB0aGUgbWFw cGluZyBhdHRyaWJ1dGVzIGNoYW5nZSBiZXR3ZWVuIGNhY2hlZAphbmQgbm9uLWNhY2hlZCB1bmRl ciB0aGUgaG9vZCwgc28gdXNlcnMgaGF2ZSB0byBiZSBjYXJlZnVsIG5vdCB0byBkbwp0aGluZ3Mg bGlrZSB1c2UgaW5zdHJ1Y3Rpb25zIHRoYXQgb25seSB3b3JrIG9uIG9uZSB0eXBlIG9mIG1hcHBp bmcKKG9yIGRvIHRoaW5ncyBsaWtlIG1pc2FsaWduZWQgYWNjZXNzZXMpLgoKPiA+ID4gd2hlcmVh cyBkcm0gaGFzIGEgbXVsdGktbWFzdGVyIG1vZGVsIGFuZCBwcm9wZXIgaXNvbGF0aW9uLiBJSXJj IHdlJ3ZlIGhhY2tlZCB1cAo+ID4gPiBzb21ldGhpbmcgb25jZSwgYW5kIGlmIHRoZXJlJ3MgaW5k ZWVkIG1vcmUgaW50ZXJlc3QgaW50byB2cmFtIGR1bWIgYnVmZmVyCj4gPiA+IGRyaXZlcnMgSSdt IHByZXR0eSBzdXJlIHdlIGNhbiBncm93IHNvbWUgbmljZSB0dG0gZmIgaGVscGVycyAobGlrZSB0 aGUgY21hCj4gPiA+IGZiIGhlbHBlcnMgd2UgaGF2ZSkgdG8gbWFrZSBpdCBhbGwgcHJldHR5IGFu ZCBuaWNlIGFuZCBmYXN0IGFuZAo+ID4gPiBlc3NlbnRpYWxseSBwbHVnLWluLWFuZC1mb3JnZXQg ZnJvbSBhIGRyaXZlciBhdXRob3JzIHBvdi4KPiA+IAo+ID4gVGhhdCB3b3VsZCBiZSBuaWNlLiBJ IGRvbid0IGhhdmUgdGhlIGJhbmR3aWR0aCB0byBzd2FwLWluIGVub3VnaAo+ID4gdW5kZXJzdGFu ZGluZyBvZiBUVE0gZ3V0cyByaWdodCBub3cgYnV0IEkgbWlnaHQgbG9vayBpbnRvIGl0IHNvbWUg dGltZSBuZXh0wqAKPiA+IHllYXIgaWYgbm9ib2R5IGJlYXRzIG1lIHRvIGl0Lgo+IAo+IFByb2Jh Ymx5IGJlc3Qgd291bGQgYmUgdG8gZmlyc3QgZXh0cmFjdCBzb21lIGhlbHBlcnMgZm9yIHR0bSBi YXNlZCB2cmFtCj4gZHVtYiBidWZmZXIgbWFuYWdlbWVudCwgYW5kIHRoZW4gc3RhcnQgdG8gaW1w bGVtZW50IHNvbWUgb2YgdGhlCj4gaW1wcm92ZW1lbnRzIHNvIHRoYXQgYWxsIGRyaXZlcnMgY2Fu IGJlbmVmaXQuIExpa2UgeW91J3ZlIHNhaWQgaXQncyBub3QKPiByb2NrZXQgc2NpZW5jZSwgaXQg anVzdCBuZWVkcyB0byBiZSBkb25lIDstKQoKUmlnaHQgOi0pCgpUaG91Z2ggZ2V0dGluZyBvbmVz IGhlYWQgYXJvdW5kIHRoZSBpbmZyYXN0cnVjdHVyZSBpbiB0aGUgRFJNIGRvZXMgdGFrZQp0aW1l IDotKSBUaGVyZSdzIGEgbG90IG9mIHN0dWZmIGluIHRoZXJlLCBiZXR3ZWVuIFRUTSwgR0VNIGV0 Yy4uLiBhbmQKbm90IGFsbCBvZiBpdCBjb21wbGV0ZWx5ICJvYnZpb3VzIiAuLi4KCkNoZWVycywK QmVuLgoKPiAtRGFuaWVsCj4gLS3CoApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVl ZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5m by9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752813AbcLIVOd (ORCPT ); Fri, 9 Dec 2016 16:14:33 -0500 Received: from gate.crashing.org ([63.228.1.57]:40184 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750756AbcLIVOb (ORCPT ); Fri, 9 Dec 2016 16:14:31 -0500 Message-ID: <1481315223.17253.15.camel@kernel.crashing.org> Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers From: Benjamin Herrenschmidt To: Daniel Vetter Cc: 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: Sat, 10 Dec 2016 07:27:03 +1100 In-Reply-To: <20161209133512.nuohi42ho3rgghau@phenom.ffwll.local> References: <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> <1481284087.27965.13.camel@kernel.crashing.org> <20161209133512.nuohi42ho3rgghau@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 14:35 +0100, Daniel Vetter wrote: > > As for multi userspace client, well, swapping an mmap between HW and > > memory backing store is a somewhat solved problem already. > > Hm, I didn't know that, but then all existing drm drivers have fairly > simplistic fbdev mmap implementations. Hrm, I though the TTM did it ... I remember talking with Thomas Hellstrom about that back in the day... you use unmap_mapping_range to unmap the existing mappings basically so you can take new faults and route them to a different page, but I can't see a call in there so maybe he ended up not doing it. We used to do that on Cell to "context switch" the local memory of the SPU engines between the real SPU and the backing store. It's not very hard to do. The main issue is that the mapping attributes change between cached and non-cached under the hood, so users have to be careful not to do things like use instructions that only work on one type of mapping (or do things like misaligned accesses). > > > 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. > > Probably best would be to first extract some helpers for ttm based vram > dumb buffer management, and then start to implement some of the > improvements so that all drivers can benefit. Like you've said it's not > rocket science, it just needs to be done ;-) Right :-) Though getting ones head around the infrastructure in the DRM does take time :-) There's a lot of stuff in there, between TTM, GEM etc... and not all of it completely "obvious" ... Cheers, Ben. > -Daniel > --