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
signature.asc
Description: OpenPGP digital signature
