From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark yao Subject: Re: [PATCH 2/2] dt-bindings: add simple-panel-dsi and simple-panel Date: Wed, 27 Jul 2016 11:03:05 +0800 Message-ID: <57982469.6030201@rock-chips.com> References: <1468984730-23186-1-git-send-email-mark.yao@rock-chips.com> <1468984730-23186-2-git-send-email-mark.yao@rock-chips.com> <20160725152125.GS21170@ulmo.ba.sec> <5796C47C.5040208@rock-chips.com> <20160726090226.GB2433@ulmo.ba.sec> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20160726090226.GB2433@ulmo.ba.sec> 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: Mark Rutland , =?UTF-8?B?6buE5rab?= , =?UTF-8?B?5bqE5paH6b6Z?= , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, Rob Herring , linux-arm-kernel@lists.infradead.org List-Id: linux-rockchip.vger.kernel.org T24gMjAxNuW5tDA35pyIMjbml6UgMTc6MDIsIFRoaWVycnkgUmVkaW5nIHdyb3RlOgo+IE9uIFR1 ZSwgSnVsIDI2LCAyMDE2IGF0IDEwOjAxOjMyQU0gKzA4MDAsIE1hcmsgeWFvIHdyb3RlOgo+PiBP biAyMDE25bm0MDfmnIgyNeaXpSAyMzoyMSwgVGhpZXJyeSBSZWRpbmcgd3JvdGU6Cj4+Cj4+ICAg ICAgT24gV2VkLCBKdWwgMjAsIDIwMTYgYXQgMTE6MTg6NTBBTSArMDgwMCwgTWFyayBZYW8gd3Jv dGU6Cj4+Cj4+ICAgICAgICAgIEFsbG93IHVzZXIgYWRkIGRpc3BsYXkgdGltaW5nIG9uIGRldmlj ZSB0cmVlIHdpdGggc2ltcGxlLXBhbmVsLWRzaQo+PiAgICAgICAgICBvciBzaW1wbGUtcGFuZWwu Cj4+Cj4+ICAgICAgICAgIENjOiBUaGllcnJ5IFJlZGluZyA8dGhpZXJyeS5yZWRpbmdAZ21haWwu Y29tPgo+PiAgICAgICAgICBDYzogUm9iIEhlcnJpbmcgPHJvYmgrZHRAa2VybmVsLm9yZz4KPj4g ICAgICAgICAgQ2M6IE1hcmsgUnV0bGFuZCA8bWFyay5ydXRsYW5kQGFybS5jb20+Cj4+Cj4+ICAg ICAgICAgIFNpZ25lZC1vZmYtYnk6IE1hcmsgWWFvIDxtYXJrLnlhb0Byb2NrLWNoaXBzLmNvbT4K Pj4gICAgICAgICAgLS0tCj4+ICAgICAgICAgICAuLi4vYmluZGluZ3MvZGlzcGxheS9wYW5lbC9z aW1wbGUtcGFuZWwudHh0ICAgICAgICB8IDQ4ICsrKysrKysrKysrKysrKysrKysrKysKPj4gICAg ICAgICAgIDEgZmlsZSBjaGFuZ2VkLCA0OCBpbnNlcnRpb25zKCspCj4+Cj4+ICAgICAgU29ycnks IG5vdCBnb2luZyB0byBoYXBwZW4uIFJlYWQgdGhpcyBmb3IgYW4gZXhwbGFuYXRpb24gb2Ygd2h5 IG5vdDoKPj4KPj4gICAgICAgICAgICAgIGh0dHBzOi8vc2lldGNoLXRhZ3IuYmxvZ3Nwb3QuZGUv MjAxNi8wNC9kaXNwbGF5LXBhbmVscy1hcmUtbm90LXNwZWNpYWwuaHRtbAo+Pgo+PiAgICAgIFRo aWVycnkKPj4KPj4KPj4gSGkgVGhpZXJyeQo+Pgo+PiBUaGUgYmxvZyBhY3R1YWxseSBub3QgcGVy c3VhZGUgbWUgd2h5IGNhbid0IHVzZSBkaXNwbGF5IHRpbWluZyBvbgo+PiBkZXZpY2UgdHJlZS4K PiBPa2F5LCBwZXJoYXBzIHJlYWQgaXQgYWdhaW4sIGl0IGFkZHJlc3NlcyBtb3N0IG9mIHlvdXIg cG9pbnRzIGJlbG93Lgo+Cj4+IDEsIEJpbmRpbmcgcGFuZWwgYXMgYSBzaW1wbGUgc3RyaW5nIG9u IGRldmljZSB0cmVlIHNlZW1zIHNpbXBsZSBvbiBkZXZpY2UgdHJlZSwKPj4gYnV0IGl0J3MgY29t cGxleCBvbiBrZXJuZWwgY29kZSwgYW5kIGtlcm5lbCBjb2RlIHdvdWxkIGJlY2FtZSBiaWdnZXIg YW5kCj4+IGJpZ2dlci4KPiBJIGRvbid0IHRoaW5rIHRoZSB2aWRlbyB0aW1pbmdzIGluIHRoZSBz aW1wbGUtcGFuZWwgZHJpdmVyIGFyZSB2ZXJ5Cj4gY29tcGxleC4gVGhleSBhbHNvIGRvbid0IHVz ZSB2ZXJ5IG11Y2ggc3BhY2UuIEFuZCBpZiB5b3UncmUgcmVhbGx5Cj4gY29uY2VybmVkIGFib3V0 IHNwYWNlIHlvdSBjYW4gYWx3YXlzIHVzZSBjb25kaXRpb25hbCBjb21waWxhdGlvbiBhbmQKPiBL Y29uZmlnIHN5bWJvbHMgdG8gcmVtb3ZlIHRpbWluZ3MgZm9yIHBhbmVscyB0aGF0IHlvdSBkb24n dCB1c2UuCj4KPiBBbHNvLCBwYW5lbHMgYXJlIGNoYXJhY3Rlcml6ZWQgYnkgbXVjaCBtb3JlIHRo YW4ganVzdCB2aWRlbyB0aW1pbmdzLgo+IFRoZXJlIHdlcmUgYXR0ZW1wdHMsIHdheSBiYWNrLCB0 byBmdWxseSBkZXNjcmliZSBwYW5lbHMgaW4gZGV2aWNlIHRyZWUKPiBhbmQgdGhhdCBmYWlsZWQu IFdoYXQgeW91IHByb3Bvc2UgaGVyZSBpcyBhIHBhcnRpYWwgc29sdXRpb24gdG8gYSBtdWNoCj4g bW9yZSBjb21wbGV4IHByb2JsZW0uCj4KPiBUaGlzIGlzIGFsbCBleHBsYWluZWQgaW4gdGhlIGJs b2cgcG9zdC4KPgo+PiAyLCBPdXIgY3VzdG9tZXIgYWx3YXlzIGFzayBtZSwgd2hlcmUgaXMgdGhl IGRpc3BsYXkgdGltaW5nPyBUaGV5IG9ubHkgZmluZCBhCj4+IHNpbXBsZSBwYW5lbCBzdHJpbmcg b24gZGV2aWNlIHRyZWUsICBuZWVkIHNlYXJjaCB0aGUga2VybmVsIGNvZGUgdG8gZmluZCB0aGUK Pj4gYWN0dWFsbHkgdGltaW5nLiBUaGV5IGFyZSB1c2VkIHRvIGZpbmQgYWxsIGRldmljZSBpbmZv IG9uIGRldmljZSB0cmVlLCBidXQKPj4gcGFuZWwgdGltaW5nIGluZm8gaXMgbm90LCB0aGlzIHdv dWxkIGNvbmZ1c2UgdGhlbS4gVGhleSBkb24ndCB3YW50IHRvIGtub3cgaG93Cj4+IGNvZGUgd29y aywganVzdCB3YW50IGEgZWFzaWVyIGludGVyZmFjZS4KPiBUaGF0J3Mgbm90IGEgdmVyeSBnb29k IGFyZ3VtZW50LiBUaGVyZSdzIHBsZW50eSBvZiBkYXRhIHRoYXQncyBub3QgaW4KPiBkZXZpY2Ug dHJlZSBmb3Igb3RoZXIgZGV2aWNlcywgd2h5IHNob3VsZCBwYW5lbHMgYmUgZGlmZmVyZW50PyBB bHNvLCBJCj4gd291bGQgaG9wZSB0aGF0IGFueSBjdXN0b21lciBvZiB5b3VycyBrbm93cyB0aGVp ciB3YXkgYXJvdW5kIGtlcm5lbAo+IGNvZGUgYW5kIGNhbiB0aGVyZWZvcmUgZWFzaWx5IGFkZCB2 aWRlbyB0aW1pbmdzIGZvciBuZXcgcGFuZWxzLiBJdCdzCj4gcXVpdGUgdHJpdmlhbCB0byBkbywg YW5kIHRoZXJlIGFyZSBtYW55IGV4YW1wbGVzIG9uIGhvdyB0byBkbyBpdC4KPgo+PiAzLCBJIHRo aW5rIGRldmljZSB0cmVlIG5vdCBvbmx5IGNhbiB1c2UgZm9yIGtlcm5lbCwgb3RoZXIgbW9kdWxl IGFsc28gY2FuIHVzZQo+PiBpdC4gb24gb3VyIHByb2plY3QsIHdlIHVzZSB1Ym9vdCArIGtlcm5l bCwgdGhlIHVib290IHN1cHBvcnQgZmR0LCB0aGF0IGZ1bmN0aW9uCj4+IGNhbiBwYXJzaW5nIGRl dmljZSB0cmVlLiBTbyBpZiBkZXNjcmliZSB0aGUgZGlzcGxheSB0aW1pbmcgb24gZGV2aWNlIHRy ZWUsIGJvdGgKPj4gdWJvb3QgYW5kIGtlcm5lbCBjYW4gc2hhcmUgc2FtZSBkaXNwbGF5IHRpbWlu Zywgbm90IG5lZWQgdG8gZGVzY3JpYmUgdHdpY2UsIGl0Cj4+IHdvdWxkIHNhdmUgd29yayBhbmQg bm90IGVhc3kgdG8gbWFrZSBtaXN0YWtlLgo+IFRoYXQncyBhIGJpdCBvZiBhIHN0cmV0Y2guIFZp ZGVvIHRpbWluZ3MgaXMgZmFpcmx5IHN0cmFpZ2h0Zm9yd2FyZCBkYXRhCj4gYW5kIGNhbiBiZSBl YXNpbHkgYWRkZWQgdG8gYW55IG90aGVyIHBpZWNlIG9mIGNvZGUgdGhhdCB5b3Ugd2FudCB0byBy dW4uCj4gWWVzIHlvdSB3aWxsIGhhdmUgdG8gZHVwbGljYXRlIHRoZSBkYXRhLCBidXQgaG93IGlz IHRoYXQgZGlmZmVyZW50IGZyb20KPiBkdXBsaWNhdGluZyBhbGwgdGhlIGRyaXZlciBjb2RlPwo+ Cj4+IDQsIEZvciBkaWZmZXJlbnRpYXRpb24gcHJvZHVjdCwgd2UgZmFjZSBtYW55IGRpZmZlcmVu dCBwYW5lbCwgZXZlcnkgb25jZSBpbiBhCj4+IHdoaWxlLCBuZWVkIHRvIGFkZCBhIG5ldyBwYW5l bCwgd2UgY2FuJ3QgY29udmVydCBhbGwgdGhlIHBhbmVsICwgY29kZSB0aGUgcGFuZWwKPj4gb24g a2VybmVsIHNlZW1zIHRvbyBiYWQsIGFuZCB0aGUga2VybmVsIGltYWdlIGJlY2FtZSBiaWdnZXIg YW5kIGJpZ2dlci4KPiBXaHkgY2FuJ3QgeW91IGNvbnZlcnQgYWxsIHRoZSBwYW5lbHM/IFdlIGFs cmVhZHkgc3VwcG9ydCBhIGJ1bmNoIG9mIHRoZW0KPiBhbmQgaGF2ZW4ndCB5ZXQgcnVuIGludG8g YW55IHByb2JsZW1zLiBJZiB5b3UgZG8gZW5jb3VudGVyIGFueSBpc3N1ZXMKPiB0cnlpbmcgdG8g cG9ydCBwYW5lbHMgdG8gdGhlIERSTSBwYW5lbCBpbmZyYXN0cnVjdHVyZSwgcGxlYXNlIGxldCBt ZQo+IGtub3cgYW5kIEkgY2FuIGhlbHAgc29ydCB0aGVtIG91dC4KPgo+IFRoZSBrZXJuZWwgaW1h Z2Ugc2l6ZSBpc24ndCBhIHByb2JsZW0gZWl0aGVyLiBJbiBhbnkgbW9kZXJuIGtlcm5lbCB0aGUK PiB2aWRlbyB0aW1pbmcgZGF0YSBpbiB0aGUgcGFuZWwgZHJpdmVyIGlzIHRpbnkgY29tcGFyZWQg dG8gdGhlIHJlc3QuCj4KPj4gR2VuZXJhbGx5LCBPdXIgY3VzdG9tZXIgZG9uJ3Qgd2FudCB0byBk byBhbnkgbW9kaWZ5IG9uIGtlcm5lbCwgdGhleSBqdXN0IG1vZGlmeQo+PiBkZXZpY2UgdHJlZSB0 byBicmluZyB1cCB0aGVpciBkZXZpY2UuIERlc2NyaWJlIHRoZSBwYW5lbCB0aW1pbmcgb24gZGV2 aWNlIHRyZWUsCj4+IHdvdWxkIG1ha2UgY3VzdG9tZXIgZWFzeSB0byB1c2UgYW5kIHJldXNlIGl0 Lgo+IFllcywgdGhhdCB3b3VsZCBwZXJoYXBzIG1ha2UgaXQgZWFzaWVyIGZvciB0aGVtIHRvIGJy aW5nIHVwIHRoZSBkZXZpY2UuCj4gQnV0IHNvb24gYWZ0ZXIgdGhleSdsbCBub3RpY2UgdGhhdCB0 aGVyZSBhcmUgZ2xpdGNoZXMgd2hlbiB0dXJuaW5nIHRoZQo+IHBhbmVsIG9uIGFuZCBvZmYsIGFu ZCB0aGVuIHRoZXknbGwgcmVhbGl6ZSB0aGF0IHRoZXkgY2FuJ3QgZml4IHRoYXQKPiB1c2luZyB0 aGVpciBzaW1wbGUgZGV2aWNlIHRyZWUuCkFib3V0IHRoZSBwYW5lbCBvbiBhbmQgb2ZmLCBJIGRv bid0IHRoaW5rIHRoZSBwYW5lbC1zaW1wbGUgZG8gdGhlIGdvb2QgCmVub3VnaC4KCnBhbmVsLXNp bXBsZSBvbmx5IGhhdmUgb25lIGdwaW8gYW5kIG9uZSByZWd1bGF0b3IsIGFuZCB0aGVpciBzZXF1 ZW5jZSBpcyAKaGFyZCBjb2RlLCBXaHkgbm90IGEgcGFuZWwgaGF2ZSB0d28gZ3BpbyBvciB0d28g cmVndWxhdG9yPyBPbiBvdXIgCnByb2plY3QsIHdlIGZpbmQgbWFueSBjdXN0b21lciBkb24ndCB1 c2UgdGhlIFJDIHRvIGRvIHBhbmVsIHJlc2V0LCB0aGV5IApkaXJlY3RseSB1c2UgZ3BpbyByZXNl dCwgc28gdGhleSBuZWVkIGEgZ3BpbyB0byBkbyBwYW5lbCByZXNldC4KCnRoZSBkZXZpY2UgdHJl ZSBwYW5lbCdzIG9uIGFuZCBvZmYgZnVuY3Rpb24gaXMgd2hhdCB0aGUgbmV4dCBzdGVwIEkgd2Fu dCAKdG8gdXBzdHJlYW0sIG9uIG91ciBkb3duc3RyZWFtIGtlcm5lbCwgd2UgZG8gbGlrZSB0aGF0 OgoKcGFuZWwgewogICAgIHBvd2VyX2N0cmwgewogICAgICAgICAgIHBvd2VyMCB7CiAgICAgICAg ICAgICAgICAgICBncGlvcyA9IDx4eHg+OwogICAgICAgICAgICAgICAgICAgZGVsYXksbXMgPSA8 Mz47CiAgICAgICAgICAgfQogICAgICAgICAgIHBvd2VyMSB7CiAgICAgICAgICAgICAgICAgICBy ZWd1bGF0b3IgPSA8eHh4PjsKICAgICAgICAgICAgICAgICAgIGRlbGF5LG1zID0gPDM+OwogICAg ICAgICAgIH0KICAgICAgICAgICBwb3dlcjIgewogICAgICAgICAgICAgICAgICAgYmFja2xpZ2h0 ID0gPHh4eD47CiAgICAgICAgICAgICAgICAgICBkZWxheSxtcyA9IDwzPjsKICAgICAgICAgICB9 CiAgICAgfQp9CmFuZCBvbiBkcml2ZXIsIHBvd2VyIG9uIHNlcXVlbmNlIHdpdGggcG93ZXIwLT5w b3dlcjEtPnBvd2VyMiwgcG93ZXIgZG93biAKd2l0aCBwb3dlcjItPnBvd2VyMS0+cG93ZXIwLgpp ZiB1c2VyIHdhbnQgdG8gc3dhcCB0aGUgcG93ZXIsIGNhbiBlYXN5IGRvIHRoYXQgYnkgIGFkanVz dCBkdHMgcG93ZXIgCnNlcXVlbmNlLgoKdGhpcyBtZXRob2QgY2FuIGVhc3kgb3JkZXIgdGhlIGdw aW8sIHJlZ3VsYXRvciwgYmFja2xpZ2h0IHNlcXVlbmNlLCAKanVkZ2UgdGhlIGRlbGF5IHRpbWUg YW5kIGFkZCBuZXcgcmVndWxhdG9yIG9yIGdwaW8uCkkgdGhpbmsgdGhpcyBwYW5lbCBwb3dlciBv biBhbmQgb2ZmIG1ldGhvZCBpcyBiZXR0ZXIgdGhhbiBwYW5lbC1zaW1wbGUgCmRyaXZlciBjdXJy ZW50bHkgdXNpbmcuCgo+IEFsbCBvZiB0aGF0IHNhaWQsIGlmIHlvdSBkbyB0aGluayB0aGlzIGlz IHZhbHVhYmxlIHRvIHlvdXIgY3VzdG9tZXJzLAo+IHBsZWFzZSBmZWVsIGZyZWUgdG8gc2hpcCB0 aGVzZSBwYXRjaGVzIGluIHlvdXIgZG93bnN0cmVhbSB0cmVlLgo+Cj4gQWxzbywgdGhvdWdoIHRo aXMgaXMgYSBiaXQgb2ZmIHRvcGljLCBJJ20gc3VyZSB0aGF0IHlvdXIgY3VzdG9tZXJzJwo+IGN1 c3RvbWVycyB3b3VsZCBiZSB2ZXJ5IGhhcHB5IHRvIGdldCBhbGwgdGhlIHNlY3VyaXR5IGFuZCBi dWcgZml4ZXMgdGhhdAo+IHdvdWxkIGF1dG9tYXRpY2FsbHkgYmUgZGVsaXZlcmVkIHdpdGggdGhl IGZyZXF1ZW50IGtlcm5lbCB1cGRhdGVzIHRoYXQKPiBicmluZyBpbiBzdXBwb3J0IGZvciBuZXcg cGFuZWxzLgo+Cj4gVGhpZXJyeQoKCi0tIArvvK1hcmsgWWFvCgoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmkt ZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3Jn L21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark.yao@rock-chips.com (Mark yao) Date: Wed, 27 Jul 2016 11:03:05 +0800 Subject: [PATCH 2/2] dt-bindings: add simple-panel-dsi and simple-panel In-Reply-To: <20160726090226.GB2433@ulmo.ba.sec> References: <1468984730-23186-1-git-send-email-mark.yao@rock-chips.com> <1468984730-23186-2-git-send-email-mark.yao@rock-chips.com> <20160725152125.GS21170@ulmo.ba.sec> <5796C47C.5040208@rock-chips.com> <20160726090226.GB2433@ulmo.ba.sec> Message-ID: <57982469.6030201@rock-chips.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 2016?07?26? 17:02, Thierry Reding wrote: > On Tue, Jul 26, 2016 at 10:01:32AM +0800, Mark yao wrote: >> On 2016?07?25? 23:21, Thierry Reding wrote: >> >> On Wed, Jul 20, 2016 at 11:18:50AM +0800, Mark Yao wrote: >> >> Allow user add display timing on device tree with simple-panel-dsi >> or simple-panel. >> >> Cc: Thierry Reding >> Cc: Rob Herring >> Cc: Mark Rutland >> >> Signed-off-by: Mark Yao >> --- >> .../bindings/display/panel/simple-panel.txt | 48 ++++++++++++++++++++++ >> 1 file changed, 48 insertions(+) >> >> Sorry, not going to happen. Read this for an explanation of why not: >> >> https://sietch-tagr.blogspot.de/2016/04/display-panels-are-not-special.html >> >> Thierry >> >> >> Hi Thierry >> >> The blog actually not persuade me why can't use display timing on >> device tree. > Okay, perhaps read it again, it addresses most of your points below. > >> 1, Binding panel as a simple string on device tree seems simple on device tree, >> but it's complex on kernel code, and kernel code would became bigger and >> bigger. > I don't think the video timings in the simple-panel driver are very > complex. They also don't use very much space. And if you're really > concerned about space you can always use conditional compilation and > Kconfig symbols to remove timings for panels that you don't use. > > Also, panels are characterized by much more than just video timings. > There were attempts, way back, to fully describe panels in device tree > and that failed. What you propose here is a partial solution to a much > more complex problem. > > This is all explained in the blog post. > >> 2, Our customer always ask me, where is the display timing? They only find a >> simple panel string on device tree, need search the kernel code to find the >> actually timing. They are used to find all device info on device tree, but >> panel timing info is not, this would confuse them. They don't want to know how >> code work, just want a easier interface. > That's not a very good argument. There's plenty of data that's not in > device tree for other devices, why should panels be different? Also, I > would hope that any customer of yours knows their way around kernel > code and can therefore easily add video timings for new panels. It's > quite trivial to do, and there are many examples on how to do it. > >> 3, I think device tree not only can use for kernel, other module also can use >> it. on our project, we use uboot + kernel, the uboot support fdt, that function >> can parsing device tree. So if describe the display timing on device tree, both >> uboot and kernel can share same display timing, not need to describe twice, it >> would save work and not easy to make mistake. > That's a bit of a stretch. Video timings is fairly straightforward data > and can be easily added to any other piece of code that you want to run. > Yes you will have to duplicate the data, but how is that different from > duplicating all the driver code? > >> 4, For differentiation product, we face many different panel, every once in a >> while, need to add a new panel, we can't convert all the panel , code the panel >> on kernel seems too bad, and the kernel image became bigger and bigger. > Why can't you convert all the panels? We already support a bunch of them > and haven't yet run into any problems. If you do encounter any issues > trying to port panels to the DRM panel infrastructure, please let me > know and I can help sort them out. > > The kernel image size isn't a problem either. In any modern kernel the > video timing data in the panel driver is tiny compared to the rest. > >> Generally, Our customer don't want to do any modify on kernel, they just modify >> device tree to bring up their device. Describe the panel timing on device tree, >> would make customer easy to use and reuse it. > Yes, that would perhaps make it easier for them to bring up the device. > But soon after they'll notice that there are glitches when turning the > panel on and off, and then they'll realize that they can't fix that > using their simple device tree. About the panel on and off, I don't think the panel-simple do the good enough. panel-simple only have one gpio and one regulator, and their sequence is hard code, Why not a panel have two gpio or two regulator? On our project, we find many customer don't use the RC to do panel reset, they directly use gpio reset, so they need a gpio to do panel reset. the device tree panel's on and off function is what the next step I want to upstream, on our downstream kernel, we do like that: panel { power_ctrl { power0 { gpios = ; delay,ms = <3>; } power1 { regulator = ; delay,ms = <3>; } power2 { backlight = ; delay,ms = <3>; } } } and on driver, power on sequence with power0->power1->power2, power down with power2->power1->power0. if user want to swap the power, can easy do that by adjust dts power sequence. this method can easy order the gpio, regulator, backlight sequence, judge the delay time and add new regulator or gpio. I think this panel power on and off method is better than panel-simple driver currently using. > All of that said, if you do think this is valuable to your customers, > please feel free to ship these patches in your downstream tree. > > Also, though this is a bit off topic, I'm sure that your customers' > customers would be very happy to get all the security and bug fixes that > would automatically be delivered with the frequent kernel updates that > bring in support for new panels. > > Thierry -- ?ark Yao From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752235AbcG0DDk (ORCPT ); Tue, 26 Jul 2016 23:03:40 -0400 Received: from regular1.263xmail.com ([211.150.99.133]:39032 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750857AbcG0DDd (ORCPT ); Tue, 26 Jul 2016 23:03:33 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: mark.yao@rock-chips.com X-FST-TO: huangtao@rock-chips.com X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: mark.yao@rock-chips.com X-UNIQUE-TAG: <68d6fe5239c1629d36a66fa577baa0eb> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH 2/2] dt-bindings: add simple-panel-dsi and simple-panel To: Thierry Reding References: <1468984730-23186-1-git-send-email-mark.yao@rock-chips.com> <1468984730-23186-2-git-send-email-mark.yao@rock-chips.com> <20160725152125.GS21170@ulmo.ba.sec> <5796C47C.5040208@rock-chips.com> <20160726090226.GB2433@ulmo.ba.sec> Cc: David Airlie , Heiko Stuebner , dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, Rob Herring , Mark Rutland , =?UTF-8?B?J+m7hOWutumSlyc=?= , =?UTF-8?B?5bqE5paH6b6Z?= , =?UTF-8?B?6buE5rab?= From: Mark yao Message-ID: <57982469.6030201@rock-chips.com> Date: Wed, 27 Jul 2016 11:03:05 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20160726090226.GB2433@ulmo.ba.sec> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016年07月26日 17:02, Thierry Reding wrote: > On Tue, Jul 26, 2016 at 10:01:32AM +0800, Mark yao wrote: >> On 2016年07月25日 23:21, Thierry Reding wrote: >> >> On Wed, Jul 20, 2016 at 11:18:50AM +0800, Mark Yao wrote: >> >> Allow user add display timing on device tree with simple-panel-dsi >> or simple-panel. >> >> Cc: Thierry Reding >> Cc: Rob Herring >> Cc: Mark Rutland >> >> Signed-off-by: Mark Yao >> --- >> .../bindings/display/panel/simple-panel.txt | 48 ++++++++++++++++++++++ >> 1 file changed, 48 insertions(+) >> >> Sorry, not going to happen. Read this for an explanation of why not: >> >> https://sietch-tagr.blogspot.de/2016/04/display-panels-are-not-special.html >> >> Thierry >> >> >> Hi Thierry >> >> The blog actually not persuade me why can't use display timing on >> device tree. > Okay, perhaps read it again, it addresses most of your points below. > >> 1, Binding panel as a simple string on device tree seems simple on device tree, >> but it's complex on kernel code, and kernel code would became bigger and >> bigger. > I don't think the video timings in the simple-panel driver are very > complex. They also don't use very much space. And if you're really > concerned about space you can always use conditional compilation and > Kconfig symbols to remove timings for panels that you don't use. > > Also, panels are characterized by much more than just video timings. > There were attempts, way back, to fully describe panels in device tree > and that failed. What you propose here is a partial solution to a much > more complex problem. > > This is all explained in the blog post. > >> 2, Our customer always ask me, where is the display timing? They only find a >> simple panel string on device tree, need search the kernel code to find the >> actually timing. They are used to find all device info on device tree, but >> panel timing info is not, this would confuse them. They don't want to know how >> code work, just want a easier interface. > That's not a very good argument. There's plenty of data that's not in > device tree for other devices, why should panels be different? Also, I > would hope that any customer of yours knows their way around kernel > code and can therefore easily add video timings for new panels. It's > quite trivial to do, and there are many examples on how to do it. > >> 3, I think device tree not only can use for kernel, other module also can use >> it. on our project, we use uboot + kernel, the uboot support fdt, that function >> can parsing device tree. So if describe the display timing on device tree, both >> uboot and kernel can share same display timing, not need to describe twice, it >> would save work and not easy to make mistake. > That's a bit of a stretch. Video timings is fairly straightforward data > and can be easily added to any other piece of code that you want to run. > Yes you will have to duplicate the data, but how is that different from > duplicating all the driver code? > >> 4, For differentiation product, we face many different panel, every once in a >> while, need to add a new panel, we can't convert all the panel , code the panel >> on kernel seems too bad, and the kernel image became bigger and bigger. > Why can't you convert all the panels? We already support a bunch of them > and haven't yet run into any problems. If you do encounter any issues > trying to port panels to the DRM panel infrastructure, please let me > know and I can help sort them out. > > The kernel image size isn't a problem either. In any modern kernel the > video timing data in the panel driver is tiny compared to the rest. > >> Generally, Our customer don't want to do any modify on kernel, they just modify >> device tree to bring up their device. Describe the panel timing on device tree, >> would make customer easy to use and reuse it. > Yes, that would perhaps make it easier for them to bring up the device. > But soon after they'll notice that there are glitches when turning the > panel on and off, and then they'll realize that they can't fix that > using their simple device tree. About the panel on and off, I don't think the panel-simple do the good enough. panel-simple only have one gpio and one regulator, and their sequence is hard code, Why not a panel have two gpio or two regulator? On our project, we find many customer don't use the RC to do panel reset, they directly use gpio reset, so they need a gpio to do panel reset. the device tree panel's on and off function is what the next step I want to upstream, on our downstream kernel, we do like that: panel { power_ctrl { power0 { gpios = ; delay,ms = <3>; } power1 { regulator = ; delay,ms = <3>; } power2 { backlight = ; delay,ms = <3>; } } } and on driver, power on sequence with power0->power1->power2, power down with power2->power1->power0. if user want to swap the power, can easy do that by adjust dts power sequence. this method can easy order the gpio, regulator, backlight sequence, judge the delay time and add new regulator or gpio. I think this panel power on and off method is better than panel-simple driver currently using. > All of that said, if you do think this is valuable to your customers, > please feel free to ship these patches in your downstream tree. > > Also, though this is a bit off topic, I'm sure that your customers' > customers would be very happy to get all the security and bug fixes that > would automatically be delivered with the frequent kernel updates that > bring in support for new panels. > > Thierry -- Ｍark Yao