On Thu, Dec 10, 2020 at 5:12 PM Jani Nikula wrote:
>
> On Thu, 10 Dec 2020, Ville Syrjälä wrote:
> > On Thu, Dec 10, 2020 at 02:17:50PM +1000, Dave Airlie wrote:
> >> From: Dave Airlie
> >>
> >> This file is a monster, let's start simple, the cursor plane code
> >> seems pretty standalone, and s
uses
the intel_dpll_mgr.c stuff. Probably more splitting to do eventually,
but just intel_dpll.c sounds reasonable for now.
-Daniel
>
> --
> Ville Syrjälä
> Intel
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Also try to clarify a bit when dma_buf_begin/end_cpu_access should
be called.
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-
Noticed while reviewing the output. Adds a bunch more links and fixes
the function interface quoting.
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf
At least amdgpu and i915 do, so lets just document this as the rule.
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-buf.c | 4
1 file
Motivated by a discussion with Christian and Thomas: Try to untangle a
bit what's relevant for importers and what's relevant for exporters.
Also add an assert that really only dynamic importers use the api
function, anything else doesn't make sense.
Signed-off-by: Daniel Vet
On Fri, Oct 23, 2020 at 04:56:20PM +0200, Daniel Vetter wrote:
> On Fri, Oct 23, 2020 at 4:54 PM Christian König
> wrote:
> >
> > Am 23.10.20 um 14:21 schrieb Daniel Vetter:
> > > ttm_resource_manager->use_type is only used for runtime changes by
> > >
lips. (Plane's damage clip might exist outside
> of fb src geometry.)
Since this is causing confusion, please make sure that the igt for damage
clips validates this correctly. I think some of the igts that vmwgfx
people have created have still not yet landed, so we definitely want to
land thes
On Mon, Dec 14, 2020 at 11:33:10AM +0100, Christian König wrote:
> Am 11.12.20 um 16:58 schrieb Daniel Vetter:
> > Also try to clarify a bit when dma_buf_begin/end_cpu_access should
> > be called.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Thomas Zimmerm
At least amdgpu and i915 do, so lets just document this as the rule.
v2: Works better with less typos (intel-gfx-ci)
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
d
f fixes pull (less than what git shortlog provides):
>
> * dma-buf: Fix docs
> * mxsfb: Silence invalid error message
> * radeon: Fix TTM multihop
>
> --------
> Christian König (1):
> drm/radeon: fix check or
On Wed, Dec 16, 2020 at 2:29 AM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> Thank you for the patch.
>
> On Fri, Oct 23, 2020 at 02:21:25PM +0200, Daniel Vetter wrote:
> > Ends right after drm_atomic_helper_commit_hw_done(), absolutely
> > nothing fancy going on here.
On Tue, Dec 15, 2020 at 03:18:49PM +0100, Christian König wrote:
> Am 14.12.20 um 17:01 schrieb Daniel Vetter:
> > On Mon, Dec 14, 2020 at 11:33:10AM +0100, Christian König wrote:
> > > Am 11.12.20 um 16:58 schrieb Daniel Vetter:
> > > > Also try to clarify a bit whe
gem_execbuffer.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h| 12 ++--
> drivers/gpu/drm/i915/i915_irq.c| 27
> ++
> drivers/gpu/drm/i915/i915_perf.c | 2 +-
> 4 files changed, 23 ins
i915_gem_execbuffer.c | 4 +++-
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 +
> drivers/gpu/drm/i915/i915_cmd_parser.c | 27
> --
> drivers/gpu/drm/i915/i915_drv.c| 5
> drivers/gpu/drm/i915/i915_drv
RU handling further
>
> Chuhong Yuan (1):
> drm/fb-helper: Add missed unlocks in setcmap_legacy()
>
> Dafna Hirschfeld (2):
> drm/rockchip: for error print, use the correct device pointer
> drm/rockchip: fix typo in Kconfig 's/HDMI/dsi/'
>
> Dan Carpenter (
| 103
> drivers/gpu/drm/i915/display/intel_ddi.c | 6 +-
> drivers/gpu/drm/i915/display/intel_display_types.h | 10 +
> drivers/gpu/drm/i915/display/intel_dp.c| 440 +++-
> drivers/gpu/drm/i915/display/intel_dp.h| 7 +-
rs/gpu/drm/i915/i915_suspend.c| 33 +-
> drivers/gpu/drm/i915/intel_device_info.c |2 +-
> drivers/gpu/drm/i915/intel_pm.c| 552 +++---
> drivers/gpu/drm/i915/intel_sideband.c |4 +-
> drivers/gpu/drm/i915/intel_uncore.c|4 +-
> drivers/gpu/drm/i915/intel_uncore.h|6 +-
> include/drm/drm_dsc.h |1 +
> 49 files changed, 3222 insertions(+), 3075 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/i9xx_plane.c
> create mode 100644 drivers/gpu/drm/i915/display/i9xx_plane.h
> create mode 100644 drivers/gpu/drm/i915/display/intel_cursor.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_cursor.h
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
drm/ttm: cleanup LRU handling further
>
> Chuhong Yuan (1):
> drm/fb-helper: Add missed unlocks in setcmap_legacy()
>
> Dafna Hirschfeld (2):
> drm/rockchip: for error print, use the correct device pointer
> drm/rockchip: fix typo in Kconfig 's/
> > > 'dev'?
> > > > 1316 | &dev_priv->dev->pdev->dev,
> > > > | ^~~~
> > > > | dev
> > > > drivers/gpu/drm/vmwgfx/
a-buf/dma-buf.c | 21 +
> drivers/gpu/drm/radeon/radeon_ttm.c | 3 ---
> drivers/gpu/drm/ttm/ttm_pool.c | 2 --
> 3 files changed, 17 insertions(+), 9 deletions(-)
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Sol
>
> > > > I checked other drivers and it doesn't look like they end up triggering
> > > > this case so I think this is safe to relax.
> > > >
> > > > Signed-off-by: Bas Nieuwenhuizen
> > > > Reviewed-by: Daniel Vetter
at has a long-term mapping intention behind it. And at that
point it's probably equally amounts of work to just go back to ad-hoc
kmap. Also the rules have changed somewhat with kmap_local anyway, a kmap
is a lot less painful in the code than it was with kmap_atomic.
-Daniel
--
Daniel
Now that my little helper has landed, use it more. On top of the
existing check this also uses lockdep through the fs_reclaim
annotations.
Signed-off-by: Daniel Vetter
Cc: Andrew Morton
Cc: linux...@kvack.org
--
v2: git add everything ... :-/
---
mm/dmapool.c | 3 ++-
1 file changed, 2
Now that my little helper has landed, use it more. On top of the
existing check this also uses lockdep through the fs_reclaim
annotations.
Signed-off-by: Daniel Vetter
Cc: Andrew Morton
Cc: linux...@kvack.org
--
v2: git add everything ... oops
---
mm/backing-dev.c | 2 +-
1 file changed, 1
irly low
in the kernel mapping, so flipping all the bits gives us a very high
pointer in userspace and hence excellent chances for an invalid
dereference.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: David Stevens
Cc: linux-me...@vger.kernel.org
Cc: linar
On Thu, May 20, 2021 at 4:28 PM Daniel Vetter wrote:
>
> On Thu, May 20, 2021 at 08:35:14AM +0100, Matthew Auld wrote:
> > From: Chris Wilson
> >
> > The first tracepoint for a request is trace_dma_fence_init called before
> > we have associated the request with
gether
> > c968d4d87cf4 drm/i915: Extract the ability to defer and rerun a request
> > later
> > 746cafc44205 drm/i915: Extract request suspension from the execlists
> > 3d473f1476d8 drm/i915: Extract request rewinding from execlists
> > d353a704a6db drm/i915: Extract
1 +80,17 @@ void mock_init_contexts(struct drm_i915_private *i915)
> struct i915_gem_context *
> live_context(struct drm_i915_private *i915, struct file *file)
> {
> + struct i915_gem_proto_context *pc;
> struct i915_gem_context *ctx;
> int err;
> u32 id;
>
>
;
> mutex_init(&ctx->engines_mutex);
> - e = default_engines(ctx);
> + e = default_engines(ctx, null_sseu);
> if (IS_ERR(e))
> goto err_free;
> RCU_INIT_POINTER(ctx->engines, e);
> @@ -112,6 +113,7 @@ live_context_for_engine(st
e have think about those interactions.
>
> v2 (Daniel Vetter):
> - Add a proto_context_free_user_engines helper
> - Comment on SSEU in the commit message
> - Use proto_context_set_persistence in set_proto_ctx_param
>
> Signed-off-by: Jason Ekstrand
&g
44
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -201,6 +201,16 @@ struct drm_i915_file_private {
> struct rcu_head rcu;
> };
>
> + /** @proto_context_lock: Guards all i915_gem_proto_context operations
> + *
> + * See i915_gem_proto_context.
Please add locking rules here, like "This is always held whenever we
manipulate any proto context, including finalizing it on first actual use
of the GEM context".
> + */
> + struct mutex proto_context_lock;
> +
> + /** @proto_context_xa: xarray of i915_gem_proto_context */
Pls fix hyperlinks.
Also please put your nice explainer from the commit message here ...
> + struct xarray proto_context_xa;
> +
> + /** @context_xa: xarray of fully created i915_gem_context */
... and reference it with a "See @proto_context_xa" here.
Maybe also reference i915_gem_context_lookup() from these so readers of
the code can easily find all the pieces of this magic.
Also mention here that write access to @context_xa is protected by
@proto_context_lock. It must be held to avoid races with finalization of
proto context in e.g. i915_gem_context_destroy_ioctl(), and this wasn't
obvious to me at all.
> struct xarray context_xa;
> struct xarray vm_xa;
>
> @@ -1857,20 +1867,6 @@ struct drm_gem_object *i915_gem_prime_import(struct
> drm_device *dev,
>
> struct dma_buf *i915_gem_prime_export(struct drm_gem_object *gem_obj, int
> flags);
>
> -static inline struct i915_gem_context *
> -i915_gem_context_lookup(struct drm_i915_file_private *file_priv, u32 id)
> -{
> - struct i915_gem_context *ctx;
> -
> - rcu_read_lock();
> - ctx = xa_load(&file_priv->context_xa, id);
> - if (ctx && !kref_get_unless_zero(&ctx->ref))
> - ctx = NULL;
> - rcu_read_unlock();
> -
> - return ctx ? ctx : ERR_PTR(-ENOENT);
> -}
> -
> static inline struct i915_address_space *
> i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id)
> {
> --
> 2.31.1
Nothing big looks wrong, with the nits addressed:
Reviewed-by: Daniel Vetter
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
cks. Iirc drm_file disappearing at a bad time is a large reasons
for all these tricks we need for context/request/engine cleanup.
But yeah definitely needs a pile more analysis.
>
> v2 (Jason Ekstrand):
> - Expand the commit mesage
I already gave you an r-b assuming you type so
ell as a
> duplicated (and slightly different) copy of the code which programs the
> PPGTT registers.
>
> v2 (Jason Ekstrand):
> - Expand the commit message
>
> Signed-off-by: Jason Ekstrand
Already scored an Reviewed-by: Daniel Vetter
now that the commit message is th
engine sets and lets us get rid of the complex VM setting code.
>
> Signed-off-by: Jason Ekstrand
On the last three patches:
Reviewed-by: Daniel Vetter
Looking at the end result we still have the ctx->user_flags which are
muttable, and I think for again no reason at all. Especially fo
On Tue, Jun 1, 2021 at 9:19 AM Dave Airlie wrote:
> On Thu, 27 May 2021 at 20:04, Daniel Vetter wrote:
> > On Wed, May 26, 2021 at 10:35:49AM +1000, Dave Airlie wrote:
> > > On Wed, 12 May 2021 at 03:05, Daniel Vetter wrote:
> > > > On Tue, May 11, 2021 at 10:31:39
On Tue, Jun 1, 2021 at 1:13 PM Matthew Auld wrote:
> On 31/05/2021 08:53, Daniel Vetter wrote:
> > On Thu, May 20, 2021 at 4:28 PM Daniel Vetter wrote:
> >>
> >> On Thu, May 20, 2021 at 08:35:14AM +0100, Matthew Auld wrote:
> >>> From: Chris Wilson
> &g
On Tue, Jun 01, 2021 at 11:09:47AM +0100, Tvrtko Ursulin wrote:
>
> On 27/05/2021 11:27, Daniel Vetter wrote:
> > On Thu, May 27, 2021 at 11:22:16AM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 27/05/2021 11:13, Daniel Vetter wrote:
> > > > On Wed, May 26
On Thu, May 27, 2021 at 03:41:02PM +0200, Christian König wrote:
> Am 27.05.21 um 15:25 schrieb Daniel Vetter:
> > On Thu, May 27, 2021 at 1:59 PM Christian König
> > wrote:
> > > Am 27.05.21 um 12:39 schrieb Daniel Vetter:
> > > > On Wed, May 26, 2021 at 12:
07] do_user_addr_fault+0x1c5/0x660
> >
> > Reverting this commit is reported to fix the issue.
> >
> > Reported-by: Eero Tamminen
> > References: https://gitlab.freedesktop.org/drm/intel/-/issues/3519
> > Fixes: b739f125e4eb ("i915: use io_mapping_map_user&q
Adding Jani and Rodrigo since drm-intel-fixes is on them.
-Daniel
On Wed, Jun 2, 2021 at 12:10 PM Matthew Auld
wrote:
>
> On Wed, 2 Jun 2021 at 09:01, Daniel Vetter wrote:
> >
> > On Wed, Jun 2, 2021 at 9:28 AM Matthew Auld
> > wrote:
> > >
> > >
n both drm-misc-next and
drm-intel-gt-next in the merge commit. If it's not too bad (I haven't
looked at what exactly we need for the i915 side from ttm in detail).
But also often figuring out the topic branch logistics takes longer than
just merging to drm-misc-next as the patches get ready
On Wed, Jun 02, 2021 at 03:06:50PM +0100, Steven Price wrote:
> On 21/05/2021 10:09, Daniel Vetter wrote:
> > More consistency and prep work for the next patch.
> >
> > Aside: I wonder whether we shouldn't just move this entire xarray
> > business into the sched
've merged already.
Minimally this needs a comment here and in the struct next to
@pin_count to explain where all this is abused, which would already
make it better than most of the in-tree ones.
As part of the ttm conversion we have a plan to sunset the "pin_count
as a lock" stuff,
On Thu, Jun 3, 2021 at 5:48 AM Matthew Brost wrote:
>
> On Wed, Jun 02, 2021 at 08:57:02PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 2, 2021 at 5:27 PM Tvrtko Ursulin
> > wrote:
> > > On 25/05/2021 17:45, Matthew Brost wrote:
> > > > On Tue, May 25, 2
On Wed, Jun 2, 2021 at 11:53 PM Jason Ekstrand wrote:
>
> On Tue, May 4, 2021 at 11:13 AM Daniel Vetter wrote:
> >
> > On Mon, May 03, 2021 at 10:57:37AM -0500, Jason Ekstrand wrote:
> > > The current context uAPI allows for two methods of setting context
> > &g
On Wed, Jun 2, 2021 at 11:24 PM Jason Ekstrand wrote:
>
> On Mon, May 31, 2021 at 3:47 AM Daniel Vetter wrote:
> >
> > On Thu, May 27, 2021 at 11:26:37AM -0500, Jason Ekstrand wrote:
> > > The current context uAPI allows for two methods of setting context
> > &g
On Thu, Jun 3, 2021 at 12:55 AM Jason Ekstrand wrote:
>
> On Mon, May 31, 2021 at 4:50 AM Daniel Vetter wrote:
> >
> > On Thu, May 27, 2021 at 11:26:45AM -0500, Jason Ekstrand wrote:
> > > @@ -2692,16 +2792,41 @@ int i915_gem_context_setparam_ioctl(struct
> &
On Thu, Jun 3, 2021 at 12:23 AM Jason Ekstrand wrote:
>
> On Mon, May 31, 2021 at 4:12 AM Daniel Vetter wrote:
> >
> > On Thu, May 27, 2021 at 11:26:42AM -0500, Jason Ekstrand wrote:
> > > +static int set_proto_ctx_engines(struct d
On Thu, Jun 3, 2021 at 8:50 AM Thomas Hellström
wrote:
>
>
> On 6/2/21 8:40 PM, Daniel Vetter wrote:
> > On Wed, Jun 02, 2021 at 11:48:41AM +0200, Christian König wrote:
> >> Am 02.06.21 um 11:16 schrieb Thomas Hellström (Intel):
> >>> On 6/2/21 10:32 AM, C
d_vma(vw->vm, &vw->stash,
> vma, vw->cache_level, vw->flags);
> - return 0;
> }
>
> static void __vma_release(struct dma_fence_work *work)
> --
> 2.31.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
,
> + &needs_clflush_after);
> + if (IS_ERR(cmd)) {
> + DRM_DEBUG("CMD: Failed to copy batch\n");
> + return PTR_ERR(cmd);
> + }
> +
> + jump_whitelist = NULL;
> + if (!trampoline)
> + /* Defer failure until attempted use */
> + jump_whitelist = alloc_whitelist(batch_length);
>
> shadow_addr = gen8_canonical_addr(shadow->node.start);
> batch_addr = gen8_canonical_addr(batch->node.start + batch_offset);
> @@ -1549,6 +1560,9 @@ int intel_engine_cmd_parser(struct intel_engine_cs
> *engine,
>
> i915_gem_object_flush_map(shadow->obj);
>
> + if (!IS_ERR_OR_NULL(jump_whitelist))
> + kfree(jump_whitelist);
> + i915_gem_object_unpin_map(shadow->obj);
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 39b5e019c1a5b..92003970253e5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1913,17 +1913,12 @@ const char *i915_cache_level_str(struct
> drm_i915_private *i915, int type);
> int i915_cmd_parser_get_version(struct drm_i915_private *dev_priv);
> int intel_engine_init_cmd_parser(struct intel_engine_cs *engine);
> void intel_engine_cleanup_cmd_parser(struct intel_engine_cs *engine);
> -unsigned long *intel_engine_cmd_parser_alloc_jump_whitelist(u32 batch_length,
> - bool trampoline);
> -
> int intel_engine_cmd_parser(struct intel_engine_cs *engine,
> struct i915_vma *batch,
> unsigned long batch_offset,
> unsigned long batch_length,
> struct i915_vma *shadow,
> - unsigned long *jump_whitelist,
> - void *shadow_map,
> - const void *batch_map);
> + bool trampoline);
> #define I915_CMD_PARSER_TRAMPOLINE_SIZE 8
>
> /* intel_device_info.c */
> --
> 2.31.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
("drm/i915: Propagate errors on awaiting already signaled
> fences")
> Signed-off-by: Daniel Vetter
> Reviewed-by: Jon Bloomfield
> ---
> drivers/gpu/drm/i915/i915_request.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/dr
On Thu, Jun 03, 2021 at 10:24:21AM +0200, Daniel Vetter wrote:
> On Wed, Jun 02, 2021 at 11:41:48AM -0500, Jason Ekstrand wrote:
> > This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
> > since that commit, we've been having issues where a hang in one client
On Thu, Jun 03, 2021 at 10:25:00AM +0200, Daniel Vetter wrote:
> On Thu, Jun 03, 2021 at 10:24:21AM +0200, Daniel Vetter wrote:
> > On Wed, Jun 02, 2021 at 11:41:48AM -0500, Jason Ekstrand wrote:
> > > This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
>
ease if needed for
> Greg to back-port.
I think just the two reversts are enough to be backported, other 3 are
cleanups.
Also I guess this will need to come with an igt patch to adjust the
cmdparser test.
With all the nits addressed, on the series.
Acked-by: Daniel Vetter
>
> Cc: Dan
On Thu, Jun 3, 2021 at 5:30 AM Matthew Brost wrote:
>
> On Mon, May 31, 2021 at 10:31:53AM +0200, Daniel Vetter wrote:
> > On Thu, May 27, 2021 at 4:19 PM Matthew Brost
> > wrote:
> > >
> > > On Thu, May 27, 2021 at 10:41:10AM +0100, Tvrtko Ursulin wrote:
Hi all,
I finally figured out why CI is unhappy on some machines, we've lost WC
mode on the vgem side!
Test-with: 20210527140732.5762-1-daniel.vet...@ffwll.ch
Cheers, Daniel
Daniel Vetter (4):
drm/gem-shmem-helper: Export drm_gem_shmem_funcs
drm/shmem-helper: Switch to vmf_insert_pfn
We want to stop gup, which isn't the case if we use vmf_insert_page
and VM_MIXEDMAP, because that does not set pte_special.
v2: With this shmem gem helpers now definitely need CONFIG_MMU (0day)
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmerman
Drivers which need to overwrite the drm_driver->gem_create_object hook
need this. Specifically vgem, which wants wc mode, but everything else
is fine as-is.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vet
shmem helpers seem a bit sloppy here by automatically rounding up when
actually creating the buffer, which results in under-reporting of what
we actually have. Caught by igt/vgem_basic tests.
Acked-by: Thomas Zimmermann
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc
appings by default"), and we need WC in vgem because vgem doesn't
have explicit begin/end cpu access ioctls.
Also add a comment why exactly vgem has to use wc.
Cc: Thomas Zimmermann
Acked-by: Thomas Zimmermann
Cc: John Stultz
Cc: Sumit Semwal
Cc: "Christian König"
Sign
Hi all,
Another small iteration, lost another patch, so another full resend.
Thomas Zimmermann pointed out how to get at drm_gem_shmem_funcs without
getting at drm_gem_shmem_funcs directly.
Test-with: 20210527140732.5762-1-daniel.vet...@ffwll.ch
Cheers, Daniel
Daniel Vetter (4):
dma-buf
We want to stop gup, which isn't the case if we use vmf_insert_page
and VM_MIXEDMAP, because that does not set pte_special.
v2: With this shmem gem helpers now definitely need CONFIG_MMU (0day)
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmerman
.gmail.com/
Acked-by: Christian König
Cc: Jason Gunthorpe
Cc: Suren Baghdasaryan
Cc: Matthew Wilcox
Cc: John Stultz
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
--
Resending this so I can test
omas Zimmermann
Cc: John Stultz
Cc: Sumit Semwal
Cc: "Christian König"
Signed-off-by: Daniel Vetter
Cc: Melissa Wen
Cc: Chris Wilson
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/vgem/vgem_drv.c | 342 ++--
2 files changed, 14 insertions(+), 3
shmem helpers seem a bit sloppy here by automatically rounding up when
actually creating the buffer, which results in under-reporting of what
we actually have. Caught by igt/vgem_basic tests.
Acked-by: Thomas Zimmermann
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc
&obj->base;
>
> here you are allocating a bigger object than what you are
> returning, in size. How does it get freed?
We're using the drm_gem_shmem_helper.c helpers, which set up all the shmem
functions for us, including an appropriate free callback.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
pages are non-contig to
begin with.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/Kconfig| 2 +-
drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
drivers/gpu/drm/gud/Kc
ng
Cc: Thomas Zimmermann
Acked-by: Thomas Zimmermann
Cc: John Stultz
Cc: Sumit Semwal
Cc: "Christian König"
Signed-off-by: Daniel Vetter
Cc: Melissa Wen
Cc: Chris Wilson
---
drivers/gpu/drm/Kconfig | 5 +-
drivers/gpu/drm/vgem/vgem_drv.c | 342 ++-
id *b)
> -{
> - return a - b;
> -}
> -
> static inline long
> i915_vma_compare(struct i915_vma *vma,
>struct i915_address_space *vm,
> --
> 2.28.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
2 #ifdef CONFIG_DRM_I915_DEBUG_GUC
> 77b20896d57e91 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c Michal Wajdeczko
> 2020-01-17 33 #define CT_DEBUG(_ct, _fmt, ...) \
> a4c78275ba7e01 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c Daniele Ceraolo
> Spurio 2021-06-02 @34drm_dbg(ct_
On Thu, Jun 03, 2021 at 07:02:57PM -0700, Matthew Brost wrote:
> On Thu, Jun 03, 2021 at 11:35:28PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 02, 2021 at 10:16:18PM -0700, Matthew Brost wrote:
> > > From: Michal Wajdeczko
> > >
> > > Generic help
On Fri, Jun 4, 2021 at 5:25 AM Matthew Brost wrote:
>
> On Wed, Jun 02, 2021 at 03:33:43PM +0100, Tvrtko Ursulin wrote:
> >
> > On 06/05/2021 20:14, Matthew Brost wrote:
> > > Reset implementation for new GuC interface. This is the legacy reset
> > > implementation which is called when the i915 ow
4;
> - cmds = blob + PAGE_SIZE / 4 + PAGE_SIZE / 2;
> - cmds_size = PAGE_SIZE / 4;
> + desc = blob + CTB_DESC_SIZE;
> + cmds = blob + 2 * CTB_DESC_SIZE + CTB_H2G_BUFFER_SIZE;
> + cmds_size = CTB_G2H_BUFFER_SIZE;
> CT_DEBUG(ct, "%s desc %#tx cmds %#tx size %u\n", "recv",
>ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
>
> --
> 2.28.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
= CONFIG_DRM_I915_GUC_CTB_TIMEOUT;
> +
> #define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
> err = wait_for_us(done, 10);
> if (err)
> - err = wait_for(done, 10);
> + err = wait_for(done, timeout);
> #und
ts _much_ preferred, since then you can
make them multi-line and actually explain stuff - the header format
strictly speaking also allows multi-line, but not with nice formatting and
so encourages people to lean way too much towards brevity.
Plus it's closer where people look (for big structs).
I guess add that to the kerneldoc cleanup work.
-Daniel
> struct guc_ct_buffer_desc *desc;
> u32 *cmds;
> u32 size;
> --
> 2.28.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
4bade6...@intel.com/
> >
> > > + } else {
> > > + /* wmb() sufficient for a barrier if in smem */
> > > + wmb();
> > > + }
> > > +}
> > > +
> > > /**
> > > * DOC: CTB Host to GuC request
> > > *
NE_INSTANCE(guc_id) \
> (((guc_id) & GUC_ENGINE_INSTANCE_MASK) >> GUC_ENGINE_INSTANCE_SHIFT)
>
> +static inline u8 engine_class_to_guc_class(u8 class)
> +{
> + BUILD_BUG_ON(GUC_RENDER_CLASS != RENDER_CLASS);
> + BUILD_BUG_ON(G
On Fri, Jun 04, 2021 at 11:01:40AM +0200, Thomas Hellström wrote:
>
> On 6/4/21 9:51 AM, Christian König wrote:
> > Am 03.06.21 um 09:36 schrieb Daniel Vetter:
> > > On Thu, Jun 3, 2021 at 8:50 AM Thomas Hellström
> > > wrote:
> > > >
> > > >
On Wed, May 26, 2021 at 04:33:56PM -0700, Matthew Brost wrote:
> Add entry for i915 GuC submission / DRM scheduler integration plan.
> Follow up patch with details of new parallel submission uAPI to come.
>
> v2:
> (Daniel Vetter)
> - Expand explaination of why bonding isn&#
On Wed, May 26, 2021 at 04:33:57PM -0700, Matthew Brost wrote:
> Add entry for i915 new parallel submission uAPI plan.
>
> v2:
> (Daniel Vetter):
> - Expand logical order explaination
> - Add dummy header
> - Only allow N BBs in execbuf IOCTL
> - Configure para
> >>>>>>
> >>>>>> So it looks like a change to ct_send to me. Is that wrong?
> >>>>
> >>>> What about this part - is the patch changing the blocking ct_send or not,
> >>>> and if it is why?
> >>>>
> &g
in
> active use today so we can't simply disallow setting the VM or engine
> set vial SET_CONTEXT_PARAM. In order to work around this wart, this
> commit adds a proto-context struct which contains all the context create
> parameters.
>
> v2 (Daniel Vetter):
> - Bett
ell as a
> duplicated (and slightly different) copy of the code which programs the
> PPGTT registers.
>
> v2 (Jason Ekstrand):
> - Expand the commit message
>
> Signed-off-by: Jason Ekstrand
> Reviewed-by: Daniel Vetter
Need to retract this r-b here until the issue
On Wed, Jun 09, 2021 at 01:34:00PM +0200, Daniel Vetter wrote:
> On Tue, Jun 08, 2021 at 11:36:07PM -0500, Jason Ekstrand wrote:
> > When the APIs were added to manage VMs more directly from userspace, the
> > questionable choice was made to allow changing out the VM on a context
. Force the issue by blocking the old mechanism on any future
> hardware generations.
>
> Signed-off-by: Jason Ekstrand
With that static added here (same ofc holds for the other one 0day
spotted):
Reviewed-by: Daniel Vetter
But also I think an ack from Jon Bloomfield here would be
; + ce->vm = i915_vm_get(ctx->vm);
> }
>
> if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
> --
> 2.31.1
>
> _______
> Intel-gfx mail
2.31.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
gniew Kempczyński
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Jason Ekstrand
This conflicts with Lucas' switch from INTEL_GEN to GRAPHICS_VER. Can you
pls rebase and resend (with Dave's ack included).
-Daniel
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c|
On Fri, Jun 04, 2021 at 11:35:39AM -0700, Matthew Brost wrote:
> On Fri, Jun 04, 2021 at 10:33:07AM +0200, Daniel Vetter wrote:
> > On Wed, Jun 02, 2021 at 10:16:23PM -0700, Matthew Brost wrote:
> > > From: Michal Wajdeczko
> > >
> > > In upcoming patch we wil
n 2021 12:41:16 +1000
> > > > > Subject: [PATCH] hack fix up for needed amdgpu_preempt_mgr_new() fix
> > > > > up
> > > > >
> > > > > Signed-off-by: Stephen Rothwell
> > > > > ---
> > > > > driver
On Wed, Jun 09, 2021 at 04:35:57PM +0200, Thomas Hellström wrote:
>
> On 6/9/21 3:08 PM, Thomas Hellström wrote:
> >
> > On 6/9/21 2:20 PM, Matthew Auld wrote:
> > > On 09/06/2021 13:16, Thomas Hellström wrote:
> > > >
> > > > On 6/9/21 1:4
ent hw doesn't have userspace
ringbuffer, but we have a pretty clever trick in the works to make
this possible with current hw, essentially by submitting a CS that
loops on itself, and then inserting batches into this "ring" by
latching a conditional branch in this CS. It's not
On Thu, Jun 10, 2021 at 1:29 PM Daniel Vetter wrote:
> On Thu, Jun 10, 2021 at 11:39 AM Christian König
> wrote:
> > Am 10.06.21 um 11:29 schrieb Tvrtko Ursulin:
> > > On 09/06/2021 22:29, Jason Ekstrand wrote:
> > >> Ever since 0eafec6d3244 ("drm/i
rs/gpu/drm/nouveau/nouveau_backlight.c| 166 +-
> drivers/gpu/drm/nouveau/nouveau_bo.c | 6 +
> drivers/gpu/drm/nouveau/nouveau_connector.h| 9 +-
> drivers/gpu/drm/nouveau/nouveau_encoder.h | 1 +
> include/drm/drm_dp_helper.h
et of
fences across exclusive and all shared slot. Not to protect against
the fence disappearing due to typesafe_by_rcu.
-Daniel
> --Jason
>
> > Regards,
> > Christian.
> >
> > >
> > > Signed-off-by: Jason Ekstrand
> > > Cc: Daniel Vetter
On Wed, Jun 09, 2021 at 04:10:23PM -0700, Matthew Brost wrote:
> On Tue, Jun 08, 2021 at 10:46:15AM +0200, Daniel Vetter wrote:
> > On Tue, Jun 8, 2021 at 10:39 AM Tvrtko Ursulin
> > wrote:
> > >
> > >
> > > On 07/06/2021 18:31, Matthew Brost wrote:
On Thu, Jun 10, 2021 at 6:24 PM Jason Ekstrand wrote:
>
> On Thu, Jun 10, 2021 at 10:13 AM Daniel Vetter wrote:
> >
> > On Thu, Jun 10, 2021 at 3:59 PM Jason Ekstrand wrote:
> > >
> > > On Thu, Jun 10, 2021 at 1:51 AM Christian König
> > > wrote:
On Wed, Jun 09, 2021 at 11:00:26AM -0500, Jason Ekstrand wrote:
> On Wed, Jun 9, 2021 at 6:28 AM Daniel Vetter wrote:
> >
> > On Tue, Jun 08, 2021 at 11:35:58PM -0500, Jason Ekstrand wrote:
> > > The current context uAPI allows for two methods of setting
1 - 100 of 23475 matches
Mail list logo
