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

[Tomi Valkeinen]

On 2013-12-13 14:06, Thierry Reding wrote:
> 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.

Right, and even if #size-cells = <1>, you can have multiple distinct VC IDs:

/* two ranges, 0-0 and 2-2 */
reg = <0 1 2 1>;

If there's a simple to use of_xxx helper function to get the VC IDs in
any case, I think we can easily support all those cases.

But if we need to parse the reg ourselves, and have different code paths
for #size-cells 0 and 1, I'd rather stick to the simplest model. No
point in having lots of code lines to handle different #size-cells, as
we most likely just one one VC ID.

I do agree that consecutive VC IDs sounds much more probable. However,
array of VC IDs work for all cases, but a (single) range doesn't. And we
can only have 4 VC IDs, so the biggest array would be <0 1 2 3>.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131213/c4ca637e/attachment-0001.pgp>