ere are no
direct users of the the addmap interface, so just whatever comes in
through an ioctl.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Wed, Apr 27, 2016 at 09:06:09AM +0200, Daniel Vetter wrote:
> On Tue, Apr 26, 2016 at 05:45:44PM -0400, Alex Deucher wrote:
> > On Tue, Apr 26, 2016 at 4:52 PM, Chris Wilson
> > wrote:
> > > On Tue, Apr 26, 2016 at 07:29:41PM +0200, Daniel Vetter wrote:
> > >
On Wed, Apr 27, 2016 at 10:01:16AM +0200, Daniel Vetter wrote:
> On Wed, Apr 27, 2016 at 08:17:08AM +0100, Chris Wilson wrote:
> > drm/i915: s/struct_mutex/bfg9000/
>
> Can't do that yet because holding struct_mutex prevents objects from
> disappearing, speficially all ou
v3: Review from Lucas:
> - drop != NULL in pointer checks.
> - fixup copypasted kerneldoc to actually match the functions.
>
> Cc: Chris Wilson
> Cc: Alex Deucher
> Cc: Lucas Stach
> Reviewed-by: Lucas Stach
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm
On Wed, Apr 27, 2016 at 02:12:46PM +0200, Daniel Vetter wrote:
> On Wed, Apr 27, 2016 at 12:58:51PM +0100, Chris Wilson wrote:
> > On Wed, Apr 27, 2016 at 01:50:00PM +0200, Daniel Vetter wrote:
> > > Finally all the core gem and a lot of drivers are entirely free of
>
_ENABLED, &sync_file->fence->flags)) {
if (fence_add_callback(sync_file->fence, &sync_file->cb,
fence_check_cb_func) < 0)
wake_up_all(&sync_file->wq);
}
Saves adding a raw atomic.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
and faster insertion.
Signed-off-by: Chris Wilson
Cc: David Herrmann
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_mm.c | 133 +++
include/drm/drm_mm.h | 12 +
2 files changed, 122 insertions(+), 23 deletions(-)
diff --git a
Having added an interval-tree to struct drm_mm, we can replace the
auxiliary rb-tree inside the drm_vma_manager with it.
Signed-off-by: Chris Wilson
Cc: David Herrmann
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_vma_manager.c | 43
As we always add this to the drm_mm->hole_stack as our first operation,
we do not need to initialise the list node.
Signed-off-by: Chris Wilson
Cc: David Herrmann
Cc: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_mm.c | 6 +-
1 file changed, 1 insertion(+), 5 deleti
to prevent later bugs.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mm.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index cb39f45d6a16..e8c15795386d 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
is
> exclusively used as tag.
>
> Replace its usage with a simple "void *tag" and make sure callers can use
> arbitrary tags.
>
> Signed-off-by: David Herrmann
> ---
> struct drm_vma_offset_file {
Now a misnomer.
Lgtm,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
priv->authenticated ? 'y' : 'n',
> -from_kuid_munged(seq_user_ns(m), priv->uid),
> +from_kuid_munged(seq_user_ns(m), uid),
from_kuid_munged(seq_user_ns(m), task_euid(task)),
Just fits.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
PIDTYPE_PID);
> - uid = priv->filp ? priv->filp->f_cred->euid : GLOBAL_ROOT_UID;
> + uid = task ? __task_cred(task)->euid : GLOBAL_ROOT_UID;
Squash this into patch 2, so the poor reader doesn't have to learn about
f_cred.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
client->uid = from_kuid_munged(current_user_ns(),
> -file_priv->uid);
> +file_priv->filp ?
> + file_priv->filp->f_cred->euid :
> +GLOBAL_ROOT_UID);
Why can't we use task_euid(pid_task(file_priv->pid)) here as well?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
> Signed-off-by: David Herrmann
Ok, the danger of untyped is having to check each and trying to spot any
missed conversions.
Couldn't find a mistake or omission,
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
gt; supported\n");
> + DRM_ERROR("TPS3 not supported, using TPS2
> instead\n");
> *DP |= DP_LINK_TRAIN_PAT_2;
Given that you have a fallback plan and if the fallback plan fails you
alert the user with an error already, these aren't errors but debug.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
nk_status,
> - DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
Or just wrap it here since you add the same code everywhere, and don't
care what the invalid length actually is.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_status & DP_LANE_CR_DONE) == 0)
> + if ((lane_status & DP_LANE_CR_DONE) == 0) {
> + DRM_DEBUG_KMS("Clock recovery not done for lane %d\n",
> lane);
Please petition, with patch, for DRM_DEBUG_DP.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
t; Reviewed-by: David Herrmann
>
> Also, how about this:
config DRM_LEGACY
bool "Enable legacy drivers (DANGEROUS)"
depends on DRM
depends on BROKEN
help
...
Then everyone else gets depends on DRM_LEGACY. The benefit is that we
get the chance to add a useful help message and hopefully explains the
situation more cleary to devs.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
d-off-by: David Herrmann
Very neatly done.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
> move them out of sight (e.g., moving all DRI1 drivers to
> drivers/gpu/dri1/).
>
> Signed-off-by: David Herrmann
Acked-by: Chris Wilson
I'd rather have a couple of distro devs check if they are still using
any of these, and would value their a-b/r-b.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
nly time we delete from this list
(currently) is in cleanup. That's highly unlikely to be running at the
same time as the register, so
Acked-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Thu, Aug 04, 2016 at 06:18:53PM -0300, Gustavo Padovan wrote:
> 2016-08-03 Chris Wilson :
>
> > On Tue, Jul 12, 2016 at 03:08:45PM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan
> > >
> > > Signalling doesn't need to be enabled at sync
On Thu, Aug 04, 2016 at 11:50:27AM +0200, Daniel Vetter wrote:
> On Thu, Aug 04, 2016 at 12:02:23PM +0300, Jani Nikula wrote:
> > On Tue, 12 Jul 2016, Daniel Vetter wrote:
> > > On Thu, Jun 30, 2016 at 12:30:56PM +0100, Chris Wilson wrote:
> > >> Backlights
unction return a struct fence pointer referencing the fence(s) in the
> Sync
> +File.
+ The returned reference is owned by the caller and must be disposed of
afterwards using fence_put(). In case of error, a NULL is returned
instead.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
llback()
>
> v4: use user bit from fence flags (comment from Chris Wilson)
>
> Signed-off-by: Gustavo Padovan
> ---
> + if (!test_and_set_bit(POLL_ENABLED, &sync_file->fence->flags)) {
> + if (fence_add_callback(sync_file->fence,
On Fri, Aug 05, 2016 at 08:28:15AM +0100, Chris Wilson wrote:
> On Thu, Aug 04, 2016 at 11:24:14PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Signalling doesn't need to be enabled at sync_file creation, it is only
> > required if userspace wai
like:
> - connector_status (as tracked by probe helpers)
> - anything in the edid changes (when setting it
> drm_mode_connector_update_edid_property)
> - other changes (like sink state changes in dpcd or whatever)
>
> That way userspace would be able to reliably spot such changes and do a
> new modeset.
Yes, please. I have had similar wishes for state changes and overall
modeset counters.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_helper]
> [1.356038] [] ? drm_modeset_unlock_all+0x66/0xc0 [drm]
> [1.356038] [] cirrus_fbdev_init+0xa0/0xb0 [cirrus]
> [1.356038] [] cirrus_modeset_init+0x18b/0x1e0 [cirrus]
> [1.356038] [] cirrus_driver_load+0xbc/0x100 [cirrus]
> [1.356038] [] drm_dev_register+0xa9/0xd0 [drm]
m/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -93,6 +93,6 @@ extern bool i915_gpu_turbo_disable(void);
> #defineI845_TSEG_SIZE_1M (3 << 1)
>
> #define INTEL_BSM 0x5c
> -#define INTEL_BSM_MASK (0x << 20)
> +#define INTEL_BSM_MASK (-(1u << 20))
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
check and potentially blocking wait.
Signed-off-by: Chris Wilson
Cc: Alex Deucher
Cc: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu
check and potentially blocking wait.
Signed-off-by: Chris Wilson
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b
check and potentially blocking wait.
Signed-off-by: Chris Wilson
Cc: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index
check and potentially blocking wait.
Signed-off-by: Chris Wilson
Cc: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 6cd4af443139
check and potentially blocking wait.
Signed-off-by: Chris Wilson
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx
ssful fence_get_rcu() that ensure that as
long as the seqlock is stable we hold the right references to the
fences.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Christian König
Cc: Alex Deucher
Cc: Sumit Semwal
---
drivers/dma-buf/reservation.c
then searching for the relevant pin later.
v2: Joonas' stylistic nitpicks.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 60 ++--
drivers/gpu/drm/i915/i915_gem.c| 225 +++-
where we are discarding the full VMA offset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 6 +++---
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/i915_gem.c| 6 +++---
drivers/gpu/drm/i915/i915_gem_context.c| 6
section does not prevent this reallocation, instead
we have to inspect the reservation's seqlock to double check if the
fences have been reassigned as we were acquiring our reference.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Christian König
Cc: Alex Deuche
section does not prevent this reallocation, instead
we have to inspect the reservation's seqlock to double check if the
fences have been reassigned as we were acquiring our reference.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Christian König
Cc: Alex Deuche
Apologies, please ignore these 2. Didn't pass the right start point to
git-send-email.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Thu, Aug 11, 2016 at 11:19:50PM +0530, Sumit Semwal wrote:
> Hi Chris,
>
> On 11 August 2016 at 20:16, Chris Wilson wrote:
> > Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
> > timeout of 0 becomes reservation_object_test_signaled_rcu(), we do n
: Chris Wilson
Cc: Daniel Vetter
Cc: Sumit Semwal
---
include/linux/fence.h | 51 ++-
1 file changed, 46 insertions(+), 5 deletions(-)
diff --git a/include/linux/fence.h b/include/linux/fence.h
index 5f50ab273c38..e93f7e70d0fe 100644
--- a/include
that our log
messages would have better conformity, especially between our messages
and those printed by subsystems on our behalf (using our struct device).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
;
> Signed-off-by: Sean Paul
> ---
>
> Changes in v2:
> - Use dev_printk for the dev variant (Chris Wilson)
>
>
> drivers/gpu/drm/drm_drv.c | 31 +--
> include/drm/drmP.h| 133
> --
>
On Fri, Aug 12, 2016 at 09:26:32PM +0200, Lukas Wunner wrote:
> On Fri, Aug 12, 2016 at 07:39:38PM +0100, Chris Wilson wrote:
> > On Fri, Aug 12, 2016 at 01:30:00PM -0400, Sean Paul wrote:
> > > This patch consolidates all the various log functions/macros into
> > > one
e devices of the same type.
>
> Signed-off-by: Sean Paul
> ---
>
> Changes in v2:
> - Use dev_printk for the dev variant (Chris Wilson)
>
> Changes in v3:
> - Rename drm_log to drm_dev_printk (Chris Wilson)
> - Break out drm_printk from drm_dev_p
loff_t *ppos)
> +{
> + struct i915_perf_read_state state = { count, 0, buf };
> + int ret = stream->ops->read(stream, &state);
> +
> + /* If we've successfully copied any data then reporting that
> + * takes precedence over any internal error status, so the
> + * data isn't lost
> + */
> + return state.read ? state.read : (ret ? ret : -EAGAIN);
return state.read ?: ret ?: -EAGAIN;
Alternatively you could follow the standard pattern for read. Dare I ask
what is going to go into state that needs the obfuscation?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
invalid.
>
> The distinction makes the difference between allowing the buffer to be
> executed as an unprivileged batch buffer or returning an EINVAL error to
> userspace without executing anything.
Ah, but you choose to actually execute it instead. We can't allow that
either.
-C
igt/prime_vgem
Testcase: igt/gem_concurrent_blit # *vgem*
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: Eric Anholt
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
Cc: linux-kernel at vger.kernel.org
---
driv
tune them appropriately to benefit
everyone.
Signed-off-by: Chris Wilson
Cc: fritsch at kodi.tv
Cc: Deepak S
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_pm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/in
Apolgies, I changed trees between resending after the first git-send-email
bounced off the wrong address.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
igt/prime_vgem
Testcase: igt/gem_concurrent_blit # *vgem*
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: Eric Anholt
Cc: linux-media at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
Cc: linaro-mm-sig at lists.linaro.org
Cc: linux-kernel at vger.kernel.org
---
driv
->ggtt_alignment,
> + 0);
> + if (ret)
> + return ret;
> +
> + i915_oa_legacy_context_pin_notify(dev_priv, ctx);
> +
> + return 0;
> +}
I am still not all at all happy with this. I hope the recent changes to
do the vma tracking make it clear.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Aug 16, 2016 at 03:59:24PM +0100, Robert Bragg wrote:
>On Mon, Aug 15, 2016 at 3:57 PM, Chris Wilson
> Alternatively you could follow the standard pattern for read. Dare I ask
> what is going to go into state that needs the obfuscation?
>
>I had dug arou
The drivers have to modify the atomic plane state during the prepare_fb
callback so they track allocations, reservations and dependencies for
this atomic operation involving this fb. In particular, how else do we
set the plane->fence from the framebuffer!
Signed-off-by: Chris Wilson
Cc: Dan
Now that we subclass our request from struct fence, we start using the
common primitives more freely and so avoid hand-rolling routines already
provided for by the helpers.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 3 --
drivers/gpu/drm/i915/intel_display.c
Since dev_printk likes to print "(NULL device *):" when passed in a NULL
pointer, we have to manually call printk() ourselves.
Fixes: c4e68a583202 ("drm: Introduce DRM_DEV_* log messages")
Signed-off-by: Chris Wilson
Cc: Eric Engestrom
Cc: Sean Paul
---
drivers/g
ed to userspace.
> + */
> + mutex_lock(&dev_priv->perf.lock);
> +
> + dev_priv->perf.metrics_kobj =
> + kobject_create_and_add("metrics",
> + &dev_priv->drm.primary->kdev->kobj);
> + if (!dev_priv->perf.metrics_kobj)
> + goto exit;
> +
> + if (i915_perf_init_sysfs_hsw(dev_priv)) {
If you say hsw only, I expect to see a local check or comment saying we
are on Haswell.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
>
> Reported-by: Alexander Potapenko
> Cc: Alexander Potapenko
> Cc: stable at vger.kernel.org
> Signed-off-by: Daniel Vetter
That explains the oops.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
filesystems) upon boot.
Fixes: 44adece57e26 ("drm/fb-helper: Add a dummy
remove_conflicting_framebuffers")
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Tobias Jakobi
Cc: Noralf Trønnes
Cc: tomi.valkeinen at ti.com
Cc: dh.herrmann at gmail.com
Cc: Alex Deucher
---
include/drm/drm_f
@ void intel_dvo_init(struct drm_device *dev)
return;
}
- drm_encoder_cleanup(&intel_encoder->base);
kfree(intel_dvo);
kfree(intel_connector);
}
--
Chris Wilson, Intel Open Source Technology Centre
[i915]] *ERROR* pipe A underrun
Other than the annoying underrun, is everything else as expected? i.e.
no connected outputs? Have we lost dvo detection?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
sequence of userspace calls from a process is
ordered from the pov of the client).
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu
On Tue, Aug 23, 2016 at 11:48:34AM +0100, Chris Wilson wrote:
> Legacy cursor updates are entirely asynchronous with respect to all
> other users of the atomic pipeline. They neither wait for any
> outstanding flips, nor do they cause subsequent flips to be delayed. The
> only or
On Tue, Aug 23, 2016 at 11:48:34AM +0100, Chris Wilson wrote:
> Legacy cursor updates are entirely asynchronous with respect to all
> other users of the atomic pipeline. They neither wait for any
> outstanding flips, nor do they cause subsequent flips to be delayed. The
> only or
Quoting Daniel Vetter (2019-05-02 08:27:27)
> +static int drm_legacy_setup(struct drm_device * dev)
> +{
> + int ret;
> +
> + if (dev->driver->firstopen &&
> + drm_core_check_feature(dev, DRIVER_LEGACY)) {
> + ret = dev->driver->firstopen(dev);
> +
rm_legacy_dev_reinit is there already too,
> plus it fits perfectly into Dave's work of making DRIVER_LEGACY code
> compile-time optional.
>
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
-Chris
Move the duplicated code within dma-fence.c into the header for wider
reuse. In the process apply a small micro-optimisation to only prune the
fence->cb_list once rather than use list_del on every entry.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/dma-buf/Makef
In order to fix a bug in i915, I would like to opencode the dma fence
signal processing (to close a race condition with preemption and signal
enabling). Tvrtko quite rightly objected to the opencoding and suggested
that dma-fence should provide the helpers, so here's my suggestion wrt
the interface
"drm/i915: Replace global breadcrumbs with per-context
interrupt tracking")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/dma-buf/dma-fence.c | 1 +
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 78 +++--
d
Quoting Chris Wilson (2019-05-08 13:05:42)
> Move the duplicated code within dma-fence.c into the header for wider
> reuse. In the process apply a small micro-optimisation to only prune the
> fence->cb_list once rather than use list_del on every entry.
>
> Signed-off-by: Chris
Quoting Daniel Vetter (2019-05-08 13:53:30)
> On Wed, May 8, 2019 at 2:06 PM Chris Wilson wrote:
> >
> > Currently there is an underlying assumption that i915_request_unsubmit()
> > is synchronous wrt the GPU -- that is the request is no longer in flight
> > as we re
Quoting Michael Yang (2019-05-09 05:34:11)
> If all the sync points were signaled in both fences a and b,
> there was only one sync point in merged fence which is a_fence[0].
> The Fence structure in android framework might be confused about
> timestamp if there were any sync points which were sign
ve commit message to address review
> questions.
>
> Signed-off-by: Daniel Vetter
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Will Deacon
> Cc: Petr Mladek
> Cc: Sergey Senozhatsky
> Cc: Steven Rostedt
> Cc: Daniel Vetter
> Cc: John Ogness
> Cc: Chris
Quoting Daniel Vetter (2019-05-13 15:39:21)
> On Mon, May 13, 2019 at 03:32:44PM +0100, Steven Price wrote:
> > panfrost_ioctl_mmap_bo() contains a reimplementation of
> > drm_gem_dump_map_offset() but with a bug - it allows mapping imported
> > objects (without going through the exporter). Fix thi
Quoting Steven Price (2019-05-13 16:14:01)
> On 13/05/2019 15:47, Chris Wilson wrote:
> > Quoting Daniel Vetter (2019-05-13 15:39:21)
> >> On Mon, May 13, 2019 at 03:32:44PM +0100, Steven Price wrote:
> >>> panfrost_ioctl_mmap_bo() contains a reimplementation of
>
Quoting Michael Yang (2019-05-14 08:55:37)
> On Thu, May 09, 2019 at 12:46:05PM +0100, Chris Wilson wrote:
> > Quoting Michael Yang (2019-05-09 05:34:11)
> > > If all the sync points were signaled in both fences a and b,
> > > there was only one sync point in merg
Quoting Masahiro Yamada (2019-05-15 05:37:53)
> The top level Makefile adds -Wall globally:
>
> KBUILD_CFLAGS := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs \
>
> I see two "-Wall" added for compiling under drivers/gpu/drm/i915/.
Does it matter? Is the statement in i915/Makefile n
Quoting Janusz Krzysztofik (2019-05-17 15:06:17)
> From: Janusz Krzysztofik
>
> During i915_driver_unload(), GEM contexts are verified restrictively
> inside i915_gem_fini() if they don't consume shared resources which
> should be cleaned up before the driver is released. If those checks
> don't
the history to trawl through.
References: 5584f1b1d73e ("drm/i915: fix i915 running as dom0 under Xen")
> Signed-off-by: Dongli Zhang
Reviewed-by: Chris Wilson
-Chris
Quoting Rob Herring (2019-05-21 16:24:27)
> On Mon, May 20, 2019 at 4:23 AM Steven Price wrote:
> >
>
> You forgot to update the subject. I can fixup when applying, but I'd
> like an ack from Chris on patch 1.
I still think it is incorrect as the limitation is purely an issue with
the shmem back
Quoting Michal Hocko (2019-05-22 07:34:42)
> On Wed 22-05-19 06:06:31, Tetsuo Handa wrote:
> [...]
> > Since OOM notifier will be called after shrinkers are attempted,
> > can i915 move from OOM notifier to shrinker?
>
> That would be indeed preferable. OOM notifier is an API from hell.
We were^W
Quoting Dongli Zhang (2019-05-21 05:40:39)
> This patch removes IO_TLB_SEGPAGES which is no longer used since
> commit 5584f1b1d73e ("drm/i915: fix i915 running as dom0 under Xen").
>
> As the define of both IO_TLB_SEGSIZE and IO_TLB_SHIFT are from swiotlb,
> IO_TLB_SEGPAGES should be defined on s
> Addresses-Coverity: ("Uninitialized scalar variable")
> Fixes: d3622099c76f ("drm/i915/gtt: Always acquire struct_mutex for
> gen6_ppgtt_cleanup")
> Signed-off-by: Colin Ian King
Saw that last night but got distracted by the panic-on-boot...
Reviewed-by: Chris Wilson
-Chris
Quoting Dan Carpenter (2019-05-29 12:03:55)
> We should check "request[n]" instead of just "request".
>
> Fixes: 78e41ddd2198 ("drm/i915: Apply an execution_mask to the
> virtual_engine")
> Signed-off-by: Dan Carpe
Quoting Chris Wilson (2019-05-29 12:06:57)
> Quoting Dan Carpenter (2019-05-29 12:03:55)
> > We should check "request[n]" instead of just "request".
> >
> > Fixes: 78e41ddd2198 ("drm/i915: Apply an execution_mask to the
> > virtual_engine"
Quoting Janusz Krzysztofik (2019-04-05 08:26:57)
> From: Janusz Krzysztofik
>
> The driver does not currently support unbinding from a device which is
> in use. Since open file descriptors may still be pointing into kernel
> memory where the device structures used to be, entirely correct kernel
Quoting Janusz Krzysztofik (2019-04-05 09:11:54)
> On Fri, 2019-04-05 at 08:41 +0100, Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2019-04-05 08:26:57)
> > > From: Janusz Krzysztofik
> > >
> > > The driver does not currently support unbinding from
Quoting Janusz Krzysztofik (2019-04-05 13:13:31)
> From: Janusz Krzysztofik
>
> If there are active users of a device during driver unbind, the driver
> now panics on non-empty list of free cachelines.
This panic is there to say that fini is being called with active
contexts, that it is being ca
Quoting Chris Wilson (2019-03-25 08:07:33)
> When one of the array of fences is signaled, propagate its errors to the
> parent fence-array (keeping the first error to be raised).
>
> v2: Opencode cmpxchg_local to avoid compiler freakout.
>
> Signed-off-by: Chris Wilson
> C
Quoting Gwan-gyeong Mun (2019-04-12 15:06:17)
> After suspend/resume process, hotplug detection is handled by
> i915_hpd_poll_init_work() workqueue. While intel_hdmi_detect() or
> intel_dp_detect() are called, intel_hdmi_set_edid() or intel_dp_set_edid()
> only update an internal detect_edid variab
viewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Quoting Thomas Zimmermann (2019-04-18 08:29:39)
> Hi
>
> Am 18.04.19 um 00:16 schrieb Kuehling, Felix:
> > Adding dri-devel
> >
> > On 2019-04-17 6:15 p.m., Yang, Philip wrote:
> >> After patch "drm: Use the same mmap-range offset and size for GEM and
> >> TTM", application failed to create bo of
_dump198 --198
sync_dump_buf 65536 - -65536
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Gustavo Padovan
---
drivers/dma-buf/sync_debug.c | 26 --
drivers/dma-buf/sync_debug.h | 1 -
2 files change
Quoting Daniel Vetter (2019-04-23 09:21:16)
> On Fri, Apr 19, 2019 at 07:19:04PM +0100, Chris Wilson wrote:
> > sync_dump() is an unused, unexported, function that adds 64k to the
> > kernel image and doesn't even provide locking around the global array it
> > uses.
>
Quoting Jian-Hong Pan (2019-04-23 10:28:10)
> From: Daniel Drake
>
> On many (all?) the Gemini Lake systems we work with, there is frequent
> momentary graphical corruption at the top of the screen, and it seems
> that disabling framebuffer compression can avoid this.
>
> The ticket was reported
ique dma_fence_ops, and
preferring to have descriptors for the whole fence context). strings do
not pack as well into the ftrace ringbuffer and we would prefer to
reduce the amount of indirect callbacks required for frequent tracepoint
emission.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: T
Quoting Koenig, Christian (2019-01-22 08:49:30)
> Am 22.01.19 um 00:20 schrieb Chris Wilson:
> > Rather than every backend and GPU driver reinventing the same wheel for
> > user level debugging of HW execution, the common dma-fence framework
> > should include the tracing in
Quoting Daniel Vetter (2019-01-22 09:11:53)
> On Tue, Jan 22, 2019 at 10:06 AM Chris Wilson
> wrote:
> >
> > Quoting Koenig, Christian (2019-01-22 08:49:30)
> > > Am 22.01.19 um 00:20 schrieb Chris Wilson:
> > > > Rather than every backend and GP
101 - 200 of 3785 matches
Mail list logo
