From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrzej Hajda Subject: Re: [PATCH v3 1/7] drm: Add DSI bus infrastructure Date: Mon, 18 Nov 2013 17:42:30 +0100 Message-ID: <528A4376.2040200@samsung.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> <20131118125707.GC26046@ulmo.nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by gabe.freedesktop.org (Postfix) with ESMTP id 78FDCFA7DF for ; Mon, 18 Nov 2013 08:42:39 -0800 (PST) Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MWG009CWX29PYC0@mailout2.w1.samsung.com> for dri-devel@lists.freedesktop.org; Mon, 18 Nov 2013 16:42:35 +0000 (GMT) In-reply-to: <20131118125707.GC26046@ulmo.nvidia.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: Thierry Reding Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On 11/18/2013 01:57 PM, Thierry Reding wrote: > On Thu, Nov 14, 2013 at 03:15:57PM +0100, Andrzej Hajda wrote: >> Hi Thierry, >> >> 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.html >>> 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? Patch sent. > >>> 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. Other alternatives: - use helpers functions to call transfer op, encoding could be done by them, - fill channel by DSI master, based on DSI slave(seems to be little over-engineering) But I see no big difference between them. Regards Andrzej > > Thierry