Hi everybody,
Here's the second RFC of what was previously known as the Generic Panel
Framework.
I won't repeat all the background information from the first version here, you
can read it at http://lwn.net/Articles/512363/.
Many developers showed interest in the first RFC, and I've had the opportunity
to discuss it with most of them. I would like to thank (in no particular
order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus
Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for
inviting me to Connect and providing a venue to discuss this topic.
After discussing the Generic Panel Framework at Linaro Connect we came to the
conclusion that "panel" is too limiting a name. In addition to panel drivers
we also want to share transmitter and bridge drivers between DRM and FBDEV. I
have thus introduced the concept of a display entity in this version to
represent any hardware block that sources, processes or sinks display-related
video streams. This patch set implements the Common Display Framework (CDF).
Display entities are connected to at least one video data bus, and optionally
to a control bus. The video data busses carry display-related video data out
of sources (such as a CRTC in a display controller) to sinks (such as a panel
or a monitor), optionally going through transmitters, encoders, decoders,
bridges or other similar devices. A CRTC or a panel will usually be connected
to a single data bus, while an encoder or a transmitter will be connected to
two data busses.
While some display entities don't require any configuration (DPI panels are a
good example), many of them are connected to a control bus accessible to the
CPU. Control requests can be sent on a dedicated control bus (such as I2C or
SPI) or multiplexed on a mixed control and data bus (such as DBI or DSI). To
support both options the CDF display entity model separates the control and
data busses in different APIs.
Display entities are abstract object that must be implemented by a real
device. The device sits on its control bus and is registered with the Linux
device core and matched with his driver using the control bus specific API.
The CDF doesn't create a display entity class or bus, display entity drivers
thus standard Linux kernel drivers using existing busses.
When a display entity driver probes a device it must create an instance of the
display_entity structure, initialize it and register it with the CDF core. The
display entity exposes abstract operations through function pointers, and the
entity driver must implement those operations. They are divided in two groups,
control operations and video operations.
Control operations are called by upper-level drivers, usually in response to a
request originating from userspace. They control the display entity state and
operation. Currently defined control operations are
- set_state(), to control the state of the entity (off, standby or on)
- update(), to trigger a display update (for entities that implement manual
update, such as manual-update panels that store frames in their internal
frame buffer)
- get_modes(), to retrieve the video modes supported by the entity
- get_params(), to retrive the data bus parameters at the entity input (sink)
- get_size(), to retrive the entity physical size (applicable to panels only)
Video operations are called by downstream entities on upstream entities (from
a video data bus point of view) to control the video operation. The only
currently defined video operation is
- set_stream(), to start (in continuous or single-shot mode) the video stream
http://www.ideasonboard.org/media/cdf/cdf.pdf#1 describes how a panel driver
implemented using the CDF interacts with the other components in the system.
The first page shows the panel driver receiving control request from the
display controller driver at its top side, usually in response to a DRM or
FBDEV API call. It then issues requests on its control bus (several possible
control busses are shown on the diagram, the panel driver uses one of them
only) and calls video operations of the display controller on its left side to
control the video stream.
The second page shows a slightly more complex use case, with a display
controller that includes an LVDS transceiver (shown as two separate entities
on the left hand side), connected to an LVDS to DSI converter that is itself
connected to a DSI panel module. The panel module contains a DSI panel
controller that drives the LCD panel. While this particular example is
probably too theoretical to be found in real devices, it illustrates the
concept of display entities chains.
The CDF models this using a Russian doll's model. From the display controller
point of view only the first external entity (LVDS to DSI converter) is
visible. The display controller thus calls the control operations implemented
by the LVDS to DSI transmitter driver (left-most green arrow). The driver is
aware of the next entity in the chain, and relays the call down, possibly
mangling the request and/or the reply, and accessing the device it handles
through its control bus (not shown here). When the operations reaches the last
entity in the chain the video operations are called upstream to control the
video stream.
Display entities are accessed by driver using notifiers. Any driver can
register a display entity notifier with the CDF, which then calls the notifier
when a matching display entity is registered. The reason for this asynchronous
mode of operation, compared to how drivers acquire regulator or clock
resources, is that the display entities 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 other display entities through a notification system seemed to be the
easiest solution.
Note that this brings a different issue after registration, as display
controller and display entity drivers would take a reference to each other.
Those circular references would make driver unloading impossible. One possible
solution to this problem would be to simulate an unplug event for the display
entity, to force the display driver to release the dislay entities it uses. We
would need a userspace API for that though. Better solutions would of course
be welcome.
Please note taht most of the display entities on devices I own are jut 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. This is why I
hope to see you using the CDF with your display device and tell me what needs
to be modified/improved/redesigned.
This patch set includes three sections:
- The first patch adds the generic display entity core
- The third patch adds a MIPI DBI bus, which is a mixed control and data video
bus using parallel data (similarly to a microprocessor external data bus)
- The second, fourth and fifth patches add drivers for DPI panels (no control
bus) and two DBI panel controllers.
The patches are available in my git tree at
git://linuxtv.org/pinchartl/fbdev.git lcdc-panel
http://git.linuxtv.org/pinchartl/fbdev.git/shortlog/refs/heads/lcdc-panel
For convenience I've included Steffen's display helpers patches on which this
series is based (see http://www.spinics.net/lists/dri-devel/msg30664.html for
more information about those), as well as modifications to the sh-mobile-lcdc
driver to use the CDF. You can read the code to see how the driver uses the
CDF to interface panels. Please note that the sh-mobile-lcdc implementation is
still work in progress, its set_stream operation implementation doesn't
enable/disable the video stream yet as it should.
I still need to gather notes from v1 and v2 and create proper documentation
from them. I didn't want to delay these patches any longer given the number of
people who were waiting for them, I will try to do work on documentation next
week.
As already mentioned in v1, 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.
Laurent Pinchart (5):
video: Add generic display entity core
video: panel: Add DPI panel support
video: display: 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/display/Kconfig | 39 +++
drivers/video/display/Makefile | 5 +
drivers/video/display/display-core.c | 362 ++++++++++++++++++++++
drivers/video/display/mipi-dbi-bus.c | 228 ++++++++++++++
drivers/video/display/panel-dpi.c | 147 +++++++++
drivers/video/display/panel-r61505.c | 554 ++++++++++++++++++++++++++++++++++
drivers/video/display/panel-r61517.c | 447 +++++++++++++++++++++++++++
include/video/display.h | 155 ++++++++++
include/video/mipi-dbi-bus.h | 125 ++++++++
include/video/panel-dpi.h | 24 ++
include/video/panel-r61505.h | 27 ++
include/video/panel-r61517.h | 28 ++
14 files changed, 2143 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/display/Kconfig
create mode 100644 drivers/video/display/Makefile
create mode 100644 drivers/video/display/display-core.c
create mode 100644 drivers/video/display/mipi-dbi-bus.c
create mode 100644 drivers/video/display/panel-dpi.c
create mode 100644 drivers/video/display/panel-r61505.c
create mode 100644 drivers/video/display/panel-r61517.c
create mode 100644 include/video/display.h
create mode 100644 include/video/mipi-dbi-bus.h
create mode 100644 include/video/panel-dpi.h
create mode 100644 include/video/panel-r61505.h
create mode 100644 include/video/panel-r61517.h
Hi All,
I was thinking of porting samsung exynos 5250 display driver as per CDF,
but i had certain doubts and wanted to discuss with you guys,
1. Samsung Exynos supports MIPI DSI based display panels, wondering how to accommodate such thing in
CDF. I mean how do I register my MIPI DSI driver with CDF.
because the s6e8ax0 AMOLED lcd driver registers itself with MIPI DSI driver, and later the MIPI DSI driver probe calls the probe and init sequence of the LCD driver.
Wanted know if anybody about any thoughts on this ?
2.One more thing is, when went through the patchset I coudn't get who will register the mipi_dbi_bus_ops?
Regards
Vikas Sajjan
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
