From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomi Valkeinen Subject: Re: [PATCH/RFC v3 00/19] Common Display Framework Date: Mon, 30 Sep 2013 16:48:54 +0300 Message-ID: <52498146.4050600@ti.com> References: <1376068510-30363-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0138924821==" Return-path: Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by gabe.freedesktop.org (Postfix) with ESMTP id 9FE4AE6F77 for ; Mon, 30 Sep 2013 06:49:17 -0700 (PDT) In-Reply-To: <1376068510-30363-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Laurent Pinchart Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, Jesse Barnes , Benjamin Gaignard , Tom Gall , Kyungmin Park , linux-media@vger.kernel.org, Stephen Warren , Mark Zhang , Alexandre Courbot , Ragesh Radhakrishnan , Thomas Petazzoni , Sunil Joshi , Maxime Ripard , Vikas Sajjan , Marcus Lorentzon List-Id: dri-devel@lists.freedesktop.org --===============0138924821== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AxNFc55mwEh156BP3EM2oME64e5E3aSUs" --AxNFc55mwEh156BP3EM2oME64e5E3aSUs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/08/13 20:14, Laurent Pinchart wrote: > Hi everybody, >=20 > Here's the third RFC of the Common Display Framework. Hi, I've been trying to adapt the latest CDF RFC for OMAP. I'm trying to gath= er some notes here about what I've discovered or how I see things. Some of t= hese I have mentioned earlier, but I'm trying to collect them here nevertheless.= I do have my branch with working DPI panel, TFP410 encoder, DVI-connector= and DSI command mode panel drivers, and modifications to make omapdss work wi= th CDF. However, it's such a big hack, that I'm not going to post it. I hop= e I will have time to work on it to get something publishable to have somethi= ng more concrete to present. But for the time being I have to move to other = tasks for a while, so I thought I'd better post some comments when I still reme= mber something about this. Using Linux buses for DBI/DSI =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D I still don't see how it would work. I've covered this multiple times in previous posts so I'm not going into more details now. I implemented DSI (just command mode for now) as a video bus but with bun= ch of extra ops for sending the control messages. Call model =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D It may be that I just don't get how things are supposed to work with the = RFC's ops, but I couldn't figure out how to use it in practice. I tried it for = a few days, but got nowhere, and I then went with the proven model that's used = in omapdss, where display entities handle calling the ops of the upstream entities. That's not to say the RFC's model doesn't work. I just didn't figure it o= ut. And I guess it was more difficult to understand how to use it as the cont= roller stuff is not implemented yet. It would be good to have a bit more complex cases in the RFC, like changi= ng and verifying videomodes, fetching them via EDID, etc. Multiple inputs/outputs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I think changing the model from single-input & single output to multiple = inputs and outputs increases the difficulty of the implementation considerably. = That's not a complaint as such, just an observation. I do think multiple inputs = & outputs is a good feature. Then again, all the use cases I have only have= single input/output, so I've been wondering if there's some middle road, = in which we somehow allow multiple inputs & outputs, but only implement the support for single input & output. I've cut the corners in my tests by just looking at a single enabled inpu= t or output from an entity, and ignoring the rest (which I don't have in my us= e cases). Internal connections =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The model currently only represents connections between entities. With mu= ltiple inputs & outputs I think it's important to maintain also connections insi= de the entity. Say, we have an entity with two inputs and two outputs. If one ou= tput is enabled, which one of the inputs needs to be enabled and configured al= so? The current model doesn't give any solution to that. I haven't implemented this, as in my use cases I have just single inputs = and outputs, so I can follow the pipeline trivially. Central entity =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D If I understand the RFC correctly, there's a "central" entity that manage= s all other entities connected to it. This central entity would normally be the= display controller. I don't like this model, as it makes it difficult or impossible to manage situations where an entity is connected to two displ= ay controllers (even if only one of the display controllers would be connect= ed at a time). It also makes this one display entity fundamentally different fr= om the others, which I don't like. I think all the display entities should be similar. They would all regist= er themselves to the CDF framework, which in turn would be used by somebody.= This somebody could be the display controller driver, which is more or less ho= w I've implemented it. Media entity/pads =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Using media_entity and media_pad fits quite well for CDF, but... It is qu= ite cumbersome to use. The constant switching between media_entity and display_entity needs quite a lot of code in total, as it has to be done a= lmost everywhere. And somehow I'd really like to combine the entity and port into one struc= t so that it would be possible to just do: src->ops->foo(src, ...); instead of src->ops->foo(src, srcport, ...); One reason is that the latter is more verbose (not only the call, you als= o need to get srcport from somewhere), but also that as far as the caller is concerned, there's no reason to manage the entity and the port as separat= e things. You just want a particular video source/sink to do something, and= whether that source/sink is port 5 of entity foo is irrelevant. The callee, of course, needs to check which port is being operated. Howev= er, if, say, 90% of the display entities have just one input and one output p= ort, the port parameter can be ignored for those entities, simplifying the cod= e. And while media_entity can be embedded into display_entity, media_pad and= media_link cannot be embedded into anything. This is somewhat vague as I = don't quite remember what my reason for needing the feature was, but I had some= need for display_link or display_pad, to add some CDF related entries, which c= an't be done except by modifying the media_link or media_pad themselves. DT data & platform data =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I think the V4L2 style port/endpoint description in DT data should work w= ell. I don't see a need for specifying the remote-endpoint in the upstream entit= y, but then again, it doesn't hurt either. The description does get pretty verbose, though, but I guess that can't b= e avoided. Describing similar things in the platform data works fine too. The RFC, however, contained somewhat lacking platform data examples which had to b= e extended to work with, for example, multiple instances of the same displa= y entity. Also, the RFC relied on the central entity to parse the platform = data, and in my model each display entity has its own platform data. Final thoughts =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D So many of the comments above are somewhat gut-feelings. I don't have con= crete evidence that my ideas are better, as I haven't been able to finalize the= code (well, and the RFC is missing important things like the controller). I think there are areas where my model and the RFC are similar. I think o= ne step would be to identify those parts, and perhaps have those parts as se= parate pieces of code. Say, the DT and platform data parts might be such that we= could have display-of.c and display-pdata.c, having support code which works fo= r the RFC and my model. This would make it easier to maintain and improve both versions, to see h= ow they evolve and what are the pros and cons with both models. But this is = just a thought, I'm not sure how much such code there would actually be. Tomi --AxNFc55mwEh156BP3EM2oME64e5E3aSUs 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.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSSYFGAAoJEPo9qoy8lh71x3sQAKaHHCD1nbgzRP8mdjM4VZ5F dQgedZF179JNVByJc7bt8x+RPC8glWCSUjVw1u68tGc1I/Zdvnpo5SceB/eOGAb3 1TyPMQdFueKdlqYiRsGiYs/yxZy54L+GrmnxEv+P5xuMNfNcE0LBYi9eHarRgkXH pBIWP40s/cey6bIhu6fkzqKy+CnA3AoWwYPbdOAoxVBvgbMXvyW6zy/pXNM71jbD J1Iq4PY4aYx+wZRaCC/GkWtc+Qbjwxh4TSyKnYAiPsy+BaHmdj3c1D4i0aYA1v1Y fYl7IUVbsQv9AxQ0gEroltM7GVsxufoZHmOP3qdO+DFHvfAil/z1thGc8GJW9ArT pv1zD/FLOTY2L4MI+8XGPRy+UkD4lchHvuFxnVI1pzqLM0Pc6/UuAY0A+UP5eJQn rNP6QpWiwV0gJ3PZ6mOr5vVUdM81xRua2S7wP13E9OGmN+vgZpnR6lRyUPpQ1fAs GWjVVeP0+Kg99t5wz+b6GvdhCJAM5cRIRwVt2JRNFGO1yB63iuspl8OX0cEkCgdT nwKCcmRI6xXsv9OwuYuhhYPrrXvdnX3Qg2ZE+76XHtUPMdrUovjlCq8YLiqouti6 vRhnoK0c+um31CNozHyJEgIJ5menyIxh52idTCdN+y/TpSatS02s/K7pJ1/dYXR9 DLLvK3tABppYRoMvR4ou =inQE -----END PGP SIGNATURE----- --AxNFc55mwEh156BP3EM2oME64e5E3aSUs-- --===============0138924821== 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 --===============0138924821==--