From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Date: Tue, 13 Dec 2016 15:17:40 +0000 Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers Message-Id: <36161238.SskTX730U1@avalon> 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> In-Reply-To: <20161208101005.6ufl3d4qvwprosju@phenom.ffwll.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: dri-devel@lists.freedesktop.org Cc: Thomas Petazzoni , linux-fbdev@vger.kernel.org, Teddy Wang , linux-kernel@vger.kernel.org, Tomi Valkeinen , Greg Kroah-Hartman , Sudip Mukherjee , Arnaud Patard Hi Daniel, On Thursday 08 Dec 2016 11:10:05 Daniel Vetter wrote: > On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote: > > On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote: > > > Hi, > > > > > > Since the fbdev framework is in maintenance mode and all new display > > > drivers should be made with the DRM framework, remove the fbdev drivers > > > from staging. > > > > > > Note: the patches are created with git format-patch -D, so they can't be > > > applied. Only for review. > > > > I missed the discussion where this decision was made, I admit I am > > unimpressed by it. > > > > DRM drivers don't strike me as suitable for small/slow cores with dumb > > framebuffers or simple 2D only accel, such as the one found in the ASpeed > > BMCs. > > We have a helper for simple drivers now, if you take into account the > massive helper libraries for everything that comes along with drm I expect > if even dumb panels behind slow spi buses drm is now the more suitable > subsytem. > > > With drmfb you basically have to shadow everything into memory & copy > > over everything, and locks you out of simple 2D accel. For a simple text > > console the result is orders of magnitude slower and memory hungry than > > a simple fbdev. > > Not true, we have full fbdev emulation, and drivers can implement the 2d > accel in there. And a bunch of them do. It's just that most teams decided > that this is pointless waste of their time.j And I'd argue that a better use of time would be to implement an accelerated console that does not use fbdev at all. > > At least that was the case last I looked at the DRM stuff with Dave, > > maybe things have changed... > > > > Not everything has a powerful 3D GPU. > > That's correct, and drm can cope. And compared to fbdev there's a very > active community who improves&refactors it every kernel release to make it > even better. Since about 2 years (when atomic landed) we merge new drivers > at a rate of 2-3 per kernel release, and those new drivers get ever simpler > and smaller thanks to all this work. -- Regards, Laurent Pinchart From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers Date: Tue, 13 Dec 2016 17:17:40 +0200 Message-ID: <36161238.SskTX730U1@avalon> References: <1479888193-23908-1-git-send-email-tomi.valkeinen@ti.com> <1481158879.26959.41.camel@kernel.crashing.org> <20161208101005.6ufl3d4qvwprosju@phenom.ffwll.local> 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 [IPv6:2001:4b98:dc2:45:216:3eff:febb:480d]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9702F6E5BD for ; Tue, 13 Dec 2016 15:17:08 +0000 (UTC) In-Reply-To: <20161208101005.6ufl3d4qvwprosju@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: dri-devel@lists.freedesktop.org Cc: Thomas Petazzoni , linux-fbdev@vger.kernel.org, Teddy Wang , linux-kernel@vger.kernel.org, Tomi Valkeinen , Greg Kroah-Hartman , Sudip Mukherjee , Arnaud Patard List-Id: dri-devel@lists.freedesktop.org SGkgRGFuaWVsLAoKT24gVGh1cnNkYXkgMDggRGVjIDIwMTYgMTE6MTA6MDUgRGFuaWVsIFZldHRl ciB3cm90ZToKPiBPbiBUaHUsIERlYyAwOCwgMjAxNiBhdCAxMjowMToxOVBNICsxMTAwLCBCZW5q YW1pbiBIZXJyZW5zY2htaWR0IHdyb3RlOgo+ID4gT24gV2VkLCAyMDE2LTExLTIzIGF0IDEwOjAz ICswMjAwLCBUb21pIFZhbGtlaW5lbiB3cm90ZToKPiA+ID4gSGksCj4gPiA+IAo+ID4gPiBTaW5j ZSB0aGUgZmJkZXYgZnJhbWV3b3JrIGlzIGluIG1haW50ZW5hbmNlIG1vZGUgYW5kIGFsbCBuZXcg ZGlzcGxheQo+ID4gPiBkcml2ZXJzIHNob3VsZCBiZSBtYWRlIHdpdGggdGhlIERSTSBmcmFtZXdv cmssIHJlbW92ZSB0aGUgZmJkZXYgZHJpdmVycwo+ID4gPiBmcm9tIHN0YWdpbmcuCj4gPiA+IAo+ ID4gPiBOb3RlOiB0aGUgcGF0Y2hlcyBhcmUgY3JlYXRlZCB3aXRoIGdpdCBmb3JtYXQtcGF0Y2gg LUQsIHNvIHRoZXkgY2FuJ3QgYmUKPiA+ID4gYXBwbGllZC4gT25seSBmb3IgcmV2aWV3Lgo+ID4g Cj4gPiBJIG1pc3NlZCB0aGUgZGlzY3Vzc2lvbiB3aGVyZSB0aGlzIGRlY2lzaW9uIHdhcyBtYWRl LCBJIGFkbWl0IEkgYW0KPiA+IHVuaW1wcmVzc2VkIGJ5IGl0Lgo+ID4gCj4gPiBEUk0gZHJpdmVy cyBkb24ndCBzdHJpa2UgbWUgYXMgc3VpdGFibGUgZm9yIHNtYWxsL3Nsb3cgY29yZXMgd2l0aCBk dW1iCj4gPiBmcmFtZWJ1ZmZlcnMgb3Igc2ltcGxlIDJEIG9ubHkgYWNjZWwsIHN1Y2ggYXMgdGhl IG9uZSBmb3VuZCBpbiB0aGUgQVNwZWVkCj4gPiBCTUNzLgo+IAo+IFdlIGhhdmUgYSBoZWxwZXIg Zm9yIHNpbXBsZSBkcml2ZXJzIG5vdywgaWYgeW91IHRha2UgaW50byBhY2NvdW50IHRoZQo+IG1h c3NpdmUgaGVscGVyIGxpYnJhcmllcyBmb3IgZXZlcnl0aGluZyB0aGF0IGNvbWVzIGFsb25nIHdp dGggZHJtIEkgZXhwZWN0Cj4gaWYgZXZlbiBkdW1iIHBhbmVscyBiZWhpbmQgc2xvdyBzcGkgYnVz ZXMgZHJtIGlzIG5vdyB0aGUgbW9yZSBzdWl0YWJsZQo+IHN1YnN5dGVtLgo+IAo+ID4gV2l0aCBk cm1mYiB5b3UgYmFzaWNhbGx5IGhhdmUgdG8gc2hhZG93IGV2ZXJ5dGhpbmcgaW50byBtZW1vcnkg JiBjb3B5Cj4gPiBvdmVyIGV2ZXJ5dGhpbmcsIGFuZCBsb2NrcyB5b3Ugb3V0IG9mIHNpbXBsZSAy RCBhY2NlbC4gRm9yIGEgc2ltcGxlIHRleHQKPiA+IGNvbnNvbGUgdGhlIHJlc3VsdCBpcyBvcmRl cnMgb2YgbWFnbml0dWRlIHNsb3dlciBhbmQgbWVtb3J5IGh1bmdyeSB0aGFuCj4gPiBhIHNpbXBs ZSBmYmRldi4KPiAKPiBOb3QgdHJ1ZSwgd2UgaGF2ZSBmdWxsIGZiZGV2IGVtdWxhdGlvbiwgYW5k IGRyaXZlcnMgY2FuIGltcGxlbWVudCB0aGUgMmQKPiBhY2NlbCBpbiB0aGVyZS4gQW5kIGEgYnVu Y2ggb2YgdGhlbSBkby4gSXQncyBqdXN0IHRoYXQgbW9zdCB0ZWFtcyBkZWNpZGVkCj4gdGhhdCB0 aGlzIGlzIHBvaW50bGVzcyB3YXN0ZSBvZiB0aGVpciB0aW1lLmoKCkFuZCBJJ2QgYXJndWUgdGhh dCBhIGJldHRlciB1c2Ugb2YgdGltZSB3b3VsZCBiZSB0byBpbXBsZW1lbnQgYW4gYWNjZWxlcmF0 ZWQgCmNvbnNvbGUgdGhhdCBkb2VzIG5vdCB1c2UgZmJkZXYgYXQgYWxsLgoKPiA+IEF0IGxlYXN0 IHRoYXQgd2FzIHRoZSBjYXNlIGxhc3QgSSBsb29rZWQgYXQgdGhlIERSTSBzdHVmZiB3aXRoIERh dmUsCj4gPiBtYXliZSB0aGluZ3MgaGF2ZSBjaGFuZ2VkLi4uCj4gPiAKPiA+IE5vdCBldmVyeXRo aW5nIGhhcyBhIHBvd2VyZnVsIDNEIEdQVS4KPiAKPiBUaGF0J3MgY29ycmVjdCwgYW5kIGRybSBj YW4gY29wZS4gQW5kIGNvbXBhcmVkIHRvIGZiZGV2IHRoZXJlJ3MgYSB2ZXJ5Cj4gYWN0aXZlIGNv bW11bml0eSB3aG8gaW1wcm92ZXMmcmVmYWN0b3JzIGl0IGV2ZXJ5IGtlcm5lbCByZWxlYXNlIHRv IG1ha2UgaXQKPiBldmVuIGJldHRlci4gU2luY2UgYWJvdXQgMiB5ZWFycyAod2hlbiBhdG9taWMg bGFuZGVkKSB3ZSBtZXJnZSBuZXcgZHJpdmVycwo+IGF0IGEgcmF0ZSBvZiAyLTMgcGVyIGtlcm5l bCByZWxlYXNlLCBhbmQgdGhvc2UgbmV3IGRyaXZlcnMgZ2V0IGV2ZXIgc2ltcGxlcgo+IGFuZCBz bWFsbGVyIHRoYW5rcyB0byBhbGwgdGhpcyB3b3JrLgoKLS0gClJlZ2FyZHMsCgpMYXVyZW50IFBp bmNoYXJ0CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpk cmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0 cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933791AbcLMPRM (ORCPT ); Tue, 13 Dec 2016 10:17:12 -0500 Received: from galahad.ideasonboard.com ([185.26.127.97]:40663 "EHLO galahad.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932346AbcLMPRJ (ORCPT ); Tue, 13 Dec 2016 10:17:09 -0500 From: Laurent Pinchart To: dri-devel@lists.freedesktop.org Cc: Daniel Vetter , Benjamin Herrenschmidt , Thomas Petazzoni , linux-fbdev@vger.kernel.org, Teddy Wang , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Tomi Valkeinen , Sudip Mukherjee , Arnaud Patard Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers Date: Tue, 13 Dec 2016 17:17:40 +0200 Message-ID: <36161238.SskTX730U1@avalon> User-Agent: KMail/4.14.10 (Linux/4.8.6-gentoo; KDE/4.14.24; x86_64; ; ) In-Reply-To: <20161208101005.6ufl3d4qvwprosju@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> 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 Daniel, On Thursday 08 Dec 2016 11:10:05 Daniel Vetter wrote: > On Thu, Dec 08, 2016 at 12:01:19PM +1100, Benjamin Herrenschmidt wrote: > > On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote: > > > Hi, > > > > > > Since the fbdev framework is in maintenance mode and all new display > > > drivers should be made with the DRM framework, remove the fbdev drivers > > > from staging. > > > > > > Note: the patches are created with git format-patch -D, so they can't be > > > applied. Only for review. > > > > I missed the discussion where this decision was made, I admit I am > > unimpressed by it. > > > > DRM drivers don't strike me as suitable for small/slow cores with dumb > > framebuffers or simple 2D only accel, such as the one found in the ASpeed > > BMCs. > > We have a helper for simple drivers now, if you take into account the > massive helper libraries for everything that comes along with drm I expect > if even dumb panels behind slow spi buses drm is now the more suitable > subsytem. > > > With drmfb you basically have to shadow everything into memory & copy > > over everything, and locks you out of simple 2D accel. For a simple text > > console the result is orders of magnitude slower and memory hungry than > > a simple fbdev. > > Not true, we have full fbdev emulation, and drivers can implement the 2d > accel in there. And a bunch of them do. It's just that most teams decided > that this is pointless waste of their time.j And I'd argue that a better use of time would be to implement an accelerated console that does not use fbdev at all. > > At least that was the case last I looked at the DRM stuff with Dave, > > maybe things have changed... > > > > Not everything has a powerful 3D GPU. > > That's correct, and drm can cope. And compared to fbdev there's a very > active community who improves&refactors it every kernel release to make it > even better. Since about 2 years (when atomic landed) we merge new drivers > at a rate of 2-3 per kernel release, and those new drivers get ever simpler > and smaller thanks to all this work. -- Regards, Laurent Pinchart