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

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

[Jani Nikula]

There are certain BDW high res eDP machines that regressed due to

commit 38aecea0ccbb909d635619cba22f1891e589b434
Author: Daniel Vetter <daniel.vetter@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.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 drivers/gpu/drm/i915/intel_dp.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9f67b724dc28..6eaefca0048d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -849,7 +849,12 @@ intel_dp_compute_config(struct intel_encoder *encoder,
 			bpp = dev_priv->vbt.edp_bpp;
 		}
 
-		if (dev_priv->vbt.edp_lanes) {
+		if (IS_BROADWELL(dev)) {
+			/* Yes, it's an ugly hack. */
+			min_lane_count = max_lane_count;
+			DRM_DEBUG_KMS("forcing lane count to max (%u) on BDW\n",
+				      min_lane_count);
+		} else if (dev_priv->vbt.edp_lanes) {
 			min_lane_count = min(dev_priv->vbt.edp_lanes,
 					     max_lane_count);
 			DRM_DEBUG_KMS("using min %u lanes per VBT\n",
-- 
1.9.1

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

[Rodrigo Vivi]

[-- Attachment #1.1: Type: text/plain, Size: 2685 bytes --]

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@gmail.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>


On Wed, May 14, 2014 at 6:02 AM, Jani Nikula <jani.nikula@intel.com> wrote:

> There are certain BDW high res eDP machines that regressed due to
>
> commit 38aecea0ccbb909d635619cba22f1891e589b434
> Author: Daniel Vetter <daniel.vetter@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.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 9f67b724dc28..6eaefca0048d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -849,7 +849,12 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>                         bpp = dev_priv->vbt.edp_bpp;
>                 }
>
> -               if (dev_priv->vbt.edp_lanes) {
> +               if (IS_BROADWELL(dev)) {
> +                       /* Yes, it's an ugly hack. */
> +                       min_lane_count = max_lane_count;
> +                       DRM_DEBUG_KMS("forcing lane count to max (%u) on
> BDW\n",
> +                                     min_lane_count);
> +               } else if (dev_priv->vbt.edp_lanes) {
>                         min_lane_count = min(dev_priv->vbt.edp_lanes,
>                                              max_lane_count);
>                         DRM_DEBUG_KMS("using min %u lanes per VBT\n",
> --
> 1.9.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br

[-- Attachment #1.2: Type: text/html, Size: 4030 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Jani Nikula]

On Wed, 14 May 2014, Rodrigo Vivi <rodrigo.vivi@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@gmail.com>
> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@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@intel.com> wrote:
>
>> There are certain BDW high res eDP machines that regressed due to
>>
>> commit 38aecea0ccbb909d635619cba22f1891e589b434
>> Author: Daniel Vetter <daniel.vetter@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.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711
>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>> ---
>>  drivers/gpu/drm/i915/intel_dp.c | 7 ++++++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index 9f67b724dc28..6eaefca0048d 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -849,7 +849,12 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>>                         bpp = dev_priv->vbt.edp_bpp;
>>                 }
>>
>> -               if (dev_priv->vbt.edp_lanes) {
>> +               if (IS_BROADWELL(dev)) {
>> +                       /* Yes, it's an ugly hack. */
>> +                       min_lane_count = max_lane_count;
>> +                       DRM_DEBUG_KMS("forcing lane count to max (%u) on
>> BDW\n",
>> +                                     min_lane_count);
>> +               } else if (dev_priv->vbt.edp_lanes) {
>>                         min_lane_count = min(dev_priv->vbt.edp_lanes,
>>                                              max_lane_count);
>>                         DRM_DEBUG_KMS("using min %u lanes per VBT\n",
>> --
>> 1.9.1
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>
>
>
> -- 
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [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@intel.com> wrote:
> On Wed, 14 May 2014, Rodrigo Vivi <rodrigo.vivi@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@gmail.com>
>> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@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@intel.com> wrote:
>>
>>> There are certain BDW high res eDP machines that regressed due to
>>>
>>> commit 38aecea0ccbb909d635619cba22f1891e589b434
>>> Author: Daniel Vetter <daniel.vetter@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.

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

[Dave Airlie]

On 14 July 2014 10:46, Dave Airlie <airlied@gmail.com> wrote:
> On 15 May 2014 18:58, Jani Nikula <jani.nikula@intel.com> wrote:
>> On Wed, 14 May 2014, Rodrigo Vivi <rodrigo.vivi@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@gmail.com>
>>> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@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@intel.com> wrote:
>>>
>>>> There are certain BDW high res eDP machines that regressed due to
>>>>
>>>> commit 38aecea0ccbb909d635619cba22f1891e589b434
>>>> Author: Daniel Vetter <daniel.vetter@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

Actually adding IS_HASWELL won't work since this problem is with a standard
DP port.

I'll send the reverts, though I've no idea if this another revert of a
revert etc.

Dave.