Dual-channel DSI

[Tomi Valkeinen]

On 08/08/14 13:14, Thierry Reding wrote:
> On Fri, Aug 08, 2014 at 09:26:17AM +0200, Andrzej Hajda wrote:
>> On 08/07/2014 10:54 AM, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 10:39:36AM +0200, Andrzej Hajda wrote:
>>>> On 08/07/2014 09:25 AM, Thierry Reding wrote:
>>>>> On Thu, Aug 07, 2014 at 08:53:47AM +0200, Andrzej Hajda wrote:
>>>>>> Hi Thierry,
>>>>>>
>>>>>> Nice case.
>>>>>>
>>>>>> On 08/05/2014 05:39 PM, Thierry Reding wrote:
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> I've been working on adding support for a panel that uses what's
>>>>>>> commonly known as dual-channel DSI. Sometimes this is referred to as
>>>>>>> ganged-mode as well.
>>>>>>>
>>>>>>> What is it, you ask? It's essentially a hack to work around the band-
>>>>>>> width restrictions of DSI, albeit one that's been commonly implemented
>>>>>>> by several SoC vendors.
>>>>>>>
>>>>>>> This typically works by equipping a peripheral with two DSI interfaces,
>>>>>>> each of which driving one half of the screen (symmetric left-right mode)
>>>>>>> or every other line (symmetric odd-even mode). Apparently there can be
>>>>>>> asymmetric modes in addition to those two, but they seem to be the
>>>>>>> common ones. Often both of the DSI interfaces need to be configured
>>>>>>> using DCS commands and vendor specific registers.
>>>>>>>
>>>>>>> A single display controller is typically used video data transmission.
>>>>>>> This is necessary to provide synchronization and avoid tearing and all
>>>>>>> kinds of other ugliness. For this to work both DSI controllers need to
>>>>>>> be made aware of which chunk of the video data stream is addressing
>>>>>>> them.
>>>>>>>
>>>>>>> From a software perspective, this poses two problems:
>>>>>>>
>>>>>>> 1) A dual-channel device is composed of two DSI peripheral devices which
>>>>>>>    cannot be programmed independently of each other. A typical example
>>>>>>>    is that the frame memory extents need to be configured differently
>>>>>>>    for each of the devices (using the DCS set_column_address and
>>>>>>>    set_page_address commands). Therefore each device must know of the
>>>>>>>    other, or there must be a driver that binds against a dummy device
>>>>>>>    that pulls in the two real devices.

I once almost had to write a driver for similar panel, but luckily the project
was canceled. =)

Here are some thoughts:

If we had a panel which is controlled via i2c, but receives the video stream
from two DSI interfaces, I think the DT would look something like:

&i2c1 {
	display at 48 {
		compatible = "sharp,lq101r1sx01";
		reg = <0x48>;

		ports {
			port at 0 {
				reg = <0>;
				lcd_in0: endpoint {
					remote-endpoint = <&dsi1_out_ep>;
				};
			};

			port at 1 {
				reg = <1>;
				lcd_in1: endpoint {
					remote-endpoint = <&dsi2_out_ep>;
				};
			};
		};
	};
};

&dsi1 {
	port {
		dsi1_out_ep: endpoint {
			remote-endpoint = <&lcd_in0>;
			lanes = <0 1 2 3 4 5>;
		};
	};

};

&dsi2 {
	port {
		dsi2_out_ep: endpoint {
			remote-endpoint = <&lcd_in1>;
			lanes = <0 1 2 3 4 5>;
		};
	};
};

And similarly, if the panel would be controlled via DSI, but only via one DSI
interface, I think the DT would look quite similar, except the "display" node
would be a child of "dsi1".

Now, a panel controlled via two DSI interfaces. I have to say the design sounds
rather nasty. What were the HW people thinking about? I guess you are _sure_
that you cannot do the configuration via just a single interface? =)

If you really need the control via two DSI interfaces, I'd suggest something
like this:

&dsi1 {
	port {
		dsi1_out_ep: endpoint {
			remote-endpoint = <&lcd_in0>;
			lanes = <0 1 2 3 4 5>;
		};
	};

	display {
		compatible = "sharp,lq101r1sx01";

		secondary = <&panel_secondary>;

		port {
			lcd_in0: endpoint {
				remote-endpoint = <&dsi1_out_ep>;
			};
		};
	};
};

&dsi2 {
	port {
		dsi2_out_ep: endpoint {
			remote-endpoint = <&lcd_in1>;
			lanes = <0 1 2 3 4 5>;
		};
	};

	panel_secondary: display {
		compatible = "sharp,lq101r1sx01-secondary";

		port {
			lcd_in1: endpoint {
				remote-endpoint = <&dsi2_out_ep>;
			};
		};
	};
};

I guess the above was already more or less presented in the thread, but I
didn't see it written out.

So there would two two devices, a master and a slave, and in the driver side
the slave would not do anything by itself.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140814/79f17c19/attachment-0001.sig>