in
i915_gem_object_create_stolen_for_preallocated since that can be
called before stolen memory is fully set up. Spotted by Chris Wilson.
v4: Readd the conversion in i915_gem_object_create_stolen_for_preallocated,
the check is for the dev_priv-mm.gtt_space drm_mm, the stolen
allocatot must already be initialized when calling that function
.
Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
I can't see anything else that we setup and miss freeing along the
failed open, so if it compiles ;-)
Reviewed-by: Chris Wilson chris
and false instead of 1 and 0.
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
if (WARN_ON(raw_edid == NULL))
return false;
Otherwise it is just a WARN_ON() followed by a BUG() :)
-Chris
--
Chris Wilson, Intel Open Source Technology
and false instead of 1 and 0.
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
remains black. This state persists until reboot. I suspect [1] is the same
bug,
none of the hints there helped.
It is not that bug. This bug I believe is that no one has figured out
how to reprobe the eDP and initialise it after a vgaswitch.
-Chris
--
Chris Wilson, Intel Open Source Technology
should also be able to accomplish the same if you were to
reload the i915 module after doing the vgaswitch.
A starting point for patches would be for a notifier to run after
vgaswitch, and for i915 to hook into that notification and reprobe
panels (LVDS/eDP).
-Chris
--
Chris Wilson, Intel Open Source
the teardown ourselves.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_debugfs.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index a05087c
All inode removal is handled for us by the core.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Alex Deucher alexander.deuc...@amd.com
Cc: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon_device.c | 4
drivers/gpu/drm/radeon/radeon_drv.c| 2 --
2 files
All inode removal is handled for us by the core.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/qxl/qxl_debugfs.c | 9 -
drivers/gpu/drm/qxl/qxl_drv.c | 1 -
drivers/gpu/drm/qxl/qxl_drv.h | 1 -
3 files changed, 11
All inode removal is handled for us by the core.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Skeggs bske...@redhat.com
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 7 ---
drivers/gpu/drm/nouveau/nouveau_debugfs.h | 6 --
drivers/gpu/drm/nouveau/nouveau_drm.c | 1
All inode removal is handled for us by the core.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Rob Clark robdcl...@gmail.com
---
drivers/gpu/drm/omapdrm/omap_debugfs.c | 10 --
drivers/gpu/drm/omapdrm/omap_drv.c | 1 -
drivers/gpu/drm/omapdrm/omap_drv.h | 1 -
3
All inode removal is handled for us by the core.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Darren Etheridge detheri...@ti.com
Cc: Benoit Parrot bpar...@ti.com
Cc: Rob Clark robdcl...@gmail.com
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 12
drivers/gpu/drm/tilcdc
All inode removal is handled for us by the core.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Ben Widawsky b...@bwidawsl.net
---
drivers/gpu/drm/i915/i915_debugfs.c | 16
drivers/gpu/drm/i915/i915_drv.c | 1 -
drivers/gpu
No driver did anything other than remove its lists of debugfs inodes
which is now handled by the core. So having removed all the driver
callbacks, we can now remove the hook from the core.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm
necessary for now, but might be in the future.
Cc: Patrik Jakobsson patrik.r.jakobs...@gmail.com
Signed-off-by: David Herrmann dh.herrm...@gmail.com
You should also CC any driver maintainers that the patch touches. They
should be acking it at the very least.
-Chris
--
Chris Wilson, Intel Open
to give this
an Acked-by: Chris Wilson ch...@chris-wilson.co.uk
Also, we need to reapply the w/a after a Function Level Reset, in other
words we do need to repeat the init_clock_gating after
intel_gpu_reset().
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
are returning information about other clients to a non-root
user? Including the magic required to authorize oneself...
This ioctl has to be neutered.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel
timestamps for vblank events. Which in turn causes e.g. gnome-shell to
hang after a DPMS off cycle with current xf86-video-ati Git.
Cc: sta...@vger.kernel.org
Signed-off-by: Michel Dänzer michel.daen...@amd.com
Dave, it looks like you missed this patch.
-Chris
--
Chris Wilson, Intel Open Source
the error to the user. In the case of success, the only
reference to the object that then remains is through the new handle.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
guesses.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Jul 25, 2013 at 06:35:10PM +0200, Sedat Dilek wrote:
On Thu, Jul 25, 2013 at 6:31 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Thu, Jul 25, 2013 at 06:11:18PM +0200, Sedat Dilek wrote:
Might be OT, but I cannot use my X graphics stack containing
libdrm-2.4.46, mesa-9.1.5
On Thu, Jul 25, 2013 at 07:15:03PM +0200, Sedat Dilek wrote:
On Thu, Jul 25, 2013 at 7:01 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Basically boils down to either an object allocation failure or mmaping
failure. I think dmesg with drm.debug=7 is the next step.
Attached! Thanks
On Thu, Jul 25, 2013 at 07:52:22PM +0200, Sedat Dilek wrote:
On Thu, Jul 25, 2013 at 7:26 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Thu, Jul 25, 2013 at 07:15:03PM +0200, Sedat Dilek wrote:
On Thu, Jul 25, 2013 at 7:01 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote
= drm_vma_node_offset_addr(obj-base.vma_node);
@@ -1558,6 +1567,7 @@ out:
drm_gem_object_unreference(obj-base);
unlock:
mutex_unlock(dev-struct_mutex);
+ DRM_DEBUG_DRIVER(done, ret=%d\n, ret);
return ret;
}
--
Chris Wilson, Intel Open Source Technology Centre
))
+ if (!intel_glamor_create_screen_resources(screen)) {
+ ErrorF(bang: %d\n, __LINE__);
return FALSE;
+ }
return TRUE;
}
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel
, __func__, __LINE__, -ret);
return FALSE;
+ }
pixmap = screen-GetScreenPixmap(screen);
intel_set_pixmap_bo(pixmap, bo);
which is most likely to report EINVAL (22)?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Fri, Jul 26, 2013 at 01:21:07AM +0200, Sedat Dilek wrote:
On Thu, Jul 25, 2013 at 11:52 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Thu, Jul 25, 2013 at 10:07:02PM +0200, Sedat Dilek wrote:
What means the bang line?
[54.564] (II) GLX: Initialized DRI2 GL provider
for map failures in 2.20.10 - which
would explain why going back to the older ddx masks the issue. And yes,
this means we do require a kernel bisect - or some passing inspiron.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing
attachment.
Yes, same failure (GTT mmaps) but at a later point, and UXA has no
fallback plan.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
/2012-April/016738.html
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
error path in i915_setup_compression()
You only applied it to the err path, I was expecting err_fb to do the
kfree(compressed_llb) as well. Feel free to rename those to err_fb and
err_llb respectively if you think that helps.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Sat, Jul 27, 2013 at 03:09:48PM +0200, David Herrmann wrote:
Hi
On Sat, Jul 27, 2013 at 3:06 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Sat, Jul 27, 2013 at 01:38:42PM +0200, David Herrmann wrote:
i915 is the last user of the weird search+get_block drm_mm API. Convert
not simply convert to using kref_put_mutex() directly.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
include/drm/drmP.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 4b518e0..ee2ef27 100644
--- a/include/drm/drmP.h
On Tue, Aug 06, 2013 at 11:27:50PM +0200, Daniel Vetter wrote:
On Tue, Aug 06, 2013 at 09:59:46AM +0100, Chris Wilson wrote:
We can apply the same optimisation tricks as kref_put_mutex() in our
local equivalent function. However, we have a different locking semantic
(we unlock ourselves
daniel.vet...@ffwll.ch
Papers over the WARN with iffy locking. Not all callers hold
struct_mutex, right? Worse some do, some don't...
What's the long term plan here?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
to export it, too.
Cc: Inki Dae inki@samsung.com
Cc: Intel Graphics Development intel-...@lists.freedesktop.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Any perverse driver could always call into drm_gem_dmabuf_release() with
container_of().
Reviewed-by: Chris Wilson ch...@chris
On Wed, Aug 07, 2013 at 11:15:08AM +0200, Daniel Vetter wrote:
Makes it more obviously correct what tricks we play by reusing the drm
prime release helper.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
I do like these little typesafe cast helpers.
Reviewed-by: Chris Wilson ch...@chris
callback the lack of the
gpu hang checks doesn't matter.
Furthermore the goal is to eventually have per dma-buf locking done
by callers with ww mutexes, so this will then be removed.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Ugh, who can't
On Wed, Aug 07, 2013 at 08:50:20PM -0400, Konrad Rzeszutek Wilk wrote:
On Wed, Aug 07, 2013 at 12:09:32PM +0200, Daniel Vetter wrote:
This fixes a WARN in i915_gem_free_object when the
obj-pages_pin_count isn't 0.
v2: Add locking to unmap, noticed by Chris Wilson. Note that even
though
; level++) {
- if (!lp_results[level - 1].fbc_val lp_maximums-fbc) {
+ if (lp_results[level - 1].fbc_val = lp_maximums-fbc) {
I didn't spot that '!' at all. It's a stray and should be just removed.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
.
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
absolutely sure that is a hardware error and not a software SDVO
protocol goof? TARGET_NOT_SPECIFIED seems pretty specific.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
*/
- alignment = 0;
+ alignment = 256 * 1024;
break;
case I915_TILING_Y:
/* Despite that we check this in framebuffer_init userspace can
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel
On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
After a logout from my BROKEN Unity-2D session - the login-screen
for LightDM seems to be OK.
Then entering my Unity-2D desktop is OK - no screen corruptions.
What hardware and display do you have?
-Chris
--
Chris Wilson, Intel
On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote:
After a logout from my BROKEN Unity-2D session - the login-screen
for LightDM seems
5456fe3882812aba251886e36fe55bfefb8e8829
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Thu Aug 8 14:41:07 2013 +0100
drm/i915: Allocate LLC ringbuffers from stolen
As stolen objects now behave identically (wrt to default LLC cacheing)
as their normal system counterparts, we
On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote:
On Tue, Aug 13
On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
Files attached.
Can you also please attach a full dmesg so I can check for anything
unusual?
Thanks,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
Files attached.
Can you also please attach a full dmesg so I can check for anything
On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue
into it.)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
) to use the now
semantically equivalent drm_gem_vm_open.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Dave Airlie airl...@redhat.com
Cc: Rob Clark robdcl...@gmail.com
Cc: Inki Dae inki@samsung.com
---
drivers/gpu/drm/drm_bufs.c | 1 +
drivers/gpu/drm/drm_drv.c
);
147 }
Correct. Patch is en route already, thanks.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Aug 19, 2013 at 09:53:23AM +0300, Dan Carpenter wrote:
We sometimes call i915_vma_unbind() inside the loop and that can free
the vma.
Oh. That is bad. The vma needs to be pinned here to prevent it being freed as
otherwise we lose track of it during the execbuffer.
Ben?
-Chris
--
Chris
, i915_reg_read_ioctl, DRM_UNLOCKED),
And reg read
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
for reads. So
if you can make it a DRM_MASTER || cappable(SYS_ADMID) privileged
operation instead, I can live with that.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
-t
Cc: sta...@vger.kernel.org
Signed-off-by: David Herrmann dh.herrm...@gmail.com
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel
?
It's a bug in the ddx, that was fixed in 2.14.902 (2011-03-29).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
, this series introduces a
new SET_CAP ioctl.
So the flow goes as following:
1/ the DRM client (limited to the DRM master) can notify it knows about
those
flags through SET_CAP
Is this capability dropped along with a change in master then?
-Chris
--
Chris Wilson, Intel Open Source Technology
if needed.
This could be renamed to SET_CLIENT_CAP and also drop the master
requirement. (That some capabilities only affect master ioctls is
irrelevant I think, as the client will be master at that time.)
That would reduce the confusion between the device caps and the session
caps.
-Chris
--
Chris
a GOOD (tm) thing,
right? ;-)
Not quite, as it would be possible for the evil userspace to trigger a
GPU hang that would cause the sane userspace to spin indefinitely
waiting for the error recovery to kick in.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Fri, Sep 27, 2013 at 03:08:27PM +0300, Jani Nikula wrote:
We have some code duplication related to EDID duplication. Add a helper.
Lgtm, debated the merits of assuming GFP_KERNEL and inlining, then thought
better of it.
All 3, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris
In the process, we can make the error handling more resilient.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/drm_edid_load.c | 75 +--
1 file changed, 32 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers
On Tue, Oct 01, 2013 at 06:49:42PM +0300, Ville Syrjälä wrote:
On Tue, Oct 01, 2013 at 02:06:13PM +0100, Chris Wilson wrote:
CC drivers/gpu/drm/drm_edid_load.o
drivers/gpu/drm/drm_edid_load.c: In function ‘drm_load_edid_firmware’:
include/linux/err.h:39:17: warning: ‘edid’ may
and prevent gcc warning about unitialised variables along
the error paths.
v2: Load builtins first, fix gcc second (Jani) and cosmetics (Ville).
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Jani Nikula jani.nik...@linux.intel.com
---
drivers
anyway want a
multiple of EDID_LENGTH.
Hmm, I'm missing the point here then. If edid_size() only returns a
non-zero mulitple of EDID_LENGTH, data_size must also be a non-zero
multiple of EDID_LENGTH for it to pass.
If you want to simply give me your ideal check_size()... :)
-Chris
--
Chris
and prevent gcc warning about unitialised variables along
the error paths.
v2: Load builtins first, fix gcc second (Jani) and cosmetics (Ville).
v3: Verify that we do not read beyond the end of the fwdata (Ville)
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj
-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Jani Nikula jani.nik...@linux.intel.com
Reviewed-by: Jani Nikula jani.nik...@linux.intel.com
---
drivers/gpu/drm/drm_edid_load.c | 108
1 file changed, 54
.
Review highly welcome.
I still think this is misleading. fbdev to me is /dev/fb not fbcon. They
are related only by implementation.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
and the patch, and why the revert is required.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Oct 08, 2013 at 10:18:54AM -0600, Alex Williamson wrote:
On Tue, 2013-10-08 at 17:08 +0100, Chris Wilson wrote:
On Tue, Oct 08, 2013 at 05:27:28PM +0200, Daniel Vetter wrote:
Adding drm/i915 into the vga arbiter chain means that X (in a piece of
well-meant paranoia) will do a get
that the mode fitted in the fb
provided by the user and by the bios. Which caught a few problems in the
past.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org
with drm.debug=7 and
--enable-debug=full Xorg.0.log?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
a full dmesg and Xorg.0.log may help unravel the mystery
of what is failing on your machine.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman
it!
v4: Kerneldoc for enum drm_mm_insert_mode.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Cc: Alex Deucher <alexander.deuc...@amd.com>
Cc: "Christian König" <christian.koe...@amd.com>
Cc:
ted with the struct drm_atomic_state and friends.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
---
t_pages_internal().
> >
> > So limit the maximum page order to be used according to the maximum
> > swiotlb segment size instead to the complete swiotlb size.
> >
> > Signed-off-by: Juergen Gross <jgr...@suse.com>
> Fixes: 920cf4194954 ("drm/i915: Int
On Mon, Feb 06, 2017 at 12:21:48PM +0200, Joonas Lahtinen wrote:
> On la, 2017-02-04 at 11:19 +0000, Chris Wilson wrote:
> > As we require valid start/end parameters, we can replace the initial
> > potential NULL with a pointer to the drm_mm.head_node and so reduce the
> > te
We can not allow the worker to run after its fbdev, or even the module,
has been removed.
Fixes: cfe63423d9be ("drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()")
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Noralf Trønnes <nor...@tronnes.org>
Cc: Dan
We can not allow the worker to run after its fbdev, or even the module,
has been removed.
Fixes: eaa434defaca ("drm/fb-helper: Add fb_deferred_io support")
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Noralf Trønnes <nor...@tronnes.org>
Cc: Daniel Vetter <d
te that I don't explain what release_fbi does, because that function
> will disappear in the next patch ...
>
> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
lper->fbdev = NULL;
> +
> mutex_lock(_fb_helper_lock);
> if (!list_empty(_helper->kernel_fb_list)) {
> list_del(_helper->kernel_fb_list);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
ks which now occur in the error paths.
The error cleanup is a bit unobvious. The fbi is allocated during the
create/initial_fb callback, which is after a successful
framebuffer_init. The caller must be prepared to do a framebuffer_fini
(and so release_fbi will be handled if required) on failur
Check that if we request bottom-up allocation from drm_mm_insert_node()
we receive the next available hole from the bottom.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
---
drivers/gpu/drm/selftests/drm_mm_selft
it!
v4: Kerneldoc for enum drm_mm_insert_mode.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Cc: Alex Deucher <alexander.deuc...@amd.com>
Cc: "Christian König" <christian.koe...@amd.com>
Cc:
x_order = min(max_order, ilog2(max_segment));
> >+}
> >+}
> > #endif
> >
> > gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
> >
>
> Looks OK to me. We could bikeshed it to only use
> swiotlb_max_segment() which I think was the
old new delta
i915_gem_evict_for_node 719 693 -26
(No other users outside of the test harness.)
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
---
dri
On Fri, Jan 20, 2017 at 10:36:55PM +0800, Geliang Tang wrote:
> To make the code clearer, use rb_entry() instead of container_of() to
> deal with rbtree.
>
> Signed-off-by: Geliang Tang <geliangt...@gmail.com>
Applied, thanks.
-Chris
--
Chris Wilson, Intel Open Source
On Sat, Jan 21, 2017 at 11:21:28PM +0200, Laurent Pinchart wrote:
> Hi Chris,
>
> Thank you for the patch.
>
> On Saturday 21 Jan 2017 10:58:25 Chris Wilson wrote:
> > Some state is coupled into the device lifetime outside of the
> > load/unload timeframe and req
For the convenience of encapsulation the reservation object's ww_mutex
was wrapped in pair of lock/unlock helpers.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
---
drivers/gpu/drm/vgem/vgem_fence.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/g
On Thu, Jan 19, 2017 at 03:17:36PM +0100, Maarten Lankhorst wrote:
> Op 19-01-17 om 10:05 schreef Chris Wilson:
> > After warning that the connector list is not empty on device
> > unregistration (i.e. module unload) also print out which connectors are
> > still hanging a
u. The WARN fires on a
succesful read on the final loop, instead of the complete failure.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
() and kfree(dev) as before.)
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.c>
---
drivers/gpu/drm/drm_drv.c | 56 +--
include/drm/
() and kfree(dev) as before.)
v3: Remember to add drm_dev_fini() to drm_drv.h
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
---
drivers/gpu/
for
‘drm_clflush_sg’ [-Wmissing-prototypes]
drivers/gpu/drm/drm_cache.c:152:1: warning: no previous prototype for
‘drm_clflush_virt_range’ [-Wmissing-prototypes]
Fixes: f9a87bd7d5b6 ("drm: Move drm_clflush prototypes to drm_cache header
file")
Signed-off-by: Chris Wilson &l
On Mon, Jan 23, 2017 at 11:12:31AM +0100, Daniel Vetter wrote:
> On Mon, Jan 23, 2017 at 10:06:07AM +0000, Chris Wilson wrote:
> > On Thu, Jan 19, 2017 at 03:17:36PM +0100, Maarten Lankhorst wrote:
> > > Op 19-01-17 om 10:05 schreef Chris Wilson:
> > > > After w
drm_dev_fini() and kfree(dev) as before.)
v3: Remember to add drm_dev_fini() to drm_drv.h
v4: Tidy language for kerneldoc
v5: Cross reference from drm_dev_init() to note that driver->release()
allows for arbitrary embedding.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Laurent
Currently this tracepoint is solely used by dma_fence_enable_sw_signaling,
however I have a need to manually perform the hw enabling of the
signaling and would like to emit this tracepoint for completeness.
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Sumit Semwal <
98a7 ("drm/i915: add tracepoints for flip requests &
> completions")
> Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com>
That's old, and indeed does seem to be present from that commit and not
exposed by something later.
Cc: <sta...@vger.kernel.org>
501 - 600 of 3670 matches
Mail list logo
