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 <airl...@gmail.com> wrote:
> On Mon, Jun 28, 2010 at 4:04 PM, Zhenyu Wang <zhen...@linux.intel.com> wrote:
>> On 2010.06.28 09:45:14 +1000, Dave Airlie wrote:
>>> From: Dave Airlie <airl...@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 <airl...@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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
