Re: [PATCH 2/2] drm/i915/dp: Remove eDP special cases from bandwidth checks

From: Adam Jackson <ajax@redhat.com>
To: Keith Packard <keithp@keithp.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/i915/dp: Remove eDP special cases from bandwidth checks
Date: Mon, 17 Oct 2011 13:29:18 -0400	[thread overview]
Message-ID: <1318872559.7630.56.camel@atropine> (raw)
In-Reply-To: <yun7h46zsry.fsf@aiko.keithp.com>

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

On Fri, 2011-10-14 at 23:13 -0700, Keith Packard wrote:
> On Fri, 14 Oct 2011 12:43:50 -0400, Adam Jackson <ajax@redhat.com> wrote:
> 
> > These were just working around the math being wrong.
> 
> One wonders whether this might break some machines which are currently
> working. Should we emit an error or something if an eDP panel asks for
> the impossible?

Probably, but I think in cases where that happens we should be
considering the driver to be broken before the panel.  No one's going to
manufacture hardware that can't run Windows.

The patch adding that check - fe27d53e5c597ee5ba5d72a29d517091f244e974 -
references bug #28070.  Relevant attachments:

https://bugs.freedesktop.org/attachment.cgi?id=35584
[drm:drm_mode_debug_printmodeline], Modeline 25:"1920x1080" 60 137700
1920 1968 2000 2066 1080 1083 1088 1111 0x48 0xa
[drm:intel_dp_mode_fixup], Display port link bw 06 lane count 2 clock 162000

https://bugs.freedesktop.org/attachment.cgi?id=35585
eDP block: type 6
	Power Sequence: T3 3000 T7 400 T9 2000 T10 500 T12 5000
	Panel color depth: 18bpp
	eDP sDRRs MSA timing delay: 0
	Link params:
		rate: 1.62G
		lanes: x1 mode
		pre-emphasis: none
		vswing: 0.4V

Old math: (137700 * 18 + 7) / 8  == 309825
New math: (137700 * 18 + 9) / 10 == 247860

I'm coming to believe that the eDP block's link parameters are nonsense
and we should just trust DPCD.  Which seems like a solid plan
regardless.  Sadly that dmesg doesn't include a DPCD dump, but, the
threshold table looks like this:

Rate / Lanes	1	2	4
1.62GHz		129600	259200	518400
2.7GHZ		216000	432000	864000

Note that the corrected math gives us a data rate that fits in 2x1.62,
but the old math requires either more lanes or a higher rate.  So I
suspect the machine wasn't broken in the first place.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 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