[RFC v2 PATCH] mipi-dsi-bus: add MIPI DSI bus support

[Thierry Reding]

On Fri, Dec 13, 2013 at 01:29:17PM +0200, Tomi Valkeinen wrote:
> On 2013-12-13 13:22, Andrzej Hajda wrote:
> > On 12/12/2013 01:19 PM, Thierry Reding wrote:
> >> On Tue, Dec 10, 2013 at 11:19:54AM +0200, Tomi Valkeinen wrote:
> >>> On 2013-12-09 18:10, Thierry Reding wrote:
> >>>
> >>> Btw, about single linux device handling multiple VC IDs: I noticed that
> >>> the DSI spec has an example, in which a DSI peripheral receives
> >>> interlaced video, and the video packets containing even field have VC ID
> >>> 0 and packets for odd field have VC ID 1. I'm not sure how relevant
> >>> interlaced video is, but I think there's an example where having
> >>> separate linux devices for each VC ID would be somewhat clumsy.
> >> Ugh... that's pretty bad.
> > I wonder if this scenario could not be solved just
> > by allowing range of VCs per device, for example:
> > dsi {
> >         #address-cells = <1>;
> >         #size-cells = <1>;
> >         panel_with_interleaved_vc at 0 {
> >              reg = <0, 2>;
> >         };
> > };
> 
> I don't think range is good, as then you can't have, say, VC IDs 0 and
> 2. But giving the VC IDs individually as I did in my recent reply,
> should do the same thing as above, without ranges.
> 
> It's still open to me if that method is good or not.

I think we can actually support both of those variants with the same
binding. #address-cells = <1> and #size-cells = <0> means that every
device has a single address, which matches Tomi's example:

	dsi {
		peripheral at 0 {
			reg = <0,  /* first VC ID */
			       2>; /* second VC ID */
		};
	};

The difference to what Andrzej proposed is that we additionally have
#size-cells = <1>, which implies each entry in reg can have a "size" as
well:

	dsi {
		peripheral at 0 {
			reg = <0 2>; /* VC IDs 0 and 1 */
		};
	};

While I could be wrong of course, I do think that the former is unlikely
since it's much easier to support consecutive addresses than completely
separate ones. Or perhaps it isn't. Either way I think the binding would
support both of those cases.

I'll see if I can come up with some wording to make that a part of the
binding and perhaps mention that only one-to-one relationships are taken
into account in the binding.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/e14cac52/attachment.pgp>