fbdev: add support for Sigma Designs' smp8xxxfb.ko
RFC PATCH 1/1 fbdev: add support for Sigma Designs' smp8xxxfb.ko
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
--- drivers/video/fbdev/Kconfig | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/video/fbdev/Kconfig +10 -0
@@ -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
Signature · 1 line
1.7.10.4
Quoted 5 lines · 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.
That's not really a solution to add a driver to the kernel. You'd have to include some actual driver code as well.
Quoted 9 lines
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_COPYAREAandFB_CFB_IMAGEBLITto 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?
Quoted 18 lines
Subject: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
Signed-off-by Sebastian Frias <[email protected]>--- drivers/video/fbdev/Kconfig | 10 ++++++++++ 1 file changed, 10 insertions(+)drivers/video/fbdev/Kconfig +3
-0@@ -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
drivers/video/fbdev/Kconfig config FB_BF537_LQ035 · line 630
Quoted 10 lines
drivers/video/fbdev/Kconfig +7
-0+ 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
Quoted 9 lines · Frans Klaver
Quoted 5 lines · 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.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.
Quoted 12 lines
Quoted 11 lines
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_COPYAREAandFB_CFB_IMAGEBLITto 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.
Quoted 3 lines
Is the below patch really a patch you intend to upstream, or are you just wondering about what your
Kconfigentry 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.
Quoted 33 lines
Quoted 20 lines
Subject: [RFC PATCH] fbdev: add support for Sigma Designs' smp8xxxfb.ko
Signed-off-by Sebastian Frias <[email protected]>--- drivers/video/fbdev/Kconfig | 10 ++++++++++ 1 file changed, 10 insertions(+)drivers/video/fbdev/Kconfig +3
-0@@ -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_TANGOdrivers/video/fbdev/Kconfig config FB_BF537_LQ035 · line 630
Quoted 10 lines
drivers/video/fbdev/Kconfig +7
-0+ 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 && BLACKFINFrans
Quoted 48 lines · Sebastian Frias
Quoted 5 lines · Frans Klaver
Quoted 3 lines · Sebastian Frias
Hi,
Quoted 7 lines
Quoted 3 lines
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_COPYAREAandFB_CFB_IMAGEBLITto 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.
Quoted 15 lines
Quoted 8 lines
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.Quoted 5 lines
Our current kernel fork (based on 3.4) hardcodes
FB_CFB_FILLRECT,FB_CFB_COPYAREAandFB_CFB_IMAGEBLITto 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.Quoted 3 lines
Is the below patch really a patch you intend to upstream, or are you just wondering about what your
Kconfigentry 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:
Quoted 6 lines
- how would you recommend enabling
FB_CFB_FILLRECT,FB_CFB_COPYAREAandFB_CFB_IMAGEBLITfor 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
Quoted 7 lines · Frans Klaver
Quoted 6 lines · Sebastian Frias
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_COPYAREAandFB_CFB_IMAGEBLITfor a driver that is not included in the kernel's tree?
Quoted 8 lines
Quoted 3 lines
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.
Hi,
Quoted 14 lines · Sebastian Frias
Quoted 13 lines · Frans Klaver
Quoted 10 lines · Sebastian Frias
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_COPYAREAandFB_CFB_IMAGEBLITfor 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.
Quoted 6 lines
Quoted 4 lines
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
Hi,
Quoted 4 lines · Tomi Valkeinen
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
Quoted 9 lines · Sebastian Frias
Hi,
Quoted 4 lines · Tomi Valkeinen
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.
Quoted 2 lines
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.
Quoted 11 lines
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.
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 1 line
By the way, does DRM improves 2D acceleration support over fbdev?
I don't know enough about 2D acceleration to answer that.
Tomi
Quoted 13 lines · Tomi Valkeinen
Quoted 9 lines · Sebastian Frias
Hi,
Quoted 4 lines · Tomi Valkeinen
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?
Quoted 8 lines
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).
Quoted 6 lines
Quoted 2 lines
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.
Quoted 33 lines
Quoted 11 lines
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.
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 7 lines
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.
Quoted 1 line
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
Signature · 3 lines
Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch