Features Download
From: Tomi Valkeinen <tomi.valkeinen <at> ti.com>
Subject: [RFC 0/6] Common Display Framework-T
Newsgroups: gmane.comp.video.dri.devel
Date: Friday 14th December 2012 14:27:26 UTC (over 5 years ago)

I have been testing Common Display Framework on OMAP, and making changes
I've discussed in the posts I've sent in reply to the CDF series from
While my CDF code is rather hacky and not at all ready, I wanted to post
code for comments and also as a reference code to my posts.

So here is CDF-T (Tomi-edition =). 

Changes compared to Laurent's CDF

- DBI bus is removed. I don't have any DBI devices, and as I said in my
  I didn't see need for a real bus for DBI (or DSI). I thus also removed
  DBI panels.

- Split the display_entity into two parts: video_source, which is used to
  connect the display chips and panels, and display_entity, which represent
  either the panel or the whole pipeline (I'm not sure which is better).

- Added ops for DVI and DSI

- Added driver for TFP410, a DPI to DVI converter chip
- Added driver for generic DVI monitor
- Added driver for Taal, a DSI command mode panel

- Removed DISPLAY_ENTITY_STREAM_SINGLE_SHOT, and instead there's update()
  It's perhaps possible to use the single-shot method, but I went for a
  separate op to get a "update done"-callback implemented easily.

Notes about the code

As I said, the code is rather untidy, but I think it's more or less
understandable. I've skipped adding any helper funcs, for example to call
ops, so it's easier for me to change the API.

I also (ab)used some of the omapdss panel headers to ease my hacking for
omapdss+cdf. These should be quite clear.

The code, including hacks to omapdss to make it use CDF, can be found from:

The DSI part is very unfinished. I am able to use it to start up the Taal
panel, and send frames to the panel, but it's really missing lots of stuff.

About display_entity & video_source

I've discussed this split in previous posts, but I'll describe it here

As I see it, the connections between the display blocks, and the use of the
panel (and thus the whole pipeline) are very different things, and I think
should be separated. So in my version I have struct video_source, used to
connect the blocks, and display_entity, representing the panel or the whole
pipeline. display_entity is probably not a good name for it anymore, but I
didn't come up with a good one yet.

As an example, let's look at chip-tfp410.c and panel-dvi.c.

tfp410 uses two video_sources, one for input and one for output. The input
comes from some other display block, in my case from OMAP display
OMAP DSS has registered a DPI video_source, and the tfp410 driver will get
source using video_source_find().

tfp410 registers its output as a video source, using video_source_register.
panel-dvi will in turn use video_source_find() to get it.

Both drivers use video_source to configure the input bus, i.e. tfp410
configures the DPI bus between OMAP DSS and TFP410 using, for example,
set_data_lines op to configure the number of datalines on the DPI bus.

With the video_sources in place, the whole video pipeline can be used.
we still need to expose an API so that somebody can actually use the
This is done with display_entity. display_entity contains higher level ops,
which are not bus specific. The display_entity is registered by the panel
the end of the chain.

In my model the display_entity ops go to the panel driver, which then calls
in the input video source to do the work. Laurent has objected to this
and would rather have the display_entity ops go to the DSS side (if I
understood right), which would then propagate forward towards the panel. I
still kept my model, as I don't see the downsides with my model, nor do I
any use for propagating the ops from DSS to the panel. But I'm happy to
examples how it is beneficial and could be used.

About the bus model

Lauren't version uses a linux bus for DBI. The idea here is that DBI is the
control bus fro the panel/chip, and should thus be represented by a real
While I agreed to this approach when we discussed about it, I now am
against it.

My reason is that DBI (or DSI or any other similar bus) is not really
bus, it is a video bus. It _can_ be used for control, but video is the main
purpose. This has the partical issues:

- There's never use for DBI only for control. DBI is always used for either
  video only, or control+video.

- If DBI is used only for video, there's no DBI bus. How to configure DBI
  this case?

- If DBI is used for control and video, we have two separate APIs for the
  In theory it's possible to handle this, but in practice it may be
  especially for more complex busses like DSI.

So in my version I added DSI as a plain video_source, without a real linux
I think this model is a lot simpler, and works better.


Tomi Valkeinen (6):
  video: add display-core
  video: add generic dpi panel
  video: add tfp410
  video: add generic dvi monitor
  video: add taal panel
  video: add makefile & kconfig

 drivers/video/Kconfig                |    1 +
 drivers/video/Makefile               |    1 +
 drivers/video/display/Kconfig        |   26 +++
 drivers/video/display/Makefile       |    5 +
 drivers/video/display/chip-tfp410.c  |  164 +++++++++++++++
 drivers/video/display/display-core.c |  207 ++++++++++++++++++
 drivers/video/display/panel-dpi.c    |  155 ++++++++++++++
 drivers/video/display/panel-dvi.c    |  164 +++++++++++++++
 drivers/video/display/panel-taal.c   |  383
 include/video/display.h              |  166 +++++++++++++++
 include/video/omap-panel-nokia-dsi.h |    4 +-
 include/video/omap-panel-tfp410.h    |    4 +
 include/video/panel-dpi.h            |   25 +++
 include/video/panel-dvi.h            |   18 ++
 14 files changed, 1321 insertions(+), 2 deletions(-)
 create mode 100644 drivers/video/display/Kconfig
 create mode 100644 drivers/video/display/Makefile
 create mode 100644 drivers/video/display/chip-tfp410.c
 create mode 100644 drivers/video/display/display-core.c
 create mode 100644 drivers/video/display/panel-dpi.c
 create mode 100644 drivers/video/display/panel-dvi.c
 create mode 100644 drivers/video/display/panel-taal.c
 create mode 100644 include/video/display.h
 create mode 100644 include/video/panel-dpi.h
 create mode 100644 include/video/panel-dvi.h

CD: 3ms