Hi Notaz, I have improved the sketch of my SSD2858 driver a little so that I hope the structure becomes a little more clear.
The basic idea is to glue the SSD2858 as an “encoder” between the OMAP5 DSI output and the Panel driver input.
This is done in the DT by plumbing two endpoints to the SSD driver, one for “in” (from OMAP) and the other for “out” (to the Panel).
An important design goal is that the panel driver is the same as with no rotator.
This means that the panel driver does send some operations (ops) to its “in” port. These ops are defined as struct omapdss_dsi_ops (see http://lxr.free-electrons.com/source/include/video/omapdss.h#L811).
The role of the SSD driver must be to intercept these requests and modify them into register settings of the SSD chip and potentially modified requests to the OMAP5 (in->ops.dsi).
For example if the panel driver wants to send a DCS 0x10 command, it will call (indirectly) a from_panel_dcs_write_nosync function in the SSD driver.
This function switches the SSD2858 to pass-through mode first (so that the command will be passed to the panel and not modify the SSD2858 registers). And then, the request is forwarded to the OMAP5 DSI driver.
The OMAP5 driver will make the MIPI interface send the DCS 0x10 command through the MIPI display cable where the SSD will receive it. And the SSD was instructed to forward and will send it out directly to the display connector. The Panel finally receives the 0x10 command - as instructed by the Panel driver.
I have pushed my current status which is far from working so that you can read into the code and check how I think the driver structure should look like.
It is “just compiling with some warnings” but not tested and most likely not working.
There are of course many thing missing * implementation of all required omapdss_dsi_ops the panel may ask for * forwarding power management requests (which come from the OMAP DSS driver) * correctly setting up the omapdss_dsi_ops during probing * correct sequence of probing (there might be a dependency) * some interface for controlling the rotation (and scaling) capabilities of the SSD (there is a get_rotate and set_rotate function in the omapdss_driver ops which could be what we need or we add some /sys node). * handling/translation of the panel timings into timings for the connection from OMAP to SSD * general code-cleanup (but it is too floating to do that now)
Please look through the code and feel free to ask about my thoughts not expressed in code yet:
http://dev.pyra-handheld.com/cgi-bin/gitweb.cgi?p=pyra-kernel.git;a=blob;f=d...
BR, Nikolaus