[Intel-gfx] [PATCH] i915: fix ironlake edp panel setup (v2)

[Ben Guthro]

This also didn't fix the Dell E6410. I'll also note this in the bug.

I'm trying to work with some contacts at Dell to get this routed to
the right person as well...but am having limited luck with that, so
far.

On Mon, Jun 28, 2010 at 2:28 AM, Dave Airlie <airlied at gmail.com> wrote:
> On Mon, Jun 28, 2010 at 4:04 PM, Zhenyu Wang <zhenyuw at linux.intel.com> wrote:
>> On 2010.06.28 09:45:14 +1000, Dave Airlie wrote:
>>> From: Dave Airlie <airlied at redhat.com>
>>>
>>> So the previous fix didn't work for everyone, I read the eDP spec and claims a 20% overhead for encoding, so make sure we take this into account when working out the bandwidth requirements.
>>>
>>> This makes my eDP panel happy also, please test on others.
>>>
>>> Signed-off-by: Dave Airlie <airlied at redhat.com>
>>> ---
>>>  drivers/gpu/drm/i915/intel_dp.c |   10 ++++++++--
>>>  1 files changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>>> index 6094e42..9830243 100644
>>> --- a/drivers/gpu/drm/i915/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>>> @@ -139,6 +139,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)
>>>  {
>>> @@ -148,7 +154,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
>>>       int max_lanes = intel_dp_max_lane_count(intel_encoder);
>>>
>>>       if (intel_dp_link_required(connector->dev, intel_encoder, mode->clock)
>>> -                     > max_link_clock * max_lanes)
>>> +                     > intel_dp_max_data_rate(max_link_clock, max_lanes))
>>>               return MODE_CLOCK_HIGH;
>>>
>>>       if (mode->clock < 10000)
>>> @@ -509,7 +515,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_encoder, mode->clock)
>>>                                       <= link_avail) {
>>> --
>>
>> sorry, this is still broken on the 16x9 panel.
>>
>> 'intel_dp_link_required' is 107840*18/8 = 242640, 'intel_dp_max_data_rate' is
>> 270000*1*8/10 = 216000. So it will fail in both check.
>
> So this panel is definitely out of spec, according to the eDP table 3.2 and 3.3
>
> Are you sure this is the mode it actually advertises over EDID vs some
> crazy mode stored in VBT?
>
> According to the eDP spec it needs 2 lanes and 1.62.
>
> A cvt rb 1600x900 mode would fit okay
> cvt -r 1600 900
> # 1600x900 59.82 Hz (CVT 1.44M9-R) hsync: 55.40 kHz; pclk: 97.50 MHz
> Modeline "1600x900R"   97.50  1600 1648 1680 1760  900 903 908 926 +hsync -vsync
>
> Dave.
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>