[LUCID SRU] request pull i915: fix ironlake edp panel setup (v4)

Thu Aug 26 21:51:18 UTC 2010

On 08/26/2010 02:29 PM, Manoj Iyer wrote:
>
> Any idea when this SRU will be reviewed ?
>
>
> Cheers
> --- manjo
>
> On Wed, 11 Aug 2010, Manoj Iyer wrote:
>
>>
>> FYI: stable patch is on gkh queue, as per his email.
>>
>>
>> Cheers
>> --- manjo
>>
>> On Wed, 11 Aug 2010, Manoj Iyer wrote:
>>
>>>
>>> BUG
>>> ===
>>> http://launchpad.net/bugs/561802
>>>
>>> SRU JUSTIFICATION
>>> ================
>>> During installation, bootup (plymouth) and while inside X, screen remains
>>> blank. Switching VTs yields no results (screen remains blank). This patch
>>> is required to fix this issue.
>>>
>>> TESTING
>>> =======
>>> The patch was tested by James Ferguson @ canonical on E6510 and E6410 and
>>> reported to work. It does introduce any regressions on other systems I
>>> tested.
>>>
>>> PATCH
>>> =====
>>> The patch is not readily application from upstream to Lucid, it needs to
>>> be back ported. I have already submitted the patch to stable at kernel.org for
>>> stable inclusion 3.6.34.y.
>>>
>>> The following changes since commit
>>> f093f69b09ba908509e031d9578e92b2ce8d3582:
>>>    Adam Jackson (1):
>>>          drm/i915: Make G4X-style PLL search more permissive
>>>
>>> are available in the git repository at:
>>>
>>>
>>> git://kernel.ubuntu.com/git/manjo/ubuntu-lucid.git lp561802
>>>
>>> Dave Airlie (1):
>>>        i915: fix ironlake edp panel setup (v4)
>>>
>>>   drivers/gpu/drm/i915/intel_dp.c |   27 ++++++++++++++++++++++++---
>>>   1 files changed, 24 insertions(+), 3 deletions(-)
>>>
>>>  From 39d72c68727400af464103d209fe0dcba832b21f Mon Sep 17 00:00:00 2001
>>> From: Dave Airlie<airlied at redhat.com>
>>> Date: Wed, 30 Jun 2010 11:46:17 +1000
>>> Subject: [PATCH] i915: fix ironlake edp panel setup (v4)
>>>
>>> The eDP spec claims a 20% overhead for the 8:10 encoding scheme used
>>> on the wire. Take this into account when picking the lane/clock speed
>>> for the panel.
>>>
>>> v3: some panels are out of spec, try our best to deal with them, don't
>>> refuse modes on eDP panels, and try the largest allowed settings if
>>> all else fails on eDP.
>>> v4: fix stupid typo, forgot to git add before amending.
>>>
>>> Fixes several reports in bugzilla:
>>>
>>>        https://bugs.freedesktop.org/show_bug.cgi?id=28070
>>>
>>> Signed-off-by: Dave Airlie<airlied at redhat.com>
>>> Signed-off-by: Eric Anholt<eric at anholt.net>
>>> Signed-off-by: Manoj Iyer<manoj.iyer at canonical.com>
>>>
>>> Buglink: http://launchpad.net/bugs/561802
>>>
>>> This patch is backported from upstream patch SHAID:
>>> fe27d53e5c597ee5ba5d72a29d517091f244e974
>>> ---
>>>   drivers/gpu/drm/i915/intel_dp.c |   27 ++++++++++++++++++++++++---
>>>   1 files changed, 24 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>>> b/drivers/gpu/drm/i915/intel_dp.c
>>> index 6b62762..63ea21e 100644
>>> --- a/drivers/gpu/drm/i915/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>>> @@ -137,6 +137,12 @@ intel_dp_link_required(struct drm_device *dev,
>>>   }
>>>
>>>   static int
>>> +intel_dp_max_data_rate(int max_link_clock, int max_lanes)
>>> +{
>>> +	return (max_link_clock * max_lanes * 8) / 10;
>>> +}
>>> +
>>> +static int
>>>   intel_dp_mode_valid(struct drm_connector *connector,
>>>   		    struct drm_display_mode *mode)
>>>   {
>>> @@ -144,8 +150,11 @@ intel_dp_mode_valid(struct drm_connector *connector,
>>>   	int max_link_clock =
>>> intel_dp_link_clock(intel_dp_max_link_bw(intel_output));
>>>   	int max_lanes = intel_dp_max_lane_count(intel_output);
>>>
>>> -	if (intel_dp_link_required(connector->dev, intel_output, mode->clock)
>>> -			>  max_link_clock * max_lanes)
>>> +	/* only refuse the mode on non eDP since we have seen some wierd eDP
>>> panels
>>> +	   which are outside spec tolerances but somehow work by magic */
>>> +	if (!IS_eDP(intel_output)&&
>>> +	    (intel_dp_link_required(connector->dev, intel_output,
>>> mode->clock)
>>> +	>  intel_dp_max_data_rate(max_link_clock, max_lanes)))
>>>   		return MODE_CLOCK_HIGH;
>>>
>>>   	if (mode->clock<  10000)
>>> @@ -497,7 +506,7 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct
>>> drm_display_mode *mode,
>>>
>>>   	for (lane_count = 1; lane_count<= max_lane_count; lane_count<<= 1)
>>> {
>>>   		for (clock = 0; clock<= max_clock; clock++) {
>>> -			int link_avail = intel_dp_link_clock(bws[clock]) *
>>> lane_count;
>>> +			int link_avail =
>>> intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count);
>>>
>>>   			if (intel_dp_link_required(encoder->dev,
>>> intel_output, mode->clock)
>>>   					<= link_avail) {
>>> @@ -512,6 +521,18 @@ intel_dp_mode_fixup(struct drm_encoder *encoder,
>>> struct drm_display_mode *mode,
>>>   			}
>>>   		}
>>>   	}
>>> +
>>> +	if (IS_eDP(intel_output)) {
>>> +		/* okay we failed just pick the highest */
>>> +		dp_priv->lane_count = max_lane_count;
>>> +		dp_priv->link_bw = bws[max_clock];
>>> +		adjusted_mode->clock = intel_dp_link_clock(dp_priv->link_bw);
>>> +		DRM_DEBUG_KMS("Force picking display port link bw %02x lane "
>>> +			      "count %d clock %d\n",
>>> +			      dp_priv->link_bw, dp_priv->lane_count,
>>> +			      adjusted_mode->clock);
>>> +		return true;
>>> +	}
>>>   	return false;
>>>   }
>>>
>>> --
>>> 1.7.0.4
>>>
>>>
>>>
>>> Cheers
>>> --- manjo
>>>
>>> --
>>> kernel-team mailing list
>>> kernel-team at lists.ubuntu.com
>>> https://lists.ubuntu.com/mailman/listinfo/kernel-team
>>>
>>
>

It's on our radar. It got caught up in some internal discussions about
how we are going to manage pulling in drm changes from upstream stable.
This issue was whether we continue to automatically pull from .35 once
.34 closes. We decided we are not. Now that we've agreed on what we
are going to do, we are looking at the drm patches from .33 and .34
which include this one.

Brad
-- 
Brad Figg brad.figg at canonical.com http://www.canonical.com