Hi,
We (TI) have been working on a DSI video mode driver for OMAP4 and I
am aware that other people are working with similar drivers. We had to
tweak the code to make the drivers work with current code but we would
like to make it the correct way, that is, introducing a proper
functionality instead of inserting tweaks in the present command mode
driver. Therefore, there is an initiative from us to modify current
dss/dsi code to support DSI video mode.
We have collected a list of requirements and ideas (with the help of
ppl copied) from our experience working with these drivers, but it
would be great if you can discuss/comment further on this.
Requirements:
- A better way of exposing VC's to a panel driver, since most panels
use more than one VC. Currently the design supports only one per
panel. Perhaps a VC resource pool could be created.
- A way of imposing restrictions on clock sources based on dsi mode.
- Runtime calculation of required clocks and PLL parameters. This is
to reduce complexity in clock calculations, specially when having two
panels running at the same time.
- A way to pass specific requirements from panel driver to DSI driver
(enable/disable BTA, set HS Clk always on, etc).
- Remove some hardcoded values in dsi.c and make the panel pass the
information to DSI driver(RX, TX fifo sizes of VCs, enabling/disabling
dsi timers, etc)
- A cleaner way of handling both DSI1 and DSI2 blocks(and more in
omap5) in the same driver.
- A way to easily set non-burst event mode, non-burst pulse mode and
burst mode configuration as defined on DSI protocol specs.
- A way to calculate correct DSI blanking parameters based on panel
blanking requirements (for DSI Video panels, these will be have to be
specified statically somewhere, much like DPI displays).
- Remove timeout error/warnings when disabling dsi phy interface since
on video mode it should wait instead for next vsync.
Design ideas:
- It could actually be worthwhile to have separate files for command
and video mode and a core dsi driver file.
- We can have a enum like this to choose between modes:
plat/display.h can have an enum like:
enum omap_dss_dsi_mode {
OMAP_DSS_DSI_CMDMODE = 1 << 0,
OMAP_DSS_DSI_VIDEOMODE = 1 << 1,
};
Nit pick - either make it #define and have bit offset as above OR
Better still, you wont need both at the same time, so bit offset wont be
useful too much.. OMAP_DSS_DSI_CMDMODE = 1, OMAP_DSS_DSI_VIDEOMODE = 2,
- If we want a user to switch between modes, we may need to have a
member like "supported_modes" which could check if the desired mode is
supported by the panel. Switching between modes at runtime would be
quite unlikely (and hard). We might want to stick with the above if we
want a member like supported_modes:
.supported_modes = OMAP_DSS_DSI_CMDMODE | OMAP_DSS_DSI_VIDEOMODE;
- The dssdev struct can have a member dsi_mode of the above type.
- This would look nice in the board file and would also be useful if
there are multiple panels.
- We can have a bootarg to choose one of the modes (module parameter),
the driver can check against this member during init.
Let me know any comments...
Regards,
Jorge Bustamante
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
