Hi Takashi,
In order to let audio power-save work even with charger connected, two
parameters need be modified in userspace pm-utils scripts.
I tested the changes under Ubuntu 13.10 on Harris Beach, no matter charger
connected or not, runtime power-saving works and power-well will
Be released
On Wed, Jul 24, 2013 at 05:04:43PM -0700, Jesse Barnes wrote:
Systems with Intel graphics controllers set aside memory exclusively for
gfx driver use. This memory is not marked in the E820 as reserved or as
RAM, and so is subject to overlap from E820 manipulation later in the
boot process.
Hi Jan!
Jan Niggemann writes:
Hi Egbert,
[...]
Thanks for generating the logs! Hope you had a nice birthday dinner :)
I applied this patch (but not the one you sent on Monday), recompiled
and logged:
uncompressed (8,2M) http://files.hz6.de/kern_20130724.log
bz2 (288 KB)
On Thu, 25 Jul 2013, Rafael J. Wysocki r...@sisk.pl wrote:
On Wednesday, July 24, 2013 02:05:15 PM Linus Torvalds wrote:
On Wed, Jul 24, 2013 at 2:02 PM, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
I think a i915 module option should be doable, otoh people seem to have a
viable
On Thu, Jul 25, 2013 at 09:41:49AM +0200, Daniel Vetter wrote:
On Wed, Jul 24, 2013 at 05:04:43PM -0700, Jesse Barnes wrote:
Two bikesheds:
- Can't we give the thing a better name like Intel Graphics Stolen?
Using a custom type and name seems simple enough and naturally leads it
to ending up
On Thu, Jul 25, 2013 at 09:34:05AM +0100, Chris Wilson wrote:
On Thu, Jul 25, 2013 at 09:41:49AM +0200, Daniel Vetter wrote:
On Wed, Jul 24, 2013 at 05:04:43PM -0700, Jesse Barnes wrote:
Two bikesheds:
- Can't we give the thing a better name like Intel Graphics Stolen?
Using a custom
On Fri, Jul 19, 2013 at 08:36:56PM +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 functions.
v2: Rebase onto uncore
Signed-off-by: Chris Wilson
On Wed, Jul 24, 2013 at 11:01:08PM +0100, Chris Wilson wrote:
On Wed, Jul 24, 2013 at 10:40:23PM +0200, Daniel Vetter wrote:
Just use a spinlock to protect them.
v2: Rebase onto the new object create refcount fix patch.
v3: Don't kill dev_priv-mm.object_memory as requested by Chris
By giving the stolen a region a unique type and name, we then insert it
into the iomem_resource as a known resource. This clear identifies it to
the user when printing the e820 map (and later the iomem resources), and
exposes it to the driver for later use.
Signed-off-by: Chris Wilson
This is useful for drivers to find a resource inserted by, for example,
an early PCI quirk.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
include/linux/ioport.h | 2 ++
kernel/resource.c | 14 ++
2 files changed, 16 insertions(+)
diff --git a/include/linux/ioport.h
As we now hook into the early PCI quirk table to earmark the Intel
Graphics Stolen region (inserting it into the iomem_resource) to prevent
it conflicting with any later resource allocations, we can simply walk
the iomem_resource tree and find it for our use. Thereby removing all of
our own code
.
The staging tree gained a build failure for which I disabled a driver.
[ CCing drm and drm-intel folks ]
With today's next-20130725 I see the following:
Use of dev_priv-gt_lock in I915_WRITE through
Daniel Vetter writes:
I've checked the docs again for gm45 and we seem to have the right
values. But on early gen4 (i.e. i965g/gm) the Bspec has been wrong
about these, so I wouldn't be surprised at all if they're wrong for
the digital ports on gm45, too.
Iirc we've already had a
On muxed systems, the other vgaswitcheroo client may depend on i915 to
handle the backlight. We began switching off the backlight since
commit a261b246ebd552fd5d5a8ed84cc931bb821c427f
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Thu Jul 26 19:21:47 2012 +0200
drm/i915: disable all
On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:
On Thu, 25 Jul 2013, Rafael J. Wysocki r...@sisk.pl wrote:
On Wednesday, July 24, 2013 02:05:15 PM Linus Torvalds wrote:
On Wed, Jul 24, 2013 at 2:02 PM, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
I think a i915 module option
On Thu, 25 Jul 2013, Rafael J. Wysocki r...@sisk.pl wrote:
On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:
On Thu, 25 Jul 2013, Rafael J. Wysocki r...@sisk.pl wrote:
Well, I wonder what about the appended (untested) patch?
Rafael, before going there, I've been trying to wrap my
On Thursday, July 25, 2013 03:34:10 PM Jani Nikula wrote:
On Thu, 25 Jul 2013, Rafael J. Wysocki r...@sisk.pl wrote:
On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote:
On Thu, 25 Jul 2013, Rafael J. Wysocki r...@sisk.pl wrote:
Well, I wonder what about the appended (untested) patch?
On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki r...@sisk.pl wrote:
Linus, do you want me to send a pull request reverting 8c5bd7a and
efaa14c?
Yes, but
This fixes a typo which set the wrong vsync and possibly also hsync
polarity for any modes with positive vsync polarity.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/dvo_ch7xxx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
.
[ CCing drm and drm-intel folks ]
With today's next-20130725 I see the following:
Use of dev_priv-gt_lock in I915_WRITE through
intel_disable_gt_powersave before spin lock init, caused by
commit 181d1b9e31c668259d3798c521672afb8edd355c
Author: Daniel Vetter
On Thu, Jul 25, 2013 at 04:22:31PM +0300, Imre Deak wrote:
This fixes a typo which set the wrong vsync and possibly also hsync
polarity for any modes with positive vsync polarity.
Note that this typo exists in the very first import of KMS:
commit 79e539453b34e35f39299a899d263b0a1f1670bd
Author:
On Thu, Jul 25, 2013 at 02:45:05PM +0100, Chris Wilson wrote:
On Thu, Jul 25, 2013 at 04:22:31PM +0300, Imre Deak wrote:
This fixes a typo which set the wrong vsync and possibly also hsync
polarity for any modes with positive vsync polarity.
Note that this typo exists in the very first
On Thu, Jul 25, 2013 at 9:00 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki r...@sisk.pl
wrote:
Linus, do you want
a driver.
[ CCing drm and drm-intel folks ]
With today's next-20130725 I see the following:
Use of dev_priv-gt_lock in I915_WRITE through
intel_disable_gt_powersave before spin lock init, caused by
commit
build failure.
The staging tree gained a build failure for which I disabled a
driver.
[ CCing drm and drm-intel folks ]
With today's next-20130725 I see the following:
Use of dev_priv
On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote:
On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki r...@sisk.pl wrote:
Linus, do you want me to send a
On Thu, Jul 25, 2013 at 07:43:17AM -0700, Kamal Mostafa wrote:
On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote:
On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
On Mon, Jul 22, 2013 at 6:02 AM, Rafael J.
On Thu, 2013-07-25 at 16:46 +0200, Daniel Vetter wrote:
On Thu, Jul 25, 2013 at 07:43:17AM -0700, Kamal Mostafa wrote:
On Thu, 2013-07-25 at 15:00 +0200, Rafael J. Wysocki wrote:
On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
On Monday, July 22, 2013 11:11:54 AM Linus
]
With today's next-20130725 I see the following:
Use of dev_priv-gt_lock in I915_WRITE through
intel_disable_gt_powersave before spin lock init, caused by
commit 181d1b9e31c668259d3798c521672afb8edd355c
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Sun Jul 21 13:16:24 2013
.
[ CCing drm and drm-intel folks ]
With today's next-20130725 I see the following:
Use of dev_priv-gt_lock in I915_WRITE through
intel_disable_gt_powersave before spin lock init, caused by
commit 181d1b9e31c668259d3798c521672afb8edd355c
disabled a
driver.
[ CCing drm and drm-intel folks ]
With today's next-20130725 I see the following:
Use of dev_priv-gt_lock in I915_WRITE through
intel_disable_gt_powersave before spin lock
build failure.
The staging tree gained a build failure for which I disabled a
driver.
[ CCing drm and drm-intel folks ]
With today's next-20130725 I see the following:
Use of dev_priv
On Thu, Jul 25, 2013 at 06:11:18PM +0200, Sedat Dilek wrote:
Might be OT, but I cannot use my X graphics stack containing
libdrm-2.4.46, mesa-9.1.5 and intel-ddx 2.21.12-git (tried also
v2.21.11).
Switching back to the one from Ubuntu/precise lets my X start.
[40.379] (II) AIGLX:
Patch 2/2 has the description, but suffice it to say I'm not really
pleased with this, though it does solve a problem we have. On some
machines, we get MMIO space allocated on top of this hidden memory,
which can cause problems. I'm not sure if there are similar problems
for other hunks of the
For use by userspace (at some point in the future) and other kernel code.
v2: move PCI IDs to uabi (Chris)
move PCI IDs to drm/ (Dave)
v3: fixup Quanta detection - needs to come first (Daniel)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.c | 164
Systems with Intel graphics controllers set aside memory exclusively for
gfx driver use. This memory is not marked in the E820 as reserved or as
RAM, and so is subject to overlap from E820 manipulation later in the
boot process. On some systems, MMIO space is allocated on top, despite
the
On 07/24/2013 05:04 PM, Jesse Barnes wrote:
For use by userspace (at some point in the future) and other kernel code.
v2: move PCI IDs to uabi (Chris)
move PCI IDs to drm/ (Dave)
v3: fixup Quanta detection - needs to come first (Daniel)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Art confirms that this should work fine. Since most panels are 18bpp
with dithering from 24bpp, the existing code wouldn't be enabled in most
cases.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 file changed, 1 insertion(+), 1
On Thu, Jul 25, 2013 at 10:06:50AM -0700, Jesse Barnes wrote:
Art confirms that this should work fine. Since most panels are 18bpp
with dithering from 24bpp, the existing code wouldn't be enabled in most
cases.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
On Thu, Jul 25, 2013 at 07:15:03PM +0200, Sedat Dilek wrote:
On Thu, Jul 25, 2013 at 7:01 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Basically boils down to either an object allocation failure or mmaping
failure. I think dmesg with drm.debug=7 is the next step.
Attached! Thanks for
On Thu, 25 Jul 2013 18:17:59 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, Jul 25, 2013 at 10:06:50AM -0700, Jesse Barnes wrote:
Art confirms that this should work fine. Since most panels are 18bpp
with dithering from 24bpp, the existing code wouldn't be enabled in most
On Thu, Jul 25, 2013 at 7:27 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Thu, 25 Jul 2013 18:17:59 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, Jul 25, 2013 at 10:06:50AM -0700, Jesse Barnes wrote:
Art confirms that this should work fine. Since most panels are 18bpp
On Thu, Jul 25, 2013 at 7:52 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Thu, Jul 25, 2013 at 7:26 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Thu, Jul 25, 2013 at 07:15:03PM +0200, Sedat Dilek wrote:
On Thu, Jul 25, 2013 at 7:01 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Thu, Jul 25, 2013 at 07:52:22PM +0200, Sedat Dilek wrote:
On Thu, Jul 25, 2013 at 7:26 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Thu, Jul 25, 2013 at 07:15:03PM +0200, Sedat Dilek wrote:
On Thu, Jul 25, 2013 at 7:01 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Thu, Jul 25, 2013 at 08:03:06PM +0200, Sedat Dilek wrote:
On Thu, Jul 25, 2013 at 7:55 PM, Sedat Dilek sedat.di...@gmail.com wrote:
F*ck. Wrong patch refreshed.
New dmesg attached.
Hmm, not seeing any difference, so let's add a couple more lines just to
be sure:
(apologies I didn't
On Thu, Jul 25, 2013 at 8:45 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, Jul 25, 2013 at 08:03:06PM +0200, Sedat Dilek wrote:
On Thu, Jul 25, 2013 at 7:55 PM, Sedat Dilek sedat.di...@gmail.com wrote:
F*ck. Wrong patch refreshed.
New dmesg attached.
Hmm, not seeing any
On Thu, Jul 25, 2013 at 08:50:59PM +0200, Sedat Dilek wrote:
Against what tree is this applicable? It is definitely not drm-intel-nightly.
Applied cleanly to nightly here, but just in case here's a rebased version:
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
On Thu, Jul 25, 2013 at 09:12:41PM +0200, Sedat Dilek wrote:
New -3 dmesg.
That puts the ball back in the ddx's court. Next debugging patch:
diff --git a/src/intel_driver.c b/src/intel_driver.c
index f4d76bb..1f4f299 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@ -170,6 +170,7 @@
On Thursday, July 25, 2013 08:14:08 PM James Hogan wrote:
On 25 July 2013 14:00, Rafael J. Wysocki r...@sisk.pl wrote:
On Monday, July 22, 2013 09:54:21 PM Rafael J. Wysocki wrote:
On Monday, July 22, 2013 11:11:54 AM Linus Torvalds wrote:
On Mon, Jul 22, 2013 at 6:02 AM, Rafael J. Wysocki
Hi Dave,
Brown-paper-bag pull request here. The snb rc6 fix from the last pull
broke forcewake BIOS dirt cleanup, which with fixed. But that fix broke
the spinlock init sequence, which results in an ugly BUG when spinlock
debugging is enabled :( So I get to throw another patch at cc: stable to
On Thu, Jul 25, 2013 at 9:32 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Thu, Jul 25, 2013 at 9:22 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Thu, Jul 25, 2013 at 09:12:41PM +0200, Sedat Dilek wrote:
New -3 dmesg.
That puts the ball back in the ddx's court. Next debugging
On Thu, 25 Jul 2013 22:05:51 +0200
Ingo Molnar mi...@kernel.org wrote:
* Jesse Barnes jbar...@virtuousgeek.org wrote:
Patch 2/2 has the description, but suffice it to say I'm
not really pleased with this, though it does solve a
problem we have. On some machines, we get MMIO space
On Thu, Jul 25, 2013 at 10:07:02PM +0200, Sedat Dilek wrote:
What means the bang line?
[54.564] (II) GLX: Initialized DRI2 GL provider for screen 0
[54.565] bang: 1159
[54.565]
Fatal server error:
[54.565] failed to create screen resources
That means between the kernel
On Thu, Jul 25, 2013 at 01:16:48PM -0700, Jesse Barnes wrote:
On Thu, 25 Jul 2013 22:05:51 +0200
Ingo Molnar mi...@kernel.org wrote:
Chris has some patches on top to add a new E820 type so
we can look up the region later, which removes some
redundant code in the i915 driver at least.
Generally I think checking our current sw state instead of reading hw
registers would be safer, e.g. in case we start to queue up more than
one pageflip. For async pageflips in benchmark mode flip as fast as
you can queue would be a sensible mode.
Ok, I've moved the tiling checks to the
This adds the necesary register defines for async page flipping
through the command ring, and then hooks those up for Ivybridge (gen7)
page flipping.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_display.c | 37
Just copies the IVB code
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
This is useful for drivers to find a resource inserted by, for example,
an early PCI quirk.
v2: We need to recurse through the resource tree as the named region we
are looking for may be a grandchild of the root node.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes
As we now hook into the early PCI quirk table to earmark the Intel
Graphics Stolen region (inserting it into the iomem_resource) to prevent
it conflicting with any later resource allocations, we can simply walk
the iomem_resource tree and find it for our use. Thereby removing all of
our own code
By giving the stolen a region a unique type and name, we then insert it
into the iomem_resource as a known resource. This clear identifies it to
the user when printing the e820 map (and later the iomem resources), and
exposes it to the driver for later use.
v2: Also need to add the string to a
Hmm, interesting licence block in i915_pciids.h - our claim to
grant licence but TG disclaims liability.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
On Thu, Jul 25, 2013 at 09:37:48AM -0700, Jesse Barnes wrote:
For use by userspace (at some point in the future) and other kernel code.
v2: move PCI IDs to uabi (Chris)
move PCI IDs to drm/ (Dave)
v3: fixup Quanta detection - needs to come first (Daniel)
One last comment!
+#define
Well, it's ok if the boot loader writes to this memory, the worst
that'll happen is you'll see garbage on the screen. If the boot loader
tries to do MMIO mapping on top it'll get into trouble... but why would
it do that?
Jesse
On Thu, 25 Jul 2013 15:42:25 -0700
H. Peter Anvin h...@zytor.com
On Thu, 25 Jul 2013 23:59:25 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
Hmm, interesting licence block in i915_pciids.h - our claim to
grant licence but TG disclaims liability.
Oops my manual search replace obviously failed. Will fix up.
--
Jesse Barnes, Intel Open Source
On Thu, Jul 25, 2013 at 11:52 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, Jul 25, 2013 at 10:07:02PM +0200, Sedat Dilek wrote:
What means the bang line?
[54.564] (II) GLX: Initialized DRI2 GL provider for screen 0
[54.565] bang: 1159
[54.565]
Fatal server error:
[
On Fri, Jul 26, 2013 at 01:21:07AM +0200, Sedat Dilek wrote:
On Thu, Jul 25, 2013 at 11:52 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Thu, Jul 25, 2013 at 10:07:02PM +0200, Sedat Dilek wrote:
What means the bang line?
[54.564] (II) GLX: Initialized DRI2 GL provider for
On Thu, Jul 25, 2013 at 3:42 PM, H. Peter Anvin h...@zytor.com wrote:
So the bootloader is just as likely to step on things... what happens when/if
it does?
This isn't a new problem. We've had this firmware tables don't show
all devices issue before.
The only odd thing about this one is how
To clarify: it'll either be marked reserved or not listed at all in e820, which
is why I did this early, before any other e820 stuff like the RAM buffer are
allocated, and before we could use the iomem resource (or maybe we could even
early per Linus? I'll check).
Jesse
--
Jesse Barnes,
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_dma.c between commit 14c5cec5d0cd (drm/i915:
initialize gt_lock early with other spin locks) from the drm-intel-fixes
tree and commit 907b28c56ea4 (drm/i915: Colocate all GT access routines
in the
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_pm.c between commit 14c5cec5d0cd (drm/i915:
initialize gt_lock early with other spin locks) from the drm-intel-fixes
tree and commit 907b28c56ea4 (drm/i915: Colocate all GT access routines
in the
Jan Niggemann writes:
Hi Daniel,
Am 25.07.2013 11:58, schrieb Daniel Vetter:
Can you pls try the below
patch (on top of Egbert's debug stuff)?
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 6caa748..2d4c884 100644
---
71 matches
Mail list logo
