Re: [Intel-gfx] [PATCH 1/2] drm/i915: simplify pipe checking
On Mon, Jan 16, 2012 at 21:28, Daniel Vetter dan...@ffwll.ch wrote: On Sun, Jan 08, 2012 at 03:01:12AM +0100, Cyril Brulebois wrote: Eugeni Dodonov eugeni.dodo...@intel.com (07/01/2012): This is also handled by i915_reg.h, so just reuse this trick to reduce universe enthropy. entropy. Besides that: Reviewed-by: Cyril Brulebois k...@debian.org Both patches queued for -next, thanks. I've botched my cross-checking with Keith's -fixes, these two are already there. Dropped them from my queue. -Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check that plane/pipe is disabled before removing the fb
On Mon, Jan 16, 2012 at 11:01:13PM +, Chris Wilson wrote:
Staring at an error state such as:
PGTBL_ER: 0x0400
Display B: Invalid tiling
fence[0] = 05001001
valid, x-tiled, pitch: 512, start: 0x0500, size: 1048576
Pinned [2]:
131072 0001 0001 P uncached
0002 4096000 0041 P uncached (name: 1)
Plane [1]:
CNTR: c000 # enabled | gamma
STRIDE: 1400
SIZE: 03ff04ff
POS:
ADDR: 0500
Suggests that we did not clear the DSPBCNTR prior to unpinning the
framebuffer and reusing the GTT space. Impossible! Unless our DPMS
bookkeeping ran afoul again...
In the meantime add an assertion that the plane is decoupled from the
framebuffer prior to release.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Acked-by: Jesse Barnes jbar...@virtuousgeek.org
Cc: Daniel Vetter dan...@ffwll.ch
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [RFC] drm/i915: read-read semaphore optimization
On Mon, Jan 16, 2012 at 02:20:55PM -0800, Ben Widawsky wrote: On 01/16/2012 01:50 PM, Daniel Vetter wrote: On Tue, Dec 13, 2011 at 10:36:15AM -0800, Ben Widawsky wrote: On 12/13/2011 09:22 AM, Eric Anholt wrote: On Mon, 12 Dec 2011 19:52:08 -0800, Ben Widawskyb...@bwidawsk.net wrote: Since we don't differentiate on the different GPU read domains, it should be safe to allow back to back reads to occur without issuing a wait (or flush in the non-semaphore case). This has the unfortunate side effect that we need to keep track of all the outstanding buffer reads so that we can synchronize on a write, to another ring (since we don't know which read finishes first). In other words, the code is quite simple for two rings, but gets more tricky for 2 rings. Here is a picture of the solution to the above problem Ring 0Ring 1 Ring 2 batch 0 batch 1batch 2 read buffer A read buffer A wait batch 0 wait batch 1 write buffer A This code is really untested. I'm hoping for some feedback if this is worth cleaning up, and testing more thoroughly. You say it's an optimization -- do you have performance numbers? 33% improvement on a hacked version of gem_ring_sync_loop with. It's not really a valid test as it's not coherent, but this is approximately the best case improvement. Oddly semaphores doesn't make much difference in this test, which was surprising. Our domain tracking is already complicated in unfunny ways. And (at least without a use-case showing gains with hard numbers in either perf or power usage) I think this patch is the kind of this looks cool stuff that added a lot to the current problem. So before adding more complexity on top I'd like to remove some of the superflous stuff we already have. I.e. all the flushing_list stuff and maybe other things ... Can you be more clear on what exactly you want done before taking a patch like this? Maybe I can work on it during some down time. I was thinking about Eric's no-more-domains stuff specifically, which has tons of natural split-points - and we want to exploit these for merging. Imo step 1 would be to just rework the batch dispatch in intel_ringbuffer.c so that we unconditionally invalidate before and flush afterwards. The ring-flush would become a no-op. No changes to the core flushing_list tracking for step 1. If we can get this in for 3.4 we could (in the -next merge cycle) walk all the callchains from their ends and rip out everything which is a no-op, starting from ring-flush. I think that's the safest way to attack this. Eric? Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: set AUD_CONFIG N_value_index for DisplayPort
On Tue, Jan 17, 2012 at 07:08:09AM +0800, Wu Fengguang wrote:
On Mon, Jan 16, 2012 at 12:44:43PM -0800, Keith Packard wrote:
On Mon, 16 Jan 2012 21:26:18 +0100, Daniel Vetter dan...@ffwll.ch wrote:
Keith, does this address your concern and this patch is r-b: Keith or do
we want an
} else {
I915_WRITE(aud_config, 0);
}
for paranoia?
I think we want this added, just to be sure we set the configuration
correctly in all cases; it's easy to imagine moving from DP to HDMI and
leaving this bit set.
Ah good point! Here is the updated patch.
---
Subject: drm/i915: set AUD_CONFIG N_value_index for DisplayPort
Date: Fri Jan 06 14:41:31 CST 2012
It should be programmed to 0 for HDMI or 1 for DisplayPort.
This enables DisplayPort audio for
- HP EliteBook 8460p
(whose BIOS does not set the N_value_index bit for us)
- DisplayPort monitor hot plugged after boot
(otherwise most BIOS will fill the N_value_index bit for us)
Tested-by: Robert Lemaire rlema...@suse.com
Signed-off-by: Wu Fengguang fengguang...@intel.com
I've tried to apply this patch but it has a conflict in i915_reg.h (with
the SOL reset stuff). Care to rebase and resend? Also, git patches as
produced by git format-patch highly preferred.
Thanks, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drivers: i915: Default backlight PWM frequency
On Tue, Nov 15, 2011 at 07:47:58PM +0100, Takashi Iwai wrote:
At Fri, 11 Nov 2011 14:12:58 -0800,
Simon Que wrote:
If the firmware did not initialize the backlight PWM registers, set up a
default PWM frequency of 200 Hz. This is determined using the following
formula:
freq = refclk / (128 * pwm_max)
The PWM register allows the max PWM value to be set. So we want to use
the formula, where freq = 200:
pwm_max = refclk / (128 * freq)
This patch will, in the case of missing PWM register initialization
values, look for the reference clock frequency. Based on that, it sets
an appropriate max PWM value for a frequency of 200 Hz.
If no refclk frequency is found, the max PWM will be zero, which results
in no change to the PWM registers.
Signed-off-by: Simon Que s...@chromium.org
---
drivers/gpu/drm/i915/intel_panel.c | 38
++-
1 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index f15388c..dda5de2 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -32,6 +32,12 @@
#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
+/* These are used to calculate a reasonable default when firmware has not
+ * configured a maximum PWM frequency, with 200Hz as the current default
target.
+ */
+#define DEFAULT_BACKLIGHT_PWM_FREQ 200
+#define BACKLIGHT_REFCLK_DIVISOR 128
+
void
intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
@@ -129,12 +135,32 @@ static int is_backlight_combination_mode(struct
drm_device *dev)
return 0;
}
+static void i915_set_default_max_backlight(struct drm_i915_private
*dev_priv)
+{
+ u32 refclk_freq_mhz = 0;
+ u32 max_pwm;
+
+ if (HAS_PCH_SPLIT(dev_priv-dev))
+ refclk_freq_mhz = I915_READ(PCH_RAWCLK_FREQ) RAWCLK_FREQ_MASK;
+ else if (dev_priv-lvds_use_ssc)
+ refclk_freq_mhz = dev_priv-lvds_ssc_freq;
+
+ max_pwm = refclk_freq_mhz * 100 /
+ (BACKLIGHT_REFCLK_DIVISOR * DEFAULT_BACKLIGHT_PWM_FREQ);
+
+ if (HAS_PCH_SPLIT(dev_priv-dev))
+ dev_priv-saveBLC_PWM_CTL2 = max_pwm 16;
+ else if (IS_PINEVIEW(dev_priv-dev))
+ dev_priv-saveBLC_PWM_CTL = max_pwm 17;
+ else
+ dev_priv-saveBLC_PWM_CTL = max_pwm 16;
Is the pineview case really correct?
The special handling for pineview in some places in intel_panel.c is
just for omitting the bit 0, IIRC. It doesn't mean that the value is
twice larger.
BTW, this handling of bit 0 seems necessary not only for pineview but
for the older chips (gen 4) in general, too, as being discussed in
another thread of LKML. 915GM hits the with problem of bit-0, for
example.
Do we still need this patch? If so, can you please address Takashi's
comment, on a quick check he seems to have a point.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drivers: i915: Fix BLC PWM register setup
On Thu, Nov 10, 2011 at 05:50:26PM -0800, Simon Que wrote: There is an error in i915_read_blc_pwm_ctl, where the register values are not being copied correctly. BLC_PWM_CTL and BLC_PWM_CTL2 are getting mixed up. This patch fixes that so that saveBLC_PWM_CTL2 and not saveBLC_PWM_CTL is copied to the BLC_PWM_CTL2 register. Signed-off-by: Simon Que s...@chromium.org Patch 1 here looks good to me.Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Force synchronous TLB invalidations on the BLT ring for SNB+
On Wed, Nov 09, 2011 at 12:17:06PM -0800, Eric Anholt wrote: On Wed, 09 Nov 2011 19:15:06 +, Chris Wilson ch...@chris-wilson.co.uk wrote: On Wed, 09 Nov 2011 10:57:00 -0800, Eric Anholt e...@anholt.net wrote: On Wed, 9 Nov 2011 17:32:26 +, Chris Wilson ch...@chris-wilson.co.uk wrote: We are advised that in order to workaround the TLB invalidation being performed asynchronously with the command streamer that we need to use a post-sync write along with the invalidations in the MI_FLUSH_DW so that all operations are complete before executing the next command in the ringbuffer. References: https://bugs.freedesktop.org/show_bug.cgi?id=37990 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Jesse Barnes jbar...@virtuousgeek.org I find the References: to a bug that this is not confirmed to fix to be very misleading. Because it references a bug I think is due to TLB invalidations as the glitches look very similar to earlier TLB invalidation. That sort of context included with the bz reference would make me feel more comfortable. What's the status of this patch? If you resend can you clarify the bugzilla reference and also include a Bspec/PRM/whatever citation for this workaround? Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915:: Disable FBC on SandyBridge
On Tue, Nov 08, 2011 at 11:17:34PM +, Chris Wilson wrote:
Enabling FBC is causing the BLT ring to run between 10-100x slower than
normal and frequently lockup. The interim solution is disable FBC once
more until we know why.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Iirc fbc isn't really worth it power-wise on snb and we don't implement it on
ivb. So shouldn't we just disable it completely? Eugeni, any opinions - I
think you're most up to speed on power saving figures for snb?
-Daniel
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9fa342e..f972a09 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1864,7 +1864,7 @@ static void intel_update_fbc(struct drm_device *dev)
if (enable_fbc 0) {
DRM_DEBUG_KMS(fbc set to per-chip default\n);
enable_fbc = 1;
- if (INTEL_INFO(dev)-gen = 5)
+ if (INTEL_INFO(dev)-gen = 6)
enable_fbc = 0;
}
if (!enable_fbc) {
--
1.7.7.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: kill i915_mem.c
On Tue, Jan 17, 2012 at 10:45 AM, Keith Whitwell kei...@vmware.com wrote: On Mon, 2012-01-16 at 21:56 +0100, Daniel Vetter wrote: On Thu, Dec 22, 2011 at 10:23:14PM +0100, Daniel Vetter wrote: Some decent history digging indicates that this was to be used for the GLX_MESA_allocate_memory extension but never actually implemented for any released i915 userspace code. So just rip it out. Cc: Dave Airlie airl...@gmail.com Cc: Keith Whitwell kei...@vmware.com Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Can some bored soul take a look at this and do the history double-checking? And maybe notice that the Makefile change is missing ... /me would like to kill this cruft All sounds good to me, kill it with fire. I've never known this code to be used in anything. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Mask the ring-head offset using the ring-size
On Tue, Nov 08, 2011 at 11:13:12PM +, Chris Wilson wrote: Rather than relying on the hardware to do this correctly, we can trivially do it ourselves. This fixes a very reliable crash on d-i-n with all bits enabled during a cairo-trace replay. The symptoms of the crash is that we continue to write commands into the render ring buffer past the active head position, leading to undefined operations. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: sta...@kernel.org I guess this is just the usual snb doesn't like being pushed to hard bug resulting in random crashes with confusing error_states. So I think I'll drop this. Correct? -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [RFC] drm/i915: Warning when reads or writes are dropped
On Fri, Nov 04, 2011 at 05:03:54PM -0700, Ben Widawsky wrote: The GTFIFODBG register gives us 3 error types when the fifo is accessed and full. Whenever we do a forcewake_put we can check this register to see if any of the CPU related errors occurred. Of more interest is perhaps the bit I am not checking which tells when some other part of the chip makes a request and the FIFO is full. I couldn't really decide on a good place to put that check. This patch seems to have value to me, but I'm not sure it's worth the cost of the extra MMIO read`. (I've yet to see this occur, but I haven't actually been running with it for very long). This looks like a nice little patch here. Care to update it for spinlocked and multithreaded forcewake and maybe also check the other errors? And also add it to the error_state output (just base it on top of danvet/my-next to avoid conflicts with the oustanding error_state cleanup). Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Mask the ring-head offset using the ring-size
On Tue, 17 Jan 2012 11:59:27 +0100, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Nov 08, 2011 at 11:13:12PM +, Chris Wilson wrote: Rather than relying on the hardware to do this correctly, we can trivially do it ourselves. This fixes a very reliable crash on d-i-n with all bits enabled during a cairo-trace replay. The symptoms of the crash is that we continue to write commands into the render ring buffer past the active head position, leading to undefined operations. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: sta...@kernel.org I guess this is just the usual snb doesn't like being pushed to hard bug resulting in random crashes with confusing error_states. So I think I'll drop this. Correct? I could find no other reason for this to have any effect other than the hw not playing fair so don't apply it until some one else starts experiencing random hangs on their SNB and can confirm whether this patch helps. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Fix recursive calls to unmap
On Thu, Nov 03, 2011 at 03:23:39PM -0700, Ben Widawsky wrote: On Thu, 3 Nov 2011 20:19:23 + Dave Airlie airl...@gmail.com wrote: The solution here is to add a new flag to the call chain which gives the routines the information they need to possibly defer actions which may cause us to recurse. A macro has been defined to replace i915_gpu_idle which defaults to the old behavior. Kudos to Chris for tracking this one down. So this fixes the non-VTd case, the VT-d case still hits a recursion here, for posterity its below. Okay I take that back, I got my EL6 kernel rock stable with the correct blend of backported bits. So ignore that backtrace, however I did get another IOMMU hang on my upstream kernel with gem_linear_blits, so this should be fine to merge but I'm guessing we have more debugging to do on the VT-d cases. Dave. Does it pass your original failing case? Hi Ben, Is v3 of this patch the right one to merge or do we still have some outstanding issues on this? Also, have you looked at the recent ilk dmar fallout, I think strict dmar iotlb flushing doesn't sit too well with our gpus. My snb dies almost immediately with that (even when I do not enable rc6 nor semaphores). Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915:: Disable FBC on SandyBridge
On Tue, 17 Jan 2012 11:57:05 +0100, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Nov 08, 2011 at 11:17:34PM +, Chris Wilson wrote: Enabling FBC is causing the BLT ring to run between 10-100x slower than normal and frequently lockup. The interim solution is disable FBC once more until we know why. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Iirc fbc isn't really worth it power-wise on snb and we don't implement it on ivb. So shouldn't we just disable it completely? Eugeni, any opinions - I think you're most up to speed on power saving figures for snb? Also note that I've had a couple of people confirm this bug and tested the patch on IRC. Doesn't help explain precisely what is wrong nor if there is a better workaround amidst the chicken bits that we've missed. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Enable FBC on IVB architecture.
On Thu, Oct 20, 2011 at 03:15:09PM -0200, Eugeni Dodonov wrote:
This is mostly similar to Ironlake, with some register changes and
additional tricks.
Jesse mentioned that it would make more sense to move those bits into
ivb-specific functions instead of making this work within ironlake ones,
so I added the corresponding functions and setup their pointers
accordingly.
v2: Now the correct patch.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
Anyone got an opinion on whether this is worth it power-consumption wise?
fbc has been a bit of a disaster and we have it disabled almost everywhere
...
-Daniel
---
drivers/gpu/drm/i915/i915_drv.c |2 +-
drivers/gpu/drm/i915/i915_reg.h | 14 ++
drivers/gpu/drm/i915/intel_display.c | 83 -
3 files changed, 95 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f07e425..a4300b7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -233,7 +233,7 @@ static const struct intel_device_info
intel_ivybridge_d_info = {
static const struct intel_device_info intel_ivybridge_m_info = {
.is_ivybridge = 1, .gen = 7, .is_mobile = 1,
.need_gfx_hws = 1, .has_hotplug = 1,
- .has_fbc = 0, /* FBC is not enabled on Ivybridge mobile yet */
+ .has_fbc = 1, /* Attempt at enabling FBC on IvyBridge mobile */
.has_bsd_ring = 1,
.has_blt_ring = 1,
};
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 542453f..4d1ce26 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -627,6 +627,7 @@
#define ILK_DISPLAY_CHICKEN1 0x42000
#define ILK_FBCQ_DIS (122)
#define ILK_PABSTRETCH_DIS (121)
+#define IVB_DPR_VS_FBCQ_DIS(122)
/*
@@ -638,6 +639,19 @@
#define SNB_CPU_FENCE_ENABLE (129)
#define DPFC_CPU_FENCE_OFFSET0x100104
+/*
+ * Framebuffer compression for IVB
+ *
+ * Mostly similar to ILK with some changes
+ */
+
+#define IVB_RESERVED (0x0F00)
+
+/* Controlled via ILK_DPFC_CONTROL */
+#define IVB_FBC_CTL_PLANEA (029)
+#define IVB_FBC_CTL_PLANEB (129)
+#define IVB_FBC_CTL_PLANEC (229)
+#define IVB_FBC_CPU_FENCE_ENABLE (128)
/*
* GPIO regs
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 04411ad..de77249 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1657,6 +1657,77 @@ static bool ironlake_fbc_enabled(struct drm_device
*dev)
return I915_READ(ILK_DPFC_CONTROL) DPFC_CTL_EN;
}
+static void ivb_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_framebuffer *fb = crtc-fb;
+ struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb-obj;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ unsigned long stall_watermark = 200;
+ u32 dpfc_ctl;
+
+ dpfc_ctl = I915_READ(ILK_DPFC_CONTROL);
+ dpfc_ctl = IVB_RESERVED;
+ /* Workarounds */
+ I915_WRITE(ILK_DISPLAY_CHICKEN1,
+ I915_READ(ILK_DISPLAY_CHICKEN1) |
+ IVB_DPR_VS_FBCQ_DIS);
+ I915_WRITE(ILK_DSPCLK_GATE,
+ I915_READ(ILK_DSPCLK_GATE) |
+ ILK_DPFC_DIS2 |
+ ILK_CLK_FBC);
+ /* IVL has 3 pipes */
+ switch (intel_crtc-plane) {
+ case 0:
+ dpfc_ctl |= IVB_FBC_CTL_PLANEA;
+ break;
+ case 1:
+ dpfc_ctl |= IVB_FBC_CTL_PLANEB;
+ break;
+ case 2:
+ dpfc_ctl |= IVB_FBC_CTL_PLANEC;
+ break;
+ }
+ /* fence enablement */
+ dpfc_ctl |= (IVB_FBC_CPU_FENCE_ENABLE | obj-fence_reg);
+ dpfc_ctl |= DPFC_CTL_LIMIT_1X;
+ I915_WRITE(ILK_DPFC_CHICKEN, DPFC_HT_MODIFY);
+
+ I915_WRITE(ILK_DPFC_RECOMP_CTL, DPFC_RECOMP_STALL_EN |
+(stall_watermark DPFC_RECOMP_STALL_WM_SHIFT) |
+(interval DPFC_RECOMP_TIMER_COUNT_SHIFT));
+ I915_WRITE(ILK_DPFC_FENCE_YOFF, crtc-y);
+ I915_WRITE(ILK_FBC_RT_BASE, obj-gtt_offset | ILK_FBC_RT_VALID);
+ /* enable it... */
+ I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
+
+ DRM_DEBUG_KMS(enabled fbc on plane %d\n, intel_crtc-plane);
+}
+
+static void ivb_disable_fbc(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 dpfc_ctl;
+
+ /* Disable compression */
+ dpfc_ctl = I915_READ(ILK_DPFC_CONTROL);
+ if (dpfc_ctl DPFC_CTL_EN) {
+ dpfc_ctl =
Re: [Intel-gfx] [PATCH] [RFC] drm/i915: Warning when reads or writes are dropped
On Tue, 17 Jan 2012 12:08:57 +0100, Daniel Vetter dan...@ffwll.ch wrote: On Fri, Nov 04, 2011 at 05:03:54PM -0700, Ben Widawsky wrote: The GTFIFODBG register gives us 3 error types when the fifo is accessed and full. Whenever we do a forcewake_put we can check this register to see if any of the CPU related errors occurred. Of more interest is perhaps the bit I am not checking which tells when some other part of the chip makes a request and the FIFO is full. I couldn't really decide on a good place to put that check. This patch seems to have value to me, but I'm not sure it's worth the cost of the extra MMIO read`. (I've yet to see this occur, but I haven't actually been running with it for very long). This looks like a nice little patch here. Care to update it for spinlocked and multithreaded forcewake and maybe also check the other errors? And also add it to the error_state output (just base it on top of danvet/my-next to avoid conflicts with the oustanding error_state cleanup). The advantage of placing the warning in _put is that we could identify the sequence of register writes that trigger the error, so a stack trace would be more useful i.e. a WARN instead. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: kill i915_mem.c
Some decent history digging indicates that this was to be used for the
GLX_MESA_allocate_memory extension but never actually implemented for
any released i915 userspace code.
So just rip it out.
v2: Fixup the Makefile.
Acked-by: Dave Airlie airl...@gmail.com
Cc: Keith Whitwell kei...@vmware.com
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_ioctl.c |2 +
drivers/gpu/drm/i915/Makefile |2 +-
drivers/gpu/drm/i915/i915_dma.c | 13 +-
drivers/gpu/drm/i915/i915_drv.h | 13 --
drivers/gpu/drm/i915/i915_mem.c | 387 ---
5 files changed, 7 insertions(+), 410 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/i915_mem.c
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 904d7e9..6bfc5ce 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -37,6 +37,7 @@
#include drm_core.h
#include linux/pci.h
+#include linux/export.h
/**
* Get the bus id.
@@ -353,3 +354,4 @@ int drm_noop(struct drm_device *dev, void *data,
DRM_DEBUG(\n);
return 0;
}
+EXPORT_SYMBOL(drm_noop);
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0ae6a7c..939b1c2 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -3,7 +3,7 @@
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
ccflags-y := -Iinclude/drm
-i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \
+i915-y := i915_drv.o i915_dma.o i915_irq.o \
i915_debugfs.o \
i915_suspend.o \
i915_gem.o \
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a9ae374..71a1946 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2243,9 +2243,6 @@ void i915_driver_lastclose(struct drm_device * dev)
i915_gem_lastclose(dev);
- if (dev_priv-agp_heap)
- i915_mem_takedown((dev_priv-agp_heap));
-
i915_dma_cleanup(dev);
}
@@ -2253,8 +2250,6 @@ void i915_driver_preclose(struct drm_device * dev, struct
drm_file *file_priv)
{
drm_i915_private_t *dev_priv = dev-dev_private;
i915_gem_release(dev, file_priv);
- if (!drm_core_check_feature(dev, DRIVER_MODESET))
- i915_mem_release(dev, file_priv, dev_priv-agp_heap);
}
void i915_driver_postclose(struct drm_device *dev, struct drm_file *file)
@@ -2273,11 +2268,11 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF_DRV(I915_ALLOC, i915_mem_alloc, DRM_AUTH),
- DRM_IOCTL_DEF_DRV(I915_FREE, i915_mem_free, DRM_AUTH),
- DRM_IOCTL_DEF_DRV(I915_INIT_HEAP, i915_mem_init_heap,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
+ DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(I915_INIT_HEAP, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_CMDBUFFER, i915_cmdbuffer, DRM_AUTH),
- DRM_IOCTL_DEF_DRV(I915_DESTROY_HEAP, i915_mem_destroy_heap,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
+ DRM_IOCTL_DEF_DRV(I915_DESTROY_HEAP, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_SET_VBLANK_PIPE, i915_vblank_pipe_set,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GET_VBLANK_PIPE, i915_vblank_pipe_get,
DRM_AUTH),
DRM_IOCTL_DEF_DRV(I915_VBLANK_SWAP, i915_vblank_swap, DRM_AUTH),
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 554bef7..0dceb4a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -327,7 +327,6 @@ typedef struct drm_i915_private {
int tex_lru_log_granularity;
int allow_batchbuffer;
- struct mem_block *agp_heap;
unsigned int sr01, adpa, ppcr, dvob, dvoc, lvds;
int vblank_pipe;
int num_pipe;
@@ -1070,18 +1069,6 @@ extern void i915_destroy_error_state(struct drm_device
*dev);
#endif
-/* i915_mem.c */
-extern int i915_mem_alloc(struct drm_device *dev, void *data,
- struct drm_file *file_priv);
-extern int i915_mem_free(struct drm_device *dev, void *data,
-struct drm_file *file_priv);
-extern int i915_mem_init_heap(struct drm_device *dev, void *data,
- struct drm_file *file_priv);
-extern int i915_mem_destroy_heap(struct drm_device *dev, void *data,
-struct drm_file *file_priv);
-extern void i915_mem_takedown(struct mem_block **heap);
-extern void i915_mem_release(struct drm_device * dev,
-struct drm_file *file_priv, struct mem_block
*heap);
/* i915_gem.c */
int i915_gem_init_ioctl(struct
Re: [Intel-gfx] [PATCH 0/5] Minor cleanup series
On Fri, Oct 07, 2011 at 02:38:41PM -0400, Adam Jackson wrote: Just a few things spotted in a readthrough. The DPLL disable one might actually be a bugfix, who knows. I've queued patches 1,25 for -next. 3 is already fixed and 4 won't be true in the near future due to something I'm not yet allowed to talk about. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Force synchronous TLB invalidations on the BLT ring for SNB+
On Tue, 17 Jan 2012 11:49:53 +0100, Daniel Vetter dan...@ffwll.ch wrote: What's the status of this patch? If you resend can you clarify the bugzilla reference and also include a Bspec/PRM/whatever citation for this workaround? We don't know what it works around, nor do we have any idea if it affects any bugs. What do we know is that my guess as to which bug might be affected was bogus. Thank VCG. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915:: Disable FBC on SandyBridge
On Tue, Jan 17, 2012 at 08:57, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Nov 08, 2011 at 11:17:34PM +, Chris Wilson wrote: Enabling FBC is causing the BLT ring to run between 10-100x slower than normal and frequently lockup. The interim solution is disable FBC once more until we know why. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Iirc fbc isn't really worth it power-wise on snb and we don't implement it on ivb. So shouldn't we just disable it completely? Eugeni, any opinions - I think you're most up to speed on power saving figures for snb? The FBC is good in some cases and bad in others. Let me confirm with our windows drivers friends first, but I'd say that we could disable it as it brings no significant improvements.. -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: kill i915_mem.c
On Tue, Jan 17, 2012 at 08:58, Dave Airlie airl...@gmail.com wrote: On Tue, Jan 17, 2012 at 10:45 AM, Keith Whitwell kei...@vmware.com wrote: On Mon, 2012-01-16 at 21:56 +0100, Daniel Vetter wrote: On Thu, Dec 22, 2011 at 10:23:14PM +0100, Daniel Vetter wrote: Some decent history digging indicates that this was to be used for the GLX_MESA_allocate_memory extension but never actually implemented for any released i915 userspace code. So just rip it out. Cc: Dave Airlie airl...@gmail.com Cc: Keith Whitwell kei...@vmware.com Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Can some bored soul take a look at this and do the history double-checking? And maybe notice that the Makefile change is missing ... /me would like to kill this cruft All sounds good to me, kill it with fire. I've never known this code to be used in anything. I think we can kill it, it does not seems to be used by anything. Just to be sure - Eric, you was the last one to touch it, do you think we may still have any need for it, or we can let it go? -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915:: Disable FBC on SandyBridge
On Tue, Jan 17, 2012 at 12:16, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, 17 Jan 2012 11:57:05 +0100, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Nov 08, 2011 at 11:17:34PM +, Chris Wilson wrote: Enabling FBC is causing the BLT ring to run between 10-100x slower than normal and frequently lockup. The interim solution is disable FBC once more until we know why. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Iirc fbc isn't really worth it power-wise on snb and we don't implement it on ivb. So shouldn't we just disable it completely? Eugeni, any opinions - I think you're most up to speed on power saving figures for snb? Also note that I've had a couple of people confirm this bug and tested the patch on IRC. Doesn't help explain precisely what is wrong nor if there is a better workaround amidst the chicken bits that we've missed. Keith, I think the disable-fbc-on-snb should go to -fixes. Eugeni can meanwhile figure out whether it's worth it on ivb or not and what we should do with this mess in -next. Hence this patch is (for -fixes) Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch -Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/dp: Tweak auxch clock divider for PCH
On Tue, 26 Jul 2011 15:39:44 -0400 Adam Jackson a...@redhat.com wrote: Matches the advice in the Sandybridge documentation. Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/i915/intel_dp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index dcc7ae6..3ad90f6 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -305,7 +305,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp, else aux_clock_divider = 225; /* eDP input clock at 450Mhz */ } else if (HAS_PCH_SPLIT(dev)) - aux_clock_divider = 62; /* IRL input clock fixed at 125Mhz */ + aux_clock_divider = 63; /* IRL input clock fixed at 125Mhz */ else aux_clock_divider = intel_hrawclk(dev) / 2; I have no problem with this set; matching the docs is nice. However we'll need to get some good test coverage before I feel comfortable. -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/dp: Tweak auxch clock divider for PCH
On Tue, 26 Jul 2011 15:39:44 -0400 Adam Jackson a...@redhat.com wrote: Matches the advice in the Sandybridge documentation. Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/i915/intel_dp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index dcc7ae6..3ad90f6 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -305,7 +305,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp, else aux_clock_divider = 225; /* eDP input clock at 450Mhz */ } else if (HAS_PCH_SPLIT(dev)) - aux_clock_divider = 62; /* IRL input clock fixed at 125Mhz */ + aux_clock_divider = 63; /* IRL input clock fixed at 125Mhz */ else aux_clock_divider = intel_hrawclk(dev) / 2; Sorry I meant: Acked-by: Jesse Barnes jbar...@virtuousgeek.org for the series. -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/dp: Tweak auxch clock divider for PCH
On Tue, Jan 17, 2012 at 07:19:35AM -0800, Jesse Barnes wrote: On Tue, 26 Jul 2011 15:39:44 -0400 Adam Jackson a...@redhat.com wrote: Matches the advice in the Sandybridge documentation. Signed-off-by: Adam Jackson a...@redhat.com --- drivers/gpu/drm/i915/intel_dp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index dcc7ae6..3ad90f6 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -305,7 +305,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp, else aux_clock_divider = 225; /* eDP input clock at 450Mhz */ } else if (HAS_PCH_SPLIT(dev)) - aux_clock_divider = 62; /* IRL input clock fixed at 125Mhz */ + aux_clock_divider = 63; /* IRL input clock fixed at 125Mhz */ else aux_clock_divider = intel_hrawclk(dev) / 2; I have no problem with this set; matching the docs is nice. However we'll need to get some good test coverage before I feel comfortable. Ok, Jesse upped these noises of approval into acked-bys on irc. Queued all 3 patches for -next. Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm: Fill in more of the DisplayPort DPCD registers
On Tue, Jul 12, 2011 at 03:42:11PM -0700, Keith Packard wrote: On Tue, 12 Jul 2011 17:37:59 -0400, Adam Jackson a...@redhat.com wrote: Signed-off-by: Adam Jackson a...@redhat.com +# define DP_DWN_STRM_PORT_TYPE_TMDS(2 1) This could be labeled TYPE_DVI_OR_HDMI according to the DP 1.1a spec. - I find the blank lines useful in this file; they separate lists of values for different fields. -#define DP_INTERLANE_ALIGN_DONE(1 0) -#define DP_DOWNSTREAM_PORT_STATUS_CHANGED (1 6) -#define DP_LINK_STATUS_UPDATED (1 7) +# define DP_INTERLANE_ALIGN_DONE (1 0) +# define DP_DOWNSTREAM_PORT_STATUS_CHANGED (1 6) +# define DP_LINK_STATUS_UPDATED(1 7) #define DP_SINK_STATUS 0x205 - -#define DP_RECEIVE_PORT_0_STATUS (1 0) -#define DP_RECEIVE_PORT_1_STATUS (1 1) +# define DP_RECEIVE_PORT_0_STATUS (1 0) +# define DP_RECEIVE_PORT_1_STATUS (1 1) #define DP_ADJUST_REQUEST_LANE0_1 0x206 #define DP_ADJUST_REQUEST_LANE2_3 0x207 Please make a separate patch for whitespace cleanups... Otherwise, these changes all match the DP 1.1a spec that I compared them with. Reviewed-by: Keith Packard kei...@keithp.com Noticed this one here while going through list archives. Doesn't apply properly anymore though. Adam, Dave? -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] FBC patchset
On Fri, Jul 08, 2011 at 08:43:47PM +0100, Chris Wilson wrote:
Oh dear, it was all looking too good. Works fine with just one output.
Runs into a nasty race if you add a second and start unplugging things...
The issue is that when unplugging an output, userspace sees this and
appropriately reconfigures from an extended desktop to just using, for the
sake of argument, the LVDS. As the desktop is changing size this requires
a new framebuffer and so we begin to teardown the two crtcs and replace
with just the one with the new fb. The first thing we do is disable the
crtc connected to the unplugged display. This triggers an
intel_update_fbc() which spots that it can now enable FBC on the current
single crtc + old fb and promptly dispatches a delayed task to do so.
The mode reconfiguration continues apace and we disable the other crtc and
start to replace the plane's FB. This involves a couple of
wait-for-vblanks, and so is quite slow. During this time we avoid taking
the struct_mutex. Meanwhile, the delayed task kicks off on a second CPU
grabs the struct_mutex and reconfigures the FBC registers. Apparently
enabling FBC on a dead plane is an undefined operation. Hilarity ensues,
followed by a swift reboot.
Bumping to 250ms sufficiently delays the task to miss the race, but we
can not foretell just how long any given crtc modeset will take. So what
we need is to take the mode_config.lock in order to prevent concurrent
access to the FBC registers and also to prevent the fb from disappearing
beneath us:
I've just noticed that we seem to miss this plug to fix fbc issues. Care
to resend a proper patch in case we still need this?
Also, I we could try to also disable fbc when we detect frontbuffer
rendering (and generally abolish setting up the fence to detect such
writes), maybe that helps with our fbc troubles (if it's actually worth
it). Eugeni?
-Daniel
---
drivers/gpu/drm/i915/intel_display.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e375500..bec9e1d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1603,6 +1603,11 @@ static void intel_fbc_work_fn(struct work_struct
*__work)
struct drm_device *dev = work-crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
+ if (!mutex_trylock(dev-mode_config.mutex)) {
+ schedule_delayed_work(work-work, msecs_to_jiffies(100));
+ return;
+ }
+
mutex_lock(dev-struct_mutex);
if (work == dev_priv-fbc_work) {
/* Double check that we haven't switched fb without cancelling
@@ -1620,6 +1625,7 @@ static void intel_fbc_work_fn(struct work_struct
*__work)
dev_priv-fbc_work = NULL;
}
mutex_unlock(dev-struct_mutex);
+ mutex_unlock(dev-mode_config.mutex);
kfree(work);
}
@@ -1684,7 +1690,7 @@ static void intel_enable_fbc(struct drm_crtc *crtc,
unsigned long interval)
* and indeed performing the enable as a co-routine and not
* waiting synchronously upon the vblank.
*/
- schedule_delayed_work(work-work, msecs_to_jiffies(50));
+ schedule_delayed_work(work-work, msecs_to_jiffies(250));
}
void intel_disable_fbc(struct drm_device *dev)
--
1.7.6
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/1] drm/i915: add a LLC feature flag in device description
LLC is not SNB/IVB-specific, so we should check for it in a more generic
way.
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c |1 +
drivers/gpu/drm/i915/i915_dma.c |3 +++
drivers/gpu/drm/i915/i915_drv.c |4
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_gem.c |4 ++--
include/drm/i915_drm.h |1 +
6 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1180798..6c3be86 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -83,6 +83,7 @@ static int i915_capabilities(struct seq_file *m, void *data)
B(supports_tv);
B(has_bsd_ring);
B(has_blt_ring);
+ B(has_llc);
#undef B
return 0;
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5f4d589..01985e0 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -784,6 +784,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_GEN7_SOL_RESET:
value = 1;
break;
+ case I915_PARAM_HAS_LLC:
+ value = HAS_LLC(dev);
+ break;
default:
DRM_DEBUG_DRIVER(Unknown parameter %d\n,
param-param);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7578c08..1658cfd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -214,6 +214,7 @@ static const struct intel_device_info
intel_sandybridge_d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.has_bsd_ring = 1,
.has_blt_ring = 1,
+ .has_llc = 1,
};
static const struct intel_device_info intel_sandybridge_m_info = {
@@ -222,6 +223,7 @@ static const struct intel_device_info
intel_sandybridge_m_info = {
.has_fbc = 1,
.has_bsd_ring = 1,
.has_blt_ring = 1,
+ .has_llc = 1,
};
static const struct intel_device_info intel_ivybridge_d_info = {
@@ -229,6 +231,7 @@ static const struct intel_device_info
intel_ivybridge_d_info = {
.need_gfx_hws = 1, .has_hotplug = 1,
.has_bsd_ring = 1,
.has_blt_ring = 1,
+ .has_llc = 1,
};
static const struct intel_device_info intel_ivybridge_m_info = {
@@ -237,6 +240,7 @@ static const struct intel_device_info
intel_ivybridge_m_info = {
.has_fbc = 0, /* FBC is not enabled on Ivybridge mobile yet */
.has_bsd_ring = 1,
.has_blt_ring = 1,
+ .has_llc = 1,
};
static const struct pci_device_id pciidlist[] = { /* aka */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 602bc80..dcafe93 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -255,6 +255,7 @@ struct intel_device_info {
u8 supports_tv:1;
u8 has_bsd_ring:1;
u8 has_blt_ring:1;
+ u8 has_llc:1;
};
enum no_fbc_reason {
@@ -970,6 +971,7 @@ struct drm_i915_file_private {
#define HAS_BSD(dev)(INTEL_INFO(dev)-has_bsd_ring)
#define HAS_BLT(dev)(INTEL_INFO(dev)-has_blt_ring)
+#define HAS_LLC(dev)(INTEL_INFO(dev)-has_llc)
#define I915_NEED_GFX_HWS(dev) (INTEL_INFO(dev)-need_gfx_hws)
#define HAS_OVERLAY(dev) (INTEL_INFO(dev)-has_overlay)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e55badb..eb98a7f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3619,8 +3619,8 @@ struct drm_i915_gem_object *i915_gem_alloc_object(struct
drm_device *dev,
obj-base.write_domain = I915_GEM_DOMAIN_CPU;
obj-base.read_domains = I915_GEM_DOMAIN_CPU;
- if (IS_GEN6(dev) || IS_GEN7(dev)) {
- /* On Gen6, we can have the GPU use the LLC (the CPU
+ if (HAS_LLC(dev)) {
+ /* On some devices, we can have the GPU use the LLC (the CPU
* cache) for about a 10% performance improvement
* compared to uncached. Graphics requests other than
* display scanout are coherent with the CPU in
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 924f6a4..da929bb 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -296,6 +296,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_EXEC_CONSTANTS 14
#define I915_PARAM_HAS_RELAXED_DELTA15
#define I915_PARAM_HAS_GEN7_SOL_RESET 16
+#define I915_PARAM_HAS_LLC 17
typedef struct drm_i915_getparam {
int param;
--
1.7.8.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH 1/1] intel: query for LLC support
This adds support for querying the kernel about the LLC support in the
hardware.
In case the ioctl fails, we assume that it is present on GEN6 and GEN7.
Signed-off-by: Eugeni Dodonov eug...@dodonov.net
---
include/drm/i915_drm.h |1 +
intel/intel_bufmgr_gem.c | 12
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index de72496..af3ce17 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -287,6 +287,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_EXEC_CONSTANTS 14
#define I915_PARAM_HAS_RELAXED_DELTA15
#define I915_PARAM_HAS_GEN7_SOL_RESET 16
+#define I915_PARAM_HAS_LLC 17
typedef struct drm_i915_getparam {
int param;
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 2b4fab1..9bbf10d 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -107,6 +107,7 @@ typedef struct _drm_intel_bufmgr_gem {
unsigned int has_bsd : 1;
unsigned int has_blt : 1;
unsigned int has_relaxed_fencing : 1;
+ unsigned int has_llc : 1;
unsigned int bo_reuse : 1;
bool fenced_relocs;
} drm_intel_bufmgr_gem;
@@ -2352,6 +2353,17 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
bufmgr_gem-has_relaxed_fencing = ret == 0;
+ gp.param = I915_PARAM_HAS_LLC;
+ ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
+ if (ret == -EINVAL) {
+ /* Kernel does not supports HAS_LLC query, fallback to GPU
+* generation detection and assume that we have LLC on GEN6/7
+*/
+ bufmgr_gem-has_llc = (IS_GEN6(bufmgr_gem-pci_device) |
+ IS_GEN7(bufmgr_gem-pci_device));
+ }
+ bufmgr_gem-has_llc = ret == 0;
+
if (bufmgr_gem-gen 4) {
gp.param = I915_PARAM_NUM_FENCES_AVAIL;
gp.value = bufmgr_gem-available_fences;
--
1.7.8.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] FBC patchset
On Tue, 17 Jan 2012 17:18:17 +0100, Daniel Vetter dan...@ffwll.ch wrote: I've just noticed that we seem to miss this plug to fix fbc issues. Care to resend a proper patch in case we still need this? Also, I we could try to also disable fbc when we detect frontbuffer rendering (and generally abolish setting up the fence to detect such writes), maybe that helps with our fbc troubles (if it's actually worth it). Eugeni? I'm testing whether disabling fbc when fb is busy helps on my troublesome SNB. But X can and will still access the scanout through a fence, so we can't simply abolish setting up fences here. The other recourse is to always used a shadow buffer so that we never access the scanout directly, and perhaps restrict that to only use render as well. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/1] intel: query for LLC support
This adds support for querying the kernel about the LLC support in the
hardware.
In case the ioctl fails, we assume that it is present on GEN6 and GEN7.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
include/drm/i915_drm.h |1 +
intel/intel_bufmgr_gem.c | 12
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index de72496..af3ce17 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -287,6 +287,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_EXEC_CONSTANTS 14
#define I915_PARAM_HAS_RELAXED_DELTA15
#define I915_PARAM_HAS_GEN7_SOL_RESET 16
+#define I915_PARAM_HAS_LLC 17
typedef struct drm_i915_getparam {
int param;
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 2b4fab1..9bbf10d 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -107,6 +107,7 @@ typedef struct _drm_intel_bufmgr_gem {
unsigned int has_bsd : 1;
unsigned int has_blt : 1;
unsigned int has_relaxed_fencing : 1;
+ unsigned int has_llc : 1;
unsigned int bo_reuse : 1;
bool fenced_relocs;
} drm_intel_bufmgr_gem;
@@ -2352,6 +2353,17 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
bufmgr_gem-has_relaxed_fencing = ret == 0;
+ gp.param = I915_PARAM_HAS_LLC;
+ ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
+ if (ret == -EINVAL) {
+ /* Kernel does not supports HAS_LLC query, fallback to GPU
+* generation detection and assume that we have LLC on GEN6/7
+*/
+ bufmgr_gem-has_llc = (IS_GEN6(bufmgr_gem-pci_device) |
+ IS_GEN7(bufmgr_gem-pci_device));
+ }
+ bufmgr_gem-has_llc = ret == 0;
+
if (bufmgr_gem-gen 4) {
gp.param = I915_PARAM_NUM_FENCES_AVAIL;
gp.value = bufmgr_gem-available_fences;
--
1.7.8.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] intel: query for LLC support
On Tue, Jan 17, 2012 at 14:44, Eugeni Dodonov eug...@dodonov.net wrote: This adds support for querying the kernel about the LLC support in the hardware. In case the ioctl fails, we assume that it is present on GEN6 and GEN7. Signed-off-by: Eugeni Dodonov eug...@dodonov.net Please ignore this and consider the next one - this was sent with the wrong S-o-b. -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Enable FBC on IVB architecture.
On Tue, 17 Jan 2012 12:22:44 +0100 Daniel Vetter dan...@ffwll.ch wrote: On Thu, Oct 20, 2011 at 03:15:09PM -0200, Eugeni Dodonov wrote: This is mostly similar to Ironlake, with some register changes and additional tricks. Jesse mentioned that it would make more sense to move those bits into ivb-specific functions instead of making this work within ironlake ones, so I added the corresponding functions and setup their pointers accordingly. v2: Now the correct patch. Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com Anyone got an opinion on whether this is worth it power-consumption wise? fbc has been a bit of a disaster and we have it disabled almost everywhere ... We also need some workarounds on IVB we haven't implemented yet. I'd say just keep it out of IVB+ unless we can show a real benefit and have all the workarounds in place. -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/1] drm/i915: print out which pixel format we do not support
Otherwise, we are left with pretty bogus message saying that the pixel format is not supported while leaving the details to the telepatic powers. Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/intel_display.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index ebe71ed..5d47d0d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7880,7 +7880,8 @@ int intel_framebuffer_init(struct drm_device *dev, case DRM_FORMAT_VYUY: break; default: - DRM_ERROR(unsupported pixel format\n); + DRM_ERROR(unsupported pixel format %u\n, + mode_cmd-pixel_format); return -EINVAL; } -- 1.7.8.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: print out which pixel format we do not support
On Tue, Jan 17, 2012 at 03:11:11PM -0200, Eugeni Dodonov wrote: Otherwise, we are left with pretty bogus message saying that the pixel format is not supported while leaving the details to the telepatic powers. Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/intel_display.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index ebe71ed..5d47d0d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7880,7 +7880,8 @@ int intel_framebuffer_init(struct drm_device *dev, case DRM_FORMAT_VYUY: break; default: - DRM_ERROR(unsupported pixel format\n); + DRM_ERROR(unsupported pixel format %u\n, + mode_cmd-pixel_format); While we're bashing Jesse, this looks like a user-triggerable error. Can we have a DRM_DEBUG_KMS instead? -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/1] intel: query for LLC support
This adds support for querying the kernel about the LLC support in the
hardware.
In case the ioctl fails, we assume that it is present on GEN6 and GEN7.
v2: fix the return code checking
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
include/drm/i915_drm.h |1 +
intel/intel_bufmgr_gem.c | 12
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index de72496..af3ce17 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -287,6 +287,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_EXEC_CONSTANTS 14
#define I915_PARAM_HAS_RELAXED_DELTA15
#define I915_PARAM_HAS_GEN7_SOL_RESET 16
+#define I915_PARAM_HAS_LLC 17
typedef struct drm_i915_getparam {
int param;
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 2b4fab1..f5db3d9 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -107,6 +107,7 @@ typedef struct _drm_intel_bufmgr_gem {
unsigned int has_bsd : 1;
unsigned int has_blt : 1;
unsigned int has_relaxed_fencing : 1;
+ unsigned int has_llc : 1;
unsigned int bo_reuse : 1;
bool fenced_relocs;
} drm_intel_bufmgr_gem;
@@ -2352,6 +2353,17 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
bufmgr_gem-has_relaxed_fencing = ret == 0;
+ gp.param = I915_PARAM_HAS_LLC;
+ ret = drmIoctl(bufmgr_gem-fd, DRM_IOCTL_I915_GETPARAM, gp);
+ if (ret == -EINVAL) {
+ /* Kernel does not supports HAS_LLC query, fallback to GPU
+* generation detection and assume that we have LLC on GEN6/7
+*/
+ bufmgr_gem-has_llc = (IS_GEN6(bufmgr_gem-pci_device) |
+ IS_GEN7(bufmgr_gem-pci_device));
+ } else
+ bufmgr_gem-has_llc = ret == 0;
+
if (bufmgr_gem-gen 4) {
gp.param = I915_PARAM_NUM_FENCES_AVAIL;
gp.value = bufmgr_gem-available_fences;
--
1.7.8.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/1] drm/i915: print out which pixel format we do not support
Otherwise, we are left with pretty bogus message saying that the pixel format is not supported while leaving the details to the telepatic powers. v2: use DRM_DEBUG_KMS instead of DRM_ERROR Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/intel_display.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index ebe71ed..56b7f6f 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7880,7 +7880,8 @@ int intel_framebuffer_init(struct drm_device *dev, case DRM_FORMAT_VYUY: break; default: - DRM_ERROR(unsupported pixel format\n); + DRM_DEBUG_KMS(unsupported pixel format %u\n, + mode_cmd-pixel_format); return -EINVAL; } -- 1.7.8.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] intel: query for LLC support
On Tue, 17 Jan 2012 14:58:21 -0200, Eugeni Dodonov eugeni.dodo...@intel.com wrote: This adds support for querying the kernel about the LLC support in the hardware. In case the ioctl fails, we assume that it is present on GEN6 and GEN7. This patch should probably come along with a consumer of the flag. pgpzbrbpXpu6i.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: add a LLC feature flag in device description
On Tue, 17 Jan 2012 14:43:53 -0200, Eugeni Dodonov eugeni.dodo...@intel.com wrote: LLC is not SNB/IVB-specific, so we should check for it in a more generic way. Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com Reviewed-by: Eric Anholt e...@anholt.net pgpRyk23Qn3FJ.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: kill i915_mem.c
On Tue, 17 Jan 2012 12:50:12 +0100, Daniel Vetter daniel.vet...@ffwll.ch wrote: Some decent history digging indicates that this was to be used for the GLX_MESA_allocate_memory extension but never actually implemented for any released i915 userspace code. So just rip it out. v2: Fixup the Makefile. Reviewed-by: Eric Anholt e...@anholt.net pgpGy28LwrGKm.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [RFC] drm/i915: read-read semaphore optimization
On Tue, 17 Jan 2012 11:15:31 +0100, Daniel Vetter dan...@ffwll.ch wrote: On Mon, Jan 16, 2012 at 02:20:55PM -0800, Ben Widawsky wrote: On 01/16/2012 01:50 PM, Daniel Vetter wrote: On Tue, Dec 13, 2011 at 10:36:15AM -0800, Ben Widawsky wrote: On 12/13/2011 09:22 AM, Eric Anholt wrote: On Mon, 12 Dec 2011 19:52:08 -0800, Ben Widawskyb...@bwidawsk.net wrote: Since we don't differentiate on the different GPU read domains, it should be safe to allow back to back reads to occur without issuing a wait (or flush in the non-semaphore case). This has the unfortunate side effect that we need to keep track of all the outstanding buffer reads so that we can synchronize on a write, to another ring (since we don't know which read finishes first). In other words, the code is quite simple for two rings, but gets more tricky for 2 rings. Here is a picture of the solution to the above problem Ring 0Ring 1 Ring 2 batch 0 batch 1batch 2 read buffer A read buffer A wait batch 0 wait batch 1 write buffer A This code is really untested. I'm hoping for some feedback if this is worth cleaning up, and testing more thoroughly. You say it's an optimization -- do you have performance numbers? 33% improvement on a hacked version of gem_ring_sync_loop with. It's not really a valid test as it's not coherent, but this is approximately the best case improvement. Oddly semaphores doesn't make much difference in this test, which was surprising. Our domain tracking is already complicated in unfunny ways. And (at least without a use-case showing gains with hard numbers in either perf or power usage) I think this patch is the kind of this looks cool stuff that added a lot to the current problem. So before adding more complexity on top I'd like to remove some of the superflous stuff we already have. I.e. all the flushing_list stuff and maybe other things ... Can you be more clear on what exactly you want done before taking a patch like this? Maybe I can work on it during some down time. I was thinking about Eric's no-more-domains stuff specifically, which has tons of natural split-points - and we want to exploit these for merging. Imo step 1 would be to just rework the batch dispatch in intel_ringbuffer.c so that we unconditionally invalidate before and flush afterwards. The ring-flush would become a no-op. No changes to the core flushing_list tracking for step 1. If we can get this in for 3.4 we could (in the -next merge cycle) walk all the callchains from their ends and rip out everything which is a no-op, starting from ring-flush. I think that's the safest way to attack this. Eric? I was stuck with a mysterious regression in my previous attempt at the patch series. I've recently realized that I can do the major code deletion with fewer + lines in the diff, which I hope will avoid that. I'm working it that again now. pgpwpVKP6opnX.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: kill i915_mem.c
On Tue, Jan 17, 2012 at 09:35:48AM -0800, Eric Anholt wrote: On Tue, 17 Jan 2012 12:50:12 +0100, Daniel Vetter daniel.vet...@ffwll.ch wrote: Some decent history digging indicates that this was to be used for the GLX_MESA_allocate_memory extension but never actually implemented for any released i915 userspace code. So just rip it out. v2: Fixup the Makefile. Reviewed-by: Eric Anholt e...@anholt.net I've queued this for -next, thanks for the r-b. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] sna: check for LLC support
Instead of checking for CPU generation, use the libdrm-provided I915_PARAM_HAS_LLC instead. Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- src/sna/kgem.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/sna/kgem.c b/src/sna/kgem.c index 970e462..96c5ddd 100644 --- a/src/sna/kgem.c +++ b/src/sna/kgem.c @@ -603,8 +603,8 @@ void kgem_init(struct kgem *kgem, int fd, struct pci_device *dev, int gen) kgem-has_relaxed_fencing)); kgem-has_llc = false; - if (!DBG_NO_LLC gen = 60) - kgem-has_llc = true; + if (!DBG_NO_LLC) + kgem-has_llc = gem_param(kgem, I915_PARAM_HAS_LLC); kgem-has_cpu_bo = kgem-has_llc; DBG((%s: cpu bo enabled %d: llc? %d\n, __FUNCTION__, kgem-has_cpu_bo, kgem-has_llc)); -- 1.7.8.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] configure: check for libdrm = 2.4.31
This is requried for I915_PARAM_HAS_LLC support. Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- configure.ac |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 63beb64..604ea6d 100644 --- a/configure.ac +++ b/configure.ac @@ -132,6 +132,7 @@ required_pixman_version=0.24 if test x$SNA != xno; then required_xorg_xserver_version=1.10 AC_DEFINE(USE_SNA, 1, [Enable SNA support]) + PKG_CHECK_MODULES(DRMINTEL, [libdrm_intel = 2.4.31]) fi AC_MSG_RESULT([$SNA]) -- 1.7.8.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: add a LLC feature flag in device description
On 01/17/2012 08:43 AM, Eugeni Dodonov wrote: LLC is not SNB/IVB-specific, so we should check for it in a more generic way. Reviewed-by: Chris Wilsonch...@chris-wilson.co.uk Reviewed-by: Daniel Vetterdaniel.vet...@ffwll.ch Signed-off-by: Eugeni Dodonoveugeni.dodo...@intel.com Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] sna: check for LLC support
Instead of checking for CPU generation, use the libdrm-provided I915_PARAM_HAS_LLC instead. v2: use a define check to verify if we have I915_PARAM_HAS_LLC. Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- src/sna/kgem.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/src/sna/kgem.c b/src/sna/kgem.c index 970e462..aa9029d 100644 --- a/src/sna/kgem.c +++ b/src/sna/kgem.c @@ -603,8 +603,20 @@ void kgem_init(struct kgem *kgem, int fd, struct pci_device *dev, int gen) kgem-has_relaxed_fencing)); kgem-has_llc = false; +#ifdef I915_PARAM_HAS_LLC + if (!DBG_NO_LLC) + kgem-has_llc = gem_param(kgem, I915_PARAM_HAS_LLC); +#else + /* If I915_PARAM_HAS_LLC is not defined by the libdrm, fallback +* to previous GPU generation check and assume that GPUs superior +* to Gen6 support it. +*/ + DBG((%s: libdrm does not provides I915_PARAM_HAS_LLC, detect GPU gen instead\n, + __FUNCTION__)); if (!DBG_NO_LLC gen = 60) kgem-has_llc = true; +#endif + kgem-has_cpu_bo = kgem-has_llc; DBG((%s: cpu bo enabled %d: llc? %d\n, __FUNCTION__, kgem-has_cpu_bo, kgem-has_llc)); -- 1.7.8.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Problem Intel i915 driver, i3 2010T, HDMI output modes problems
Hi Paulo, sorry for not getting back you sooner... your email was here on my to do list Could you please report this issue on bugs.freedesktop.org attaching this xrandr verbose info and also dmesg xorg log and confs? Also, Is it possible to test it without the AV receiver? I think you wont see a similar behaviour? Maybe AV receiver is meessing up EDID info when booting, but it would be strange to see x reporting a freq and receiver another one anyway. The interlacing issue is also possible, so as much info you can provide us the best! I also think that the workaround Andy suggested will work in your case, but I would like to get it really fixed. Rodrigo. On Mon, Jan 16, 2012 at 8:09 PM, Andy Burns xorg.li...@burns.me.uk wrote: [apologies for munged threading, I subscribed after the original message was sent] paulo louro wrote: When starting ubuntu without the AV receiver or the TV being on, the xorg start with a resolution of 720x576. Have you tried forcing an initial mode in the Monitor section of your xorg.conf? Option PreferredMode whatever presumably whatever is something like 1920x1080x60.0 in your case ... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br GPG: 0x905BE242 @ wwwkeys.pgp.net ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] sna: check for LLC support
On Tue, 17 Jan 2012 16:16:37 -0200, Eugeni Dodonov eugeni.dodo...@intel.com wrote: Instead of checking for CPU generation, use the libdrm-provided I915_PARAM_HAS_LLC instead. v2: use a define check to verify if we have I915_PARAM_HAS_LLC. Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com I attacked it slightly so that gem_param reported the lack of support so that we could fallback to guessing by gen for GET_PARAM failure. Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: add a LLC feature flag in device description
On Tue, Jan 17, 2012 at 02:43:53PM -0200, Eugeni Dodonov wrote: LLC is not SNB/IVB-specific, so we should check for it in a more generic way. Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working
On Tue, Jan 17, 2012 at 18:14, Alfonso Fiore alfonso.fi...@gmail.comwrote: Hi Angela, I have a very similar problem! I have Sandy Bridge (i3 2130) and a Philips 32pf9731d (coincidence?). With my previous i3 550 I didn't have any problem. I tried all possible resolutions over HDMI and all the time the screen is split in two (twice the top half) and flickering. I also can't manage to use VGA (TV has VGA input). I also tried with the latest kernel and latest X. Can you try to run this tool? http://polypux.org/projects/read-edid/ I'm absolutely not an expert, but the output I get (Your EDID is probably invalid.) is not encouraging. I'd love to know if you get the same error. Could you try with the following two patches which just came to this list this week? http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/8006 Don't know if they will fix the problem, but they could help perhaps. -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working
On Tue, Jan 17, 2012 at 9:25 PM, Eugeni Dodonov eug...@dodonov.net wrote: On Tue, Jan 17, 2012 at 18:14, Alfonso Fiore alfonso.fi...@gmail.comwrote: Hi Angela, I have a very similar problem! I have Sandy Bridge (i3 2130) and a Philips 32pf9731d (coincidence?). With my previous i3 550 I didn't have any problem. I tried all possible resolutions over HDMI and all the time the screen is split in two (twice the top half) and flickering. I also can't manage to use VGA (TV has VGA input). I also tried with the latest kernel and latest X. Can you try to run this tool? http://polypux.org/projects/read-edid/ I'm absolutely not an expert, but the output I get (Your EDID is probably invalid.) is not encouraging. I'd love to know if you get the same error. Could you try with the following two patches which just came to this list this week? http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/8006 Don't know if they will fix the problem, but they could help perhaps. Hi Eugeni, and thank you. I'm just an end-user. I have the willingness to try, but I need a bit more guidance... I've never compiled X. If you can point me to some page that explains the process I'll be more than happy to try. cheers, ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working
On Tue, Jan 17, 2012 at 09:59:18PM +0100, Alfonso Fiore wrote: Hi, here is mine. Let me know if you need any other log. Ok, your TV only reports 1080i as a mode (at least that's the only thing your kernel can decode). The i915 driver then rejects it because it's interlaced (we unfortunately do not yet support interlaced everywhere we could). Which leaves you with no modes, so as a fallback the kernel just adds a bunch of default VGA modes which your TV can't cope with properly. Your TV likely sends a CEA block with some HDMI default modes set. Since linux-3.3-rc1 (to be released in a few days) we should be able to decode that. Can you grab the latest -linus kernel git and try that? Also, can you add a short list of the modelines you've manually added that work with your TV? Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working
On Tue, Jan 17, 2012 at 10:32:33PM +0100, Angela Schmid wrote: Hello Thanks for helping. I added the dmesg with drm.debug=0x0e below. I tried last month with get-edid in DOS, with the same unhappy result, see below for actual linux. Could you try with the following two patches which just came to this list this week? http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/8006 I have this version from xorg-edgers xserver-xorg-video-intel/oneiric uptodate 2:2.17.0+git20120115.8652bf7a-0ubuntu0sarvatt~oneiric Is it included ? I cannot find the repository to look for the log: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/ Is this link correct ? where is src/drivers ? http://intellinuxgraphics.org/download.html Need to look for 1) X.org 2D driver, correct ? dmesg indicates the same issue (not suprising given that it's the same TV). You need to compile a new kernel, the output handling part of the graphics driver is there. Best is to try the latest drm-intel-fixes tree available at: https://git.kernel.org/?p=linux/kernel/git/keithp/linux.git;a=shortlog;h=refs/heads/drm-intel-fixes Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working
Hello Over HDMI works: 1280x720@50hz 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync 1280x720@50hz (0xb4) 74.2MHz +HSync +VSync *current h: width 1280 start 1720 end 1760 total 1980 skew0 clock 37.5KHz v: height 720 start 725 end 730 total 750 clock 50.0Hz 1440x576ix0.0 27.00 1440 1464 1590 1728 576 580 586 625 interlace -hsync -vsync 1440x576ix0.0 (0xbd) 27.0MHz -HSync -VSync Interlace *current h: width 1440 start 1464 end 1590 total 1728 skew0 clock 15.6KHz v: height 576 start 580 end 586 total 625 clock 25.0Hz and 1440x288x0.0 27.00 1440 1464 1590 1728 288 290 293 312 -hsync -vsync Have a lot of horizontal overscan, vertical very small, useless. It is some time ago, that I compiled kernels myself. I compile drivers regularly. I will have a look next week. Your TV likely sends a CEA block with some HDMI default modes set. Since linux-3.3-rc1 (to be released in a few days) we should be able to decode that. Can you grab the latest -linus kernel git and try that? Too many ways described on one page: http://wiki.ubuntuusers.de/Kernel/Kompilierung Kernel.org links to kernel newbies website. Do you have a link how to compile/install ? You need to compile a new kernel, the output handling part of the graphics driver is there. Best is to try the latest drm-intel-fixes tree available at: https://git.kernel.org/?p=linux/kernel/git/keithp/linux.git;a=shortlog;h=refs/heads/drm-intel-fixes Can I wait for the ppa:xorg-edgers ? Angela From: Alfonso Fiore [mailto:alfonso.fi...@gmail.com] Sent: 17 January 2012 22:53 To: Daniel Vetter Cc: Angela Schmid; intel-gfx@lists.freedesktop.org; Rodrigo Vivi Subject: Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working Ok, your TV only reports 1080i as a mode (at least that's the only thing your kernel can decode). true, it's non a Full HD TV. we unfortunately do not yet support interlaced everywhere we could when do you think the support will be added? weeks? months? can you add a short list of the modelines you've manually added that work with your TV? not sure I understand your question... The TV works with nomodeset and then I tried a bunch of resolutions with xrandr (when running without nomodeset) that ALL didn't work: I tried some of the modes I got from Xorg.0.log: [88.893] (II) intel(0): Modeline 1920x1080ix0.0 74.25 1920 2448 2492 2640 1080 1084 1094 1125 interlace +hsync +vsync (28.1 kHz) [88.893] (II) intel(0): Modeline 1024x768x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) [88.893] (II) intel(0): Modeline 1920x1080ix0.0 74.25 1920 2008 2052 2200 1080 1084 1094 1125 interlace +hsync +vsync (33.8 kHz) [88.893] (II) intel(0): Modeline 1280x720x0.0 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync (37.5 kHz) [88.893] (II) intel(0): Modeline 1280x720x0.0 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync (45.0 kHz) [88.893] (II) intel(0): Modeline 720x576x0.0 27.00 720 732 796 864 576 581 586 625 -hsync -vsync (31.2 kHz) [88.893] (II) intel(0): Modeline 720x480x0.0 27.00 720 736 798 858 480 483 489 525 -hsync -vsync (31.5 kHz) [88.893] (II) intel(0): Modeline 800x600x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) [88.893] (II) intel(0): Modeline 640x480x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) [88.893] (II) intel(0): Modeline 720x480x0.0 27.00 720 736 798 858 480 489 495 525 -hsync -vsync (31.5 kHz) [88.893] (II) intel(0): Modeline 1440x480ix0.0 27.00 1440 1478 1602 1716 480 488 494 525 interlace -hsync -vsync (15.7 kHz) [88.893] (II) intel(0): Modeline 1440x240x0.0 27.00 1440 1478 1602 1716 240 244 247 262 -hsync -vsync (15.7 kHz) [88.893] (II) intel(0): Modeline 1440x576ix0.0 27.00 1440 1464 1590 1728 576 580 586 625 interlace -hsync -vsync (15.6 kHz) [88.893] (II) intel(0): Modeline 1440x288x0.0 27.00 1440 1464 1590 1728 288 290 293 312 -hsync -vsync (15.6 kHz) 74.25 1920 2448 2492 2640 1080 1084 1094 1125 interlace +hsync +vsync nothing - blue screen (and now I know why since it's interlaced) 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync back to the original situation (two bands, flickering) 74.25 1920 2008 2052 2200 1080 1084 1094 1125 interlace +hsync +vsync nothing - blue screen 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync three bands, flickering 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync two bands, flickering 27.00 720 732 796 864 576 581 586 625 -hsync -vsync three bands, no flickering 27.00 720 736 798 858 480 483 489 525 -hsync -vsync two bands, no flickering 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync two bands, flickering
Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working
On Tue, Jan 17, 2012 at 11:53:47PM +0100, Angela Schmid wrote: Over HDMI works: 1280x720@50hz 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync 1280x720@50hz (0xb4) 74.2MHz +HSync +VSync *current h: width 1280 start 1720 end 1760 total 1980 skew0 clock 37.5KHz v: height 720 start 725 end 730 total 750 clock 50.0Hz 1440x576ix0.0 27.00 1440 1464 1590 1728 576 580 586 625 interlace -hsync -vsync 1440x576ix0.0 (0xbd) 27.0MHz -HSync -VSync Interlace *current h: width 1440 start 1464 end 1590 total 1728 skew0 clock 15.6KHz v: height 576 start 580 end 586 total 625 clock 25.0Hz and 1440x288x0.0 27.00 1440 1464 1590 1728 288 290 293 312 -hsync -vsync Have a lot of horizontal overscan, vertical very small, useless. Yeah, many TVs send out a different edid depending upon what connector they are plugged in. Also we currently don't handle overscan compensation at all, Rodrigo is working on that. It is some time ago, that I compiled kernels myself. I compile drivers regularly. I will have a look next week. Your TV likely sends a CEA block with some HDMI default modes set. Since linux-3.3-rc1 (to be released in a few days) we should be able to decode that. Can you grab the latest -linus kernel git and try that? Too many ways described on one page: http://wiki.ubuntuusers.de/Kernel/Kompilierung Kernel.org links to kernel newbies website. Do you have a link how to compile/install ? Maybe ask on irc about what's suggested. Way back I've used Die klassische Debian-Methode. You need to compile a new kernel, the output handling part of the graphics driver is there. Best is to try the latest drm-intel-fixes tree available at: https://git.kernel.org/?p=linux/kernel/git/keithp/linux.git;a=shortlog;h=refs/heads/drm-intel-fixes Can I wait for the ppa:xorg-edgers ? If they track drm-intel-fixes, yeah. But you might want to try to compile the kernel, too, in case we have some additional patches for you to apply. Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] I've got the RC6 bug
On Wed, Jan 18, 2012 at 01:16:02AM +0100, CC wrote: On Mon, Jan 16, 2012 at 5:36 PM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, Jan 16, 2012 at 05:18:17PM +0100, CC wrote: Hi, I've heard that you need users having the RC6 bug. I have the following setup: CPU: Intel Core i5-2500K Mainboard: ASRock Z68 Pro3-M Memory: Corsair Vengeance CMZ8GX3M2A1866C9 Although the CPU doesn't support VT-d, I disabled all virtualization support in the UEFI setup. I use Arch Linux and Gnome 3 in the fallback mode. The problem is more drastic without fallback mode, however. Whenever I enable RC6, I get the a few of these errors in dmesg: [ 48.90] WARNING: at drivers/gpu/drm/i915/i915_drv.c:387 __gen6_gt_wait_for_fifo+0x94/0xa0 [i915]() [ 48.92] Hardware name: To Be Filled By O.E.M. [ 48.92] Modules linked in: ipv6 fuse ext2 snd_hda_codec_hdmi snd_hda_codec_realtek mei(C) joydev r8169 shpchp pci_hotplug usbhid hid snd_hda_intel iTCO_wdt mii iTCO_vendor_support i2c_i801 snd_hda_codec processor snd_hwdep snd_pcm snd_timer snd soundcore snd_page_alloc psmouse serio_raw pcspkr evdev ext4 mbcache jbd2 crc16 xhci_hcd ehci_hcd usbcore i915 drm_kms_helper drm intel_agp i2c_algo_bit button intel_gtt i2c_core video sd_mod ahci libahci libata scsi_mod [ 48.900019] Pid: 623, comm: Xorg Tainted: GWC 3.1.9-2-ARCH #1 [ 48.900020] Call Trace: [ 48.900023] [81061bef] warn_slowpath_common+0x7f/0xc0 [ 48.900025] [81061c4a] warn_slowpath_null+0x1a/0x20 [ 48.900028] [a00e0764] __gen6_gt_wait_for_fifo+0x94/0xa0 [i915] [ 48.900032] [a015d2d5] ring_write_tail+0x65/0x120 [i915] [ 48.900036] [a01619bc] render_ring_flush+0xbc/0xe0 [i915] [ 48.900040] [a010b803] i915_gem_flush_ring+0x43/0x250 [i915] [ 48.900044] [a0112b50] i915_gem_do_execbuffer.isra.7+0x1020/0x16d0 [i915] [ 48.900048] [a01136bb] i915_gem_execbuffer2+0x8b/0x240 [i915] [ 48.900051] [a0098434] drm_ioctl+0x3e4/0x4c0 [drm] [ 48.900053] [810746cb] ? recalc_sigpending+0x1b/0x50 [ 48.900057] [a0113630] ? i915_gem_execbuffer+0x430/0x430 [i915] [ 48.900059] [8101e9b1] ? fpu_finit+0x21/0x40 [ 48.900061] [8116fddf] do_vfs_ioctl+0x8f/0x500 [ 48.900063] [81014beb] ? sys_rt_sigreturn+0x1eb/0x200 [ 48.900064] [811702e1] sys_ioctl+0x91/0xa0 [ 48.900066] [8140c3c2] system_call_fastpath+0x16/0x1b [ 48.900067] ---[ end trace 9a23b8b32b16a424 ]--- This is a known side-effect of a dying gpu. It essentially means that the gpu refuses to wake up from deep-sleep states. and then [ 53.163526] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [ 53.165046] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state [ 53.177356] [drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting 1593 at 1592, next 1594) [ 53.181979] [drm:init_ring_common] *ERROR* render ring initialization failed ctl head tail start [ 53.185522] [drm:init_ring_common] *ERROR* gen6 bsd ring initialization failed ctl head tail start [ 53.188558] [drm:init_ring_common] *ERROR* blt ring initialization failed ctl head tail start [ 55.330146] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [ 55.332202] [drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting 1594 at 1591, next 1595) [ 55.333258] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged! [ 55.333260] [drm:i915_reset] *ERROR* Failed to reset chip. Of course, I'd be willing to test out stuff. I'd need a bit of guide, however. Can you please attach i915_error_state from debugfs (you need to retrigger the issue)? It contains a gpu dump which is useful to diagnose the bug. Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 I attached the error state. Nice one, your gpu seems to have simply disappeared. And the ringbuffer contains a rather peculiar cmd sequence. Putting Chris (maybe he recognizes the pattern) and Ben (he's got a patch in the works to dump a debug register that might be interesting here) on cc. It's too late atm for me to think about this some more. Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: rip out the HWSTAM missed irq workaround
On Thu, Jan 05, 2012 at 11:11:53PM +0100, Daniel Vetter wrote:
With the new ducttape of much finer quality, this seems to be no
longer necessary.
Tested on my ivb and snb machine with the usual suspects of testcases.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b9ba180..af54153 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1779,17 +1779,6 @@ static void ironlake_irq_preinstall(struct drm_device
*dev)
INIT_WORK(dev_priv-rps_work, gen6_pm_rps_work);
I915_WRITE(HWSTAM, 0xeffe);
- if (IS_GEN6(dev) || IS_GEN7(dev)) {
- /* Workaround stalls observed on Sandy Bridge GPUs by
- * making the blitter command streamer generate a
- * write to the Hardware Status Page for
- * MI_USER_INTERRUPT. This appears to serialize the
- * previous seqno write out before the interrupt
- * happens.
- */
- I915_WRITE(GEN6_BLITTER_HWSTAM, ~GEN6_BLITTER_USER_INTERRUPT);
- I915_WRITE(GEN6_BSD_HWSTAM, ~GEN6_BSD_USER_INTERRUPT);
- }
/* XXX hotplug from PCH */
---
This patch is a requirement for functional simulation on Gen7. It
appears to not break Gen6 afaics. Therefore:
Acked-by: Ben Widawsky b...@bwidawsk.net
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Make XAA support optional
Does what it says on the box.
Signed-off-by: Daniel Stone dan...@fooishbar.org
---
configure.ac | 14 ++
src/legacy/i810/Makefile.am |6 +-
src/legacy/i810/i810.h|4
src/legacy/i810/i810_dga.c|2 ++
src/legacy/i810/i810_driver.c | 10 +-
src/legacy/i810/i810_hwmc.c |2 ++
src/legacy/i810/i810_video.c |2 ++
7 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 63beb64..c3cbfd4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -268,6 +268,20 @@ if test x$DEBUG = xfull; then
CFLAGS=$CFLAGS -O0 -ggdb3
fi
+save_CFLAGS=$CFLAGS
+CFLAGS=$XORG_CFLAGS
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[#include xorg-server.h
+#include xaa.h
+#include xaalocal.h
+]])],
+ [have_xaa=yes],
+ [have_xaa=no])
+CFLAGS=$save_CFLAGS
+if test x$have_xaa = xyes; then
+ AC_DEFINE(XAA,1,[Enable XAA acceleration for i810])
+fi
+AM_CONDITIONAL(XAA, test x$have_xaa = xyes)
+
AC_CHECK_HEADERS([sys/timerfd.h])
DRIVER_NAME=intel
diff --git a/src/legacy/i810/Makefile.am b/src/legacy/i810/Makefile.am
index a1bdd85..a88508c 100644
--- a/src/legacy/i810/Makefile.am
+++ b/src/legacy/i810/Makefile.am
@@ -8,7 +8,6 @@ AM_CFLAGS = @CWARNFLAGS@ @XORG_CFLAGS@ @DRM_CFLAGS@
@DRI_CFLAGS@ @PCIACCESS_CFLA
$(NULL)
liblegacy_i810_la_SOURCES = \
- i810_accel.c \
i810_common.h \
i810_cursor.c \
i810_dga.c \
@@ -20,6 +19,11 @@ liblegacy_i810_la_SOURCES = \
i810_video.c \
i810_wmark.c
+if XAA
+liblegacy_i810_la_SOURCES += \
+ i810_accel.c
+endif
+
if DRI
liblegacy_i810_la_SOURCES +=\
i810_dri.c \
diff --git a/src/legacy/i810/i810.h b/src/legacy/i810/i810.h
index 183c701..d10f304 100644
--- a/src/legacy/i810/i810.h
+++ b/src/legacy/i810/i810.h
@@ -42,7 +42,9 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#include compiler.h
#include xf86Pci.h
#include i810_reg.h
+#ifdef XAA
#include xaa.h
+#endif
#include xf86Cursor.h
#include xf86xv.h
#include vbe.h
@@ -201,7 +203,9 @@ typedef struct _I810Rec {
I810RegRec SavedReg;
I810RegRec ModeReg;
+#ifdef XAA
XAAInfoRecPtr AccelInfoRec;
+#endif
xf86CursorInfoPtr CursorInfoRec;
CloseScreenProcPtr CloseScreen;
ScreenBlockHandlerProcPtr BlockHandler;
diff --git a/src/legacy/i810/i810_dga.c b/src/legacy/i810/i810_dga.c
index 44181c6..4174309 100644
--- a/src/legacy/i810/i810_dga.c
+++ b/src/legacy/i810/i810_dga.c
@@ -29,8 +29,10 @@
#include xf86.h
#include xf86_OSproc.h
#include xf86Pci.h
+#ifdef XAA
#include xaa.h
#include xaalocal.h
+#endif
#include i810.h
#include i810_reg.h
#include dgaproc.h
diff --git a/src/legacy/i810/i810_driver.c b/src/legacy/i810/i810_driver.c
index d8f7c45..5026a26 100644
--- a/src/legacy/i810/i810_driver.c
+++ b/src/legacy/i810/i810_driver.c
@@ -345,13 +345,15 @@ I810PreInit(ScrnInfoPtr pScrn, int flags)
if (xf86ReturnOptValBool(pI810-Options, OPTION_NOACCEL, FALSE))
pI810-noAccel = TRUE;
+#ifdef XAA
if (!pI810-noAccel) {
if (!xf86LoadSubModule(pScrn, xaa)) {
I810FreeRec(pScrn);
return FALSE;
}
}
-
+#endif
+
#ifdef XF86DRI
pI810-directRenderingDisabled =
!xf86ReturnOptValBool(pI810-Options, OPTION_DRI, TRUE);
@@ -1701,6 +1703,7 @@ I810ScreenInit(int scrnIndex, ScreenPtr pScreen, int
argc, char **argv)
return FALSE;
}
+#ifdef XAA
if (!xf86ReturnOptValBool(pI810-Options, OPTION_NOACCEL, FALSE)) {
if (pI810-LpRing-mem.Size != 0) {
I810SetRingRegs(pScrn);
@@ -1712,6 +1715,7 @@ I810ScreenInit(int scrnIndex, ScreenPtr pScreen, int
argc, char **argv)
I810EmitFlush(pScrn);
}
}
+#endif
miInitializeBackingStore(pScreen);
xf86SetBackingStore(pScreen);
@@ -1962,7 +1966,9 @@ I810CloseScreen(int scrnIndex, ScreenPtr pScreen)
ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
vgaHWPtr hwp = VGAHWPTR(pScrn);
I810Ptr pI810 = I810PTR(pScrn);
+#ifdef XAA
XAAInfoRecPtr infoPtr = pI810-AccelInfoRec;
+#endif
if (pScrn-vtSema == TRUE) {
if (pI810-AccelInfoRec != NULL) {
@@ -1994,12 +2000,14 @@ I810CloseScreen(int scrnIndex, ScreenPtr pScreen)
pI810-ScanlineColorExpandBuffers = NULL;
}
+#ifdef XAA
if (infoPtr) {
if (infoPtr-ScanlineColorExpandBuffers)
free(infoPtr-ScanlineColorExpandBuffers);
XAADestroyInfoRec(infoPtr);
pI810-AccelInfoRec = NULL;
}
+#endif
if (pI810-CursorInfoRec) {
xf86DestroyCursorInfoRec(pI810-CursorInfoRec);
diff --git a/src/legacy/i810/i810_hwmc.c b/src/legacy/i810/i810_hwmc.c
index ba50e1e..43feb55 100644
--- a/src/legacy/i810/i810_hwmc.c
+++ b/src/legacy/i810/i810_hwmc.c
@@ -53,8 +53,10 @@ THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#include xf86xvmc.h
#include X11/extensions/Xv.h
#include X11/extensions/XvMC.h
+#ifdef XAA
#include xaa.h
#include xaalocal.h
Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working
Hello Daniel Your TV likely sends a CEA block with some HDMI default modes set. Since linux-3.3-rc1 (to be released in a few days) we should be able to decode that. Can you grab the latest -linus kernel git and try that? I wanted to remind, that the interlaced modes work with the noveau driver with the 3.0.0 Kernel. Do they ignore the kernel routines and have their own code ? [ 18.242858] [drm:drm_mode_debug_printmodeline], Modeline 28:1920x1080i 0 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x40 0x15 [ 18.242861] [drm:drm_mode_prune_invalid], Not using 1920x1080i mode 7 [ 18.242863] [drm:drm_mode_debug_printmodeline], Modeline 27:1920x1080i 0 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x48 0x15 [ 18.242865] [drm:drm_mode_prune_invalid], Not using 1920x1080i mode 7 At this point, does the drm driver call kernel routines and decide on your mentioned kernel routines return to ignore those modes ? Angela -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: 18 January 2012 00:13 To: Angela Schmid Cc: 'Alfonso Fiore'; 'Daniel Vetter'; intel-gfx@lists.freedesktop.org; 'Rodrigo Vivi' Subject: Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working On Tue, Jan 17, 2012 at 11:53:47PM +0100, Angela Schmid wrote: Over HDMI works: 1280x720@50hz 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync 1280x720@50hz (0xb4) 74.2MHz +HSync +VSync *current h: width 1280 start 1720 end 1760 total 1980 skew0 clock 37.5KHz v: height 720 start 725 end 730 total 750 clock 50.0Hz 1440x576ix0.0 27.00 1440 1464 1590 1728 576 580 586 625 interlace -hsync -vsync 1440x576ix0.0 (0xbd) 27.0MHz -HSync -VSync Interlace *current h: width 1440 start 1464 end 1590 total 1728 skew0 clock 15.6KHz v: height 576 start 580 end 586 total 625 clock 25.0Hz and 1440x288x0.0 27.00 1440 1464 1590 1728 288 290 293 312 -hsync -vsync Have a lot of horizontal overscan, vertical very small, useless. Yeah, many TVs send out a different edid depending upon what connector they are plugged in. Also we currently don't handle overscan compensation at all, Rodrigo is working on that. It is some time ago, that I compiled kernels myself. I compile drivers regularly. I will have a look next week. Your TV likely sends a CEA block with some HDMI default modes set. Since linux-3.3-rc1 (to be released in a few days) we should be able to decode that. Can you grab the latest -linus kernel git and try that? Too many ways described on one page: http://wiki.ubuntuusers.de/Kernel/Kompilierung Kernel.org links to kernel newbies website. Do you have a link how to compile/install ? Maybe ask on irc about what's suggested. Way back I've used Die klassische Debian-Methode. You need to compile a new kernel, the output handling part of the graphics driver is there. Best is to try the latest drm-intel-fixes tree available at: https://git.kernel.org/?p=linux/kernel/git/keithp/linux.git;a=shortlog;h=refs/heads/drm-intel-fixes Can I wait for the ppa:xorg-edgers ? If they track drm-intel-fixes, yeah. But you might want to try to compile the kernel, too, in case we have some additional patches for you to apply. Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
