All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC 0/7] staging: fbtft: minimize coupling to the fbdev subsystem
@ 2015-03-02 10:54 Noralf Trønnes
  2015-03-02 10:54 ` [RFC 1/7] staging: fbtft: add lcd register abstraction Noralf Trønnes
                   ` (7 more replies)
  0 siblings, 8 replies; 19+ messages in thread
From: Noralf Trønnes @ 2015-03-02 10:54 UTC (permalink / raw)
  To: thomas.petazzoni; +Cc: gregkh, driverdev-devel, Noralf Trønnes

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@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2015-03-21 18:23 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-02 10:54 [RFC 0/7] staging: fbtft: minimize coupling to the fbdev subsystem Noralf Trønnes
2015-03-02 10:54 ` [RFC 1/7] staging: fbtft: add lcd register abstraction Noralf Trønnes
2015-03-02 12:25   ` Dan Carpenter
2015-03-03 12:19     ` Noralf Trønnes
2015-03-03 12:28       ` Dan Carpenter
2015-03-02 10:54 ` [RFC 2/7] staging: fbtft: lcdreg: add i2c support Noralf Trønnes
2015-03-02 10:54 ` [RFC 3/7] staging: fbtft: add lcd controller abstraction Noralf Trønnes
2015-03-02 11:48   ` Dan Carpenter
2015-03-03 11:57     ` Noralf Trønnes
2015-03-03 12:04       ` Dan Carpenter
2015-03-03 14:08         ` Noralf Trønnes
2015-03-02 10:54 ` [RFC 4/7] staging: fbtft: lcdctrl: add ssd1306 support Noralf Trønnes
2015-03-02 10:54 ` [RFC 5/7] staging: fbtft: don't require platform data Noralf Trønnes
2015-03-02 11:31   ` Dan Carpenter
2015-03-03 11:15     ` Noralf Trønnes
2015-03-02 10:54 ` [RFC 6/7] staging: fbtft: extend core to use lcdctrl Noralf Trønnes
2015-03-02 10:54 ` [RFC 7/7] staging: fbtft: add driver for Adafruit ssd1306 based displays Noralf Trønnes
2015-03-21 18:23 ` [RFC 0/7] staging: fbtft: minimize coupling to the fbdev subsystem Noralf Trønnes
2015-03-21 18:23   ` Noralf Trønnes

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.