[Intel-gfx] [PATCH] allow 945 to control self refresh automatically
I changed 945's self refresh to work without the need for the driver to
enable/disable self refresh manually based on the idle state of the gpu.
This is much better than enabling/disabling self refresh for various
reasons, including staying in a lower power state for more time and
avoiding the need for cpu cycles.
Something must have been fixed in the driver between the initial
implementation of 945 self refresh and now.
(maybe 944001201ca0196bcdb088129e5866a9f379d08c: drm/i915: enable low
power render writes on GEN3 hardware?)
This patch probably doesn't cover all cases concerning if SR should
be enabled/disabled, not to mention doing things in the wrong order or
in the wrong place.
Signed-off-by: Alexander Lam lambchop...@gmail.com
Acked-by : Li Peng peng...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 37 ++---
1 files changed, 11 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fe56cb3..46f6878 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3316,7 +3316,7 @@ static void i9xx_update_wm(struct drm_device *dev, int
planea_clock,
int planea_wm, planeb_wm;
struct intel_watermark_params planea_params, planeb_params;
unsigned long line_time_us;
- int sr_clock, sr_entries = 0;
+ int sr_clock, sr_entries = 0, sr_enabled = 0;
/* Create copies of the base settings for each pipe */
if (IS_CRESTLINE(dev) || IS_I945GM(dev))
@@ -3363,8 +3363,11 @@ static void i9xx_update_wm(struct drm_device *dev, int
planea_clock,
if (srwm 0)
srwm = 1;
- if (IS_I945G(dev) || IS_I945GM(dev))
+ if (IS_I945G(dev) || IS_I945GM(dev)){
I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_FIFO_MASK | (srwm
0xff));
+ DRM_DEBUG_KMS(enable memory self refresh on 945\n);
+ sr_enabled = 1;
+ }
else if (IS_I915GM(dev)) {
/* 915M has a smaller SRWM field */
I915_WRITE(FW_BLC_SELF, srwm 0x3f);
@@ -3373,6 +3376,8 @@ static void i9xx_update_wm(struct drm_device *dev, int
planea_clock,
} else {
/* Turn off self refresh if both pipes are enabled */
if (IS_I945G(dev) || IS_I945GM(dev)) {
+ DRM_DEBUG_KMS(disable memory self refresh on 945\n);
+ sr_enabled = 0;
I915_WRITE(FW_BLC_SELF, I915_READ(FW_BLC_SELF)
~FW_BLC_SELF_EN);
} else if (IS_I915GM(dev)) {
@@ -3392,6 +3397,8 @@ static void i9xx_update_wm(struct drm_device *dev, int
planea_clock,
I915_WRITE(FW_BLC, fwater_lo);
I915_WRITE(FW_BLC2, fwater_hi);
+ if (sr_enabled)
+ I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_EN_MASK | FW_BLC_SELF_EN);
}
static void i830_update_wm(struct drm_device *dev, int planea_clock, int
unused,
@@ -5125,7 +5132,6 @@ static void intel_idle_update(struct work_struct *work)
struct drm_device *dev = dev_priv-dev;
struct drm_crtc *crtc;
struct intel_crtc *intel_crtc;
- int enabled = 0;
if (!i915_powersave)
return;
@@ -5139,16 +5145,11 @@ static void intel_idle_update(struct work_struct *work)
if (!crtc-fb)
continue;
- enabled++;
intel_crtc = to_intel_crtc(crtc);
if (!intel_crtc-busy)
intel_decrease_pllclock(crtc);
}
- if ((enabled == 1) (IS_I945G(dev) || IS_I945GM(dev))) {
- DRM_DEBUG_DRIVER(enable memory self refresh on 945\n);
- I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_EN_MASK | FW_BLC_SELF_EN);
- }
mutex_unlock(dev-struct_mutex);
}
@@ -5173,17 +5174,9 @@ void intel_mark_busy(struct drm_device *dev, struct
drm_i915_gem_object *obj)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return;
- if (!dev_priv-busy) {
- if (IS_I945G(dev) || IS_I945GM(dev)) {
- u32 fw_blc_self;
-
- DRM_DEBUG_DRIVER(disable memory self refresh on
945\n);
- fw_blc_self = I915_READ(FW_BLC_SELF);
- fw_blc_self = ~FW_BLC_SELF_EN;
- I915_WRITE(FW_BLC_SELF, fw_blc_self |
FW_BLC_SELF_EN_MASK);
- }
+ if (!dev_priv-busy)
dev_priv-busy = true;
- } else
+ else
mod_timer(dev_priv-idle_timer, jiffies +
msecs_to_jiffies(GPU_IDLE_TIMEOUT));
@@ -5195,14 +5188,6 @@ void intel_mark_busy(struct drm_device *dev, struct
drm_i915_gem_object *obj)
intel_fb = to_intel_framebuffer(crtc-fb);
if (intel_fb
Re: [Intel-gfx] [PATCH] allow 945 to control self refresh automatically
Hi,
I probably should mention that the patch is in reply to: (I got Li's ack here)
http://lists.freedesktop.org/archives/intel-gfx/2010-October/008302.html
School kept me busy since then and I haven't been able to find any free
time until this winter break to respin. (College unexpectedly took more time
than I imagined)
On Mon, Jan 3, 2011 at 2:33 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, 3 Jan 2011 13:28:56 -0500, Alexander Lam lambchop...@gmail.com
wrote:
I changed 945's self refresh to work without the need for the driver to
enable/disable self refresh manually based on the idle state of the gpu.
This is much better than enabling/disabling self refresh for various
reasons, including staying in a lower power state for more time and
avoiding the need for cpu cycles.
Something must have been fixed in the driver between the initial
implementation of 945 self refresh and now.
(maybe 944001201ca0196bcdb088129e5866a9f379d08c: drm/i915: enable low
power render writes on GEN3 hardware?)
Considering that there is no rationale in the git history as why it was
done manually, maybe you could explain the reason why it could not have
been automatically before? Was it simply causing hangs? Do you have any
measurements that show power/performance impacts of the switch?
It is explained in commit ee980b80
(same as Jesse says)
I don't have any measurements (although the absolute idle power savings
is the same before and after). The problem is that I don't really have a way
to reliably reproduce a workload situation for this and measure average
power consumption (I guess I could throw together a test, but I don't think
I have time for that). Anyway, this would totally solve the problem fixed
by 060e645a.
This patch probably doesn't cover all cases concerning if SR should
be enabled/disabled, not to mention doing things in the wrong order or
in the wrong place.
Does this patch introduce bugs? Certainly sounds like it does, but that may
have just been badly phrased.
What that really is is a disclaimer that I might be programming the
hardware's bits
in the wrong order (i.e. I don't know if we are allowed to write FW_BLC_SELF_EN
before writing the actual watermarks) because I don't have the hardware docs.
Reading the patch did raise one concern:
/* Turn off self refresh if both pipes are enabled */
if (IS_I945G(dev) || IS_I945GM(dev)) {
+ DRM_DEBUG_KMS(disable memory self refresh on 945\n);
+ sr_enabled = 0;
I915_WRITE(FW_BLC_SELF, I915_READ(FW_BLC_SELF)
~FW_BLC_SELF_EN);
This looks wrong, as elsewhere to disable self-refresh we do:
I915_WRITE(FW_BLC_SELF, (I915_READ(FW_BLC_SELF) | FW_BLC_SELF_EN_MASK)
~FB_BLC_SELF_EN);
This looks to be a bug in the original code, 33c5fd12, but does it mean
that upon applying your patch that we never disable SR, even when it is
not supported by the hardware configuration?
ee980b80 uses both methods, so I'm not sure. I figured going with the
original code would be best, but I'm not entirely sure without
docs. I didn't consider that the original code was incorrect, so it
may be because
the manual enable/disable could have masked the bug. I am not sure why this
issue didn't show up in testingshould I respin?
Also, is it possible for me to move
I915_WRITE(FW_BLC_SELF, FW_BLC_SELF_EN_MASK | FW_BLC_SELF_EN);
to before the watermark is written (to avoid needing sr_enabled; I
used sr_enabled
to keep the ordering of writing these bits the same compared to prior
to this patch)
-Chrs
--
Chris Wilson, Intel Open Source Technology Centre
Thanks,
--
Alexander Lam
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
On Mon, Sep 27, 2010 at 5:18 PM, Vasily Khoruzhick anars...@gmail.comwrote: On 26 of September 2010 13:53:35 Stefan Biereigel wrote: Hello Everyone, just to add on to reports of this problem, there was a Thread here in LKML some months ago targeting the same problem (but not really attacking it at the Chipset driver). As I have one of those Laptops with a 945GM-Chipset and am stuck with the same Problem (disabled tickless now as a workaround and set ticks to 1000) I could maybe do some testing of patches. So what I can summarize is what the others did before: Disabling CPU1 helps, adding nohz=off helps, changing the Clocksource afterwards helps, binding the Interrupt does NOT help. So here's the Link to the old Discussion with follow-ups, maybe you can get some furter information from there. http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-05/msg03696.html We targeted the BIOS itself as everyone in this thread happened to own an Phoenix BIOS with some special version string. best, Stefan Yep, my laptop has Phoenix BIOS too. Btw, this BIOS has buggy DSDT (thermal and battery don't work reliably without patching DSDT). But I tested with and without patched DSDT - so my custom DSDT is not cause of bug in my case. My laptop (original acer aspire one) uses an H2O Insyde BIOS. I had never heard of Insyde until I bought the computer. Apparently, Insyde's H2O line is EFI firmware -- Alexander Lam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Interrupt latency on some 945GM platforms
2010/9/26 Shaohua Li shaohua...@intel.com 2010/9/26 Stefan Biereigel secur...@biereigel-wb.de: Am 24.09.2010 21:51, schrieb Jesse Barnes: On Fri, 24 Sep 2010 22:48:36 +0300 Vasily Khoruzhickanars...@gmail.com wrote: On 24 of September 2010 22:39:01 Jesse Barnes wrote: On Thu, 16 Sep 2010 23:06:46 +0300 Vasily Khoruzhickanars...@gmail.com wrote: В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner написал: Ok. The problematic part of HPET was not the clocksource, it was the clock event device which failed to deliver interrupts occasionally. It was worth a try at least. Hm, it seems that jerky glxgears is not related to jerky keyboard events. Keyboard is jerky only in konsole (kde terminal emulator), it seems something happened it seems that font rendering performance is much worse in latest xf86-video-intel than in xf86-video-intel-2.12.0. Len just had me try a few things too: - maxcpus=1 lets things work - offlining cpu1 at runtime (echo 0 /sys/devices/system/cpu/cpu1/online) lets things work - binding the i915 interrupt to cpu 0 does *not* help Vasily and Paolo, do you both have Atom CPUs with hyperthreading enabled? Nope, I have Core2Duo T5500, dual-core, no hyperthreading :) Hm, well there goes the theory about Atom HT... Hello Everyone, just to add on to reports of this problem, there was a Thread here in LKML some months ago targeting the same problem (but not really attacking it at the Chipset driver). As I have one of those Laptops with a 945GM-Chipset and am stuck with the same Problem (disabled tickless now as a workaround and set ticks to 1000) I could maybe do some testing of patches. So what I can summarize is what the others did before: Disabling CPU1 helps, adding nohz=off helps, changing the Clocksource afterwards helps, binding the Interrupt does NOT help. So here's the Link to the old Discussion with follow-ups, maybe you can get some furter information from there. http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-05/msg03696.html We targeted the BIOS itself as everyone in this thread happened to own an Phoenix BIOS with some special version string. best, Stefan does disable msi help with 'pci=nomsi'? Didn't help for me - besides, according to the KMS driver code, MSI is disabled on 945G I thought that maybe *enabling* MSI might help, but it seems 945 doesn't support MSI according to the comments in the source. Hardware: Acer Aspire One Intel Atom N270 w/ 945GSE ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Alexander Lam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Possible compilation error in commit 6ef3d42
Hi, I think there may be a possibility of compilation error with drm-intel commit 6ef3d42 if CONFIG_DEBUG_FS isn't selected. commit 6ef3d4278034982c13df87c4a51e0445f762d316 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Wed Aug 4 20:26:07 2010 +0100 drm/i915: Capture the overlay status upon a GPU hang. v2: Add the interrupt status and address. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Eric Anholt e...@anholt.net this commit uses seq_printf, which is defined in include/linux/seq_file.h, which is included in include/drm/drm_mm.h only if CONFIG_DEBUG_FS is defined. some wrapping with #ifdefs may be needed Thanks for the great drivers, Alexander Lam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Intel Pineview 3150 DPMS not working (monitor doesn't power off)
On Sat, Aug 7, 2010 at 11:31 AM, Brian Hall hal...@gmail.com wrote: I have a nice little Atom motherboard, the D510MO, with the integrated Pineview graphics (GMA 3150). Everything works fine, but my LCD monitor never turns off. xset dpms force suspend turns off the screen image, but the monitor stays in on mode, and after a few seconds the monitor says Cable not connected. LCD turns off just fine with dpms suspend from other video cards. Console blanking doesn't work either: setterm -powersave on, although I didn't test that with other video cards. Is this a known problem with Intel KMS, or the xf86-video-intel driver? Just trying to figure out if I need to file a bug report against the kernel or xorg. I did find this closed bug but it didn't seem to resolve anything: https://bugs.freedesktop.org/show_bug.cgi?id=20294 I have installed the latest driver, xf86-video-intel-newest 2.12.0-1, but that didn't change the DPMS issue. Neither did updating the motherboard BIOS. uname -a Linux brain 2.6.35-ARCH #1 SMP PREEMPT Mon Aug 2 21:54:18 CEST 2010 x86_64 Intel(R) Atom(TM) CPU D510 @ 1.66GHz GenuineIntel GNU/Linux xf86-video-intel-newest 2.12.0-1 xorg-server 1.8.1.902-1 I'm using the autodefault xorg config (no /etc/X11/xorg.conf file). DPMS itself appears to be enabled and thinks it's working. # grep -i DPMS /var/log/Xorg.0.log [ 87.339] (II) Loading extension DPMS [ 87.663] (II) intel(0): DPMS capabilities: StandBy Suspend; RGB/Color Display [ 87.717] (==) intel(0): DPMS enabled 00:02.0 VGA compatible controller: Intel Corporation Pineview Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) Subsystem: Intel Corporation Device 4f4d Flags: bus master, fast devsel, latency 0, IRQ 47 Memory at f020 (32-bit, non-prefetchable) [size=512K] I/O ports at 20c0 [size=8] Memory at e000 (32-bit, prefetchable) [size=256M] Memory at f010 (32-bit, non-prefetchable) [size=1M] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Kernel driver in use: i915 Kernel modules: i915 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx I have an acer aspire one and on my old 17 CRT, I have to use xset dpms force standby. If i use xset dpms force suspend, the display does the same exact thing you describe. -- Alexander Lam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 945gm: xrandr crashes X
On Tue, May 25, 2010 at 5:18 AM, Vasily Khoruzhick anars...@gmail.com wrote: I've updated my xf86-video-intel and libdrm and this issue gone, but now I hit another bug - one with VSYNC on 945GM :( Is there any way to disable vsync wait? (It's disabled in driconf, but for some reason it remains enabled in apps) Regards Vasily ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx Regurgitating something I read on irc: to disable vsync wait, set env var vblank_mode=0 (or is it 3?) you need git mesa in order for that to work: This commit http://cgit.freedesktop.org/mesa/mesa/commit/?id=45e2b51c853471b79004a954ce3092a253b20b77 enables using that env var. -- Alexander Lam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
