Hi Inki, On Saturday 20 October 2012 22:10:17 Inki Dae wrote: > Hi Laurent. sorry for being late. No worries. > 2012/8/17 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>: > > 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 > > 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. > > 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). After discussing the generic panel framework at Linaro Connect, we came to the conclusion that "panel" is too limiting a name. I will send an RFC v2 titled "common display framework", with a drivers/video/display/ directory. I'm unsure whether panels should go to drivers/video/panels/ or drivers/video/display/panels/. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
