Re: [RFC 0/5] Generic panel framework

Inki Dae
2012-10-20T13:10:17Z

Hi Laurent. sorry for being late.

2012/8/17 Laurent Pinchart <laurent.pinchart@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
> 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).

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