On 11/2/11 5:13 PM, Keith Packard wrote:
> On Wed, 02 Nov 2011 16:35:51 -0400, Adam Jackson wrote:
>
>> It is? The DP 1.1a text for lane count is "For Rev.1.1, only the
>> following three values are supported. All other values are reserved."
>
> Yeah, if you look at the MAX_LINK_RATE field, we
On 11/2/11 4:05 PM, Keith Packard wrote:
> On Wed, 02 Nov 2011 15:36:20 -0400, Adam Jackson wrote:
>
>> The VBT is going to be crap.
>
> The only question then is what to do with hardware that doesn't have the
> DPCD value -- that's "new" in revision 0x11, after all.
It is? The DP 1.1a text for
On 11/2/11 1:31 PM, Keith Packard wrote:
> On Wed, 02 Nov 2011 13:13:52 -0400, Adam Jackson wrote:
>
>> Given the choice of trusting DPCD or the VBT, I'd definitely prefer
>> DPCD.
>
> Except that the DPCD is coded into the monitor while the VBT is done by
> the platform. And, it's the platform
On Wed, Nov 2, 2011 at 2:54 PM, Keith Packard wrote:
> On Tue, ?1 Nov 2011 23:20:26 -0700, Keith Packard
> wrote:
>
>> ? ? ? ? ? ? ? intel_dp = enc_to_intel_dp(encoder);
>> - ? ? ? ? ? ? if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT) {
>> + ? ? ? ? ? ? if (intel_dp->base.type ==
On Wed, 02 Nov 2011 16:35:51 -0400, Adam Jackson wrote:
> It is? The DP 1.1a text for lane count is "For Rev.1.1, only the
> following three values are supported. All other values are reserved."
Yeah, if you look at the MAX_LINK_RATE field, we assume that it has a
useful value. I'll bet they
On 11/2/11 12:20 PM, Jesse Barnes wrote:
> @@ -766,10 +766,10 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct
> drm_display_mode *mode,
> continue;
>
> intel_dp = enc_to_intel_dp(encoder);
> - if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT)
On Wed, 02 Nov 2011 15:36:20 -0400, Adam Jackson wrote:
> The VBT is going to be crap.
The only question then is what to do with hardware that doesn't have the
DPCD value -- that's "new" in revision 0x11, after all.
How about this:
commit 34ebe02cc78f20ae6b7865c5087c3b5ac7810185
Author: Keith
On Tue, 1 Nov 2011 23:20:26 -0700, Keith Packard wrote:
> intel_dp = enc_to_intel_dp(encoder);
> - if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT) {
> + if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT ||
> is_pch_edp(intel_dp)) {
>
On 11/2/11 2:20 AM, Keith Packard wrote:
> + if (intel_dp->link_configuration [1] &
> DP_LANE_COUNT_ENHANCED_FRAME_EN)
> + intel_dp->DP |= DP_ENHANCED_FRAMING;
> +
> + /*
> + * Check for DPCD version> 1.1 and enhanced framing support
> +
On Wed, 02 Nov 2011 11:29:53 -0400, Adam Jackson wrote:
> Redundant. You've already done the link_configuration |= above in the
> common code. You can drop the second if chunk altogether.
Here's the new version of that chunk of patch:
@@ -850,32 +864,45 @@ intel_dp_mode_set(struct
On Wed, 02 Nov 2011 13:13:52 -0400, Adam Jackson wrote:
> Given the choice of trusting DPCD or the VBT, I'd definitely prefer
> DPCD.
Except that the DPCD is coded into the monitor while the VBT is done by
the platform. And, it's the platform which may neglect to connect some
of the wires. In
On Wed, 2 Nov 2011 09:20:19 -0700, Jesse Barnes
wrote:
> But I was curious about this hunk:
>
> @@ -766,10 +766,10 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct
> drm_display_mode *mode,
> continue;
>
> intel_dp = enc_to_intel_dp(encoder);
> -
On Wed, 02 Nov 2011 11:29:53 -0400, Adam Jackson wrote:
> Redundant. You've already done the link_configuration |= above in the
> common code. You can drop the second if chunk altogether.
Thanks for catching this mistake; cut programming without the cut part...
> In related news, the
On Tue, 1 Nov 2011 23:20:26 -0700
Keith Packard wrote:
> PCH eDP has many of the same needs as regular PCH DP connections,
> including the DP_CTl bit settings, the TRANS_DP_CTL register.
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/intel_display.c |3 +-
>
PCH eDP has many of the same needs as regular PCH DP connections,
including the DP_CTl bit settings, the TRANS_DP_CTL register.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c |3 +-
drivers/gpu/drm/i915/intel_dp.c | 112 --
2
PCH eDP has many of the same needs as regular PCH DP connections,
including the DP_CTl bit settings, the TRANS_DP_CTL register.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c |3 +-
drivers/gpu/drm/i915/intel_dp.c | 112
On 11/2/11 2:20 AM, Keith Packard wrote:
+ if (intel_dp-link_configuration [1]
DP_LANE_COUNT_ENHANCED_FRAME_EN)
+ intel_dp-DP |= DP_ENHANCED_FRAMING;
+
+ /*
+* Check for DPCD version 1.1 and enhanced framing support
+
On Tue, 1 Nov 2011 23:20:26 -0700
Keith Packard kei...@keithp.com wrote:
PCH eDP has many of the same needs as regular PCH DP connections,
including the DP_CTl bit settings, the TRANS_DP_CTL register.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c
On Wed, 02 Nov 2011 11:29:53 -0400, Adam Jackson a...@redhat.com wrote:
Redundant. You've already done the link_configuration |= above in the
common code. You can drop the second if chunk altogether.
Thanks for catching this mistake; cutpaste programming without the cut part...
In related
On Wed, 2 Nov 2011 09:20:19 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
But I was curious about this hunk:
@@ -766,10 +766,10 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct
drm_display_mode *mode,
continue;
intel_dp =
On 11/2/11 12:20 PM, Jesse Barnes wrote:
@@ -766,10 +766,10 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct
drm_display_mode *mode,
continue;
intel_dp = enc_to_intel_dp(encoder);
- if (intel_dp-base.type == INTEL_OUTPUT_DISPLAYPORT) {
+
On Wed, 02 Nov 2011 13:13:52 -0400, Adam Jackson a...@redhat.com wrote:
Given the choice of trusting DPCD or the VBT, I'd definitely prefer
DPCD.
Except that the DPCD is coded into the monitor while the VBT is done by
the platform. And, it's the platform which may neglect to connect some
of
On Wed, 02 Nov 2011 11:29:53 -0400, Adam Jackson a...@redhat.com wrote:
Redundant. You've already done the link_configuration |= above in the
common code. You can drop the second if chunk altogether.
Here's the new version of that chunk of patch:
@@ -850,32 +864,45 @@
On Tue, 1 Nov 2011 23:20:26 -0700, Keith Packard kei...@keithp.com wrote:
intel_dp = enc_to_intel_dp(encoder);
- if (intel_dp-base.type == INTEL_OUTPUT_DISPLAYPORT) {
+ if (intel_dp-base.type == INTEL_OUTPUT_DISPLAYPORT ||
is_pch_edp(intel_dp)) {
On Wed, Nov 2, 2011 at 2:54 PM, Keith Packard kei...@keithp.com wrote:
On Tue, 1 Nov 2011 23:20:26 -0700, Keith Packard kei...@keithp.com wrote:
intel_dp = enc_to_intel_dp(encoder);
- if (intel_dp-base.type == INTEL_OUTPUT_DISPLAYPORT) {
+ if
On 11/2/11 1:31 PM, Keith Packard wrote:
On Wed, 02 Nov 2011 13:13:52 -0400, Adam Jacksona...@redhat.com wrote:
Given the choice of trusting DPCD or the VBT, I'd definitely prefer
DPCD.
Except that the DPCD is coded into the monitor while the VBT is done by
the platform. And, it's the
On Wed, 02 Nov 2011 15:36:20 -0400, Adam Jackson a...@redhat.com wrote:
The VBT is going to be crap.
The only question then is what to do with hardware that doesn't have the
DPCD value -- that's new in revision 0x11, after all.
How about this:
commit 34ebe02cc78f20ae6b7865c5087c3b5ac7810185
On Wed, 02 Nov 2011 16:35:51 -0400, Adam Jackson a...@redhat.com wrote:
It is? The DP 1.1a text for lane count is For Rev.1.1, only the
following three values are supported. All other values are reserved.
Yeah, if you look at the MAX_LINK_RATE field, we assume that it has a
useful value.
On 11/2/11 5:13 PM, Keith Packard wrote:
On Wed, 02 Nov 2011 16:35:51 -0400, Adam Jacksona...@redhat.com wrote:
It is? The DP 1.1a text for lane count is For Rev.1.1, only the
following three values are supported. All other values are reserved.
Yeah, if you look at the MAX_LINK_RATE field,
29 matches
Mail list logo
