[RFC 0/6] drm: Add support for userspace drivers
On 04/01/17 17:06, Daniel Vetter wrote: > 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 at 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 This is actually something David Herrmann told us not to do, stating that it was too hard for Desktop Environments to select which GPUs to output to. I however disagreed as this is something they need to support anyway for USB GPUs and miracast could piggy back on this effort. An engineer in Intel Finland did work on this and we got approval for Open Sourcing it but I really have no time for this right now though :s That was my 2 cents. Martin
[RFC 0/6] drm: Add support for userspace drivers
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 at 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 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 at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[RFC 0/6] drm: Add support for userspace drivers
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 at 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? 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
