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@48 {
compatible = "sharp,lq101r1sx01";
reg = <0x48>;
ports {
port@0 {
reg = <0>;
lcd_in0: endpoint {
remote-endpoint = <&dsi1_out_ep>;
};
};
port@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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
