[RFC 0/5] Generic panel framework
inki.dae at samsung.com
Sat Oct 20 07:22:11 PDT 2012
correct some typo. Sorry for this.
2012/10/20 Inki Dae <inki.dae at samsung.com>:
> Hi Laurent. sorry for being late.
> 2012/8/17 Laurent Pinchart <laurent.pinchart at ideasonboard.com>:
>> Hi everybody,
>> While working on DT bindings for the Renesas Mobile SoC display controller
>> (a.k.a. LCDC) I quickly realized that display panel implementation based on
>> board code callbacks would need to be replaced by a driver-based panel
>> Several driver-based panel support solution already exist in the kernel.
>> - The LCD device class is implemented in drivers/video/backlight/lcd.c and
>> exposes a kernel API in include/linux/lcd.h. That API is tied to the FBDEV
>> API for historical reason, uses board code callback for reset and power
>> management, and doesn't include support for standard features available in
>> today's "smart panels".
>> - OMAP2+ based systems use custom panel drivers available in
>> drivers/video/omap2/displays. Those drivers are based on OMAP DSS (display
>> controller) specific APIs.
>> - Similarly, Exynos based systems use custom panel drivers available in
>> drivers/video/exynos. Only a single driver (s6e8ax0) is currently available.
>> That driver is based on Exynos display controller specific APIs and on the
>> LCD device class API.
>> I've brought up the issue with Tomi Valkeinen (OMAP DSS maintainer) and Marcus
>> Lorentzon (working on panel support for ST/Linaro), and we agreed that a
>> generic panel framework for display devices is needed. These patches implement
>> a first proof of concept.
>> One of the main reasons for creating a new panel framework instead of adding
>> missing features to the LCD framework is to avoid being tied to the FBDEV
>> framework. Panels will be used by DRM drivers as well, and their API should
>> thus be subsystem-agnostic. Note that the panel framework used the
>> fb_videomode structure in its API, this will be replaced by a common video
>> mode structure shared across subsystems (there's only so many hours per day).
>> Panels, as used in these patches, are defined as physical devices combining a
>> matrix of pixels and a controller capable of driving that matrix.
>> Panel physical devices are registered as children of the control bus the panel
>> controller is connected to (depending on the panel type, we can find platform
>> devices for dummy panels with no control bus, or I2C, SPI, DBI, DSI, ...
>> devices). The generic panel framework matches registered panel devices with
>> panel drivers and call the panel drivers probe method, as done by other device
>> classes in the kernel. The driver probe() method is responsible for
>> instantiating a struct panel instance and registering it with the generic
>> panel framework.
>> Display drivers are panel consumers. They register a panel notifier with the
>> framework, which then calls the notifier when a matching panel is registered.
>> The reason for this asynchronous mode of operation, compared to how drivers
>> acquire regulator or clock resources, is that the panel can use resources
>> provided by the display driver. For instance a panel can be a child of the DBI
>> or DSI bus controlled by the display device, or use a clock provided by that
>> device. We can't defer the display device probe until the panel is registered
>> and also defer the panel device probe until the display is registered. As
>> most display drivers need to handle output devices hotplug (HDMI monitors for
>> instance), handling panel through a notification system seemed to be the
>> easiest solution.
>> Note that this brings a different issue after registration, as display and
>> panel drivers would take a reference to each other. Those circular references
>> would make driver unloading impossible. I haven't found a good solution for
>> that problem yet (hence the RFC state of those patches), and I would
>> appreciate your input here. This might also be a hint that the framework
>> design is wrong to start with. I guess I can't get everything right on the
>> first try ;-)
>> Getting hold of the panel is the most complex part. Once done, display drivers
>> can call abstract operations provided by panel drivers to control the panel
>> operation. These patches implement three of those operations (enable, start
>> transfer and get modes). More operations will be needed, and those three
>> operations will likely get modified during review. Most of the panels on
>> devices I own are dumb panels with no control bus, and are thus not the best
>> candidates to design a framework that needs to take complex panels' needs into
>> In addition to the generic panel core, I've implemented MIPI DBI (Display Bus
>> Interface, a parallel bus for panels that supports read/write transfers of
>> commands and data) bus support, as well as three panel drivers (dummy panels
>> with no control bus, and Renesas R61505- and R61517-based panels, both using
>> DBI as their control bus). Only the dummy panel driver has been tested as I
>> lack hardware for the two other drivers.
>> I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If
>> you can find a clever way to solve the cyclic references issue described above
>> I'll buy you a beer at the next conference we will both attend. If you think
>> the proposed solution is too complex, or too simple, I'm all ears. I
>> personally already feel that we might need something even more generic to
>> support other kinds of external devices connected to display controllers, such
>> as external DSI to HDMI converters for instance. Some kind of video entity
>> exposing abstract operations like the panels do would make sense, in which
>> case panels would "inherit" from that video entity.
>> Speaking of conferences, I will attend the KS/LPC in San Diego in a bit more
>> than a week, and would be happy to discuss this topic face to face there.
>> Laurent Pinchart (5):
>> video: Add generic display panel core
>> video: panel: Add dummy panel support
>> video: panel: Add MIPI DBI bus support
>> video: panel: Add R61505 panel support
>> video: panel: Add R61517 panel support
> how about using 'buses' directory instead of 'panel' and adding
> 'panel' under that like below?
> video/buess: display bus frameworks such as MIPI-DBI/DSI and eDP are placed.
> video/buess/panel: panel drivers based on display bus-based drivers are placed.
video/busses: display bus frameworks such as MIPI-DBI/DSI and eDP are placed.
video/busses/panel: panel drivers based on display bus-based drivers are placed.
> I think MIPI-DBI(Display Bus Interface)/DSI(Display Serial Interface)
> and eDP are the bus interfaces for display controllers such as
> DISC(OMAP SoC) and FIMC(Exynos SoC).
> Inki Dae
>> drivers/video/Kconfig | 1 +
>> drivers/video/Makefile | 1 +
>> drivers/video/panel/Kconfig | 37 +++
>> drivers/video/panel/Makefile | 5 +
>> drivers/video/panel/panel-dbi.c | 217 +++++++++++++++
>> drivers/video/panel/panel-dummy.c | 103 +++++++
>> drivers/video/panel/panel-r61505.c | 520 ++++++++++++++++++++++++++++++++++++
>> drivers/video/panel/panel-r61517.c | 408 ++++++++++++++++++++++++++++
>> drivers/video/panel/panel.c | 269 +++++++++++++++++++
>> include/video/panel-dbi.h | 92 +++++++
>> include/video/panel-dummy.h | 25 ++
>> include/video/panel-r61505.h | 27 ++
>> include/video/panel-r61517.h | 28 ++
>> include/video/panel.h | 111 ++++++++
>> 14 files changed, 1844 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/video/panel/Kconfig
>> create mode 100644 drivers/video/panel/Makefile
>> create mode 100644 drivers/video/panel/panel-dbi.c
>> create mode 100644 drivers/video/panel/panel-dummy.c
>> create mode 100644 drivers/video/panel/panel-r61505.c
>> create mode 100644 drivers/video/panel/panel-r61517.c
>> create mode 100644 drivers/video/panel/panel.c
>> create mode 100644 include/video/panel-dbi.h
>> create mode 100644 include/video/panel-dummy.h
>> create mode 100644 include/video/panel-r61505.h
>> create mode 100644 include/video/panel-r61517.h
>> create mode 100644 include/video/panel.h
>> Laurent Pinchart
>> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the dri-devel