Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1213774
| From | Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP |
| Date | 2015-08-26 14:10 +0200 |
| Message-ID | <q1HGG-5gu-23@gated-at.bofh.it> (permalink) |
| References | (3 earlier) <pRBsU-3BG-45@gated-at.bofh.it> <pRNu1-44v-7@gated-at.bofh.it> <pUcHD-2rB-13@gated-at.bofh.it> <pXwA9-8kZ-1@gated-at.bofh.it> <pYyTf-Mb-17@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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@redhat.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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> - 2015-08-26 14:10 +0200
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP Benjamin Tissoires <benjamin.tissoires@redhat.com> - 2015-08-26 16:30 +0200
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> - 2015-08-27 07:30 +0200
csiph-web