From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Date: Thu, 08 Dec 2016 21:34:37 +0000 Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers Message-Id: <1481232877.26959.52.camel@kernel.crashing.org> List-Id: References: <1479888193-23908-1-git-send-email-tomi.valkeinen@ti.com> <1481158879.26959.41.camel@kernel.crashing.org> <20161208101005.6ufl3d4qvwprosju@phenom.ffwll.local> <20161208140210.rfyjf2265flsfpfj@phenom.ffwll.local> <20161208153735.74d7d350@free-electrons.com> <20161208152134.wnv4j4i6m5xpoycp@phenom.ffwll.local> In-Reply-To: <20161208152134.wnv4j4i6m5xpoycp@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Daniel Vetter , Geert Uytterhoeven Cc: Thomas Petazzoni , Linux Fbdev development list , Teddy Wang , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , DRI Development , Tomi Valkeinen , Sudip Mukherjee , Arnaud Patard On Thu, 2016-12-08 at 16:21 +0100, Daniel Vetter wrote: > Yeah, small drivers like these we have piles now, things exploded a lot > after atomic landed two years ago. And they seem to shrink with every > release a bit more (since lots more drivers gives you lots more insight > into what other refactorings would make sense). Those we have a big pile > of, and nowadays (at least with developers expirienced with upstream, but > not necessarily with drm) it takes but a few weeks from initial submission > to getting them merged. > > What we don't yet have a nice tidy example driver of is the even simpler > "dumb framebuffer behind a slow bus with explicit/manual upload", for like > small i2c/spi panels (and conceptually also usb, even though there bw and > panel size are a bit scaled up). We've gained some really nice helpers for > this this year, and there's 3 drivers in-flight to make use of it. But > since that's right now just a hobbyist effort it's moving a bit slower > (and I was mistaken a few weeks back where I assumed that one of them > landed already). What I find usually confusing is the interaction with the TTM and overall fb memory management, when trying to plumb in simple 2d accel to speed up fbcon mostly (but I don't mind making it available to user space via ioctls, though that's not a priority). As I mentioned earlier, probably 1 or 2 years ago, Dave made the argument that shadowing through memory was necessary and precluded 2D accel, though I don't fully remember the root of the argument. If that is indeed not the case, then my main objection is lifted. Cheers, Ben. 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 08:34:37 +1100 Message-ID: <1481232877.26959.52.camel@kernel.crashing.org> References: <1479888193-23908-1-git-send-email-tomi.valkeinen@ti.com> <1481158879.26959.41.camel@kernel.crashing.org> <20161208101005.6ufl3d4qvwprosju@phenom.ffwll.local> <20161208140210.rfyjf2265flsfpfj@phenom.ffwll.local> <20161208153735.74d7d350@free-electrons.com> <20161208152134.wnv4j4i6m5xpoycp@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 07CFC6E865 for ; Thu, 8 Dec 2016 21:35:05 +0000 (UTC) In-Reply-To: <20161208152134.wnv4j4i6m5xpoycp@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 Cc: Thomas Petazzoni , Linux Fbdev development list , Teddy Wang , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , DRI Development , Tomi Valkeinen , Sudip Mukherjee , Arnaud Patard List-Id: dri-devel@lists.freedesktop.org T24gVGh1LCAyMDE2LTEyLTA4IGF0IDE2OjIxICswMTAwLCBEYW5pZWwgVmV0dGVyIHdyb3RlOgo+ IFllYWgsIHNtYWxsIGRyaXZlcnMgbGlrZSB0aGVzZSB3ZSBoYXZlIHBpbGVzIG5vdywgdGhpbmdz IGV4cGxvZGVkIGEgbG90Cj4gYWZ0ZXIgYXRvbWljIGxhbmRlZCB0d28geWVhcnMgYWdvLiBBbmQg dGhleSBzZWVtIHRvIHNocmluayB3aXRoIGV2ZXJ5Cj4gcmVsZWFzZSBhIGJpdCBtb3JlIChzaW5j ZSBsb3RzIG1vcmUgZHJpdmVycyBnaXZlcyB5b3UgbG90cyBtb3JlIGluc2lnaHQKPiBpbnRvIHdo YXQgb3RoZXIgcmVmYWN0b3JpbmdzIHdvdWxkIG1ha2Ugc2Vuc2UpLiBUaG9zZSB3ZSBoYXZlIGEg YmlnIHBpbGUKPiBvZiwgYW5kIG5vd2FkYXlzIChhdCBsZWFzdCB3aXRoIGRldmVsb3BlcnMgZXhw aXJpZW5jZWQgd2l0aCB1cHN0cmVhbSwgYnV0Cj4gbm90IG5lY2Vzc2FyaWx5IHdpdGggZHJtKSBp dCB0YWtlcyBidXQgYSBmZXcgd2Vla3MgZnJvbSBpbml0aWFsIHN1Ym1pc3Npb24KPiB0byBnZXR0 aW5nIHRoZW0gbWVyZ2VkLgo+IAo+IFdoYXQgd2UgZG9uJ3QgeWV0IGhhdmUgYSBuaWNlIHRpZHkg ZXhhbXBsZSBkcml2ZXIgb2YgaXMgdGhlIGV2ZW4gc2ltcGxlcgo+ICJkdW1iIGZyYW1lYnVmZmVy IGJlaGluZCBhIHNsb3cgYnVzIHdpdGggZXhwbGljaXQvbWFudWFsIHVwbG9hZCIsIGZvciBsaWtl Cj4gc21hbGwgaTJjL3NwaSBwYW5lbHMgKGFuZCBjb25jZXB0dWFsbHkgYWxzbyB1c2IsIGV2ZW4g dGhvdWdoIHRoZXJlIGJ3IGFuZAo+IHBhbmVsIHNpemUgYXJlIGEgYml0IHNjYWxlZCB1cCkuIFdl J3ZlIGdhaW5lZCBzb21lIHJlYWxseSBuaWNlIGhlbHBlcnMgZm9yCj4gdGhpcyB0aGlzIHllYXIs IGFuZCB0aGVyZSdzIDMgZHJpdmVycyBpbi1mbGlnaHQgdG8gbWFrZSB1c2Ugb2YgaXQuIEJ1dAo+ IHNpbmNlIHRoYXQncyByaWdodCBub3cganVzdCBhIGhvYmJ5aXN0IGVmZm9ydCBpdCdzIG1vdmlu ZyBhIGJpdCBzbG93ZXIKPiAoYW5kIEkgd2FzIG1pc3Rha2VuIGEgZmV3IHdlZWtzIGJhY2sgd2hl cmUgSSBhc3N1bWVkIHRoYXQgb25lIG9mIHRoZW0KPiBsYW5kZWQgYWxyZWFkeSkuCgpXaGF0IEkg ZmluZCB1c3VhbGx5IGNvbmZ1c2luZyBpcyB0aGUgaW50ZXJhY3Rpb24gd2l0aCB0aGUgVFRNIGFu ZApvdmVyYWxsIGZiIG1lbW9yeSBtYW5hZ2VtZW50LCB3aGVuIHRyeWluZyB0byBwbHVtYiBpbiBz aW1wbGUgMmQgYWNjZWwKdG8gc3BlZWQgdXAgZmJjb24gbW9zdGx5IChidXQgSSBkb24ndCBtaW5k IG1ha2luZyBpdCBhdmFpbGFibGUgdG8gdXNlcgpzcGFjZSB2aWEgaW9jdGxzLCB0aG91Z2ggdGhh dCdzIG5vdCBhIHByaW9yaXR5KS4KCkFzIEkgbWVudGlvbmVkIGVhcmxpZXIsIHByb2JhYmx5IDEg b3IgMiB5ZWFycyBhZ28sIERhdmUgbWFkZSB0aGUKYXJndW1lbnQgdGhhdCBzaGFkb3dpbmcgdGhy b3VnaCBtZW1vcnkgd2FzIG5lY2Vzc2FyeSBhbmQgcHJlY2x1ZGVkIDJECmFjY2VsLCB0aG91Z2gg SSBkb24ndCBmdWxseSByZW1lbWJlciB0aGUgcm9vdCBvZiB0aGUgYXJndW1lbnQuIElmIHRoYXQK aXMgaW5kZWVkIG5vdCB0aGUgY2FzZSwgdGhlbiBteSBtYWluIG9iamVjdGlvbiBpcyBsaWZ0ZWQu CgpDaGVlcnMsCkJlbi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9w Lm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1k ZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753363AbcLHVfd (ORCPT ); Thu, 8 Dec 2016 16:35:33 -0500 Received: from gate.crashing.org ([63.228.1.57]:32897 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752136AbcLHVfc (ORCPT ); Thu, 8 Dec 2016 16:35:32 -0500 Message-ID: <1481232877.26959.52.camel@kernel.crashing.org> Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers From: Benjamin Herrenschmidt To: Daniel Vetter , Geert Uytterhoeven Cc: 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 08:34:37 +1100 In-Reply-To: <20161208152134.wnv4j4i6m5xpoycp@phenom.ffwll.local> References: <1479888193-23908-1-git-send-email-tomi.valkeinen@ti.com> <1481158879.26959.41.camel@kernel.crashing.org> <20161208101005.6ufl3d4qvwprosju@phenom.ffwll.local> <20161208140210.rfyjf2265flsfpfj@phenom.ffwll.local> <20161208153735.74d7d350@free-electrons.com> <20161208152134.wnv4j4i6m5xpoycp@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: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2016-12-08 at 16:21 +0100, Daniel Vetter wrote: > Yeah, small drivers like these we have piles now, things exploded a lot > after atomic landed two years ago. And they seem to shrink with every > release a bit more (since lots more drivers gives you lots more insight > into what other refactorings would make sense). Those we have a big pile > of, and nowadays (at least with developers expirienced with upstream, but > not necessarily with drm) it takes but a few weeks from initial submission > to getting them merged. > > What we don't yet have a nice tidy example driver of is the even simpler > "dumb framebuffer behind a slow bus with explicit/manual upload", for like > small i2c/spi panels (and conceptually also usb, even though there bw and > panel size are a bit scaled up). We've gained some really nice helpers for > this this year, and there's 3 drivers in-flight to make use of it. But > since that's right now just a hobbyist effort it's moving a bit slower > (and I was mistaken a few weeks back where I assumed that one of them > landed already). What I find usually confusing is the interaction with the TTM and overall fb memory management, when trying to plumb in simple 2d accel to speed up fbcon mostly (but I don't mind making it available to user space via ioctls, though that's not a priority). As I mentioned earlier, probably 1 or 2 years ago, Dave made the argument that shadowing through memory was necessary and precluded 2D accel, though I don't fully remember the root of the argument. If that is indeed not the case, then my main objection is lifted. Cheers, Ben.