All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Noralf Trønnes" <noralf@tronnes.org>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [RFC 0/6] drm: Add support for userspace drivers
Date: Wed, 4 Jan 2017 16:06:03 +0100	[thread overview]
Message-ID: <20170104150603.swrccqksc4hkff4k@phenom.ffwll.local> (raw)
In-Reply-To: <20170104133442.4534-1-noralf@tronnes.org>

On Wed, Jan 04, 2017 at 02:34:36PM +0100, Noralf Trønnes wrote:
> Hi,
> 
> I was previously working on tinydrm as a replacement for staging/fbtft.
> During a break from that work, I started to think about if it would be
> possible to move the drivers to userspace instead. No point in having
> them in the kernel if it's not necessary.
> 
> This patchset includes all the pieces necessary to get a userspace
> driver[1] working that is compatible with the fbtft/fb_ili9341 driver.
> It is tested with a SPI interfaced display hat/shield for the Raspberry Pi,
> which has an eeprom with a Device Tree fragment on it (merged by the
> bootloader). With the help of udev and systemd, the driver is able to
> autoload when the display is connected.
> Performance wise, the kernel driver can do ~19fps on a 320x240 spi@32MHz
> display, whereas the userspace version does ~18fps. So performance is not
> an argument to keep the driver in the kernel.
> 
> What do you think about this approach?

It's a pretty nifty thing, and iirc some of the ideas for implementing
miracast centered around the same idea: Small userspace drm driver shim
that forwards everything to the miracast code running all in userspace.
David Herrmann looked into that years ago, not sure he ever got the full
stack up&running.

For dumb panels itself I'm not sure it's the right design. Adding a
kernel/userspace interface will make code sharing harder, and experience
also says that we'll rework kms semantics every few years. In-kernel
drivers seem to me like the better default choice, except when there's a
clear reason for why userspace is the only option. For miracast that's the
case, since porting the userspace video encode libraries to the kernel
just doesn't make sense. For SPI and other slow buses I don't see any such
compelling reason to move it into userspace.
-Daniel


> 
> Note: This patchset is based on 4.9
> 
> [1] https://github.com/notro/udrm
> 
> 
> Noralf.
> 
> 
> Noralf Trønnes (6):
>   drm/modes: Export drm_mode_convert_umode()
>   drm: Add support for userspace drivers
>   dma-buf: Support generic userspace allocations
>   spi: Let clients do scatter/gather transfers
>   spi: spidev: Add dma-buf support
>   spi: spidev: Add userspace driver support
> 
>  drivers/dma-buf/Makefile         |   2 +-
>  drivers/dma-buf/dev.c            | 211 ++++++++++++++++++
>  drivers/gpu/drm/Kconfig          |   2 +
>  drivers/gpu/drm/Makefile         |   1 +
>  drivers/gpu/drm/drm_modes.c      |   1 +
>  drivers/gpu/drm/udrm/Kconfig     |   9 +
>  drivers/gpu/drm/udrm/Makefile    |   4 +
>  drivers/gpu/drm/udrm/udrm-dev.c  | 276 ++++++++++++++++++++++++
>  drivers/gpu/drm/udrm/udrm-drv.c  | 324 ++++++++++++++++++++++++++++
>  drivers/gpu/drm/udrm/udrm-fb.c   | 369 ++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/udrm/udrm-pipe.c | 170 +++++++++++++++
>  drivers/gpu/drm/udrm/udrm.h      |  84 ++++++++
>  drivers/spi/Kconfig              |   1 +
>  drivers/spi/spi.c                |  24 ++-
>  drivers/spi/spidev.c             | 447 ++++++++++++++++++++++++++++++++++++++-
>  include/linux/spi/spi.h          |   4 +
>  include/uapi/drm/udrm.h          |  78 +++++++
>  include/uapi/linux/dma-buf-dev.h |  35 +++
>  include/uapi/linux/spi/spidev.h  |   8 +
>  19 files changed, 2032 insertions(+), 18 deletions(-)
>  create mode 100644 drivers/dma-buf/dev.c
>  create mode 100644 drivers/gpu/drm/udrm/Kconfig
>  create mode 100644 drivers/gpu/drm/udrm/Makefile
>  create mode 100644 drivers/gpu/drm/udrm/udrm-dev.c
>  create mode 100644 drivers/gpu/drm/udrm/udrm-drv.c
>  create mode 100644 drivers/gpu/drm/udrm/udrm-fb.c
>  create mode 100644 drivers/gpu/drm/udrm/udrm-pipe.c
>  create mode 100644 drivers/gpu/drm/udrm/udrm.h
>  create mode 100644 include/uapi/drm/udrm.h
>  create mode 100644 include/uapi/linux/dma-buf-dev.h
> 
> --
> 2.10.2
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2017-01-04 15:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-04 13:34 [RFC 0/6] drm: Add support for userspace drivers Noralf Trønnes
2017-01-04 13:34 ` [RFC 1/6] drm/modes: Export drm_mode_convert_umode() Noralf Trønnes
2017-01-04 13:34 ` [RFC 2/6] drm: Add support for userspace drivers Noralf Trønnes
2017-01-04 13:34 ` [RFC 3/6] dma-buf: Support generic userspace allocations Noralf Trønnes
2017-01-04 15:08   ` Daniel Vetter
2017-01-04 13:34 ` [RFC 4/6] spi: Let clients do scatter/gather transfers Noralf Trønnes
2017-01-04 13:34 ` [RFC 5/6] spi: spidev: Add dma-buf support Noralf Trønnes
2017-01-04 13:34 ` [RFC 6/6] spi: spidev: Add userspace driver support Noralf Trønnes
2017-01-04 15:06 ` Daniel Vetter [this message]
2017-01-04 15:15   ` [RFC 0/6] drm: Add support for userspace drivers Martin Peres

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170104150603.swrccqksc4hkff4k@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=noralf@tronnes.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.