| Message ID | 56828767.4050302@laposte.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 > -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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
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
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(+)