All of lore.kernel.org
 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 --]

WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Thierry Reding <thierry.reding@gmail.com>,
	Andrzej Hajda <a.hajda@samsung.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	YoungJun Cho <yj44.cho@samsung.com>,
	Ajay Kumar <ajaykumar.rs@samsung.com>,
	<dri-devel@lists.freedesktop.org>, <devicetree@vger.kernel.org>,
	<linux-kernel@vger.kernel.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: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-05 15:39 Dual-channel DSI Thierry Reding
2014-08-05 15:39 ` Thierry Reding
2014-08-07  6:53 ` Andrzej Hajda
2014-08-07  7:25   ` Thierry Reding
2014-08-07  7:25     ` Thierry Reding
2014-08-07  8:39     ` Andrzej Hajda
2014-08-07  8:39       ` Andrzej Hajda
2014-08-07  8:54       ` Thierry Reding
2014-08-07  8:54         ` Thierry Reding
2014-08-08  7:26         ` Andrzej Hajda
2014-08-08  7:26           ` Andrzej Hajda
2014-08-08 10:14           ` Thierry Reding
2014-08-08 10:14             ` Thierry Reding
2014-08-12 16:00             ` Andrzej Hajda
2014-08-12 16:00               ` Andrzej Hajda
2014-08-14 12:59             ` Tomi Valkeinen [this message]
2014-08-14 12:59               ` Tomi Valkeinen

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.