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 framework. 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 account. 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 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 -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
