I've had a working kernel.org account for a couple months now, and have
been pushing code to both there and fdo for the last release. I'll
continue to push to both, but I'll be sending pull requests from
kernel.org from now on.
git:/git.kernel.org/pub/scm/linux/kernel/git/keithp/linux
N
Here are the rest of the 3.3 pending changes.
This has a bunch of small bug fixes and overlay plane support for i915.
The following changes since commit 7a7e8734ac3235efafd34819b27fbdf5417e6d60:
Merge branch 'drm-radeon-testing' of ../drm-radeon-next into drm-core-next
(2012-01-03 09:45:12 +
On Wed, 4 Jan 2012 19:40:45 +0100, Daniel Vetter
wrote:
> Two things seem to do the trick on my ivb machine here:
> - prevent the gt from powering down while waiting for seqno
> notification interrupts by grabbing the force_wake in get_irq (and
> dropping it in put_irq again).
> - ordering
On Wed, 4 Jan 2012 19:12:57 +0100, Daniel Vetter wrote:
> The "Correct?" was just to check my understanding of your concern, I still
> think its invalid. You've cut away the second part of my mail where I
> explain why and I don't see you responding to that here. Also
> micro-optimizing the gpu r
On 01/04/2012 11:23 AM, je...@vige.it wrote:
> Are the graphic drivers for gma 4500m included in the intel-gfx release?
> If no there is a future develop for it?
Yes, that's been supported for ages, and the drivers should already ship
with basically any Linux distribution. You shouldn't have to d
On Wed, 04 Jan 2012 14:48:37 -0800
Eric Anholt wrote:
> On Wed, 4 Jan 2012 08:52:34 -0800, Jesse Barnes
> wrote:
> > On Tue, 3 Jan 2012 19:10:00 -0800
> > Eric Anholt wrote:
> >
> > > ---
> > >
> > > This syncs the code up to the kernel as of the gen7 SOL changes. It
> > > would be nice if
---
intel/intel_decode.c | 62 ++-
intel/tests/gen7-3d.batch-ref.txt | 388 +
2 files changed, 241 insertions(+), 209 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 49242dc..d9001d4 100644
--- a/intel/intel_decod
Since CC_STATE_POINTERS for gen6 and 7 are quite different but use the
same opcode, move gen6 out to a helper function too, so we can use a
helper function for gen7.
---
intel/intel_decode.c | 80
intel/tests/gen7-3d.batch-ref.txt | 30 ++--
---
intel/intel_decode.c | 44 ++
intel/tests/gen7-3d.batch-ref.txt | 112 ++--
2 files changed, 100 insertions(+), 56 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index e1243ee..7b4ed42 100644
--- a/intel/intel_
This puts the error message in a consistent location relative to the
packet, and while I'm here I made the error message a bit more
informative.
Now, most static length packets need to just declare their length in
the table and not worry.
---
intel/intel_decode.c | 55 +++--
The overflow checks were all thoroughly untested, and a bunch of the
ones I'm deleting were pretty broken. Now, in the case of overflow,
you just decode data of 0xd0d0d0d0, and instr_out prints the warning
message instead. Note that this still has the same issue of being
under-tested, but at leas
It's a lot nicer than using IS_WHATEVER(devid) all over the place, and
we have this in our other projects too.
---
intel/intel_decode.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 97820b3..35
---
intel/intel_decode.c |3 ++-
intel/tests/gen7-3d.batch-ref.txt |1 -
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 3548f57..864d802 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -2744,7 +2
While I'm touching every line of the table, sort it by opcode.
---
intel/intel_decode.c | 156 +++--
1 files changed, 73 insertions(+), 83 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 1f01b11..1519f6a 100644
--- a/intel/i
I want to add packets, without contributing to the switch statement of
doom.
---
intel/intel_decode.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 864d802..1f01b11 100644
--- a/intel/intel_decode.c
+++ b/intel/int
Similar to BR00, count was always 1 and was always an index, not a count.
---
intel/intel_decode.c | 26 ++
1 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 5a4246d..0c3ec3c 100644
--- a/intel/intel_decode.
The count (actually index) was always 0, because BR00 is dword 0.
---
intel/intel_decode.c | 23 +++
1 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index be49b84..5a4246d 100644
--- a/intel/intel_decode.c
+++ b/int
---
intel/Makefile.am |1 +
intel/tests/gen7-2d-copy.batch | Bin 0 -> 56 bytes
intel/tests/gen7-2d-copy.batch-ref.txt | 14 ++
intel/tests/gen7-2d-copy.batch.sh |1 +
4 files changed, 16 insertions(+), 0 deletions(-)
create mode 100644 int
We still deref the context at the start of every call, but that will
change next.
---
intel/intel_decode.c | 70 +++--
1 files changed, 44 insertions(+), 26 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 6345e87..be49b84 1
This is the start of plumbing the context through the decode
callchain instead of the current 4 arguments.
---
intel/intel_decode.c | 69 +++--
intel/tests/gen7-3d.batch-ref.txt | 18 +-
2 files changed, 52 insertions(+), 35 deletions(-)
di
Nothing was consuming it. If something wants this in the future,
would be done using the decode context anyway.
---
intel/intel_decode.c | 74 -
1 files changed, 24 insertions(+), 50 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_de
There was a logical split in this series at patch 8-9, but I figured I
should share the final result as well since people are probably
wondering why I care, and I'm hoping to land this all for the next
libdrm release (which we need to do for the updated header, which we
need for mesa).
___
On Wed, 4 Jan 2012 08:52:34 -0800, Jesse Barnes
wrote:
> On Tue, 3 Jan 2012 19:10:00 -0800
> Eric Anholt wrote:
>
> > ---
> >
> > This syncs the code up to the kernel as of the gen7 SOL changes. It
> > would be nice if doing this was just a straight copy of the kernel
> > code -- there are t
On Wed, Jan 04, 2012 at 02:04:33PM -0800, Ben Widawsky wrote:
> This is needed to run the simulator.
>
> Cc: Jesse Barnes
> Signed-off-by: Ben Widawsky
I'll refrain from asking how you got here ...
Acked-by: Daniel Vetter
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
This is needed to run the simulator.
Cc: Jesse Barnes
Signed-off-by: Ben Widawsky
---
drivers/char/agp/intel-agp.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index b427711..f853514 100644
--- a/drivers/cha
Are the graphic drivers for gma 4500m included in the intel-gfx release?
If no there is a future develop for it?
--
Luca Stancapiano
javaee consultant
skype: flashboss62
mobile: +393381584484
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
h
Two things seem to do the trick on my ivb machine here:
- prevent the gt from powering down while waiting for seqno
notification interrupts by grabbing the force_wake in get_irq (and
dropping it in put_irq again).
- ordering writes from the ring's CS by reading a CS register, ACTHD
seems to w
On Wed, Jan 4, 2012 at 14:52, Daniel Vetter wrote:
> Two things seem to do the trick on my ivb machine here:
> - prevent the gt from powering down while waiting for seqno
> notification interrupts by grabbing the force_wake in get_irq (and
> dropping it in put_irq again).
> - ordering writes fr
On Wed, Jan 04, 2012 at 09:54:08AM -0800, Keith Packard wrote:
> On Wed, 4 Jan 2012 18:11:18 +0100, Daniel Vetter
> wrote:
>
> > Ah, I think I see you're concern: Between the time we reset the gpu
> > and the time we fix up the forcewake state somebody might sneak in and
> > see an inconstency b
On Wed, 4 Jan 2012 18:11:18 +0100, Daniel Vetter wrote:
> Ah, I think I see you're concern: Between the time we reset the gpu
> and the time we fix up the forcewake state somebody might sneak in and
> see an inconstency between our tracking and the actual hw state, hence
> reading garbage. Correc
On Thu, 15 Dec 2011 23:04:21 +0100
Johannes Bauer wrote:
> Am 13.12.2011 22:46, schrieb Jesse Barnes:
> > On Tue, 13 Dec 2011 22:30:42 +0100
> > Johannes Bauer wrote:
> >>> then echo that value into the max freq file, e.g.:
> >>>
> >>> $ echo 400 > /sys/kernel/debug/dri/0/i915_max_freq
> >>
> >>
On Wed, Jan 04, 2012 at 09:05:51AM -0800, Keith Packard wrote:
> On Wed, 4 Jan 2012 18:02:21 +0100, Daniel Vetter wrote:
>
> > So I really don't like the busy-looping, especially now that
> > semaphores are enabled by default for ivb.
>
> Alternatives are welcome; we have no other known fix for
On Wed, 4 Jan 2012 13:00:40 +
"Sun, Yi" wrote:
> > -Original Message-
> > From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
> > Sent: Wednesday, January 04, 2012 6:53 AM
> > To: Sun, Yi
> > Cc: intel-gfx@lists.freedesktop.org; Yang, Guang A
> > Subject: Re: [Intel-gfx] The latest s
On Wed, Jan 4, 2012 at 00:33, Keith Packard wrote:
> On Tue, 3 Jan 2012 22:49:52 +0100, Daniel Vetter
> wrote:
>
>> Nope, current hangcheck blows up, and we have an i-g-t testcase for it
>> (which the commit msg clearly states). There are also numerous bug
>> reports where a dying gpu results in
On Wed, 4 Jan 2012 18:02:21 +0100, Daniel Vetter wrote:
> So I really don't like the busy-looping, especially now that
> semaphores are enabled by default for ivb.
Alternatives are welcome; we have no other known fix for missing
sequence writes.
--
keith.pack...@intel.com
pgpHcsh2BtIKu.pgp
D
On Tue, Jan 03, 2012 at 03:38:25PM -0800, Keith Packard wrote:
> On Wed, 4 Jan 2012 00:04:18 +0100, Daniel Vetter wrote:
>
> > I kinda prefer Chris' approach of sticking with irqs, but backing it up
> > with a timer in the msec range. Can't find that patch though atm (iirc
> > it's in bugzilla so
Two things seem to do the trick on my ivb machine here:
- prevent the gt from powering down while waiting for seqno
notification interrupts by grabbing the force_wake in get_irq (and
dropping it in put_irq again).
- ordering writes from the ring's CS by reading a CS register, ACTHD
seems to w
Keith, see below in case you want to update the changelogs.
Jesse
On Wed, 4 Jan 2012 13:36:01 +
"Sun, Yi" wrote:
> Now, 3 bugs are fixed by the patches:
>
> [patch 1/2] drm/i915: don't disable a PCH DPLL that's in use
> and
> [patch 2/2] drm/i915: only set the intel_crtc DPMS mode to on
On Tue, 3 Jan 2012 19:10:00 -0800
Eric Anholt wrote:
> ---
>
> This syncs the code up to the kernel as of the gen7 SOL changes. It
> would be nice if doing this was just a straight copy of the kernel
> code -- there are two diffs left out. One is this hunk:
>
> -#ifdef __KERNEL__
> -/* For u
Now, 3 bugs are fixed by the patches:
[patch 1/2] drm/i915: don't disable a PCH DPLL that's in use
and
[patch 2/2] drm/i915: only set the intel_crtc DPMS mode to on if the mode set
succeeded
http://lists.freedesktop.org/archives/intel-gfx/2011-November/013424.html
http://lists.freedesktop.
> -Original Message-
> From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
> Sent: Wednesday, January 04, 2012 6:53 AM
> To: Sun, Yi
> Cc: intel-gfx@lists.freedesktop.org; Yang, Guang A
> Subject: Re: [Intel-gfx] The latest status of intel graphics on kernel 3.2
>
> On Sat, 31 Dec 2011 08
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, January 04, 2012 5:47 AM
> To: zhigang.g...@linux.intel.com
> Cc: intel-gfx@lists.freedesktop.org; zhigang.g...@gmail.com;
> zhigang.g...@linux.intel.com
> Subject: Re: [PATCH 0/1] uxa/glamor: Rou
On Tue, Jan 03, 2012 at 07:10:00PM -0800, Eric Anholt wrote:
> ---
>
> This syncs the code up to the kernel as of the gen7 SOL changes. It
> would be nice if doing this was just a straight copy of the kernel
> code -- there are two diffs left out. One is this hunk:
>
> -#ifdef __KERNEL__
> -/*
On Tue, Jan 03, 2012 at 06:29:35PM -0800, Eric Anholt wrote:
> On Wed, 4 Jan 2012 00:24:28 +0100, Daniel Vetter wrote:
> > On Tue, Jan 03, 2012 at 03:05:26PM -0800, Eric Anholt wrote:
> > > The .batch was generated using the dump-a-batch branch of
> > >
> > > git://people.freedesktop.org/~anholt/
On Tue, 03 Jan 2012 19:40:36 -0800, Ben Widawsky wrote:
> On 12/29/2011 05:52 PM, Eric Anholt wrote:
> > These registers are automatically incremented by the hardware during
> > transform feedback to track where the next streamed vertex output
> > should go. Unlike the previous generation, which
45 matches
Mail list logo
