On Thu, 08 May 2014, Ben Widawsky wrote:
> On Wed, May 07, 2014 at 09:42:57AM +0200, Daniel Vetter wrote:
>> Aside: Please add the regression tags when handling bugs, I need those for
>> tracking and stats.
>> -Daniel
>>
>
> I don't know what a regression tag is.
"[regression]" at the front of t
On Wed, May 07, 2014 at 10:44:23PM -0700, Jamey Sharp wrote:
> On Wed, May 07, 2014 at 04:55:18PM +0100, Chris Wilson wrote:
> > On Mon, May 05, 2014 at 11:05:07PM -0700, Jamey Sharp wrote:
> > > UXA was reporting page-flip completion as soon as the flip was scheduled
> > > with the kernel, instead
On Wed, May 07, 2014 at 04:55:18PM +0100, Chris Wilson wrote:
> On Mon, May 05, 2014 at 11:05:07PM -0700, Jamey Sharp wrote:
> > UXA was reporting page-flip completion as soon as the flip was scheduled
> > with the kernel, instead of waiting for the kernel to indicate that the
> > flip had actually
Daniel requested in the bug that I use a 3GB fallback size. Since this
is not in the spec as a valid size, I decided against it. We could
potentially add a patch to bump it to 3GB on top of this one.
This probably should be CC: stable - but I'll let the powers that be
decide that one.
Regression
On Wed, May 07, 2014 at 09:42:57AM +0200, Daniel Vetter wrote:
> On Tue, May 06, 2014 at 09:58:59PM -0700, Ben Widawsky wrote:
> > From: Ben Widawsky
> >
> > Daniel requested in the bug that I use a 3GB fallback size. Since this
> > is not in the spec as a valid size, I decided against it. We cou
On Mon, May 05, 2014 at 09:07:32AM +0100, Chris Wilson wrote:
> A few improvements to the fallback method for waiting upon ring space:
>
> 1. Fix the start/end wait tracepoints to always be paired.
> 2. Increase responsiveness of checking
> 3. Mark the process as waiting upon io
> 4. Check for sig
On Mon, May 05, 2014 at 01:07:33AM -0700, Chris Wilson wrote:
> During the review of
>
> commit 1f70999f9052f5a1b0ce1a55aff3808f2ec9fe42
> Author: Chris Wilson
> Date: Mon Jan 27 22:43:07 2014 +
>
> drm/i915: Prevent recursion by retiring requests when the ring is full
>
> Ville raise
On Wednesday, May 07, 2014 02:49:31 PM Ville Syrjälä wrote:
> I quickly cobbled together a hsw version of this and gave it a whirl on
> one machine. Seems to work just fine here, and no lockups when switching
> between hw and sw binding tables. Did you get the lockups on hsw even
> with rendercopy?
On Mon, May 05, 2014 at 01:07:32AM -0700, Chris Wilson wrote:
> A few improvements to the fallback method for waiting upon ring space:
>
> 1. Fix the start/end wait tracepoints to always be paired.
> 2. Increase responsiveness of checking
> 3. Mark the process as waiting upon io
> 4. Check for sig
"Gupta, Sourab" writes:
> On Tue, 2014-05-06 at 17:56 +, Eric Anholt wrote:
>> sourab.gu...@intel.com writes:
>>
>> > From: Sourab Gupta
>> >
>> > This patch is in continuation of and is dependent on earlier patch
>> > series to 'reduce the time for which device mutex is kept locked'.
>> >
With the ring mask we now have an easy way to know the number of rings
in the system, and therefore can accurately predict the number of dwords
to emit for semaphore signalling. This was not possible (easily)
previously.
There should be no functional impact, simply fewer instructions emitted.
Whi
On Wed, May 07, 2014 at 05:55:00PM +0100, Chris Wilson wrote:
> On Wed, May 07, 2014 at 09:00:16AM -0700, Ben Widawsky wrote:
> > On Wed, May 07, 2014 at 04:53:08PM +0100, Chris Wilson wrote:
> > > On Wed, May 07, 2014 at 08:45:38AM -0700, Ben Widawsky wrote:
> > > > Hmm. I really don't see what's
This appears to not actually be needed on the current code. Just putting
it on the ML so we can point bug reports at it later.
As pointed out by Ville, the current code is "broken" since we do
FORCE_RESTORE, and RESTORE_INHIBIT on the same dword. Anecdotally, this
seems fine.
Signed-off-by: Ben W
Gen8 has already had some differentiation with how it handles rings.
Semaphores bring yet more differences, and now is as good a time as any
to do the split.
Also, since gen8 doesn't actually use semaphores up until this point,
put the proper "NULL" values in for the mbox info.
v2: v1 had a stale
Simple debugfs file to display the current state of semaphores. This is
useful if you want to see the state without hanging the GPU.
NOTE: This patch is optional to the series.
NOTE2: Like the GPU error state collection, the reads are currently
incoherent.
Signed-off-by: Ben Widawsky
---
drive
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gpu_error.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 2d81985..a7eaab2 100644
--- a/drivers/gpu
As Ville points out, it's possible/probable we don't actually need this.
Potentially, this validates the letter of the spec, and not the spirit.
Ville:
> I discussed this on irc w/ Ben, and I was suggesting we don't need to
> poll. Polling apparently can be used as a workaround for certain
> hardw
The series is mostly done, but it needs a few last tweaks to make it acceptable
for merge.
Chris noticed that the series doesn't properly work with the new VCS2 code that
Daniel merged a couple of weeks ago. I too noticed this, but was remaining
silent in the hopes that we could actually try to ma
Semaphore waits use a new instruction, MI_SEMAPHORE_WAIT. The seqno to
wait on is all well defined by the table in the previous patch. There is
nothing else different from previous GEN's semaphore synchronization
code.
v2: Update macros to not require the other ring's ring->id (Chris)
Signed-off-
Semaphore signalling works similarly to previous GENs with the exception
that the per ring mailboxes no longer exist. Instead you must define
your own space, somewhere in the GTT.
The comments in the code define the layout I've opted for, which should
be fairly future proof. Ie. I tried to define
From: Ben Widawsky
This is needed to implement ipehr_is_semaphore_wait
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_irq.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2d76183
Since the semaphore information is in an object, just dump it, and let
the user parse it later.
NOTE: The page being used for the semaphores are incoherent with the
CPU. No matter what I do, I cannot figure out a way to read anything but
0s. Note that the semaphore waits are indeed working.
v2: D
On Wed, 2014-05-07 at 19:57 +0300, Imre Deak wrote:
> Currently user space can access GEM buffers mapped to GTT through
> existing mappings concurrently while the platform specific suspend
> handlers are running. Since these handlers may change the HW state in a
> way that would break such accesses
On Wed, May 07, 2014 at 09:59:14AM -0700, Ben Widawsky wrote:
> On Wed, Apr 30, 2014 at 02:21:15PM +0300, Ville Syrjälä wrote:
> > On Tue, Apr 29, 2014 at 02:52:35PM -0700, Ben Widawsky wrote:
> > > From: Ben Widawsky
> > >
> > > This is needed to implement ipehr_is_semaphore_wait
> > >
> > > Si
On Wed, Apr 30, 2014 at 02:21:15PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 29, 2014 at 02:52:35PM -0700, Ben Widawsky wrote:
> > From: Ben Widawsky
> >
> > This is needed to implement ipehr_is_semaphore_wait
> >
> > Signed-off-by: Ben Widawsky
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 11
Currently user space can access GEM buffers mapped to GTT through
existing mappings concurrently while the platform specific suspend
handlers are running. Since these handlers may change the HW state in a
way that would break such accesses, remove the mappings before calling
the handlers. Spotted b
On Wed, May 07, 2014 at 09:00:16AM -0700, Ben Widawsky wrote:
> On Wed, May 07, 2014 at 04:53:08PM +0100, Chris Wilson wrote:
> > On Wed, May 07, 2014 at 08:45:38AM -0700, Ben Widawsky wrote:
> > > Hmm. I really don't see what's actually upsetting. Can you be a bit more
> > > explicit about what's
Could someone help to review this patch please? It provides a nice
improvement to the command parser's performance, so I'd like to get
this one in.
Thanks,
Brad
On Mon, Apr 28, 2014 at 08:22:08AM -0700, Volkin, Bradley D wrote:
> From: Brad Volkin
>
> For clients that submit large batch buffers
On Wed, May 07, 2014 at 04:53:08PM +0100, Chris Wilson wrote:
> On Wed, May 07, 2014 at 08:45:38AM -0700, Ben Widawsky wrote:
> > On Wed, May 07, 2014 at 08:02:38AM +0100, Chris Wilson wrote:
> > > On Tue, May 06, 2014 at 10:21:31PM -0700, Ben Widawsky wrote:
> > > > The DRM node allocation code wa
On Wed, May 07, 2014 at 08:54:56AM -0700, Ben Widawsky wrote:
> On Wed, May 07, 2014 at 09:55:49AM +0200, Daniel Vetter wrote:
> > On Tue, May 06, 2014 at 10:21:35PM -0700, Ben Widawsky wrote:
> > > This will be useful for some upcoming patches which do more platform
> > > specific work. Having it
On Mon, May 05, 2014 at 11:05:07PM -0700, Jamey Sharp wrote:
> UXA was reporting page-flip completion as soon as the flip was scheduled
> with the kernel, instead of waiting for the kernel to indicate that the
> flip had actually completed.
>
> Moving the DRI2SwapComplete call to the right place f
On Wed, May 07, 2014 at 09:55:49AM +0200, Daniel Vetter wrote:
> On Tue, May 06, 2014 at 10:21:35PM -0700, Ben Widawsky wrote:
> > This will be useful for some upcoming patches which do more platform
> > specific work. Having it in one central place just makes things a bit
> > cleaner and easier.
>
On Wed, May 07, 2014 at 08:45:38AM -0700, Ben Widawsky wrote:
> On Wed, May 07, 2014 at 08:02:38AM +0100, Chris Wilson wrote:
> > On Tue, May 06, 2014 at 10:21:31PM -0700, Ben Widawsky wrote:
> > > The DRM node allocation code was already a bit of an ugly bit of code
> > > within a complex function
On Wed, May 07, 2014 at 08:02:38AM +0100, Chris Wilson wrote:
> On Tue, May 06, 2014 at 10:21:31PM -0700, Ben Widawsky wrote:
> > The DRM node allocation code was already a bit of an ugly bit of code
> > within a complex function. Removing it serves the purpose of cleaning
> > the function up. More
UXA was reporting page-flip completion as soon as the flip was scheduled
with the kernel, instead of waiting for the kernel to indicate that the
flip had actually completed.
Moving the DRI2SwapComplete call to the right place fixes all of our
Piglit tests for OML_sync_control when run on xf86-vide
On Wed, May 07, 2014 at 09:49:57AM +0200, Daniel Vetter wrote:
> On Tue, May 06, 2014 at 10:21:33PM -0700, Ben Widawsky wrote:
> > AFAICT, it's impossible to actually infinitely retry the allocation in
> > our current code. However, a small oversight on my part, slight bug, or
> > future bug, could
On Mon, May 05, 2014 at 06:17:39PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> On CHV, All the freq request should be even. So, we need to make sure we
> request the opcode accordingly.
>
> Signed-off-by: Deepak S
> Reviewed-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_d
Hello all,
As per previous discussions, I am sending the drm-color-manager design
for review, as inline text. Please have a look and let me know your
feedback.
(I tried hard to align the inline text diagram in mail, hope you can see
the proper picture too)
=
DRM Color Manag
On Wed, May 07, 2014 at 04:55:28PM +0300, Mika Kuoppala wrote:
> We need to add one drm_open_any() before getting the object counts
> as first call to drm_open_any() allocates file descriptors for
> exit handlers and thus is not symmetrical
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?i
On Mon, May 05, 2014 at 06:17:31PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> In BDW, Apart from unmasking up/down threshold interrupts. we need
> to umask bit 32 of PM_INTRMASK to route interrupts to target via Display
> Interface.
>
> v2: Add (1<<31) mask (Ville)
>
> Signed-o
On Mon, May 05, 2014 at 06:17:30PM +0530, deepa...@linux.intel.com wrote:
> From: Ben Widawsky
>
> Almost all of it is reusable from the existing code. The primary
> difference is we need to do even less in the interrupt handler, since
> interrupts are not shared in the same way.
>
> The patch i
We need to add one drm_open_any() before getting the object counts
as first call to drm_open_any() allocates file descriptors for
exit handlers and thus is not symmetrical
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77867
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77875
Sign
On Fri, 2014-04-25 at 10:45 +0200, Daniel Vetter wrote:
> Ok, review assignements. Please complain if you don't have the
> bandwidth so that I can find someone else.
>
> On Thu, Apr 24, 2014 at 11:54 PM, Daniel Vetter
> wrote:
> >
> > Daniel Vetter (66):
> > drm/i915: Make encoder->mode_set ca
On Wed, May 07, 2014 at 02:49:31PM +0300, Ville Syrjälä wrote:
> I quickly cobbled together a hsw version of this and gave it a whirl on
> one machine. Seems to work just fine here, and no lockups when switching
> between hw and sw binding tables. Did you get the lockups on hsw even
> with renderco
I quickly cobbled together a hsw version of this and gave it a whirl on
one machine. Seems to work just fine here, and no lockups when switching
between hw and sw binding tables. Did you get the lockups on hsw even
with rendercopy?
Here's my hsw version:
>From 17eeb8021815e2c18d6ba9b2185a37904296
On Wed, May 7, 2014 at 9:39 AM, Daniel Vetter wrote:
>> Yes no real backing storage is needed, but still the object should be
>> allowed to get mapped into the GGTT, using the scratch page (already
>> zeroed out).
>>
>> Is there a patch for a new drm/i915 ioctl similar to fallocate, which
>> could
On 05/02/2014 06:15 PM, Ben Widawsky wrote:
On Fri, May 02, 2014 at 11:27:45AM +0100, Tvrtko Ursulin wrote:
Some people expressed interest in tiling so I thought to preserve it in the
API.
Kernel even allows it, and it is just because Chris found bspec references
saying it will break badly on
On Tue, 2014-05-06 at 17:56 +, Eric Anholt wrote:
> sourab.gu...@intel.com writes:
>
> > From: Sourab Gupta
> >
> > This patch is in continuation of and is dependent on earlier patch
> > series to 'reduce the time for which device mutex is kept locked'.
> > (http://lists.freedesktop.org/archi
On Tue, 2014-05-06 at 13:12 +, Chris Wilson wrote:
> On Tue, May 06, 2014 at 12:59:37PM +, Gupta, Sourab wrote:
> > On Tue, 2014-05-06 at 11:34 +, Chris Wilson wrote:
> > > On Tue, May 06, 2014 at 04:40:58PM +0530, sourab.gu...@intel.com wrote:
> > > > From: Sourab Gupta
> > > >
> > >
On Tue, May 06, 2014 at 10:21:38PM -0700, Ben Widawsky wrote:
> This patch finishes off actually separating the aliasing and global
> finds. Prior to this, all global binds would be aliased. Now if aliasing
> binds are required, they must be explicitly asked for. So far, we have
> no users of this
On Tue, May 06, 2014 at 10:21:36PM -0700, Ben Widawsky wrote:
> There is a good debate to be had about how best to fit the aliasing
> PPGTT into the code. However, as it stands right now, getting aliasing
> PPGTT bindings is a hack, and done through implicit arguments. To make
> this absolutely cle
On Tue, May 06, 2014 at 10:21:35PM -0700, Ben Widawsky wrote:
> This will be useful for some upcoming patches which do more platform
> specific work. Having it in one central place just makes things a bit
> cleaner and easier.
>
> There is a small functional change here. There are more calls to th
On Tue, May 06, 2014 at 10:21:33PM -0700, Ben Widawsky wrote:
> AFAICT, it's impossible to actually infinitely retry the allocation in
> our current code. However, a small oversight on my part, slight bug, or
> future bug, could easily change that.
>
> To avoid a potential breakage, a simple retry
On Tue, May 06, 2014 at 10:21:30PM -0700, Ben Widawsky wrote:
> It was always the intention to do the topdown allocation for context
> objects (Chris' idea originally). Unfortunately, I never managed to land
> the patch, but someone else did, so now we can use it.
>
> As a reminder, hardware conte
On Tue, May 06, 2014 at 09:58:59PM -0700, Ben Widawsky wrote:
> From: Ben Widawsky
>
> Daniel requested in the bug that I use a 3GB fallback size. Since this
> is not in the spec as a valid size, I decided against it. We could
> potentially add a patch to bump it to 3GB on top of this one.
>
> T
On Wed, May 07, 2014 at 11:19:57AM +0530, Akash Goel wrote:
> On Mon, 2014-05-05 at 16:07 +0200, Daniel Vetter wrote:
> > On Mon, May 05, 2014 at 05:13:18PM +0530, akash.g...@intel.com wrote:
> > > From: Akash Goel
> > >
> > > There is a use case, when user space (display compositor) tries
> > >
On Tue, May 06, 2014 at 10:21:31PM -0700, Ben Widawsky wrote:
> The DRM node allocation code was already a bit of an ugly bit of code
> within a complex function. Removing it serves the purpose of cleaning
> the function up. More importantly, it provides a way to have a
> preallocated (address spac
57 matches
Mail list logo
