[RFC 0/5] Generic panel framework

[Inki Dae]

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
>> 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

s/buses/busses

> '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).
>
> 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 at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html