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 [off-list ref]:

quoted

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