Re: [Intel-gfx] [PATCH v2] drm/i915: fix long-standing SNB regression in power consumption after resume

On Wed, Jul 17, 2013 at 10:22:58AM +0400, Konstantin Khlebnikov wrote: > This patch fixes regression in power consumtion of sandy bridge gpu, which > exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that > it's extremely busy. After that it never reaches rc6 state. > > Bug

[Intel-gfx] [PATCH v2] drm/i915: fix long-standing SNB regression in power consumption after resume

This patch fixes regression in power consumtion of sandy bridge gpu, which exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that it's extremely busy. After that it never reaches rc6 state. Bug exists since kernel v3.6, commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 ("drm/

Re: [Intel-gfx] [Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8

On Wed, 2013-07-17 at 00:01 +0200, Rafael J. Wysocki wrote: > On Tuesday, July 16, 2013 05:08:16 PM Matthew Garrett wrote: > > On Tue, 2013-07-16 at 17:32 +0400, Igor Gnatenko wrote: > > > Hmm. I found regression in user-space. In GNOME (maybe and other DEs) we > > > no longer see switch status of

Re: [Intel-gfx] [PATCH] drm/i915: Make i915 events part of uapi

On Tue, Jul 16, 2013 at 04:41:13PM -0700, Ben Widawsky wrote: > Make the uevent strings part of the user API for people who wish to > write their own listeners. > > CC: Chad Versace > Signed-off-by: Ben Widawsky One thing I've toyed around with a bit is that we should add kerneldoc to our uapi

[Intel-gfx] [PATCH] drm/i915: Sanitize shared dpll state

There seems to be no limit to the amount of gunk the firmware can leave behind. Some platforms leave pch dplls on which are not in active use at all. The example in the bug report is a Apple Macbook Pro. Note that this escape scrunity of the hw state checker until we've tried to use this enabled,

Re: [Intel-gfx] Intel Crash

I send what you want(I guess), online and as attach Xorg Log Commands addr2line 2013/7/16 Chris Wilson > On Tue, Jul 16, 2013 at 09:58:45AM -0600, Oscar Dario Trujillo Tejada > wrote: > >I really hope that this help if don't,

Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell

Hi Takashi/Paulo, > > > would you change it to "auto" and test again. > > > Runtime power save should be enabled with "auto". > > > > Doesn't solve the problem. Should I open a bug report somewhere? > > Having the power well enabled prevents some power saving features from > > the graphics driver.

[Intel-gfx] [PATCH 5/5] [v5] drm/i915: Create VMAs

Formerly: "drm/i915: Create VMAs (part 1)" In a previous patch, the notion of a VM was introduced. A VMA describes an area of part of the VM address space. A VMA is similar to the concept in the linux mm. However, instead of representing regular memory, a VMA is backed by a GEM BO. There may be ma

[Intel-gfx] [PATCH 4/5] [v2] drm/i915: Move active/inactive lists to new mm

Shamelessly manipulated out of Daniel :-) "When moving the lists around explain that the active/inactive stuff is used by eviction when we run out of address space, so needs to be per-vma and per-address space. Bound/unbound otoh is used by the shrinker which only cares about the amount of memory u

[Intel-gfx] [PATCH 3/5] [v2] drm/i915: Create a global list of vms

After we plumb our code to support multiple address spaces (VMs), there are a few situations where we want to be able to traverse the list of all address spaces in the system. Cases like eviction, or error state collection are obvious example. v2: Delete the global link instead of the list head. W

[Intel-gfx] [PATCH 2/5] [v2] drm/i915: Put the mm in the parent address space

Every address space should support object allocation. It therefore makes sense to have the allocator be part of the "superclass" which GGTT and PPGTT will derive. Since our maximum address space size is only 2GB we're not yet able to avoid doing allocation/eviction; but we'd hope one day this beco

[Intel-gfx] [PATCH 1/5] [v3] drm/i915: Move gtt and ppgtt under address space umbrella

The GTT and PPGTT can be thought of more generally as GPU address spaces. Many of their actions (insert entries), state (LRU lists), and many of their characteristics (size) can be shared. Do that. The change itself doesn't actually impact most of the VMA/VM rework coming up, it just fits in with

[Intel-gfx] [PATCH] drm/i915: Make i915 events part of uapi

