From mboxrd@z Thu Jan 1 00:00:00 1970 From: Archit Taneja Subject: Re: [PATCH v7 0/5] Add mipi dsi support for rk3288 Date: Mon, 8 Feb 2016 17:56:27 +0530 Message-ID: <56B88973.6000701@codeaurora.org> References: <1452053038-32098-1-git-send-email-zyw@rock-chips.com> <56B869F4.6090507@codeaurora.org> <5060470.dfeHX20DRa@phil> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <5060470.dfeHX20DRa@phil> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Heiko Stuebner , treding@nvidia.com Cc: Mark Rutland , devicetree@vger.kernel.org, Russell King , Pawel Moll , Ian Campbell , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, Rob Herring , Kumar Gala , Chris Zhong , linux-arm-kernel@lists.infradead.org List-Id: linux-rockchip.vger.kernel.org CgpPbiAwMi8wOC8yMDE2IDA0OjIyIFBNLCBIZWlrbyBTdHVlYm5lciB3cm90ZToKPiBIaSBBcmNo aXQsCj4KPiBBbSBNb250YWcsIDguIEZlYnJ1YXIgMjAxNiwgMTU6NDI6MDQgc2NocmllYiBBcmNo aXQgVGFuZWphOgo+PiBPbiAwMS8wNi8yMDE2IDA5OjMzIEFNLCBDaHJpcyBaaG9uZyB3cm90ZToK Pj4+IFRoZSByazMyODggTUlQSSBEU0kgaXMgYSBTeW5vcHN5cyBEZXNpZ25XYXJlIE1JUEkgRFNJ IGhvc3QgY29udHJvbGxlcgo+Pj4gSVAuIFRoaXMgc2VyaWVzIGFkZHMgc3VwcG9ydCBmb3IgYSBT eW5vcHN5cyBEZXNpZ25XYXJlIE1JUEkgRFNJIGhvc3QKPj4+IGNvbnRyb2xsZXIgRFJNIGRyaXZl ci4KPj4+Cj4+PiBUaGUgTUlQSSBEU0kgZmVhdHVyZSBpcyB0ZXN0ZWQgb24gcmszMjg4IGV2YiBi b2FyZCwgYmFja3BvcnQgdGhlbSB0bwo+Pj4gY2hyb21lIG9zIGtlcm5lbCBjaHJvbWVfdjMuMTQs IGFuZCBpdCBjYW4gZGlzcGxheSBub3JtYWxseS4KPj4+Cj4+PiBUaGlzIHBhdGNoc2V0IGlzIGJh c2Ugb24gdGhlIHBhdGNoc2V0IGZyb20gWWluZy5saXVAZnJlZXNjYWxlLmNvbS4KPj4+IDxodHRw Oi8vd3d3LnNwaW5pY3MubmV0L2xpc3RzL2RyaS1kZXZlbC9tc2c3NzE4MS5odG1sPgo+Pj4KPj4+ IEFjY29yZGluZyB0byB0aGUgc3VnZ2VzdGlvbiBmcm9tIFRoaWVycnksIEkgaGF2ZSBnZXQgcmlk IG9mIHRoZSBicmlkZ2UsCj4+PiBhbmQgcmVnaXN0ZXIgdGhlIGVuY29kZXIgJiBjb25uZWN0ZXIg aW4gZHJtL3JvY2tjaGlwL2R3LW1pcGktZHNpLmMuCj4+Cj4+IEkndmUgcmFpc2VkIHRoaXMgcXVl c3Rpb24gdG9vIGxhdGUsIGJ1dCB3aGF0IHdhcyB0aGUgcmVhc29uIHRvIG5vdAo+PiBpbXBsZW1l bnQgdGhlIERTSSBibG9jayBhcyBhIGJyaWRnZSBkcml2ZXI/Cj4KPiBUaGVyZSBzZWVtcyB0byBh bHdheXMgYmUgc29tZSBzb3J0IG9mIGNvbnRlbnRpb24gYWJvdXQgdGhvc2UgYmVpbmcgYnJpZGdl Cj4gZHJpdmVycyAtIEkgdGhpbmsgSSByZW1lbWJlciBUaGllcnJ5IHNwZWFraW5nIHVwIGFib3V0 IHRoYXQuIEJ1dCBJIGRvbid0Cj4gcmVtZW1iZXIgaWYgYW55IGRpZmZlcmVudCBzb2x1dGlvbiB3 YXMgc3VnZ2VzdGVkLgoKV2VsbCwgeWVhaCwgdGhlc2UgY2FuIGJlIGNvbnNpZGVyZWQgYXMgZW5j b2RlcnMgdG9vLiBJIGd1ZXNzIGl0J3MganVzdApub3QgdmVyeSBjb21tb24gdG8gaGF2ZSBlbmNv ZGVyIGRyaXZlcnMgb3V0c2lkZSBvZiB0aGUga21zIGRyaXZlciwgaW4KY29tcGFyaXNvbiB0byBi cmlkZ2VzLgoKVGhlIGFkdmFudGFnZSBvZiBoYXZpbmcgc3VjaCBzaGFyZWQgSVBzIGFzIGJyaWRn ZXMgaXMgdGhhdCB0aGV5IGNhbiBiZQp1c2VkIGJ5IGttcyBkcml2ZXJzIHRoYXQgYWxyZWFkeSBp bXBsZW1lbnQgYW4gZW5jb2RlciBpbiB0aGUgZGlzcGxheQpjaGFpbi4KCj4KPiBBbHNvIGFzIHdl IGhhdmUgc2VlbiB3aXRoIGN1cnJlbnQgc2hhcmVkIElQcyAoZHctaGRtaSArIGFuYWxvZ2l4LWRw KSB0aGVyZQo+IGFyZSBhbHdheXMgaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgcGFydHMgYW5kIGRl Y2lkaW5nIHdoaWNoIG5lZWRzIHRvIGxhbmQKPiB3aGVyZSBpcyBkaWZmaWN1bHQgd2l0aG91dCB0 aGUgc2Vjb25kYXJ5IHVzZXIgcHJlc2VudC4KClllYWgsIEkgY2FuIGltYWdpbmUgaXQgYmVpbmcg aGFyZCB0byBzZXBhcmF0ZSBvdXQgdGhlIGltcGxlbWVudGF0aW9uCnNwZWNpZmljIGFuZCBjb3Jl IHBhcnRzLgoKPgo+IFRoZSBmaXJzdCBpdGVyYXRpb25zIHdoZXJlIHVzaW5nIGEgYnJpZGdlLWRy aXZlci1iYXNlIGZvciBpdCBidXQgSSBndWVzcyBpdAo+IHdhcyB0byBtdWNoIGhhc3NsZSB3aXRo b3V0IHNlZWluZyBhbm90aGVyIHVzZXIgb24gdGhlIGhvcml6b24uCj4KPgo+PiBUaGUgZHJtL2hp c2lsaWNvbiBJUCBzZWVtcyB0byB1c2UgYSB2ZXJ5IHNpbWlsYXIgRFNJIERlc2lnbndhcmUgSVAg KHRoZQo+PiByZWdpc3RlciBvZmZzZXRzIHNlZW1zIHRvIGJlIHRoZSBzYW1lKS4gVGhlcmUgaXMg YSBnb29kIHBvdGVudGlhbCBvZgo+PiByZS11c2UgaGVyZSBieSBkaWZmZXJlbnQga21zIGRyaXZl cnMgaGVyZSB0aGUgd2F5IGl0J3MgYWxyZWFkeSBkb25lIGZvcgo+PiBEVyBIRE1JIGFuZCB0aGUg YW5hbG9naXggRFAgZHJpdmVyIHRoYXQncyBpbiByZXZpZXcgcHJvY2Vzcy4KPgo+IEkgZ3Vlc3Ms IHRoZSBzZWNvbmQgdXNlciBub3cgZ2V0cyB0byBkbyB0aGUgZ2VuZXJhbGl6YXRpb24gOy0pCgpJ ZiBub3QgdGhlIGdlbmVyYWxpemF0aW9uLCB0aGVuIGF0IGxlYXN0IGFuIGFzc2Vzc21lbnQgaWYg aXQncyB3b3J0aCB0aGUKZWZmb3J0IG9yIG5vdCA6KQoKQXJjaGl0CgotLSAKVGhlIFF1YWxjb21t IElubm92YXRpb24gQ2VudGVyLCBJbmMuIGlzIGEgbWVtYmVyIG9mIHRoZSBDb2RlIEF1cm9yYSAK Rm9ydW0sIGhvc3RlZCBieSBUaGUgTGludXggRm91bmRhdGlvbgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1k ZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcv bWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: architt@codeaurora.org (Archit Taneja) Date: Mon, 8 Feb 2016 17:56:27 +0530 Subject: [PATCH v7 0/5] Add mipi dsi support for rk3288 In-Reply-To: <5060470.dfeHX20DRa@phil> References: <1452053038-32098-1-git-send-email-zyw@rock-chips.com> <56B869F4.6090507@codeaurora.org> <5060470.dfeHX20DRa@phil> Message-ID: <56B88973.6000701@codeaurora.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 02/08/2016 04:22 PM, Heiko Stuebner wrote: > Hi Archit, > > Am Montag, 8. Februar 2016, 15:42:04 schrieb Archit Taneja: >> On 01/06/2016 09:33 AM, Chris Zhong wrote: >>> The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller >>> IP. This series adds support for a Synopsys DesignWare MIPI DSI host >>> controller DRM driver. >>> >>> The MIPI DSI feature is tested on rk3288 evb board, backport them to >>> chrome os kernel chrome_v3.14, and it can display normally. >>> >>> This patchset is base on the patchset from Ying.liu at freescale.com. >>> >>> >>> According to the suggestion from Thierry, I have get rid of the bridge, >>> and register the encoder & connecter in drm/rockchip/dw-mipi-dsi.c. >> >> I've raised this question too late, but what was the reason to not >> implement the DSI block as a bridge driver? > > There seems to always be some sort of contention about those being bridge > drivers - I think I remember Thierry speaking up about that. But I don't > remember if any different solution was suggested. Well, yeah, these can be considered as encoders too. I guess it's just not very common to have encoder drivers outside of the kms driver, in comparison to bridges. The advantage of having such shared IPs as bridges is that they can be used by kms drivers that already implement an encoder in the display chain. > > Also as we have seen with current shared IPs (dw-hdmi + analogix-dp) there > are always implementation-specific parts and deciding which needs to land > where is difficult without the secondary user present. Yeah, I can imagine it being hard to separate out the implementation specific and core parts. > > The first iterations where using a bridge-driver-base for it but I guess it > was to much hassle without seeing another user on the horizon. > > >> The drm/hisilicon IP seems to use a very similar DSI Designware IP (the >> register offsets seems to be the same). There is a good potential of >> re-use here by different kms drivers here the way it's already done for >> DW HDMI and the analogix DP driver that's in review process. > > I guess, the second user now gets to do the generalization ;-) If not the generalization, then at least an assessment if it's worth the effort or not :) Archit -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753073AbcBHM0i (ORCPT ); Mon, 8 Feb 2016 07:26:38 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:53784 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751519AbcBHM0f (ORCPT ); Mon, 8 Feb 2016 07:26:35 -0500 Subject: Re: [PATCH v7 0/5] Add mipi dsi support for rk3288 To: Heiko Stuebner , treding@nvidia.com References: <1452053038-32098-1-git-send-email-zyw@rock-chips.com> <56B869F4.6090507@codeaurora.org> <5060470.dfeHX20DRa@phil> Cc: Chris Zhong , linux-rockchip@lists.infradead.org, mark.yao@rock-chips.com, Mark Rutland , devicetree@vger.kernel.org, Russell King , Pawel Moll , Ian Campbell , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Rob Herring , Kumar Gala , linux-arm-kernel@lists.infradead.org, Xinliang Liu From: Archit Taneja Message-ID: <56B88973.6000701@codeaurora.org> Date: Mon, 8 Feb 2016 17:56:27 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5060470.dfeHX20DRa@phil> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/08/2016 04:22 PM, Heiko Stuebner wrote: > Hi Archit, > > Am Montag, 8. Februar 2016, 15:42:04 schrieb Archit Taneja: >> On 01/06/2016 09:33 AM, Chris Zhong wrote: >>> The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller >>> IP. This series adds support for a Synopsys DesignWare MIPI DSI host >>> controller DRM driver. >>> >>> The MIPI DSI feature is tested on rk3288 evb board, backport them to >>> chrome os kernel chrome_v3.14, and it can display normally. >>> >>> This patchset is base on the patchset from Ying.liu@freescale.com. >>> >>> >>> According to the suggestion from Thierry, I have get rid of the bridge, >>> and register the encoder & connecter in drm/rockchip/dw-mipi-dsi.c. >> >> I've raised this question too late, but what was the reason to not >> implement the DSI block as a bridge driver? > > There seems to always be some sort of contention about those being bridge > drivers - I think I remember Thierry speaking up about that. But I don't > remember if any different solution was suggested. Well, yeah, these can be considered as encoders too. I guess it's just not very common to have encoder drivers outside of the kms driver, in comparison to bridges. The advantage of having such shared IPs as bridges is that they can be used by kms drivers that already implement an encoder in the display chain. > > Also as we have seen with current shared IPs (dw-hdmi + analogix-dp) there > are always implementation-specific parts and deciding which needs to land > where is difficult without the secondary user present. Yeah, I can imagine it being hard to separate out the implementation specific and core parts. > > The first iterations where using a bridge-driver-base for it but I guess it > was to much hassle without seeing another user on the horizon. > > >> The drm/hisilicon IP seems to use a very similar DSI Designware IP (the >> register offsets seems to be the same). There is a good potential of >> re-use here by different kms drivers here the way it's already done for >> DW HDMI and the analogix DP driver that's in review process. > > I guess, the second user now gets to do the generalization ;-) If not the generalization, then at least an assessment if it's worth the effort or not :) Archit -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation