On Wed, 6 Jun 2012 11:33:21 +0200
Daniel Vetter wrote:
> On Tue, Jun 05, 2012 at 03:43:07PM -0700, Ben Widawsky wrote:
> > int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
> >
> > This should bump the libdrm version. We're waiting for context sup
Anyone aware of what this will break? It seems to be a much nicer thing
to do for callers. If people do not like it, I will probably just create
a #define drmIoctl2 or some such thing.
Cc: Daniel Vetter
Cc: Keith Packard
Signed-off-by: Ben Widawsky
---
xf86drm.c |4
1 file changed, 4
am at init
prototypes now have a signed input value
v4: update comments
fall back to correct polling behavior with new userspace and old kernel
Cc: Eric Anholt
Cc: Daniel Vetter
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr.h |1 +
intel/intel_bufmgr_ge
On Thu, 7 Jun 2012 09:10:08 +0200
Daniel Vetter wrote:
> On Wed, Jun 06, 2012 at 04:42:11PM -0700, Ben Widawsky wrote:
> > int drm_intel_gem_bo_wait(drm_intel_bo *bo, uint64_t timeout_ns)
> >
> > This should bump the libdrm version. We're waiting for context sup
0) should also return -ETIME.
Cc: Eric Anholt
Cc: Daniel Vetter
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr.h |1 +
intel/intel_bufmgr_gem.c | 57 ++
2 files changed, 58 insertions(+)
diff --git a/intel/intel_bufmgr.h b/intel/inte
On Tue, 05 Jun 2012 16:37:20 -0700
Kenneth Graunke wrote:
> On 06/04/2012 02:42 PM, Ben Widawsky wrote:
> > Setting myself up for a late night crying session once again. Most of the
> > people reading this probably know the history and reasons for the patches.
> > If
> &
om getting evicted.
I am not aware of a good way to test it's effectiveness
performance-wise; but it introduces no regressions with piglit on my
ILK, or SNB.
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr_gem.c | 46 ++
1 file changed, 34 in
On Tue, 19 Jun 2012 09:22:03 +0100
Chris Wilson wrote:
> On Mon, 18 Jun 2012 20:38:15 -0700, Ben Widawsky wrote:
> > The history on this patch goes back quite a way. This time around, the
> > patch builds on top of the map_unsynchronized that Eric pushed. Eric's
> &g
of the data arg
(file), but otherwise this is
Reviewed-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_gem_context.c |5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_con
The logic seemed to be inverse to me.
Signed-off-by: Ben Widawsky
---
intel/intel_decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index c9bfee4..eac48c3 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
two instances of
warning: cannot optimize loop, the loop counter may overflow
[-Wunsafe-loop-optimizations]
Signed-off-by: Ben Widawsky
---
intel/intel_decode.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index c9bfee4
On Wed, 27 Jun 2012 10:02:35 -0700
Eric Anholt wrote:
> Ben Widawsky writes:
>
> > The logic seemed to be inverse to me.
> >
> > Signed-off-by: Ben Widawsky
>
> Reviewed-by: Eric Anholt
This patch was bonghits :-(
My bad, I've fixed the problem upstream
git send-email doesn't appear to be doing the right thing.
Begin forwarded message:
Date: Fri, 29 Jun 2012 11:17:47 -0700
From: Ben Widawsky
To: xorg-announce at lists.freedesktop.org
Cc: mesa-dev at lists.freedesktop.org, intel-gfx at lists.freedesktop.org,
dri-devel at lists.freedeskto
On Fri, 29 Jun 2012 11:48:29 -0700
Ben Widawsky wrote:
> git send-email doesn't appear to be doing the right thing.
>
> Begin forwarded message:
>
> Date: Fri, 29 Jun 2012 11:17:47 -0700
> From: Ben Widawsky
> To: xorg-announce at lists.freedesktop.org
> Cc: mesa
gt; fix IS_ERR_OR_NULL -> IS_ERR
> v3: Fix Ville pointed out using buffer + kmalloc
> v4: add locking as per ickle review
> v5: allow re-exporting the original dma-buf (Daniel)
>
> Signed-off-by: Dave Airlie
I swear there was some other reason for the global hash... if only I
could remember it.
Acked-by: Ben Widawsky
mediate solution it seems you can demote the DRM_ERROR to
DRM_DEBUG_DRIVER, and add a check in valleyview_enable_rps for the pctx
value.
--
Ben Widawsky, Intel Open Source Technology Center
; Signed-off-by: Thierry Reding
Thanks for fixing this. It was driving me nuts.
Tested-by: Ben Widawsky
[snip]
--
Ben Widawsky, Intel Open Source Technology Center
gt; > always when lighting up more than one screen). All this fanciness
> > happens in intel_alloc_plane_obj in intel_display.c.
> >
> > Since no one else uses this we can savely remove the WARN without
> > repercursions.
> >
> > Reported-by: Ben Widaw
On Wed, Apr 09, 2014 at 07:25:37AM +0100, Chris Wilson wrote:
> On Tue, Apr 08, 2014 at 10:21:44AM -0700, Ben Widawsky wrote:
> > I am not convinced this is the correct solution. At least the way we
> > used this interface, it isn't meant to ever fail. I also didn't loo
PPC specific code is only compile tested.
Thanks.
Ben Widawsky (4):
drm/cache: Use wbinvd helpers
drm/cache: Try to be smarter about clflushing on x86
drm/cache: Return what type of cache flush occurred
drm/i915: Opportunistically reduce flushing at execbuf
drivers/gpu/drm/drm_ca
When the original drm code was written there were no centralized functions for
doing a coordinated wbinvd across all CPUs. Now (since 2010) there are, so use
them instead of rolling a new one.
Cc: Intel GFX
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/drm_cache.c | 12 +++-
1 file
. It would be nice to hear what
other developers who depend on this code think.
Cc: Intel GFX
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/drm_cache.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cac
fer and attempt to flush it first, the results would be even more desirable.
Cc: DRI Development
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h| 3 ++-
drivers/gpu/drm/i915/i915_gem.c| 12 +---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +-
very minimally considered for the sake of getting
the data for the profile.
Cc: Intel GFX
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/drm_cache.c | 34 +-
include/drm/drmP.h | 13 ++---
2 files changed, 35 insertions(+), 12 deletions(-)
diff --
On Sun, Dec 14, 2014 at 03:12:21PM +0200, Ville Syrjälä wrote:
> On Sat, Dec 13, 2014 at 07:08:24PM -0800, Ben Widawsky wrote:
> > If we're moving a bunch of buffers from the CPU domain to the GPU domain,
> > and
> > we've already blown out the entire cache
On Sun, Dec 14, 2014 at 08:06:20PM -0800, Jesse Barnes wrote:
> On 12/14/2014 4:59 AM, Chris Wilson wrote:
> >One of the things wbinvd is considered evil for is that it blocks the
> >CPU for an indeterminate amount of time - upsetting latency critcial
> >aspects of the OS. For example, the x86/mm h
On Mon, Dec 15, 2014 at 08:20:50AM +, Chris Wilson wrote:
> On Mon, Dec 15, 2014 at 08:55:32AM +0100, Daniel Vetter wrote:
> > On Sun, Dec 14, 2014 at 03:37:36PM -0800, Ben Widawsky wrote:
> > > On Sun, Dec 14, 2014 at 03:12:21PM +0200, Ville Syrjälä wrote:
> > > &
From: Ben Widawsky
When the original drm code was written there were no centralized functions for
doing a coordinated wbinvd across all CPUs. Now (since 2010) there are, so use
them instead of rolling a new one.
v2: On x86 UP systems the wbinvd_on_all_cpus() is defined as a static inline in
On Mon, Dec 15, 2014 at 08:39:35PM +, Chris Wilson wrote:
> On Mon, Dec 15, 2014 at 11:56:05AM -0800, Ben Widawsky wrote:
> > On Mon, Dec 15, 2014 at 08:20:50AM +, Chris Wilson wrote:
> > > On Mon, Dec 15, 2014 at 08:55:32AM +0100, Daniel Vetter wrote:
> > > >
On Sat, Dec 13, 2014 at 08:15:22PM -0800, Matt Turner wrote:
> On Sat, Dec 13, 2014 at 7:08 PM, Ben Widawsky
> wrote:
> > Any GEM driver which has very large objects and a slow CPU is subject to
> > very
> > long waits simply for clflushing incoherent objects. General
On Tue, Dec 16, 2014 at 07:57:39AM +, Chris Wilson wrote:
> On Mon, Dec 15, 2014 at 01:06:40PM -0800, Ben Widawsky wrote:
> > On Mon, Dec 15, 2014 at 08:39:35PM +, Chris Wilson wrote:
> > > On Mon, Dec 15, 2014 at 11:56:05AM -0800, Ben Widawsky wrote:
> > > >
eedesktop.org/~bwidawsk/drm-intel/log/?h=drm-intel-fixes
Nightly:
http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=drm-intel-nightly
--
Ben Widawsky, Intel Open Source Technology Center
hanks to Dan for catching this. /me hides
Cc: stable at kernel.org
Reported-by: Dan Carpenter
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_reg.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
4 has type 'long unsigned int'
Found by Fenguang's 0-DAY kernel build testing
Recommend to squash this in to, since it is not on an upstream branch
yet.
commit 00fc2c3c53d7bfc9a29e5f4bdf2677f0c399f3bc
Author: Ben Widawsky
Date: Thu Jan 17 12:45:14 2013 -0800
drm/i915
11:00:06 -0800)
Alexander van Heukelum (1):
Revert "drm/i915: assume all GM45 Acer laptops use inverted backlight PWM"
drivers/gpu/drm/i915/intel_display.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
--
Ben Widawsky, Intel Open Source Technology Center
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr_gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 48ff62e..3b1f584 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -1337,7 +1337,9 @@ int
The previous code would just use the potentially unallocated variable,
which is probably okay most of the time, but not very nice to the user
of the library.
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr_gem.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/intel
This was not done as a straight copy because reset_stats IOCTL landed in libdrm
before upstream kernel. (We'll do a similar thing for full PPGTT anyway, so
there isn't really a point in syncing exactly).
Signed-off-by: Ben Widawsky
---
include/drm/i915_d
Provides the parameter for full PPGTT on Intel.
Signed-off-by: Ben Widawsky
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index c5b8d40..d0d051a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -20,7 +20,7 @@
AC_PREREQ([2.63
thereis full PPGTT and per fd contexts). As such, callers can expect
NULL when this is not the case.
See the usage in mesa for details.
Cc: Kenneth Graunke
Signed-off-by: Ben Widawsky
---
include/drm/i915_drm.h| 1 +
intel/intel_bufmgr.h | 1 +
intel/intel_bufmgr_gem.c | 30
On Tue, Jan 07, 2014 at 08:53:36AM +0100, Daniel Vetter wrote:
> On Thu, Jan 02, 2014 at 07:50:33PM -1000, Ben Widawsky wrote:
> > This will allow mesa to determine if it needs to create a context, or
> > can reuse the default context. Reusing the default context saves memory,
>
debugfs helper functions.
Cc: linux-arm-kernel at lists.infradead.org
Cc: intel-gfx at lists.freedesktop.org
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/armada/armada_debugfs.c | 24 +---
drivers/gpu/drm/drm_debugfs.c | 24
drivers/gpu/drm/i915
t;> On Tue, Jan 14, 2014 at 06:14:06AM -0800, Ben Widawsky wrote:
> >>> > Both i915 and Armada had the exact same implementation. For an upcoming
> >>> > patch, I'd like to call this function from two different source files in
> >>> > i915,
On Thu, Jan 16, 2014 at 12:42:22AM +0100, Daniel Vetter wrote:
> On Wed, Jan 15, 2014 at 12:08:19PM -0800, Ben Widawsky wrote:
> > On Wed, Jan 15, 2014 at 09:45:28AM +0100, Daniel Vetter wrote:
> > > On Wed, Jan 15, 2014 at 9:39 AM, Daniel Vetter wrote:
> > > > On
The debugfs helper duplicates the functionality used by Armada, so let's
just use that.
WARNING: Not even compile tested. I can compile test this if required,
but I figured there'd be other kind people who already have the cross
toolchain setup.
Signed-off-by: Ben Widawsky
---
drive
The debugfs helper duplicates the functionality used by Armada, so let's
just use that.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c | 25 -
1 file changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs
quested-by: Daniel Vetter
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/drm_debugfs.c | 49 +++
include/drm/drmP.h| 14 +
2 files changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
ind
The debugfs helper duplicates the functionality used by Armada, so let's
just use that.
WARNING: only compile tested
Cc: Christian K?nig
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/radeon/radeon.h | 5 -
drivers/gpu/drm/radeon/radeon_ttm.c
is targeted for a new file, so there is no
reason to move it.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c | 48 +++--
1 file changed, 14 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915
On Wed, Jan 22, 2014 at 11:11:10AM +0100, Christian K?nig wrote:
> Am 21.01.2014 21:33, schrieb Ben Widawsky:
> >The debugfs helper duplicates the functionality used by Armada, so let's
> >just use that.
> >
> >WARNING: only compile tested
> >
> >Cc: Chr
sionally see missed IRQ on 16 (which is my USB) but it has only
started showing up in fairly recent dinq (haven't tried Linus') kernels
(I'd been using this laptop for over a year).
--
Ben Widawsky, Intel Open Source Technology Center
The kernel patches have now landed in Daniel's -next-queued tree.
Begin forwarded message:
Date: Fri, 11 May 2012 13:54:11 -0700
From: Ben Widawsky
To: intel-gfx at lists.freedesktop.org
Cc: Ben Widawsky
Subject: [Intel-gfx] [PATCH] intel: add a timed wait function
drm_intel_gem_bo_wa
On Wed, 30 May 2012 10:41:20 -0700
Eric Anholt wrote:
> On Sun, 27 May 2012 13:16:54 -0700, Ben Widawsky wrote:
> > diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> > index b776d2f..695a449 100644
> > --- a/intel/intel_bufmgr_gem.c
> > +++
er.
> -Daniel
What have we all agreed on for the color?
--
Ben Widawsky, Intel Open Source Technology Center
drivers/gpu/drm/i915/i915_drv.h:1545:2: warning: '__f' is static but
declared in inline function 'i915_gem_chipset_flush' which is not static
Reported-by: kbuild test robot
dri-devel-Reference: <50a4d41c.586VhmwghPuKZbkB%fengguang.wu at intel.com>
Signed-off-by:
> + const char *name;
> > };
> >
> > /**
> > @@ -324,7 +325,7 @@ struct drm_ioctl_desc {
> > */
> >
> > #define DRM_IOCTL_DEF_DRV(ioctl, _func, _flags)\
> > - [DRM_IOCTL_NR(DRM_##ioctl)] = {.cmd = DRM_##ioctl, .func = _func,
> > .flags = _flags, .cmd_drv = DRM_IOCTL_##ioctl}
> > + [DRM_IOCTL_NR(DRM_##ioctl)] = {.cmd = DRM_##ioctl, .func = _func,
> > .flags = _flags, .cmd_drv = DRM_IOCTL_##ioctl, .name = #ioctl}
> >
> > struct drm_magic_entry {
> > struct list_head head;
> > --
> > 1.8.1.4
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrj?l?
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
Nothing special here... I'm fine with not pushing any of the AUB stuff if
anyone has issues.
Ben Widawsky (2):
intel/bdw: Add broadwell chipset IDs
intel/bdw: Handle gen8 bufmgr_init
Damien Lespiau (2):
intel/bdw: Add gen8 to the decode init
intel/bdw: Update MI_BATCH_BUFFER_STAR
From: Ben Widawsky
v2: Rename s//IRIS/
Signed-off-by: Ben Widawsky
---
intel/intel_chipset.h | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index aeb439e..e5589be 100644
--- a/intel/intel_chipset.h
+++ b
From: Damien Lespiau
Signed-off-by: Damien Lespiau
Reviewed-by: Kenneth Graunke
Signed-off-by: Ben Widawsky
---
intel/intel_decode.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 1b80b75..c0a0caf 100644
--- a/intel
From: Kenneth Graunke
Since our aub file dumping's GTT handling is totally fake, we always put
everything in the low 4GB anyway and shouldn't ever need to set
AddressHigh to anything other than 0.
Signed-off-by: Kenneth Graunke
[ben: slight commit message change]
Signed-off-by: Be
From: Damien Lespiau
The command now takes a 48bits address and is thus 1 byte longer.
Signed-off-by: Damien Lespiau
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr_gem.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel
From: Ben Widawsky
[bwidawsk: Added Damien's SOB]
Signed-off-by: Damien Lespiau
Reviewed-by: Kenneth Graunke
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr_gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 27
rent, we can't play any games. Since the DDX doesn't use libdrm
however, I think it is fairly moot.
Acked-by: Ben Widawsky
--
Ben Widawsky, Intel Open Source Technology Center
exported by other drivers.
>
> v2: remove platform_device and do not attach to dma bufs
>
> Reviewed-by: Stéphane Marchesin
> Signed-off-by: Adam Jackson
> Signed-off-by: Ben Widawsky
> Signed-off-by: Zach Reizner
Looks good to me.
[snip]
ing them to userspace. The mmap is done using the mmap
> > operation exported by other drivers.
> >
> > v2: remove platform_device and do not attach to dma bufs
> >
> > Reviewed-by: Stéphane Marchesin
> > Signed-off-by: Adam Jackson
> > Signed-off-by: B
Cc: Kristian Høgsberg
Cc: Damien Lespiau
Signed-off-by: Ben Widawsky
---
intel/intel_chipset.h | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 253ea71..6c8dc73 100644
--- a/intel/intel_chipset.h
+++ b/intel
This removes ones which aren't used 0x190b, 192a), and adds some new ones. I
kept the original names where possible.
Cc: Kristian Høgsberg
Cc: Damien Lespiau
Signed-off-by: Ben Widawsky
---
intel/intel_chipset.h | 46 ++
1 file change
; drm_mm
> > >
> > > only the allocation side was converted, but not the freeing. Fix this
> > > up.
> > >
> > > Note that the only difference between put_block and remove_node is
> > > that the former fills up the preallocation cache.
en this patch myself a number of times.
Reviewed-by: Ben Widawsky
> ---
> drivers/gpu/drm/drm_mm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index f9d4873..d303e31 100644
> --- a/drivers
_create_block(), both related to stolen memory.
It also allows us to embed the drm_mm_node into the object currently
which provides a nice transition over to the new code.
v2: Reordered to do before ripping out obj->gtt_offset.
Some minor cleanups made available because of reordering.
CC:
Si
removal
Signed-off-by: Chris Wilson
CC:
Signed-off-by: Ben Widawsky
Conflicts:
drivers/gpu/drm/drm_mm.c
include/drm/drm_mm.h
---
drivers/gpu/drm/drm_mm.c | 121 +++
drivers/gpu/drm/i915/i915_gem.c| 4 +-
drivers/gpu/drm/i915
On Thu, Jul 04, 2013 at 11:19:58AM +0200, David Herrmann wrote:
> Hi
>
> On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky wrote:
> > For an upcoming patch where we introduce the i915 VMA, it's ideal to
> > have the drm_mm_node as part of the VMA struct (ie. it's
mann
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/drm_mm.c | 16 +--
drivers/gpu/drm/i915/i915_gem_gtt.c| 20 ++
drivers/gpu/drm/i915/i915_gem_stolen.c | 37 +-
include/drm/drm_mm.h | 9 +
On Fri, Jul 05, 2013 at 09:25:35PM +0200, Daniel Vetter wrote:
> On Thu, Jul 04, 2013 at 10:32:27PM +0200, David Herrmann wrote:
> > Hi
> >
> > On Thu, Jul 4, 2013 at 10:14 PM, Ben Widawsky wrote:
> > > For an upcoming patch where we introduce the i915 VMA
id Herrmann
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/drm_mm.c | 16 +--
drivers/gpu/drm/i915/i915_gem_gtt.c| 20 ++
drivers/gpu/drm/i915/i915_gem_stolen.c | 37 +-
include/drm/drm_mm.h | 9
nveniently this is the only user of the
interface.
CC: David Airlie
CC:
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/drm_mm.c | 19 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c| 8
drivers/gpu/drm/i915/i915_gem_stolen.c | 14 --
include/dr
removal
v4: by Ben:
Rebased on reserve_node addition.
Signed-off-by: Chris Wilson
CC:
Signed-off-by: Ben Widawsky
Conflicts:
drivers/gpu/drm/drm_mm.c
include/drm/drm_mm.h
Conflicts:
drivers/gpu/drm/drm_mm.c
drivers/gpu/drm/i915/i915_gem_gtt.c
drivers/gpu/drm
id Herrmann
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/drm_mm.c | 16 +--
drivers/gpu/drm/i915/i915_gem_gtt.c| 20 ++
drivers/gpu/drm/i915/i915_gem_stolen.c | 37 +-
include/drm/drm_mm.h | 9
nveniently this is the only user of the
interface.
CC: David Airlie
CC:
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/drm_mm.c | 19 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c| 8
drivers/gpu/drm/i915/i915_gem_stolen.c | 14 --
include/dr
removal
v4: by Ben:
Rebased on reserve_node addition.
Signed-off-by: Chris Wilson
CC:
Signed-off-by: Ben Widawsky
Conflicts:
drivers/gpu/drm/drm_mm.c
include/drm/drm_mm.h
Conflicts:
drivers/gpu/drm/drm_mm.c
drivers/gpu/drm/i915/i915_gem_gtt.c
drivers/gpu/drm
e {
kdata = kmalloc(asize, GFP_KERNEL);
if (!kdata) {
retcode = -ENOMEM;
goto err_i1;
}
}
if (asize > usize)
memset(kdata + usize, 0, asize - usize);
}
Sorry if these are stupid questions.
--
Ben Widawsky, Intel Open Source Technology Center
e {
kdata = kmalloc(asize, GFP_KERNEL);
if (!kdata) {
retcode = -ENOMEM;
goto err_i1;
}
}
if (asize > usize)
memset(kdata + usize, 0, asize - usize);
}
Sorry if these are stupid questions.
--
Ben Widawsky, Intel Open Source Technology Center
On Fri, Mar 15, 2013 at 08:24:03AM +, Chris Wilson wrote:
> On Thu, Mar 14, 2013 at 09:50:04PM -0700, Ben Widawsky wrote:
> > On Thu, Mar 14, 2013 at 12:59:57PM +, Chris Wilson wrote:
> > > In order to prevent a potential NULL deference with hostile userspace,
>
On Fri, Mar 15, 2013 at 10:06:19PM +, Chris Wilson wrote:
> On Fri, Mar 15, 2013 at 09:36:07AM -0700, Ben Widawsky wrote:
> > On Fri, Mar 15, 2013 at 08:24:03AM +, Chris Wilson wrote:
> > > That's what I thought too. Looking at the stack trace, the empirical
> &g
301 - 384 of 384 matches
Mail list logo
