Hi,
On Tuesday 01 March 2011 09:26 PM, Valkeinen, Tomi wrote:
On Tue, 2011-03-01 at 06:32 -0600, Taneja, Archit wrote:
The current DSI driver design requires the DSI panel driver to specify the
DSI Virtual Channel and the Panel Virtual Channel ID for the transfer of
commands and frame data. Out of these, only the second parameter is a property
of the Panel.
The DSI Virtual Channel in use by the panel driver ideally shouldn't be provided
by the panel driver. The current design leads to the following issues:
-Multiple panels connected to the same DSI interface would be unaware of the
VC's in use.
-Hard coded Virtual Channel numbers in panel drivers which is not generic.
-No clean way of configuring DSI for panels which need atleast 2 DSI Virtual
Channels.
-No clean way of configuring DSI for the special case where a panel may have 2
or VC ID's corresponding to it.
The panel driver should, instead, request for, and release DSI Virtual Channels
through calls to the DSI driver. The DSI driver should return VC numbers which
the panel can use. The panel driver then uses this VC to either send pixel data,
send commands and receive data from the panel. The DSI driver then automatically
configures the Virtual Channel source to either Video Port or L4 Slave Port.
This patch set tries to achieve the above design, and make Panel Taal driver use
this approach.
This patch set doesn't apply, and seems not to be based on Linus',
Tony's or my tree. What is it based on?
This is based on your master with a few patches I posted on l-o before
which haven't been applied yet. I will make sure I mention the pending
patches required when I post the next version.
Archit
You should always base the patches on top of a public tree before
sending the patches. Otherwise it is difficult to apply those patches.
Or clearly say the required patch sets, which have previously been sent
for review, but not yet applied.
Tomi
--
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
