From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH v3 1/7] drm: Add DSI bus infrastructure Date: Mon, 18 Nov 2013 13:49:16 +0100 Message-ID: <20131118124914.GB26046@ulmo.nvidia.com> References: <1384171235-2498-1-git-send-email-treding@nvidia.com> <1384171235-2498-2-git-send-email-treding@nvidia.com> <528237BE.8020501@samsung.com> <20131113213856.GA10856@mithrandir> <5284DB1D.10704@samsung.com> <20131118112208.GC8646@ulmo.nvidia.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2056768985==" Return-path: Received: from mail-bk0-f41.google.com (mail-bk0-f41.google.com [209.85.214.41]) by gabe.freedesktop.org (Postfix) with ESMTP id 377A4105D3E for ; Mon, 18 Nov 2013 04:49:41 -0800 (PST) Received: by mail-bk0-f41.google.com with SMTP id v15so2603501bkz.0 for ; Mon, 18 Nov 2013 04:49:39 -0800 (PST) In-Reply-To: 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: Bert Kenward Cc: Andrzej Hajda , "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org --===============2056768985== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SkvwRMAIpAhPCcCJ" Content-Disposition: inline --SkvwRMAIpAhPCcCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 18, 2013 at 11:59:23AM +0000, Bert Kenward wrote: > On 11/18/2013 11:22, Thierry Reding wrote: > > On Thu, Nov 14, 2013 at 03:04:19PM +0000, Bert Kenward wrote: > > > #define DSI_WINDOW_VFP (1 << 0) > > > #define DSI_WINDOW_ACT (1 << 1) > > > #define DSI_WINDOW_VBP (1 << 2) > > > #define DSI_WINDOW_VSY (1 << 3) > > > > > > /** > > > * struct dsi_msg - DSI command message > > > * @channel: virtual channel to send the message to > > > * @type: data ID of the message > > > * @lp_mode: send in LP mode if non-zero > >=20 > > Perhaps a flags field would be more flexible here. I can easily imagine > > other I can imagine that other flags may be needed eventually. >=20 > Agreed. "TE synchronised" would be one such extra flag, for supporting co= mmand mode updates. >=20 > > > * @window: video period when transfer is allowed - bitmask of > > DSI_WINDOW_* > >=20 > > I'm not sure if this is the right interface. What will happen for > > instance if the hardware doesn't support any of the bits in that mask? > > Perhaps a slightly better approach might be to expose the capabilities > > of the DSI host, so that the DSI core knows up front which windows can > > be used. >=20 > Exposing the capabilities seems like the smart thing to do, certainly > - but you'd still need a way to specify which of those capabilities > you want to use for each transfer. Yes. I think we'll still need to have that. It's just that for some transfers it doesn't matter during which window they are executed. Although I guess in those cases the caller could just specify all bits to signal that it doesn't care. > I'd suggest that hardware would ignore bits that it couldn't support - > in the limit, hardware that has no way to choose when to send a > command during video would ignore this completely. I realise that > could well cause confusion when trying to work out why a particularly > display is misbehaving when you think you're sending commands at the > right time. I think at the very least if there's no match between the requested set of windows and the ones that a particular DSI host supports, then the driver should report an error. The reason why I thought that exposing the capabilities might be useful is that the caller could be smart about how to transfer a message, or perhaps use different messages to the same effect. But perhaps that's not even possible and maybe not worth considering. A smart thing to do in my opinion will be to not try to overengineer this from the beginning. That's why I'm thinking of splitting out the whose dsi_msg support in a first step, so that the bus infrastructure can be merged without having discussed all possible cases. And even so dsi_msg doesn't have to be perfect from the start. It's an in-kernel API, therefore can change easily if needed. The less we require of it now the easier it will be to extend when the need arises. Thierry --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSigzKAAoJEN0jrNd/PrOhWAwQAL7UqrHjyx66gLENQ2ZeFIG3 YQTEmK+9JzvvpLQsh3kP9VuXkyakD+WtCrvALNhk+7XlBw04U3KflRtSaqs0K5pw TOJ7DFpWMjJbl0JBAIL3b9sjygILhqx7zupyq37uNPoc//ocyLAhxIsnkjFgAA8t QUjSWKI99kzohCGn4zdtOqd+WOjuwJBjtQ1oGrYyskCsUoixofnhCFy2X4BK7lWP /dZvr9wZ2uGrudDYhU9OI8y1Jca/lRMzJM0Izemi1sBRfKu0ZqrNKBtfUj/X940X qKcllTs2ZuJLjV9d4BkAw2op2nQ9UNHD5Ls113jDeTwr9ejSjp0NKFwma/pw8hC/ qjpz5FOXN/NIW7u5yoitlEjJ7e4Z5WXDyIs7p0HhlNhrI9Tev1/78NTthRPLDDuG 6eXRG3C0ejsYniMYj13W4MpwPO8vVbpimZVCt6uZ/jLNWI20vKkq1BBAaNiQbNpN IoWGtUyDeBqg9ZH4X91piZiW9XnLPdBTPcVy919lVrNwBhenYoeCEB3BHZlE/gB4 25NB5uqWYpjCNxi7h4UvLn6oiA91duvKMJfRfP0RkYsRoanRKE0QcXX0H3zyDmuT A18/S364NR5uP3TAOBStG9r3Q4AJskvxE3elWL/DLx/rPOpW2jrP9arQM8yvyxYC WRsSGgNp6fKC1nkhpupC =Y0uC -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ-- --===============2056768985== 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 --===============2056768985==--