Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1232084 > unrolled thread

No more new fbdev drivers, please

Back to article view | Back to linux.kernel

Contents

  No more new fbdev drivers, please Tomi Valkeinen <tomi.valkeinen@ti.com> - 2015-09-24 14:30 +0200
    Re: No more new fbdev drivers, please Thomas Petazzoni <thomas.petazzoni@free-electrons.com> - 2015-09-24 14:50 +0200
      Re: No more new fbdev drivers, please Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-24 17:30 +0200
        Re: No more new fbdev drivers, please Alex Deucher <alexdeucher@gmail.com> - 2015-09-24 17:40 +0200
        Re: No more new fbdev drivers, please Daniel Vetter <daniel@ffwll.ch> - 2015-09-24 18:00 +0200
          Re: No more new fbdev drivers, please Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-24 18:20 +0200
          Re: No more new fbdev drivers, please Ondrej Zary <linux@rainbow-software.org> - 2015-09-24 19:20 +0200
            Re: No more new fbdev drivers, please Daniel Vetter <daniel@ffwll.ch> - 2015-09-24 20:10 +0200
      Re: No more new fbdev drivers, please Daniel Vetter <daniel@ffwll.ch> - 2015-09-24 17:30 +0200
        Re: No more new fbdev drivers, please Geert Uytterhoeven <geert@linux-m68k.org> - 2015-09-26 10:30 +0200
          Re: No more new fbdev drivers, please Alex Deucher <alexdeucher@gmail.com> - 2015-09-26 19:10 +0200
            Re: No more new fbdev drivers, please Geert Uytterhoeven <geert@linux-m68k.org> - 2015-09-26 20:10 +0200
              Re: No more new fbdev drivers, please David Herrmann <dh.herrmann@gmail.com> - 2015-09-26 20:20 +0200
                Re: No more new fbdev drivers, please Geert Uytterhoeven <geert@linux-m68k.org> - 2015-09-26 20:50 +0200
                  Re: No more new fbdev drivers, please Rob Clark <robdclark@gmail.com> - 2015-09-26 22:50 +0200
                    Re: No more new fbdev drivers, please Dave Airlie <airlied@gmail.com> - 2015-09-27 00:00 +0200
                  Re: No more new fbdev drivers, please Emil Velikov <emil.l.velikov@gmail.com> - 2015-09-30 14:00 +0200
                Re: No more new fbdev drivers, please Gerd Hoffmann <kraxel@redhat.com> - 2015-09-28 09:50 +0200
                  Re: No more new fbdev drivers, please Daniel Vetter <daniel@ffwll.ch> - 2015-09-28 14:40 +0200
                    Re: No more new fbdev drivers, please Gerd Hoffmann <kraxel@redhat.com> - 2015-09-29 10:30 +0200
                      Re: No more new fbdev drivers, please Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2015-09-29 10:40 +0200
              Re: No more new fbdev drivers, please Bernie Thompson <bernie@plugable.com> - 2015-09-28 23:00 +0200
              Re: No more new fbdev drivers, please Daniel Vetter <daniel@ffwll.ch> - 2015-09-29 09:10 +0200
    Re: No more new fbdev drivers, please Aaro Koskinen <aaro.koskinen@iki.fi> - 2015-09-25 11:00 +0200
      Re: No more new fbdev drivers, please Ondrej Zary <linux@rainbow-software.org> - 2015-09-25 13:10 +0200
    Re: No more new fbdev drivers, please Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2015-09-26 09:20 +0200
      Re: No more new fbdev drivers, please Ilia Mirkin <imirkin@alum.mit.edu> - 2015-09-26 09:40 +0200
    Re: No more new fbdev drivers, please Noralf Trønnes <noralf@tronnes.org> - 2015-09-27 15:20 +0200
      Re: No more new fbdev drivers, please Emil Velikov <emil.l.velikov@gmail.com> - 2015-09-27 18:10 +0200
        Re: No more new fbdev drivers, please Noralf Trønnes <noralf@tronnes.org> - 2015-09-29 01:00 +0200
          Re: No more new fbdev drivers, please Daniel Vetter <daniel@ffwll.ch> - 2015-09-29 09:10 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1234827

Hi Gerd,

