From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: [RFC v2 PATCH] mipi-dsi-bus: add MIPI DSI bus support Date: Fri, 13 Dec 2013 14:23:20 +0200 Message-ID: <52AAFC38.709@ti.com> References: <52A08FB3.5040800@ti.com> <20131206125424.GA30625@ulmo.nvidia.com> <52A5AAAE.5090601@ti.com> <20131209131015.GB17693@ulmo.nvidia.com> <52A5DC30.5030801@ti.com> <20131209161048.GA11742@ulmo.nvidia.com> <52A6DCBA.7060801@ti.com> <20131212121941.GF11524@ulmo.nvidia.com> <52AAEDEB.5090102@samsung.com> <52AAEF8D.7040804@ti.com> <20131213120603.GA9820@ulmo.nvidia.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0364426905==" Return-path: Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by gabe.freedesktop.org (Postfix) with ESMTP id 7E469FAB49 for ; Fri, 13 Dec 2013 04:23:24 -0800 (PST) In-Reply-To: <20131213120603.GA9820@ulmo.nvidia.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: Thierry Reding Cc: Andrzej Hajda , Kyungmin Park , Thierry Reding , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0364426905== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="50Cm3BFv6SJNWvwNxUnE0WOJvk3igjFee" --50Cm3BFv6SJNWvwNxUnE0WOJvk3igjFee Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 =3D <1>; >>> #size-cells =3D <1>; >>> panel_with_interleaved_vc@0 { >>> reg =3D <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. >=20 > I think we can actually support both of those variants with the same > binding. #address-cells =3D <1> and #size-cells =3D <0> means that ever= y > device has a single address, which matches Tomi's example: >=20 > dsi { > peripheral@0 { > reg =3D <0, /* first VC ID */ > 2>; /* second VC ID */ > }; > }; >=20 > The difference to what Andrzej proposed is that we additionally have > #size-cells =3D <1>, which implies each entry in reg can have a "size" = as > well: >=20 > dsi { > peripheral@0 { > reg =3D <0 2>; /* VC IDs 0 and 1 */ > }; > }; >=20 > While I could be wrong of course, I do think that the former is unlikel= y > since it's much easier to support consecutive addresses than completely= > separate ones. Or perhaps it isn't. Either way I think the binding woul= d > support both of those cases. Right, and even if #size-cells =3D <1>, you can have multiple distinct VC= IDs: /* two ranges, 0-0 and 2-2 */ reg =3D <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 --50Cm3BFv6SJNWvwNxUnE0WOJvk3igjFee Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSqvw4AAoJEPo9qoy8lh716FoQAJ5WoRMI2aO8FSL90ke8HlDt 5GTgggINnb2hNdNQK95MzqI2T2kbOfU0uU31DE9/B0NfDx/gr9sF8m2W2JvUij8u OyDoPH/fKUJMOqtCufgAE3pdHJKITYqXiI2Y62XyLwEAgirBlE9tep9mxFeWi/yn u6sPLiRoayAuMIHZ63MoFCysVHEIiXE0r4QXn1odQcEFmUsmXKT5225EQFUUiFWW Ceaw/siwHEmRN+ZaBgnLcoVTSHTZmjQGGUVWF4Q/OuV/ZDGyd0b1KRdbm+VVW7YE m230+nYfPC2RyjyBkKnSzSXd7TN6f0rURPLOYlmlYwAXUPnPsRq5A2aoTPB2Hiak ObUdfgabC0xxUDf4KnAsd32x59WCVZMtsMYc0cJznj+MiQ59YSo2mYvOQbL/YhZg Ajl4qwsYoVdLqemaglhCv8yx5/+ffFnF2uukJWr9fWQUIBa+NAkt/ssvFUQVl4mZ WaK6xr0trQsmi00XyCiOGNC9bMZRjbX7IGmCFMXE8poSDss/Q8U7AyshWvyMWRVJ nWyzt0h0VurnbPxegLn8ePOmexVskLSufT69c5uyZiCpBBKUgxiJxQxWf44iyY2z 6Po4OQcaXFdEsS4hjGGInnVbLOpqEcXpvW2QA2Y98Ot5TcIiVJ3POYA/Unz7WZlk UobbaEfiuFipUDQUQ1Au =FlZT -----END PGP SIGNATURE----- --50Cm3BFv6SJNWvwNxUnE0WOJvk3igjFee-- --===============0364426905== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0364426905==--