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:57:07 +0100 Message-ID: <20131118125707.GC26046@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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0292275342==" Return-path: Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) by gabe.freedesktop.org (Postfix) with ESMTP id 93718F9DAA for ; Mon, 18 Nov 2013 04:57:31 -0800 (PST) Received: by mail-bk0-f43.google.com with SMTP id mz12so374510bkb.2 for ; Mon, 18 Nov 2013 04:57:30 -0800 (PST) In-Reply-To: <5284DB1D.10704@samsung.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: Andrzej Hajda Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0292275342== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KDt/GgjP6HVcx58l" Content-Disposition: inline --KDt/GgjP6HVcx58l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 14, 2013 at 03:15:57PM +0100, Andrzej Hajda wrote: > Hi Thierry, >=20 > On 11/13/2013 10:38 PM, Thierry Reding wrote: > > On Tue, Nov 12, 2013 at 03:14:22PM +0100, Andrzej Hajda wrote: > >> Hi Thierry, > >> > >> I have already sent patch with DSI bus implementation [1]. > >> It was posted as the first step of CDF implementation attempt, > >> but in fact it do not depend on CDF. > >> > >> [1] > >> http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg45252.h= tml > > Seems like that patchset was never merged. I guess probably because it > > was posted as part of CDF work. > > > > Do you have any plans on continuing work on that?If not I could extract > > the DSI bus patch from the series, it's largely similar to the patch I > > proposed here, and rework it somewhat. > I will soon sent new patch with the current version of the bus. > It could be a better base to your rework. Any estimate on when this will be? I want to get started on this as soon as possible so we can get this in good shape for 3.14. I suspect that if I start based on the current patch, I won't have to redo everything when updating for the next version. Quite a bit should remain similar, right? > > I'd very much like to avoid > > putting the code in drivers/video, though, since that's considered > > obsolete. > I have followed convention proposed by Laurent in his DBI bus. > It seems to me OK - DSI bus is more related to video than to drm. > I know that drivers/video is mostly occupied by FB drivers, > but according to Kconfig it is not only for FB. > Of course this is only my suggestion. I've had an IRC discussion with Dave and Rob (added on Cc), and they both agreed that implementing it as part of DRM would be preferred. The reason, as I've said before, is primarily that drivers/video is considered obsolete and new drivers and features should be implemented within the context of DRM/KMS. Additionally this has the benefit of being able to reuse the native DRM data structures and types, as well as helper functions, without having to go through an extra layer of compatibility. > > Furthermore I think if we kept the transfer function proposed > > in my patch should make it easier to address Bert's comments from your > > posting. > I am not sure which part of Barts comment you are addressing. > Anyway I also prefer passing struct and returning ssize_t. > I am not sure about splitting type and channel but this seems to be a > minor detail. I find that to be a perfectly natural split. A DSI peripheral will have an associated virtual channel number anyway, and having a separate field will allow drivers to just copy that field into the dsi_msg's equivalent. The alternative would be to require each driver to properly encode the channel and data type. Thierry --KDt/GgjP6HVcx58l Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSig6jAAoJEN0jrNd/PrOhxyoP/RGZVl5QMDqGkupo58IG+Mm3 Js1P94XkUAaIdVI/k5MWdI63mKFRnZ+9iJ+SQvlsNfcOrOChj3kt8pnfE7bYXhuN /UYXqSoiKA1faJTMgIwgDALAgd745cPmIFxy173RhdpXJhG/etmgk3h7Mvza+H/P DPbJLMzre958iAy/cNOaQ3okeSHqrptd00shNS/j13zRsjsgNHfYChAaMrZOIY5o LSChm9to94npgvISWWVMmCVl+LRECmkgfsBKT/kUToSasSPyA7WjXLCa1y4thA58 mZQLwvLoqh9/r0dyHWy8fdFEPsNgzIfAG7r19H+iqyDt1/d9eZvTQdopgCwxiI2v MvJSrxA6ztZO2gPzhRx/cdE1i4StBWEc1n8wsiAJP9NVslszkwkkPZ9DgOHmD9Cc 7mlpJ/tDVDzyeBVTdSg4D4VJ/QO1grLACzeVLgA9RyN60/UOE1SM7acHG8G5TBDR dbcFAs7naNPcO3ikoNfs56e0gFcY1yUhCccy08qPUp17ZNfI+ANBzxMMeqJE7zFo djHXCT76d1YlLfMt1l9iJOOxiyJuN7+BXUdTjlIq5wuHijoJK9l82c6WVd1MH8Yu DWc9B1xxfVFhb+XhOrW0Ww2PShekOoil1WleXDWvqjFGC+BV+vTrd5yKcQr4ZJCC RmTr5sW65JSC/pq8TDn3 =TTTP -----END PGP SIGNATURE----- --KDt/GgjP6HVcx58l-- --===============0292275342== 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 --===============0292275342==--