On Tuesday 29 September 2015 10:23:23 Gerd Hoffmann wrote:
> On Mo, 2015-09-28 at 14:36 +0200, Daniel Vetter wrote:
> > On Mon, Sep 28, 2015 at 09:39:13AM +0200, Gerd Hoffmann wrote:
> > >   Hi,
> > >   
> > > > As Daniel mentioned, the connector+encoder+crtc combination is one of
> > > > those simplifications that would make sense if more such drivers are
> > > > added.
> > > 
> > > Another one is memory management.  It's pretty complex because it can
> > > handle _way_ more than what simple drivers need, and the result is
> > > _alot_ of ttm boilerplate in the drivers.
> > 
> > ttm is pretty impressive overkill for most simplistic drm drivers. If you
> > just need contiguous framebuffers for display then the cma helpers should
> > take care of pretty much all the boilerplate for you. They have ready-made
> > simple gem and dumb framebuffer mmap support, which is all a basic kms
> > driver needs.
> 
> Does that work on !arm meanwhile?  Last time I checked (when writing
> bochsdrm, around v3.14) the cma helpers didn't even build on x86 ...

config DRM_GEM_CMA_HELPER
        bool
        depends on DRM && HAVE_DMA_ATTRS
        help
          Choose this if you need the GEM CMA helper functions

x86 defines HAVE_DMA_ATTRS.

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1234448

On Sat, Sep 26, 2015 at 11:01 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> The smallest of these (udl) still counts in at ca. 2800 LoC,

Note udlfb.c, the original fbdev driver that I helped write and that
the udl DRM driver was based on, is ~1800 LoC ... so we're actually
talking in the ballpark of 2x (rather than 10x) between fbdev and DRM
in this case. That said, the complexity difference is probably higher
than the LoC difference. I know I personally have struggled in the
shift from understanding fbdev to understanding DRM.

The fact that there's drivers of both types and USB hardware might
make udl may be a good driver to use as a base for any additional
simplification / helper work. David Airlie and David Herrmann both
have this hardware. David Airlie did the port from fbdev to DRM, so
he's made it an exemplary driver.  And if anyone needs any hardware
which works with udlfb and udl, we're happy to send free hardware to
any programmers who are willing to contribute in the form of code or
testing: http://plugable.com/projects/plugable-open-source-hardware-samples-program

More simplification and documentation would be great. In particular,
the optimization for the connector+encoder+crtc combination others
have mentioned seems like it would be worthwhile.

Cheers,
Bernie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1234759

On Mon, Sep 28, 2015 at 01:52:31PM -0700, Bernie Thompson wrote:
> On Sat, Sep 26, 2015 at 11:01 AM, Geert Uytterhoeven <geert@linux-m68k.org>
>  wrote:
> > The smallest of these (udl) still counts in at ca. 2800 LoC,
> 
> Note udlfb.c, the original fbdev driver that I helped write and that the
> udl DRM driver was based on, is ~1800 LoC ... so we're actually talking in
> the ballpark of 2x (rather than 10x) between fbdev and DRM in this case.
> That said, the complexity difference is probably higher than the LoC
> difference. I know I personally have struggled in the shift from
> understanding fbdev to understanding DRM.

udl has a bit of room for improvement, we really should push the worker
logicy for fbdev emulation into the core drm fbdev helpers using the
->dirtyfb callback. That should rip out quite a few lines.

The other thing to consider is that drm/udl supports PRIME buffer sharing
for seamlessly extending your desktop by just plugging in an usb dongle.

> The fact that there's drivers of both types and USB hardware might make udl
> may be a good driver to use as a base for any additional simplification /
> helper work. David Airlie and David Herrmann both have this hardware. David
> Airlie did the port from fbdev to DRM, so he's made it an exemplary
> driver.  And if anyone needs any hardware which works with udlfb and udl,
> we're happy to send free hardware to any programmers who are willing to
> contribute in the form of code or testing:
> http://plugable.com/projects/plugable-open-source-hardware-samples-program

For example drivers I think it's better to look at the latest drm driver
merged - those are up-to-date wrt best practices. udl has already
accumulated a bit of cruft (e.g. still using legacy modeset helpers and
not the atomic ones).

> More simplification and documentation would be great. In particular, the
> optimization for the connector+encoder+crtc combination others have
> mentioned seems like it would be worthwhile.

Atomic helpers already make almost everything optional except for the
crtc-level enable/disable callbacks and the per-plane atomic_plane_update
(for buffer flips/panning/rotation/...). So a comibined helper would be
mostly for cutting down the structure setup/teardown boilerplate. So
should be fairly easy to implement even for drm beginners (when using one
of the latest drivers as a template for what needs to be done).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1232668

