From mboxrd@z Thu Jan 1 00:00:00 1970 From: spanda@codeaurora.org Subject: Re: [PATCH 2/2] drm/bridge: ti-sn65dsi86: Allow DT to set "HPD delay" Date: Thu, 25 Oct 2018 00:02:47 +0530 Message-ID: <9d5b42b94772fb3adb86e20eff72cd88@codeaurora.org> References: <20181019201940.138179-1-dianders@chromium.org> <20181019201940.138179-2-dianders@chromium.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20181019201940.138179-2-dianders@chromium.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Douglas Anderson Cc: David Airlie , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, ryandcase@chromium.org, Laurent Pinchart , Sean Paul List-Id: linux-arm-msm@vger.kernel.org T24gMjAxOC0xMC0yMCAwMTo0OSwgRG91Z2xhcyBBbmRlcnNvbiB3cm90ZToKPiBMZXQncyBzb2x2 ZSB0aGUgbXlzdGVyeSBvZiBjb21taXQgYmYxMTc4Yzk4OTMwICgiZHJtL2JyaWRnZToKPiB0aS1z bjY1ZHNpODY6IEFkZCBteXN0ZXJ5IGRlbGF5IHRvIGVuYWJsZSgpIikuICBTcGVjaWZpY2FsbHkg dGhlCj4gcmVhc29uIHdlIG5lZWRlZCB0aGF0IG15c3RlcnkgZGVsYXkgaXMgdGhhdCB3ZSB3ZXJl bid0IHBheWluZwo+IGF0dGVudGlvbiB0byBIUEQuCj4gCj4gTG9va2luZyBhdCB0aGUgZGF0YXNo ZWV0IGZvciB0aGUgc2FtZSBwYW5lbCB0aGF0IHdhcyB0ZXN0ZWQgZm9yIHRoZQo+IG9yaWdpbmFs IGNvbW1pdCwgSSBzZWUgdGhlcmUncyBhIHRpbWluZyAidDMiIHRoYXQgdGltZXMgZnJvbSBwb3dl ciBvbgo+IHRvIHRoZSBhdXggY2hhbm5lbCBiZWluZyBvcGVyYXRpb25hbC4gIFRoaXMgdGltZSBp cyBzcGVjY2VkIGFzIDAgLSAyMDAKPiBtcy4gIFRoZSBkYXRhc2hlZXQgc2F5cyB0aGF0IHRoZSBh dXggY2hhbm5lbCBpcyBvcGVyYXRpb25hbCBhdCBleGFjdGx5Cj4gdGhlIHNhbWUgdGltZSB0aGF0 IEhQRCBpcyBhc3NlcnRlZC4KPiAKPiBTY29waW5nIHRoZSBzaWduYWxzIG9uIHRoaXMgYm9hcmQg c2hvd2VkIHRoYXQgSFBEIHdhcyBhc3NlcnRlZCA4NCBtcwo+IGFmdGVyIHBvd2VyIHdhcyBhc3Nl cnRlZC4gIFRoYXQgdmVyeSBjbG9zZWx5IG1hdGNoZXMgdGhlIG1hZ2ljIDcwIG1zCj4gZGVsYXkg dGhhdCB3ZSBoYWQuICAuLi5hbmQgYWN0dWFsbHksIGluIG15IGVzdGluZyB0aGUgNzAgbXMgd2Fz bid0Cj4gcXVpdGUgZW5vdWdoIG9mIGEgZGVsYXkgYW5kIHNvbWUgcGVyY2VudGFnZSBvZiB0aGUg dGltZSB0aGUgZGlzcGxheQo+IGRpZG4ndCBjb21lIHVwIHVudGlsIEkgYnVtcGVkIGl0IHRvIDEw MCBtcy4KPiAKPiBUbyBzb2x2ZSB0aGlzLCB3ZSB0cmllZCB0byBob29rIHVwIHRoZSBIUEQgc2ln bmFsIGluIHRoZSBicmlkZ2UuCj4gLi4uYnV0IGluIGRvaW5nIHNvIHdlIGZvdW5kIHRoYXQgdGhh dCB0aGUgYnJpZGdlIGRpZG4ndCByZXBvcnQgdGhhdAo+IEhQRCB3YXMgYXNzZXJ0ZWQgdW50aWwg fjI4MCBtcyBhZnRlciB3ZSBwb3dlcmVkIGl0ICghKS4gIFRoaXMgaXMKPiBleHBsYWluZWQgYnkg bG9va2luZyBhdCB0aGUgc242NWRzaTg2IGRhdGFzaGVldCBzZWN0aW9uICI4LjQuNS4xIEhQRAo+ IChIb3QgUGx1Zy9VbnBsdWcgRGV0ZWN0aW9uKSIuICBSZWFkaW5nIHRoZXJlIHdlIHNlZSB0aGF0 IHRoZSBicmlkZ2UKPiBpc24ndCBldmVuIGludGVuZGVkIHRvIHJlcG9ydCBIUEQgdW50aWwgMTAw IG1zIGFmdGVyIGl0J3MgYXNzZXJ0ZWQuCj4gLi4uYnV0IHRoYXQgd291bGQgaGF2ZSBsZWZ0IHVz IGF0IDE4NCBtcy4gIFRoZSBleHRyYSAxMDAgbXMKPiAocHJlc3VtYWJseSkgY29tZXMgZnJvbSB0 aGlzIHBhcnQgaW4gdGhlIGRhdGFzaGVldDoKPiAKPj4gVGhlIEhQRCBzdGF0ZSBtYWNoaW5lIG9w ZXJhdGVzIG9mZiBhbiBpbnRlcm5hbCByaW5nIG9zY2lsbGF0b3IuIFRoZQo+PiByaW5nIG9zY2ls bGF0b3IgZnJlcXVlbmN5IHdpbGwgdmFyeSBbIC4uLiBdLiBUaGUgbWluL21heCByYW5nZSBpbgo+ PiB0aGUgSFBEIFN0YXRlIERpYWdyYW0gcmVmZXJzIHRvIHRoZSBwb3NzaWJsZSB0aW1lcyBiYXNl ZCBvZmYKPj4gdmFyaWF0aW9uIGluIHRoZSByaW5nIG9zY2lsbGF0b3IgZnJlcXVlbmN5Lgo+IAo+ IEdpdmVuIHRoYXQgdGhlIDI4MCBtcyB3ZSdsbCBlbmQgdXAgZGVsYXlpbmcgaWYgd2UgaG9vayB1 cCBIUEQgaXMKPiBfc2xvd2VyXyB0aGFuIHRoZSAyMDAgbXMgd2UgY291bGQganVzdCBoYXJkY29k ZSwgZm9yIG5vdyB3ZSdsbCBzb2x2ZQo+IHRoZSBwcm9ibGVtIGJ5IGp1c3QgYWxsb3dpbmcgYm9h cmRzIHRvIGhhcmRjb2RlIGEgdmFsdWUuICBJZiBzb21lb25lCj4gdXNpbmcgdGhpcyBwYXJ0IGZp bmRzIHRoYXQgdGhleSBjYW4gZ2V0IHRoaW5ncyB0byB3b3JrIG1vcmUgcXVpY2tseSBieQo+IGFj dHVhbGx5IGhvb2tpbmcgdXAgSFBEIHRoYXQgY2FuIGFsd2F5cyBiZSBhIGZ1dHVyZSBwYXRjaC4K PiAKPiBPbmUgbGFzdCBub3RlIGlzIHRoYXQgSSB0cmllZCB0byBzb2x2ZSB0aGlzIHRocm91Z2gg YW5vdGhlciB3YXk6IEluCj4gdGlfc25fYnJpZGdlX2VuYWJsZSgpIEkgdHJpZWQgdG8gdXNlIHZh cmlvdXMgY29tYmluYXRpb25zIG9mCj4gZHBfZHBjZF93cml0ZWIoKSBhbmQgZHBfZHBjZF9yZWFk YigpIHRvIGRldGVjdCB3aGVuIHRoZSBhdXggY2hhbm5lbAo+IHdhcyB1cC4gIEluIHRoZW9yeSB0 aGF0IHdvdWxkIGxldCBtZSBkZXRlY3QgX2V4YWN0bHlfIHdoZW4gSSBjb3VsZAo+IGNvbnRpbnVl IGFuZCBkbyBsaW5rIHRyYWluaW5nLiAgVW5mb3J0dW5hdGVseSBldmVuIGlmIEkgZGlkIGFuIGF1 eAo+IHRyYW5zZmVyIHcvb3V0IHdhaXRpbmcgSSBjb3VsZG4ndCBzZWUgYW55IGVycm9ycy4gIFBv c3NpYmx5IEkgY291bGQKPiBrZWVwIGxvb3Bpbmcgb3ZlciBsaW5rIHRyYWluaW5nIHVudGlsIGl0 IGNhbWUgYmFjayB3aXRoIHN1Y2Nlc3MsIGJ1dAo+IHRoYXQgc2VlbWVkIGEgbGl0dGxlIG92ZXJs eSBoYWNreSB0byBtZS4KPiAKClRoYW5rcyBmb3IgdmVyeSBkZXRhaWxlZCBleHBsYW5hdGlvbi4K Cj4gU2lnbmVkLW9mZi1ieTogRG91Z2xhcyBBbmRlcnNvbiA8ZGlhbmRlcnNAY2hyb21pdW0ub3Jn Pgo+IC0tLQo+IAo+ICBkcml2ZXJzL2dwdS9kcm0vYnJpZGdlL3RpLXNuNjVkc2k4Ni5jIHwgNDUg KysrKysrKysrKysrKysrKysrKysrKy0tLS0tCj4gIDEgZmlsZSBjaGFuZ2VkLCAzNyBpbnNlcnRp b25zKCspLCA4IGRlbGV0aW9ucygtKQo+IAo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2dwdS9kcm0v YnJpZGdlL3RpLXNuNjVkc2k4Ni5jCj4gYi9kcml2ZXJzL2dwdS9kcm0vYnJpZGdlL3RpLXNuNjVk c2k4Ni5jCj4gaW5kZXggZjhhOTMxY2YzNjY1Li41ZGVlZDY2NzQ4MGMgMTAwNjQ0Cj4gLS0tIGEv ZHJpdmVycy9ncHUvZHJtL2JyaWRnZS90aS1zbjY1ZHNpODYuYwo+ICsrKyBiL2RyaXZlcnMvZ3B1 L2RybS9icmlkZ2UvdGktc242NWRzaTg2LmMKPiBAQCAtOTMsNiArOTMsNyBAQCBzdHJ1Y3QgdGlf c25fYnJpZGdlIHsKPiAgCXN0cnVjdCBjbGsJCQkqcmVmY2xrOwo+ICAJc3RydWN0IGRybV9wYW5l bAkJKnBhbmVsOwo+ICAJc3RydWN0IGdwaW9fZGVzYwkJKmVuYWJsZV9ncGlvOwo+ICsJaW50CQkJ CXBhbmVsX2hwZF9kZWxheV9tczsKPiAgCXN0cnVjdCByZWd1bGF0b3JfYnVsa19kYXRhCXN1cHBs aWVzW1NOX1JFR1VMQVRPUl9TVVBQTFlfTlVNXTsKPiAgfTsKPiAKPiBAQCAtNDU5LDE2ICs0NjAs MzcgQEAgc3RhdGljIHZvaWQgdGlfc25fYnJpZGdlX2VuYWJsZShzdHJ1Y3QgZHJtX2JyaWRnZSAK PiAqYnJpZGdlKQo+ICAJaW50IHJldDsKPiAKPiAgCS8qCj4gLQkgKiBGSVhNRToKPiAtCSAqIFRo aXMgNzBtcyB3YXMgZm91bmQgbmVjZXNzYXJ5IGJ5IGV4cGVyaW1lbnRhdGlvbi4gSWYgaXQncyBu b3QKPiAtCSAqIHByZXNlbnQsIGxpbmsgdHJhaW5pbmcgZmFpbHMuIEl0IHNlZW1zIGxpa2UgaXQg Y2FuIGdvIGFueXdoZXJlIAo+IGZyb20KPiAtCSAqIHByZV9lbmFibGUoKSB1cCB0byBzZW1pLWF1 dG8gbGluayB0cmFpbmluZyBpbml0aWF0aW9uIGJlbG93Lgo+ICsJICogVGhlIHRpbWluZyBkaWFn cmFtIG9mIHNvbWUgZURQIHBhbmVscyBzYXlzIHRoYXQgeW91J3JlIHN1cHBvc2VkIHRvCj4gKwkg KiB3YWl0IGZvciBIUEQgdG8gYmUgYXNzZXJ0ZWQgYmVmb3JlIHRoZSBhdXggY2hhbm5lbCBpcyBv cGVyYXRpb25hbC4KPiAgCSAqCj4gLQkgKiBOZWl0aGVyIHRoZSBkYXRhc2hlZXQgZm9yIHRoZSBi cmlkZ2Ugbm9yIHRoZSBwYW5lbCB0ZXN0ZWQgbWVudGlvbiAKPiBhCj4gLQkgKiBkZWxheSBvZiB0 aGlzIG1hZ25pdHVkZSBpbiB0aGUgdGltaW5nIHJlcXVpcmVtZW50cy4gU28gZm9yIG5vdywgCj4g YWRkCj4gLQkgKiB0aGUgbXlzdGVyeSBkZWxheSB1bnRpbCBzb21lb25lIGZpZ3VyZXMgb3V0IGEg YmV0dGVyIGZpeC4KPiArCSAqIFdoaWxlIHdlIGNvdWxkIGNvbmZpZ3VyZSB0aGUgYnJpZGdlIHRv IHJlcG9ydCB0aGUgSFBEIHNpZ25hbCB0byB1cwo+ICsJICogYW5kIGFkZCBhIGRlbGF5IGhlcmUg dW50aWwgdGhlIEhQRCBpcyBhc3NlcnRlZCwgaXQgdHVybnMgb3V0IAo+IHRoYXQncwo+ICsJICog c2xvd2VyIHRoYW4ganVzdCBoYXJkY29kaW5nIHRoZSBtYXggZGVsYXkgZnJvbSB0aGUgcGFuZWwg aW4gc29tZQo+ICsJICogY2FzZXMuICBXaHk/Cj4gKwkgKgo+ICsJICogVGhlIHNuNjVkc2k4NiBk YXRhc2hlZXQgc2F5cyB0aGF0IGl0IG9ubHkgcmVwb3J0cyB0aGUgZGVib3VuY2VkCj4gKwkgKiBI UEQgc2lnbmFsIHRvIHNvZnR3YXJlLiAgSXQgd2lsbCB0ZWxsIHNvZnR3YXJlIGFib3V0IEhQRCBh c3NlcnRpb24KPiArCSAqIGFzIHF1aWNrbHkgYXMgMTAwIG1zIGFmdGVyIGl0J3MgYXNzZXJ0ZWQs IGJ1dCBzb21ldGltZXMgaXQgbWlnaHQKPiArCSAqIHRha2UgNDAwIG1zIGJlY2F1c2UgaXQncyB0 aW1lZCB3aXRoIGEgdmVyeSBpbmFjY3VyYXRlIHJpbmcKPiArCSAqIG9zY2lsbGF0b3IuICBJbiBw cmFjdGljZSBpdCB3YXMgbWVhc3VyZWQgYXQgMjAwIG1zIG9uIGF0IGxlYXN0Cj4gKwkgKiBvbmUg c3lzdGVtLgo+ICsJICoKPiArCSAqIE9uIGEgcGFydGljdWxhciBwYW5lbCwgSFBEIHdhcyBhc3Nl cnRlZCA4NCBtcyBhZnRlciBwb3dlciB3YXMgCj4gZ2l2ZW4uCj4gKwkgKiBUaGlzIHNhbWUgcGFu ZWwgc3BlY2lmaWVkIHRoYXQgSFBEIHdvdWxkIGFsd2F5cyBiZSBhc3NlcnRlZCB3aXRoaW4KPiAr CSAqIDIwMCBtcyBvZiBhcHBseWluZyBwb3dlci4gIFRodXMgb24gdGhpcyBwYW5lbCB3aXRoIHRo ZSBtZWFzdXJlZAo+ICsJICogODQgbXMgdG8gYXNzZXJ0IEhQRCArIHRoZSAyMDAgbXMgbWVhc3Vy ZWQgZGVib3VuY2Ugd2UnZCB3YWl0IDI4NCAKPiBtcwo+ICsJICogd2hpY2ggaXMgODQgbXMgbG9u Z2VyIHRoYW4ganVzdCBoYXJkY29kaW5nIHRoZSBzbGVlcC4KPiArCSAqCj4gKwkgKiBGb3Igbm93 IHdlIGRvbid0IGtub3cgb2YgYW55IGNhc2VzIHdoZXJlIHBheWluZyBhdHRlbnRpb24gdG8gSFBE Cj4gKwkgKiBpcyBiZXR0ZXIgdGhhbiBoYXJkY29kaW5nIHRoZSB2YWx1ZS4gIFRodXMgZm9yIG5v dyBvbmx5IHN1cHBvcnQgCj4gdGhlCj4gKwkgKiBoYXJkY29kZWQgZGVsYXkgYW5kIHByaW50IGEg d2FybmluZyBpZiBpdCB3YXNuJ3Qgc3BlY2lmaWVkLiAgTGF0ZXIKPiArCSAqIG9uZSBjb3VsZCBp bWFnaW5lIGltcHJvdmluZyB0aGUgZHJpdmVyIHRvIGVuYWJsZSBIUEQgc3VwcG9ydCBpZgo+ICsJ ICogcGFuZWwtaHBkLWRlbGF5LW1zIHdhc24ndCBzcGVjaWZpZWQgaW4gdGhlIGRldmljZSB0cmVl Lgo+ICAJICovCj4gLQltc2xlZXAoNzApOwo+ICsJaWYgKHBkYXRhLT5wYW5lbF9ocGRfZGVsYXlf bXMgPj0gMCkKCklzIFplcm8gYSB2YWxpZCBvcHRpb24gaGVyZSwgbXNsZWVwKDApID8KCgo+ICsJ CW1zbGVlcChwZGF0YS0+cGFuZWxfaHBkX2RlbGF5X21zKTsKPiArCWVsc2UKPiArCQlEUk1fV0FS TigiSFBEIG5vdCBzdXBwb3J0ZWQ7IGNvbnNpZGVyIGEgaGFyZGNvZGVkIGRlbGF5XG4iKTsKPiAK PiAgCS8qIERTSV9BIGxhbmUgY29uZmlnICovCj4gIAl2YWwgPSBDSEFfRFNJX0xBTkVTKDQgLSBw ZGF0YS0+ZHNpLT5sYW5lcyk7Cj4gQEAgLTY1Niw2ICs2NzgsNyBAQCBzdGF0aWMgaW50IHRpX3Nu X2JyaWRnZV9wcm9iZShzdHJ1Y3QgaTJjX2NsaWVudCAKPiAqY2xpZW50LAo+ICB7Cj4gIAlzdHJ1 Y3QgdGlfc25fYnJpZGdlICpwZGF0YTsKPiAgCWludCByZXQ7Cj4gKwl1MzIgdmFsOwo+IAo+ICAJ aWYgKCFpMmNfY2hlY2tfZnVuY3Rpb25hbGl0eShjbGllbnQtPmFkYXB0ZXIsIEkyQ19GVU5DX0ky QykpIHsKPiAgCQlEUk1fRVJST1IoImRldmljZSBkb2Vzbid0IHN1cHBvcnQgSTJDXG4iKTsKPiBA QCAtNzEyLDYgKzczNSwxMiBAQCBzdGF0aWMgaW50IHRpX3NuX2JyaWRnZV9wcm9iZShzdHJ1Y3Qg aTJjX2NsaWVudCAKPiAqY2xpZW50LAo+ICAJaWYgKHJldCkKPiAgCQlyZXR1cm4gcmV0Owo+IAo+ ICsJaWYgKCFvZl9wcm9wZXJ0eV9yZWFkX3UzMihwZGF0YS0+ZGV2LT5vZl9ub2RlLAo+ICsJCQkJ ICAidGkscGFuZWwtaHBkLWRlbGF5LW1zIiwgJnZhbCkpCj4gKwkJcGRhdGEtPnBhbmVsX2hwZF9k ZWxheV9tcyA9IHZhbDsKPiArCWVsc2UKPiArCQlwZGF0YS0+cGFuZWxfaHBkX2RlbGF5X21zID0g LTE7CgpTYW1lIGNvbW1lbnQgYXMgYWJvdmUuCj4gKwo+ICAJcG1fcnVudGltZV9lbmFibGUocGRh dGEtPmRldik7Cj4gCj4gIAlpMmNfc2V0X2NsaWVudGRhdGEoY2xpZW50LCBwZGF0YSk7Cl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWls aW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZy ZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.5 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91C13ECDE46 for ; Wed, 24 Oct 2018 18:32:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3AB4D2082E for ; Wed, 24 Oct 2018 18:32:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="kY2XwqVm"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="kr8QgGnr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3AB4D2082E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726964AbeJYDB6 (ORCPT ); Wed, 24 Oct 2018 23:01:58 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:37548 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726521AbeJYDB6 (ORCPT ); Wed, 24 Oct 2018 23:01:58 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 1F18F60C1B; Wed, 24 Oct 2018 18:32:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1540405969; bh=r6fIr463GEoNFeFvkNBPZR8bR9memTwKtKrXmoWTUIo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kY2XwqVmTl/sBxBoBhOuRNmwLJFHqev/6tsrC85EKHfeoA4sNmmXk0P1WwM6kUHku veXoJZEK4CjR/UG/clQEMrsPvPM5C6XqBqf6SimFbbHJbftG8pbLmKBGMQKlqBenK1 aZvh+9OjrBRG3sSHFtvPJ6pHyiFoEVeuIUUFiVHs= Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id D9C7360C1B; Wed, 24 Oct 2018 18:32:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1540405967; bh=r6fIr463GEoNFeFvkNBPZR8bR9memTwKtKrXmoWTUIo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kr8QgGnrpQv4NKCDgX+4s9dDPFbPZWvmsPeQcb0X6xzlHXhkk3oN+XkMYrS2PYeqo Cq9JfIR+79fKZmdtTbKZ7Ol/9II7P5eLJj211a218WJBEJvjcXk5dnmS1i5U6aBprP R6OigEb3s9qKeMkuuVgt86SVKcaQYyKOGDee/9B4= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 25 Oct 2018 00:02:47 +0530 From: spanda@codeaurora.org To: Douglas Anderson Cc: Sean Paul , linux-arm-msm@vger.kernel.org, jsanka@codeaurora.org, ryandcase@chromium.org, Andrzej Hajda , Archit Taneja , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, David Airlie , Laurent Pinchart Subject: Re: [PATCH 2/2] drm/bridge: ti-sn65dsi86: Allow DT to set "HPD delay" In-Reply-To: <20181019201940.138179-2-dianders@chromium.org> References: <20181019201940.138179-1-dianders@chromium.org> <20181019201940.138179-2-dianders@chromium.org> Message-ID: <9d5b42b94772fb3adb86e20eff72cd88@codeaurora.org> X-Sender: spanda@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-10-20 01:49, Douglas Anderson wrote: > Let's solve the mystery of commit bf1178c98930 ("drm/bridge: > ti-sn65dsi86: Add mystery delay to enable()"). Specifically the > reason we needed that mystery delay is that we weren't paying > attention to HPD. > > Looking at the datasheet for the same panel that was tested for the > original commit, I see there's a timing "t3" that times from power on > to the aux channel being operational. This time is specced as 0 - 200 > ms. The datasheet says that the aux channel is operational at exactly > the same time that HPD is asserted. > > Scoping the signals on this board showed that HPD was asserted 84 ms > after power was asserted. That very closely matches the magic 70 ms > delay that we had. ...and actually, in my esting the 70 ms wasn't > quite enough of a delay and some percentage of the time the display > didn't come up until I bumped it to 100 ms. > > To solve this, we tried to hook up the HPD signal in the bridge. > ...but in doing so we found that that the bridge didn't report that > HPD was asserted until ~280 ms after we powered it (!). This is > explained by looking at the sn65dsi86 datasheet section "8.4.5.1 HPD > (Hot Plug/Unplug Detection)". Reading there we see that the bridge > isn't even intended to report HPD until 100 ms after it's asserted. > ...but that would have left us at 184 ms. The extra 100 ms > (presumably) comes from this part in the datasheet: > >> The HPD state machine operates off an internal ring oscillator. The >> ring oscillator frequency will vary [ ... ]. The min/max range in >> the HPD State Diagram refers to the possible times based off >> variation in the ring oscillator frequency. > > Given that the 280 ms we'll end up delaying if we hook up HPD is > _slower_ than the 200 ms we could just hardcode, for now we'll solve > the problem by just allowing boards to hardcode a value. If someone > using this part finds that they can get things to work more quickly by > actually hooking up HPD that can always be a future patch. > > One last note is that I tried to solve this through another way: In > ti_sn_bridge_enable() I tried to use various combinations of > dp_dpcd_writeb() and dp_dpcd_readb() to detect when the aux channel > was up. In theory that would let me detect _exactly_ when I could > continue and do link training. Unfortunately even if I did an aux > transfer w/out waiting I couldn't see any errors. Possibly I could > keep looping over link training until it came back with success, but > that seemed a little overly hacky to me. > Thanks for very detailed explanation. > Signed-off-by: Douglas Anderson > --- > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 45 ++++++++++++++++++++++----- > 1 file changed, 37 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > index f8a931cf3665..5deed667480c 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > @@ -93,6 +93,7 @@ struct ti_sn_bridge { > struct clk *refclk; > struct drm_panel *panel; > struct gpio_desc *enable_gpio; > + int panel_hpd_delay_ms; > struct regulator_bulk_data supplies[SN_REGULATOR_SUPPLY_NUM]; > }; > > @@ -459,16 +460,37 @@ static void ti_sn_bridge_enable(struct drm_bridge > *bridge) > int ret; > > /* > - * FIXME: > - * This 70ms was found necessary by experimentation. If it's not > - * present, link training fails. It seems like it can go anywhere > from > - * pre_enable() up to semi-auto link training initiation below. > + * The timing diagram of some eDP panels says that you're supposed to > + * wait for HPD to be asserted before the aux channel is operational. > * > - * Neither the datasheet for the bridge nor the panel tested mention > a > - * delay of this magnitude in the timing requirements. So for now, > add > - * the mystery delay until someone figures out a better fix. > + * While we could configure the bridge to report the HPD signal to us > + * and add a delay here until the HPD is asserted, it turns out > that's > + * slower than just hardcoding the max delay from the panel in some > + * cases. Why? > + * > + * The sn65dsi86 datasheet says that it only reports the debounced > + * HPD signal to software. It will tell software about HPD assertion > + * as quickly as 100 ms after it's asserted, but sometimes it might > + * take 400 ms because it's timed with a very inaccurate ring > + * oscillator. In practice it was measured at 200 ms on at least > + * one system. > + * > + * On a particular panel, HPD was asserted 84 ms after power was > given. > + * This same panel specified that HPD would always be asserted within > + * 200 ms of applying power. Thus on this panel with the measured > + * 84 ms to assert HPD + the 200 ms measured debounce we'd wait 284 > ms > + * which is 84 ms longer than just hardcoding the sleep. > + * > + * For now we don't know of any cases where paying attention to HPD > + * is better than hardcoding the value. Thus for now only support > the > + * hardcoded delay and print a warning if it wasn't specified. Later > + * one could imagine improving the driver to enable HPD support if > + * panel-hpd-delay-ms wasn't specified in the device tree. > */ > - msleep(70); > + if (pdata->panel_hpd_delay_ms >= 0) Is Zero a valid option here, msleep(0) ? > + msleep(pdata->panel_hpd_delay_ms); > + else > + DRM_WARN("HPD not supported; consider a hardcoded delay\n"); > > /* DSI_A lane config */ > val = CHA_DSI_LANES(4 - pdata->dsi->lanes); > @@ -656,6 +678,7 @@ static int ti_sn_bridge_probe(struct i2c_client > *client, > { > struct ti_sn_bridge *pdata; > int ret; > + u32 val; > > if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) { > DRM_ERROR("device doesn't support I2C\n"); > @@ -712,6 +735,12 @@ static int ti_sn_bridge_probe(struct i2c_client > *client, > if (ret) > return ret; > > + if (!of_property_read_u32(pdata->dev->of_node, > + "ti,panel-hpd-delay-ms", &val)) > + pdata->panel_hpd_delay_ms = val; > + else > + pdata->panel_hpd_delay_ms = -1; Same comment as above. > + > pm_runtime_enable(pdata->dev); > > i2c_set_clientdata(client, pdata);