Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756760AbbHZMJr (ORCPT ); Wed, 26 Aug 2015 08:09:47 -0400 Received: from mga01.intel.com ([192.55.52.88]:17038 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751887AbbHZMJp (ORCPT ); Wed, 26 Aug 2015 08:09:45 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,415,1437462000"; d="scan'208";a="548841186" Message-ID: <55DDAC84.7060105@intel.com> Date: Wed, 26 Aug 2015 17:39:40 +0530 From: Sivakumar Thulasimani User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Benjamin Tissoires , =?UTF-8?B?U3TDqXBo?= =?UTF-8?B?YW5lIE1hcmNoZXNpbg==?= CC: 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 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> In-Reply-To: <20150817200653.GB14631@mail.corp.redhat.com> 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 Content-Length: 3885 Lines: 93 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, All Intel platforms (at-least those i inquired about) handle lane reversal in HW. 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 ? -- regards, Sivakumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/