devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
To: Thierry Reding
	<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Andrzej Hajda <a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Cc: Laurent Pinchart
	<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>,
	YoungJun Cho <yj44.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	Ajay Kumar <ajaykumar.rs-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Dual-channel DSI
Date: Thu, 14 Aug 2014 15:59:08 +0300	[thread overview]
Message-ID: <53ECB29C.7070703@ti.com> (raw)
In-Reply-To: <20140808101447.GF15852@ulmo>

[-- Attachment #1: Type: text/plain, Size: 4481 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

      parent reply	other threads:[~2014-08-14 12:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-05 15:39 Dual-channel DSI Thierry Reding
2014-08-07  6:53 ` Andrzej Hajda
2014-08-07  7:25   ` Thierry Reding
2014-08-07  8:39     ` Andrzej Hajda
2014-08-07  8:54       ` Thierry Reding
2014-08-08  7:26         ` Andrzej Hajda
2014-08-08 10:14           ` Thierry Reding
2014-08-12 16:00             ` Andrzej Hajda
2014-08-14 12:59             ` Tomi Valkeinen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53ECB29C.7070703@ti.com \
    --to=tomi.valkeinen-l0cymroini0@public.gmane.org \
    --cc=a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=ajaykumar.rs-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=yj44.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).