Hi,

On Thu, Sep 24, 2015 at 03:27:01PM +0300, Tomi Valkeinen wrote:
> fbdev is (more or less) maintained, but it's a deprecated framework. All
> new Linux display drivers should be done on DRM.
> 
> So let's not add any more new fbdev drivers.
> 
> I will continue to maintain the current fbdev drivers, and I don't mind
> adding some new features to those current drivers, as long as the amount
> of code required to add the features stays sensible.
> 
> I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
> and the question is what to do with those.

I was still planning to work on xgifb as I need it on some systems for
the console.

A.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1232712

On Friday 25 September 2015, Aaro Koskinen wrote:
> Hi,
>
> On Thu, Sep 24, 2015 at 03:27:01PM +0300, Tomi Valkeinen wrote:
> > fbdev is (more or less) maintained, but it's a deprecated framework. All
> > new Linux display drivers should be done on DRM.
> >
> > So let's not add any more new fbdev drivers.
> >
> > I will continue to maintain the current fbdev drivers, and I don't mind
> > adding some new features to those current drivers, as long as the amount
> > of code required to add the features stays sensible.
> >
> > I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
> > and the question is what to do with those.
>
> I was still planning to work on xgifb as I need it on some systems for
> the console.

xgifb supports these devices:
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_20
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_27
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_40
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_42

Two of them are already supported by sisfb:
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_20
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_40

So I think that support for the remaining two (and missing features, if any) 
should be added to sisfb.

-- 
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1233161

On Thu, Sep 24, 2015 at 03:27:01PM +0300, Tomi Valkeinen wrote:
> Hi all,
> 
> fbdev is (more or less) maintained, but it's a deprecated framework. All
> new Linux display drivers should be done on DRM.
<snip>
> 
> SM750 hardware seems to support multiple outputs, hardware overlays, 2D
> accelerator... I think it's pointless to write an fbdev driver for such
> a HW, as it's not possible to use those features with fbdev (without
> custom API).
Yes, it supports these and even SM712 which was recently moved out of
staging to fbdev area (which is the main reason that this thread
started) also supports dual display and 2D acceleration but those
features are not yet done in that driver.
SM750 will also have its code cleaned in few months so that it will be
ready to be moved out of staging. Right now we only have the framebuffer
driver and this hardware is being used in many laptops and notebooks. As
of now drm driver is not there for both SM712 and SM750. So then what
happens after SM750 is ready to be moved out? Will it be accepted in
fbdev or it will have to stay in staging untill a drm driver is ready?

BTW, I had a doubt about drm drivers. Is there any library or test suite
to test the driver? I am almost halfway in making a KMS driver for SM712
but still don't know how to test it properly. I was thinkig of asking
Daniel offlist but since this thread came up so asking here.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1233162

On Sat, Sep 26, 2015 at 3:15 AM, Sudip Mukherjee
<sudipm.mukherjee@gmail.com> wrote:
> BTW, I had a doubt about drm drivers. Is there any library or test suite
> to test the driver? I am almost halfway in making a KMS driver for SM712
> but still don't know how to test it properly. I was thinkig of asking
> Daniel offlist but since this thread came up so asking here.

Take a look at the modetest tool, part of libdrm:
http://cgit.freedesktop.org/mesa/drm/tree/tests/modetest

It's quite handy and contains command-line access to a lot of the
various KMS functionality, changing modes, configuring planes,
different formats, etc.

  -ilia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1233659

Den 24.09.2015 14:27, skrev Tomi Valkeinen:
> Hi all,
>
> fbdev is (more or less) maintained, but it's a deprecated framework. All
> new Linux display drivers should be done on DRM.
>
> So let's not add any more new fbdev drivers.
>
> I will continue to maintain the current fbdev drivers, and I don't mind
> adding some new features to those current drivers, as long as the amount
> of code required to add the features stays sensible.
>
> I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
> and the question is what to do with those.
>
> xgifb was added in 2010, and is still in staging.
>
> fbtft looks like maybe some kind of framework on top of fbdev, with
> fbtft specific subdrivers... I didn't look at it in detail, but my gut
> says "never".

I have done some work [1] to try and make fbtft look more like the rest
of the kernel (doc [2]), but that work will result in an almost complete
rewrite of fbtft. When Tomi showed reluctance to move sm712fb out of
staging [3], I started to look at DRM to see if I could find my way
through the myriad of helpers and objects/structs.

