From mboxrd@z Thu Jan 1 00:00:00 1970 From: Archit Taneja Subject: Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus Date: Fri, 21 Aug 2015 11:39:01 +0530 Message-ID: <55D6C07D.4050405@codeaurora.org> References: <1435641851-27295-1-git-send-email-architt@codeaurora.org> <55D40F2A.6000208@codeaurora.org> <20150819131300.GC15607@ulmo.nvidia.com> <1439993828.31432.28.camel@pengutronix.de> <20150819143452.GH15607@ulmo.nvidia.com> <1439995944.31432.34.camel@pengutronix.de> <20150819150207.GJ15607@ulmo.nvidia.com> <55D5548E.9030608@codeaurora.org> <20150820114815.GB7479@ulmo.nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20150820114815.GB7479@ulmo.nvidia.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Thierry Reding Cc: "devicetree@vger.kernel.org" , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, a.hajda@samsung.com List-Id: linux-arm-msm@vger.kernel.org CgpPbiAwOC8yMC8yMDE1IDA1OjE4IFBNLCBUaGllcnJ5IFJlZGluZyB3cm90ZToKPiBPbiBUaHUs IEF1ZyAyMCwgMjAxNSBhdCAwOTo0NjoxNEFNICswNTMwLCBBcmNoaXQgVGFuZWphIHdyb3RlOgo+ PiBIaSBUaGllcnJ5LCBMdWNhcywKPj4KPj4KPj4gT24gMDgvMTkvMjAxNSAwODozMiBQTSwgVGhp ZXJyeSBSZWRpbmcgd3JvdGU6Cj4+PiBPbiBXZWQsIEF1ZyAxOSwgMjAxNSBhdCAwNDo1MjoyNFBN ICswMjAwLCBMdWNhcyBTdGFjaCB3cm90ZToKPj4+PiBBbSBNaXR0d29jaCwgZGVuIDE5LjA4LjIw MTUsIDE2OjM0ICswMjAwIHNjaHJpZWIgVGhpZXJyeSBSZWRpbmc6Cj4+Pj4+IE9uIFdlZCwgQXVn IDE5LCAyMDE1IGF0IDA0OjE3OjA4UE0gKzAyMDAsIEx1Y2FzIFN0YWNoIHdyb3RlOgo+Pj4+Pj4g SGkgVGhpZXJyeSwgQXJjaGl0LAo+Pj4+Pj4KPj4+PiBbLi4uXQo+Pj4+Pj4+IFBlcmhhcHMgYSBi ZXR0ZXIgd2F5IHdvdWxkIGJlIHRvIGludmVydCB0aGlzIHJlbGF0aW9uc2hpcC4gQWNjb3JkaW5n IHRvCj4+Pj4+Pj4geW91ciBwcm9wb3NhbCB3ZSdkIGhhdmUgdG8gaGF2ZSBEVCBsaWtlIHRoaXM6 Cj4+Pj4+Pj4KPj4+Pj4+PiAJaTJjQC4uLiB7Cj4+Pj4+Pj4gCQkuLi4KPj4+Pj4+Pgo+Pj4+Pj4+ IAkJZHNpLWRldmljZUAuLi4gewo+Pj4+Pj4+IAkJCS4uLgo+Pj4+Pj4+IAkJCWRzaS1idXMgPSA8 JmRzaT47Cj4+Pj4+Pj4gCQkJLi4uCj4+Pj4+Pj4gCQl9Owo+Pj4+Pj4+Cj4+Pj4+Pj4gCQkuLi4K Pj4+Pj4+PiAJfTsKPj4+Pj4+Pgo+Pj4+Pj4+IAlkc2lALi4uIHsKPj4+Pj4+PiAJCS4uLgo+Pj4+ Pj4+IAl9Owo+Pj4+Pj4+Cj4+Pj4+Pj4gSW52ZXJzaW5nIHRoZSByZWxhdGlvbnNoaXAgd291bGQg YmVjb21lIHNvbWV0aGluZyBsaWtlIHRoaXM6Cj4+Pj4+Pj4KPj4+Pj4+PiAJaTJjQC4uLiB7Cj4+ Pj4+Pj4gCQkuLi4KPj4+Pj4+PiAJfTsKPj4+Pj4+Pgo+Pj4+Pj4+IAlkc2lALi4uIHsKPj4+Pj4+ PiAJCS4uLgo+Pj4+Pj4+Cj4+Pj4+Pj4gCQlwZXJpcGhlcmFsQC4uLiB7Cj4+Pj4+Pj4gCQkJLi4u Cj4+Pj4+Pj4gCQkJaTJjLWJ1cyA9IDwmaTJjPjsKPj4+Pj4+PiAJCQkuLi4KPj4+Pj4+PiAJCX07 Cj4+Pj4+Pj4KPj4+Pj4+PiAJCS4uLgo+Pj4+Pj4+IAl9Owo+Pj4+Pj4+Cj4+Pj4+Pj4gQm90aCBv ZiB0aG9zZSBhcmVuJ3QgZnVuZGFtZW50YWxseSBkaWZmZXJlbnQsIGFuZCB0aGV5IGJvdGggaGF2 ZSB0aGUKPj4+Pj4+PiBkaXNhdmFudGFnZSBvZiBsYWNraW5nIHdheXMgdG8gdHJhbnNwb3J0IGNv bmZpZ3VyYXRpb24gZGF0YSB0aGF0IHRoZQo+Pj4+Pj4+IG90aGVyIGJ1cyBuZWVkcyB0byBpbnN0 YW50aWF0ZSB0aGUgZHVtbXkgZGV2aWNlIChzdWNoIGFzIHRoZSByZWcKPj4+Pj4+PiBwcm9wZXJ0 eSBmb3IgZXhhbXBsZSwgZGVub3RpbmcgdGhlIEkyQyBzbGF2ZSBhZGRyZXNzIG9yIHRoZSBEU0kg VkMpLgo+Pj4+Pj4+Cj4+Pj4+Pj4gU28gaG93IGFib3V0IHdlIGNyZWF0ZSB0d28gZGV2aWNlcyBp biB0aGUgZGV2aWNlIHRyZWUgYW5kIGZ1c2UgdGhlbSBhdAo+Pj4+Pj4+IHRoZSBkcml2ZXIgbGV2 ZWw6Cj4+Pj4+Pj4KPj4+Pj4+PiAJaTJjQC4uLiB7Cj4+Pj4+Pj4gCQkuLi4KPj4+Pj4+Pgo+Pj4+ Pj4+IAkJaTJjZHNpOiBkc2ktZGV2aWNlQC4uLiB7Cj4+Pj4+Pj4gCQkJLi4uCj4+Pj4+Pj4gCQl9 Owo+Pj4+Pj4+Cj4+Pj4+Pj4gCQkuLi4KPj4+Pj4+PiAJfTsKPj4+Pj4+Pgo+Pj4+Pj4+IAlkc2lA Li4uIHsKPj4+Pj4+PiAJCS4uLgo+Pj4+Pj4+Cj4+Pj4+Pj4gCQlwZXJpcGhlcmFsQC4uLiB7Cj4+ Pj4+Pj4gCQkJLi4uCj4+Pj4+Pj4gCQkJY29udHJvbCA9IDwmaTJjZHNpPjsKPj4+Pj4+PiAJCQku Li4KPj4+Pj4+PiAJCX07Cj4+Pj4+Pj4KPj4+Pj4+PiAJCS4uLgo+Pj4+Pj4+IAl9Owo+Pj4+Pj4+ Cj4+Pj4+Pj4gVGhpcyB3YXkgd2UnbGwgZ2V0IGJvdGggYW4gSTJDIGRldmljZSBhbmQgYSBEU0kg ZGV2aWNlIHRoYXQgd2UgY2FuIGZ1bGx5Cj4+Pj4+Pj4gZGVzY3JpYmUgdXNpbmcgdGhlIHN0YW5k YXJkIGRldmljZSB0cmVlIGJpbmRpbmdzLiBBdCBkcml2ZXIgdGltZSB3ZSBjYW4KPj4+Pj4+PiBn ZXQgdGhlIEkyQyBkZXZpY2UgZnJvbSB0aGUgcGhhbmRsZSBpbiB0aGUgY29udHJvbCBwcm9wZXJ0 eSBvZiB0aGUgRFNJCj4+Pj4+Pj4gZGV2aWNlIGFuZCB1c2UgaXQgdG8gZXhlY3V0ZSBJMkMgdHJh bnNhY3Rpb25zLgo+Pj4+Pj4+Cj4+Pj4+PiBJIGRvbid0IHJlYWxseSBsaWtlIHRvIHNlZSB0aGF0 IHlvdSBhcmUgaW52ZW50aW5nIHlldC1hbm90aGVyLXdheSB0bwo+Pj4+Pj4gaGFuZGxlIGRldmlj ZXMgY29ubmVjdGVkIHRvIG11bHRpcGxlIGJ1c2VzLgo+Pj4+Pj4KPj4+Pj4+IERldmljZXRyZWUg aXMgc3RydWN0dXJlZCBhbG9uZyB0aGUgY29udHJvbCBidXNlcywgZXZlbiBpZiB0aGUgZGV2aWNl cwo+Pj4+Pj4gYXJlIGNvbm5lY3RlZCB0byBtdWx0aXBsZSBidXNlcywgaW4gdGhlIERUIHRoZXkg YXJlIGFsd2F5cyBjaGlsZHJlbiBvZgo+Pj4+Pj4gdGhlIGJ1cyB0aGF0IGlzIHVzZWQgdG8gY29u dHJvbCB0aGVpciByZWdpc3RlcnMgZnJvbSB0aGUgQ1BVcwo+Pj4+Pj4gcGVyc3BlY3RpdmUuIFNv IGEgRFNJIGVuY29kZXIgdGhhdCBpcyBjb250cm9sbGVkIHRocm91Z2ggaTJjIGlzIGNsZWFybHkK Pj4+Pj4+IGEgY2hpbGQgb2YgdGhlIGkyYyBtYXN0ZXIgY29udHJvbGxlciBhbmQgb25seSBvZiB0 aGF0IG9uZS4KPj4+Pj4KPj4+Pj4gSSB0aGluayB0aGF0J3MgYSBmbGF3ZWQgaW50ZXJwcmV0YXRp b24gb2Ygd2hhdCdzIGdvaW5nIG9uIGhlcmUuIFRoZQo+Pj4+PiBkZXZpY2UgaW4gZmFjdCBoYXMg dHdvIGludGVyZmFjZXM6IG9uZSBpcyBJMkMsIHRoZSBvdGhlciBpcyBEU0kuIEluIG15Cj4+Pj4+ IG9waW5pb24gdGhhdCdzIHJlYXNvbiBlbm91Z2ggdG8gcmVwcmVzZW50IGl0IGFzIHR3byBsb2dp Y2FsIGRldmljZXMuCj4+Pj4+Cj4+Pj4gRG9lcyBpdCByZWFsbHkgaGF2ZSAyIGNvbnRyb2wgaW50 ZXJmYWNlcyB0aGF0IGFyZSB1c2VkIGF0IHRoZSBzYW1lIHRpbWU/Cj4+Pj4gT3IgaXMgdGhlIERT SSBjb25uZWN0aW9uIGEgcGFzc2l2ZSBkYXRhIGJ1cyBpZiB0aGUgcmVnaXN0ZXIgY29udHJvbAo+ Pj4+IGhhcHBlbnMgdGhyb3VnaCBpMmM/Cj4+Pgo+Pj4gVGhlIGludGVyZmFjZXMgbWF5IG5vdCBi ZSB1c2VkIGF0IHRoZSBzYW1lIHRpbWUsIGFuZCB0aGUgRFNJIGludGVyZmFjZQo+Pj4gbWF5IGV2 ZW4gYmUgY3JpcHBsZWQsIGJ1dCB0aGUgZGV2aWNlIGlzIHN0aWxsIGFkZHJlc3NhYmxlIGZyb20g dGhlIERTSQo+Pj4gaG9zdCBjb250cm9sbGVyLCBpZiBmb3Igbm90aGluZyBlbHNlIHRoYW4gZm9y IHJvdXRpbmcgdGhlIHZpZGVvIHN0cmVhbS4KPj4+Cj4+Pj4+PiBJZiB5b3UgbmVlZCB0byBtb2Rl bCBjb25uZWN0aW9ucyBiZXR3ZWVuIGRldmljZXMgdGhhdCBhcmUgbm90IHJlZmxlY3RlZAo+Pj4+ Pj4gdGhyb3VnaCB0aGUgY29udHJvbCBidXMgaGllcmFyY2h5IHlvdSBzaG91bGQgcmVhbGx5IGNv bnNpZGVyIHVzaW5nIHRoZQo+Pj4+Pj4gc3RhbmRhcmRpemVkIG9mLWdyYXBoIGJpbmRpbmdzLgo+ Pj4+Pj4gKERvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9ncmFwaC50eHQpCj4+Pj4+ Cj4+Pj4+IFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIG9yaWdpbmFsIHByb3Bvc2FsIHdvdWxkIGlu c3RhbnRpYXRlIGEgZHVtbXkKPj4+Pj4gZGV2aWNlLCBzbyBpdCB3b3VsZG4ndCBiZSByZXByZXNl bnRlZCBpbiBEVCBhdCBhbGwuIFNvIHVubGVzcyB5b3UgZG8gYWRkCj4+Pj4+IHR3byBsb2dpY2Fs IGRldmljZXMgdG8gRFQgKG9uZSBmb3IgZWFjaCBidXMgaW50ZXJmYWNlKSwgeW91IGRvbid0IGhh dmUKPj4+Pj4gYW55dGhpbmcgdG8gZ2x1ZSB0b2dldGhlciB3aXRoIGFuIE9GIGdyYXBoLgo+Pj4+ Pgo+Pj4+IEkgc2VlIHRoYXQgdGhlIGhhdmluZyBkdW1teSBkZXZpY2UgaXMgdGhlIGxlYXN0IGRl c2lyYWJsZSBzb2x1dGlvbi4gQnV0Cj4+Pj4gaWYgdGhlcmUgaXMgb25seSBvbmUgY29udHJvbCBi dXMgdG8gdGhlIGRldmljZSBJIHRoaW5rIGl0IHNob3VsZCBiZSBvbmUKPj4+PiBkZXZpY2Ugc2l0 dGluZyBiZW5lYXRoIHRoZSBjb250cm9sIGJ1cy4KPj4+Pgo+Pj4+IFlvdSBjYW4gdGhlbiB1c2Ug b2YtZ3JhcGggdG8gbW9kZWwgdGhlIGRhdGEgcGF0aCBiZXR3ZWVuIHRoZSBEU0kgZW5jb2Rlcgo+ Pj4+IGFuZCBkZXZpY2UuCj4+Pgo+Pj4gQnV0IHlvdSB3aWxsIGJlIG5lZWRpbmcgYSBkZXZpY2Ug YmVsb3cgdGhlIERTSSBob3N0IGNvbnRyb2xsZXIgdG8KPj4+IHJlcHJlc2VudCB0aGF0IGVuZHBv aW50IG9mIHRoZSBjb25uZWN0aW9uLiBUaGUgRFNJIGhvc3QgY29udHJvbGxlcgo+Pj4gaXRzZWxm IGlzIGluIG5vIHdheSBjb25uZWN0ZWQgdG8gdGhlIEkyQyBhZGFwdGVyLiBZb3Ugd291bGQgaGF2 ZSB0bwo+Pj4gYWRkIHNvbWUgc29ydCBvZiBxdWlyayB0byB0aGUgRFNJIGNvbnRyb2xsZXIgYmlu ZGluZyB0byBhbGxvdyBpdCB0bwo+Pgo+PiBUaGFua3MgZm9yIHRoZSByZXZpZXcuCj4+Cj4+IEkg aW1wbGVtZW50ZWQgdGhpcyB0byBzdXBwb3J0IEFEVjc1MzMgRFNJIHRvIEhETUkgZW5jb2RlciBj aGlwLCB3aGljaAo+PiBoYXMgYSBEU0kgdmlkZW8gYnVzIGFuZCBhbiBpMmMgY29udHJvbCBidXMu Cj4+Cj4+IFRoZXJlIHdlcmVuJ3QgYW55IHF1aXJrcyBhcyBzdWNoIGluIHRoZSBkZXZpY2UgdHJl ZSB3aGVuIEkgdHJpZWQgdG8KPj4gaW1wbGVtZW50IHRoaXMuIFRoZSBEVCBzZWVtcyB0byBtYW5h Z2UgZmluZSB3aXRob3V0IGEgbm9kZQo+PiBjb3JyZXNwb25kaW5nIHRvIGEgbWlwaV9kc2lfZGV2 aWNlOgo+Pgo+PiBpMmNfYWRhcEAuLiB7Cj4+IAlhZHY3NTMzQC4uIHsKPj4KPj4gCQlwb3J0IHsK Pj4gCQkJYWR2X2luOiBlbmRwb2ludCB7Cj4+IAkJCQlyZW1vdGUtZW5kcG9pbnQgPSA8JmRzaV9v dXQ+Owo+PiAJCQl9Owo+PiAJCX07Cj4+IAl9Owo+PiB9Owo+Pgo+PiBkc2lfaG9zdEAuLiB7Cj4+ IAkuLi4KPj4gCS4uLgo+Pgo+PiAJcG9ydCB7Cj4+IAkJZHNpX291dDogZW5kcG9pbnQgewo+PiAJ CQlyZW1vdGUtZW5kcG9pbnQgPSA8JmFkdl9pbj47Cj4+IAkJfQo+PiAJfTsKPj4gfTsKPj4KPj4g SXQncyB0aGUgaTJjIGRyaXZlcidzIGpvYiB0byBwYXJzZSB0aGUgZ3JhcGggYW5kIHJldHJpZXZl IHRoZQo+PiBwaGFuZGxlIHRvIHRoZSBkc2kgaG9zdC4gVXNpbmcgdGhpcywgaXQgY2FuIHByb2Nl ZWQgd2l0aAo+PiByZWdpc3RlcmluZyBpdHNlbGYgdG8gdGhpcyBob3N0IHVzaW5nIHRoZSBuZXcg ZHNpIGZ1bmNzLiBUaGlzCj4+IHBhdGNoIGRvZXMgdGhlIHNhbWUgZm9yIHRoZSBhZHY3NTMzIGky YyBkcml2ZXI6Cj4+Cj4+IGh0dHA6Ly93d3cuc3Bpbmljcy5uZXQvbGlzdHMvZHJpLWRldmVsL21z Zzg2ODQwLmh0bWwKPj4KPj4+IGhvb2sgdXAgd2l0aCBhIGNvbnRyb2wgZW5kcG9pbnQuIEFuZCB0 aGVuIHlvdSdsbCBuZWVkIG1vcmUgcXVpcmtzCj4+PiB0byBkZXNjcmliZSB3aGF0IGtpbmQgb2Yg RFNJIGRldmljZSB0aGlzIGlzLgo+Pgo+PiBDb3VsZCB5b3UgZXhwbGFpbiB3aGF0IHlvdSBtZWFu dCBieSB0aGlzPyBJLmUuIGRlc2NyaWJpbmcgdGhlIGtpbmQKPj4gb2YgRFNJIGRldmljZT8KPgo+ IERlc2NyaWJpbmcgdGhlIG51bWJlciBvZiBsYW5lcywgc3BlY2lmeWluZyB0aGUgdmlydHVhbCBj aGFubmVsLCBtb2RlCj4gZmxhZ3MsIGV0Yy4gWW91IGNvdWxkIHByb2JhYmx5IHNldCB0aGUgbnVt YmVyIG9mIGxhbmVzIGFuZCBtb2RlIGZsYWdzCj4gdmlhIHRoZSBJMkMgZHJpdmVyLCBidXQgZXNw ZWNpYWxseSB0aGUgdmlydHVhbCBjaGFubmVsIGNhbm5vdCBiZSBzZXQKPiBiZWNhdXNlIGl0IGlz bid0IGtub3duIHRvIHRoZSBJMkMgRFQgYnJhbmNoIG9mIHRoZSBkZXZpY2UuCgpJIGFncmVlIHdp dGggdGhlIFZDIHBhcnQuIEl0IGNvdWxkIGJlIGEgRFQgZW50cnkgd2l0aGluIHRoZSBpMmMgY2xp ZW50IApub2RlLCBidXQgdGhhdCBkb2VzIG1ha2UgaXQgc2VlbSBsaWtlIGEgcXVpcmsuIFRoZSAn cmVnJyB3YXkgdW5kZXIgdGhlCkRTSSBob3N0IGlzIGRlZmluaXRlbHkgYmV0dGVyIHRvIHBvcHVs YXRlIHRoZSB2aXJ0dWFsIGNoYW5uZWwuCgo+Cj4+IFRoZSBkc2kgZGV2aWNlIGNyZWF0ZWQgaXNu J3QgcmVhbGx5IGEgZHVtbXkgZGV2aWNlIGFzIHN1Y2guIEl0J3MKPj4gZHVtbXkgaW4gdGhlIHNl bnNlIHRoYXQgdGhlcmUgaXNuJ3QgYSByZWFsIGRzaSBkcml2ZXIgYXNzb2NpYXRlZAo+PiB3aXRo IGl0LiBUaGUgZHNpIGRldmljZSBpcyBzdGlsbCB1c2VkIHRvIGF0dGFjaCB0byBhIG1pcGkgZHNp IGhvc3QsCj4+IHRoZSB3YXkgbm9ybWFsIGRzaSBkZXZpY2VzIGRvLgo+Cj4gSSB1bmRlcnN0YW5k LCBidXQgSSBkb24ndCBzZWUgd2h5IGl0IGhhcyB0byBiZSBpbnN0YW50aWF0ZWQgYnkgdGhlIEky Qwo+IGRyaXZlciwgdGhhdCdzIHdoYXQgSSBmaW5kIGJhY2t3YXJkcy4gVGhlcmUgaXMgYWxyZWFk eSBhIHN0YW5kYXJkIHdheQo+IGZvciBpbnN0YW50aWF0aW5nIERTSSBkZXZpY2VzLCB3aHkgbm90 IHVzZSBpdD8KCkkgYXNzdW1lZCB3ZSBjb3VsZCBlaXRoZXIgcmVwcmVzZW50IHRoZSBkZXZpY2Ug dXNpbmcgYW4gaTJjIGRyaXZlciwgb3IKZHNpLCBidXQgbm90IGJvdGguIEhlbmNlLCBJIGNhbWUg dXAgd2l0aCB0aGlzIGFwcHJvYWNoLgoKPgo+Pj4gT24gdGhlIG90aGVyIGhhbmQgaWYgeW91IHBy b3Blcmx5IGluc3RhbnRpYXRlIHRoZSBEU0kgZGV2aWNlIHlvdSBjYW4KPj4+IGVhc2lseSB3cml0 ZSBhIGRyaXZlciBmb3IgaXQsIGFuZCB0aGUgZHJpdmVyIHdpbGwgc2V0IHVwIHRoZSBjb3JyZWN0 Cj4+PiBwcm9wZXJ0aWVzIGFzIGltcGxpZWQgYnkgdGhlIGNvbXBhdGlibGUgc3RyaW5nLiBPbmNl IHlvdSBoYXZlIHRoYXQgeW91Cj4+PiBjYW4gZWFzaWx5IGhvb2sgaXQgdXAgdG8gdGhlIEkyQyBj b250cm9sIGludGVyZmFjZSBpbiB3aGF0ZXZlciB3YXkgeW91Cj4+PiBsaWtlLCBiZSB0aGF0IGFu IE9GIGdyYXBoIG9yIGp1c3QgYSBzaW1wbGUgdW5pZGlyZWN0aW9uYWwgbGluayBieQo+Pj4gcGhh bmRsZS4KPj4+Cj4+Cj4+IFdpdGggdGhlIGZ1c2VkIGFwcHJvYWNoIHlvdSBzdWdnZXN0ZWQsIHdl IHdvdWxkIGhhdmUgMiBkcml2ZXJzOiBvbmUgaTJjCj4+IGFuZCB0aGUgb3RoZXIgZHNpLiBUaGUg aTJjIGNsaWVudCBkcml2ZXIgd291bGQgYmUgbW9yZSBvciBsZXNzIG1pbmltYWwsCj4+IHByZXBh cmluZyBhbiBpMmNfY2xpZW50IGRldmljZSBmb3IgdGhlIGRzaSBkcml2ZXIgdG8gdXNlLiBJcyBt eQo+PiB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/Cj4KPiBDb3JyZWN0LiBUaGF0J3Mga2luZCBvZiBz aW1pbGFyIHRvIHRoZSB3YXkgYW4gSERNSSBlbmNvZGVyIGRyaXZlciB3b3VsZAo+IHVzZSBhbiBJ MkMgYWRhcHRlciB0byBxdWVyeSBFRElELiBUaGUgaTJjX2NsaWVudCBkZXZpY2Ugd291bGQgYmUg YSBtZWFucwo+IGZvciB0aGUgRFNJIGRyaXZlciB0byBhY2Nlc3MgdGhlIGNvbnRyb2wgaW50ZXJm YWNlLgoKT2theS4KCkFsdGhvdWdoLCBJJ20gbm90IHN1cmUgYWJvdXQgdGhlIEhETUkgZW5jb2Rl ciBleGFtcGxlLiBBbiBIRE1JCmVuY29kZXIgd291bGQgcmVhZCBvZmYgZWRpZCBkaXJlY3RseSBm cm9tIHRoZSBhZGFwdGVyKHdpdGggYW4gYWRkcmVzcwpzcGVjaWZpZWQpLCBpdCB3b3VsZG4ndCBu ZWVkIHRvIGNyZWF0ZSBhbiBpMmMgY2xpZW50IGRldmljZS4gVGhlcmVmb3JlLAphbiBIRE1JIGVu Y29kZXIgd291bGRuJ3QgbmVlZCB0byBoYXZlIGEgc2VwYXJhdGUgbm9kZSBmb3IgaTJjIGluIERU LgoKPgo+PiBXZSBjYW4gZG8gd2l0aG91dCBkdW1teSBkc2kgZGV2aWNlcyB3aXRoIHRoaXMgbWV0 aG9kLiBCdXQsIHJlcHJlc2VudGluZwo+PiBhIGRldmljZSB3aXRoIDIgRFQgbm9kZXMgc2VlbXMg YSBiaXQgb2ZmLiBXZSdkIGFsc28gbmVlZCB0byBjb21wYXRpYmxlCj4+IHN0cmluZ3MgZm9yIHRo ZSBzYW1lIGRldmljZSwgb25lIGZvciB0aGUgaTJjIHBhcnQsIGFuZCB0aGUgb3RoZXIgZm9yCj4+ IHRoZSBkc2kgcGFydC4KPgo+IEkgYWdyZWUgdGhhdCB0aGlzIHNvbWV3aGF0IHN0cmV0Y2hlcyB0 aGUgY2FwYWJpbGl0aWVzIG9mIGRldmljZSB0cmVlLgo+IEFub3RoZXIgYWx0ZXJuYXRpdmUgSSBn dWVzcyB3b3VsZCBiZSB0byBub3QgaGF2ZSBhIGNvbXBhdGlibGUgc3RyaW5nIGZvcgo+IHRoZSBJ MkMgZGV2aWNlIGF0IGFsbCAodGhhdCdzIHRlY2huaWNhbGx5IG5vdCB2YWxpZCwgSSBndWVzcykg YmVjYXVzZSB3ZQo+IHJlYWxseSBkb24ndCBuZWVkIGFuIEkyQyBkcml2ZXIgZm9yIHRoZSBkZXZp Y2UuIFdoYXQgd2UgcmVhbGx5IG5lZWQgaXMgYQo+IERTSSBkcml2ZXIgd2l0aCBhIG1lYW5zIHRv IHRhbGsgb3ZlciBzb21lIEkyQyBidXMgd2l0aCBzb21lIG90aGVyIHBhcnQKPiBvZiBpdHMgZGV2 aWNlLgoKSSB0aGluayB3aGF0IHRoZSBkcml2ZXIgc2hvdWxkICdyZWFsbHknIGJlIGlzIGEgYml0 IHN1YmplY3RpdmUsIGFuZCBjYW4KdmFyeSBiYXNlZCBvbiB3aGF0IHRoZSBidXNlcyBhcmUgdXNl ZCBmb3IgaW4gdGhlIGRldmljZS4gRm9yIHRoZSBUb3NoaWJhCmNoaXAgdGhhdCBKYW5pIG1lbnRp b25lZCwgaXQgdGVuZHMgbW9yZSB0b3dhcmRzIGEgRFNJIGRyaXZlci4gV2hlcmVhcywKZm9yIGFu IEFEVjc1eHggY2hpcCwgaXQncyBjbG9zZXIgdG8gYW4gSTJDIGRyaXZlciBzaW5jZSBvbmx5IEky QyBjYW4gYmUKdXNlZCB0byBjb25maWd1cmUgdGhlIGNoaXAgcmVnaXN0ZXJzLgoKQWx0aG91Z2gs IEkgYWdyZWUgd2l0aCB0aGUgcG9pbnQgeW91IG1hZGUgYWJvdXQgdGhlIERTSSBidXMgaGVyZToK CiJhbmQgdGhlIERTSSBpbnRlcmZhY2UgbWF5IGV2ZW4gYmUgY3JpcHBsZWQsIGJ1dCB0aGUgZGV2 aWNlIGlzIHN0aWxsIAphZGRyZXNzYWJsZSBmcm9tIHRoZSBEU0kgaG9zdCBjb250cm9sbGVyLCBp ZiBmb3Igbm90aGluZyBlbHNlIHRoYW4gZm9yIApyb3V0aW5nIHRoZSB2aWRlbyBzdHJlYW0uIgoK VGhlIGZhY3QgdGhhdCB0aGUgZGF0YSBvbiB0aGUgRFNJIGJ1cyBjb250YWlucyByb3V0aW5nIGlu Zm9ybWF0aW9uIChpLmUsIAp2aXJ0dWFsIGNoYW5uZWwgbnVtYmVyKSBhbHdheXMgZ2l2ZXMgaXQg c29tZSAnY29udHJvbCcgYXNwZWN0LgoKPgo+PiAgRnJvbSBhbiBhZHY3NXh4IGRyaXZlciBwZXJz cGVjdGl2ZSwgaXQgc2hvdWxkIGFsc28gc3VwcG9ydCB0aGUgQURWNzUxMQo+PiBjaGlwLCB3aGlj aCBpcyBhIFJHQi9EUEkgdG8gSERNSSBlbmNvZGVyLiBGb3IgYWR2NzUxMSwgd2UgZG9uJ3QgbmVl ZCBhCj4+IERTSSBEVCBub2RlLiBJdCB3b3VsZCBiZSBhIGJpdCBpbmNvbnNpc3RlbnQgdG8gaGF2 ZSB0aGUgYmluZGluZ3MKPj4gcmVxdWlyZSBib3RoIERTSSBhbmQgSTJDIG5vZGVzIGZvciBvbmUg Y2hpcCwgYW5kIG9ubHkgSTJDIG5vZGUgZm9yIHRoZQo+PiBvdGhlciwgd2l0aCBib3RoIGNoaXBz IGJlaW5nIHN1cHBvcnRlZCBieSB0aGUgc2FtZSBkcml2ZXIuCj4KPiBXaHkgd291bGQgdGhhdCBi ZSBpbmNvbnNpc3RlbnQ/IFRoYXQgc291bmRzIGxpa2UgdGhlIG1vc3QgYWNjdXJhdGUKPiByZXBy ZXNlbnRhdGlvbiBvZiB0aGUgaGFyZHdhcmUgdG8gbWUuCgpJbmNvbnNpc3RlbnQgd2Fzbid0IHRo ZSByaWdodCB0ZXJtLiBJIHNob3VsZCBoYXZlIHVzZWQgJ3VuY29tbW9uJyA6KQpJdCdzIGNvbW1v biBmb3IgdHdvIGNoaXBzIG9mIHRoZSBzYW1lIGZhbWlseSB0byBoYXZlIGEgZGlmZmVyZW50IHNl dApvcHRpb25hbCBwcm9wZXJ0aWVzIGluIERULCBidXQgaXQncyBub3QgY29tbW9uIGZvciB0d28g Y2hpcHMgb2YgdGhlCnNhbWUgZmFtaWx5IHRvIGJlIHJlcHJlc2VudGVkIGJ5IGEgZGlmZmVyZW50 IG51bWJlciBvZiBkZXZpY2VzIGluCkRULgoKSSBkb24ndCBoYXZlIGFuIGlzc3VlIHdpdGggdGhl IGZ1c2VkIGFwcHJvYWNoIHlvdSBzdWdnZXN0ZWQsIGFzIGxvbmcKYXMgcGVvcGxlIGFyZSBva2F5 IHdpdGggdGhlIERUIHBhcnRzLiBFc3BlY2lhbGx5IHRoZSBwYXJ0IG9mIG5lZWRpbmcgMgpjb21w YXRpYmxlIHN0cmluZ3MgaW4gdGhlIERULgoKVGhhbmtzLApBcmNoaXQKCi0tIApRdWFsY29tbSBJ bm5vdmF0aW9uIENlbnRlciwgSW5jLiBpcyBhIG1lbWJlciBvZiBDb2RlIEF1cm9yYSBGb3J1bSwK YSBMaW51eCBGb3VuZGF0aW9uIENvbGxhYm9yYXRpdmUgUHJvamVjdApfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRy aS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752292AbbHUGJO (ORCPT ); Fri, 21 Aug 2015 02:09:14 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:39752 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751364AbbHUGJL (ORCPT ); Fri, 21 Aug 2015 02:09:11 -0400 Message-ID: <55D6C07D.4050405@codeaurora.org> Date: Fri, 21 Aug 2015 11:39:01 +0530 From: Archit Taneja User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Thierry Reding CC: Lucas Stach , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, a.hajda@samsung.com, lars@metafoo.de, Jani Nikula , "devicetree@vger.kernel.org" Subject: Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus References: <1435641851-27295-1-git-send-email-architt@codeaurora.org> <55D40F2A.6000208@codeaurora.org> <20150819131300.GC15607@ulmo.nvidia.com> <1439993828.31432.28.camel@pengutronix.de> <20150819143452.GH15607@ulmo.nvidia.com> <1439995944.31432.34.camel@pengutronix.de> <20150819150207.GJ15607@ulmo.nvidia.com> <55D5548E.9030608@codeaurora.org> <20150820114815.GB7479@ulmo.nvidia.com> In-Reply-To: <20150820114815.GB7479@ulmo.nvidia.com> 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 08/20/2015 05:18 PM, Thierry Reding wrote: > On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote: >> Hi Thierry, Lucas, >> >> >> On 08/19/2015 08:32 PM, Thierry Reding wrote: >>> On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote: >>>> Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding: >>>>> On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote: >>>>>> Hi Thierry, Archit, >>>>>> >>>> [...] >>>>>>> Perhaps a better way would be to invert this relationship. According to >>>>>>> your proposal we'd have to have DT like this: >>>>>>> >>>>>>> i2c@... { >>>>>>> ... >>>>>>> >>>>>>> dsi-device@... { >>>>>>> ... >>>>>>> dsi-bus = <&dsi>; >>>>>>> ... >>>>>>> }; >>>>>>> >>>>>>> ... >>>>>>> }; >>>>>>> >>>>>>> dsi@... { >>>>>>> ... >>>>>>> }; >>>>>>> >>>>>>> Inversing the relationship would become something like this: >>>>>>> >>>>>>> i2c@... { >>>>>>> ... >>>>>>> }; >>>>>>> >>>>>>> dsi@... { >>>>>>> ... >>>>>>> >>>>>>> peripheral@... { >>>>>>> ... >>>>>>> i2c-bus = <&i2c>; >>>>>>> ... >>>>>>> }; >>>>>>> >>>>>>> ... >>>>>>> }; >>>>>>> >>>>>>> Both of those aren't fundamentally different, and they both have the >>>>>>> disavantage of lacking ways to transport configuration data that the >>>>>>> other bus needs to instantiate the dummy device (such as the reg >>>>>>> property for example, denoting the I2C slave address or the DSI VC). >>>>>>> >>>>>>> So how about we create two devices in the device tree and fuse them at >>>>>>> the driver level: >>>>>>> >>>>>>> i2c@... { >>>>>>> ... >>>>>>> >>>>>>> i2cdsi: dsi-device@... { >>>>>>> ... >>>>>>> }; >>>>>>> >>>>>>> ... >>>>>>> }; >>>>>>> >>>>>>> dsi@... { >>>>>>> ... >>>>>>> >>>>>>> peripheral@... { >>>>>>> ... >>>>>>> control = <&i2cdsi>; >>>>>>> ... >>>>>>> }; >>>>>>> >>>>>>> ... >>>>>>> }; >>>>>>> >>>>>>> This way we'll get both an I2C device and a DSI device that we can fully >>>>>>> describe using the standard device tree bindings. At driver time we can >>>>>>> get the I2C device from the phandle in the control property of the DSI >>>>>>> device and use it to execute I2C transactions. >>>>>>> >>>>>> I don't really like to see that you are inventing yet-another-way to >>>>>> handle devices connected to multiple buses. >>>>>> >>>>>> Devicetree is structured along the control buses, even if the devices >>>>>> are connected to multiple buses, in the DT they are always children of >>>>>> the bus that is used to control their registers from the CPUs >>>>>> perspective. So a DSI encoder that is controlled through i2c is clearly >>>>>> a child of the i2c master controller and only of that one. >>>>> >>>>> I think that's a flawed interpretation of what's going on here. The >>>>> device in fact has two interfaces: one is I2C, the other is DSI. In my >>>>> opinion that's reason enough to represent it as two logical devices. >>>>> >>>> Does it really have 2 control interfaces that are used at the same time? >>>> Or is the DSI connection a passive data bus if the register control >>>> happens through i2c? >>> >>> The interfaces may not be used at the same time, and the DSI interface >>> may even be crippled, but the device is still addressable from the DSI >>> host controller, if for nothing else than for routing the video stream. >>> >>>>>> If you need to model connections between devices that are not reflected >>>>>> through the control bus hierarchy you should really consider using the >>>>>> standardized of-graph bindings. >>>>>> (Documentation/devicetree/bindings/graph.txt) >>>>> >>>>> The problem is that the original proposal would instantiate a dummy >>>>> device, so it wouldn't be represented in DT at all. So unless you do add >>>>> two logical devices to DT (one for each bus interface), you don't have >>>>> anything to glue together with an OF graph. >>>>> >>>> I see that the having dummy device is the least desirable solution. But >>>> if there is only one control bus to the device I think it should be one >>>> device sitting beneath the control bus. >>>> >>>> You can then use of-graph to model the data path between the DSI encoder >>>> and device. >>> >>> But you will be needing a device below the DSI host controller to >>> represent that endpoint of the connection. The DSI host controller >>> itself is in no way connected to the I2C adapter. You would have to >>> add some sort of quirk to the DSI controller binding to allow it to >> >> Thanks for the review. >> >> I implemented this to support ADV7533 DSI to HDMI encoder chip, which >> has a DSI video bus and an i2c control bus. >> >> There weren't any quirks as such in the device tree when I tried to >> implement this. The DT seems to manage fine without a node >> corresponding to a mipi_dsi_device: >> >> i2c_adap@.. { >> adv7533@.. { >> >> port { >> adv_in: endpoint { >> remote-endpoint = <&dsi_out>; >> }; >> }; >> }; >> }; >> >> dsi_host@.. { >> ... >> ... >> >> port { >> dsi_out: endpoint { >> remote-endpoint = <&adv_in>; >> } >> }; >> }; >> >> It's the i2c driver's job to parse the graph and retrieve the >> phandle to the dsi host. Using this, it can proceed with >> registering itself to this host using the new dsi funcs. This >> patch does the same for the adv7533 i2c driver: >> >> http://www.spinics.net/lists/dri-devel/msg86840.html >> >>> hook up with a control endpoint. And then you'll need more quirks >>> to describe what kind of DSI device this is. >> >> Could you explain what you meant by this? I.e. describing the kind >> of DSI device? > > Describing the number of lanes, specifying the virtual channel, mode > flags, etc. You could probably set the number of lanes and mode flags > via the I2C driver, but especially the virtual channel cannot be set > because it isn't known to the I2C DT branch of the device. I agree with the VC part. It could be a DT entry within the i2c client node, but that does make it seem like a quirk. The 'reg' way under the DSI host is definitely better to populate the virtual channel. > >> The dsi device created isn't really a dummy device as such. It's >> dummy in the sense that there isn't a real dsi driver associated >> with it. The dsi device is still used to attach to a mipi dsi host, >> the way normal dsi devices do. > > I understand, but I don't see why it has to be instantiated by the I2C > driver, that's what I find backwards. There is already a standard way > for instantiating DSI devices, why not use it? I assumed we could either represent the device using an i2c driver, or dsi, but not both. Hence, I came up with this approach. > >>> On the other hand if you properly instantiate the DSI device you can >>> easily write a driver for it, and the driver will set up the correct >>> properties as implied by the compatible string. Once you have that you >>> can easily hook it up to the I2C control interface in whatever way you >>> like, be that an OF graph or just a simple unidirectional link by >>> phandle. >>> >> >> With the fused approach you suggested, we would have 2 drivers: one i2c >> and the other dsi. The i2c client driver would be more or less minimal, >> preparing an i2c_client device for the dsi driver to use. Is my >> understanding correct? > > Correct. That's kind of similar to the way an HDMI encoder driver would > use an I2C adapter to query EDID. The i2c_client device would be a means > for the DSI driver to access the control interface. Okay. Although, I'm not sure about the HDMI encoder example. An HDMI encoder would read off edid directly from the adapter(with an address specified), it wouldn't need to create an i2c client device. Therefore, an HDMI encoder wouldn't need to have a separate node for i2c in DT. > >> We can do without dummy dsi devices with this method. But, representing >> a device with 2 DT nodes seems a bit off. We'd also need to compatible >> strings for the same device, one for the i2c part, and the other for >> the dsi part. > > I agree that this somewhat stretches the capabilities of device tree. > Another alternative I guess would be to not have a compatible string for > the I2C device at all (that's technically not valid, I guess) because we > really don't need an I2C driver for the device. What we really need is a > DSI driver with a means to talk over some I2C bus with some other part > of its device. I think what the driver should 'really' be is a bit subjective, and can vary based on what the buses are used for in the device. For the Toshiba chip that Jani mentioned, it tends more towards a DSI driver. Whereas, for an ADV75xx chip, it's closer to an I2C driver since only I2C can be used to configure the chip registers. Although, I agree with the point you made about the DSI bus here: "and the DSI interface may even be crippled, but the device is still addressable from the DSI host controller, if for nothing else than for routing the video stream." The fact that the data on the DSI bus contains routing information (i.e, virtual channel number) always gives it some 'control' aspect. > >> From an adv75xx driver perspective, it should also support the ADV7511 >> chip, which is a RGB/DPI to HDMI encoder. For adv7511, we don't need a >> DSI DT node. It would be a bit inconsistent to have the bindings >> require both DSI and I2C nodes for one chip, and only I2C node for the >> other, with both chips being supported by the same driver. > > Why would that be inconsistent? That sounds like the most accurate > representation of the hardware to me. Inconsistent wasn't the right term. I should have used 'uncommon' :) It's common for two chips of the same family to have a different set optional properties in DT, but it's not common for two chips of the same family to be represented by a different number of devices in DT. I don't have an issue with the fused approach you suggested, as long as people are okay with the DT parts. Especially the part of needing 2 compatible strings in the DT. Thanks, Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project