* Re: drivers/gpu/drm/i915/intel_dp.c problem with commit dc22ee6fc18ce0f15424e753e8473c306ece95c1 [not found] <CACVkyFdhpU1sQb-T-pXYkV8Ot27+LYxV_=FGd=aPLLyrD3-1dg@mail.gmail.com> @ 2011-11-26 19:27 ` Keith Packard 2011-11-29 14:06 ` Patrik Kullman 0 siblings, 1 reply; 3+ messages in thread From: Keith Packard @ 2011-11-26 19:27 UTC (permalink / raw) To: Jerker Buud, Patrik Kullman; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 2204 bytes --] On Sat, 26 Nov 2011 09:50:41 -0800, Jerker Buud <b.jerker@gmail.com> wrote: > 245,247c245,246 > < if (!is_edp(intel_dp) && > < (intel_dp_link_required(intel_dp, mode->clock) > < > intel_dp_max_data_rate(max_link_clock, max_lanes))) > --- > > if (intel_dp_link_required(intel_dp, mode->clock) > > > intel_dp_max_data_rate(max_link_clock, max_lanes)) Ok, I think I understand why this change is required. These machines are 'optimized' to provide the bare minimum connection necessary between the CPU and the eDP panel -- a single lane is hooked up, which is just enough to run the link at 18bpp, but not enough to run it at 24bpp. The problem here (in intel_dp_link_required) is that this is being called to see which modes can be supported on the panel. Without the CRTC being configured with the appropriate bpp value, this code assumes 24bpp. I thought Adam Jackson had some code around that automatically switched From 24bpp to 18bpp when the link didn't have enough bandwidth for 24bpp, but I can't find that now. In any case, I think we need to centralize the bpp selection inside intel_dp.c instead of having it in both places. Then, we can make that depend on the requested mode as well as the machine configuration. Here's a patch which uses the VBT configured bpp value in this case. I'd love to hear whether this suffices to resolve your problem. diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 294f557..3e15479 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -212,10 +212,16 @@ intel_dp_link_required(struct intel_dp *intel_dp, int pixel_clock) { struct drm_crtc *crtc = intel_dp->base.base.crtc; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - int bpp = 24; + struct drm_device *dev = intel_dp->base.base.dev; + struct drm_i915_private *dev_priv = dev->dev_private; + int bpp; if (intel_crtc) bpp = intel_crtc->bpp; + else if (intel_dp->base.type == INTEL_OUTPUT_EDP) + bpp = dev_priv->edp.bpp; + else + bpp = 24; return (pixel_clock * bpp + 9) / 10; } -- keith.packard@intel.com [-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --] ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: drivers/gpu/drm/i915/intel_dp.c problem with commit dc22ee6fc18ce0f15424e753e8473c306ece95c1 2011-11-26 19:27 ` drivers/gpu/drm/i915/intel_dp.c problem with commit dc22ee6fc18ce0f15424e753e8473c306ece95c1 Keith Packard @ 2011-11-29 14:06 ` Patrik Kullman 2011-11-30 20:36 ` Patrik Kullman 0 siblings, 1 reply; 3+ messages in thread From: Patrik Kullman @ 2011-11-29 14:06 UTC (permalink / raw) To: Keith Packard; +Cc: Jerker Buud, linux-kernel I checked out a clean v3.2-rc3, applied this patch and rebooted. It still doesn't work and Caps Lock still doesn't respond, but I get very subtle flickering of the screen, 2-3 seconds apart, kind of like different shades of black. It 'feels' as if some graphics card/link/monitor negotiation is taking place. 2011/11/26 Keith Packard <keith.packard@intel.com>: > On Sat, 26 Nov 2011 09:50:41 -0800, Jerker Buud <b.jerker@gmail.com> wrote: > >> 245,247c245,246 >> < if (!is_edp(intel_dp) && >> < (intel_dp_link_required(intel_dp, mode->clock) >> < > intel_dp_max_data_rate(max_link_clock, max_lanes))) >> --- >> > if (intel_dp_link_required(intel_dp, mode->clock) >> > > intel_dp_max_data_rate(max_link_clock, max_lanes)) > > Ok, I think I understand why this change is required. > > These machines are 'optimized' to provide the bare minimum connection > necessary between the CPU and the eDP panel -- a single lane is hooked > up, which is just enough to run the link at 18bpp, but not enough to run > it at 24bpp. > > The problem here (in intel_dp_link_required) is that this is being > called to see which modes can be supported on the panel. Without the > CRTC being configured with the appropriate bpp value, this code assumes > 24bpp. > > I thought Adam Jackson had some code around that automatically switched > From 24bpp to 18bpp when the link didn't have enough bandwidth for > 24bpp, but I can't find that now. > > In any case, I think we need to centralize the bpp selection inside > intel_dp.c instead of having it in both places. Then, we can make that > depend on the requested mode as well as the machine configuration. > > Here's a patch which uses the VBT configured bpp value in this case. I'd > love to hear whether this suffices to resolve your problem. > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 294f557..3e15479 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -212,10 +212,16 @@ intel_dp_link_required(struct intel_dp *intel_dp, int pixel_clock) > { > struct drm_crtc *crtc = intel_dp->base.base.crtc; > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > - int bpp = 24; > + struct drm_device *dev = intel_dp->base.base.dev; > + struct drm_i915_private *dev_priv = dev->dev_private; > + int bpp; > > if (intel_crtc) > bpp = intel_crtc->bpp; > + else if (intel_dp->base.type == INTEL_OUTPUT_EDP) > + bpp = dev_priv->edp.bpp; > + else > + bpp = 24; > > return (pixel_clock * bpp + 9) / 10; > } > > -- > keith.packard@intel.com ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: drivers/gpu/drm/i915/intel_dp.c problem with commit dc22ee6fc18ce0f15424e753e8473c306ece95c1 2011-11-29 14:06 ` Patrik Kullman @ 2011-11-30 20:36 ` Patrik Kullman 0 siblings, 0 replies; 3+ messages in thread From: Patrik Kullman @ 2011-11-30 20:36 UTC (permalink / raw) To: Keith Packard; +Cc: Jerker Buud, linux-kernel Not sure if this is somehow related, but I experienced a weird issue with the HDMI-output today. I connected the computer to a (Acer) projector at work to hold a presentation, but it didn't work. In GNOME Displays, I could see a connected "Acer Technologies" screen, its supported resolutions listed, I could even move the cursor as if a screen was connected. Everything about Linux/GNOME seems to "think" everything was working. On the projector side of things, the Acer-logo was showing and the source (HDMI1/2) was showing. It didn't say "No Signal" as it can, but it didn't either come as far as to "Process signal", which usually appears a moment before everything is up and running. Booting up Windows, everything worked perfectly. When I got home, I connected the computer to my LCD TV and watched a video without any issues. Even sound through HDMI works great. Please let me know if you think this might be related or if I should start a new thread about this. 2011/11/29 Patrik Kullman <patrik.kullman@gmail.com>: > I checked out a clean v3.2-rc3, applied this patch and rebooted. > > It still doesn't work and Caps Lock still doesn't respond, but I get > very subtle flickering of the screen, 2-3 seconds apart, kind of like > different shades of black. > > It 'feels' as if some graphics card/link/monitor negotiation is taking place. > > 2011/11/26 Keith Packard <keith.packard@intel.com>: >> On Sat, 26 Nov 2011 09:50:41 -0800, Jerker Buud <b.jerker@gmail.com> wrote: >> >>> 245,247c245,246 >>> < if (!is_edp(intel_dp) && >>> < (intel_dp_link_required(intel_dp, mode->clock) >>> < > intel_dp_max_data_rate(max_link_clock, max_lanes))) >>> --- >>> > if (intel_dp_link_required(intel_dp, mode->clock) >>> > > intel_dp_max_data_rate(max_link_clock, max_lanes)) >> >> Ok, I think I understand why this change is required. >> >> These machines are 'optimized' to provide the bare minimum connection >> necessary between the CPU and the eDP panel -- a single lane is hooked >> up, which is just enough to run the link at 18bpp, but not enough to run >> it at 24bpp. >> >> The problem here (in intel_dp_link_required) is that this is being >> called to see which modes can be supported on the panel. Without the >> CRTC being configured with the appropriate bpp value, this code assumes >> 24bpp. >> >> I thought Adam Jackson had some code around that automatically switched >> From 24bpp to 18bpp when the link didn't have enough bandwidth for >> 24bpp, but I can't find that now. >> >> In any case, I think we need to centralize the bpp selection inside >> intel_dp.c instead of having it in both places. Then, we can make that >> depend on the requested mode as well as the machine configuration. >> >> Here's a patch which uses the VBT configured bpp value in this case. I'd >> love to hear whether this suffices to resolve your problem. >> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c >> index 294f557..3e15479 100644 >> --- a/drivers/gpu/drm/i915/intel_dp.c >> +++ b/drivers/gpu/drm/i915/intel_dp.c >> @@ -212,10 +212,16 @@ intel_dp_link_required(struct intel_dp *intel_dp, int pixel_clock) >> { >> struct drm_crtc *crtc = intel_dp->base.base.crtc; >> struct intel_crtc *intel_crtc = to_intel_crtc(crtc); >> - int bpp = 24; >> + struct drm_device *dev = intel_dp->base.base.dev; >> + struct drm_i915_private *dev_priv = dev->dev_private; >> + int bpp; >> >> if (intel_crtc) >> bpp = intel_crtc->bpp; >> + else if (intel_dp->base.type == INTEL_OUTPUT_EDP) >> + bpp = dev_priv->edp.bpp; >> + else >> + bpp = 24; >> >> return (pixel_clock * bpp + 9) / 10; >> } >> >> -- >> keith.packard@intel.com ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-11-30 20:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CACVkyFdhpU1sQb-T-pXYkV8Ot27+LYxV_=FGd=aPLLyrD3-1dg@mail.gmail.com>
2011-11-26 19:27 ` drivers/gpu/drm/i915/intel_dp.c problem with commit dc22ee6fc18ce0f15424e753e8473c306ece95c1 Keith Packard
2011-11-29 14:06 ` Patrik Kullman
2011-11-30 20:36 ` Patrik Kullman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox