ki
CC: Daniel Vetter
Cc: Eugeni Dodonov
Signed-off-by: Keith Packard
---
drivers/iommu/intel-iommu.c |5 +
include/linux/dma_remapping.h |2 ++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c0c7820..8
Ok, here's a "final" patch set to enable RC6 where possible on SNB and IVB
machines.
The first patch creates a new variable, intel_iommu_enabled, that is
exported by the intel iommu code and set when that code has
successfully initialized itself. The old plan of using no_iommu ||
dmar_disabled
forcewake, causing the test to work correctly.
Signed-off-by: Keith Packard
Cc: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c |7 ---
drivers/gpu/drm/i915/i915_drv.h |3 +--
drivers/gpu/drm/i915/intel_display.c |8 +++-
3 files changed, 8 insertions(+), 10 deletions
forcewake, causing the test to work correctly.
Signed-off-by: Keith Packard kei...@keithp.com
Cc: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.c |7 ---
drivers/gpu/drm/i915/i915_drv.h |3 +--
drivers/gpu/drm/i915/intel_display.c |8 +++-
3
Hejtmanek xhejt...@fi.muni.cz
Cc: Andrew Lutomirski l...@mit.edu
CC: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Eugeni Dodonov eugeni.dodo...@intel.com
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/iommu/intel-iommu.c |5 +
include/linux/dma_remapping.h |2 ++
2 files changed, 7
Ok, here's a final patch set to enable RC6 where possible on SNB and IVB
machines.
The first patch creates a new variable, intel_iommu_enabled, that is
exported by the intel iommu code and set when that code has
successfully initialized itself. The old plan of using no_iommu ||
dmar_disabled
On Fri, 21 Oct 2011 09:10:12 +0200, Jean Delvare wrote:
> - /* vesa says 2.2 ms is enough, 1 jiffy doesn't seem to always
> - * make this, 2 jiffies is a lot more reliable */
> - i2c->algo.bit.timeout = 2;
> + i2c->algo.bit.timeout =
On Wed, 23 Nov 2011 20:36:00 +, David Woodhouse
wrote:
> This is horrid. In the general case, drivers have no business knowing
> this. We need to properly identify what is wrong with this hardware, and
> put in a quirk for it ? perhaps refusing to enable the IOMMU at all on
> the broken
On Wed, 23 Nov 2011 16:29:58 +0800, Wu Fengguang
wrote:
> What I need is a hot plug hook that knows whether the monitor is
> plugged or removed, which is only possible if the hook is called
> after ->detect().
That would be mode_set to tell you that the monitor is in use, and the
disable
On Wed, 23 Nov 2011 16:29:58 +0800, Wu Fengguang fengguang...@intel.com wrote:
What I need is a hot plug hook that knows whether the monitor is
plugged or removed, which is only possible if the hook is called
after -detect().
That would be mode_set to tell you that the monitor is in use, and
On Wed, 23 Nov 2011 20:36:00 +, David Woodhouse dw...@infradead.org wrote:
This is horrid. In the general case, drivers have no business knowing
this. We need to properly identify what is wrong with this hardware, and
put in a quirk for it — perhaps refusing to enable the IOMMU at all on
.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpY1RP4t0c3h.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, 23 Nov 2011 09:28:52 +0200 (EET), Meelis Roos wrote:
> Yes, VT-x and VT-d are both enabled from BIOS setup.
Any reason for that? We've found all kinds of problems with DMAR enabled
on these machines that is only resolved by completely turning it
off. You might try with intel_iommu=off
On Tue, 22 Nov 2011 14:43:00 -0800 (PST), Linus Torvalds wrote:
> X is hung, but I can at least switch VT's and send this from a text
> terminal..
Yeah, the GPU is locked up; doesn't look like we did anything wrong in
the kernel here; it's happily waiting for the GPU which isn't moving.
On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett wrote:
> So the user has to choose between 5W of power saving or having dmar? And
> we default to giving them dmar? I think that's going to come as a
> surprise to people.
You'd have to go into the BIOS to turn this on for most machines at
On Tue, 22 Nov 2011 15:40:55 +0800, Wu Fengguang
wrote:
> So the v3 patch will behave equally well on KMS console, gnome desktop
> and bare X. Shall we just use it, or go back and use the original
> ->hot_remove patch?
I'm not sure why we need any change to the core DRM code. The HDMI and
DP
On Tue, 22 Nov 2011 13:08:06 +0200 (EET), Meelis Roos wrote:
> > 3.0 worked fine, 3.1-rc9 worked fine, I think -rc10 too. 3.1 release
> > hangs in random places while using X.
Do you have VT-d enabled in the BIOS?
--
keith.packard at intel.com
-- next part --
A
On Tue, 22 Nov 2011 13:08:06 +0200 (EET), Meelis Roos mr...@linux.ee wrote:
3.0 worked fine, 3.1-rc9 worked fine, I think -rc10 too. 3.1 release
hangs in random places while using X.
Do you have VT-d enabled in the BIOS?
--
keith.pack...@intel.com
pgpDDQsjBrQss.pgp
Description: PGP
On Tue, 22 Nov 2011 15:40:55 +0800, Wu Fengguang fengguang...@intel.com wrote:
So the v3 patch will behave equally well on KMS console, gnome desktop
and bare X. Shall we just use it, or go back and use the original
-hot_remove patch?
I'm not sure why we need any change to the core DRM code.
On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett m...@redhat.com wrote:
So the user has to choose between 5W of power saving or having dmar? And
we default to giving them dmar? I think that's going to come as a
surprise to people.
You'd have to go into the BIOS to turn this on for most
On Tue, 22 Nov 2011 14:43:00 -0800 (PST), Linus Torvalds
torva...@linux-foundation.org wrote:
X is hung, but I can at least switch VT's and send this from a text
terminal..
Yeah, the GPU is locked up; doesn't look like we did anything wrong in
the kernel here; it's happily waiting for the
On Wed, 23 Nov 2011 09:28:52 +0200 (EET), Meelis Roos mr...@linux.ee wrote:
Yes, VT-x and VT-d are both enabled from BIOS setup.
Any reason for that? We've found all kinds of problems with DMAR enabled
on these machines that is only resolved by completely turning it
off. You might try with
On Mon, 21 Nov 2011 22:48:21 + (Local time zone must be set--see zic manual
page), Marcos Paulo de Souza wrote:
> My max_brightness is 1, and my brightness is 0.
Right, we've prevented the internal backlight driver from exposing a max
value of 0 as that's just confusing.
> But, my
On Mon, 21 Nov 2011 17:23:06 +0100, Daniel Vetter wrote:
> Indeed, nice catch (albeit totally unlikely to be hit, because the error
> only happens when the gpu ceases to progress in the ring, so imo not
> stable material). Keith, please pick this up for fixes, thanks.
It's already there and
On Mon, 21 Nov 2011 19:05:38 +0800, Wu Fengguang
wrote:
> Ah I got it. I'm running debian+fluxbox w/o those fancy features...
Then you can manually run the 'xrandr' command to configure the new
monitor as desired, at which point the kernel mode_set function will be
called.
--
keith.packard
On Mon, 21 Nov 2011 14:37:49 +0800, Wu Fengguang
wrote:
> On monitor hot plug/unplug, update ELD and set/clear SDVO_AUDIO_ENABLE
> or DP_AUDIO_OUTPUT_ENABLE accordingly. So that the audio driver will
> receive hot plug events and take action to refresh its device state and
> ELD contents.
>
>
On Mon, 21 Nov 2011 14:37:49 +0800, Wu Fengguang fengguang...@intel.com wrote:
On monitor hot plug/unplug, update ELD and set/clear SDVO_AUDIO_ENABLE
or DP_AUDIO_OUTPUT_ENABLE accordingly. So that the audio driver will
receive hot plug events and take action to refresh its device state and
On Mon, 21 Nov 2011 19:05:38 +0800, Wu Fengguang fengguang...@intel.com wrote:
Ah I got it. I'm running debian+fluxbox w/o those fancy features...
Then you can manually run the 'xrandr' command to configure the new
monitor as desired, at which point the kernel mode_set function will be
called.
On Mon, 21 Nov 2011 17:23:06 +0100, Daniel Vetter dan...@ffwll.ch wrote:
Indeed, nice catch (albeit totally unlikely to be hit, because the error
only happens when the gpu ceases to progress in the ring, so imo not
stable material). Keith, please pick this up for fixes, thanks.
It's already
On Sat, 19 Nov 2011 11:26:07 + (Local time zone must be set--see zic manual
page), Marcos Paulo de Souza wrote:
> So, anybody gets the same message?
>
> I'm trying the 3.2-rc2 and it gives the same message.
>
> Again, if you need someone to make tests, or test some patches, I'm
> able to
On Sat, 19 Nov 2011 07:25:09 -0200, Eugeni Dodonov
wrote:
> Just one question I caught on 2nd read. Shouldn't we have #else within
> this #ifdef block, to return 1? Otherwise, if CONFIG_INTEL_IOMMU is
> not defined, we'll always disable rc6.
Oops! Thanks for catching this. Here's a new version
On Sat, 19 Nov 2011 07:25:09 -0200, Eugeni Dodonov eug...@dodonov.net wrote:
Just one question I caught on 2nd read. Shouldn't we have #else within
this #ifdef block, to return 1? Otherwise, if CONFIG_INTEL_IOMMU is
not defined, we'll always disable rc6.
Oops! Thanks for catching this. Here's
):
drm/i915: enable cacheable objects on Ivybridge
Keith Packard (12):
agp: iommu_gfx_mapped only available if CONFIG_INTEL_IOMMU is set
drm/i915: Use mode_config.mutex in ironlake_panel_vdd_work
drm/i915: Module parameters using '-1' as default must be signed type
drm/i915
RC6 should always work on IVB, and should work on SNB whenever IO
remapping is disabled. Make the default value for the parameter turn
it on in these cases. Setting the value to either 0 or 1 will force
the specified behavior.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.c
On Fri, 18 Nov 2011 17:37:40 +0800, Wu Fengguang
wrote:
> However when in X, ->mode_set won't be called at all. Only
> ->get_modes and ->detect are called...
The desktop software will call mode_set when it configures the
monitor. Otherwise, it's not being used (and so shouldn't have audio
On Fri, 18 Nov 2011 17:37:40 +0800, Wu Fengguang fengguang...@intel.com wrote:
However when in X, -mode_set won't be called at all. Only
-get_modes and -detect are called...
The desktop software will call mode_set when it configures the
monitor. Otherwise, it's not being used (and so
RC6 should always work on IVB, and should work on SNB whenever IO
remapping is disabled. Make the default value for the parameter turn
it on in these cases. Setting the value to either 0 or 1 will force
the specified behavior.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm
):
drm/i915: enable cacheable objects on Ivybridge
Keith Packard (12):
agp: iommu_gfx_mapped only available if CONFIG_INTEL_IOMMU is set
drm/i915: Use mode_config.mutex in ironlake_panel_vdd_work
drm/i915: Module parameters using '-1' as default must be signed type
drm/i915
On Thu, 17 Nov 2011 17:45:40 -0500, Adam Jackson wrote:
> Your silicon people worry me.
In any case, the changes are mostly to move bits around so that there
are two bits for pipe select
> I don't even. Unless you're looking at some other version of the DP
> spec than me, I was pretty sure
-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h | 18 +
drivers/gpu/drm/i915/intel_dp.c | 151 ++-
2 files changed, 135 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b080cc8..43f27ad
-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_reg.h | 18 +
drivers/gpu/drm/i915/intel_dp.c | 151 ++-
2 files changed, 135 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index
On Thu, 3 Nov 2011 15:41:25 -0700, Jesse Barnes
wrote:
> Except for VDD?? That does come on... and shouldn't be any different
> than a full power sequence as far as link training etc go...
Oh, that's a good point. Doing things in this order essentially forces
yet another full panel power
On Thu, 3 Nov 2011 13:03:49 -0700, Jesse Barnes
wrote:
> Reviewed-by: Jesse Barnes
I've updated the pch-edp-fixes branch with your suggestions and attached
your R-b: to the reviewed patches.
That leaves only the panel power sequencing changes, which could
probably use more testing to make
On Thu, 3 Nov 2011 13:03:29 -0700, Jesse Barnes
wrote:
> Sneaky putting this bug fix into this patch. :)
Ickle already saw that, and I've split it out into a separate patch. I
don't think this is necessary, but it seems like a sensible change.
> Don't you love the training state machine? I
On Thu, 3 Nov 2011 13:00:11 -0700, Jesse Barnes
wrote:
> A few comments on this one (also, is it strictly required to fix your
> bug)?
I think so; the panel definitely was not happy when I turned the link
off while the panel power was on. Having the mode setting and DPMS paths
doing things in
On Thu, 3 Nov 2011 12:57:08 -0700, Jesse Barnes
wrote:
> Modulo what we already discussed on irc about the PP_READY bit, and the
Right, the PP_READY bit requires that everything needed for PCH eDP be
running, even when you're using a CPU connected eDP panel, and so it's
not actually useful.
>
On Thu, 3 Nov 2011 12:57:08 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Modulo what we already discussed on irc about the PP_READY bit, and the
Right, the PP_READY bit requires that everything needed for PCH eDP be
running, even when you're using a CPU connected eDP panel, and so it's
On Thu, 3 Nov 2011 13:00:11 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
A few comments on this one (also, is it strictly required to fix your
bug)?
I think so; the panel definitely was not happy when I turned the link
off while the panel power was on. Having the mode setting and DPMS
On Thu, 3 Nov 2011 13:03:29 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Sneaky putting this bug fix into this patch. :)
Ickle already saw that, and I've split it out into a separate patch. I
don't think this is necessary, but it seems like a sensible change.
Don't you love the
On Thu, 3 Nov 2011 13:03:49 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Thanks for your careful patch review here.
--
keith.pack...@intel.com
pgpPNrs802K0I.pgp
Description: PGP signature
On Thu, 3 Nov 2011 13:03:49 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
I've updated the pch-edp-fixes branch with your suggestions and attached
your R-b: to the reviewed patches.
That leaves only the panel power sequencing changes,
On Thu, 3 Nov 2011 15:41:25 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Except for VDD?? That does come on... and shouldn't be any different
than a full power sequence as far as link training etc go...
Oh, that's a good point. Doing things in this order essentially forces
yet another
value. I'll bet they were thinking of letting the spec support
things like alternate clock rates or 3 lanes or something, and the 1.1
version just tied things down to allow only sensible values there.
How about we just always use the DPCD value?
commit e0fafa5dee031ef6174eadb005a5f01d13da931d
Autho
Author: Keith Packard
Date: Wed Nov 2 13:03:47 2011 -0700
drm/i915: Use DPCD value for max DP lanes where possible
Fall back to the VBT value for eDP monitors only when DPCD is missing
the value.
Signed-off-by: Keith Packard
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/dr
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 ||
> i
On Wed, 02 Nov 2011 09:12:13 +, Chris Wilson
wrote:
> This would seem to be a separate chunk to initiate training on only the
> lanes we intend to use.
> -Chris
Here's that patch separated out:
commit e7fecae483754ca9a42312be18f58ceb454702fe
Author: Keith Packard
Date: Wed No
On Wed, 2 Nov 2011 09:23:10 -0700, Jesse Barnes
wrote:
> Note that PP_READY will incorrectly depend on some other register
> values, so in some configs the panel will happily power up even if
> PP_READY isn't set yet...
Here's the new version of that chunk:
@@ -906,32 +905,56 @@
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, 02 Nov 2011 09:12:13 +, Chris Wilson
wrote:
> This would seem to be a separate chunk to initiate training on only the
> lanes we intend to use.
Yeah, this got left in during some debugging; it might be a good thing
to do, but it's completely separate. I've pulled it out into a
On Wed, 2 Nov 2011 09:23:10 -0700, Jesse Barnes
wrote:
> Note that PP_READY will incorrectly depend on some other register
> values, so in some configs the panel will happily power up even if
> PP_READY isn't set yet...
Yeah, I'd like to understand why PP_READY isn't getting set; we should
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 Wed, 2 Nov 2011 09:02:55 -0700, Jesse Barnes
wrote:
> Can't we just set UNLOCK_REGS at load time and have asserts sprinkled
> here and there?
I think we'd need it at resume time as well; it seemed easier to just
set it every time we touch the register.
--
keith.packard at intel.com
On Tue, 1 Nov 2011 23:20:27 -0700, Keith Packard wrote:
> -static void ironlake_wait_panel_off(struct intel_dp *intel_dp)
> +#define IDLE_ON_MASK (PP_ON | PP_READY | PP_SEQUENCE_MASK | 0
> | PP_SEQUENCE_STATE_MASK)
> +#define IDLE_ON_VALUE(PP_O
Found a couple of bare tabs in intel_dp.c
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bf20a35..7ebeb01 100644
--- a/drivers
Instead of going through the sequence just once, run through the whole
set up to 5 times to see if something can work. This isn't part of the
DP spec, but the BIOS seems to do it, and given that link training
failure is so bad, it seems reasonable to follow suit.
Signed-off-by: Keith Packard
Make sure the sequence of operations in all three functions makes
sense:
1) The backlight must be off unless the screen is running
2) The link must be running to turn the eDP panel on/off
3) The CPU eDP PLL must be running until everything is off
Signed-off-by: Keith Packard
---
drivers/gpu
The panel power sequencing hardware tracks the stages of panel power
sequencing and signals when the panel is completely on or off. Instead
of blindly assuming the panel timings will work, poll the panel power
status register until it shows the correct values.
Signed-off-by: Keith Packard
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
No persistent data was ever stored here, so link_status is instead
allocated on the stack as needed.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 65 +-
1 files changed, 36 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm
Every usage of PCH_PP_CONTROL sets the PANEL_UNLOCK_REGS value to
ensure that writes will be respected, move this to a common function
to make the driver cleaner.
No functional changes.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 37
Here's a patch sequence which makes my PCH-connected eDP panel
work. The main bug was a pile of places where the driver was
incorrectly treating a PCH connected eDP panel like a CPU connected
eDP panel, setting incorrect bits in the DP_CTL register and failing
to configure the TRANS_DP_CTL
Here's a patch sequence which makes my PCH-connected eDP panel
work. The main bug was a pile of places where the driver was
incorrectly treating a PCH connected eDP panel like a CPU connected
eDP panel, setting incorrect bits in the DP_CTL register and failing
to configure the TRANS_DP_CTL
Every usage of PCH_PP_CONTROL sets the PANEL_UNLOCK_REGS value to
ensure that writes will be respected, move this to a common function
to make the driver cleaner.
No functional changes.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 37
Make sure the sequence of operations in all three functions makes
sense:
1) The backlight must be off unless the screen is running
2) The link must be running to turn the eDP panel on/off
3) The CPU eDP PLL must be running until everything is off
Signed-off-by: Keith Packard kei...@keithp.com
The panel power sequencing hardware tracks the stages of panel power
sequencing and signals when the panel is completely on or off. Instead
of blindly assuming the panel timings will work, poll the panel power
status register until it shows the correct values.
Signed-off-by: Keith Packard kei
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
Instead of going through the sequence just once, run through the whole
set up to 5 times to see if something can work. This isn't part of the
DP spec, but the BIOS seems to do it, and given that link training
failure is so bad, it seems reasonable to follow suit.
Signed-off-by: Keith Packard kei
On Tue, 1 Nov 2011 23:20:27 -0700, Keith Packard kei...@keithp.com wrote:
-static void ironlake_wait_panel_off(struct intel_dp *intel_dp)
+#define IDLE_ON_MASK (PP_ON | PP_READY | PP_SEQUENCE_MASK | 0
| PP_SEQUENCE_STATE_MASK)
+#define IDLE_ON_VALUE(PP_ON
On Wed, 2 Nov 2011 09:02:55 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Can't we just set UNLOCK_REGS at load time and have asserts sprinkled
here and there?
I think we'd need it at resume time as well; it seemed easier to just
set it every time we touch the register.
--
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 Wed, 2 Nov 2011 09:23:10 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Note that PP_READY will incorrectly depend on some other register
values, so in some configs the panel will happily power up even if
PP_READY isn't set yet...
Yeah, I'd like to understand why PP_READY isn't
On Wed, 02 Nov 2011 09:12:13 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
This would seem to be a separate chunk to initiate training on only the
lanes we intend to use.
Yeah, this got left in during some debugging; it might be a good thing
to do, but it's completely separate. I've
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 Wed, 02 Nov 2011 09:12:13 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
This would seem to be a separate chunk to initiate training on only the
lanes we intend to use.
-Chris
Here's that patch separated out:
commit e7fecae483754ca9a42312be18f58ceb454702fe
Author: Keith Packard kei
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
Author: Keith Packard kei...@keithp.com
Date: Wed Nov 2 13:03:47 2011 -0700
drm/i915: Use DPCD value for max DP lanes where possible
Fall back to the VBT value for eDP monitors only when DPCD is missing
the value.
Signed-off-by: Keith Packard kei...@keithp.com
diff --git
value everywhere.
Signed-off-by: Keith Packard kei...@keithp.com
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 02b56ce..5056d29 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -154,16 +154,12
Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.
Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: Keith Packard
Cc: Ben Widawsky
---
Here's a shorter patch which just elides the body
Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.
Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: Keith Packard
Cc: Ben Widawsky
---
drivers/char/agp/intel-gtt.c |4
1 files
Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.
Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: Keith Packard kei...@keithp.com
Cc: Ben Widawsky b...@bwidawsk.net
---
drivers/char/agp
Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.
Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: Keith Packard kei...@keithp.com
Cc: Ben Widawsky b...@bwidawsk.net
---
Here's a shorter
per specs
drm/i915: read full receiver capability field during DP hot plug
drm/i915: add DP test request handling
drm/i915: fix ILK+ infoframe support
drm/i915: use correct SPD type value
Keith Packard (30):
drm/i915: broken copyright encoding in intel_bios.c
drm
drm/i915: read full receiver capability field during DP hot plug
drm/i915: add DP test request handling
drm/i915: fix ILK+ infoframe support
drm/i915: use correct SPD type value
Keith Packard (30):
drm/i915: broken copyright encoding in intel_bios.c
drm/i915: Use
On Mon, 17 Oct 2011 19:07:51 -0200, Eugeni Dodonov
wrote:
> From what I've checked, the other return error value in this context could
> be -EREMOTEIO, which could be caused by transmission error so it should be
> retried.
Oh, there's -ENOMEM, -EINVAL and probably a few others down in the
+ }
This seems good to me; are there additional error values which should
also be considered fatal and not subject to retry?
Reviewed-by: Keith Packard
-keith
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-si
;
+ }
This seems good to me; are there additional error values which should
also be considered fatal and not subject to retry?
Reviewed-by: Keith Packard kei...@keithp.com
-keith
pgpFsUdLzQUmW.pgp
Description: PGP signature
___
dri-devel mailing list
dri
501 - 600 of 1027 matches
Mail list logo
