[RFC 0/7] staging: fbtft: minimize coupling to the fbdev subsystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

This patchset introduces a new API to minimize the coupling to the
fbdev graphics subsystem. There have been calls to deprecate fbdev and
new fbdev drivers are discouraged.
Currently the FBTFT drivers are tightly coupled to fbdev through the
fbtft module and the fbtft_par structure.

What is FBTFT?
FBTFT is a framework for writing drivers for MIPI DCS/DBI [1] like controllers.
These controllers have the following characteristics:
- Onchip graphics RAM that is scanned out to the display panel.
- Registers to set operational parameters and write pixel data
- SPI, I2C and/or parallel interface

To provide better layering and provide opportunity for reuse,
I propose the following layers:

+-----------------------------+
|          fbdev              |
+-----------------------------+
|          fbtft              |
+-------------------------+---+
|      Display driver     |   |
+---+---------------------+   |
|   |     lcdctrl             |
|   +-------------------------+
|         lcdreg              |
+-----------------------------+
|  Interface (SPI, parallel)  |
+-----------------------------+

lcdreg
------
This layer deals with the various LCD controller interface
implementations (SPI, Intel 8080, I2C). It provides a simple interface
for reading and writing to the LCD controller register.
Especially the SPI interface has several modes and variations that
makes it rather complex.

lcdreg can be reused by drivers that drive these same controllers in
digital RGB interface mode (MIPI DPI). Even when the parallel RGB
interface is used for pixeldata, the controller some times has to be
configured. This is usually done through a SPI interface.

lcdctrl
-------
Layer providing an abstraction of the LCD controller and it's
principal funtions:
- Poweron initialization
- Set display rotation
- Set pixel format
- Display blanking
- Update grahics RAM

This decouples the controller implementation from the graphics subsystem,
and prepares for a possible future move to DRM or other grahics subsystems.
The controller specific functionality is kept in library modules.

fbtft
-----
The fbtft module gets some helper functions in fbtft-lcdctrl to map
the lcdtrl functions into the fbtft_par structure.
Later when all the drivers have been converted, large parts of the
fbtft module can be removed.


The I2C implementation of lcdreg is used in this proposal, because of
it's simplicity. This is to keep focus on the architectural design.
Implementations for SPI and the Intel 8080 bus interface exists.

Display or Controller driver?
Currently FBTFT has drivers for each controller it supports.
Each driver has a default controller setup which often matches many
displays, but no all (fbtftops.init_display()). A different init
sequence (register values and delays) can be passed in using
platform_data or as a DT property.
I made a post to the DT mailinglist [2] about setting an init sequence
from the Device Tree, but didn't get any replies. Based on an earlier
post and comments I've read, it's looks like init sequence in DT is
not going to happen. That's why this proposal shifts to having display
drivers, with controller specific code in library modules.

Device Tree questions
- What about Device Tree property names that are used by all drivers
  (initialized, format, rotation)? Should they be prefixed in any way?
- Device Tree compatible string. If a driver supports both SPI and I2C,
  can the same compatible string be used for both busses (ada-ssd1306fb)?
  I have seen examples where the bus is added as a postfix (-i2c).
  And which one is preferred: 'ada-ssd1306' or 'ada-ssd1306fb'?

Why RFC?
I did this because of some uncertainties I have with this proposal:
1. This changes almost the entire FBTFT stack. Would it be better to
   just move directly to DRM? DRM is the preferred way to write graphics
   drivers now, but fbdev is really a perfect match for FBTFT.
   And DRM doesn't have deferred io support AFAICT.
2. The change from controller centric drivers to display drivers is
   that correct?
   This will deprecate all of the current controller drivers.

So any help in pinning down the path for moving FBTFT forward is appreciated.


[1]: MIPI Alliance Display Interface Specifications:
     MIPI DCS - Display Command Set
     MIPI DBI - Display Bus Interface
     MIPI DPI - Display Pixel Interface
     http://mipi.org/specifications/display-interface
[2]: http://article.gmane.org/gmane.linux.drivers.devicetree/109103


Regards,
Noralf Trønnes


Noralf Trønnes (7):
  staging: fbtft: add lcd register abstraction
  staging: fbtft: lcdreg: add i2c support
  staging: fbtft: add lcd controller abstraction
  staging: fbtft: lcdctrl: add ssd1306 support
  staging: fbtft: don't require platform data
  staging: fbtft: extend core to use lcdctrl
  staging: fbtft: add driver for Adafruit ssd1306 based displays

 drivers/staging/fbtft/Kconfig                 |  12 +
 drivers/staging/fbtft/Makefile                |  11 +-
 drivers/staging/fbtft/ada-ssd1306fb.c         | 173 ++++++++++++++
 drivers/staging/fbtft/fbtft-core.c            |   6 +-
 drivers/staging/fbtft/fbtft-lcdctrl.c         | 311 ++++++++++++++++++++++++++
 drivers/staging/fbtft/fbtft.h                 |  13 ++
 drivers/staging/fbtft/lcdctrl/Kconfig         |   8 +
 drivers/staging/fbtft/lcdctrl/Makefile        |   3 +
 drivers/staging/fbtft/lcdctrl/lcdctrl.c       | 207 +++++++++++++++++
 drivers/staging/fbtft/lcdctrl/lcdctrl.h       | 104 +++++++++
 drivers/staging/fbtft/lcdctrl/ssd1306.c       | 168 ++++++++++++++
 drivers/staging/fbtft/lcdctrl/ssd1306.h       |  51 +++++
 drivers/staging/fbtft/lcdreg/Kconfig          |  10 +
 drivers/staging/fbtft/lcdreg/Makefile         |   5 +
 drivers/staging/fbtft/lcdreg/internal.h       |   9 +
 drivers/staging/fbtft/lcdreg/lcdreg-core.c    | 187 ++++++++++++++++
 drivers/staging/fbtft/lcdreg/lcdreg-debugfs.c | 272 ++++++++++++++++++++++
 drivers/staging/fbtft/lcdreg/lcdreg-i2c.c     | 129 +++++++++++
 drivers/staging/fbtft/lcdreg/lcdreg.h         | 154 +++++++++++++
 19 files changed, 1827 insertions(+), 6 deletions(-)
 create mode 100644 drivers/staging/fbtft/ada-ssd1306fb.c
 create mode 100644 drivers/staging/fbtft/fbtft-lcdctrl.c
 create mode 100644 drivers/staging/fbtft/lcdctrl/Kconfig
 create mode 100644 drivers/staging/fbtft/lcdctrl/Makefile
 create mode 100644 drivers/staging/fbtft/lcdctrl/lcdctrl.c
 create mode 100644 drivers/staging/fbtft/lcdctrl/lcdctrl.h
 create mode 100644 drivers/staging/fbtft/lcdctrl/ssd1306.c
 create mode 100644 drivers/staging/fbtft/lcdctrl/ssd1306.h
 create mode 100644 drivers/staging/fbtft/lcdreg/Kconfig
 create mode 100644 drivers/staging/fbtft/lcdreg/Makefile
 create mode 100644 drivers/staging/fbtft/lcdreg/internal.h
 create mode 100644 drivers/staging/fbtft/lcdreg/lcdreg-core.c
 create mode 100644 drivers/staging/fbtft/lcdreg/lcdreg-debugfs.c
 create mode 100644 drivers/staging/fbtft/lcdreg/lcdreg-i2c.c
 create mode 100644 drivers/staging/fbtft/lcdreg/lcdreg.h

--
2.2.2

_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel





[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux