Re: [Intel-gfx] [PATCH] Fix i915 drm regression on AOpen i915GMm-HFS motherboard
On Mon, 03 Jan 2011 15:25:05 +0100, Knut Petersen knut_peter...@t-online.de wrote: The AOpen i915GMm-HFS is a desktop motherboard for the Intel Pentium M. A mobile chipset is used (Intel 915GM / ICH6-M). Kernel 2.6.31.14 works fine for that mobo, but from 2.6.32 on graphics support is broken because the i915 driver detects an lvds device with a resolution of 1024x768 pixels that in reality is not present. Unfortunately the driver assumes that the detected lvds is the primary screen and uses the wrong resolution also for the real VGA and DVI connectors. Can you try: diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index 58040f6..28d 100644 --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -384,7 +384,7 @@ int intel_setup_gmbus(struct drm_device *dev) bus-reg0 = i | GMBUS_RATE_100KHZ; /* XXX force bit banging until GMBUS is fully debugged */ - bus-force_bit = intel_gpio_create(dev_priv, i); + //bus-force_bit = intel_gpio_create(dev_priv, i); } intel_i2c_reset(dev_priv-dev); -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] drm-nvidia-switch git branch but still vgaswitcheroo not working for i915/nvidia (nouveau) on ASUS U30JC
Hello. In my double-carded ASUS U30JC (nvidia + intel i915) I do the following: stop X This is the output of /sys/kernel/debug/vgaswitcheroo/switch daphne linux # cat /sys/kernel/debug/vgaswitcheroo/switch 0: :Pwr::01:00.0 1:+:Pwr::00:02.0 (intel graphic card in use, ok) echo DDIS /sys/kernel/debug/vgaswitcheroo/switch does not change the output above (intel remains marked as active) echo OFF /sys/kernel/debug/vgaswitcheroo/switch seems to switch off Nvidia card, because the output above becomes: 0: :Off::01:00.0 1:+:Pwr::00:02.0 restarting X completely freezes the machine, black screen (need to power down by pressing the power button). ASUS U30JC Nvidia (nouveau) + intel i915. Kernel 2.6.35 x11-base/xorg-server 1.9.2.902 x11-drivers/xf86-video-nouveau 0.0.16_pre20101010 Shutting down the Nvidia graphic card via acpi_call https://github.com/mkottman/acpi_call produces the same freeze after trying to restart X. Same problem with kernel 2.6.36 and acpi_call. Did not try vga switcheroo on 2.6.36 due to problems with that kernel https://bugzilla.kernel.org/show_bug.cgi?id=24542 echo OFF /sys/kernel/debug/vgaswitcheroo/switch produces in dmesg: Dec 8 00:06:18 daphne kernel: VGA switcheroo: switched nouveau off Dec 8 00:06:18 daphne kernel: [drm] nouveau :01:00.0: Disabling fbcon acceleration... Dec 8 00:06:18 daphne kernel: [drm] nouveau :01:00.0: Unpinning framebuffer(s)... Dec 8 00:06:18 daphne kernel: [drm] nouveau :01:00.0: Evicting buffers... Dec 8 00:06:18 daphne kernel: [drm] nouveau :01:00.0: Idling channels... Dec 8 00:06:18 daphne kernel: [drm] nouveau :01:00.0: Suspending GPU objects... Dec 8 00:06:19 daphne kernel: [drm] nouveau :01:00.0: And we're gone! Dec 8 00:06:19 daphne kernel: nouveau :01:00.0: PCI INT A disabled Dec 8 00:06:19 daphne kernel: nouveau :01:00.0: power state changed by ACPI to D3 which seems to be correct. The crash taking place when restarting X does not leave any trace on dmesg. 2010/12/13 Dave Airlie airl...@gmail.com: - Ocultar texto citado - On Sun, Dec 12, 2010 at 12:05 AM, Giacomo dellece...@gmail.com wrote: Hello. In my double-carded ASUS U30JC (nvidia + intel i915) I do the following: You might want to try the branch in my drm-testing repo http://git.kernel.org/?p=linux/kernel/git/airlied/drm-testing.git;a=shortlog;h=refs/heads/drm-nvidia-switch Has much improvements for gpu switching on intel/nvidia. Dave. The branch code does not solve the situation: both echo DDIS /sys/kernel/debug/vgaswitcheroo/switch and echo OFF /sys/kernel/debug/vgaswitcheroo/switch hang the machine. The first command hangs immediately, the second at X restart. DMESG out in the first case: Dec 21 22:46:10 daphne kernel: fbcon: Remapping primary device, fb0, to tty 1-63 Dec 21 22:46:10 daphne kernel: calling mux switch 0 Dec 21 22:46:10 daphne kernel: mux switched 0 Dec 21 22:46:10 daphne kernel: ACPI Error: Needed [Buffer/String/Package], found [Integer] 880146f23420 (20101013/exresop-590) Dec 21 22:46:10 daphne kernel: ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20101013/dswexec-460) Dec 21 22:46:10 daphne kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.GFX0._DSM] (Node 880147c6d1c8), AE_AML_OPERAND_TYPE (20101013/psparse-537) Dec 21 22:46:10 daphne kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEG1.GFX0._DSM] (Node 880147c83830), AE_AML_OPERAND_TYPE (20101013/psparse-537) Dec 21 22:46:10 daphne kernel: failed to evaluate _DSM: 12291 Dec 21 22:46:10 daphne kernel: vga_switcheroo: switching failed stage 2 12291 -- here need to press power button to force shutdown --- Second case (echo OFF...): Dec 21 22:43:44 daphne kernel: VGA switcheroo: switched nouveau off Dec 21 22:43:44 daphne kernel: [drm] nouveau :01:00.0: Disabling fbcon acceleration... Dec 21 22:43:44 daphne kernel: [drm] nouveau :01:00.0: Unpinning framebuffer(s)... Dec 21 22:43:44 daphne kernel: [drm] nouveau :01:00.0: Evicting buffers... Dec 21 22:43:44 daphne kernel: [drm] nouveau :01:00.0: Idling channels... Dec 21 22:43:44 daphne kernel: [drm] nouveau :01:00.0: Suspending GPU objects... Dec 21 22:43:45 daphne kernel: [drm] nouveau :01:00.0: And we're gone! Dec 21 22:43:45 daphne kernel: nouveau :01:00.0: PCI INT A disabled Dec 21 22:43:45 daphne kernel: nouveau :01:00.0: power state changed by ACPI to D3 starting X hangs the machine immediately. Let me know if I can help more. Hope to hearing from you soon, Giacomo, Italy. -- Giacomo S. http://www.giacomos.it - - - - - - - - - - - - - - - - - - - - - - * iqfire-wall, un progetto open source che implementa un filtro di pacchetti di rete per Linux, e` disponibile per il download qui: http://sourceforge.net/projects/ipfire-wall * Informazioni e pagina web ufficiale: http://www.giacomos.it/iqfire/index.html - - - - - - - - - - - - - - - -
[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
Re: [Intel-gfx] [PATCH] allow 945 to control self refresh automatically
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?
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.
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?
-Chrs
--
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] allow 945 to control self refresh automatically
On Mon, 03 Jan 2011 19:33:05 + 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? Yes, it would hang before, but only on some platforms. It's likely related to the low power render writes issue... -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Fix i915 drm regression on AOpen i915GMm-HFS motherboard
On Mon, Jan 3, 2011 at 10:12 AM, Knut Petersen knut_peter...@t-online.de wrote: I tried 2.6.37-rc8-git2 with both patches applied. I thought Chris meant instead of, rather than both. Chris? Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Fix i915 drm regression on AOpen i915GMm-HFS motherboard
On Mon, 3 Jan 2011 11:45:48 -0800, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, Jan 3, 2011 at 10:12 AM, Knut Petersen knut_peter...@t-online.de wrote: I tried 2.6.37-rc8-git2 with both patches applied. I thought Chris meant instead of, rather than both. Chris? Right, I was trying to ascertain whether the intel_lvds_ddc_probe() correctly detected the missing panel. That function currently requires GMBUS to differentiate between a NAK and an IO error (bitbanging just returns EREMOTEIO regardless, iirc). So far it has been successful in detecting one false-positive for an AOpen All-in-one and hasn't fouled up LVDS detection for the laptops I have. -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] Fix i915 drm regression on AOpen i915GMm-HFS motherboard
[ related, but independent, issue ] On Mon, Jan 3, 2011 at 11:59 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: That function currently requires GMBUS to differentiate between a NAK and an IO error (bitbanging just returns EREMOTEIO regardless, iirc). Hmm. That sounds like something that would be worth fixing regardless and independently of this. I'd expect that a lot of users would care whether there was an actual protocol error or whether the command got a NAK. There's a big difference between those lines don't seem to even be connected to anything and the other end didn't like us. Even the comments in the bitbanging code seem to say that it should be returning ETIMEDOUT etc for when there is no answer (and the low-level i2c_outb() seems to do that), but then the code does seem to ignore all that information and turn all errors into EREMOTEIO. Which sounds bogus. Added Jean to the cc in case he has some input (or knows who we should bug about algo-bit.c). Also David Brownell, because he touched an error code in that file two and a half years ago, so he now owns it forever ;) Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] xv: Fix interlace computation
scrn-currentMode is a hack for xf86vidmode and in general is wrong for
RANDRful drivers. Use the mode on the associated CRTC instead.
Signed-off-by: Adam Jackson a...@redhat.com
---
src/intel_video.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/intel_video.c b/src/intel_video.c
index cdff149..d086cbf 100644
--- a/src/intel_video.c
+++ b/src/intel_video.c
@@ -1348,7 +1348,7 @@ intel_wait_for_scanline(ScrnInfoPtr scrn, PixmapPtr
pixmap,
event = MI_WAIT_FOR_PIPEB_SVBLANK;
}
- if (scrn-currentMode-Flags V_INTERLACE) {
+ if (crtc-mode (crtc-mode-Flags V_INTERLACE)) {
/* DSL count field lines */
y1 /= 2;
y2 /= 2;
--
1.7.3.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] dri2: Fix interlace computation
scrn-currentMode is a hack for xf86vidmode and in general is wrong for
RANDRful drivers. Use the mode on the associated CRTC instead.
Signed-off-by: Adam Jackson a...@redhat.com
---
src/intel_dri.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/intel_dri.c b/src/intel_dri.c
index 7096369..0e74b7d 100644
--- a/src/intel_dri.c
+++ b/src/intel_dri.c
@@ -433,8 +433,7 @@ I830DRI2CopyRegion(DrawablePtr drawable, RegionPtr pRegion,
/* Wait for the scanline to be outside the region to be copied */
if (pixmap_is_scanout(get_drawable_pixmap(dst))
- intel-swapbuffers_wait
- scrn-currentMode) {
+ intel-swapbuffers_wait) {
BoxPtr box;
BoxRec crtcbox;
int y1, y2;
@@ -449,7 +448,7 @@ I830DRI2CopyRegion(DrawablePtr drawable, RegionPtr pRegion,
* Make sure the CRTC is valid and this is the real front
* buffer
*/
- if (crtc != NULL !crtc-rotatedData) {
+ if (crtc != NULL crtc-mode !crtc-rotatedData) {
pipe = intel_crtc_to_pipe(crtc);
/*
@@ -485,7 +484,7 @@ I830DRI2CopyRegion(DrawablePtr drawable, RegionPtr pRegion,
event = MI_WAIT_FOR_PIPEB_SVBLANK;
}
- if (scrn-currentMode-Flags V_INTERLACE) {
+ if (crtc-mode-Flags V_INTERLACE) {
/* DSL count field lines */
y1 /= 2;
y2 /= 2;
--
1.7.3.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] dri2: Fix interlace computation
On Mon, 3 Jan 2011 17:52:27 -0500, Adam Jackson a...@redhat.com wrote: scrn-currentMode is a hack for xf86vidmode and in general is wrong for RANDRful drivers. Use the mode on the associated CRTC instead. Thanks Adam, that looks much saner than scrn-currentMode. Fixed up the Ptr/Rec confusion and pushed. -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] Crash of repeated playback using libva and gstreamer
On Mon, 2011-01-03 at 14:54 +0800, Jyotsana wrote: Hi, I am trying to play multiple video files one after the other using GStreamer(vaapidecode and vaapisink plugins) and libVA-1.0.3. I am able to play one file successfully but once the first file is played to completion, we delete all references of the first pipeline and create a new one. I can play multiple videos (MPEG2 H.264) with mplayer_vaapi. Does GStreamer call vaTerminate after playing a file? Could you try the latest master branch? If you still experience this issue, please file a bug to track it. Thanks Haihao When the second file is played, application crashes with the following error: libva: libva version 0.31.1 libva: va_getDriverName() returns 0 libva: Trying to open /opt/X11R7/lib/dri/i965_drv_video.so libva: va_openDriver() returns 0 libva: libva version 0.31.1 libva: va_getDriverName() returns 0 libva: Trying to open /opt/X11R7/lib/dri/i965_drv_video.so libva: va_openDriver() returns 0 VaapiApp: i965_media.c:277: i965_media_decode_picture: Assertion `media_state-media_states_setup' failed. Following is the backtrace obtained from gdb: i965_media_decode_picture: Assertion `media_state-media_states_setup' failed. # 0xb7fff424 in __kernel_vsyscall () # #1 0x00414d71 in raise () from /lib/libc.so.6 # #2 0x0041664a in abort () from /lib/libc.so.6 # #3 0x0040dde8 in __assert_fail () from /lib/libc.so.6 # #4 0xb71531d5 in i965_media_decode_picture (ctx=0xaeb19760, profile=VAProfileMPEG2Main, decode_state=0xaeb1a524) at i965_media.c:277 # #5 0xb715afcf in i965_EndPicture (ctx=0xaeb19760, context=33554432) at i965_drv_video.c:1146 # #6 0xb7d8cec5 in vaEndPicture (dpy=0xaeb1e960, context=33554432) at va.c:815 # #7 0xb5f73a85 in render_picture (s=0xb0701c00) at libavcodec/vaapi.c:74 # #8 ff_vaapi_common_end_frame (s=0xb0701c00) at libavcodec/vaapi.c:188 # #9 0xb5d37c0b in slice_end (avctx=0xb0701400, picture=0xb0740940, data_size=0xb10fef24, buf=0xb0704600 , buf_size=18936) at libavcodec/mpeg12.c:1935 # #10 decode_chunks (avctx=0xb0701400, picture=0xb0740940, data_size=0xb10fef24, buf=0xb0704600 , buf_size=18936) at libavcodec/mpeg12.c:2303 # #11 0xb5d39290 in mpeg_decode_frame (avctx=0xb0701400, data=0xb0740940, data_size=0xb10fef24, avpkt=0xb10fee64) at libavcodec/mpeg12.c:2272 # #12 0xb5e2de35 in avcodec_decode_video2 (avctx=0xb0701400, picture=0xb0740940, got_picture_ptr=0xb10fef24, buf=0xb0704600 , buf_size=18936) at libavcodec/utils.c:611 # #13 avcodec_decode_video (avctx=0xb0701400, picture=0xb0740940, got_picture_ptr=0xb10fef24, buf=0xb0704600 , buf_size=18936) at libavcodec/utils.c:597 # #14 0xb5be3392 in decode_frame (decoder=0xafd03478, buffer=0xae91b9e0) at gstvaapidecoder_ffmpeg.c:483 # #15 gst_vaapi_decoder_ffmpeg_decode (decoder=0xafd03478, buffer=0xae91b9e0) at gstvaapidecoder_ffmpeg.c:566 # #16 0xb5bd74ad in decode_step (decoder=0xafd03478, pstatus=0xb10ff00c) at gstvaapidecoder.c:117 # #17 gst_vaapi_decoder_get_surface (decoder=0xafd03478, pstatus=0xb10ff00c) at gstvaapidecoder.c:422 # #18 0xb7fe5105 in gst_vaapidecode_step (pad=0xb7036008, buf=0xae91b9e0) at gstvaapidecode.c:116 # #19 gst_vaapidecode_chain (pad=0xb7036008, buf=0xae91b9e0) at gstvaapidecode.c:536 # #20 0x420dfacd in gst_pad_chain_data_unchecked (pad=0xb7036008, is_buffer=1, data=0xae91b9e0) at gstpad.c:4131 # #21 0x420e04e7 in gst_pad_push_data (pad=0xb70363f0, is_buffer=1, data=0xae91b9e0) at gstpad.c:4360 # #22 0xb71e2655 in gst_queue_push_one (pad=0xb70363f0) at gstqueue.c:1083 # #23 gst_queue_loop (pad=0xb70363f0) at gstqueue.c:1185 # #24 0x4210ba11 in gst_task_func (task=0xb70570b0) at gsttask.c:271 # #25 0x4210d047 in default_func (tdata=0xaeb00d58, pool=0xb7408c08) at gsttaskpool.c:68 # #26 0x0066e214 in ?? () from /lib/libglib-2.0.so.0 # #27 0x0066c210 in ?? () from /lib/libglib-2.0.so.0 # #28 0x00585919 in start_thread () from /lib/libpthread.so.0 # #29 0x004c7e5e in clone () from /lib/libc.so.6 I am running this on Fedora Core 13 on Calpella Platform. What could be the problem? :-( Regards, Jyotsana. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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
