[RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko

[RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko

[Sebastian Frias]

Hi,

We are wondering what is the recommended way of adding support for a 
framebuffer driver on the Linux kernel.
Below you can find a patch with a proposed solution.

Our frambuffer driver source code is provided separately, but right now 
it requires "cfb_fillrect", "cfb_copyarea" and "cfb_imageblit" to be 
provided by the kernel.

Our current kernel fork (based on 3.4) hardcodes FB_CFB_FILLRECT, 
FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
Since we are in the process of migrating to 4.x and upstreaming changes 
along the way, we would like to know if the patch below is the way to go 
with it or if you have suggestions to improve it.

Thanks in advance,

Sebastian


-- >8 --

Subject: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko

Signed-off-by: Sebastian Frias <sf84@laposte.net>
---
  drivers/video/fbdev/Kconfig |   10 ++++++++++
  1 file changed, 10 insertions(+)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index e6d16d6..46c4ab2 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -615,6 +615,16 @@ config FB_BF537_LQ035
           To compile this driver as a module, choose M here: the
           module will be called bf537-lq035.

+config FB_TANGO
+       bool "Sigma Designs FrameBuffer support"
+       depends on FB && ARCH_TANGO
+       select FB_CFB_FILLRECT
+       select FB_CFB_COPYAREA
+       select FB_CFB_IMAGEBLIT
+       help
+         You need to enable this if you intend to use Sigma
+         Designs' smp8xxxfb.ko driver.
+
  config FB_BFIN_7393
         tristate "Blackfin ADV7393 Video encoder"
         depends on FB && BLACKFIN
-- 
1.7.10.4

Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko

[Frans Klaver]

On Tue, Dec 29, 2015 at 2:15 PM, Sebastian Frias <sf84@laposte.net> wrote:
> Hi,
>
> We are wondering what is the recommended way of adding support for a
> framebuffer driver on the Linux kernel.
> Below you can find a patch with a proposed solution.

That's not really a solution to add a driver to the kernel. You'd have
to include some actual driver code as well.


> Our frambuffer driver source code is provided separately, but right now it
> requires "cfb_fillrect", "cfb_copyarea" and "cfb_imageblit" to be provided
> by the kernel.
>
> Our current kernel fork (based on 3.4) hardcodes FB_CFB_FILLRECT,
> FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
> Since we are in the process of migrating to 4.x and upstreaming changes
> along the way, we would like to know if the patch below is the way to go
> with it or if you have suggestions to improve it.

Is the below patch really a patch you intend to upstream, or are you
just wondering about what your Kconfig entry should look like when you
upstream your driver?


> Subject: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
>
> Signed-off-by: Sebastian Frias <sf84@laposte.net>
> ---
>  drivers/video/fbdev/Kconfig |   10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index e6d16d6..46c4ab2 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -615,6 +615,16 @@ config FB_BF537_LQ035
>           To compile this driver as a module, choose M here: the
>           module will be called bf537-lq035.
>
> +config FB_TANGO
> +       bool "Sigma Designs FrameBuffer support"
> +       depends on FB && ARCH_TANGO
> +       select FB_CFB_FILLRECT
> +       select FB_CFB_COPYAREA
> +       select FB_CFB_IMAGEBLIT
> +       help
> +         You need to enable this if you intend to use Sigma
> +         Designs' smp8xxxfb.ko driver.
> +
>  config FB_BFIN_7393
>         tristate "Blackfin ADV7393 Video encoder"
>         depends on FB && BLACKFIN

Frans

Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko

[Sebastian Frias]

On 12/29/2015 02:49 PM, Frans Klaver wrote:
> On Tue, Dec 29, 2015 at 2:15 PM, Sebastian Frias <sf84@laposte.net> wrote:
>> Hi,
>>
>> We are wondering what is the recommended way of adding support for a
>> framebuffer driver on the Linux kernel.
>> Below you can find a patch with a proposed solution.
>
> That's not really a solution to add a driver to the kernel. You'd have
> to include some actual driver code as well.

We are not attempting to upstream the driver yet, that's why its code is 
not included.

The patch is an attempt to allow the user to enable Framebuffer support 
by providing an option for the user and then setting FB_CFB_FILLRECT, 
FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.

It does the job, but we feel (and you have sort of confirmed it) that it 
may not be a good idea to do it that way.

>
>
>> Our frambuffer driver source code is provided separately, but right now it
>> requires "cfb_fillrect", "cfb_copyarea" and "cfb_imageblit" to be provided
>> by the kernel.
>>
>> Our current kernel fork (based on 3.4) hardcodes FB_CFB_FILLRECT,
>> FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
>> Since we are in the process of migrating to 4.x and upstreaming changes
>> along the way, we would like to know if the patch below is the way to go
>> with it or if you have suggestions to improve it.
>
> Is the below patch really a patch you intend to upstream, or are you
> just wondering about what your Kconfig entry should look like when you
> upstream your driver?

Right now we don't know if the driver will be upstreamed.
Let me rephrase my question:

- how would you recommend enabling FB_CFB_FILLRECT, FB_CFB_COPYAREA and 
FB_CFB_IMAGEBLIT for a driver that is not included in the kernel's tree?

If that is not possible, I guess we will have to keep a forked tree 
until the driver is upstreamed, but we would like to avoid that, hence 
the question.

>
>
>> Subject: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
>>
>> Signed-off-by: Sebastian Frias <sf84@laposte.net>
>> ---
>>   drivers/video/fbdev/Kconfig |   10 ++++++++++
>>   1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
>> index e6d16d6..46c4ab2 100644
>> --- a/drivers/video/fbdev/Kconfig
>> +++ b/drivers/video/fbdev/Kconfig
>> @@ -615,6 +615,16 @@ config FB_BF537_LQ035
>>            To compile this driver as a module, choose M here: the
>>            module will be called bf537-lq035.
>>
>> +config FB_TANGO
>> +       bool "Sigma Designs FrameBuffer support"
>> +       depends on FB && ARCH_TANGO
>> +       select FB_CFB_FILLRECT
>> +       select FB_CFB_COPYAREA
>> +       select FB_CFB_IMAGEBLIT
>> +       help
>> +         You need to enable this if you intend to use Sigma
>> +         Designs' smp8xxxfb.ko driver.
>> +
>>   config FB_BFIN_7393
>>          tristate "Blackfin ADV7393 Video encoder"
>>          depends on FB && BLACKFIN
>
> Frans
>

Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko

[Frans Klaver]

On Tue, Dec 29, 2015 at 3:06 PM, Sebastian Frias <sf84@laposte.net> wrote:
> On 12/29/2015 02:49 PM, Frans Klaver wrote:
>>
>> On Tue, Dec 29, 2015 at 2:15 PM, Sebastian Frias <sf84@laposte.net> wrote:
>>>
>>> Hi,
>>>
>>> We are wondering what is the recommended way of adding support for a
>>> framebuffer driver on the Linux kernel.
>>> Below you can find a patch with a proposed solution.
>>
>>
>> That's not really a solution to add a driver to the kernel. You'd have
>> to include some actual driver code as well.
>
>
> We are not attempting to upstream the driver yet, that's why its code is not
> included.
>
> The patch is an attempt to allow the user to enable Framebuffer support by
> providing an option for the user and then setting FB_CFB_FILLRECT,
> FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
>
> It does the job, but we feel (and you have sort of confirmed it) that it may
> not be a good idea to do it that way.
>
>>
>>
>>> Our frambuffer driver source code is provided separately, but right now
>>> it
>>> requires "cfb_fillrect", "cfb_copyarea" and "cfb_imageblit" to be
>>> provided
>>> by the kernel.
>>>
>>> Our current kernel fork (based on 3.4) hardcodes FB_CFB_FILLRECT,
>>> FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT to yes.
>>> Since we are in the process of migrating to 4.x and upstreaming changes
>>> along the way, we would like to know if the patch below is the way to go
>>> with it or if you have suggestions to improve it.
>>
>>
>> Is the below patch really a patch you intend to upstream, or are you
>> just wondering about what your Kconfig entry should look like when you
>> upstream your driver?
>
>
> Right now we don't know if the driver will be upstreamed.
> Let me rephrase my question:
>
> - how would you recommend enabling FB_CFB_FILLRECT, FB_CFB_COPYAREA and
> FB_CFB_IMAGEBLIT for a driver that is not included in the kernel's tree?
>
> If that is not possible, I guess we will have to keep a forked tree until
> the driver is upstreamed, but we would like to avoid that, hence the
> question.

I guess you'll have to keep on doing that indeed. I'm not aware of any
location where out-of-tree drivers are considered. You should try
again when you have some actual code to upstream.

Cheers,
Frans

Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko

[Sebastian Frias]

On 12/29/2015 03:16 PM, Frans Klaver wrote:
> On Tue, Dec 29, 2015 at 3:06 PM, Sebastian Frias <sf84@laposte.net> wrote:
>> Right now we don't know if the driver will be upstreamed.
>> Let me rephrase my question:
>>
>> - how would you recommend enabling FB_CFB_FILLRECT, FB_CFB_COPYAREA and
>> FB_CFB_IMAGEBLIT for a driver that is not included in the kernel's tree?
>>
>> If that is not possible, I guess we will have to keep a forked tree until
>> the driver is upstreamed, but we would like to avoid that, hence the
>> question.
>
> I guess you'll have to keep on doing that indeed. I'm not aware of any
> location where out-of-tree drivers are considered. You should try
> again when you have some actual code to upstream.
>

Ok, thanks.

Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

Hi,

On 29/12/15 18:51, Sebastian Frias wrote:
> On 12/29/2015 03:16 PM, Frans Klaver wrote:
>> On Tue, Dec 29, 2015 at 3:06 PM, Sebastian Frias <sf84@laposte.net>
>> wrote:
>>> Right now we don't know if the driver will be upstreamed.
>>> Let me rephrase my question:
>>>
>>> - how would you recommend enabling FB_CFB_FILLRECT, FB_CFB_COPYAREA and
>>> FB_CFB_IMAGEBLIT for a driver that is not included in the kernel's tree?
>>>
>>> If that is not possible, I guess we will have to keep a forked tree
>>> until
>>> the driver is upstreamed, but we would like to avoid that, hence the
>>> question.
>>
>> I guess you'll have to keep on doing that indeed. I'm not aware of any
>> location where out-of-tree drivers are considered. You should try
>> again when you have some actual code to upstream.
>>
> 
> Ok, thanks.

Also note that I don't want new fbdev drivers into the mainline kernel.
You should implement a DRM based driver instead.

 Tomi


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko

[Sebastian Frias]

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?
Does DRM provides a "fbdev" backward compatible API? Would that be feasible?
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.

If "implement a DRM driver" is a lot of work, it would end up as a 
business decision and probably would not happen.
Would you say there are good solid arguments to shake our current stack 
(other than for dusting it off)?

By the way, does DRM improves 2D acceleration support over fbdev?

Thanks,

Sebastian

Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 2678 bytes --]



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.

> 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.

> 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.

 Tomi


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko

[Daniel Vetter]

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