Il 28/01/2011 23:13, Peter Clifton ha scritto:
> Without this, querying the backlight value returns half of the value it
> has been set to. Hilarity ensues, as my user-space likes to query first
> before incrementing / decrementing brightness, leading to brightness
> collapsing to near as I try to
On Tue, 1 Feb 2011 10:16:19 -0800, Ben Widawsky wrote:
> Added the minimal amount of code to enable the two ioctls used for
> creating and destroying contexts. Also added neccessary information in
> the structures to implement some basic operations the ioctls will have
> to perform.
Locking to b
On Tue, 1 Feb 2011 10:16:18 -0800
Ben Widawsky wrote:
> Adding parameters for userspace to query what features the
> driver/hardware supports. In the future context and ppgtt will always go
> together, but for now we will use hardware contexts without ppgtt since
> there are some issues with ppg
Added ringbuffer code to initiate context switch. The context switch can
fail since intel_ring_begin() can fail, and I am not sure how to handle
that yet. In most cases a context switch failure is pretty much fatal.
Modified the locking on deinit, which had a race (though results were
not fatal, j
Changed context_validation code to return a pointer to the context which
was validated. This saved us a context id lookup later when we want to
actually context switch. The downside is we can't differentiate a
lost context (buffer moved) from a never-existed context. This seems
okay to me for now.
Adds the support for actually doing something with buffer validation for
the context when submitted via execbuffer2. When a set of context flags
are submitted in the execbuffer call, the code is able to handle the
commands. It will also go through the existing buffers associated with
the context an
This change doesn't do anything except take parameters from clients
for context flag information, and pass it to a stubbed function to
validate the context flag information.
Included here are the updates to the necessary functions and structures
needed to handle contexts when execbuffer is called.
---
drivers/gpu/drm/i915/i915_dma.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b0acc0d..9d055ba 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -772,7 +772,7
---
drivers/gpu/drm/i915/i915_context.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_context.c
b/drivers/gpu/drm/i915/i915_context.c
index 4e19636..90b7bf3 100644
--- a/drivers/gpu/drm/i915/i915_context.c
+++ b/drivers/gpu/drm/i915/i915_
This does most of the work needed to create, destroy, and cleanup-after
contexts, but does not have the actual code to the do the context
switching, or buffer association. This includes context id/name
generation, context object allocation, calls hardware initialization
functions, ringbuffer API f
Added the minimal amount of code to enable the two ioctls used for
creating and destroying contexts. Also added neccessary information in
the structures to implement some basic operations the ioctls will have
to perform.
A small whitespace fixup in the Makefile also made it in here.
---
drivers/g
Adding parameters for userspace to query what features the
driver/hardware supports. In the future context and ppgtt will always go
together, but for now we will use hardware contexts without ppgtt since
there are some issues with ppgtt on the current generation.
---
drivers/gpu/drm/i915/i915_dma.
This patch adds the basic API for HW context manipulation. Right now
only a very basic unit test is passing. I was hoping to get some eyes on
this code while I look into porting some of mesa (and cleaning up my
libdrm patches).
I tried my best to split up the patches logically, but I'm afraid the
Thanks a lot Chris. Thanks for your valuable inputs.
Sudeep
Chris Wilson wrote:
On Tue, 01 Feb 2011 15:45:34 +0530, sudeep wrote:
Hi All,
I am a starter in Linux graphics. Our development board is
*MATXM*-*CORE*-*411*-*B* from Emerson. It has
Intel i5 core and QM57 chip set. We have a a
On Mon, 31 Jan 2011 15:00:23 +0800, "Lan, Hai" wrote:
> Add test case for dumping display into, test all mode(including clone/twin
> mode) and support to test forced mode in testdisplay
> usage: ./testdisplay [-hiaf:]
> -i dump info
> -a test all modes
> -f MHz>,
On Tue, 01 Feb 2011 15:45:34 +0530, sudeep wrote:
> Hi All,
>
> I am a starter in Linux graphics. Our development board is
> *MATXM*-*CORE*-*411*-*B* from Emerson. It has
> Intel i5 core and QM57 chip set. We have a a requirement to use the
> hardware acceleration for various graphics
> operati
Hi All,
I am a starter in Linux graphics. Our development board is
*MATXM*-*CORE*-*411*-*B* from Emerson. It has
Intel i5 core and QM57 chip set. We have a a requirement to use the
hardware acceleration for various graphics
operations such as blit, blend etc.
1)Does the Linux graphics driver f
Hi Dave, a fairly busy week or two of bouncing .38 regression fixes off
testers. A great big thanks to the QA at Suse who have been very
responsive and helped a great deal with these patches.
In the wings, as always, we have more patches under test, mainly focusing
on stability fixes for SNB and
18 matches
Mail list logo