Make the uevent strings part of the user API for people who wish to write their own listeners. CC: Chad Versace Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_irq.c | 8 include/uapi/drm/i915_drm.h | 3 +++ 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/d

Re: [Intel-gfx] [Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8

On Tuesday, July 16, 2013 05:08:16 PM Matthew Garrett wrote: > On Tue, 2013-07-16 at 17:32 +0400, Igor Gnatenko wrote: > > Hmm. I found regression in user-space. In GNOME (maybe and other DEs) we no > > longer see switch status of backlight. > > Yeah, I can duplicate that. Rafael, we have to call

Re: [Intel-gfx] [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume

On Tue, 16 Jul 2013 22:43:49 +0200 Daniel Vetter wrote: > On Tue, Jul 16, 2013 at 01:19:25PM -0700, Jesse Barnes wrote: > > On Tue, 16 Jul 2013 10:06:54 -0700 > > Jesse Barnes wrote: > > > > > On Tue, 16 Jul 2013 11:34:25 +0400 > > > Konstantin Khlebnikov wrote: > > > > I've tested that patch

Re: [Intel-gfx] [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume

On Tue, Jul 16, 2013 at 01:19:25PM -0700, Jesse Barnes wrote: > On Tue, 16 Jul 2013 10:06:54 -0700 > Jesse Barnes wrote: > > > On Tue, 16 Jul 2013 11:34:25 +0400 > > Konstantin Khlebnikov wrote: > > > I've tested that patch and it really works for me. If you want change > > > something for other

Re: [Intel-gfx] [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume

On Tue, 16 Jul 2013 10:06:54 -0700 Jesse Barnes wrote: > On Tue, 16 Jul 2013 11:34:25 +0400 > Konstantin Khlebnikov wrote: > > I've tested that patch and it really works for me. If you want change > > something for other hardware or > > extend range where forcewake is held prease do it in a sepa

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Squash gen lookup through multiple indirections inside GT access

On Tue, Jul 16, 2013 at 9:30 PM, Paulo Zanoni wrote: > 2013/7/16 Chris Wilson : >> The INTEL_INFO() macro extracts the dev_private pointer from the device, >> so passing in the dev_private->dev is a long winded circumlocution. >> >> v2: rebase onto uncore >> >> Signed-off-by: Chris Wilson > > Rev

[Intel-gfx] [PATCH] Addendum: 915: Use a private interface for register access within GT

Remove the unrequired argument to the i915_read/write macros in i915_drv.h Please squash into above patch. --- drivers/gpu/drm/i915/i915_drv.h | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Squash gen lookup through multiple indirections inside GT access

2013/7/16 Chris Wilson : > The INTEL_INFO() macro extracts the dev_private pointer from the device, > so passing in the dev_private->dev is a long winded circumlocution. > > v2: rebase onto uncore > > Signed-off-by: Chris Wilson Reviewed-by: Paulo Zanoni I also wouldn't complain if you submitte

[Intel-gfx] [PATCH 6/6] drm/i915: Convert the register access tracepoint to be conditional

The TRACE_EVENT_CONDITION is supposed to generate more efficient code than if (cond) trace(), which is what we are currently using inside the register access functions. v2: Rebase onto uncore Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_t

[Intel-gfx] [PATCH 5/6] drm/i915: Squash gen lookup through multiple indirections inside GT access

The INTEL_INFO() macro extracts the dev_private pointer from the device, so passing in the dev_private->dev is a long winded circumlocution. v2: rebase onto uncore Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_uncore.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff

[Intel-gfx] [PATCH 4/6] drm/i915: Serialize all register access

In theory, the different register blocks were meant to be only ever touched when holding either the struct_mutex, mode_config.lock or even a specific localised lock. This does not seem to be the case, and the hardware reacts extremely badly if we attempt to concurrently access two registers within

[Intel-gfx] [PATCH 2/6] drm/i915: Use a private interface for register access within GT

The GT functions for enabling register access also need to occasionally write to and read from registers. To avoid the potential recursion as we modify the public interface to be stricter, introduce a private register access API for the GT functions. v2: Rebase v3: Rebase onto uncore v4: Use raw i

[Intel-gfx] [PATCH 3/6] drm/i915: Use the common register access functions for NOTRACE variants

Detangle the confusion that NOTRACE variants of the register read/write routines were directly using the raw register access. We need for those routines to reuse the common code for serializing register access and ensuring the correct register power states. This is only possible now that the only r

Re: [Intel-gfx] [PATCH 0/9] HW contest support for Ironlake

On Mon, Jul 15, 2013 at 01:44:13PM +0100, Chris Wilson wrote: > On Sun, Jul 14, 2013 at 09:22:44AM -0700, Ben Widawsky wrote: > > Finally, in the series I reenable rc6 on ILK. I've never had an issue > > with this on my ILK, but I recommend anyone testing on it who sees > > issues to try to disable

Re: [Intel-gfx] [Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8

On Tue, 2013-07-16 at 17:32 +0400, Igor Gnatenko wrote: > Hmm. I found regression in user-space. In GNOME (maybe and other DEs) we no > longer see switch status of backlight. Yeah, I can duplicate that. Rafael, we have to call acpi_video_init_brightness() even if we're not going to initialise the

Re: [Intel-gfx] [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume

On Tue, 16 Jul 2013 11:34:25 +0400 Konstantin Khlebnikov wrote: > I've tested that patch and it really works for me. If you want change > something for other hardware or > extend range where forcewake is held prease do it in a separate patch. > This will be good for bisecting new bugs in the futur

Re: [Intel-gfx] Intel Crash

On Tue, Jul 16, 2013 at 09:58:45AM -0600, Oscar Dario Trujillo Tejada wrote: >I really hope that this help if don't, I don't know what to do > >(EE) Backtrace: >(EE) 0: X (xorg_backtrace+0x49) [0x81d7eb9] >(EE) 1: X (0x8048000+0x193c24) [0x81dbc24] >(EE) 2: linux-gate.so.1 (__k

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Use a private interface for register access within GT

On Sun, Jul 14, 2013 at 12:48:29PM -0700, Ben Widawsky wrote: > If I am not mistaken, I915_*_NOTRACE would no longer be used after this > patch. Maybe removing those here would also help clarify what you're > doing, and make merge easier (in case someone adds a new one before this > gets merged). A

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Serialize all register access

On Sun, Jul 14, 2013 at 01:23:52PM -0700, Ben Widawsky wrote: > On Fri, Jul 12, 2013 at 06:08:25PM +0100, Chris Wilson wrote: > > In theory, the different register blocks were meant to be only ever > > touched when holding either the struct_mutex, mode_config.lock or even a > > specific localised l

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Convert the register access tracepoint to be conditional

On Sun, Jul 14, 2013 at 01:28:11PM -0700, Ben Widawsky wrote: > On Fri, Jul 12, 2013 at 06:08:27PM +0100, Chris Wilson wrote: > > The TRACE_EVENT_CONDITION is supposed to generate more efficient code > > than if (cond) trace(), which is what we are currently using inside the > > register access fun

Re: [Intel-gfx] [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume

On Tue, Jul 16, 2013 at 10:31 AM, Daniel Vetter wrote: > On Sun, Jul 14, 2013 at 09:56:45PM +0400, Konstantin Khlebnikov wrote: > > Daniel Vetter wrote: > > >On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov > > > wrote: > > >>This patch fixes regression in power consumtion of sandy bridge

Re: [Intel-gfx] Intel Crash

I really hope that this help if don't, I don't know what to do (EE) Backtrace: (EE) 0: X (xorg_backtrace+0x49) [0x81d7eb9] (EE) 1: X (0x8048000+0x193c24) [0x81dbc24] (EE) 2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xb77bb40c] (EE) 3: /usr/lib/xorg/modules/drivers/intel_drv.so (0xb70a+0x41

Re: [Intel-gfx] Intel Crash

On Tue, Jul 16, 2013 at 08:13:59AM -0600, Oscar Dario Trujillo Tejada wrote: >This is what I got > > > /var/abs/local/yaourtbuild/xf86-video-intel-git/src/xf86-video-intel-git/src/sna/blt.c:734 > > /var/abs/local/yaourtbuild/xf86-video-intel-git/src/xf86-video-intel-git/src/sna/kgem.c:

Re: [Intel-gfx] Intel Crash

This is what I got /var/abs/local/yaourtbuild/xf86-video-intel-git/src/xf86-video-intel-git/src/sna/blt.c:734 /var/abs/local/yaourtbuild/xf86-video-intel-git/src/xf86-video-intel-git/src/sna/kgem.c:2602 /var/abs/local/yaourtbuild/xf86-video-intel-git/src/xf86-video-intel-git/src/sna/kgem.c:3742 /v

Re: [Intel-gfx] [PATCH 08/11] drm/intel: add enable_psr module option and disable psr by default

On Mon, Jul 15, 2013 at 7:01 PM, Chris Wilson wrote: > On Mon, Jul 15, 2013 at 05:23:35PM -0300, Rodrigo Vivi wrote: >> On Mon, Jul 15, 2013 at 11:01 AM, Chris Wilson >> wrote: >> > On Thu, Jul 11, 2013 at 06:45:02PM -0300, Rodrigo Vivi wrote: >> >> v2: prefer seq_puts to seq_printf detected by

Re: [Intel-gfx] [Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8

Hmm. I found regression in user-space. In GNOME (maybe and other DEs) we no longer see switch status of backlight. -- Igor Gnatenko Fedora release 19 (Schrödinger’s Cat) Linux 3.11.0-0.rc0.git7.1.fc20.x86_64 ___ Intel-gfx mailing list Intel-gfx@lists.

Re: [Intel-gfx] [PATCH libdrm] intel: silence valgrind warnings for unsynchronized maps

On Wed, Jul 10, 2013 at 10:49:59AM +0800, Chia-I Wu wrote: > Mark the address ranges as accessible with VALGRIND_MAKE_MEM_DEFINED. > > Signed-off-by: Chia-I Wu lgtm. Applied to mater, thanks for the patch. -Daniel > --- > intel/intel_bufmgr_gem.c | 7 +++ > 1 file changed, 7 insertions(+)

Re: [Intel-gfx] [PATCH] tools/inter_error_decode: decode for ctl and acthd

On Fri, Jul 12, 2013 at 05:02:04PM +0300, Mika Kuoppala wrote: > Signed-off-by: Mika Kuoppala Applied, thanks for the patch. -Daniel > --- > tools/intel_error_decode.c | 35 +-- > 1 file changed, 33 insertions(+), 2 deletions(-) > > diff --git a/tools/intel_er

[Intel-gfx] [PULL] drm-intel-fixes

Hi Dave, [resend, somehow this was lost somewhere. At least I couldn't find it in the list archives.] One feature latecomer, I've forgotten to merge the patch to reeanble the Haswell power well feature now that the audio interaction is fixed up. Since that was the only unfixed issue with it I've

Re: [Intel-gfx] [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume

On Tue, Jul 16, 2013 at 08:32:40AM +0200, Daniel Vetter wrote: > On Sun, Jul 14, 2013 at 08:30:09PM +0400, Konstantin Khlebnikov wrote: > > This patch fixes regression in power consumtion of sandy bridge gpu, which > > exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking > > t

Re: [Intel-gfx] [Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8

On Tuesday, July 16, 2013 11:24:05 AM Aaron Lu wrote: > On 07/15/2013 07:42 PM, Rafael J. Wysocki wrote: > > On Monday, July 15, 2013 10:36:15 AM Aaron Lu wrote: > >> On 07/13/2013 08:46 AM, Rafael J. Wysocki wrote: > >>> From: Rafael J. Wysocki > >>> > >>> According to Matthew Garrett, "Windows 8

Re: [Intel-gfx] [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume

On Tue, Jul 16, 2013 at 10:31 AM, Chris Wilson wrote: > On Tue, Jul 16, 2013 at 09:44:59AM +0200, Daniel Vetter wrote: >> The issue I have with the current patch is that it looks a bit like >> duct-tape since the point where we drop the forcewake references seems to >> lack justification. The writ

Re: [Intel-gfx] [PATCH 08/10] drm/i915: Don't try to calculate RC6 residency on GEN4 and before

On Tue, Jul 16, 2013 at 10:34:06AM +0200, Daniel Vetter wrote: > Ok, I've merged the patches in this series for which I've found an r-b > tag. Some are still in limbo though. Thanks for doing that, I still need to answer questions from Paulo and the last two of them are 'hard' because we don't kno

Re: [Intel-gfx] Volunteer to implement Prefault testcase in intel_gpu_tools

Hi! Adding intel-gfx to keep everyone in the loop. On Tue, Jul 16, 2013 at 10:19 AM, Zhang, Xiong Y wrote: >This is Xiong from OSV enabling team in OTC BeiJing. > > My manager ask me to solve some intel graphic issues from OSV(ubuntu and > Suse), so recently I am always reading i915 driver,

Re: [Intel-gfx] [PATCH 5/7] drm/i915: queue hangcheck on reset

On Tue, Jul 16, 2013 at 10:49:29AM +0200, Daniel Vetter wrote: > On Wed, Jul 03, 2013 at 05:22:10PM +0300, Mika Kuoppala wrote: > > From: Mika Kuoppala > > > > Upon resetting the GPU, we begin processing batches once more, so > > reset the hangcheck timer. > > > > v2: kicking inside reset instea

Re: [Intel-gfx] [PATCH 5/7] drm/i915: queue hangcheck on reset

On Wed, Jul 03, 2013 at 05:22:10PM +0300, Mika Kuoppala wrote: > From: Mika Kuoppala > > Upon resetting the GPU, we begin processing batches once more, so > reset the hangcheck timer. > > v2: kicking inside reset instead of hangcheck_elapsed and > sane commit message by Chris Wilson > > Sig

Re: [Intel-gfx] [PATCH 4/7] drm/i915: no hangcheck when reset is in progress

On Wed, Jul 03, 2013 at 05:22:09PM +0300, Mika Kuoppala wrote: > From: Mika Kuoppala > > The timer for hangchecking can run again before the previous > reset it has triggered has been handled. This can corrupt > the hangcheck state as reset handling will access and write to > the hangcheck data.

Re: [Intel-gfx] [PATCH 08/10] drm/i915: Don't try to calculate RC6 residency on GEN4 and before

On Tue, Jun 11, 2013 at 11:03:40PM +0200, Daniel Vetter wrote: > On Tue, Jun 11, 2013 at 04:33:24PM -0300, Paulo Zanoni wrote: > > 2013/6/7 Damien Lespiau : > > > intel_enable_rc6() is used to check if we can compute the RC6 residency > > > in the sysfs code. Disable this for platforms older than I

Re: [Intel-gfx] [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume

On Tue, Jul 16, 2013 at 09:44:59AM +0200, Daniel Vetter wrote: > The issue I have with the current patch is that it looks a bit like > duct-tape since the point where we drop the forcewake references seems to > lack justification. The write to MBCTL itself will temporarily wake up the > chip, so ju

Re: [Intel-gfx] Intel Crash

On Mon, Jul 15, 2013 at 10:23:51PM -0600, Oscar Dario Trujillo Tejada wrote: >I put those commits because in the moment that they have been pushed my >system crash, should I make the bug report in [1]bugs.freedesktop.org or >with the one in the arch bugs, I'm fine? Neither of those are

Re: [Intel-gfx] [Update][PATCH] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8

On Tue, 2013-07-16 at 01:53 +0200, Rafael J. Wysocki wrote: > On Monday, July 15, 2013 05:06:09 PM Igor Gnatenko wrote: > > On Sat, 2013-07-13 at 02:46 +0200, Rafael J. Wysocki wrote: > > [...] > > > > > I can't build it. Where did I go wrong? > > Probably nowhere, you tried to build the ACPI

Re: [Intel-gfx] [PATCH] drm/i915: fix long-standing SNB regression in power consumption after resume

On Tue, Jul 16, 2013 at 11:34:25AM +0400, Konstantin Khlebnikov wrote: > On Tue, Jul 16, 2013 at 10:31 AM, Daniel Vetter wrote: > > > On Sun, Jul 14, 2013 at 09:56:45PM +0400, Konstantin Khlebnikov wrote: > > > Daniel Vetter wrote: > > > >On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov > >

[Intel-gfx] [PATCH 13/20] drm/gem: create drm_gem_dumb_destroy

All the gem based kms drivers really want the same function to destroy a dumb framebuffer backing storage object. So give it to them and roll it out in all drivers. This still leaves the option open for kms drivers which don't use GEM for backing storage, but it does decently simplify matters for

[Intel-gfx] [PATCH 01/20] drm: use common drm_gem_dmabuf_release in i915/exynos drivers

Note that this is slightly tricky since both drivers store their native objects in dma_buf->priv. But both also embed the base drm_gem_object at the first position, so the implicit cast is ok. To use the release helper we need to export it, too. Cc: Inki Dae Cc: Intel Graphics Development Signe