[Intel-gfx] [PATCH] drm/i915/dp: force eDP lane count to max available lanes on BDW

[Dave Airlie]

On 15 May 2014 18:58, Jani Nikula <jani.nikula at intel.com> wrote:
> On Wed, 14 May 2014, Rodrigo Vivi <rodrigo.vivi at gmail.com> wrote:
>> We do have to continue the investigation on the link training side, but
>> since 76711 is a critical I'm completely in favor of this workaround for
>> now.
>>
>> I just tested and it worked very well here, so:
>>
>> Tested-by: Rodrigo Vivi <rodrigo.vivi at gmail.com>
>> Reviewed-by: Rodrigo Vivi <rodrigo.vivi at gmail.com>
>
> Pushed to -fixes, thanks for the review and testing.
>
> BR,
> Jani.
>
>>
>>
>> On Wed, May 14, 2014 at 6:02 AM, Jani Nikula <jani.nikula at intel.com> wrote:
>>
>>> There are certain BDW high res eDP machines that regressed due to
>>>
>>> commit 38aecea0ccbb909d635619cba22f1891e589b434
>>> Author: Daniel Vetter <daniel.vetter at ffwll.ch>
>>> Date:   Mon Mar 3 11:18:10 2014 +0100
>>>
>>>     drm/i915: reverse dp link param selection, prefer fast over wide again
>>>
>>> The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at
>>> 2.7 Gbps on the affected machines. Link training succeeded for both, but
>>> the screen remained blank with the former config. Further investigation
>>> showed that 4 lanes at 5.4 Gbps worked also.
>>>
>>> The root cause for the blank screen using 2 lanes remains unknown, but
>>> apparently the driver for a certain other operating system by default
>>> uses the max available lanes. Follow suit on Broadwell eDP, for at least
>>> until we figure out what is going on.

Uggh, okay this lane thing is such a pita,

On haswell the Lenovo dock in SST mode is broken by the original patch as well.

I'm not sure we want to do IS_HASWELL here as well,

I think we need to revert 38aecea0ccbb909d635619cba22f1891e589b434

Dave.