I now have this simplified view of DRM [4]:

struct tinydrm_device {
         struct drm_device *base;
         struct drm_plane plane;
         struct drm_crtc crtc;
         struct drm_encoder encoder;
         struct drm_connector connector;
         struct drm_fbdev_cma *fbdev_cma;
         bool enabled;
         u32 width, height;
         void *dev_private;

         int (*enable)(struct tinydrm_device *tdev);
         int (*disable)(struct tinydrm_device *tdev);

         int (*dirty)(struct drm_framebuffer *fb,
                      struct drm_gem_cma_object *cma_obj,
                      unsigned flags, unsigned color,
                      struct drm_clip_rect *clips, unsigned num_clips);
         /* blank() is missing */
         /* maybe some modeset() function to set hw rotation */
};

Currently I'm able to get fbdev framebuffer changes through as dirty()
calls. Next step is to hook up some of the rewritten fbtft code to
actually get something on the display.

This is the display controller abstraction I use in the rewritten fbtft:

struct lcdctrl {
         struct lcdreg *lcdreg;
         u32 width;
         u32 height;
         u32 rotation;
         bool enabled;
         struct regulator *power_supply;
         void *driver_private;
         u64 flags;

         int (*poweron)(struct lcdctrl *ctrl);
         void (*poweroff)(struct lcdctrl *ctrl);
         int (*update)(struct lcdctrl *ctrl, struct lcdctrl_update *update);
         int (*rotate)(struct lcdctrl *ctrl, u32 rotation);
         int (*blank)(struct lcdctrl *ctrl, bool blank);
         bool (*check)(struct lcdctrl *ctrl, u32 value);
};

So what I would like, is to have a simple struct like this to hide the
complexity of the graphics subsystem. Leaving the driver with just a
few lines of code to setup the controller:

static int ada_mipifb_1480_poweron(struct lcdctrl *ctrl)
{
         lcdreg_reset(reg);
         lcdreg_writereg(reg, ILI9340_PWCTRL1, 0x23);
[...]
}

static int ada_mipifb_probe(struct spi_device *spi)
{
         cfg.width = 240;
         cfg.height = 320;
         cfg.addr_mode0 = ILI9340_MADCTL_MX;
         cfg.addr_mode90 = ILI9340_MADCTL_MV | ILI9340_MADCTL_MY |
               ILI9340_MADCTL_MX;
         cfg.addr_mode180 = ILI9340_MADCTL_MY;
         cfg.addr_mode270 = ILI9340_MADCTL_MV;
         cfg.bgr = true;

         reg = devm_lcdreg_spi_init(spi, LCDREG_SPI_4WIRE);

         ctrl = devm_mipi_dbi_init(reg, &cfg);
         ctrl->poweron = ada_mipifb_1480_poweron;

         return devm_lcdctrl_register(ctrl);
}


For me personally it doesn't matter whether these drivers are drm or fbdev.
fbdev has everything these drivers need, but maybe it's not such a good 
choice
for the future.


Noralf.


[1] https://github.com/notro/linux-staging/commits/next
[2] 
https://github.com/notro/linux-staging/blob/next/drivers/staging/fbtft/Documentation/fb/fbtft.txt
[3] https://lkml.org/lkml/2015/9/1/274
[4] https://gist.github.com/notro/59e0c064bc512e85e9b2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1233701

Hi all,

On 27 September 2015 at 14:09, Noralf Trønnes <noralf@tronnes.org> wrote:
>
> Den 24.09.2015 14:27, skrev Tomi Valkeinen:
>>
>> Hi all,
>>
>> fbdev is (more or less) maintained, but it's a deprecated framework. All
>> new Linux display drivers should be done on DRM.
>>
>> So let's not add any more new fbdev drivers.
>>
>> I will continue to maintain the current fbdev drivers, and I don't mind
>> adding some new features to those current drivers, as long as the amount
>> of code required to add the features stays sensible.
>>
>> I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
>> and the question is what to do with those.
>>
>> xgifb was added in 2010, and is still in staging.
>>
>> fbtft looks like maybe some kind of framework on top of fbdev, with
>> fbtft specific subdrivers... I didn't look at it in detail, but my gut
>> says "never".
>
>
> I have done some work [1] to try and make fbtft look more like the rest
> of the kernel (doc [2]), but that work will result in an almost complete
> rewrite of fbtft.
From a very quick skim fbtft looks pretty much like drm/panel. We
presently have 30+ 'simple' dsi panels, plus a bunch of spi ones. Have
you had a look at these ?

