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 register
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
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
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
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
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 Pa
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
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.pack...@intel.com
pgp9aTPX
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&paste programming without the cut part...
> In related news, the c
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, 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
have
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 separ
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 an
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 drm_encode
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 @@ intel_dp_mode_
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: W
On Wed, 2 Nov 2011 16:52:46 +0800, Wu Fengguang wrote:
> In fact Linux 3.1 does not have the ELD patch yet. It should go into
> the upcoming 3.2.
The ELD patch is on Linus' master branch.
--
keith.pack...@intel.com
pgprsJ9jvJTLR.pgp
Description: PGP signature
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
ac7810185
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/i9
e. 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
On Sun, 23 Oct 2011 12:13:43 +0200, Daniel Vetter wrote:
> Hi Keith,
>
> This patch isn't in your -next pull request. Please consider merging for
> 3.2.
I've merged this to -next.
--
keith.pack...@intel.com
pgpWigHouv8wm.pgp
Description: PGP signature
On Sun, 23 Oct 2011 13:35:45 +0100, Chris Wilson
wrote:
> On Sun, 23 Oct 2011 14:09:07 +0200, Daniel Vetter wrote:
> > Keith, can take a look at patches 1-2 and consider merging them for 3.2?
>
> Those two are
> Reviewed-by: Chris Wilson
And merged to -next.
--
keith.pack...@intel.com
pgp
On Mon, 24 Oct 2011 00:11:57 +0200, Daniel Vetter wrote:
> This patch only fixes things up so that we prefault the entire page range
> and not just the first PAGE_SIZE bytes (i.e. at most 2 pages). So I don't
> see the risk of extending the current behaviour to all pages. Userspace
> can already
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 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 d
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 th
On Thu, 3 Nov 2011 13:03:49 -0700, Jesse Barnes
wrote:
> Reviewed-by: Jesse Barnes
Thanks for your careful patch review here.
--
keith.pack...@intel.com
pgpgfyj2k2GbD.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freed
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 sur
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 seque
On Fri, 4 Nov 2011 23:28:07 +0100, Cedric Sodhi wrote:
Non-text part: multipart/mixed
> Hello,
>
> between 3.1 and cc03bbf1 on linux-next there has been a regression which
> causes the screen to go black (not blank, backlight is still lit) on
> KMS. The system runs fine in the background and, to
On Wed, 09 Nov 2011 15:29:13 +0100, Michel Alexandre Salim
wrote:
> the quirk table unreachable if i915_panel_use_ssc is set. This patch
> reorders the tests so that the quirk table is checked first, the
> i915_panel_use_ssc next and the original per-device setting last.
The requirement is that
e -- we're supposed to make it so that the
command line can override the quirks, but there's no way to use a quirk
given the mis-declared parameter.
This is untested...
From e64ecadef40e3c2035cd4e9b967ffd83489bdea0 Mon Sep 17 00:00:00 2001
From: Keith Packard
Date: Wed, 9 Nov 2011 0
On Wed, 16 Nov 2011 16:49:40 +0100, Daniel Vetter
wrote:
> So we need to check whether DMAR is enabled (on the
> entire system, i.e. the variable exported for the ilk workaround is
> not good enough)
Can you figure out what *would* be sufficient? Getting semaphores turned
on for the 99% who are
On Wed, 16 Nov 2011 21:18:13 +0100, Daniel Vetter
wrote:
> Last time I've played around with all the combinations, only
> intel_iommu=off was good enough to prevent the hang.
> intel_iommu=igd_off still hangs (which is what the current value
> exported by the dmar code dopends on, iirc). If I re
On Wed, 16 Nov 2011 21:56:37 +0100 (CET), "Nicolas Kalkhof"
wrote:
> Not quite. On my i7 2620M (Lenovo T420) the gpu frequently hangs when
> decoding videos (vaapi) and running OpenGL apps/games at the same
> time. Disabling iommu makes my system relatively stable even with rc6
> enabled. I have
: 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
On Wed, 16 Nov 2011 18:14:55 +0100, Takashi Iwai wrote:
> While refactoring of backlight control code in commit [a95735569:
> drm/i915: Refactor panel backlight controls], the handling of the bit
> 0 of duty-cycle was gone except for pineview. This resulted in invalid
> register values for old c
On Wed, 28 Sep 2011 11:57:24 +0200, Daniel Vetter
wrote:
> + char __user *end = uaddr + size - 1;
...
> + if (ret == 0) {
> + if (((unsigned long)uaddr & PAGE_MASK) !=
> + ((unsigned long)end & PAGE_MASK))
> + ret = __put_user
On Wed, 16 Nov 2011 10:58:03 +0100, Takashi Iwai wrote:
> When the brightness property is inquired while the backlight is disabled,
> the driver returns a wrong value (zero) because it probes the value after
> the backlight was turned off. This caused a black screen even after the
> backlight is
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 tho
On Fri, 18 Nov 2011 10:12:38 +0100, Daniel Vetter
wrote:
> We want to prefault the last byte if the pfn of the last prefault
> address doesn't match the pfn of the last byte of the userspace
> address range. Only happens when userspace hands in badly aligned
> address, not every time. I've reche
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
route
eans that up at the same time).
From e06789f688dc7ab1331f5f15ad3d60326b5139b4 Mon Sep 17 00:00:00 2001
From: Keith Packard
Date: Fri, 18 Nov 2011 11:09:24 -0800
Subject: [PATCH] drm/i915: Treat pre-gen4 backlight duty cycle value
consistently
For i945 and earlier chips, the backlight frequency value
On Fri, 18 Nov 2011 11:36:32 -0800, Jesse Barnes
wrote:
> + while (count++ < 50 && (I915_READ_NOTRACE(FORCEWAKE_MT_ACK) & 1))
You said this should be << 16
> + I915_WRITE_NOTRACE(FORCEWAKE_MT, (1<<15) | 1);
and this should be << 16 too
> + if (I915_READ(ECOBUS) &
On Fri, 18 Nov 2011 14:12:03 -0800, Jesse Barnes
wrote:
> No this one should be looking at the bottom bit, so I think it's ok.
Sorry, bad mail edit. There's one << 15 in both force_wake_mt_put and
force_wake_mt_get and they both need to be << 16:
+void __gen6_gt_force_wake_mt_get(struct drm_i
On Fri, 18 Nov 2011 14:48:39 -0800, Jesse Barnes
wrote:
> So the ECOBUS reg *is* in the GT power well. Which means in order to
> read it we have to disable RC6 altogether, forcibly, using the 0xa090
> reg, set up force wake, then re-enable RC6.
Not surprising the ECOBUS is in the well; we real
2: force MT mode. shift by 16
v3: set MT force wake bits then check ECOBUS
Tested-by: Keith Packard
Signed-off-by: Jesse Barnes
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.c | 35 -
drivers/gpu/drm/i915/i915_drv.h | 13
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
n6.
Jesse Barnes (1):
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
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 o
On Sat, 19 Nov 2011 11:05:05 +0100, Takashi Iwai wrote:
> Maybe it'd be better to mention that actually setting bit-0 caused a
> blank screen on some machines.
Was that caused by *just* setting bit zero? Or was it caused by setting
the duty cycle to 0x, in which case it would be larger than
On Mon, 21 Nov 2011 11:03:49 -0200, Eugeni Dodonov
wrote:
> -unsigned int i915_semaphores __read_mostly = 0;
> +unsigned int i915_semaphores __read_mostly = -1;
That better be signed or it's not going to compare well with -1
Otherwise, this looks good to me.
Reviewed-by: Ke
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.
>
> A
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.pack...@int
On Sun, 20 Nov 2011 12:22:50 +0100, Takashi Iwai wrote:
> So, writing bit-0 caused a problem, as it seems.
Thanks. I've noted that in the patch message.
--
keith.pack...@intel.com
pgpCXCnhRKCYp.pgp
Description: PGP signature
___
Intel-gfx mailing l
On Tue, 22 Nov 2011 17:40:25 +0100, Daniel Mack wrote:
> Just curious - is this patch queued somewhere for mainline yet?
I'm waiting for airlied to pull drm-fixes-intel before I push more stuff
there.
--
keith.pack...@intel.com
pgpn9lOMl3zqH.pgp
Description: PGP signature
___
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 dri
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
le
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 functio
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 chips
On Sat, 22 Oct 2011 19:41:23 -0700, Ben Widawsky wrote:
> + mode != dev_priv->relative_constants_mode) {
> + if (INTEL_INFO(dev)->gen < 4)
> + return -EINVAL;
> +
> + if (INTEL_INFO(dev)->gen > 5 &&
> +
On Wed, 26 Oct 2011 10:53:11 -0400, Adam Jackson wrote:
> On Wed, 2011-10-19 at 10:28 -0400, Adam Jackson wrote:
>
> > I assume the SDVO LVDS options block in the VBT would tell us what bits
> > are correct to program here, but intel_bios.h documents only the layout
> > of that structure, not its
Just reading through vol1c.4 of the bspec this evening and found something odd.
Bit 11 of MI_MODE is "Invalidate UHPTR enable".
Bit 12 of MI_MODE is "MI_FLUSH Enable"
And, yet, in i915_reg.h:
#define MI_MODE 0x0209c
# define VS_TIMER_DISPATCH (1 << 6)
# def
On Wed, 30 Nov 2011 03:42:00 +, Ben Widawsky wrote:
> I do not think so. We've (Chris, I, and perhaps Jesse?) been through
> this excercise at least twice before, and both times resulted in hangs
> when we switched to bit 12 on Ironlake, not sure about other
> platforms.
Then, perhaps, a com
On Thu, 08 Dec 2011 14:10:06 +, Chris Wilson
wrote:
> I had to remind myself why both the driver and the kernel are both
> touching the backlight across DPMS; the answer as I see it is that the
> kernel only knows about the raw backlight interface whereas the driver
> adjusts it via the pref
in RC6 and isn't
using MT 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,
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..8dc19b8 100644
--- a/dri
RC6 should always work on IVB, and should work on SNB whenever IO
remapping is disabled. RC6 never works on Ironlake. Make the default
value for the parameter follow these guidelines. Setting the value
to either 0 or 1 will force the specified behavior.
Signed-off-by: Keith Packard
Reviewed-by
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 wou
On Mon, 28 Nov 2011 16:15:19 -0200, Eugeni Dodonov
wrote:
> For now, as semaphores interaction with VTd causes random issues on SNB,
> we do not enable them by default. But they can still be enabled via the
> semaphores=1 kernel parameter.
Could we enable semaphores on SNB when VTd is not runni
On Tue, 13 Dec 2011 17:01:33 +0100, Daniel Vetter wrote:
> - or remove it all and invalidate/flush unconditionally.
Eric and I were chatting yesterday about trying this -- it seems like
we'd be able to dramatically simplify the kernel module by doing this,
and given how much flushing already occ
On Tue, 13 Dec 2011 14:49:49 -0800, Ben Widawsky wrote:
> Would we want to keep domain tracking if the HW worked correctly and we
> didn't have to always flush. It seems like a shame to just gut the code
> if it actually could offer a benefit on future generations.
That sounds like premature opt
On Wed, 14 Dec 2011 00:04:26 +0100, Daniel Vetter
wrote:
> Hi Keith,
>
> I've noticed that you merged my patch "rm/i915: properly prefault for
> pread/pwrite" into your -fixes branch (which I assume is headed for
> 3.2). Please remove that from your queue again for the following
> reasons:
Than
On Tue, 13 Dec 2011 17:09:45 -0800, Eric Anholt wrote:
> We introduced this complexity with no evidence that it would help, just
> because we thought, like you, that "avoiding cache flushes should be
> good, right?". Experiments so far say we were wrong.
Right, you'd think we'd have learned to
On Thu, 15 Dec 2011 10:38:16 +, Chris Wilson
wrote:
> Reverting de842eff4101 (drm/i915: Wait for LVDS panel power sequence)
> should get another 0.4s back if intel_lvds_enable() is still in the
> critical path. After that the focus looks to be upon speeding up
> modeset.
*not* doing modeset
On Thu, 15 Dec 2011 13:48:00 -0800, Scott James Remnant
wrote:
> This gives us a significant chunk of time back (>0.5s) - what would be
> the downside of carrying a revert to this patch?
It fails to light up some LVDS panels, causing machines to not be
usable.
That's generally what we've found
On Fri, 16 Dec 2011 17:38:39 +0100, tino.keitel+x...@tikei.de wrote:
> Hum, could this be related to the RC6 vs. IOMMU issue? I have
> CONFIG_INTEL_IOMMU enabled in 3.2, and disabled in 3.1, and boot with
> i915.i915_enable_rc6=1.
Very likely -- RC6 and semaphores are not compatible with IOMMU. Y
nt division by zero when asking for chipset power
iommu: Export intel_iommu_enabled to signal when iommu is in use
drm/i915: enable semaphores on per-device defaults
Jesse Barnes (1):
drm/i915: don't set unpin_work if vblank_get fails
Keith Packard (4):
drm/i915: add mu
...@lists.freedesktop.org
Cc: Daniel Vetter
Reported-by: Alex Villacís Lasso
Reported-by: Dirk Hohndel
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_gem.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915
On Wed, 21 Dec 2011 19:54:10 +0100, Udo Steinberg wrote:
> Hi,
>
> With Linux-3.2-rc6 I'm frequently seeing GPU hangs when large amounts of
> text scroll in an xterm, such as when extracting a tar archive. Such as this
> one (note the timestamps):
Can you try with semaphores disabled?
i915.sema
On Thu, 22 Dec 2011 01:28:36 +0100, Daniel Vetter
wrote:
> Half of the users actually don't want just no tracing, but need to
> avoid the forcewake dance for correctness. So add new variants
> __I915_READ and __I915_WRITE for that.
I'd sure like something more descriptive than '__' here. Perhaps
reproduce it fairly easily with something
> as simple as:
>
> while true; do dmesg; done
This patch turns them off on SNB while leaving them on for IVB.
Reported-by: Udo Steinberg
Cc: Daniel Vetter
Cc: Eugeni Dodonov
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_
On Fri, 23 Dec 2011 13:33:07 -0800, Keith Packard wrote:
> /* Enable semaphores on SNB when IO remapping is off */
Yeah, the comment is wrong now. I've updated this too:
- /* Enable semaphores on SNB when IO remapping is off */
+ /* Enable semaphores on SNB */
--
ke
On Mon, 26 Dec 2011 01:43:37 +0100, Kai Krakow wrote:
> I didn't have such issues with early 3.2 rcs (afair), and not with 3.1
> kernels. After some digging through google I've found you enabled RC6 in
> 3.2. I disabled it now, and my system runs wonderfully.
Argh. Can you try building a kerne
On Mon, 26 Dec 2011 03:43:22 +0100, Kai Krakow wrote:
> Keith Packard schrieb:
>
> > On Mon, 26 Dec 2011 01:43:37 +0100, Kai Krakow
> > wrote:
> >
> >> I didn't have such issues with early 3.2 rcs (afair), and not with 3.1
> >> kernels. After som
This leaves them enabled on IVB, but disables them on SNB as we've
discovered (yet again) that there are hardware combinations that
simply cannot run with them.
[PATCH 1/2] drm/i915: Disable semaphores by default on SNB
[PATCH 2/2] drm/i915: Disable RC6 on Sandybridge by default
--
keith.pack..
reproduce it fairly easily with something
> as simple as:
>
> while true; do dmesg; done
This patch turns them off on SNB while leaving them on for IVB.
Reported-by: Udo Steinberg
Cc: Daniel Vetter
Cc: Eugeni Dodonov
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_ge
, and my system runs wonderfully.
> The system is a Z68 Pro board with Sandybridge i5-2500K processor, 8
> GB of RAM and UEFI firmware.
Reported-by: Kai Krakow
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c |8 +++-
1 files changed, 3 insertions(+), 5 delet
On Mon, 26 Dec 2011 11:59:04 +0100, Kai Krakow wrote:
> > North Bridge Configuration:
> > VT-d
>
> This doesn't exist
That's odd. I don't understand all of the SNB CPU variations; perhaps
there's a desktop version that has VT-d fused out or something?
> If I should provide more info to ide
On Tue, 27 Dec 2011 04:18:21 +0100, Kai Krakow wrote:
> 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor
> ...
Thanks. I'll see about duplicating this system here so we can try and
make it work and still have RC6 enabled, either by fixing it for this
platform or figur
On Wed, 14 Dec 2011 13:57:03 +0100, Daniel Vetter
wrote:
> The problem this patch solves is that the forcewake accounting
> necessary for register reads is protected by dev->struct_mutex. But the
> hangcheck and error_capture code need to access registers without
> grabbing this mutex because we
On Tue, 3 Jan 2012 20:12:35 +0100, Daniel Vetter wrote:
> I'm a bit confused by this. With the current code forcewake is
> protected by dev->struct_mutex. Which doesn't work out because we need
> to access registers that require the forcewake dance from non-process
> context.
Right, I like addin
On Tue, 3 Jan 2012 22:49:52 +0100, Daniel Vetter wrote:
> Nope, current hangcheck blows up, and we have an i-g-t testcase for it
> (which the commit msg clearly states). There are also numerous bug
> reports where a dying gpu results in tons of
> WARN_ON(!mutex_locked(dev->struct_mutex)) noise in
On Wed, 4 Jan 2012 00:04:18 +0100, Daniel Vetter wrote:
> I kinda prefer Chris' approach of sticking with irqs, but backing it up
> with a timer in the msec range. Can't find that patch though atm (iirc
> it's in bugzilla somewhere).
I think we've resolved that the interrupt arrives, but that it
On Wed, 4 Jan 2012 18:02:21 +0100, Daniel Vetter wrote:
> So I really don't like the busy-looping, especially now that
> semaphores are enabled by default for ivb.
Alternatives are welcome; we have no other known fix for missing
sequence writes.
--
keith.pack...@intel.com
pgpHcsh2BtIKu.pgp
D
On Wed, 4 Jan 2012 18:11:18 +0100, Daniel Vetter wrote:
> Ah, I think I see you're concern: Between the time we reset the gpu
> and the time we fix up the forcewake state somebody might sneak in and
> see an inconstency between our tracking and the actual hw state, hence
> reading garbage. Correc
On Wed, 4 Jan 2012 19:12:57 +0100, Daniel Vetter wrote:
> The "Correct?" was just to check my understanding of your concern, I still
> think its invalid. You've cut away the second part of my mail where I
> explain why and I don't see you responding to that here. Also
> micro-optimizing the gpu r
On Wed, 4 Jan 2012 19:40:45 +0100, Daniel Vetter
wrote:
> Two things seem to do the trick on my ivb machine here:
> - prevent the gt from powering down while waiting for seqno
> notification interrupts by grabbing the force_wake in get_irq (and
> dropping it in put_irq again).
> - ordering
301 - 400 of 748 matches
Mail list logo
