From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Tissoires Subject: Re: [PATCH 3/3] drm/i915: Support DDI lane reversal for DP Date: Wed, 26 Aug 2015 10:29:14 -0400 Message-ID: <20150826142914.GA17672@mail.corp.redhat.com> References: <1438099409-25456-1-git-send-email-benjamin.tissoires@redhat.com> <1438099409-25456-4-git-send-email-benjamin.tissoires@redhat.com> <55B88E25.6000006@intel.com> <20150729152240.GD2743@mail.corp.redhat.com> <55B9A471.2070107@intel.com> <20150805193427.GA6097@mail.corp.redhat.com> <20150817200653.GB14631@mail.corp.redhat.com> <55DDAC84.7060105@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by gabe.freedesktop.org (Postfix) with ESMTPS id DAFA97A124 for ; Wed, 26 Aug 2015 07:29:17 -0700 (PDT) Content-Disposition: inline In-Reply-To: <55DDAC84.7060105@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Sivakumar Thulasimani Cc: intel-gfx , Todd Broch , linux-kernel@vger.kernel.org, Daniel Vetter List-Id: intel-gfx@lists.freedesktop.org T24gQXVnIDI2IDIwMTUgb3IgdGhlcmVhYm91dHMsIFNpdmFrdW1hciBUaHVsYXNpbWFuaSB3cm90 ZToKPiAKPiAKPiBPbiA4LzE4LzIwMTUgMTozNiBBTSwgQmVuamFtaW4gVGlzc29pcmVzIHdyb3Rl Ogo+ID5PbiBBdWcgMTQgMjAxNSBvciB0aGVyZWFib3V0cywgU3TDqXBoYW5lIE1hcmNoZXNpbiB3 cm90ZToKPiA+Pk9uIFdlZCwgQXVnIDUsIDIwMTUgYXQgMTI6MzQgUE0sIEJlbmphbWluIFRpc3Nv aXJlcwo+ID4+PGJlbmphbWluLnRpc3NvaXJlc0ByZWRoYXQuY29tPiB3cm90ZToKPiA+Pj5PbiBK dWwgMzAgMjAxNSBvciB0aGVyZWFib3V0cywgU2l2YWt1bWFyIFRodWxhc2ltYW5pIHdyb3RlOgo+ ID4+Pj4KPiA+Pj4+T24gNy8yOS8yMDE1IDg6NTIgUE0sIEJlbmphbWluIFRpc3NvaXJlcyB3cm90 ZToKPiA+Pj4+Pk9uIEp1bCAyOSAyMDE1IG9yIHRoZXJlYWJvdXRzLCBTaXZha3VtYXIgVGh1bGFz aW1hbmkgd3JvdGU6Cj4gPj4+Pj4+d2h5IG5vdCBkZXRlY3QgcmV2ZXJzZSBpbiBpbnRlbF9kcF9k ZXRlY3QvaW50ZWxfaHBkX3B1bHNlID8gdGhhdCB3YXkgeW91IGNhbgo+ID4+Pj4+PmlkZW50aWZ5 IGJvdGggbGFuZSBjb3VudCBhbmQgcmV2ZXJzYWwgc3RhdGUgd2l0aG91dCB0b3VjaGluZyBhbnl0 aGluZyBpbiB0aGUKPiA+Pj4+Pj5saW5rIHRyYWluaW5nIGNvZGUuIGkgYW0geWV0IHRvIHVwc3Ry ZWFtIG15IGNoYW5nZXMgZm9yIENIVCB0aGF0IGkgY2FuIHNoYXJlCj4gPj4+Pj4+aWYgcmVxdWly ZWQgdGhhdCBkb2VzIHRoZSBzYW1lIGluIGludGVsX2RwX2RldGVjdCB3aXRob3V0IHRvdWNoaW5n IGFueSBsaW5lCj4gPj4+Pj4+aW4gbGluayB0cmFpbmluZyBwYXRoLgo+ID4+Pj4+V2l0aCBteSBj dXJyZW50IGxpbWl0ZWQga25vd2xlZGdlIG9mIHRoZSBkcCBob3RwbHVnIChhbmQgaTkxNSBkcml2 ZXIpIEkKPiA+Pj4+PmFtIG5vdCBzdXJlIHdlIGNvdWxkIGRldGVjdCB0aGUgcmV2ZXJzZWQgc3Rh dGUgd2l0aG91dCB0cnlpbmcgdG8gdHJhaW4gMQo+ID4+Pj4+bGFuZSBvbmx5LiBJJ2QgYmUgZ2xh ZCB0byBsb29rIGF0IHlvdXIgY2hhbmdlcyBhbmQgdGVzdCB0aGVtIG9uIG15Cj4gPj4+Pj5zeXN0 ZW0gaWYgeW91IHRoaW5rIHRoYXQgY291bGQgaGVscCBoYXZpbmcgYSBjbGVhbmVyIHNvbHV0aW9u Lgo+ID4+Pj4+Cj4gPj4+Pj5DaGVlcnMsCj4gPj4+Pj5CZW5qYW1pbgo+ID4+Pj5Obywgd2hhdCBp IHJlY29tbWVuZGVkIHdhcyB0byBkbyBsaW5rIHRyYWluaW5nIGJ1dCBpbiBpbnRlbF9kcF9kZXRl Y3QuIFNpbmNlCj4gPj4+PlVTQiBUeXBlIEMgY2FibGUKPiA+Pj4+YWxzbyBoYXMgaXRzIG93biBs YW5lIGNvdW50IHJlc3RyaWN0aW9uIChpdCBjYW4gaGF2ZSBkaWZmZXJlbnQgbGFuZSBjb3VudAo+ ID4+Pj50aGFuIHRoZSBvbmUgc3VwcG9ydGVkCj4gPj4+PmJ5IHBhbmVsKSB5b3UgbWlnaHQgaGF2 ZSB0byBmaWd1cmUgdGhhdCBvdXQgYXMgd2VsbC4gc28gYm90aCByZXZlcnNhbCBhbmQKPiA+Pj4+ bGFuZSBjb3VudCBkZXRlY3Rpb24KPiA+Pj4+Y2FuIGJlIGRvbmUgb3V0c2lkZSB0aGUgbW9kZXNl dCBwYXRoIGFuZCBrZWVwIHRoZSBjb2RlIGZyZWUgb2YgdHlwZSBDCj4gPj4+PmNoYW5nZXMgb3V0 c2lkZQo+ID4+Pj5kZXRlY3Rpb24gcGF0aC4KPiA+Pj4+Cj4gPj4+PlBsZWFzZSBmaW5kIGJlbG93 IHRoZSBjb2RlIHRvIGRvIHRoZSBzYW1lLiBEbyBub3Qgd2FzdGUgdGltZSB0cnlpbmcgdG8gYXBw bHkKPiA+Pj4+dGhpcyBkaXJlY3RseSBvbgo+ID4+Pj5uaWdodGx5IHNpbmNlIHRoaXMgaXMgYmFz ZWQgb24gYSBsb2NhbCB0cmVlIGFuZCBiZWNhdXNlIHRoaXMgaXMgcHJlLSBhdG9taWMKPiA+Pj4+ Y2hhbmdlcyBjb2RlLCBzbyB5b3UKPiA+Pj4+bWlnaHQgaGF2ZSB0byBtb2RpZnkgY2h2X3VwZnJv bnRfbGlua190cmFpbiB0byB3b3JrIG9uIHRvcCBvZiB0aGUgbGF0ZXN0Cj4gPj4+Pm5pZ2h0bHkg Y29kZS4gd2UKPiA+Pj4+YXJlIHN1cHBvc2VkIHRvIHVwc3RyZWFtIHRoaXMgYW5kIGlzIGluIG15 IHRvZG8gbGlzdC4KPiA+Pj4+Cj4gPj4+W29yaWdpbmFsIHBhdGNoIHNuaXBwZWQuLi5dCj4gPj4+ Cj4gPj4+SGkgU2l2YWt1bWFyLAo+ID4+Pgo+ID4+PlNvIEkgbWFuYWdlZCB0byBtYW51YWxseSBy ZS1hcHBseSB5b3VyIHBhdGNoIG9uIHRvcCBvZgo+ID4+PmRybS1pbnRlbC1uaWdodGx5LCBhbmQg dHJpZWQgdG8gcG9ydCBpdCB0byBtYWtlIEJyb2Fkd2VsbCB3b3JraW5nIHRvby4KPiA+Pj5JdCB3 b3JrcyBPSyBpZiB0aGUgc3lzdGVtIGlzIGFscmVhZHkgYm9vdCB3aXRob3V0IGFueSBleHRlcm5h bCBEUCB1c2VkLgo+ID4+PkluIHRoaXMgY2FzZSwgdGhlIGRldGVjdGlvbiB3b3JrcyBhbmQgSSBj YW4gc2VlIG15IGV4dGVybmFsIG1vbml0b3IKPiA+Pj53b3JraW5nIHByb3Blcmx5Lgo+ID4+Pgo+ ID4+Pkhvd2V2ZXIsIGlmIHRoZSBtb25pdG9yIGlzIGNvbGQgcGx1Z2dlZCwgdGhlIGNwdS9HUFUg aGFuZ3MgYW5kIEkgY2FuIG5vdAo+ID4+PnVuZGVyc3RhbmQgd2h5LiBJIHRoaW5rIEkgZW5hYmxl ZCBhbGwgdGhhdCBpcyBtZW50aW9uZWQgaW4gdGhlIFBSTSB0byBiZQo+ID4+PmFibGUgdG8gdHJh aW4gdGhlIERQIGxpbmssIGJ1dCBJIGFtIG9idmlvdXNseSBtaXNzaW5nIHNvbWV0aGluZyBlbHNl Lgo+ID4+PkNhbiB5b3UgaGF2ZSBhIGxvb2s/Cj4gPj4+Cj4gPj5IaSBCZW5qYW1pbiwKPiA+Pgo+ ID4+SSB3b3VsZCByZWNvbW1lbmQgYWdhaW5zdCB0aGlzIGFwcHJvYWNoLiBTb21lIGFkYXB0ZXJz IHdpbGwgY2xhaW0gdGhhdAo+ID4+dGhleSByZWNvdmVyZWQgYSBjbG9jayBldmVuIHdoZW4gaXQg aXNuJ3Qgb24gdGhlIGxhbmVzIHlvdSBlbmFibGVkLAo+ID4+d2hpY2ggbWVhbnMgdGhhdCB0aGUg cmV2ZXJzYWwgZGV0ZWN0aW9uIGRvZXNuJ3QgYWx3YXlzIHdvcmsuIFRoZSBvbmx5Cj4gPj5yZWxp YWJsZSB3YXkgdG8gZG8gdGhpcyBpcyB0byBnbyB0YWxrIHRvIHRoZSBDaHJvbWUgT1MgRUMgKHlv dSBjYW4KPiA+PmZpbmQgdGhlc2UgcGF0Y2hlcyBsYXRlciBpbiB0aGUgQ2hyb21lIE9TIHRyZWUp LiBJdCdzIG5vdCBhcyBnZW5lcmljLAo+ID4+YnV0IHdlIG1pZ2h0IGJlIGFibGUgdG8gYWJzdHJh Y3QgdGhhdCBsb2dpYywgbWF5YmUuCj4gPj4KPiA+SGkgU3TDqXBoYW5lLAo+ID4KPiA+VGhpcyBp cyBhIHZlcnkgZ29vZCBuZXdzLiBJIHdhcyBhZnJhaWQgd2Ugd291bGQgbm90IGhhdmUgYWNjZXNz IHRvIHRoZQo+ID5oYXJkd2FyZSBjb250cm9sbGVyIGJlY2F1c2UgdGhlIEludGVsIGNvbnRyb2xs ZXIgaHViIHNwZWMgd2FzIG5vdAo+ID5wdWJsaWMuCj4gPgo+ID5JIHdpbGwgdHJ5IHRvIGhhdmUg YSBsb29rIGF0IGl0LCBidXQgdGhlIGxhdGVzdCBjaHJvbWVvcyBicmFuY2ggKDMuMTgpCj4gPnNl ZW1zIHRvIGRpZmZlciBxdWl0ZSBhIGxvdCBmcm9tIHRoZSB1cHN0cmVhbSBvbmUuIEFueXdheSwg ZmluZ2Vycwo+ID5jcm9zc2VkLgo+ID4KPiA+Q2hlZXJzLAo+ID5CZW5qYW1pbgo+IEhpIEJlbmph bWluL1N0w6lwaGFuLAoKSGkgU2l2YWt1bWFyLAoKPiAgICAgQWxsIEludGVsIHBsYXRmb3JtcyAo YXQtbGVhc3QgdGhvc2UgaSBpbnF1aXJlZCBhYm91dCkgaGFuZGxlIGxhbmUKPiByZXZlcnNhbCBp biBIVy4KClRoYXQgaXMgdGhlIHRoZW9yeSBhbmQgd2hhdCBpcyB3cml0dGVuIGluIHRoZSBVU0Ig VHlwZSBDIHNwZWMgSUlSQy4KUHJvYmxlbSBpcywgdGhlIENocm9tZWJvb2sgUGl4ZWwgMiBleHRl cm5hbCBkaXNwbGF5IGRvZXMgbm90IHdvcmsgd2hlbiBhClVTQiBUeXBlLUMgYWRhcHRlciBpcyBp biB0aGUgcmV2ZXJzZWQgcG9zaXRpb24gKG9yIGJlbGlldmUgbWUsIEkgd291bGQKZGVmaW5pdGl2 ZWx5IG5vdCBoYXZlIHN1Ym1pdHRlZCBhIHBhdGNoIGZvciB0aGUgYmVhdXR5IG9mIGl0KS4KRXZl cnl0aGluZyBlbHNlIHdvcmtzIChsaW5rIHRyYWluaW5nIHdoZW4gNCBsYW5lcyBhcmUgYWN0aXZh dGVkLCBvcgpvdGhlciBjb21tdW5pY2F0aW9uIGNoYW5uZWxzKS4gT25seSB0aGUgb3JkZXIgb2Yg dGhlIDQgZGF0YSBsYW5lcwptYXR0ZXJzIGluIHRoaXMgc2l0dWF0aW9uIGFuZCB0aGUgVVNCIGNv bnRyb2xsZXIgZG9lcyBub3QgcmV2ZXJzZSB0aGVtCmZvciB1cyBvbiB0aGlzIGxhcHRvcC4KCj4g eW91ciBzdGF0ZW1lbnQgdGhhdCBsaW5rIHRyYWluaW5nIHdpbGwgcGFzcyBldmVuIG9uIHJldmVy c2VkIGxhbmUgc2VlbXMgdG8KPiBwb2ludAo+IHRvIHRoZSBzYW1lIGZhY3QuIGluIHN1Y2ggYSBz Y2VuYXJpbyB3aHkgc2hvdWxkIHRoZSBlbmNvZGVyL2Nvbm5lY3RvciBjYXJlCj4gaWYgdGhlIGxh bmUgaXMgcmV2ZXJzZWQgb3Igbm90ID8KClByb2JsZW0gaXMgdGhhdCBTdGVwaGFuZSBzYWlkIHNv bWUgYWRhcHRlcnMgYXJlIGx5aW5nIHJlZ2FyZGluZyB0aGUKY2xvY2sgcmVjb3ZlcnkuIFRoZXkg Y2xhaW0gZXZlcnl0aGluZyBpcyBmaW5lIHdoaWxlIGluIHRoZSBlbmQsIHRoZQpkaXNwbGF5IGRv ZXNuJ3Qgc2hvdyBhbnl0aGluZyBiZWNhdXNlIHRoZSBsYW5lcyBhcmUgcmV2ZXJzZWQuIElmIHRo aXMgaXMKanVzdCBhIGNocm9tZWJvb2sgUGl4ZWwgMiBpc3N1ZSwgdGhhdCdzIGJldHRlciB0aGVu LiBJIHdvbid0IGhhdmUgdG8gdHJ5CnRvIHB1dCBzb21lIGdlbmVyaWMgaW50ZXJmYWNlIHRvIG5v dGlmeSB0aGF0IHRoZSBkaXNwbGF5IHBvcnQgbGFuZXMgaGF2ZQp0byBiZSByZXZlcnNlZC4KCkNo ZWVycywKQmVuamFtaW4KCj4gCj4gLS0gCj4gcmVnYXJkcywKPiBTaXZha3VtYXIKPiAKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4IG1haWxp bmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0cy5mcmVl ZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnRlbC1nZngK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756321AbbHZO3S (ORCPT ); Wed, 26 Aug 2015 10:29:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49472 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752378AbbHZO3R (ORCPT ); Wed, 26 Aug 2015 10:29:17 -0400 Date: Wed, 26 Aug 2015 10:29:14 -0400 From: Benjamin Tissoires To: Sivakumar Thulasimani Cc: =?utf-8?B?U3TDqXBoYW5l?= Marchesin , Daniel Vetter , intel-gfx , Todd Broch , linux-kernel@vger.kernel.org Subject: Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP Message-ID: <20150826142914.GA17672@mail.corp.redhat.com> References: <1438099409-25456-1-git-send-email-benjamin.tissoires@redhat.com> <1438099409-25456-4-git-send-email-benjamin.tissoires@redhat.com> <55B88E25.6000006@intel.com> <20150729152240.GD2743@mail.corp.redhat.com> <55B9A471.2070107@intel.com> <20150805193427.GA6097@mail.corp.redhat.com> <20150817200653.GB14631@mail.corp.redhat.com> <55DDAC84.7060105@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55DDAC84.7060105@intel.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Aug 26 2015 or thereabouts, Sivakumar Thulasimani wrote: > > > On 8/18/2015 1:36 AM, Benjamin Tissoires wrote: > >On Aug 14 2015 or thereabouts, Stéphane Marchesin wrote: > >>On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires > >> wrote: > >>>On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote: > >>>> > >>>>On 7/29/2015 8:52 PM, Benjamin Tissoires wrote: > >>>>>On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote: > >>>>>>why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can > >>>>>>identify both lane count and reversal state without touching anything in the > >>>>>>link training code. i am yet to upstream my changes for CHT that i can share > >>>>>>if required that does the same in intel_dp_detect without touching any line > >>>>>>in link training path. > >>>>>With my current limited knowledge of the dp hotplug (and i915 driver) I > >>>>>am not sure we could detect the reversed state without trying to train 1 > >>>>>lane only. I'd be glad to look at your changes and test them on my > >>>>>system if you think that could help having a cleaner solution. > >>>>> > >>>>>Cheers, > >>>>>Benjamin > >>>>No, what i recommended was to do link training but in intel_dp_detect. Since > >>>>USB Type C cable > >>>>also has its own lane count restriction (it can have different lane count > >>>>than the one supported > >>>>by panel) you might have to figure that out as well. so both reversal and > >>>>lane count detection > >>>>can be done outside the modeset path and keep the code free of type C > >>>>changes outside > >>>>detection path. > >>>> > >>>>Please find below the code to do the same. Do not waste time trying to apply > >>>>this directly on > >>>>nightly since this is based on a local tree and because this is pre- atomic > >>>>changes code, so you > >>>>might have to modify chv_upfront_link_train to work on top of the latest > >>>>nightly code. we > >>>>are supposed to upstream this and is in my todo list. > >>>> > >>>[original patch snipped...] > >>> > >>>Hi Sivakumar, > >>> > >>>So I managed to manually re-apply your patch on top of > >>>drm-intel-nightly, and tried to port it to make Broadwell working too. > >>>It works OK if the system is already boot without any external DP used. > >>>In this case, the detection works and I can see my external monitor > >>>working properly. > >>> > >>>However, if the monitor is cold plugged, the cpu/GPU hangs and I can not > >>>understand why. I think I enabled all that is mentioned in the PRM to be > >>>able to train the DP link, but I am obviously missing something else. > >>>Can you have a look? > >>> > >>Hi Benjamin, > >> > >>I would recommend against this approach. Some adapters will claim that > >>they recovered a clock even when it isn't on the lanes you enabled, > >>which means that the reversal detection doesn't always work. The only > >>reliable way to do this is to go talk to the Chrome OS EC (you can > >>find these patches later in the Chrome OS tree). It's not as generic, > >>but we might be able to abstract that logic, maybe. > >> > >Hi Stéphane, > > > >This is a very good news. I was afraid we would not have access to the > >hardware controller because the Intel controller hub spec was not > >public. > > > >I will try to have a look at it, but the latest chromeos branch (3.18) > >seems to differ quite a lot from the upstream one. Anyway, fingers > >crossed. > > > >Cheers, > >Benjamin > Hi Benjamin/Stéphan, Hi Sivakumar, > All Intel platforms (at-least those i inquired about) handle lane > reversal in HW. That is the theory and what is written in the USB Type C spec IIRC. Problem is, the Chromebook Pixel 2 external display does not work when a USB Type-C adapter is in the reversed position (or believe me, I would definitively not have submitted a patch for the beauty of it). Everything else works (link training when 4 lanes are activated, or other communication channels). Only the order of the 4 data lanes matters in this situation and the USB controller does not reverse them for us on this laptop. > your statement that link training will pass even on reversed lane seems to > point > to the same fact. in such a scenario why should the encoder/connector care > if the lane is reversed or not ? Problem is that Stephane said some adapters are lying regarding the clock recovery. They claim everything is fine while in the end, the display doesn't show anything because the lanes are reversed. If this is just a chromebook Pixel 2 issue, that's better then. I won't have to try to put some generic interface to notify that the display port lanes have to be reversed. Cheers, Benjamin > > -- > regards, > Sivakumar >