We are about to remove the dss bus support, which also means that the
omap_dss_device won't be a real device anymore. This means that the
embedded "dev" struct needs to be removed from omap_dss_device.
After we've finished the removal of the dss bus, we see the following
changes:
- struct omap_dss_device won't be a real Linux device anymore, but more
like a "display entity".
- struct omap_dss_driver won't be a Linux device driver, but "display
entity ops".
- The panel devices/drivers won't be omapdss devices/drivers, but
platform/i2c/spi/etc devices/drivers, whichever fits the control
mechanism of the panel.
- The panel drivers will create omap_dss_device and omap_dss_driver,
fill the required fields, and register the omap_dss_device to
omapdss.
- omap_dss_device won't have an embedded dev struct anymore, but a
dev pointer to the actual device that manages the omap_dss_device.
The model described above resembles the model that has been discussed
with CDF (common display framework).
For the duration of the conversion, we temporarily have two devs in the
dssdev, the old "old_dev", which is a full embedded device struct, and the
new "dev", which is a pointer to the device. "old_dev" will be removed
in the future.
For devices belonging to dss bus the dev is initialized to point to
old_dev. This way all the code can just use the dev, for both old and
new style panels.
Both the new and old style panel drivers work during the conversion, and
only after the dss bus support is removed will the old style panels stop
to compile.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The panel drivers contain enable, disable, suspend and resume calls.
The suspend and resume are effectively identical to disable and enable.
This patch removes panel suspend and enable code from omapdss and the
panel drivers, and replaces their use with enable and disable.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The VENC driver currently relies on the omap_dss_device struct to configure the
video output polarity. This makes the VENC interface driver dependent on the
omap_dss_device struct.
Make the VENC driver data maintain it's own polarity field. A panel driver
is expected to call omapdss_venc_invert_vid_out_polarity() before enabling the
interface.
Signed-off-by: Archit Taneja <archit@ti.com>
The VENC driver currently relies on the omap_dss_device struct to configure the
venc type. This makes the VENC interface driver dependent on the omap_dss_device
struct.
Make the VENC driver data maintain it's own 'venc type' field. A panel driver
is expected to call omapdss_venc_set_type() before enabling the interface or
changing the type via display sysfs attributes.
Signed-off-by: Archit Taneja <archit@ti.com>
The VENC driver currently relies on the timings in omap_dss_device struct to
configure the DISPC and VENC blocks accordingly. This makes the VENC interface
driver dependent on the omap_dss_device struct.
Make the VENC driver data maintain it's own timings field. The panel driver is
expected to call omapdss_venc_set_timings() to set these timings before the
panel is enabled. Call omapdss_venc_set_timings() before enabling
venc output, this is done to atleast have the venc output configured to the
panel's default timings if the DSS user didn't explicitly call the venc panel
driver's set_timings op.
Make the VENC panel driver configure the new timings is the omap_dss_device
struct(dssdev->panel.timings). The VENC driver is responsible for maintaining
only it's own copy of timings.
Signed-off-by: Archit Taneja <archit@ti.com>
The current venc.c driver contains both the interface and panel driver code.
This makes the driver hard to read, and difficult to understand the work split
between the interface and panel driver and the how the locking works.
This also makes it easier to clearly define the VENC interface ops called by the
panel driver.
Split venc.c into venc.c and venc_panel.c representing the interface and panel
driver respectively. This split is done along the lines of the HDMI interface
and panel drivers.
Signed-off-by: Archit Taneja <archit@ti.com>
