From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Date: Mon, 04 Jan 2016 07:08:14 +0000 Subject: Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko Message-Id: <20160104070814.GC8076@phenom.ffwll.local> List-Id: References: <56828767.4050302@laposte.net> <5682936E.2040904@laposte.net> <5682BA0B.9060001@laposte.net> <5683908C.5040001@ti.com> <5683A48C.80203@laposte.net> <5683B2A0.9090901@ti.com> In-Reply-To: <5683B2A0.9090901@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Tomi Valkeinen Cc: Sebastian Frias , linux-fbdev@vger.kernel.org, =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= , mason , LKML , dri-devel@lists.freedesktop.org, laurent.pinchart@ideasonboard.com, Frans Klaver , Jean-Christophe Plagniol-Villard On Wed, Dec 30, 2015 at 12:32:00PM +0200, Tomi Valkeinen wrote: > > > On 30/12/15 11:31, Sebastian Frias wrote: > > Hi, > > > > On 12/30/2015 09:06 AM, Tomi Valkeinen wrote: > >> > >> Also note that I don't want new fbdev drivers into the mainline kernel. > >> You should implement a DRM based driver instead. > >> > > > > Thanks, is there a porting guide to go from fbdev to DRM? > > I don't think you should "port" the driver from fbdev to DRM, as the > frameworks are just so different. You should implement the driver from > scratch. Of course, the bits of code that actually touch the hardware > can possibly be copied directly. > > Kernel docs contain documentation about DRM, but I don't know if there's > really a "how to write a DRM driver" style documentation. There's an > active mailing list and irc channel, though. Laurent Pinchart has a presentation which gives a good overview over drm for display drivers: https://www.youtube.com/watch?v=5uHMpjz68HE DRM docs are at http://dri.freedesktop.org/docs/drm/ (this version is using asciidoc for more pretties, but you can also build it locally with make htmldocs and then look at it in Documentation/DocBook/drm/index.html). > > Does DRM provides a "fbdev" backward compatible API? Would that be > > feasible? > > DRM provides an fbdev "emulation". I think it's mainly aimed at > providing fb console, but many fbdev applications should work fine on > top of it. Modeset side should be full featured out of the box (i.e. you can change modes), drivers have the option to overallocate (to allow the fake page flipping using set_par) and adding 2d accel is possible. > > I did not find much about that. > > > > Currently our stack is something like: > > > > Qt -> eglfs -> Mali -> fbdev -> mem -> output > > (HW) (HW) > > > > We don't control the eglfs/Mali (GPU) part. > > From what I could see, Mali uses DRM with X11 which we do not need > > (note: I'm not a Mali expert and just took a quick look at the code so I > > may be wrong), which could be a problem. > > I'm not familiar with Mali, so I have no idea. > > > If "implement a DRM driver" is a lot of work, it would end up as a > > business decision and probably would not happen. > > True. It's, of course, up to you. If the fbdev driver works fine for you > and provides all the features, and you're happy with it, and there's no > requirement to get the driver to the mainline Linux, there's not much > point in going for a DRM driver. > > > Would you say there are good solid arguments to shake our current stack > > (other than for dusting it off)? > > Fbdev is the legacy framework, hopefully deprecated at some point, and > DRM is the current display framework. So DRM has much more features, is > actively developed, has a community that may help you with your issues, etc. > > From purely technical point of view, it depends on the hardware in > question. If the HW supports hardware overlays and multiple outputs, DRM > supports those fully, whereas fbdev does not. > > I'm not that familiar with the 3D side, but I think that can be > implemented properly with DRM, whereas on fbdev supporting 3D is always > more or less a hack. > > > By the way, does DRM improves 2D acceleration support over fbdev? > > I don't know enough about 2D acceleration to answer that. We've tried in-kernel accel of 2d fbdev ops in i915 and realized it's too much work and pretty pointless. But it's definitely possible to do that, on top of the provided fbdev emulation (e.g. gma500 has some scrolling accel tricks). Otherwise same as 3D really, using the split kernel/userspace driver approach. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko Date: Mon, 4 Jan 2016 08:08:14 +0100 Message-ID: <20160104070814.GC8076@phenom.ffwll.local> References: <56828767.4050302@laposte.net> <5682936E.2040904@laposte.net> <5682BA0B.9060001@laposte.net> <5683908C.5040001@ti.com> <5683A48C.80203@laposte.net> <5683B2A0.9090901@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2C5ED89895 for ; Sun, 3 Jan 2016 23:08:18 -0800 (PST) Received: by mail-wm0-f51.google.com with SMTP id l65so151955844wmf.1 for ; Sun, 03 Jan 2016 23:08:18 -0800 (PST) Content-Disposition: inline In-Reply-To: <5683B2A0.9090901@ti.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Tomi Valkeinen Cc: Sebastian Frias , linux-fbdev@vger.kernel.org, =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= , mason , LKML , dri-devel@lists.freedesktop.org, laurent.pinchart@ideasonboard.com, Frans Klaver , Jean-Christophe Plagniol-Villard List-Id: dri-devel@lists.freedesktop.org T24gV2VkLCBEZWMgMzAsIDIwMTUgYXQgMTI6MzI6MDBQTSArMDIwMCwgVG9taSBWYWxrZWluZW4g d3JvdGU6Cj4gCj4gCj4gT24gMzAvMTIvMTUgMTE6MzEsIFNlYmFzdGlhbiBGcmlhcyB3cm90ZToK PiA+IEhpLAo+ID4gCj4gPiBPbiAxMi8zMC8yMDE1IDA5OjA2IEFNLCBUb21pIFZhbGtlaW5lbiB3 cm90ZToKPiA+Pgo+ID4+IEFsc28gbm90ZSB0aGF0IEkgZG9uJ3Qgd2FudCBuZXcgZmJkZXYgZHJp dmVycyBpbnRvIHRoZSBtYWlubGluZSBrZXJuZWwuCj4gPj4gWW91IHNob3VsZCBpbXBsZW1lbnQg YSBEUk0gYmFzZWQgZHJpdmVyIGluc3RlYWQuCj4gPj4KPiA+IAo+ID4gVGhhbmtzLCBpcyB0aGVy ZSBhIHBvcnRpbmcgZ3VpZGUgdG8gZ28gZnJvbSBmYmRldiB0byBEUk0/Cj4gCj4gSSBkb24ndCB0 aGluayB5b3Ugc2hvdWxkICJwb3J0IiB0aGUgZHJpdmVyIGZyb20gZmJkZXYgdG8gRFJNLCBhcyB0 aGUKPiBmcmFtZXdvcmtzIGFyZSBqdXN0IHNvIGRpZmZlcmVudC4gWW91IHNob3VsZCBpbXBsZW1l bnQgdGhlIGRyaXZlciBmcm9tCj4gc2NyYXRjaC4gT2YgY291cnNlLCB0aGUgYml0cyBvZiBjb2Rl IHRoYXQgYWN0dWFsbHkgdG91Y2ggdGhlIGhhcmR3YXJlCj4gY2FuIHBvc3NpYmx5IGJlIGNvcGll ZCBkaXJlY3RseS4KPiAKPiBLZXJuZWwgZG9jcyBjb250YWluIGRvY3VtZW50YXRpb24gYWJvdXQg RFJNLCBidXQgSSBkb24ndCBrbm93IGlmIHRoZXJlJ3MKPiByZWFsbHkgYSAiaG93IHRvIHdyaXRl IGEgRFJNIGRyaXZlciIgc3R5bGUgZG9jdW1lbnRhdGlvbi4gVGhlcmUncyBhbgo+IGFjdGl2ZSBt YWlsaW5nIGxpc3QgYW5kIGlyYyBjaGFubmVsLCB0aG91Z2guCgpMYXVyZW50IFBpbmNoYXJ0IGhh cyBhIHByZXNlbnRhdGlvbiB3aGljaCBnaXZlcyBhIGdvb2Qgb3ZlcnZpZXcgb3ZlciBkcm0KZm9y IGRpc3BsYXkgZHJpdmVyczoKCmh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9NXVITXBq ejY4SEUKCkRSTSBkb2NzIGFyZSBhdCBodHRwOi8vZHJpLmZyZWVkZXNrdG9wLm9yZy9kb2NzL2Ry bS8gKHRoaXMgdmVyc2lvbiBpcwp1c2luZyBhc2NpaWRvYyBmb3IgbW9yZSBwcmV0dGllcywgYnV0 IHlvdSBjYW4gYWxzbyBidWlsZCBpdCBsb2NhbGx5IHdpdGgKbWFrZSBodG1sZG9jcyBhbmQgdGhl biBsb29rIGF0IGl0IGluCkRvY3VtZW50YXRpb24vRG9jQm9vay9kcm0vaW5kZXguaHRtbCkuCgo+ ID4gRG9lcyBEUk0gcHJvdmlkZXMgYSAiZmJkZXYiIGJhY2t3YXJkIGNvbXBhdGlibGUgQVBJPyBX b3VsZCB0aGF0IGJlCj4gPiBmZWFzaWJsZT8KPiAKPiBEUk0gcHJvdmlkZXMgYW4gZmJkZXYgImVt dWxhdGlvbiIuIEkgdGhpbmsgaXQncyBtYWlubHkgYWltZWQgYXQKPiBwcm92aWRpbmcgZmIgY29u c29sZSwgYnV0IG1hbnkgZmJkZXYgYXBwbGljYXRpb25zIHNob3VsZCB3b3JrIGZpbmUgb24KPiB0 b3Agb2YgaXQuCgpNb2Rlc2V0IHNpZGUgc2hvdWxkIGJlIGZ1bGwgZmVhdHVyZWQgb3V0IG9mIHRo ZSBib3ggKGkuZS4geW91IGNhbiBjaGFuZ2UKbW9kZXMpLCBkcml2ZXJzIGhhdmUgdGhlIG9wdGlv biB0byBvdmVyYWxsb2NhdGUgKHRvIGFsbG93IHRoZSBmYWtlIHBhZ2UKZmxpcHBpbmcgdXNpbmcg c2V0X3BhcikgYW5kIGFkZGluZyAyZCBhY2NlbCBpcyBwb3NzaWJsZS4KCj4gPiBJIGRpZCBub3Qg ZmluZCBtdWNoIGFib3V0IHRoYXQuCj4gPiAKPiA+IEN1cnJlbnRseSBvdXIgc3RhY2sgaXMgc29t ZXRoaW5nIGxpa2U6Cj4gPiAKPiA+ICAgIFF0IC0+IGVnbGZzIC0+IE1hbGkgLT4gZmJkZXYgLT4g bWVtIC0+IG91dHB1dAo+ID4gICAgICAgICAgICAgICAgICAgKEhXKSAgICAgICAgICAgICAgICAg ICAgIChIVykKPiA+IAo+ID4gV2UgZG9uJ3QgY29udHJvbCB0aGUgZWdsZnMvTWFsaSAoR1BVKSBw YXJ0Lgo+ID4gRnJvbSB3aGF0IEkgY291bGQgc2VlLCBNYWxpIHVzZXMgRFJNIHdpdGggWDExIHdo aWNoIHdlIGRvIG5vdCBuZWVkCj4gPiAobm90ZTogSSdtIG5vdCBhIE1hbGkgZXhwZXJ0IGFuZCBq dXN0IHRvb2sgYSBxdWljayBsb29rIGF0IHRoZSBjb2RlIHNvIEkKPiA+IG1heSBiZSB3cm9uZyks IHdoaWNoIGNvdWxkIGJlIGEgcHJvYmxlbS4KPiAKPiBJJ20gbm90IGZhbWlsaWFyIHdpdGggTWFs aSwgc28gSSBoYXZlIG5vIGlkZWEuCj4gCj4gPiBJZiAiaW1wbGVtZW50IGEgRFJNIGRyaXZlciIg aXMgYSBsb3Qgb2Ygd29yaywgaXQgd291bGQgZW5kIHVwIGFzIGEKPiA+IGJ1c2luZXNzIGRlY2lz aW9uIGFuZCBwcm9iYWJseSB3b3VsZCBub3QgaGFwcGVuLgo+IAo+IFRydWUuIEl0J3MsIG9mIGNv dXJzZSwgdXAgdG8geW91LiBJZiB0aGUgZmJkZXYgZHJpdmVyIHdvcmtzIGZpbmUgZm9yIHlvdQo+ IGFuZCBwcm92aWRlcyBhbGwgdGhlIGZlYXR1cmVzLCBhbmQgeW91J3JlIGhhcHB5IHdpdGggaXQs IGFuZCB0aGVyZSdzIG5vCj4gcmVxdWlyZW1lbnQgdG8gZ2V0IHRoZSBkcml2ZXIgdG8gdGhlIG1h aW5saW5lIExpbnV4LCB0aGVyZSdzIG5vdCBtdWNoCj4gcG9pbnQgaW4gZ29pbmcgZm9yIGEgRFJN IGRyaXZlci4KPiAKPiA+IFdvdWxkIHlvdSBzYXkgdGhlcmUgYXJlIGdvb2Qgc29saWQgYXJndW1l bnRzIHRvIHNoYWtlIG91ciBjdXJyZW50IHN0YWNrCj4gPiAob3RoZXIgdGhhbiBmb3IgZHVzdGlu ZyBpdCBvZmYpPwo+IAo+IEZiZGV2IGlzIHRoZSBsZWdhY3kgZnJhbWV3b3JrLCBob3BlZnVsbHkg ZGVwcmVjYXRlZCBhdCBzb21lIHBvaW50LCBhbmQKPiBEUk0gaXMgdGhlIGN1cnJlbnQgZGlzcGxh eSBmcmFtZXdvcmsuIFNvIERSTSBoYXMgbXVjaCBtb3JlIGZlYXR1cmVzLCBpcwo+IGFjdGl2ZWx5 IGRldmVsb3BlZCwgaGFzIGEgY29tbXVuaXR5IHRoYXQgbWF5IGhlbHAgeW91IHdpdGggeW91ciBp c3N1ZXMsIGV0Yy4KPiAKPiBGcm9tIHB1cmVseSB0ZWNobmljYWwgcG9pbnQgb2YgdmlldywgaXQg ZGVwZW5kcyBvbiB0aGUgaGFyZHdhcmUgaW4KPiBxdWVzdGlvbi4gSWYgdGhlIEhXIHN1cHBvcnRz IGhhcmR3YXJlIG92ZXJsYXlzIGFuZCBtdWx0aXBsZSBvdXRwdXRzLCBEUk0KPiBzdXBwb3J0cyB0 aG9zZSBmdWxseSwgd2hlcmVhcyBmYmRldiBkb2VzIG5vdC4KPiAKPiBJJ20gbm90IHRoYXQgZmFt aWxpYXIgd2l0aCB0aGUgM0Qgc2lkZSwgYnV0IEkgdGhpbmsgdGhhdCBjYW4gYmUKPiBpbXBsZW1l bnRlZCBwcm9wZXJseSB3aXRoIERSTSwgd2hlcmVhcyBvbiBmYmRldiBzdXBwb3J0aW5nIDNEIGlz IGFsd2F5cwo+IG1vcmUgb3IgbGVzcyBhIGhhY2suCj4gCj4gPiBCeSB0aGUgd2F5LCBkb2VzIERS TSBpbXByb3ZlcyAyRCBhY2NlbGVyYXRpb24gc3VwcG9ydCBvdmVyIGZiZGV2Pwo+IAo+IEkgZG9u J3Qga25vdyBlbm91Z2ggYWJvdXQgMkQgYWNjZWxlcmF0aW9uIHRvIGFuc3dlciB0aGF0LgoKV2Un dmUgdHJpZWQgaW4ta2VybmVsIGFjY2VsIG9mIDJkIGZiZGV2IG9wcyBpbiBpOTE1IGFuZCByZWFs aXplZCBpdCdzIHRvbwptdWNoIHdvcmsgYW5kIHByZXR0eSBwb2ludGxlc3MuIEJ1dCBpdCdzIGRl ZmluaXRlbHkgcG9zc2libGUgdG8gZG8gdGhhdCwKb24gdG9wIG9mIHRoZSBwcm92aWRlZCBmYmRl diBlbXVsYXRpb24gKGUuZy4gZ21hNTAwIGhhcyBzb21lIHNjcm9sbGluZwphY2NlbCB0cmlja3Mp LiBPdGhlcndpc2Ugc2FtZSBhcyAzRCByZWFsbHksIHVzaW5nIHRoZSBzcGxpdAprZXJuZWwvdXNl cnNwYWNlIGRyaXZlciBhcHByb2FjaC4KCkNoZWVycywgRGFuaWVsCi0tIApEYW5pZWwgVmV0dGVy ClNvZnR3YXJlIEVuZ2luZWVyLCBJbnRlbCBDb3Jwb3JhdGlvbgpodHRwOi8vYmxvZy5mZndsbC5j aApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2 ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xp c3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752874AbcADHJI (ORCPT ); Mon, 4 Jan 2016 02:09:08 -0500 Received: from mail-wm0-f53.google.com ([74.125.82.53]:38609 "EHLO mail-wm0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752524AbcADHIS (ORCPT ); Mon, 4 Jan 2016 02:08:18 -0500 Date: Mon, 4 Jan 2016 08:08:14 +0100 From: Daniel Vetter To: Tomi Valkeinen Cc: Sebastian Frias , linux-fbdev@vger.kernel.org, =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= , mason , LKML , dri-devel@lists.freedesktop.org, laurent.pinchart@ideasonboard.com, Frans Klaver , Jean-Christophe Plagniol-Villard Subject: Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko Message-ID: <20160104070814.GC8076@phenom.ffwll.local> Mail-Followup-To: Tomi Valkeinen , Sebastian Frias , linux-fbdev@vger.kernel.org, =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= , mason , LKML , dri-devel@lists.freedesktop.org, laurent.pinchart@ideasonboard.com, Frans Klaver , Jean-Christophe Plagniol-Villard References: <56828767.4050302@laposte.net> <5682936E.2040904@laposte.net> <5682BA0B.9060001@laposte.net> <5683908C.5040001@ti.com> <5683A48C.80203@laposte.net> <5683B2A0.9090901@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5683B2A0.9090901@ti.com> X-Operating-System: Linux phenom 4.3.0-1-amd64 User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 30, 2015 at 12:32:00PM +0200, Tomi Valkeinen wrote: > > > On 30/12/15 11:31, Sebastian Frias wrote: > > Hi, > > > > On 12/30/2015 09:06 AM, Tomi Valkeinen wrote: > >> > >> Also note that I don't want new fbdev drivers into the mainline kernel. > >> You should implement a DRM based driver instead. > >> > > > > Thanks, is there a porting guide to go from fbdev to DRM? > > I don't think you should "port" the driver from fbdev to DRM, as the > frameworks are just so different. You should implement the driver from > scratch. Of course, the bits of code that actually touch the hardware > can possibly be copied directly. > > Kernel docs contain documentation about DRM, but I don't know if there's > really a "how to write a DRM driver" style documentation. There's an > active mailing list and irc channel, though. Laurent Pinchart has a presentation which gives a good overview over drm for display drivers: https://www.youtube.com/watch?v=5uHMpjz68HE DRM docs are at http://dri.freedesktop.org/docs/drm/ (this version is using asciidoc for more pretties, but you can also build it locally with make htmldocs and then look at it in Documentation/DocBook/drm/index.html). > > Does DRM provides a "fbdev" backward compatible API? Would that be > > feasible? > > DRM provides an fbdev "emulation". I think it's mainly aimed at > providing fb console, but many fbdev applications should work fine on > top of it. Modeset side should be full featured out of the box (i.e. you can change modes), drivers have the option to overallocate (to allow the fake page flipping using set_par) and adding 2d accel is possible. > > I did not find much about that. > > > > Currently our stack is something like: > > > > Qt -> eglfs -> Mali -> fbdev -> mem -> output > > (HW) (HW) > > > > We don't control the eglfs/Mali (GPU) part. > > From what I could see, Mali uses DRM with X11 which we do not need > > (note: I'm not a Mali expert and just took a quick look at the code so I > > may be wrong), which could be a problem. > > I'm not familiar with Mali, so I have no idea. > > > If "implement a DRM driver" is a lot of work, it would end up as a > > business decision and probably would not happen. > > True. It's, of course, up to you. If the fbdev driver works fine for you > and provides all the features, and you're happy with it, and there's no > requirement to get the driver to the mainline Linux, there's not much > point in going for a DRM driver. > > > Would you say there are good solid arguments to shake our current stack > > (other than for dusting it off)? > > Fbdev is the legacy framework, hopefully deprecated at some point, and > DRM is the current display framework. So DRM has much more features, is > actively developed, has a community that may help you with your issues, etc. > > From purely technical point of view, it depends on the hardware in > question. If the HW supports hardware overlays and multiple outputs, DRM > supports those fully, whereas fbdev does not. > > I'm not that familiar with the 3D side, but I think that can be > implemented properly with DRM, whereas on fbdev supporting 3D is always > more or less a hack. > > > By the way, does DRM improves 2D acceleration support over fbdev? > > I don't know enough about 2D acceleration to answer that. We've tried in-kernel accel of 2d fbdev ops in i915 and realized it's too much work and pretty pointless. But it's definitely possible to do that, on top of the provided fbdev emulation (e.g. gma500 has some scrolling accel tricks). Otherwise same as 3D really, using the split kernel/userspace driver approach. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch