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 functio
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
Date: Mon Apr 9 18:12:03 2012 +0200
We covered the platform IvyBridge, SandyBridge, IronLake, G45 and Pi
On Tue, 10 Apr 2012 17:00:41 +0100
Chris Wilson 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
> stuck in a hangcheck loo
On Tue, Apr 10, 2012 at 07:13:59PM +0200, Daniel Vetter wrote:
> Reported-and-Tested-by: Bernard Blackham
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: https://bugs.freedesktop.org
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 g
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
Since the bspec says nothing, I think we need to do some performance
test
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
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
I'm having a lot of trouble actually tracking this one down in something
ot
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 tho
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 t
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 c
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-
On Tue, 10 Apr 2012 23:50:45 +0200
Daniel Vetter 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 PCH regs
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 Barn
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:
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
On Tue, 10 Apr 2012 11:52:50 +0100, Chris Wilson
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 managed by allowing
On Tue, Apr 10, 2012 at 02:30:20PM -0700, Ben Widawsky wrote:
> 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 -
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
On Tue, 10 Apr 2012 11:58:04 -0700, Jesse Barnes
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
Other than adding a cleanup: error path (de
On Tue, 10 Apr 2012 11:58:03 -0700, Jesse Barnes
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
> everywhere). And rename th
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.kilarski"
> >
> >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 Ber
On Tue, 10 Apr 2012 11:58:04 -0700
Jesse Barnes 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
> ---
> drivers/gpu/drm/i915/intel_dp.c |
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
---
drivers/gpu/drm/i915/intel_panel.c | 12
1 files
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 abov
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
---
drivers/gpu/drm/i915/intel_dp.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --gi
On Tue, Apr 10, 2012 at 01:10, Ben Widawsky 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 12 and 4?
I thi
On 04/09/2012 09:10 PM, Ben Widawsky wrote:
From: "bernard.r.kilarski"
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 description, and I haven't real
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 drm_i
<#part sign=pgpmime>
On Tue, 10 Apr 2012 09:20:38 -0400, Adam Jackson 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 th
<#part sign=pgpmime>
On Tue, 10 Apr 2012 09:46:53 -0400, Adam Jackson wrote:
> Certainly an improvement.
>
> Reviewed-by: Adam Jackson
I'd like to know if this actually helps someone before I stick it in
drm-intel-fixes...
--
keith.pack...@intel.com
__
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 w
On Tue, Apr 10, 2012 at 09:01:10AM -0700, Jesse Barnes wrote:
> On Tue, 10 Apr 2012 11:41:49 +0100
> Chris Wilson 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 simi
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 situati
On Tue, 10 Apr 2012 11:41:49 +0100
Chris Wilson 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
> already written for San
On Tue, 10 Apr 2012 18:36:49 +0200
Daniel Vetter 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 the other
On Tue, Apr 10, 2012 at 09:17:37AM -0700, Jesse Barnes wrote:
> On Tue, 10 Apr 2012 13:55:46 +0200
> Daniel Vetter 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
On Tue, 10 Apr 2012 13:55:46 +0200
Daniel Vetter 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 lvds case. And we sh
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
Bugzilla: https://bu
On Tue, 10 Apr 2012 17:29:17 +0200, daniel.vet...@ffwll.ch wrote:
> From: 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.
>
> v3: Collapse the two identi
From: 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.
v3: Collapse the two identical if blocks. Chris Wilson makes me look
like a moron right now ...
Noticed-by:
On Tue, 10 Apr 2012 17:04:35 +0200, Daniel Vetter
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
> Signed-Off-by: Daniel Vet
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
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +-
1 files
On Tue, 10 Apr 2012 16:25:54 +0200, Daniel Vetter
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
> Signed-Off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c |7 +
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
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_gtt.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/dr
On Tue, 10 Apr 2012 09:20:38 -0400, Adam Jackson 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 states
On Tue, 10 Apr 2012 15:50:11 +0200, Daniel Vetter
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 has a small change
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 c
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 mode_fixup
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 c
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
On Tue, 10 Apr 2012 14:39:49 +0200, Daniel Vetter
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 code after reset so th
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.
Signed-Off-by:
On Tue, 10 Apr 2012 13:55:47 +0200, Daniel Vetter
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 the
> preferred
We round-trip quite often from sdvo dtd timings through drm mode back
to sdvo dtd timings, e.g. due to mode_fixup. Add an informational
message that tells us when we lose things on the way.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_sdvo.c |5 +
1 files changed, 5 insert
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
---
drivers/gpu/drm/i915/intel_sdvo.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff
- 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
side-ef
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 situati
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 below
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
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.
Signed-
On Fri, Apr 06, 2012 at 04:10:05PM -0700, Ben Widawsky wrote:
> On Fri, 6 Apr 2012 16:07:56 -0700
> Ben Widawsky wrote:
>
> > On Fri, 6 Apr 2012 11:46:27 -0700
> > Jesse Barnes wrote:
> >
> > > Just noticed this while verifying the VGA disable code.
> > >
> > > Signed-off-by: Jesse Barnes
>
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
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 les
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
> ---
> drivers/gpu/drm/i915/i915_reg.h |3 +++
> drivers/gpu/drm/
Am Samstag, den 31.03.2012, 11:52 +0100 schrieb Chris Wilson:
> On Sat, 31 Mar 2012 11:22:02 +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"
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 res
On Tue, 27 Mar 2012 18:59:39 -0700, Ben Widawsky 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 the future I cre
-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
brotscheib
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
> Bugzilla: https://bugs.freedesktop.org/sh
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.
Ch
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
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48491
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915
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.
Ch
On Tue, 10 Apr 2012 09:33:19 +0200, 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),
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.
Th
75 matches
Mail list logo
