Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752618AbbH0FYl (ORCPT ); Thu, 27 Aug 2015 01:24:41 -0400 Received: from mga01.intel.com ([192.55.52.88]:56533 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751612AbbH0FYk (ORCPT ); Thu, 27 Aug 2015 01:24:40 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,421,1437462000"; d="scan'208";a="549345213" Message-ID: <55DE9F03.7090603@intel.com> Date: Thu, 27 Aug 2015 10:54:19 +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 CC: =?UTF-8?B?U3TDqXBoYW5lIE1hcmNoZXNpbg==?= , 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> <55DDAC84.7060105@intel.com> <20150826142914.GA17672@mail.corp.redhat.com> In-Reply-To: <20150826142914.GA17672@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: 5440 Lines: 124 On 8/26/2015 7:59 PM, Benjamin Tissoires wrote: > 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 Thanks for the info :). There is no way in code to confirm if after link training display is working properly (other than short pulse for link related issues) so this has to be on a case by case basis. i would recommend if you plan to upstream it to restrict the changes for chromebook Pixel 2 alone. >> -- >> regards, >> Sivakumar >> -- 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/