On Tue, 10 Apr 2012 09:33:19 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
We've only computed whether we need to fall back to 6bpc due to dp
link bandwidth constrains in mode_valid, but not mode_fixup. Under
various circumstances X likes to create new modes which then lack
proper 6bpc
We've only computed whether we need to fall back to 6bpc due to dp
link bandwidth constrains in mode_valid, but not mode_fixup. Under
various circumstances X likes to create new modes which then lack
proper 6bpc flags (if required), resulting in mode_fixup failures and
ultimately black screens.
As part of the PCH split, the ability to control CRT standby/suspend
states was defeatured; the bits are now marked reserved and apparently
have no effect.
Reported-by: Ouping Zhang ouping.zh...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48491
Signed-off-by: Chris Wilson
We've only computed whether we need to fall back to 6bpc due to dp
link bandwidth constrains in mode_valid, but not mode_fixup. Under
various circumstances X likes to create new modes which then lack
proper 6bpc flags (if required), resulting in mode_fixup failures and
ultimately black screens.
On Tue, Apr 10, 2012 at 09:35:30AM +0100, Chris Wilson wrote:
As part of the PCH split, the ability to control CRT standby/suspend
states was defeatured; the bits are now marked reserved and apparently
have no effect.
Reported-by: Ouping Zhang ouping.zh...@intel.com
Bugzilla:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello everyone,
it looks like this does indeed fix the fbc problem. I applied the
patch, and did some testing. I am using a Dell Latitude e6420, this is
my setup:
brotscheibe brot # cat /sys/kernel/debug/dri/0/i915_fbc_status
FBC enabled
On Tue, 27 Mar 2012 18:59:39 -0700, Ben Widawsky b...@bwidawsk.net wrote:
Merge rc6 information into the power group for our device. Until now the
i915 driver has not had any sysfs entries (aside from the connector
stuff enabled by drm core). Since it seems like we're likely to have
more in
On Tue, Mar 27, 2012 at 06:59:38PM -0700, Ben Widawsky wrote:
RC6 residency should be in intervals of 1.28us, and the counter wraps.
Here is an example using awk to get the various RC6 and RC6+ residency
times in seconds, since boot.
cat /sys/kernel/debug/dri/0/i915_drpc_info | grep
Am Samstag, den 31.03.2012, 11:52 +0100 schrieb Chris Wilson:
On Sat, 31 Mar 2012 11:22:02 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
Note that async flush also means things like VT-d IOTLB invalidation.
See Bspec vol1c.4 Render Engine Command Streamer, Section ECOSKPD -
Eco
Am Samstag, den 31.03.2012, 11:21 +0200 schrieb Daniel Vetter:
According to an internal workaround master list, we need to set bit 5
of register 9400 to avoid issues with color blits.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_reg.h |3 +++
On Thu, Mar 22, 2012 at 03:10:00PM +, Chris Wilson wrote:
By simplifying the rules to calling get_fence when writing to the
through the GTT in a tiled manner, and calling put_fence before writing
to the object through the GTT in a linear manner, the code becomes
clearer and there is less
On Thu, Apr 05, 2012 at 02:47:36PM -0700, Ben Widawsky wrote:
In theory this will have performance and power improvements. Performance
because we don't need to stall when the scanout BO is busy, and power
because we don't have to stall when the BO is busy (and the ring can
even go to sleep if
On Fri, Apr 06, 2012 at 04:10:05PM -0700, Ben Widawsky wrote:
On Fri, 6 Apr 2012 16:07:56 -0700
Ben Widawsky b...@bwidawsk.net wrote:
On Fri, 6 Apr 2012 11:46:27 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
Just noticed this while verifying the VGA disable code.
Well, almost. Just a couple of differences, Ironlake lacks a few of the
RGB formats, only exposing x8r8g8b8, and lacks a couple of unused
features. Given the similarities, we can then reuse the same routines as
already written for Sandybridge to enable overlay support for Ironlake as
well.
Similar to allowing a buffer to be simultaneously read by the GPU and
through the GTT, we wish to allow readback of the pages through the CPU
domain whilst they are also being read by the GPU. Domain coherency
is managed by allowing multiple readers, but only a single writer.
This is used by mesa
Hi all,
The first patch in this series fixes a long-standing hdmi-on-sdvo regression -
we apparently have not set up the pixel doubling (or quadrupling) correctly.
This regression was introduced in 2.6.36. Now if this patch is indeed correct,
hdmi on sdvo (and _only_ hdmi) for any pixelclock
We seem to have a decent confusion between the output timings and the
input timings of the sdvo encoder. If I understand the code correctly,
we use the original mode unchanged for the output timings, safe for
the lvds case. And we should use the adjusted mode for input timings.
Clarify the
- kill intel_sdvo-input_dtd, it's only used as a temporary variable,
we store the preferred input mode in the adjusted mode at mode_fixup
time.
- rename the function to make it clear what we want it to do (get the
preferred mode) and say in a comment what it unfortunately does as a
Unfortunately we can't abort a mode_set, but at least tell the user
that something might have gone wrong when setting the sdvo input or
output timing fails.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_sdvo.c |8 ++--
1 files changed, 6
On Tue, 10 Apr 2012 13:55:47 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
- kill intel_sdvo-input_dtd, it's only used as a temporary variable,
we store the preferred input mode in the adjusted mode at mode_fixup
time.
- rename the function to make it clear what we want it to do (get
Over time we've added more and more workarounds in there for render
core issues, so these register settings will revert back to their
reset state. To avoid making a bad situation worse, re-run the clock
gating code after reset so that we don't crash right away with a known
hw issue.
On Tue, 10 Apr 2012 14:39:49 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
Over time we've added more and more workarounds in there for render
core issues, so these register settings will revert back to their
reset state. To avoid making a bad situation worse, re-run the clock
gating
On 4/10/12 4:35 AM, Chris Wilson wrote:
As part of the PCH split, the ability to control CRT standby/suspend
states was defeatured; the bits are now marked reserved and apparently
have no effect.
Are the intermediate states even tested? I have vague memories of them
not working. I'd be just
After a gpu reset we need to re-init some of the hw state we only
initialize when modeset is enabled, like rc6, hw contexts or render/GT
core clock gating and workaround register settings.
Note that this patch has a small change in the resume code:
- rc6 on gen6+ is only restored for the modeset
On 4/10/12 4:42 AM, Daniel Vetter wrote:
We've only computed whether we need to fall back to 6bpc due to dp
link bandwidth constrains in mode_valid, but not mode_fixup. Under
various circumstances X likes to create new modes which then lack
proper 6bpc flags (if required), resulting in
On Tue, 10 Apr 2012 15:50:11 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
After a gpu reset we need to re-init some of the hw state we only
initialize when modeset is enabled, like rc6, hw contexts or render/GT
core clock gating and workaround register settings.
Note that this patch
On Tue, 10 Apr 2012 09:20:38 -0400, Adam Jackson a...@redhat.com wrote:
On 4/10/12 4:35 AM, Chris Wilson wrote:
As part of the PCH split, the ability to control CRT standby/suspend
states was defeatured; the bits are now marked reserved and apparently
have no effect.
Are the intermediate
We don't need the pt_addr for the !dmar case, so drop the else and
move the if (dmar) condition out of the loop.
Noticed-by: Konstantin Belousov kostik...@gmail.com
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_gtt.c |7 +++
1 files changed, 3
On Tue, 10 Apr 2012 16:25:54 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
We don't need the pt_addr for the !dmar case, so drop the else and
move the if (dmar) condition out of the loop.
Noticed-by: Konstantin Belousov kostik...@gmail.com
Signed-Off-by: Daniel Vetter
We don't need the pt_addr for the !dmar case, so drop the else and
move the if (dmar) condition out of the loop.
v2: Fixup whitespace damage noticed by Chris Wilson.
Noticed-by: Konstantin Belousov kostik...@gmail.com
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
On Tue, 10 Apr 2012 17:04:35 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
We don't need the pt_addr for the !dmar case, so drop the else and
move the if (dmar) condition out of the loop.
v2: Fixup whitespace damage noticed by Chris Wilson.
Noticed-by: Konstantin Belousov
On Tue, 10 Apr 2012 17:29:17 +0200, daniel.vet...@ffwll.ch wrote:
From: Daniel Vetter daniel.vet...@ffwll.ch
We don't need the pt_addr for the !dmar case, so drop the else and
move the if (dmar) condition out of the loop.
v2: Fixup whitespace damage noticed by Chris Wilson.
v3: Collapse
On the first instance we just wish to kick the waiters and see if that
terminates the wait conditions. If it does not, then we do not want to
keep retrying without ever making any forward progress and becoming
stuck in a hangcheck loop.
Reported-and-tested-by: Lukas Hejtmanek xhejt...@fi.muni.cz
On Tue, 10 Apr 2012 13:55:46 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
We seem to have a decent confusion between the output timings and the
input timings of the sdvo encoder. If I understand the code correctly,
we use the original mode unchanged for the output timings, safe for
the
On Tue, Apr 10, 2012 at 09:17:37AM -0700, Jesse Barnes wrote:
On Tue, 10 Apr 2012 13:55:46 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
We seem to have a decent confusion between the output timings and the
input timings of the sdvo encoder. If I understand the code correctly,
we use
On Tue, 10 Apr 2012 18:36:49 +0200
Daniel Vetter dan...@ffwll.ch wrote:
Well, neither do I have a clue about sdvo, but I think I somewhat
self-consistent explanation for what's going on.
Sdvo seems to have two timings, one is the output timing which will be
sent over whatever is connected on
On Tue, 10 Apr 2012 11:41:49 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Well, almost. Just a couple of differences, Ironlake lacks a few of the
RGB formats, only exposing x8r8g8b8, and lacks a couple of unused
features. Given the similarities, we can then reuse the same routines as
We seem to have a decent confusion between the output timings and the
input timings of the sdvo encoder. If I understand the code correctly,
we use the original mode unchanged for the output timings, safe for
the lvds case. And we should use the adjusted mode for input timings.
Clarify the
On Tue, Apr 10, 2012 at 09:01:10AM -0700, Jesse Barnes wrote:
On Tue, 10 Apr 2012 11:41:49 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Well, almost. Just a couple of differences, Ironlake lacks a few of the
RGB formats, only exposing x8r8g8b8, and lacks a couple of unused
On Tue, Apr 10, 2012 at 09:46:53AM -0400, Adam Jackson wrote:
On 4/10/12 4:42 AM, Daniel Vetter wrote:
We've only computed whether we need to fall back to 6bpc due to dp
link bandwidth constrains in mode_valid, but not mode_fixup. Under
various circumstances X likes to create new modes which
#part sign=pgpmime
On Tue, 10 Apr 2012 09:46:53 -0400, Adam Jackson a...@redhat.com wrote:
Certainly an improvement.
Reviewed-by: Adam Jackson a...@redhat.com
I'd like to know if this actually helps someone before I stick it in
drm-intel-fixes...
--
keith.pack...@intel.com
#part sign=pgpmime
On Tue, 10 Apr 2012 09:20:38 -0400, Adam Jackson a...@redhat.com wrote:
On 4/10/12 4:35 AM, Chris Wilson wrote:
As part of the PCH split, the ability to control CRT standby/suspend
states was defeatured; the bits are now marked reserved and apparently
have no effect.
Designed to exercise this patch to i915.ko:
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fbf1118..57ae1f2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3181,9 +3181,11 @@ i915_gem_object_set_to_cpu_domain(struct
On 04/09/2012 09:10 PM, Ben Widawsky wrote:
From: bernard.r.kilarskiyour-user-n...@intel.com
Full disclosure: my IVB hangs on nexuiz both before, and after this patch, and
I haven't done any debug
This patch was given to me by Bernard, by way of Daniel. The patch came
with very little
On Tue, Apr 10, 2012 at 01:10, Ben Widawsky b...@bwidawsk.net wrote:
+#define GEN7_FF_THREAD_MODE0x20a0
+#define GEN7_FF_THREAD_SIMPLE_SCHED0x28a00010
Would it be too much asking you to check with the 0x28a0 value as well
please, and with a patch which only cleans the bit
If these regs don't have valid values, the panel won't come up, and may
even cause a system hang. So do a basic sanity check when an eDP panel
is detected.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c |7 +++
1 files changed, 7 insertions(+),
Both PCH and CPU eDP are DP, so set the is_dp flag to true. Add
is_cpu_edp and is_pch_edp bools to make checking for each less verbose
(rather than has_edp_encoder !intel_encoder_is_pch_edp() sprinkled
everywhere). And rename the has_edp_encoder variable to just
edp_encoder.
With the above
On IVB, there are two sets of panel backlight regs: one in the CPU and
one in the PCH. The CPU ones aren't generally used, so on IVB make sure
we allow the PCH regs to actually control the backlight.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_panel.c |
On Tue, 10 Apr 2012 11:58:04 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
If these regs don't have valid values, the panel won't come up, and may
even cause a system hang. So do a basic sanity check when an eDP panel
is detected.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
On Tue, Apr 10, 2012 at 11:38:32AM -0700, Kenneth Graunke wrote:
On 04/09/2012 09:10 PM, Ben Widawsky wrote:
From: bernard.r.kilarskiyour-user-n...@intel.com
Full disclosure: my IVB hangs on nexuiz both before, and after this patch,
and
I haven't done any debug
This patch was given to
On Tue, 10 Apr 2012 11:58:03 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Both PCH and CPU eDP are DP, so set the is_dp flag to true. Add
is_cpu_edp and is_pch_edp bools to make checking for each less verbose
(rather than has_edp_encoder !intel_encoder_is_pch_edp() sprinkled
On Tue, 10 Apr 2012 11:58:04 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
If these regs don't have valid values, the panel won't come up, and may
even cause a system hang. So do a basic sanity check when an eDP panel
is detected.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
On Sat, Mar 31, 2012 at 11:21:58AM +0200, Daniel Vetter wrote:
Contrary to the other clock gating w/a in GEN6_UCGCTL1, this one is
actually documented in Bspec, vol1g GT Interface Registers [SNB],
Section 1.5.1 UCGCTL1 - Unit Level Clock Gating Control 1.
Supposedly this can prevent hangs on
On Tue, 10 Apr 2012 11:52:50 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Similar to allowing a buffer to be simultaneously read by the GPU and
through the GTT, we wish to allow readback of the pages through the CPU
domain whilst they are also being read by the GPU. Domain coherency
is
On Sat, Mar 31, 2012 at 11:21:58AM +0200, Daniel Vetter wrote:
Contrary to the other clock gating w/a in GEN6_UCGCTL1, this one is
actually documented in Bspec, vol1g GT Interface Registers [SNB],
Section 1.5.1 UCGCTL1 - Unit Level Clock Gating Control 1.
Supposedly this can prevent hangs on
On Sat, Mar 31, 2012 at 11:21:59AM +0200, Daniel Vetter wrote:
Bspec says that we need to set this: vol1c.3 Blitter Command
Streamer, Section 1.1.2.1 GAB_CTL_REG - GAB Unit Control Register.
We don't really rely on pagefaults, but who knows what this all
affects.
Signed-Off-by: Daniel
On Tue, Apr 10, 2012 at 11:58:05AM -0700, Jesse Barnes wrote:
On IVB, there are two sets of panel backlight regs: one in the CPU and
one in the PCH. The CPU ones aren't generally used, so on IVB make sure
we allow the PCH regs to actually control the backlight.
Signed-off-by: Jesse Barnes
On Tue, 10 Apr 2012 23:50:45 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Apr 10, 2012 at 11:58:05AM -0700, Jesse Barnes wrote:
On IVB, there are two sets of panel backlight regs: one in the CPU and
one in the PCH. The CPU ones aren't generally used, so on IVB make sure
we allow the
On Sat, Mar 31, 2012 at 11:22:00AM +0200, Daniel Vetter wrote:
For some reason snb has 2 fields to set ppgtt cacheability. This one
here does not exist on gen7.
This might explain why ppgtt wasn't a win on snb like on ivb - not
enough pte caching.
So, is it a win now?
Signed-Off-by:
On Sat, Mar 31, 2012 at 11:22:01AM +0200, Daniel Vetter wrote:
According to Bsepc, this should be set by default, but isn't. See vo1c.4
Render Engine Command Streamer, Section 1.1.14.3 3D_CHICKEN3
Bspec also says that we always need to set all mask bits.
I think this deserves to be a comment
On Tue, Apr 10, 2012 at 03:13:52PM -0700, Ben Widawsky wrote:
On Sat, Mar 31, 2012 at 11:22:01AM +0200, Daniel Vetter wrote:
According to Bsepc, this should be set by default, but isn't. See vo1c.4
Render Engine Command Streamer, Section 1.1.14.3 3D_CHICKEN3
Bspec also says that we
On Sat, Mar 31, 2012 at 11:22:02AM +0200, Daniel Vetter wrote:
Note that async flush also means things like VT-d IOTLB invalidation.
See Bspec vol1c.4 Render Engine Command Streamer, Section ECOSKPD -
Eco Scratch Pad.
It doesn't seem to help in for any of our VT-d related bugs thoug.
On Sat, Mar 31, 2012 at 11:21:57AM +0200, Daniel Vetter wrote:
According to an internal workaround master list, we need to set bit 5
of register 9400 to avoid issues with color blits.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
I'm having a lot of trouble actually tracking this one
On Tue, Apr 10, 2012 at 03:11:07PM -0700, Ben Widawsky wrote:
On Sat, Mar 31, 2012 at 11:22:00AM +0200, Daniel Vetter wrote:
For some reason snb has 2 fields to set ppgtt cacheability. This one
here does not exist on gen7.
This might explain why ppgtt wasn't a win on snb like on ivb -
On Sat, Mar 31, 2012 at 11:22:03AM +0200, Daniel Vetter wrote:
Our workaround list kindly lists that this new default value needs to
be updated in Bspec. Naturally, this did not happen.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
Since the bspec says nothing, I think we need to do
On Wed, Apr 11, 2012 at 12:27:25AM +0200, Daniel Vetter wrote:
On Tue, Apr 10, 2012 at 03:11:07PM -0700, Ben Widawsky wrote:
On Sat, Mar 31, 2012 at 11:22:00AM +0200, Daniel Vetter wrote:
For some reason snb has 2 fields to set ppgtt cacheability. This one
here does not exist on gen7.
On Tue, Apr 10, 2012 at 07:13:59PM +0200, Daniel Vetter wrote:
Reported-and-Tested-by: Bernard Blackham b-linux...@largestprime.net
This tested-by is actually a lie, I've mixed up a few bug reports. Bug
reporter is currently on vacation and will test this stuff in 2 weeks.
-Daniel
Bugzilla:
On Tue, 10 Apr 2012 17:00:41 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On the first instance we just wish to kick the waiters and see if that
terminates the wait conditions. If it does not, then we do not want to
keep retrying without ever making any forward progress and becoming
Hi all,
We finished a new round of kernel testing. The version of kernel is:
Kernel: (drm-intel-testing)9d0b5b5468650e0ac72a7786cf6625963f926d4d
Merge: ec34a01 b4db1e3
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Mon Apr 9 18:12:03 2012 +0200
We covered the platform IvyBridge,
Merge rc6 information into the power group for our device. Until now the
i915 driver has not had any sysfs entries (aside from the connector
stuff enabled by drm core). Since it seems like we're likely to have
more in the future I created a new file for sysfs stubs, as well as the
rc6 sysfs
70 matches
Mail list logo
