> > > with vt-d enabled. This regression was introduced in
> > >
> > > commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549
> > > Author: Ben Widawsky
> > > Date: Fri Dec 6 14:11:14 2013 -0800
> > >
> > > drm/i915: Reorganize intel_enab
t being discussed, and it will certainly be more explicit if the right
> bits are poked into the context directly to keep the hw from falling over.
> -Chris
>
Paper is better than no paper. Anyway there are a couple of units where
we know NULL is better than not NULL (VFE is one). I have be
i << PAGE_SHIFT;
> -
> - memcpy_fromio(d, (void __iomem *) offset, PAGE_SIZE);
> } else {
> struct page *page;
> void *s;
> @@ -604,11 +618,9 @@ i915_error_object_create_sized(struct drm_i915_priva
On Mon, Apr 21, 2014 at 01:34:05PM +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.
u8 val)
> if (INTEL_INFO(dev_priv->dev)->gen <= 7 && !IS_HASWELL(dev_priv->dev))
> mask |= GEN6_PM_RP_UP_EI_EXPIRED;
>
> + mask |= GEN8_PMINTR_REDIRECT_TO_NON_DISP;
> +
> return ~mask;
> }
if (IS_BROADWELL(dev)), or gen>= 8
rm_device *dev)
> ironlake_enable_rc6(dev);
> intel_init_emon(dev);
> } else if (IS_GEN6(dev) || IS_GEN7(dev)) {
> + if (IS_VALLEYVIEW(dev))
> + valleyview_setup_pctx(dev);
Spurious hunk?
> /*
>
Also, s/Cheeryview/Cherryview
On Fri, Apr 25, 2014 at 02:42:26PM -0700, Ben Widawsky wrote:
> On Mon, Apr 21, 2014 at 01:34:07PM +0530, deepa...@linux.intel.com wrote:
> > From: Deepak S
> >
> > v2: Configure PCBR if BIOS fails allocate pcbr (deepak)
> >
> > v3
dev_priv->uncore.funcs.mmio_readl = chv_read32;
> + dev_priv->uncore.funcs.mmio_readq = chv_read64;
> +
> + } else {
> + dev_priv->uncore.funcs.mmio_writeb = gen8_write8;
> +
diff --git a/drivers/gpu/drm/i915/intel_sideband.c
> b/drivers/gpu/drm/i915/intel_sideband.c
> index b1a5514..8f6904d 100644
> --- a/drivers/gpu/drm/i915/intel_sideband.c
> +++ b/drivers/gpu/drm/i915/intel_sideband.c
> @@ -106,6 +106,21 @@ void vlv_bunit_write(struct drm_i915_private *dev_p
ORCEWAKE_RENDER & fwengine)) { \
> - if (--dev_priv->uncore.fw_rendercount == 0) \
> -
> (dev_priv)->uncore.funcs.force_wake_put(dev_priv, \
> -
> fwengine); \
> -
same cacheline, but !FORCEWAKE_VLV */
> + __raw_posting_read(dev_priv, FORCEWAKE_ACK_VLV);
> + if (!IS_CHERRYVIEW(dev_priv->dev))
> + gen6_gt_check_fifodbg(dev_priv);
You could save a read for the VLV case, but no big deal.
Reviewed-by: Ben Widawsky
>
+ break;
> + }
>
> DRM_DEBUG_DRIVER("GPLL enabled? %s\n", val & 0x10 ? "yes" : "no");
> DRM_DEBUG_DRIVER("GPU status: 0x%08x\n", val);
This, like all the other patches related to freq. don't seem to be
findable b
ew_delay = dev_priv->rps.cur_freq + adj;
> } else { /* unknown event */
> new_delay = dev_priv->rps.cur_freq;
splitting hairs a bit, but adding a new function that isn't named well
doesn't really improve readability. Since we only ever do it for one
c
There are a few places that expect 32b values for offsets
and these all won't work.
Cc: Rafael Barbalho
Cc: Chris Wilson
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/d
On Sat, Jan 25, 2014 at 08:10:06PM +0100, Daniel Vetter wrote:
> On Fri, Jan 24, 2014 at 12:13:44PM -0800, Ben Widawsky wrote:
> > ping
>
> Merged the first patch to topic/ppgtt, but punted on the 2nd - I think
> with Mika's improvement to the guilty batch detection we
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 16 +---
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 539f16db..cdde849
v2: 0 pad the new 8B fields or else intel_error_decode has a hard time.
Note, regardless we need an igt update.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 16 +---
2 files changed, 11 insertions(+), 9
See the relevant kernel patch for the details. I guess this breaks
support for older error state, I am not actually sure. Without
versioning our error state though, I cannot think of a better way.
Suggestions are welcome.
Signed-off-by: Ben Widawsky
---
tools/intel_error_decode.c | 14
riv->rps.enabled
> + && !dev_priv->rps.debugfs_disable_boost) {
> if (IS_VALLEYVIEW(dev))
> vlv_set_rps_idle(dev_priv);
> else
> @@ -3178,7 +3180,9 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv)
> struct drm_device *d
v2: 0 pad the new 8B fields or else intel_error_decode has a hard time.
Note, regardless we need an igt update.
v3: Make reloc_offset 64b also.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 18 ++
2
Previously, our code only had a 32b offset value for where the
batchbuffer starts. With full PPGTT, and 64b canonical GPU address
space, that is an insufficient value. The code to expand is pretty
straight forward, and only one platform needs to do anything with the
extra bits.
Signed-off-by: Ben
On Mon, Feb 24, 2014 at 03:08:04PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 19, 2014 at 10:19:23PM -0800, Ben Widawsky wrote:
> > Since the semaphore information is in an object, just dump it, and let
> > the user parse it later.
> >
> > NOTE: The page being
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
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-o
)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_ringbuffer.c | 33 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 ++--
3 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i9
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
e)
Do the proper math for the signal offset (Ville)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 51 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 14 -
3 files changed, 55 inser
orkaround for certain
> hardware issues, but it looks like those issues shouldn't affect us,
> for the momemnt at least. So my suggestion was to try w/o polling
> first (since there could be some power cost to polling) and add the
> poll bit if problems arise.
Signed-off-by: B
Syrjälä
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 42 -
drivers/gpu/drm/i915/intel_ringbuffer.h | 11 +
2 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm
This will be helpful in abstracting some of the code in preparation for
gen8 semaphores.
v2: Move mbox stuff to a separate struct
v3: Rebased over VCS2 work
Reviewed-by: Ville Syrjälä (v1)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c | 10 +--
drivers/gpu/drm/i915
14 14:01:11 2014 +0100
drm/i915: Consolidate binding parameters into flags
v5: VCS2 rebase
Replace hweight_long with hweight32
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 5 +-
drivers/gpu/drm/i915/i
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
emit (Ville)
Conditionally set .sync_to when semaphores are enabled (Ville)
v3: Rebased on VCS2
Replace hweight_long with hweight32 (Ville)
Reviewed-by: Ville Syrjälä (v1)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 173 +---
1 file ch
d, there's probably not much
other than execlists to be painful
The series is completely untested since the last rebase. I also didn't look
really closely to make sure the rebase was correct - I'm just totally short on
time atm. It was tested before that.
Ben Widawsky (13):
drm/i915
.
v2: v1 had a stale commit message
v3: Move everything in the is_semaphore_enabled() check
v4: VCS2 rebase
Remove double assignment of signal in render ring (Ville)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 187 +---
1 file changed,
shared #define
On a related not, gen8 will use a different number of dwords for
semaphores, but not for add request.
v2: Make number of dwords an explicit part of signalling (via function
argument). (Chris)
v3: very slight comment change
Reviewed-by: Ville Syrjälä
Signed-off-by: Ben Widawsky
On Tue, Apr 29, 2014 at 11:01:10AM +0200, Daniel Vetter wrote:
> On Tue, Apr 29, 2014 at 10:52:44AM +0200, Daniel Vetter wrote:
> > On Mon, Apr 28, 2014 at 06:45:50PM -0700, Ben Widawsky wrote:
> > > See the relevant kernel patch for the details. I guess this breaks
> > &
DE(1) |
> + rc6_mask);
>
> /* 4 Program defaults and thresholds for RPS*/
> I915_WRITE(GEN6_RPNSWREQ,
> --
> 1.7.9.5
>
> _______
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.or
On Wed, Apr 30, 2014 at 08:13:25AM +0100, Chris Wilson wrote:
> On Tue, Apr 29, 2014 at 02:52:40PM -0700, Ben Widawsky wrote:
> > 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.
> >
> > A
On Wed, Apr 30, 2014 at 08:03:27PM +0100, Chris Wilson wrote:
> On Wed, Apr 30, 2014 at 11:44:47AM -0700, Ben Widawsky wrote:
> > On Wed, Apr 30, 2014 at 08:13:25AM +0100, Chris Wilson wrote:
> > > On Tue, Apr 29, 2014 at 02:52:40PM -0700, Ben Widawsky wrote:
> > > >
On Wed, Apr 30, 2014 at 01:34:36PM -0700, Kristen Carlson Accardi wrote:
> On Tue, 29 Apr 2014 22:31:49 -0700
> Ben Widawsky wrote:
>
> > On Wed, Apr 09, 2014 at 11:44:06AM -0700, Tom O'Rourke wrote:
> > > Higher RC6 residency is observed using timeout mode
&g
t;
> commit 0eea67eb26000657079b7fc41079097942339452
> Author: Ben Widawsky
> Date: Fri Dec 6 14:11:19 2013 -0800
>
> drm/i915: Create a per file_priv default context
>
> Signed-off-by: Chris Wilson
> Cc: Ben Widawsky
> Cc: Mika Kuoppala
> Cc: Kenneth Graunke
Acked-by
intel_bufmgr_priv.h b/intel/intel_bufmgr_priv.h
> index 2592d42..3aa1abb 100644
> --- a/intel/intel_bufmgr_priv.h
> +++ b/intel/intel_bufmgr_priv.h
> @@ -60,7 +60,17 @@ struct _drm_intel_bufmgr {
> const char *name,
> unsigned long size,
> unsigned int alignment);
> -
> + /**
> + * Allocate a buffer object from an existing user accessible
> + * address malloc'd with the provided size.
> + * Alignment is used when mapping to the gtt.
> + * Flags may be I915_VMAP_READ_ONLY or I915_USERPTR_UNSYNCHRONIZED
> + */
> + drm_intel_bo *(*bo_alloc_userptr)(drm_intel_bufmgr *bufmgr,
> + const char *name, void *addr,
> + uint32_t tiling_mode, uint32_t stride,
> + unsigned long size,
> + unsigned long flags);
> /**
>* Allocate a tiled buffer object.
>*
Probably don't need the special function pointer yet since I don't think
we can yet envision use cases which will require any kind of special
handling. A simple has_userptr in bufmgr_gem will probably suffice. But
I don't care too much either way.
I couldn't spot any real bugs...
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, Apr 30, 2014 at 02:14:02PM -0700, Kristen Carlson Accardi wrote:
> On Thu, 01 May 2014 00:03:15 +0300
> Imre Deak wrote:
>
> > On Wed, 2014-04-30 at 13:41 -0700, Ben Widawsky wrote:
> > > On Wed, Apr 30, 2014 at 01:34:36PM -0700, Kristen Carlson Accardi wrote:
>
o make the code
as future-proof, and as clear as possible, by match the spec.
Cc: Art Runyan
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drive
On Fri, May 02, 2014 at 04:00:25PM +0300, Ville Syrjälä wrote:
> On Fri, May 02, 2014 at 09:38:11AM +0100, Chris Wilson wrote:
> > On Fri, May 02, 2014 at 11:19:27AM +0300, Ville Syrjälä wrote:
> > > On Thu, May 01, 2014 at 06:47:54PM -0700, Ben Widawsky wrote:
> > > &
On Fri, May 02, 2014 at 11:27:45AM +0100, Tvrtko Ursulin wrote:
>
> On 05/01/2014 07:47 PM, Ben Widawsky wrote:
> >On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>Allow userptr objects to be created and
On Fri, May 02, 2014 at 09:35:20PM +0100, Chris Wilson wrote:
> On Fri, May 02, 2014 at 10:00:01AM -0700, Ben Widawsky wrote:
> > On Fri, May 02, 2014 at 04:00:25PM +0300, Ville Syrjälä wrote:
> > > On Fri, May 02, 2014 at 09:38:11AM +0100, Chris Wilson wrote:
> > > >
Each ring only has ring-1 sync seqnos. It is a bug to try to print
extra.
This should be squashed into drm/i915: semaphore debugfs. I don't have
an easy way at the moment to do the rebase and resend, but that is what
should be done.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm
nodes. With 64b PPGTT, and something like a userptr
interface, doing this becomes a really desirable thing to do.
In any event, I think the patches stand as a nice cleanup on their own,
provided they don't blow anything up. I haven't had a chance to do
anything but compile these
what is what happens with the normal bottom up
allocation we do today. Doing a top down allocation increases the odds
that the HW contexts can get out of the way, especially with per FD
contexts as is done in full PPGTT
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +
We only actually want to retry if the failure mode was not enough space,
and so we'll evict. This will help us realize quickly in case we missed
a change in the common drm code.
NOTE: A similar check is already in place for the GEN7 PPGTT code.
Signed-off-by: Ben Widawsky
---
drivers/gp
l. Frankly, I'd rather overflow the stack
and blow it up than loop forever. In either case, this is addressed in
the next patch.
I believe, and intend, that other than the stack usage, there is no
functional change here.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/
eturn address and such)... it's way more than we
want to use already. 64b architectures might be slightly better, since
6? of the first args will get passed through registers, but it's still
bad.
If anything, we might want to do way less than 100, like 3.
Signed-off-by: Ben Widawsky
---
The two users were already really similar. By adding the flags (I hope
you like a lot of arguments in your functions), we can satisfy both
callers quite well.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 16
drivers/gpu/drm/i915/i915_gem.c | 34
end upon (e.g. igt/gem_exec_lut_handle), this raises the
> spectre that the ppgtt will randomly call i915_gpu_idle() and recurse
> back into intel_ring_begin().
Forgive my ignorance. Why is i915_gpu_idle() randomly being called for
PPGTT? I don't see anything PPGTT specific here.
[snip
; +};
> +
> +#endif /* __INTEL_RENDERSTATE_GEN6 */
> diff --git a/drivers/gpu/drm/i915/intel_renderstate_gen7.h
> b/drivers/gpu/drm/i915/intel_renderstate_gen7.h
> new file mode 100644
> index 000..9b1420b
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_renderstate_gen7.h
> @@ -0,0 +1,11 @@
> +#ifndef __INTEL_RENDERSTATE_GEN7
> +#define __INTEL_RENDERSTATE_GEN7
> +
> +static const uint32_t gen7_null_state_relocs[] = {
> +};
> +
> +static const uint32_t gen7_null_state_batch[] = {
> + MI_BATCH_BUFFER_END,
> +};
> +
> +#endif /* __INTEL_RENDERSTATE_GEN7 */
> diff --git a/drivers/gpu/drm/i915/intel_renderstate_gen8.h
> b/drivers/gpu/drm/i915/intel_renderstate_gen8.h
> new file mode 100644
> index 000..d349dda
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_renderstate_gen8.h
> @@ -0,0 +1,11 @@
> +#ifndef __INTEL_RENDERSTATE_GEN8
> +#define __INTEL_RENDERSTATE_GEN8
> +
> +static const uint32_t gen8_null_state_relocs[] = {
> +};
> +
> +static const uint32_t gen8_null_state_batch[] = {
> + MI_BATCH_BUFFER_END,
> +};
> +
> +#endif /* __INTEL_RENDERSTATE_GEN8 */
> --
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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.
This probably should be CC: stable - but I'll let the powers that be
d
r the intended purpose, but I
thought it was a nice patch to keep around.
v2: s/i915_gem_bind_vma/i915_gem_vma_bind/
s/i915_gem_unbind_vma/i915_gem_vma_unbind/
(Chris)
v3: Missed one spot
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h| 3 +++
drivers/gpu/drm
what is what happens with the normal bottom up
allocation we do today. Doing a top down allocation increases the odds
that the HW contexts can get out of the way, especially with per FD
contexts as is done in full PPGTT
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +
We only actually want to retry if the failure mode was not enough space,
and so we'll evict. This will help us realize quickly in case we missed
a change in the common drm code.
NOTE: A similar check is already in place for the GEN7 PPGTT code.
Signed-off-by: Ben Widawsky
---
drivers/gp
they shouldn't.
I have no issue with an eventual revert of this patch. It makes sense
for what we have today.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_
The two users were already really similar. By adding the flags (I hope
you like a lot of arguments in your functions), we can satisfy both
callers quite well.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 16
drivers/gpu/drm/i915/i915_gem.c | 34
zed should fix both of the issues. This patch
which should have no functional impact begins to address these issues
without intentionally breaking things.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h| 4 +++-
drivers/gpu/drm/i915/i915_gem.c
requiring just this.
A nice benefit of this is we should no longer be able to clobber GTT
only objects from the aliasing PPGTT.
TEST=gem_storedw_batches_loop
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/i915_gem.c| 6 --
drivers
l. Frankly, I'd rather overflow the stack
and blow it up than loop forever. In either case, this is addressed in
the next patch.
I believe, and intend, that other than the stack usage, there is no
functional change here.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/
eturn address and such)... it's way more than we
want to use already. 64b architectures might be slightly better, since
6? of the first args will get passed through registers, but it's still
bad.
If anything, we might want to do way less than 100, like 3.
Signed-off-by: Ben Widawsky
---
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 bu
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
>
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
> &g
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:
> > > >
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
> > -
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
14 14:01:11 2014 +0100
drm/i915: Consolidate binding parameters into flags
v5: VCS2 rebase
Replace hweight_long with hweight32
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 5 +-
drivers/gpu/drm/i915/i
e)
Do the proper math for the signal offset (Ville)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 51 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 14 -
3 files changed, 55 inser
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
orkaround for certain
> hardware issues, but it looks like those issues shouldn't affect us,
> for the momemnt at least. So my suggestion was to try w/o polling
> first (since there could be some power cost to polling) and add the
> poll bit if problems arise.
Signed-off-by: B
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
g I am aware. If
someone could take over the patches, and get them merged, I think it'd really
help in getting this useful feature added to our driver for gen8.
* The last two patches aren't needed, but are here for posterity.
If nobody has taken this over when I return I will see if
)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_ringbuffer.c | 33 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 ++--
3 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i9
.
v2: v1 had a stale commit message
v3: Move everything in the is_semaphore_enabled() check
v4: VCS2 rebase
Remove double assignment of signal in render ring (Ville)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 225 +---
1 file changed,
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-o
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:
> > > >
emit (Ville)
Conditionally set .sync_to when semaphores are enabled (Ville)
v3: Rebased on VCS2
Replace hweight_long with hweight32 (Ville)
v4: Pull out the accidentally squashed hunk from the next patch after
rebase (Daniel).
Reviewed-by: Ville Syrjälä (v1)
Signed-off-by: Ben Widawsky
---
dr
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 siz
ssion from a revert of the revert:
commit 7907f45bf9f67a1c5e5d4ae05bab428d7c2f43b2
Author: Ben Widawsky
Date: Wed Feb 19 22:05:46 2014 -0800
Revert "drm/i915/bdw: Limit GTT to 2GB"
v2: Change ifdef to 32b, instead of ifndef
update comment
v3. Update comment to not wrap (Daniel)
Hi everyone. I'll be out on vacation until WW21.3. In my absence if you
need an owner for any critical bugs, please make Rodrigo the point of
contact.
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Inte
TR_UNSYNCHRONIZED 0x8000
> + /**
> + * Returned handle for the object.
> + *
> + * Object handles are nonzero.
> + */
> + __u32 handle;
> +};
> +
Oh yeah. I want a ctx_id here as well. Chris, any objection to adding
this?
[snip]
--
Ben Widawsky
This reverts commit 7d9c477966e739a52d4c9655149958a2671ef376.
Conflicts:
drivers/gpu/drm/i915/i915_dma.c
include/uapi/drm/i915_drm.h
---
drivers/gpu/drm/i915/i915_dma.c | 5 -
include/uapi/drm/i915_drm.h | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/
think it's really relevant here.
One last thing. Intel GPU tools, as it stands today, makes a lot of
assumptions about using an address space > 32b. I have not had time to
fix this. It is something which needs fixing before this series could
even be considered testable.
[1] http://lists
vma and contexts under full-ppgtt,
but this is useful piece of defensive programming enforcing our
userspace API contract.
Cc: Ben Widawsky
Signed-off-by: Chris Wilson
Reviewed-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_dma.c | 9 +
1 file changed, 9 insertions(+)
diff --git a
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_context.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 6e2145b..29dd825 100644
--- a/drivers/gpu/drm/i915
requiring just this.
A nice benefit of this is we should no longer be able to clobber GTT
only objects from the aliasing PPGTT.
v2: Only add aliasing binds for the GGTT/Aliasing PPGTT at execbuf
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915
zed should fix both of the issues. This patch
which should have no functional impact begins to address these issues
without intentionally breaking things.
v2: Replace PIN_GLOBAL with PIN_ALIASING in _pin(). Copy paste error
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h
In gen8, 32b PPGTT has always had one "pdp" (it doesn't actually have
one, but it resembles having one). The #define was confusing as is, and
using "PDPE" is a much better description.
sed -i 's/GEN8_LEGACY_PDPS/GEN8_LEGACY_PDPES/' drivers/gpu/drm/i915/
v2: s/i915_gem_bind_vma/i915_gem_vma_bind/
s/i915_gem_unbind_vma/i915_gem_vma_unbind/
(Chris)
v3: Missed one spot
v4: Don't change the trace events (Daniel)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h| 3 +++
drivers/gpu/drm/i915/i915_gem.c
The current code will both potentially print a WARN, and setup part of
the PPGTT structure. Neither of these harm the current code, it is
simply for clarity, and to perhaps prevent later bugs, or weird
debug messages.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 5
cific init, now that GEN8 exists.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 5ca8208..08b1b25 1
Move the remaining members over to the new page table structures.
This can be squashed with the previous commit if desire. The reasoning
is the same as that patch. I simply felt it is easier to review if split.
Signed-off-by: Ben Widawsky
Conflicts:
drivers/gpu/drm/i915/i915_drv.h
trivial.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 7c06c43..2002393 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
601 - 700 of 3830 matches
Mail list logo