Cheers,
Emil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1234563

Den 27.09.2015 18:08, skrev Emil Velikov:
> Hi all,
>
> On 27 September 2015 at 14:09, Noralf Trønnes <noralf@tronnes.org> wrote:
>> Den 24.09.2015 14:27, skrev Tomi Valkeinen:
>>> Hi all,
>>>
>>> fbdev is (more or less) maintained, but it's a deprecated framework. All
>>> new Linux display drivers should be done on DRM.
>>>
>>> So let's not add any more new fbdev drivers.
>>>
>>> I will continue to maintain the current fbdev drivers, and I don't mind
>>> adding some new features to those current drivers, as long as the amount
>>> of code required to add the features stays sensible.
>>>
>>> I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
>>> and the question is what to do with those.
>>>
>>> xgifb was added in 2010, and is still in staging.
>>>
>>> fbtft looks like maybe some kind of framework on top of fbdev, with
>>> fbtft specific subdrivers... I didn't look at it in detail, but my gut
>>> says "never".
>>
>> I have done some work [1] to try and make fbtft look more like the rest
>> of the kernel (doc [2]), but that work will result in an almost complete
>> rewrite of fbtft.
>  From a very quick skim fbtft looks pretty much like drm/panel. We
> presently have 30+ 'simple' dsi panels, plus a bunch of spi ones. Have
> you had a look at these ?

Thanks, that was useful.
I can use drm_panel to setup the controller (prepare) and do backlight
(enable/disable), but I need a way to send framebuffer changes.
I could do this:

struct tinydrm_panel_funcs {
         int (*update)(struct drm_framebuffer *fb,
                       struct drm_gem_cma_object *cma_obj,
                       unsigned flags, unsigned color,
                       struct drm_clip_rect *clips, unsigned num_clips);
};

struct tinydrm_panel {
         struct drm_panel panel;
         u32 width;
         u32 height;
         void *dev_private;

         const struct tinydrm_panel_funcs *funcs;
};

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1234757

On Tue, Sep 29, 2015 at 12:51:38AM +0200, Noralf Trønnes wrote:
> 
> Den 27.09.2015 18:08, skrev Emil Velikov:
> >Hi all,
> >
> >On 27 September 2015 at 14:09, Noralf Trønnes <noralf@tronnes.org> wrote:
> >>Den 24.09.2015 14:27, skrev Tomi Valkeinen:
> >>>Hi all,
> >>>
> >>>fbdev is (more or less) maintained, but it's a deprecated framework. All
> >>>new Linux display drivers should be done on DRM.
> >>>
> >>>So let's not add any more new fbdev drivers.
> >>>
> >>>I will continue to maintain the current fbdev drivers, and I don't mind
> >>>adding some new features to those current drivers, as long as the amount
> >>>of code required to add the features stays sensible.
> >>>
> >>>I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
> >>>and the question is what to do with those.
> >>>
> >>>xgifb was added in 2010, and is still in staging.
> >>>
> >>>fbtft looks like maybe some kind of framework on top of fbdev, with
> >>>fbtft specific subdrivers... I didn't look at it in detail, but my gut
> >>>says "never".
> >>
> >>I have done some work [1] to try and make fbtft look more like the rest
> >>of the kernel (doc [2]), but that work will result in an almost complete
> >>rewrite of fbtft.
> > From a very quick skim fbtft looks pretty much like drm/panel. We
> >presently have 30+ 'simple' dsi panels, plus a bunch of spi ones. Have
> >you had a look at these ?
> 
> Thanks, that was useful.
> I can use drm_panel to setup the controller (prepare) and do backlight
> (enable/disable), but I need a way to send framebuffer changes.
> I could do this:
> 
> struct tinydrm_panel_funcs {
>         int (*update)(struct drm_framebuffer *fb,
>                       struct drm_gem_cma_object *cma_obj,
>                       unsigned flags, unsigned color,
>                       struct drm_clip_rect *clips, unsigned num_clips);
> };
> 
> struct tinydrm_panel {
>         struct drm_panel panel;
>         u32 width;
>         u32 height;
>         void *dev_private;
> 
>         const struct tinydrm_panel_funcs *funcs;
> };

I'm not sure whether putting the manual-update stuff into drm_panel is a
good idea - it's transport/bus (spi, dsi, ...) specific. Not sure how to
best solve that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web