linux-kernel - Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <55DDAC84.7060105@intel.com>
Date:	Wed, 26 Aug 2015 17:39:40 +0530
From:	Sivakumar Thulasimani <sivakumar.thulasimani@...el.com>
To:	Benjamin Tissoires <benjamin.tissoires@...hat.com>,
	Stéphane Marchesin 
	<marcheu@...omium.org>
CC:	Daniel Vetter <daniel.vetter@...el.com>,
	intel-gfx <intel-gfx@...ts.freedesktop.org>,
	Todd Broch <tbroch@...omium.org>, linux-kernel@...r.kernel.org
Subject: Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for
 DP



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
>> <benjamin.tissoires@...hat.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/