On Sun, Mar 18, 2012 at 01:39:40PM -0700, Ben Widawsky wrote:
> The patches have changed quite a bit since the RFC, and therefore I
> didn't feel comfortable trying to do v2 information. I didn't feel
> comfortable taking the few r-bs that I had from the RFC except for the
> one patch that I applie
> Please, can anyone tell me if there is a list for user questions about
> VAAPI? I have several questions...
The list for VAAPI is li...@lists.freedesktop.org
As for brightness property, the driver doesn't support it.
Thanks
Haihao
>
> Greets,
> Kiste
>
>
>
> Am 09.03.2012 08:04, schrieb
Hi Dave,
QA beat on the -next tree in my absence and filed 3 new issue. Afaict
they're all new sightings of old issues (hooray for improved test-suites)
safe for a very funky sporadic failure on ilk - investigation is still
going on this one.
Otherwise the missed irq on snb poped up again, but Be
In some off chance the HW context code and new error check fixes things
magically..
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_display.c |6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
Use the context interfaces to create the power context. Assuming we
have a default context, there should be no need to switch to
the render context anymore as the default context should already serve
this purpose.
As a double cautionary measure we check the CCID to make sure everything
looks kosh
Ironlake RC6 needs to allocate a power context object which the hardware
can automatically switch to. Since the new context code nicely handles
contexts, create some interfaces so we can hook up the existing code to
the new code.
The right way to do this is to move a bunch of code out of
intel_dis
From: Ben Widawsky
Parameters tell user space if contexts are available.
Signed-off-by: Ben Widawsky
Reviewed-by: Eugeni Dodonov
Reviewed-by: Eric Anholt
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
include/drm/i915_drm.h |1 +
2 files changed, 4 insertions(+)
diff --git a/d
Use the rsvd1 field in execbuf2 to specify the context ID associated
with the workload. This will allow the driver to do the proper context
switch when/if needed.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |6 ++
include/drm/i915_drm.h
Add the interfaces to allow user space to create and destroy contexts.
Contexts are destroyed automatically if the file descriptor for the dri
device is closed.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_dma.c |2 +
drivers/gpu/drm/i915/i915_drv.h |4 ++
dr
paranoia
For context support the HW expects the default context to always be
available as there is no way to shut off HW contexts once turned on
(afaics). This is problematic when unloading the driver as we have no
way to prevent the GPU from expecting the BO to still be present once
unloaded.
Th
To keep things as sane as possible, switch to the default context before
idling. This should help free context objects, as well as put things in
a more well defined state before suspending.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c |6 ++
1 file changed, 6 insertion
With the code to do HW context switches in place have the driver load the
default context for the render ring when the driver loads.
The default context will be an ever present context that is available to
switch to at any time for the given ring.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm
From http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol1_Part3.pdf
[DevSNB] If Flush TLB invalidation Mode is enabled it’s the driver’s
responsibility to invalidate the TLBs at least once after the previous
context switch after any GTT mappings changed (including new GTT
entries). This ca
This has showed up in several other patches. It's required for the next
context workaround.
I tested this one on its own and saw no differences in basic tests
(performance or otherwise).
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel
The workaround itself applies to gen7 only (according to the docs) and
as Eric Anholt points out shouldn't be required since we don't use HW
scheduling features, and therefore arbitration. Though since it is a
small, and simple addition, and we don't really understand the issue,
just do it.
Signed
Recommended by Daniel Vetter. The original code used DRM_DEBUG_DRIVER.
With this we track context creation, destruction, and switching.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_context.c |7 +++-
drivers/gpu/drm/i915/i915_trace.h | 59
Implement the context switch code as well as the interfaces to do the
context switch. This patch also doesn't match 1:1 with the RFC patches.
The main difference is that from Daniel's responses the last context
object is now stored instead of the last context. This aids in allows us
to free the con
Handy mostly for assertions.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h |5 +
drivers/gpu/drm/i915/i915_gem.c |1 +
drivers/gpu/drm/i915/i915_gem_context.c |3 +++
3 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
This commit doesn't really match up 1:1 with any of the RFC patches. The
primary difference in the equivalent logic though is the new use of a reference
counter for the context life cycle. This allows us to free the context backing
object, and context kernel memory separately.
For example if a con
Very basic code for context setup/destruction in the driver.
There are 4 entry points into the contexts, load, unload, open, close.
The names are self-explanatory except that load can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these even
From: Ben Widawsky
The GPUs can have different default context layouts, and the sizes could
vary based on platform or BIOS. In order to back the context object with
a properly sized BO, we must read this register in order to find out a
sufficient size.
Thankfully (sarcarm!), the register moves a
The patches have changed quite a bit since the RFC, and therefore I
didn't feel comfortable trying to do v2 information. I didn't feel
comfortable taking the few r-bs that I had from the RFC except for the
one patch that I applied wholesale.
Summary:
- Completely redid the patch splitting.
The n
On Sun, Mar 18, 2012 at 2:09 PM, Daniel Vetter wrote:
> On Fri, Mar 16, 2012 at 12:43:21PM -0400, Sean Paul wrote:
>> I have experienced a number of NULL pointer dereferences on
>> suspend/resume where ring->private is NULL. These come from failed
>> initialization of the ring buffer. Sincce this
At Sat, 17 Mar 2012 12:01:17 -0700,
Keith Packard wrote:
>
> <#part sign=pgpmime>
> On Sat, 17 Mar 2012 08:59:56 +0100, Takashi Iwai wrote:
>
> > Well, the LVDS reg data isn't in lvds_dvo_timing but in lvds_fp_timing,
> > thus you need to look at a different entry in anyway.
>
> Right, a parall
At Sun, 18 Mar 2012 19:01:21 +0100,
Andreas Heider wrote:
>
> Am 18.03.2012 um 18:50 schrieb Daniel Vetter:
> > On Fri, Mar 16, 2012 at 09:29:24PM +0100, Takashi Iwai wrote:
> >> At Fri, 16 Mar 2012 15:55:52 -0400,
> >> Adam Jackson wrote:
> >>>
> >>> On 3/15/12 10:42 AM, Takashi Iwai wrote:
> >>
At Sun, 18 Mar 2012 18:50:31 +0100,
Daniel Vetter wrote:
>
> On Fri, Mar 16, 2012 at 09:29:24PM +0100, Takashi Iwai wrote:
> > At Fri, 16 Mar 2012 15:55:52 -0400,
> > Adam Jackson wrote:
> > >
> > > On 3/15/12 10:42 AM, Takashi Iwai wrote:
> > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_di
On Fri, Mar 16, 2012 at 12:43:21PM -0400, Sean Paul wrote:
> I have experienced a number of NULL pointer dereferences on
> suspend/resume where ring->private is NULL. These come from failed
> initialization of the ring buffer. Sincce this doesn't seem to be easily
> recoverable, this patch adds a B
Am 18.03.2012 um 18:50 schrieb Daniel Vetter:
> On Fri, Mar 16, 2012 at 09:29:24PM +0100, Takashi Iwai wrote:
>> At Fri, 16 Mar 2012 15:55:52 -0400,
>> Adam Jackson wrote:
>>>
>>> On 3/15/12 10:42 AM, Takashi Iwai wrote:
>>>
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/g
On Fri, Mar 16, 2012 at 12:43:22PM -0400, Sean Paul wrote:
> I have seen a number of "blt ring initialization failed" messages
> where the ctl or start registers are not the correct value. Upon further
> inspection, if the code just waited a little bit, it would read the
> correct value. Adding the
On Fri, Mar 16, 2012 at 09:29:24PM +0100, Takashi Iwai wrote:
> At Fri, 16 Mar 2012 15:55:52 -0400,
> Adam Jackson wrote:
> >
> > On 3/15/12 10:42 AM, Takashi Iwai wrote:
> >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index f851db7.
On Wed, Mar 14, 2012 at 11:22:11AM -0400, Adam Jackson wrote:
> Some newer BIOSes are shipping with all MTRRs already populated. These
> BIOSes are all on machines with sufficiently new CPUs that the
> referenced errata doesn't apply anyway, so just don't try to claim the
> MTRR.
>
> Signed-off-b
31 matches
Mail list logo
