Re: [QUESTION] drmModeAtomicCommit returns -EINVAL on return
Hi Michel, Thanks for your answer, I just enabled the debug and captured a drm debug log from dmesg, but I don't seem to find anything that looks like an error, Is there anything specific I should be looking for? Sorry for attaching my log here, here is the last drmModeAtomicCommit where I had -einval. [ 56.005133] [drm:drm_atomic_state_init [drm]] Allocated atomic state c20a40d6 [ 56.005218] [drm:drm_mode_object_get [drm]] OBJ ID: 97 (3) [ 56.005297] [drm:drm_mode_object_get [drm]] OBJ ID: 97 (4) [ 56.005373] [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:31:plane 1A] 40b2d9eb state to c20a40d6 [ 56.005457] [drm:drm_mode_object_get [drm]] OBJ ID: 122 (1) [ 56.005534] [drm:drm_atomic_get_crtc_state [drm]] Added [CRTC:51:pipe A] 73659c18 state to c20a40d6 [ 56.005611] [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:39:plane 2A] 71f640c7 state to c20a40d6 [ 56.005687] i915 :00:02.0: [drm:drm_atomic_set_fb_for_plane [drm]] Set [NOFB] for [PLANE:39:plane 2A] state 71f640c7 [ 56.005765] [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:47:cursor A] 0ebe824b state to c20a40d6 [ 56.005839] i915 :00:02.0: [drm:drm_atomic_set_fb_for_plane [drm]] Set [NOFB] for [PLANE:47:cursor A] state 0ebe824b [ 56.005911] [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:52:plane 1B] b6f083af state to c20a40d6 [ 56.005983] [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:60:plane 2B] 243f0105 state to c20a40d6 [ 56.006055] i915 :00:02.0: [drm:drm_atomic_set_fb_for_plane [drm]] Set [NOFB] for [PLANE:60:plane 2B] state 243f0105 [ 56.006124] [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:68:cursor B] c385344b state to c20a40d6 [ 56.006196] i915 :00:02.0: [drm:drm_atomic_set_fb_for_plane [drm]] Set [NOFB] for [PLANE:68:cursor B] state c385344b [ 56.006264] [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:73:plane 1C] 6229658a state to c20a40d6 [ 56.006336] [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:81:plane 2C] 65fc3015 state to c20a40d6 [ 56.006407] i915 :00:02.0: [drm:drm_atomic_set_fb_for_plane [drm]] Set [NOFB] for [PLANE:81:plane 2C] state 65fc3015 [ 56.006475] [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:89:cursor C] c5c2644d state to c20a40d6 [ 56.006546] i915 :00:02.0: [drm:drm_atomic_set_fb_for_plane [drm]] Set [NOFB] for [PLANE:89:cursor C] state c5c2644d [ 56.006618] i915 :00:02.0: [drm:drm_atomic_set_fb_for_plane [drm]] Set [FB:97] for [PLANE:31:plane 1A] state 40b2d9eb [ 56.006686] [drm:drm_mode_object_get [drm]] OBJ ID: 97 (5) [ 56.006763] [drm:drm_mode_object_put.part.0 [drm]] OBJ ID: 97 (6) [ 56.006858] [drm:drm_atomic_add_affected_connectors [drm]] Adding all current connectors for [CRTC:51:pipe A] to c20a40d6 [ 56.006942] [drm:drm_mode_object_get [drm]] OBJ ID: 95 (4) [ 56.007019] [drm:drm_mode_object_get [drm]] OBJ ID: 95 (5) [ 56.007094] [drm:drm_atomic_get_connector_state [drm]] Added [CONNECTOR:95:eDP-1] 66710aab state to c20a40d6 [ 56.007172] [drm:drm_mode_object_put.part.0 [drm]] OBJ ID: 95 (5) [ 56.007250] i915 :00:02.0: [drm:drm_atomic_set_crtc_for_connector [drm]] Link [CONNECTOR:95:eDP-1] state 66710aab to [NOCRTC] [ 56.007321] [drm:drm_mode_object_get [drm]] OBJ ID: 95 (4) [ 56.007397] i915 :00:02.0: [drm:drm_atomic_set_crtc_for_connector [drm]] Link [CONNECTOR:95:eDP-1] state 66710aab to [CRTC:51:pipe A] [ 56.007471] [drm:drm_atomic_get_crtc_state [drm]] Added [CRTC:72:pipe B] 65ce9351 state to c20a40d6 [ 56.007548] i915 :00:02.0: [drm:drm_atomic_set_mode_for_crtc [drm]] Set [NOMODE] for [CRTC:72:pipe B] state 65ce9351 [ 56.007618] i915 :00:02.0: [drm:drm_atomic_set_fb_for_plane [drm]] Set [NOFB] for [PLANE:52:plane 1B] state b6f083af [ 56.007684] [drm:drm_atomic_add_affected_connectors [drm]] Adding all current connectors for [CRTC:72:pipe B] to c20a40d6 [ 56.007765] [drm:drm_atomic_get_crtc_state [drm]] Added [CRTC:93:pipe C] 67f37a81 state to c20a40d6 [ 56.007838] i915 :00:02.0: [drm:drm_atomic_set_mode_for_crtc [drm]] Set [NOMODE] for [CRTC:93:pipe C] state 67f37a81 [ 56.007907] i915 :00:02.0: [drm:drm_atomic_set_fb_for_plane [drm]] Set [NOFB] for [PLANE:73:plane 1C] state 6229658a [ 56.007975] [drm:drm_atomic_add_affected_connectors [drm]] Adding all current connectors for [CRTC:93:pipe C] to c20a40d6 [ 56.008051] [drm:drm_atomic_check_only [drm]] checking c20a40d6 [ 56.008133] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:95:eDP-1] [ 56.008184] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CONNECTOR:95:eDP-1] keeps [ENCODER:94:
Re: [PATCH 1/6] drm/i915/ttm: add ttm_buddy_man
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
> Add back our standalone i915_buddy allocator and integrate it into a
> ttm_resource_manager. This will plug into our ttm backend for
> managing
> device local-memory in the next couple of patches.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> ---
>
Since the buddy + selftests have been part of the driver before, I
didn't review them separately, but for the TTM interface, some minor
comments below. With those fixed,
Acked-by: Thomas Hellström
> diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> new file mode 100644
> index ..d7bf37be1932
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
> @@ -0,0 +1,246 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2021 Intel Corporation
> + */
> +
> +#include
> +
> +#include
> +#include
> +
> +#include "i915_ttm_buddy_manager.h"
> +
> +#include "i915_buddy.h"
> +#include "i915_gem.h"
> +
> +struct i915_ttm_buddy_manager {
> + struct ttm_resource_manager manager;
> + struct i915_buddy_mm mm;
> + struct list_head reserved;
> + struct mutex lock;
> +};
> +
> +static inline struct i915_ttm_buddy_manager *
"inline" shouldn't be needed here.
> +to_buddy_manager(struct ttm_resource_manager *man)
> +{
> + return container_of(man, struct i915_ttm_buddy_manager,
> manager);
> +}
> +
> +static int i915_ttm_buddy_man_alloc(struct ttm_resource_manager
> *man,
> + struct ttm_buffer_object *bo,
> + const struct ttm_place *place,
> + struct ttm_resource **res)
> +{
> + struct i915_ttm_buddy_manager *bman = to_buddy_manager(man);
> + struct i915_ttm_buddy_resource *bman_res;
> + struct i915_buddy_mm *mm = &bman->mm;
> + unsigned long n_pages;
> + unsigned int min_order;
> + u64 size;
> + int err;
> +
> + GEM_BUG_ON(place->fpfn || place->lpfn);
> + GEM_BUG_ON(bo->page_alignment < mm->chunk_size);
> +
> + bman_res = kzalloc(sizeof(*bman_res), GFP_KERNEL);
> + if (!bman_res)
> + return -ENOMEM;
> +
> + ttm_resource_init(bo, place, &bman_res->base);
> + INIT_LIST_HEAD(&bman_res->blocks);
> + bman_res->mm = mm;
> +
> + GEM_BUG_ON(!bman_res->base.num_pages);
> + size = bman_res->base.num_pages << PAGE_SHIFT;
> +
> + min_order = ilog2(bo->page_alignment) - ilog2(mm-
> >chunk_size);
> + if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
> + size = roundup_pow_of_two(size);
> + min_order = ilog2(size) - ilog2(mm->chunk_size);
> + }
> +
> + if (size > mm->size) {
> + err = -E2BIG;
> + goto err_free_res;
> + }
> +
> + n_pages = size >> ilog2(mm->chunk_size);
> +
> + do {
> + struct i915_buddy_block *block;
> + unsigned int order;
> +
> + order = fls(n_pages) - 1;
> + GEM_BUG_ON(order > mm->max_order);
> + GEM_BUG_ON(order < min_order);
> +
> + do {
> + mutex_lock(&bman->lock);
> + block = i915_buddy_alloc(mm, order);
> + mutex_unlock(&bman->lock);
> + if (!IS_ERR(block))
> + break;
> +
> + if (order-- == min_order) {
> + err = -ENXIO;
IIRC, TTM relies on -ENOSPC to retry with evictions.
> + goto err_free_blocks;
> + }
> + } while (1);
> +
> + n_pages -= BIT(order);
> +
> + list_add_tail(&block->link, &bman_res->blocks);
> +
> + if (!n_pages)
> + break;
> + } while (1);
> +
> + *res = &bman_res->base;
> + return 0;
> +
> +err_free_blocks:
> + mutex_lock(&bman->lock);
> + i915_buddy_free_list(mm, &bman_res->blocks);
> + mutex_unlock(&bman->lock);
> +err_free_res:
> + kfree(bman_res);
> + return err;
> +}
> +
/Thomas
Re: [PATCH 01/10] drm/ttm: allocate resource object instead of embedding it v2
Am 08.06.21 um 07:29 schrieb Thomas Hellström (Intel):
Hi,
On 6/7/21 7:59 PM, Christian König wrote:
Am 07.06.21 um 19:58 schrieb Thomas Hellström (Intel):
On 6/7/21 7:54 PM, Christian König wrote:
Am 07.06.21 um 19:06 schrieb Thomas Hellström (Intel):
On 6/7/21 6:40 PM, Thomas Hellström (Intel) wrote:
On 6/2/21 12:09 PM, Christian König wrote:
...
@@ -728,14 +728,15 @@ static int ttm_bo_add_move_fence(struct
ttm_buffer_object *bo,
*/
static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
const struct ttm_place *place,
- struct ttm_resource *mem,
+ struct ttm_resource **mem,
struct ttm_operation_ctx *ctx)
{
struct ttm_device *bdev = bo->bdev;
- struct ttm_resource_manager *man = ttm_manager_type(bdev,
mem->mem_type);
+ struct ttm_resource_manager *man;
struct ww_acquire_ctx *ticket;
int ret;
+ man = ttm_manager_type(bdev, (*mem)->mem_type);
Isn't (*mem) uninitialized here? Should be place->mem_type?
Eviction is immediately sent to the bushes.
Got at least one additional NULL pointer deref to track down in
the eviction code, but could be a merge error of mine as well.
Actually this last one was probably due to a bad temporary fix of
the above one.
I've found one more warning during my testing now. But that is just
a false positive.
Apart from that I haven't seen any other fallout, but fingers crossed.
vmwgfx doesn't seem to happy. It works AFAICT., but warns in
vmw_move() about ttm_bo_assign_mem() replacing an existing resource.
Yeah, that's the one I've just fixed. Patch is underway.
If that's the move_to_ghost patch, I don't think that would fix the
vmwgfx issue, as IIRC vmwgfx ever uses ghost objects.
Mhm, could be that vmwgfx is hitting the same warning with a different
backtrace.
Do you have the log to double check?
Thanks,
Christian.
/Thomas
Re: [PATCH 01/10] drm/ttm: allocate resource object instead of embedding it v2
Hi,
On 6/8/21 9:14 AM, Christian König wrote:
Am 08.06.21 um 07:29 schrieb Thomas Hellström (Intel):
Hi,
On 6/7/21 7:59 PM, Christian König wrote:
Am 07.06.21 um 19:58 schrieb Thomas Hellström (Intel):
On 6/7/21 7:54 PM, Christian König wrote:
Am 07.06.21 um 19:06 schrieb Thomas Hellström (Intel):
On 6/7/21 6:40 PM, Thomas Hellström (Intel) wrote:
On 6/2/21 12:09 PM, Christian König wrote:
...
@@ -728,14 +728,15 @@ static int ttm_bo_add_move_fence(struct
ttm_buffer_object *bo,
*/
static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
const struct ttm_place *place,
- struct ttm_resource *mem,
+ struct ttm_resource **mem,
struct ttm_operation_ctx *ctx)
{
struct ttm_device *bdev = bo->bdev;
- struct ttm_resource_manager *man = ttm_manager_type(bdev,
mem->mem_type);
+ struct ttm_resource_manager *man;
struct ww_acquire_ctx *ticket;
int ret;
+ man = ttm_manager_type(bdev, (*mem)->mem_type);
Isn't (*mem) uninitialized here? Should be place->mem_type?
Eviction is immediately sent to the bushes.
Got at least one additional NULL pointer deref to track down in
the eviction code, but could be a merge error of mine as well.
Actually this last one was probably due to a bad temporary fix of
the above one.
I've found one more warning during my testing now. But that is
just a false positive.
Apart from that I haven't seen any other fallout, but fingers
crossed.
vmwgfx doesn't seem to happy. It works AFAICT., but warns in
vmw_move() about ttm_bo_assign_mem() replacing an existing resource.
Yeah, that's the one I've just fixed. Patch is underway.
If that's the move_to_ghost patch, I don't think that would fix the
vmwgfx issue, as IIRC vmwgfx ever uses ghost objects.
Mhm, could be that vmwgfx is hitting the same warning with a different
backtrace.
Do you have the log to double check?
Unfortunately not, but IIRC it was directly from vmw_move().
/Thomas
Re: [PATCH 2/6] drm/i915/ttm: add i915_sg_from_buddy_resource
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote: > We need to be able to build an sg table from our list of buddy > blocks, > so that we can later plug this into our ttm backend, and replace our > use > of the range manager. > > Signed-off-by: Matthew Auld > Cc: Thomas Hellström Not sure whether this is the best place to put this or move both the drm_mm variant and this to the TTM region code, but I guess it doesn't really matter. Reviewed-by: Thomas Hellström
Re: [PATCH 01/10] drm/ttm: allocate resource object instead of embedding it v2
Am 08.06.21 um 09:17 schrieb Thomas Hellström (Intel): [SNIP] Do you have the log to double check? Unfortunately not, but IIRC it was directly from vmw_move(). Nirmoy do you still have your vmwgfx test environment? Thanks, Christian. /Thomas
Re: [PATCH 4/6] drm/i915/ttm: pass along the I915_BO_ALLOC_CONTIGUOUS
Hi,
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
> Currently we just ignore the I915_BO_ALLOC_CONTIGUOUS flag, which is
> fine since everything is already contiguous with the ttm range
> manager.
> However in the next patch we want to switch over to the ttm buddy
> manager, where allocations are by default not contiguous.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 73d52df8f2be..0b0fce445e9b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -86,10 +86,18 @@ i915_ttm_select_tt_caching(const struct
> drm_i915_gem_object *obj)
>
> static void
> i915_ttm_place_from_region(const struct intel_memory_region *mr,
> - struct ttm_place *place)
> + struct ttm_place *place,
> + unsigned int flags)
> {
> memset(place, 0, sizeof(*place));
> place->mem_type = intel_region_to_ttm_type(mr);
> +
> + switch(mr->type) {
> + case INTEL_MEMORY_LOCAL:
> + if (flags & I915_BO_ALLOC_CONTIGUOUS)
> + place->flags = TTM_PL_FLAG_CONTIGUOUS;
> + break;
> + }
Do we need to restrict this to INTEL_MEMORY_LOCAL? While it doesn't
currently make much sense for other memory regions, no point in not
forwarding for all?
/Thomas
Re: [PATCH 5/6] drm/i915/ttm: switch over to ttm_buddy_man
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote: > Move back to the buddy allocator for managing device local memory, > and > restore the lost mock selftests. Keep around the range manager > related > bits, since we likely need this for managing stolen at some point. > For > stolen we also don't need to reserve anything so no need to support a > generic reserve interface. > > Signed-off-by: Matthew Auld > Cc: Thomas Hellström lgtm. Reviewed-by: Thomas Hellström
Re: [PATCH 5/6] drm/i915/ttm: switch over to ttm_buddy_man
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
> Move back to the buddy allocator for managing device local memory,
> and
> restore the lost mock selftests. Keep around the range manager
> related
> bits, since we likely need this for managing stolen at some point.
> For
> stolen we also don't need to reserve anything so no need to support a
> generic reserve interface.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 26 +--
> drivers/gpu/drm/i915/intel_memory_region.c | 55 +-
> drivers/gpu/drm/i915/intel_memory_region.h | 17 --
> drivers/gpu/drm/i915/intel_region_ttm.c | 100 +++
> .../drm/i915/selftests/intel_memory_region.c | 170
> --
>
...
>
> static int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
> @@ -661,20 +661,8 @@ int __i915_gem_ttm_object_init(struct
> intel_memory_region *mem,
> static struct lock_class_key lock_class;
> struct drm_i915_private *i915 = mem->i915;
> enum ttm_bo_type bo_type;
> - size_t alignment = 0;
> int ret;
>
> - /* Adjust alignment to GPU- and CPU huge page sizes. */
> -
> - if (mem->is_range_manager) {
> - if (size >= SZ_1G)
> - alignment = SZ_1G >> PAGE_SHIFT;
> - else if (size >= SZ_2M)
> - alignment = SZ_2M >> PAGE_SHIFT;
> - else if (size >= SZ_64K)
> - alignment = SZ_64K >> PAGE_SHIFT;
> - }
> -
> drm_gem_private_object_init(&i915->drm, &obj->base, size);
> i915_gem_object_init(obj, &i915_gem_ttm_obj_ops, &lock_class,
> flags);
> i915_gem_object_init_memory_region(obj, mem);
> @@ -696,7 +684,7 @@ int __i915_gem_ttm_object_init(struct
> intel_memory_region *mem,
> */
> obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
> ret = ttm_bo_init(&i915->bdev, i915_gem_to_ttm(obj), size,
> - bo_type, &i915_sys_placement, alignment,
> + bo_type, &i915_sys_placement, PAGE_SIZE,
Actually just realized that the alignment is specified in PAGE_SIZE
units, so above should be s/PAGE_SIZE/1/. Might need to check that the
buddy TTM interface gets this right as well.
Re: [PATCH 6/6] drm/i915/ttm: restore min_page_size behaviour
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
> We now have bo->page_alignment which perfectly describes what we need
> if
> we have min page size restrictions for lmem. We can also drop the
> flag
> here, since this is the default behaviour for all objects.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 +--
> drivers/gpu/drm/i915/intel_memory_region.h | 3 +--
> drivers/gpu/drm/i915/intel_region_ttm.c | 2 +-
> drivers/gpu/drm/i915/selftests/mock_region.c | 2 +-
> 4 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 3f5624f36afc..eda6c258ea92 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -684,9 +684,8 @@ int __i915_gem_ttm_object_init(struct
> intel_memory_region *mem,
> */
> obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
> ret = ttm_bo_init(&i915->bdev, i915_gem_to_ttm(obj), size,
> - bo_type, &i915_sys_placement, PAGE_SIZE,
> + bo_type, &i915_sys_placement, mem-
> >min_page_size,
Page size units here as well.
> true, NULL, NULL, i915_ttm_bo_destroy);
> -
> if (!ret)
> obj->ttm.created = true;
>
> diff --git a/drivers/gpu/drm/i915/intel_memory_region.h
> b/drivers/gpu/drm/i915/intel_memory_region.h
> index b04fb22726d9..2be8433d373a 100644
> --- a/drivers/gpu/drm/i915/intel_memory_region.h
> +++ b/drivers/gpu/drm/i915/intel_memory_region.h
> @@ -40,8 +40,7 @@ enum intel_region_id {
> #define REGION_STOLEN_SMEM BIT(INTEL_REGION_STOLEN_SMEM)
> #define REGION_STOLEN_LMEM BIT(INTEL_REGION_STOLEN_LMEM)
>
> -#define I915_ALLOC_MIN_PAGE_SIZE BIT(0)
> -#define I915_ALLOC_CONTIGUOUS BIT(1)
> +#define I915_ALLOC_CONTIGUOUS BIT(0)
>
> #define for_each_memory_region(mr, i915, id) \
> for (id = 0; id < ARRAY_SIZE((i915)->mm.regions); id++) \
> diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
> b/drivers/gpu/drm/i915/intel_region_ttm.c
> index 23af995f7b67..59fa78225852 100644
> --- a/drivers/gpu/drm/i915/intel_region_ttm.c
> +++ b/drivers/gpu/drm/i915/intel_region_ttm.c
> @@ -153,7 +153,7 @@ intel_region_ttm_node_alloc(struct
> intel_memory_region *mem,
> int ret;
>
> mock_bo.base.size = size;
> - mock_bo.page_alignment = PAGE_SIZE;
> + mock_bo.page_alignment = mem->min_page_size;
And here.
> place.flags = flags;
>
> ret = man->func->alloc(man, &mock_bo, &place, &res);
> diff --git a/drivers/gpu/drm/i915/selftests/mock_region.c
> b/drivers/gpu/drm/i915/selftests/mock_region.c
> index d3e4e6573cb9..6ce0f9dacad7 100644
> --- a/drivers/gpu/drm/i915/selftests/mock_region.c
> +++ b/drivers/gpu/drm/i915/selftests/mock_region.c
> @@ -28,7 +28,7 @@ static int mock_region_get_pages(struct
> drm_i915_gem_object *obj)
> struct sg_table *pages;
> int err;
>
> - flags = I915_ALLOC_MIN_PAGE_SIZE;
> + flags = 0;
> if (obj->flags & I915_BO_ALLOC_CONTIGUOUS)
> flags |= TTM_PL_FLAG_CONTIGUOUS;
>
[PATCH] drm/ttm: fix pipelined gutting
We need to make sure to allocate the sys_mem resource before the point
of no return.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 9be6a10a5873..eccf2ad8f335 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -582,6 +582,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
{
static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
struct ttm_buffer_object *ghost;
+ struct ttm_resource *sys_res;
struct ttm_tt *ttm;
int ret;
@@ -602,6 +603,9 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
return ttm_resource_alloc(bo, &sys_mem, &bo->resource);
}
+
+ ret = ttm_resource_alloc(bo, &sys_mem, &sys_res);
+
/*
* We need an unpopulated ttm_tt after giving our current one,
* if any, to the ghost object. And we can't afford to fail
@@ -615,13 +619,11 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
ret = ttm_tt_create(bo, true);
swap(bo->ttm, ttm);
if (ret)
- return ret;
+ goto error_free_sys_mem;
ret = ttm_buffer_object_transfer(bo, &ghost);
- if (ret) {
- ttm_tt_destroy(bo->bdev, ttm);
- return ret;
- }
+ if (ret)
+ goto error_destroy_tt;
ret = dma_resv_copy_fences(&ghost->base._resv, bo->base.resv);
/* Last resort, wait for the BO to be idle when we are OOM */
@@ -631,6 +633,14 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
dma_resv_unlock(&ghost->base._resv);
ttm_bo_put(ghost);
bo->ttm = ttm;
+ bo->resource = NULL;
+ ttm_bo_assign_mem(bo, sys_mem);
+ return 0;
- return ttm_resource_alloc(bo, &sys_mem, &bo->resource);
+error_destroy_tt:
+ ttm_tt_destroy(bo->bdev, ttm);
+
+error_free_sys_mem:
+ ttm_resource_free(bo, &sys_mem);
+ return ret;
}
--
2.25.1
Re: [PATCH 0/9] Enhance pipe color support for multi segmented luts
On Mon, 7 Jun 2021 18:07:23 + "Shankar, Uma" wrote: > > -Original Message- > > From: dri-devel On Behalf Of Pekka > > Paalanen > > Sent: Monday, June 7, 2021 1:00 PM > > To: Harry Wentland > > Cc: intel-...@lists.freedesktop.org; Shankar, Uma ; > > Sebastian Wick ; > > dri-devel@lists.freedesktop.org; > > Modem, Bhanuprakash > > Subject: Re: [PATCH 0/9] Enhance pipe color support for multi segmented luts > > > > On Fri, 4 Jun 2021 14:51:25 -0400 > > Harry Wentland wrote: > > > > > On 2021-06-01 6:41 a.m., Uma Shankar wrote: > > > > Modern hardwares have multi segmented lut approach to prioritize the > > > > darker regions of the spectrum. This series introduces a new UAPI to > > > > define the lut ranges supported by the respective hardware. > > > > > > > > This also enables Pipe Color Management Support for Intel's XE_LPD hw. > > > > Enable Support for Pipe Degamma with the increased lut samples > > > > supported by hardware. This also adds support for newly introduced > > > > Logarithmic Gamma for XE_LPD. Also added the gamma readout support. > > > > > > > > The Logarithmic gamma implementation on XE_LPD is non linear and > > > > adds 25 segments with non linear lut samples in each segment. The > > > > expectation is userspace will create the luts as per this > > > > distribution and pass the final samples to driver to be programmed in > > > > hardware. > > > > > > > > > > Is this design targetting Intel XE_LPD HW in particular or is it > > > intended to be generic? > > > > > > If this is intended to be generic I think it would benefit from a lot > > > more documentation. At this point it's difficult for me to see how to > > > adapt this to AMD HW. It would take me a while to be comfortable to > > > make a call on whether we can use it or not. And what about other vendors? > > > > > > I think we need to be cautious in directly exposing HW functionality > > > through UAPI. The CM parts of AMD HW seem to be changing in some way > > > each generation and it looks like the same is true for Intel. The > > > trouble we have with adapting the old gamma/degamma properties to > > > modern HW is some indication to me that this approach is somewhat > > > problematic. > > > > > > It would be useful to understand and document the specific use-cases > > > we want to provide to userspace implementers with this functionality. > > > Do we want to support modern transfer functions such as PQ or HLG? If > > > so, it might be beneficial to have an API to explicitly specify that, > > > and then use LUT tables in drivers that are optimized for the > > > implementing HW. > > > > Hi Harry, > > > > from my very limited understanding so far, enum might be fine for PQ, but > > HLG is not > > just one transfer function, although it may often be confused as one. PQ > > and HLG > > are fundamentally different designs to HDR broadcasting I believe. It would > > be > > unfortunate to make a mistake here, engraving it into UAPI. > > Yes Pekka, putting this in UAPI may limit us. > > > > Or is the use case tone mapping? If so, would a parametric definition > > > of tone mapping be easier to manage? > > > > A very good question at least I have no idea about. > > Responded on earlier mail in thread. For non linear lut (gamma > block), usecase is primarily tone mapping but there are > implementations where non linear blending is seeked (AFAIR Android > does that), so it leaves room for those usecases as well. Yes, non-linear blending is a thing, unfortunately. Developers do not usually understand what could be wrong with simply blending "RGBA values", so most software just does that. It produces *a* result, and if all you use it for is shades of black (shadows) or rounded window corners, you never even see anything wrong with it. So the world has accustomed to seeing "incorrect blending" so much that they think doing anything else is wrong and complain if you try to move to physically correct blending, because it changes the strength of shadows. Hence any software migrating to a more correct blending formula may be met with bug reports. What's worse, pre-multiplied alpha is used as an optimization, as implemented everywhere including Wayland, in a way that is actually a step *away* from correct blending. If one wants to do correct blending, you first need to divide out the pre-multiplied alpha, then linearize, then blend. Luckily(?), non-linear blending of HDR content will probably look a lot worse than the same mistake on SDR content. Thanks, pq pgpoO0bON6uq7.pgp Description: OpenPGP digital signature
Re: [PATCH 01/13] drm/i915/guc: Introduce unified HXG messages
On 08.06.2021 00:46, Daniele Ceraolo Spurio wrote: > > > On 6/7/2021 11:03 AM, Matthew Brost wrote: >> From: Michal Wajdeczko >> >> New GuC firmware will unify format of MMIO and CTB H2G messages. >> Introduce their definitions now to allow gradual transition of >> our code to match new changes. >> >> Signed-off-by: Matthew Brost >> Signed-off-by: Michal Wajdeczko >> Cc: Michał Winiarski >> --- >> .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 ++ >> 1 file changed, 213 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h >> b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h >> index 775e21f3058c..29ac823acd4c 100644 >> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h >> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h >> @@ -6,6 +6,219 @@ >> #ifndef _ABI_GUC_MESSAGES_ABI_H >> #define _ABI_GUC_MESSAGES_ABI_H >> +/** >> + * DOC: HXG Message >> + * >> + * All messages exchanged with GuC are defined using 32 bit dwords. >> + * First dword is treated as a message header. Remaining dwords are >> optional. >> + * >> + * >> +---+---+--+ >> >> + * | | Bits | >> Description | >> + * >> +===+===+==+ >> >> + * | | >> | | >> + * | 0 | 31 | **ORIGIN** - originator of the >> message | >> + * | | | - _`GUC_HXG_ORIGIN_HOST` = >> 0 | >> + * | | | - _`GUC_HXG_ORIGIN_GUC` = >> 1 | >> + * | | >> | | >> + * | >> +---+--+ >> + * | | 30:28 | **TYPE** - message >> type | >> + * | | | - _`GUC_HXG_TYPE_REQUEST` = >> 0 | >> + * | | | - _`GUC_HXG_TYPE_EVENT` = >> 1 | >> + * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_BUSY` = >> 3 | >> + * | | | - _`GUC_HXG_TYPE_NO_RESPONSE_RETRY` = >> 5 | >> + * | | | - _`GUC_HXG_TYPE_RESPONSE_FAILURE` = >> 6 | >> + * | | | - _`GUC_HXG_TYPE_RESPONSE_SUCCESS` = >> 7 | >> + * | >> +---+--+ >> + * | | 27:0 | **AUX** - auxiliary data (depends on >> TYPE) | >> + * >> +---+---+--+ >> >> + * | 1 | 31:0 >> | | >> + * >> +---+---+ >> | >> + * |...| | **PAYLOAD** - optional payload (depends on >> TYPE) | >> + * >> +---+---+ >> | >> + * | n | 31:0 >> | | >> + * >> +---+---+--+ >> >> + */ >> + >> +#define GUC_HXG_MSG_MIN_LEN 1u >> +#define GUC_HXG_MSG_0_ORIGIN (0x1 << 31) > > Any reason not to use BIT(31) here? same below with other bits and with > GENMASK for masks. initial goal was to have all ABI definitions auto-generated from GuC spec files, using just pure C syntax to avoid any dependencies. we can try to wrap some definitions into generic helpers like HXG_MASK(...) and then remap them to our REG_GENMASK but didn't feel this is super important > >> +#define GUC_HXG_ORIGIN_HOST 0u >> +#define GUC_HXG_ORIGIN_GUC 1u >> +#define GUC_HXG_MSG_0_TYPE (0x7 << 28) > > I think the masks could use a _MASK postfix all field definitions are masks, so it would be redundant IMHO note that previously there were both _MASK and _SHIFT definitions and then it was required to have extra suffix > >> +#define GUC_HXG_TYPE_REQUEST 0u >> +#define GUC_HXG_TYPE_EVENT 1u >> +#define GUC_HXG_TYPE_NO_RESPONSE_BUSY 3u >> +#define GUC_HXG_TYPE_NO_RESPONSE_RETRY 5u >> +#define GUC_HXG_TYPE_RESPONSE_FAILURE 6u >> +#define GUC_HXG_TYPE_RESPONSE_SUCCESS 7u >> +#define GUC_HXG_MSG_0_AUX (0xfff << 0) >> +#define GUC_HXG_MSG_n_PAYLOAD (0x << 0) > > Is a mask that covers the whole u32 really needed? Even for future > proofing, I find it very unlikely that we'll ever have a case where the > payload is not an entire dword. maybe not strictly required but IIRC allows to have consistent definitions for derived messages > >> + >> +/** >> + * DOC: HXG Request >> + * >> + * The `HXG Request`_ message
Re: [PATCH 4/6] drm/i915/ttm: pass along the I915_BO_ALLOC_CONTIGUOUS
On 08/06/2021 08:26, Thomas Hellström wrote:
Hi,
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
Currently we just ignore the I915_BO_ALLOC_CONTIGUOUS flag, which is
fine since everything is already contiguous with the ttm range
manager.
However in the next patch we want to switch over to the ttm buddy
manager, where allocations are by default not contiguous.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 73d52df8f2be..0b0fce445e9b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -86,10 +86,18 @@ i915_ttm_select_tt_caching(const struct
drm_i915_gem_object *obj)
static void
i915_ttm_place_from_region(const struct intel_memory_region *mr,
- struct ttm_place *place)
+ struct ttm_place *place,
+ unsigned int flags)
{
memset(place, 0, sizeof(*place));
place->mem_type = intel_region_to_ttm_type(mr);
+
+ switch(mr->type) {
+ case INTEL_MEMORY_LOCAL:
+ if (flags & I915_BO_ALLOC_CONTIGUOUS)
+ place->flags = TTM_PL_FLAG_CONTIGUOUS;
+ break;
+ }
Do we need to restrict this to INTEL_MEMORY_LOCAL? While it doesn't
currently make much sense for other memory regions, no point in not
forwarding for all?
Yeah, don't see why not.
/Thomas
Re: [PATCH V6 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
Hi, On 07/06/2021 19:42, Marek Vasut wrote: > Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge > and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS > bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on, > but easy to add. > > The driver operates the chip via I2C bus. Currently the LVDS clock are > always derived from DSI clock lane, which is the usual mode of operation. > Support for clock from external oscillator is not implemented, but it is > easy to add if ever needed. Only RGB888 pixel format is implemented, the > LVDS666 is not supported, but could be added if needed. > > Reviewed-by: Linus Walleij > Reviewed-by: Frieder Schrempf > Tested-by: Frieder Schrempf > Tested-by: Adam Ford > Signed-off-by: Marek Vasut > Cc: Douglas Anderson > Cc: Jagan Teki > Cc: Laurent Pinchart > Cc: Linus Walleij > Cc: Loic Poulain > Cc: Philippe Schenker > Cc: Sam Ravnborg > Cc: Stephen Boyd > Cc: Valentin Raevsky > To: dri-devel@lists.freedesktop.org > --- > V2: - Use dev_err_probe() > - Set REG_RC_RESET as volatile > - Wait for PLL stabilization by polling REG_RC_LVDS_PLL > - Use ctx->mode = *adj instead of *mode in sn65dsi83_mode_set > - Add tested DSI84 support in dual-link mode > - Correctly set VCOM > - Fill in missing DSI CHB and LVDS CHB bits from DSI84 and DSI85 > datasheets, with that all the reserved bits make far more sense > as the DSI83 and DSI84 seems to be reduced version of DSI85 > V3: - Handle the dual-link LVDS with two port panel or bridge > V4: - Add RB from Linus Walleij > - Rename REG_DSI_LANE_LVDS_LINK_CFG_DUAL to > REG_DSI_LANE_DSI_CHANNEL_MODE_SINGLE and fill in the remaining > DSI link options from DSI85 datasheet. DSI85 can do dual and 2x > single DSI mode, but DSI85 is currently unsupported by the > driver. Add a comment about DSI85, so that all the places which > need to be adjusted for DSI85 are marked accordingly. > - Add REG_DSI_LANE_LEFT_RIGHT_PIXELS bit for DSI > - Add handling for JEIDA18/JEIDA24/SPWG24 LVDS formats. Use SPWG24 > as fallback on output bridges until they are all fixed. > - Patch DSI bus format to fixed RGB888_1X24 instead of passing > through the LVDS bus format. > V5: - Move bus format patching to mode_fixup > - Use cpu_to_le16() to guarantee endianness in regmap_bulk_write() > V6: - Cast of_device_get_match_data() output to uintptr_t first > --- > drivers/gpu/drm/bridge/Kconfig| 10 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/ti-sn65dsi83.c | 709 ++ > 3 files changed, 720 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c > Looks complete & well reviewed, LGTM Rob, Laurent ? is it ok for you ? Neil
Re: [PATCH 1/6] drm/i915/ttm: add ttm_buddy_man
On 08/06/2021 08:11, Thomas Hellström wrote:
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
Add back our standalone i915_buddy allocator and integrate it into a
ttm_resource_manager. This will plug into our ttm backend for
managing
device local-memory in the next couple of patches.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
Since the buddy + selftests have been part of the driver before, I
didn't review them separately, but for the TTM interface, some minor
comments below. With those fixed,
Acked-by: Thomas Hellström
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
new file mode 100644
index ..d7bf37be1932
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -0,0 +1,246 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include
+
+#include
+#include
+
+#include "i915_ttm_buddy_manager.h"
+
+#include "i915_buddy.h"
+#include "i915_gem.h"
+
+struct i915_ttm_buddy_manager {
+ struct ttm_resource_manager manager;
+ struct i915_buddy_mm mm;
+ struct list_head reserved;
+ struct mutex lock;
+};
+
+static inline struct i915_ttm_buddy_manager *
"inline" shouldn't be needed here.
+to_buddy_manager(struct ttm_resource_manager *man)
+{
+ return container_of(man, struct i915_ttm_buddy_manager,
manager);
+}
+
+static int i915_ttm_buddy_man_alloc(struct ttm_resource_manager
*man,
+ struct ttm_buffer_object *bo,
+ const struct ttm_place *place,
+ struct ttm_resource **res)
+{
+ struct i915_ttm_buddy_manager *bman = to_buddy_manager(man);
+ struct i915_ttm_buddy_resource *bman_res;
+ struct i915_buddy_mm *mm = &bman->mm;
+ unsigned long n_pages;
+ unsigned int min_order;
+ u64 size;
+ int err;
+
+ GEM_BUG_ON(place->fpfn || place->lpfn);
+ GEM_BUG_ON(bo->page_alignment < mm->chunk_size);
+
+ bman_res = kzalloc(sizeof(*bman_res), GFP_KERNEL);
+ if (!bman_res)
+ return -ENOMEM;
+
+ ttm_resource_init(bo, place, &bman_res->base);
+ INIT_LIST_HEAD(&bman_res->blocks);
+ bman_res->mm = mm;
+
+ GEM_BUG_ON(!bman_res->base.num_pages);
+ size = bman_res->base.num_pages << PAGE_SHIFT;
+
+ min_order = ilog2(bo->page_alignment) - ilog2(mm-
chunk_size);
+ if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
+ size = roundup_pow_of_two(size);
+ min_order = ilog2(size) - ilog2(mm->chunk_size);
+ }
+
+ if (size > mm->size) {
+ err = -E2BIG;
+ goto err_free_res;
+ }
+
+ n_pages = size >> ilog2(mm->chunk_size);
+
+ do {
+ struct i915_buddy_block *block;
+ unsigned int order;
+
+ order = fls(n_pages) - 1;
+ GEM_BUG_ON(order > mm->max_order);
+ GEM_BUG_ON(order < min_order);
+
+ do {
+ mutex_lock(&bman->lock);
+ block = i915_buddy_alloc(mm, order);
+ mutex_unlock(&bman->lock);
+ if (!IS_ERR(block))
+ break;
+
+ if (order-- == min_order) {
+ err = -ENXIO;
IIRC, TTM relies on -ENOSPC to retry with evictions.
Ah, right. We convert that back to -ENXIO in the upper levels somewhere?
+ goto err_free_blocks;
+ }
+ } while (1);
+
+ n_pages -= BIT(order);
+
+ list_add_tail(&block->link, &bman_res->blocks);
+
+ if (!n_pages)
+ break;
+ } while (1);
+
+ *res = &bman_res->base;
+ return 0;
+
+err_free_blocks:
+ mutex_lock(&bman->lock);
+ i915_buddy_free_list(mm, &bman_res->blocks);
+ mutex_unlock(&bman->lock);
+err_free_res:
+ kfree(bman_res);
+ return err;
+}
+
/Thomas
Re: [PATCH] drm/ttm: fix pipelined gutting
On 6/8/21 9:50 AM, Christian König wrote:
We need to make sure to allocate the sys_mem resource before the point
of no return.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 9be6a10a5873..eccf2ad8f335 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -582,6 +582,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
{
static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
struct ttm_buffer_object *ghost;
+ struct ttm_resource *sys_res;
struct ttm_tt *ttm;
int ret;
@@ -602,6 +603,9 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
return ttm_resource_alloc(bo, &sys_mem, &bo->resource);
}
+
+ ret = ttm_resource_alloc(bo, &sys_mem, &sys_res);
This needs to be moved higher up to also cover the idle optimization path.
Also the return value doesn't seem to be checked?
/Thomas
Re: [PATCH 5/6] drm/i915/ttm: switch over to ttm_buddy_man
On 08/06/2021 08:39, Thomas Hellström wrote:
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
Move back to the buddy allocator for managing device local memory,
and
restore the lost mock selftests. Keep around the range manager
related
bits, since we likely need this for managing stolen at some point.
For
stolen we also don't need to reserve anything so no need to support a
generic reserve interface.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 26 +--
drivers/gpu/drm/i915/intel_memory_region.c | 55 +-
drivers/gpu/drm/i915/intel_memory_region.h | 17 --
drivers/gpu/drm/i915/intel_region_ttm.c | 100 +++
.../drm/i915/selftests/intel_memory_region.c | 170
--
...
static int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
@@ -661,20 +661,8 @@ int __i915_gem_ttm_object_init(struct
intel_memory_region *mem,
static struct lock_class_key lock_class;
struct drm_i915_private *i915 = mem->i915;
enum ttm_bo_type bo_type;
- size_t alignment = 0;
int ret;
- /* Adjust alignment to GPU- and CPU huge page sizes. */
-
- if (mem->is_range_manager) {
- if (size >= SZ_1G)
- alignment = SZ_1G >> PAGE_SHIFT;
- else if (size >= SZ_2M)
- alignment = SZ_2M >> PAGE_SHIFT;
- else if (size >= SZ_64K)
- alignment = SZ_64K >> PAGE_SHIFT;
- }
-
drm_gem_private_object_init(&i915->drm, &obj->base, size);
i915_gem_object_init(obj, &i915_gem_ttm_obj_ops, &lock_class,
flags);
i915_gem_object_init_memory_region(obj, mem);
@@ -696,7 +684,7 @@ int __i915_gem_ttm_object_init(struct
intel_memory_region *mem,
*/
obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
ret = ttm_bo_init(&i915->bdev, i915_gem_to_ttm(obj), size,
- bo_type, &i915_sys_placement, alignment,
+ bo_type, &i915_sys_placement, PAGE_SIZE,
Actually just realized that the alignment is specified in PAGE_SIZE
units, so above should be s/PAGE_SIZE/1/. Might need to check that the
buddy TTM interface gets this right as well.
Oops, and yes it looks like the buddy is also confused here.
Re: [PATCH 02/13] drm/i915/guc: Update MMIO based communication
On 08.06.2021 01:06, Daniele Ceraolo Spurio wrote: > > > On 6/7/2021 11:03 AM, Matthew Brost wrote: >> From: Michal Wajdeczko >> >> The MMIO based Host-to-GuC communication protocol has been >> updated to use unified HXG messages. >> >> Update our intel_guc_send_mmio() function by correctly handle >> BUSY, RETRY and FAILURE replies. Also update our documentation. >> >> GuC: 55.0.0 >> Signed-off-by: Matthew Brost >> Signed-off-by: Michal Wajdeczko >> Cc: Piotr Piórkowski >> Cc: Michal Winiarski #v3 >> --- >> .../gt/uc/abi/guc_communication_mmio_abi.h | 63 ++--- >> drivers/gpu/drm/i915/gt/uc/intel_guc.c | 92 ++- >> 2 files changed, 97 insertions(+), 58 deletions(-) >> >> diff --git >> a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h >> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h >> index be066a62e9e0..3f9039e3ef9d 100644 >> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h >> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h >> @@ -7,46 +7,43 @@ >> #define _ABI_GUC_COMMUNICATION_MMIO_ABI_H >> /** >> - * DOC: MMIO based communication >> + * DOC: GuC MMIO based communication >> * >> - * The MMIO based communication between Host and GuC uses software >> scratch >> - * registers, where first register holds data treated as message header, >> - * and other registers are used to hold message payload. >> + * The MMIO based communication between Host and GuC relies on special >> + * hardware registers which format could be defined by the software >> + * (so called scratch registers). >> * >> - * For Gen9+, GuC uses software scratch registers 0xC180-0xC1B8, >> - * but no H2G command takes more than 8 parameters and the GuC FW >> - * itself uses an 8-element array to store the H2G message. >> - * >> - * +---+-+-+-+ >> - * | MMIO[0] | MMIO[1] | ... | MMIO[n] | >> - * +---+-+-+-+ >> - * | header | optional payload | >> - * +==++=+=+=+ >> - * | 31:28|type| | | | >> - * +--++ | | | >> - * | 27:16|data| | | | >> - * +--++ | | | >> - * | 15:0|code| | | | >> - * +--++-+-+-+ >> - * >> - * The message header consists of: >> - * >> - * - **type**, indicates message type >> - * - **code**, indicates message code, is specific for **type** >> - * - **data**, indicates message data, optional, depends on **code** >> + * Each MMIO based message, both Host to GuC (H2G) and GuC to Host (G2H) >> + * messages, which maximum length depends on number of available scratch >> + * registers, is directly written into those scratch registers. >> * >> - * The following message **types** are supported: >> + * For Gen9+, there are 16 software scratch registers 0xC180-0xC1B8, >> + * but no H2G command takes more than 8 parameters and the GuC firmware >> + * itself uses an 8-element array to store the H2G message. > > Is this statement still true? I believe no MMIO H2G is over 4 DWs (given > the limitation of the new gen11+ scratch regs), while CTB messages can > be longer than 8 DWs. oops, it was just copy/past, you're correct, with new unified firmware, all MMIO H2G are up to 4 DWs > >> * >> - * - **REQUEST**, indicates Host-to-GuC request, requested GuC action >> code >> - * must be priovided in **code** field. Optional action specific >> parameters >> - * can be provided in remaining payload registers or **data** field. >> + * For Gen11+, there are additional 4 registers 0x190240-0x19024C, which >> + * are, regardless on lower count, preffered over legacy ones. > > typo: preffered -> preferred > >> * >> - * - **RESPONSE**, indicates GuC-to-Host response from earlier GuC >> request, >> - * action response status will be provided in **code** field. Optional >> - * response data can be returned in remaining payload registers or >> **data** >> - * field. >> + * The MMIO based communication is mainly used during driver >> initialization >> + * phase to setup the `CTB based communication`_ that will be used >> afterwards. >> */ >> #define GUC_MAX_MMIO_MSG_LEN 8 > > See comment above. Reduce this to 4? yes, must be reduced > >> +/** >> + * DOC: MMIO HXG Message >> + * >> + * Format of the MMIO messages follows definitions of `HXG Message`_. >> + * >> + * >> +---+---+--+ >> >> + * | | Bits | >> Description | >> + * >> +===+===+==+ >> >> + * | 0 | 31:0 | >> ++ | >> + * +---+---+ >> |
Re: [PATCH 1/6] drm/i915/ttm: add ttm_buddy_man
On 6/8/21 10:11 AM, Matthew Auld wrote:
On 08/06/2021 08:11, Thomas Hellström wrote:
On Mon, 2021-06-07 at 19:22 +0100, Matthew Auld wrote:
Add back our standalone i915_buddy allocator and integrate it into a
ttm_resource_manager. This will plug into our ttm backend for
managing
device local-memory in the next couple of patches.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
Since the buddy + selftests have been part of the driver before, I
didn't review them separately, but for the TTM interface, some minor
comments below. With those fixed,
Acked-by: Thomas Hellström
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
new file mode 100644
index ..d7bf37be1932
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -0,0 +1,246 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include
+
+#include
+#include
+
+#include "i915_ttm_buddy_manager.h"
+
+#include "i915_buddy.h"
+#include "i915_gem.h"
+
+struct i915_ttm_buddy_manager {
+ struct ttm_resource_manager manager;
+ struct i915_buddy_mm mm;
+ struct list_head reserved;
+ struct mutex lock;
+};
+
+static inline struct i915_ttm_buddy_manager *
"inline" shouldn't be needed here.
+to_buddy_manager(struct ttm_resource_manager *man)
+{
+ return container_of(man, struct i915_ttm_buddy_manager,
manager);
+}
+
+static int i915_ttm_buddy_man_alloc(struct ttm_resource_manager
*man,
+ struct ttm_buffer_object *bo,
+ const struct ttm_place *place,
+ struct ttm_resource **res)
+{
+ struct i915_ttm_buddy_manager *bman = to_buddy_manager(man);
+ struct i915_ttm_buddy_resource *bman_res;
+ struct i915_buddy_mm *mm = &bman->mm;
+ unsigned long n_pages;
+ unsigned int min_order;
+ u64 size;
+ int err;
+
+ GEM_BUG_ON(place->fpfn || place->lpfn);
+ GEM_BUG_ON(bo->page_alignment < mm->chunk_size);
+
+ bman_res = kzalloc(sizeof(*bman_res), GFP_KERNEL);
+ if (!bman_res)
+ return -ENOMEM;
+
+ ttm_resource_init(bo, place, &bman_res->base);
+ INIT_LIST_HEAD(&bman_res->blocks);
+ bman_res->mm = mm;
+
+ GEM_BUG_ON(!bman_res->base.num_pages);
+ size = bman_res->base.num_pages << PAGE_SHIFT;
+
+ min_order = ilog2(bo->page_alignment) - ilog2(mm-
chunk_size);
+ if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
+ size = roundup_pow_of_two(size);
+ min_order = ilog2(size) - ilog2(mm->chunk_size);
+ }
+
+ if (size > mm->size) {
+ err = -E2BIG;
+ goto err_free_res;
+ }
+
+ n_pages = size >> ilog2(mm->chunk_size);
+
+ do {
+ struct i915_buddy_block *block;
+ unsigned int order;
+
+ order = fls(n_pages) - 1;
+ GEM_BUG_ON(order > mm->max_order);
+ GEM_BUG_ON(order < min_order);
+
+ do {
+ mutex_lock(&bman->lock);
+ block = i915_buddy_alloc(mm, order);
+ mutex_unlock(&bman->lock);
+ if (!IS_ERR(block))
+ break;
+
+ if (order-- == min_order) {
+ err = -ENXIO;
IIRC, TTM relies on -ENOSPC to retry with evictions.
Ah, right. We convert that back to -ENXIO in the upper levels somewhere?
Yes, that's done in the ttm bo backend after ttm_bo_validate() and bo
initialization.
/Thomas
[PATCH] drm/ttm: fix pipelined gutting v2
We need to make sure to allocate the sys_mem resource before the point
of no return.
v2: add missing return value checking, also handle idle case
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 9be6a10a5873..2f57f824e6db 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -582,9 +582,14 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
{
static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
struct ttm_buffer_object *ghost;
+ struct ttm_resource *sys_res;
struct ttm_tt *ttm;
int ret;
+ ret = ttm_resource_alloc(bo, &sys_mem, &sys_res);
+ if (ret)
+ return ret;
+
/* If already idle, no need for ghost object dance. */
ret = ttm_bo_wait(bo, false, true);
if (ret != -EBUSY) {
@@ -592,14 +597,15 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
/* See comment below about clearing. */
ret = ttm_tt_create(bo, true);
if (ret)
- return ret;
+ goto error_free_sys_mem;
} else {
ttm_tt_unpopulate(bo->bdev, bo->ttm);
if (bo->type == ttm_bo_type_device)
ttm_tt_mark_for_clear(bo->ttm);
}
ttm_resource_free(bo, &bo->resource);
- return ttm_resource_alloc(bo, &sys_mem, &bo->resource);
+ ttm_bo_assign_mem(bo, sys_res);
+ return 0;
}
/*
@@ -615,13 +621,11 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
ret = ttm_tt_create(bo, true);
swap(bo->ttm, ttm);
if (ret)
- return ret;
+ goto error_free_sys_mem;
ret = ttm_buffer_object_transfer(bo, &ghost);
- if (ret) {
- ttm_tt_destroy(bo->bdev, ttm);
- return ret;
- }
+ if (ret)
+ goto error_destroy_tt;
ret = dma_resv_copy_fences(&ghost->base._resv, bo->base.resv);
/* Last resort, wait for the BO to be idle when we are OOM */
@@ -631,6 +635,14 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
dma_resv_unlock(&ghost->base._resv);
ttm_bo_put(ghost);
bo->ttm = ttm;
+ bo->resource = NULL;
+ ttm_bo_assign_mem(bo, sys_res);
+ return 0;
+
+error_destroy_tt:
+ ttm_tt_destroy(bo->bdev, ttm);
- return ttm_resource_alloc(bo, &sys_mem, &bo->resource);
+error_free_sys_mem:
+ ttm_resource_free(bo, &sys_res);
+ return ret;
}
--
2.25.1
Re: [PATCH V6 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
Hi Neil, On Tue, Jun 08, 2021 at 10:10:05AM +0200, Neil Armstrong wrote: > On 07/06/2021 19:42, Marek Vasut wrote: > > Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge > > and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS > > bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on, > > but easy to add. > > > > The driver operates the chip via I2C bus. Currently the LVDS clock are > > always derived from DSI clock lane, which is the usual mode of operation. > > Support for clock from external oscillator is not implemented, but it is > > easy to add if ever needed. Only RGB888 pixel format is implemented, the > > LVDS666 is not supported, but could be added if needed. > > > > Reviewed-by: Linus Walleij > > Reviewed-by: Frieder Schrempf > > Tested-by: Frieder Schrempf > > Tested-by: Adam Ford > > Signed-off-by: Marek Vasut > > Cc: Douglas Anderson > > Cc: Jagan Teki > > Cc: Laurent Pinchart > > Cc: Linus Walleij > > Cc: Loic Poulain > > Cc: Philippe Schenker > > Cc: Sam Ravnborg > > Cc: Stephen Boyd > > Cc: Valentin Raevsky > > To: dri-devel@lists.freedesktop.org > > --- > > V2: - Use dev_err_probe() > > - Set REG_RC_RESET as volatile > > - Wait for PLL stabilization by polling REG_RC_LVDS_PLL > > - Use ctx->mode = *adj instead of *mode in sn65dsi83_mode_set > > - Add tested DSI84 support in dual-link mode > > - Correctly set VCOM > > - Fill in missing DSI CHB and LVDS CHB bits from DSI84 and DSI85 > > datasheets, with that all the reserved bits make far more sense > > as the DSI83 and DSI84 seems to be reduced version of DSI85 > > V3: - Handle the dual-link LVDS with two port panel or bridge > > V4: - Add RB from Linus Walleij > > - Rename REG_DSI_LANE_LVDS_LINK_CFG_DUAL to > > REG_DSI_LANE_DSI_CHANNEL_MODE_SINGLE and fill in the remaining > > DSI link options from DSI85 datasheet. DSI85 can do dual and 2x > > single DSI mode, but DSI85 is currently unsupported by the > > driver. Add a comment about DSI85, so that all the places which > > need to be adjusted for DSI85 are marked accordingly. > > - Add REG_DSI_LANE_LEFT_RIGHT_PIXELS bit for DSI > > - Add handling for JEIDA18/JEIDA24/SPWG24 LVDS formats. Use SPWG24 > > as fallback on output bridges until they are all fixed. > > - Patch DSI bus format to fixed RGB888_1X24 instead of passing > > through the LVDS bus format. > > V5: - Move bus format patching to mode_fixup > > - Use cpu_to_le16() to guarantee endianness in regmap_bulk_write() > > V6: - Cast of_device_get_match_data() output to uintptr_t first > > --- > > drivers/gpu/drm/bridge/Kconfig| 10 + > > drivers/gpu/drm/bridge/Makefile | 1 + > > drivers/gpu/drm/bridge/ti-sn65dsi83.c | 709 ++ > > 3 files changed, 720 insertions(+) > > create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c > > > > Looks complete & well reviewed, LGTM > > Rob, Laurent ? is it ok for you ? No objection. -- Regards, Laurent Pinchart
Re: [PATCH] drm/ttm: fix pipelined gutting v2
On 6/8/21 10:19 AM, Christian König wrote: We need to make sure to allocate the sys_mem resource before the point of no return. v2: add missing return value checking, also handle idle case Signed-off-by: Christian König lgtm. Reviewed-by: Thomas Hellström
Re: [PATCH 03/13] drm/i915/guc: Update CTB response status definition
On 08.06.2021 02:05, Daniele Ceraolo Spurio wrote:
>
>
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
>> From: Michal Wajdeczko
>>
>> Format of the STATUS dword in CTB response message now follows
>> definition of the HXG header. Update our code and remove any
>> obsolete legacy definitions.
>
> This is kind of hard to review on its own against the specs, because
> there are larger changes to the CTB flows which AFAICS are part of patch
> 8. If what you wanted to do here was a simple replacement of defines to
> keep the later patch simpler, then, considering all patches are going to
> be squashed anyway:
>
> Reviewed-by: Daniele Ceraolo Spurio
>
> One suggestion below.
>
>>
>> GuC: 55.0.0
>> Signed-off-by: Michal Wajdeczko
>> Acked-by: Piotr Piórkowski
>> ---
>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 14 --
>> drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 17 -
>> 2 files changed, 8 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> index 8f7b148fef58..3f7f48611487 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> @@ -477,7 +477,9 @@ static int wait_for_ct_request_update(struct
>> ct_request *req, u32 *status)
>> * up to that length of time, then switch to a slower sleep-wait
>> loop.
>> * No GuC command should ever take longer than 10ms.
>> */
>> -#define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
>> +#define done \
>> + (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) == \
>> + GUC_HXG_ORIGIN_GUC)
>> err = wait_for_us(done, 10);
>> if (err)
>> err = wait_for(done, 10);
>> @@ -532,21 +534,21 @@ static int ct_send(struct intel_guc_ct *ct,
>> if (unlikely(err))
>> goto unlink;
>> - if (!INTEL_GUC_MSG_IS_RESPONSE_SUCCESS(*status)) {
>> + if (FIELD_GET(GUC_HXG_MSG_0_TYPE, *status) !=
>> GUC_HXG_TYPE_RESPONSE_SUCCESS) {
>> err = -EIO;
>> goto unlink;
>> }
>> if (response_buf) {
>> /* There shall be no data in the status */
>> - WARN_ON(INTEL_GUC_MSG_TO_DATA(request.status));
>> + WARN_ON(FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0,
>> request.status));
>> /* Return actual response len */
>> err = request.response_len;
>> } else {
>> /* There shall be no response payload */
>> WARN_ON(request.response_len);
>> /* Return data decoded from the status dword */
>> - err = INTEL_GUC_MSG_TO_DATA(*status);
>> + err = FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, *status);
>
> Given that the same FIELD_GET() are repeated multiple times, IMO we
> could've kept some helper macros, something like:
>
> INTEL_GUC_HXG_RESPONSE_TO_DATA(hxg) \
> FIELD_GET(GUC_HXG_RESPONSE_MSG_0_DATA0, hxg)
>
> INTEL_GUC_HXG_ORIGIN_IS_GUC(hxg) \
> (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, hxg) == GUC_HXG_ORIGIN_GUC)
>
> INTEL_GUC_HXG_TYPE(hxg) \
> FIELD_GET(GUC_HXG_MSG_0_TYPE, hxg)
>
> Which could be useful in the mmio code as well.
> Not sure how this changes in patch 8 though, I might put some more
> comments on that patch.
sure, we can add some of above helper macros, but not part of the ABI
definitions, but in fwif.h where we have other wrappers
and better to add them later as optional improvement, when all
refactoring dust settles down
>
> Daniele
>
>> }
>> unlink:
>> @@ -741,8 +743,8 @@ static int ct_handle_response(struct intel_guc_ct
>> *ct, struct ct_incoming_msg *r
>> status = response->msg[2];
>> datalen = len - 2;
>> - /* Format of the status follows RESPONSE message */
>> - if (unlikely(!INTEL_GUC_MSG_IS_RESPONSE(status))) {
>> + /* Format of the status dword follows HXG header */
>> + if (unlikely(FIELD_GET(GUC_HXG_MSG_0_ORIGIN, status) !=
>> GUC_HXG_ORIGIN_GUC)) {
>> CT_ERROR(ct, "Corrupted response (status %#x)\n", status);
>> return -EPROTO;
>> }
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
>> index e9a9d85e2aa3..fb04e2211b79 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
>> @@ -414,23 +414,6 @@ struct guc_shared_ctx_data {
>> struct guc_ctx_report preempt_ctx_report[GUC_MAX_ENGINES_NUM];
>> } __packed;
>> -#define __INTEL_GUC_MSG_GET(T, m) \
>> - (((m) & INTEL_GUC_MSG_ ## T ## _MASK) >> INTEL_GUC_MSG_ ## T ##
>> _SHIFT)
>> -#define INTEL_GUC_MSG_TO_TYPE(m) __INTEL_GUC_MSG_GET(TYPE, m)
>> -#define INTEL_GUC_MSG_TO_DATA(m) __INTEL_GUC_MSG_GET(DATA, m)
>> -#define INTEL_GUC_MSG_TO_CODE(m) __INTEL_GUC_MSG_GET(CODE, m)
>> -
>> -#define __INTEL_GUC_MSG_TYPE_IS(T, m) \
>> - (INTEL_GUC_MSG_TO_TYPE(m) == INTEL_GUC_MSG_TYPE_ ## T)
>> -#define INTEL_GUC_MSG_IS_REQUEST(m)
>> __INTEL_GUC_MSG_TYPE_IS(REQUE
Re: [PATCH 02/21] drm: Add Plane Degamma Mode property
On Mon, 7 Jun 2021 17:34:06 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: Harry Wentland
> > Sent: Friday, June 4, 2021 11:54 PM
> > To: Shankar, Uma ; intel-...@lists.freedesktop.org;
> > dri-
> > de...@lists.freedesktop.org
> > Cc: Modem, Bhanuprakash ; Cyr, Aric
> >
> > Subject: Re: [PATCH 02/21] drm: Add Plane Degamma Mode property
> >
> > On 2021-06-01 6:51 a.m., Uma Shankar wrote:
> > > Add Plane Degamma Mode as an enum property. Create a helper function
> > > for all plane color management features.
> > >
> > > This is an enum property with values as blob_id's and exposes the
> > > various gamma modes supported and the lut ranges. Getting the blob id
> > > in userspace, user can get the mode supported and also the range of
> > > gamma mode supported with number of lut coefficients. It can then set
> > > one of the modes using this enum property.
> > >
> > > Lut values will be sent through separate GAMMA_LUT blob property.
> > >
> > > Signed-off-by: Uma Shankar
> > > ---
> > > Documentation/gpu/drm-kms.rst | 90 ++
> > > drivers/gpu/drm/drm_atomic.c | 1 +
> > > drivers/gpu/drm/drm_atomic_state_helper.c | 2 +
> > > drivers/gpu/drm/drm_atomic_uapi.c | 4 +
> > > drivers/gpu/drm/drm_color_mgmt.c | 93 ++-
> > > include/drm/drm_mode_object.h | 2 +-
> > > include/drm/drm_plane.h | 23 ++
> > > 7 files changed, 212 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/Documentation/gpu/drm-kms.rst
> > > b/Documentation/gpu/drm-kms.rst index 87e5023e3f55..752be545e7d7
> > > 100644
> > > --- a/Documentation/gpu/drm-kms.rst
> > > +++ b/Documentation/gpu/drm-kms.rst
> > > @@ -514,9 +514,99 @@ Damage Tracking Properties Color Management
> > > Properties
> > > ---
> > >
> > > +Below is how a typical hardware pipeline for color will look like:
> > > +
> > > +.. kernel-render:: DOT
> > > + :alt: Display Color Pipeline
> > > + :caption: Display Color Pipeline Overview
> > > +
> > > + digraph "KMS" {
> > > + node [shape=box]
> > > +
> > > + subgraph cluster_static {
> > > + style=dashed
> > > + label="Display Color Hardware Blocks"
> > > +
> > > + node [bgcolor=grey style=filled]
> > > + "Plane Degamma A" -> "Plane CSC/CTM A"
> > > + "Plane CSC/CTM A" -> "Plane Gamma A"
> > > + "Pipe Blender" [color=lightblue,style=filled, width=5.25,
> > > height=0.75];
> > > + "Plane Gamma A" -> "Pipe Blender"
> > > + "Pipe Blender" -> "Pipe DeGamma"
> > > + "Pipe DeGamma" -> "Pipe CSC/CTM"
> > > + "Pipe CSC/CTM" -> "Pipe Gamma"
> > > + "Pipe Gamma" -> "Pipe Output"
> > > + }
> > > +
> >
> > It might be worthwhile to also highlight the YCbCr coefficient matrix in
> > the pipeline,
> > between the FB and Plane degamma, i.e.
> > YCbCr coefficients > plane degamma > csc > ...
> >
> > One problem with this view is that not all HW will support all (or any) of
> > these CM
> > blocks on all planes. For example, on AMD HW cursors are very different
> > from other
> > planes and don't really have full CM support.
> >
> > > + subgraph cluster_static {
> > > + style=dashed
> > > +
> > > + node [shape=box]
> > > + "Plane Degamma B" -> "Plane CSC/CTM B"
> > > + "Plane CSC/CTM B" -> "Plane Gamma B"
> > > + "Plane Gamma B" -> "Pipe Blender"
> > > + }
> > > +
> > > + subgraph cluster_static {
> > > + style=dashed
> > > +
> > > + node [shape=box]
> > > + "Plane Degamma C" -> "Plane CSC/CTM C"
> > > + "Plane CSC/CTM C" -> "Plane Gamma C"
> > > + "Plane Gamma C" -> "Pipe Blender"
> > > + }
> > > +
> > > + subgraph cluster_fb {
> > > + style=dashed
> > > + label="RAM"
> > > +
> > > + node [shape=box width=1.7 height=0.2]
> > > +
> > > + "FB 1" -> "Plane Degamma A"
> > > + "FB 2" -> "Plane Degamma B"
> > > + "FB 3" -> "Plane Degamma C"
> > > + }
> > > + }
> > > +
> > > +In real world usecases,
> > > +
> > > +1. Plane Degamma can be used to linearize a non linear gamma encoded
> > > +framebuffer. This is needed to do any linear math like color space
> > > +conversion. For ex, linearize frames encoded in SRGB or by HDR curve.
> > > +
> > > +2. Later Plane CTM block can convert the content to some different
> > > +colorspace. For ex, SRGB to BT2020 etc.
> > > +
> > > +3. Plane Gamma block can be used later to re-apply the non-linear
> > > +curve. This can also be used to apply Tone Mapping for HDR usecases.
> > > +
> >
> > This would mean you're blending in gamma space which is likely not what most
> > compositors expect. There are numerous articles that describe why blending
> > in
> > gamma space is problematic, such as [1]
> >
> > [1] https://ninedegreesbelow.com/photog
Re: [Intel-gfx] [RFC PATCH 36/97] drm/i915/guc: Add non blocking CTB send function
On 07/06/2021 18:31, Matthew Brost wrote:
On Thu, May 27, 2021 at 04:11:50PM +0100, Tvrtko Ursulin wrote:
On 27/05/2021 15:35, Matthew Brost wrote:
On Thu, May 27, 2021 at 11:02:24AM +0100, Tvrtko Ursulin wrote:
On 26/05/2021 19:10, Matthew Brost wrote:
[snip]
+static int ct_send_nb(struct intel_guc_ct *ct,
+ const u32 *action,
+ u32 len,
+ u32 flags)
+{
+ struct intel_guc_ct_buffer *ctb = &ct->ctbs.send;
+ unsigned long spin_flags;
+ u32 fence;
+ int ret;
+
+ spin_lock_irqsave(&ctb->lock, spin_flags);
+
+ ret = ctb_has_room(ctb, len + 1);
+ if (unlikely(ret))
+ goto out;
+
+ fence = ct_get_next_fence(ct);
+ ret = ct_write(ct, action, len, fence, flags);
+ if (unlikely(ret))
+ goto out;
+
+ intel_guc_notify(ct_to_guc(ct));
+
+out:
+ spin_unlock_irqrestore(&ctb->lock, spin_flags);
+
+ return ret;
+}
+
static int ct_send(struct intel_guc_ct *ct,
const u32 *action,
u32 len,
@@ -473,6 +541,7 @@ static int ct_send(struct intel_guc_ct *ct,
u32 response_buf_size,
u32 *status)
{
+ struct intel_guc_ct_buffer *ctb = &ct->ctbs.send;
struct ct_request request;
unsigned long flags;
u32 fence;
@@ -482,8 +551,20 @@ static int ct_send(struct intel_guc_ct *ct,
GEM_BUG_ON(!len);
GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
GEM_BUG_ON(!response_buf && response_buf_size);
+ might_sleep();
Sleep is just cond_resched below or there is more?
Yes, the cond_resched.
+ /*
+* We use a lazy spin wait loop here as we believe that if the CT
+* buffers are sized correctly the flow control condition should be
+* rare.
+*/
+retry:
spin_lock_irqsave(&ct->ctbs.send.lock, flags);
+ if (unlikely(!ctb_has_room(ctb, len + 1))) {
+ spin_unlock_irqrestore(&ct->ctbs.send.lock, flags);
+ cond_resched();
+ goto retry;
+ }
If this patch is about adding a non-blocking send function, and below we can
see that it creates a fork:
intel_guc_ct_send:
...
if (flags & INTEL_GUC_SEND_NB)
return ct_send_nb(ct, action, len, flags);
ret = ct_send(ct, action, len, response_buf, response_buf_size,
&status);
Then why is there a change in ct_send here, which is not the new
non-blocking path?
There is not a change to ct_send(), just to intel_guc_ct_send.
I was doing by the diff which says:
static int ct_send(struct intel_guc_ct *ct,
const u32 *action,
u32 len,
@@ -473,6 +541,7 @@ static int ct_send(struct intel_guc_ct *ct,
u32 response_buf_size,
u32 *status)
{
+ struct intel_guc_ct_buffer *ctb = &ct->ctbs.send;
struct ct_request request;
unsigned long flags;
u32 fence;
@@ -482,8 +551,20 @@ static int ct_send(struct intel_guc_ct *ct,
GEM_BUG_ON(!len);
GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
GEM_BUG_ON(!response_buf && response_buf_size);
+ might_sleep();
+ /*
+* We use a lazy spin wait loop here as we believe that if the CT
+* buffers are sized correctly the flow control condition should be
+* rare.
+*/
+retry:
spin_lock_irqsave(&ct->ctbs.send.lock, flags);
+ if (unlikely(!ctb_has_room(ctb, len + 1))) {
+ spin_unlock_irqrestore(&ct->ctbs.send.lock, flags);
+ cond_resched();
+ goto retry;
+ }
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?
Yes, ct_send() changes. Sorry for the confusion.
This function needs to be updated to account for the H2G space and
backoff if no space is available.
Since this one is the sleeping path, it probably can and needs to be smarter
than having a cond_resched busy loop added. Like sleep and get woken up when
there is space. Otherwise it can degenerate to busy looping via contention
with the non-blocking path.
That screams over enginerring a simple problem to me. If the CT channel
is full we are really in trouble anyways - i.e. the performance is going
to terrible as we overwhelmed the GuC with traffic. That being said,
Performance of what would be terrible? Something relating to submitting
new jobs to the GPU I guess. Or something SRIOV related as you hint below.
But there is no real reason why CPU cycles/power should suffer if GuC is
busy.
Okay, if it can't happen in real world then it's possibly passable as a
design of a communication interface. But to me it leaves a bad taste and
a doubt that there is this other aspect of the real world. And that is
when the unexpected happens. Even the most trivial things like
[PATCH v2 0/6] Add back the buddy allocator
Needs to be applied on top of: https://patchwork.freedesktop.org/series/90681/ Matthew Auld (5): drm/i915/ttm: add ttm_buddy_man drm/i915/ttm: add i915_sg_from_buddy_resource drm/i915/ttm: pass along the I915_BO_ALLOC_CONTIGUOUS drm/i915/ttm: switch over to ttm_buddy_man drm/i915/ttm: restore min_page_size behaviour Thomas Hellström (1): drm/i915/ttm: Calculate the object placement at get_pages time drivers/gpu/drm/i915/Makefile | 2 + drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 102 ++- drivers/gpu/drm/i915/i915_buddy.c | 412 + drivers/gpu/drm/i915/i915_buddy.h | 133 +++ drivers/gpu/drm/i915/i915_scatterlist.c | 80 ++ drivers/gpu/drm/i915/i915_scatterlist.h | 5 + drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 248 ++ drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 56 ++ drivers/gpu/drm/i915/intel_memory_region.c| 55 +- drivers/gpu/drm/i915/intel_memory_region.h| 20 +- drivers/gpu/drm/i915/intel_region_ttm.c | 108 +-- drivers/gpu/drm/i915/intel_region_ttm.h | 2 + drivers/gpu/drm/i915/selftests/i915_buddy.c | 789 ++ .../drm/i915/selftests/intel_memory_region.c | 170 ++-- drivers/gpu/drm/i915/selftests/mock_region.c | 17 +- 15 files changed, 1969 insertions(+), 230 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_buddy.c create mode 100644 drivers/gpu/drm/i915/i915_buddy.h create mode 100644 drivers/gpu/drm/i915/i915_ttm_buddy_manager.c create mode 100644 drivers/gpu/drm/i915/i915_ttm_buddy_manager.h create mode 100644 drivers/gpu/drm/i915/selftests/i915_buddy.c -- 2.26.3
[PATCH v2 1/6] drm/i915/ttm: add ttm_buddy_man
Add back our standalone i915_buddy allocator and integrate it into a
ttm_resource_manager. This will plug into our ttm backend for managing
device local-memory in the next couple of patches.
v2(Thomas):
- Return -ENOSPC from the buddy; ttm expects this in order to
trigger eviction
- Drop the unnecessary inline
- bo->page_alignment is in page units
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Acked-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 2 +
drivers/gpu/drm/i915/i915_buddy.c | 412 +
drivers/gpu/drm/i915/i915_buddy.h | 133 +++
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 248 ++
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 56 ++
drivers/gpu/drm/i915/selftests/i915_buddy.c | 789 ++
6 files changed, 1640 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_buddy.c
create mode 100644 drivers/gpu/drm/i915/i915_buddy.h
create mode 100644 drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
create mode 100644 drivers/gpu/drm/i915/i915_ttm_buddy_manager.h
create mode 100644 drivers/gpu/drm/i915/selftests/i915_buddy.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f57dfc74d6ce..6c84e96ab26a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -162,6 +162,7 @@ gem-y += \
i915-y += \
$(gem-y) \
i915_active.o \
+ i915_buddy.o \
i915_cmd_parser.o \
i915_gem_evict.o \
i915_gem_gtt.o \
@@ -171,6 +172,7 @@ i915-y += \
i915_request.o \
i915_scheduler.o \
i915_trace_points.o \
+ i915_ttm_buddy_manager.o \
i915_vma.o \
intel_wopcm.o
diff --git a/drivers/gpu/drm/i915/i915_buddy.c
b/drivers/gpu/drm/i915/i915_buddy.c
new file mode 100644
index ..29dd7d0310c1
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_buddy.c
@@ -0,0 +1,412 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include
+
+#include "i915_buddy.h"
+
+#include "i915_gem.h"
+#include "i915_utils.h"
+
+static struct i915_buddy_block *i915_block_alloc(struct i915_buddy_mm *mm,
+struct i915_buddy_block
*parent,
+unsigned int order,
+u64 offset)
+{
+ struct i915_buddy_block *block;
+
+ GEM_BUG_ON(order > I915_BUDDY_MAX_ORDER);
+
+ block = kmem_cache_zalloc(mm->slab_blocks, GFP_KERNEL);
+ if (!block)
+ return NULL;
+
+ block->header = offset;
+ block->header |= order;
+ block->parent = parent;
+
+ GEM_BUG_ON(block->header & I915_BUDDY_HEADER_UNUSED);
+ return block;
+}
+
+static void i915_block_free(struct i915_buddy_mm *mm,
+ struct i915_buddy_block *block)
+{
+ kmem_cache_free(mm->slab_blocks, block);
+}
+
+static void mark_allocated(struct i915_buddy_block *block)
+{
+ block->header &= ~I915_BUDDY_HEADER_STATE;
+ block->header |= I915_BUDDY_ALLOCATED;
+
+ list_del(&block->link);
+}
+
+static void mark_free(struct i915_buddy_mm *mm,
+ struct i915_buddy_block *block)
+{
+ block->header &= ~I915_BUDDY_HEADER_STATE;
+ block->header |= I915_BUDDY_FREE;
+
+ list_add(&block->link,
+&mm->free_list[i915_buddy_block_order(block)]);
+}
+
+static void mark_split(struct i915_buddy_block *block)
+{
+ block->header &= ~I915_BUDDY_HEADER_STATE;
+ block->header |= I915_BUDDY_SPLIT;
+
+ list_del(&block->link);
+}
+
+int i915_buddy_init(struct i915_buddy_mm *mm, u64 size, u64 chunk_size)
+{
+ unsigned int i;
+ u64 offset;
+
+ if (size < chunk_size)
+ return -EINVAL;
+
+ if (chunk_size < PAGE_SIZE)
+ return -EINVAL;
+
+ if (!is_power_of_2(chunk_size))
+ return -EINVAL;
+
+ size = round_down(size, chunk_size);
+
+ mm->size = size;
+ mm->chunk_size = chunk_size;
+ mm->max_order = ilog2(size) - ilog2(chunk_size);
+
+ GEM_BUG_ON(mm->max_order > I915_BUDDY_MAX_ORDER);
+
+ mm->slab_blocks = KMEM_CACHE(i915_buddy_block, SLAB_HWCACHE_ALIGN);
+ if (!mm->slab_blocks)
+ return -ENOMEM;
+
+ mm->free_list = kmalloc_array(mm->max_order + 1,
+ sizeof(struct list_head),
+ GFP_KERNEL);
+ if (!mm->free_list)
+ goto out_destroy_slab;
+
+ for (i = 0; i <= mm->max_order; ++i)
+ INIT_LIST_HEAD(&mm->free_list[i]);
+
+ mm->n_roots = hweight64(size);
+
+ mm->roots = kmalloc_array(mm->n_roots,
+ sizeof(struct i915_buddy_block *),
+ GFP_KERNEL);
+ if (!mm->roots)
+ goto out_free_list;
+
+
[PATCH v2 2/6] drm/i915/ttm: add i915_sg_from_buddy_resource
We need to be able to build an sg table from our list of buddy blocks,
so that we can later plug this into our ttm backend, and replace our use
of the range manager.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_scatterlist.c | 80 +
drivers/gpu/drm/i915/i915_scatterlist.h | 5 ++
2 files changed, 85 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.c
b/drivers/gpu/drm/i915/i915_scatterlist.c
index 69e9e6c3135e..0959fe3efbbb 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.c
+++ b/drivers/gpu/drm/i915/i915_scatterlist.c
@@ -6,6 +6,9 @@
#include "i915_scatterlist.h"
+#include "i915_buddy.h"
+#include "i915_ttm_buddy_manager.h"
+
#include
#include
@@ -104,6 +107,83 @@ struct sg_table *i915_sg_from_mm_node(const struct
drm_mm_node *node,
return st;
}
+/**
+ * i915_sg_from_buddy_resource - Create an sg_table from a struct
+ * i915_buddy_block list
+ * @res: The i915_ttm_buddy_resource.
+ * @region_start: An offset to add to the dma addresses of the sg list.
+ *
+ * Create a struct sg_table, initializing it from struct i915_buddy_block list,
+ * taking a maximum segment length into account, splitting into segments
+ * if necessary.
+ *
+ * Return: A pointer to a kmalloced struct sg_table on success, negative
+ * error code cast to an error pointer on failure.
+ */
+struct sg_table *i915_sg_from_buddy_resource(struct ttm_resource *res,
+u64 region_start)
+{
+ struct i915_ttm_buddy_resource *bman_res = to_ttm_buddy_resource(res);
+ struct i915_buddy_mm *mm = bman_res->mm;
+ const u64 size = res->num_pages << PAGE_SHIFT;
+ const u64 max_segment = UINT_MAX;
+ struct list_head *blocks = &bman_res->blocks;
+ struct i915_buddy_block *block;
+ struct scatterlist *sg;
+ struct sg_table *st;
+ resource_size_t prev_end;
+
+ GEM_BUG_ON(list_empty(blocks));
+
+ st = kmalloc(sizeof(*st), GFP_KERNEL);
+ if (!st)
+ return ERR_PTR(-ENOMEM);
+
+ if (sg_alloc_table(st, size >> PAGE_SHIFT, GFP_KERNEL)) {
+ kfree(st);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ sg = st->sgl;
+ st->nents = 0;
+ prev_end = (resource_size_t)-1;
+
+ list_for_each_entry(block, blocks, link) {
+ u64 block_size, offset;
+
+ block_size = min_t(u64, size, i915_buddy_block_size(mm, block));
+ offset = i915_buddy_block_offset(block);
+
+ while (block_size) {
+ u64 len;
+
+ if (offset != prev_end || sg->length >= max_segment) {
+ if (st->nents)
+ sg = __sg_next(sg);
+
+ sg_dma_address(sg) = region_start + offset;
+ sg_dma_len(sg) = 0;
+ sg->length = 0;
+ st->nents++;
+ }
+
+ len = min(block_size, max_segment - sg->length);
+ sg->length += len;
+ sg_dma_len(sg) += len;
+
+ offset += len;
+ block_size -= len;
+
+ prev_end = offset;
+ }
+ }
+
+ sg_mark_end(sg);
+ i915_sg_trim(st);
+
+ return st;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/scatterlist.c"
#endif
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
b/drivers/gpu/drm/i915/i915_scatterlist.h
index 5acca45ea981..b8bd5925b03f 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.h
+++ b/drivers/gpu/drm/i915/i915_scatterlist.h
@@ -14,6 +14,7 @@
#include "i915_gem.h"
struct drm_mm_node;
+struct ttm_resource;
/*
* Optimised SGL iterator for GEM objects
@@ -145,4 +146,8 @@ bool i915_sg_trim(struct sg_table *orig_st);
struct sg_table *i915_sg_from_mm_node(const struct drm_mm_node *node,
u64 region_start);
+
+struct sg_table *i915_sg_from_buddy_resource(struct ttm_resource *res,
+u64 region_start);
+
#endif
--
2.26.3
[PATCH v2 3/6] drm/i915/ttm: Calculate the object placement at get_pages time
From: Thomas Hellström
Instead of relying on a static placement, calculate at get_pages() time.
This should work for LMEM regions and system for now. For stolen we need
to take preallocated range into account. That well be added later.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 69 +
drivers/gpu/drm/i915/intel_region_ttm.c | 8 ++-
drivers/gpu/drm/i915/intel_region_ttm.h | 2 +
3 files changed, 68 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 9dd6e4f69d53..73d52df8f2be 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -24,6 +24,11 @@
#define I915_TTM_PRIO_NO_PAGES 1
#define I915_TTM_PRIO_HAS_PAGES 2
+/*
+ * Size of struct ttm_place vector in on-stack struct ttm_placement allocs
+ */
+#define I915_TTM_MAX_PLACEMENTS 10
+
/**
* struct i915_ttm_tt - TTM page vector with additional private information
* @ttm: The base TTM page vector.
@@ -56,13 +61,6 @@ static const struct ttm_place lmem0_sys_placement_flags[] = {
}
};
-static struct ttm_placement i915_lmem0_placement = {
- .num_placement = 1,
- .placement = &lmem0_sys_placement_flags[0],
- .num_busy_placement = 1,
- .busy_placement = &lmem0_sys_placement_flags[0],
-};
-
static struct ttm_placement i915_sys_placement = {
.num_placement = 1,
.placement = &lmem0_sys_placement_flags[1],
@@ -72,6 +70,55 @@ static struct ttm_placement i915_sys_placement = {
static void i915_ttm_adjust_lru(struct drm_i915_gem_object *obj);
+static enum ttm_caching
+i915_ttm_select_tt_caching(const struct drm_i915_gem_object *obj)
+{
+ /*
+* Objects only allowed in system get cached cpu-mappings.
+* Other objects get WC mapping for now. Even if in system.
+*/
+ if (obj->mm.region->type == INTEL_MEMORY_SYSTEM &&
+ obj->mm.n_placements <= 1)
+ return ttm_cached;
+
+ return ttm_write_combined;
+}
+
+static void
+i915_ttm_place_from_region(const struct intel_memory_region *mr,
+ struct ttm_place *place)
+{
+ memset(place, 0, sizeof(*place));
+ place->mem_type = intel_region_to_ttm_type(mr);
+}
+
+static void
+i915_ttm_placement_from_obj(const struct drm_i915_gem_object *obj,
+ struct ttm_place *requested,
+ struct ttm_place *busy,
+ struct ttm_placement *placement)
+{
+ unsigned int i;
+ unsigned int num_allowed = obj->mm.n_placements;
+
+ placement->num_placement = 1;
+ i915_ttm_place_from_region(num_allowed ? obj->mm.placements[0] :
+ obj->mm.region, requested);
+
+ /* Cache this on object? */
+ placement->num_busy_placement = num_allowed;
+ for (i = 0; i < placement->num_busy_placement; ++i)
+ i915_ttm_place_from_region(obj->mm.placements[i], busy + i);
+
+ if (num_allowed == 0) {
+ *busy = *requested;
+ placement->num_busy_placement = 1;
+ }
+
+ placement->placement = requested;
+ placement->busy_placement = busy;
+}
+
static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
uint32_t page_flags)
{
@@ -89,7 +136,8 @@ static struct ttm_tt *i915_ttm_tt_create(struct
ttm_buffer_object *bo,
man->use_tt)
page_flags |= TTM_PAGE_FLAG_ZERO_ALLOC;
- ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags, ttm_write_combined);
+ ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags,
+ i915_ttm_select_tt_caching(obj));
if (ret) {
kfree(i915_tt);
return NULL;
@@ -414,10 +462,13 @@ static int i915_ttm_get_pages(struct drm_i915_gem_object
*obj)
.no_wait_gpu = false,
};
struct sg_table *st;
+ struct ttm_place requested, busy[I915_TTM_MAX_PLACEMENTS];
+ struct ttm_placement placement;
int ret;
/* Move to the requested placement. */
- ret = ttm_bo_validate(bo, &i915_lmem0_placement, &ctx);
+ i915_ttm_placement_from_obj(obj, &requested, busy, &placement);
+ ret = ttm_bo_validate(bo, &placement, &ctx);
if (ret)
return ret == -ENOSPC ? -ENXIO : ret;
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 27fe0668d094..5a664f6cc93f 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -50,12 +50,16 @@ void intel_region_ttm_device_fini(struct drm_i915_private
*dev_priv)
* driver-private types for now, reserving TTM_PL_VRAM for stolen
* memory and TTM_PL_TT for GGTT use if decided to implement this.
*/
-static int intel_region_to_ttm_type(struct intel_memory_region *mem)
+
[PATCH v2 4/6] drm/i915/ttm: pass along the I915_BO_ALLOC_CONTIGUOUS
Currently we just ignore the I915_BO_ALLOC_CONTIGUOUS flag, which is
fine since everything is already contiguous with the ttm range manager.
However in the next patch we want to switch over to the ttm buddy
manager, where allocations are by default not contiguous.
v2(Thomas):
- Forward ALLOC_CONTIG for all regions
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 73d52df8f2be..c612275c36c9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -86,10 +86,14 @@ i915_ttm_select_tt_caching(const struct drm_i915_gem_object
*obj)
static void
i915_ttm_place_from_region(const struct intel_memory_region *mr,
- struct ttm_place *place)
+ struct ttm_place *place,
+ unsigned int flags)
{
memset(place, 0, sizeof(*place));
place->mem_type = intel_region_to_ttm_type(mr);
+
+ if (flags & I915_BO_ALLOC_CONTIGUOUS)
+ place->flags = TTM_PL_FLAG_CONTIGUOUS;
}
static void
@@ -100,15 +104,16 @@ i915_ttm_placement_from_obj(const struct
drm_i915_gem_object *obj,
{
unsigned int i;
unsigned int num_allowed = obj->mm.n_placements;
+ unsigned int flags = obj->flags;
placement->num_placement = 1;
i915_ttm_place_from_region(num_allowed ? obj->mm.placements[0] :
- obj->mm.region, requested);
+ obj->mm.region, requested, flags);
/* Cache this on object? */
placement->num_busy_placement = num_allowed;
for (i = 0; i < placement->num_busy_placement; ++i)
- i915_ttm_place_from_region(obj->mm.placements[i], busy + i);
+ i915_ttm_place_from_region(obj->mm.placements[i], busy + i,
flags);
if (num_allowed == 0) {
*busy = *requested;
--
2.26.3
[PATCH v2 5/6] drm/i915/ttm: switch over to ttm_buddy_man
Move back to the buddy allocator for managing device local memory, and
restore the lost mock selftests. Keep around the range manager related
bits, since we likely need this for managing stolen at some point. For
stolen we also don't need to reserve anything so no need to support a
generic reserve interface.
v2(Thomas):
- bo->page_alignment is in page units, not bytes
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 26 +--
drivers/gpu/drm/i915/intel_memory_region.c| 55 +-
drivers/gpu/drm/i915/intel_memory_region.h| 17 --
drivers/gpu/drm/i915/intel_region_ttm.c | 100 +++
.../drm/i915/selftests/intel_memory_region.c | 170 --
drivers/gpu/drm/i915/selftests/mock_region.c | 15 +-
6 files changed, 168 insertions(+), 215 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index c612275c36c9..5bf1d1945dd6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -181,11 +181,7 @@ static bool i915_ttm_eviction_valuable(struct
ttm_buffer_object *bo,
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
/* Will do for now. Our pinned objects are still on TTM's LRU lists */
- if (!i915_gem_object_evictable(obj))
- return false;
-
- /* This isn't valid with a buddy allocator */
- return ttm_bo_eviction_valuable(bo, place);
+ return i915_gem_object_evictable(obj);
}
static void i915_ttm_evict_flags(struct ttm_buffer_object *bo,
@@ -328,11 +324,15 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
struct ttm_resource_manager *man =
ttm_manager_type(bo->bdev, res->mem_type);
+ struct intel_memory_region *mr = obj->mm.region;
if (man->use_tt)
return i915_ttm_tt_get_st(bo->ttm);
- return intel_region_ttm_node_to_st(obj->mm.region, res->mm_node);
+ if (mr->is_range_manager)
+ return intel_region_ttm_node_to_st(mr, res);
+ else
+ return i915_sg_from_buddy_resource(res, mr->region.start);
}
static int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
@@ -657,20 +657,8 @@ int __i915_gem_ttm_object_init(struct intel_memory_region
*mem,
static struct lock_class_key lock_class;
struct drm_i915_private *i915 = mem->i915;
enum ttm_bo_type bo_type;
- size_t alignment = 0;
int ret;
- /* Adjust alignment to GPU- and CPU huge page sizes. */
-
- if (mem->is_range_manager) {
- if (size >= SZ_1G)
- alignment = SZ_1G >> PAGE_SHIFT;
- else if (size >= SZ_2M)
- alignment = SZ_2M >> PAGE_SHIFT;
- else if (size >= SZ_64K)
- alignment = SZ_64K >> PAGE_SHIFT;
- }
-
drm_gem_private_object_init(&i915->drm, &obj->base, size);
i915_gem_object_init(obj, &i915_gem_ttm_obj_ops, &lock_class, flags);
i915_gem_object_init_memory_region(obj, mem);
@@ -692,7 +680,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region
*mem,
*/
obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
ret = ttm_bo_init(&i915->bdev, i915_gem_to_ttm(obj), size,
- bo_type, &i915_sys_placement, alignment,
+ bo_type, &i915_sys_placement, 1,
true, NULL, NULL, i915_ttm_bo_destroy);
if (!ret)
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
b/drivers/gpu/drm/i915/intel_memory_region.c
index 12fb5423fd5e..df59f884d37c 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -5,6 +5,7 @@
#include "intel_memory_region.h"
#include "i915_drv.h"
+#include "i915_ttm_buddy_manager.h"
static const struct {
u16 class;
@@ -28,11 +29,6 @@ static const struct {
},
};
-struct intel_region_reserve {
- struct list_head link;
- struct ttm_resource *res;
-};
-
struct intel_memory_region *
intel_memory_region_lookup(struct drm_i915_private *i915,
u16 class, u16 instance)
@@ -63,27 +59,6 @@ intel_memory_region_by_type(struct drm_i915_private *i915,
return NULL;
}
-/**
- * intel_memory_region_unreserve - Unreserve all previously reserved
- * ranges
- * @mem: The region containing the reserved ranges.
- */
-void intel_memory_region_unreserve(struct intel_memory_region *mem)
-{
- struct intel_region_reserve *reserve, *next;
-
- if (!mem->priv_ops || !mem->priv_ops->free)
- return;
-
- mutex_lock(&mem->mm_lock);
- list_for_each_entry_safe(reserve, next, &mem->reserved, link) {
- list_del(&reserve->link);
- mem->priv_ops-
[PATCH v2 6/6] drm/i915/ttm: restore min_page_size behaviour
We now have bo->page_alignment which perfectly describes what we need if
we have min page size restrictions for lmem. We can also drop the flag
here, since this is the default behaviour for all objects.
v2(Thomas):
- bo->page_alignment is in page units
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 4 ++--
drivers/gpu/drm/i915/intel_memory_region.h | 3 +--
drivers/gpu/drm/i915/intel_region_ttm.c | 2 +-
drivers/gpu/drm/i915/selftests/mock_region.c | 2 +-
4 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 5bf1d1945dd6..3df73c79aa19 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -680,9 +680,9 @@ int __i915_gem_ttm_object_init(struct intel_memory_region
*mem,
*/
obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
ret = ttm_bo_init(&i915->bdev, i915_gem_to_ttm(obj), size,
- bo_type, &i915_sys_placement, 1,
+ bo_type, &i915_sys_placement,
+ mem->min_page_size >> PAGE_SHIFT,
true, NULL, NULL, i915_ttm_bo_destroy);
-
if (!ret)
obj->ttm.created = true;
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h
b/drivers/gpu/drm/i915/intel_memory_region.h
index b04fb22726d9..2be8433d373a 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -40,8 +40,7 @@ enum intel_region_id {
#define REGION_STOLEN_SMEM BIT(INTEL_REGION_STOLEN_SMEM)
#define REGION_STOLEN_LMEM BIT(INTEL_REGION_STOLEN_LMEM)
-#define I915_ALLOC_MIN_PAGE_SIZE BIT(0)
-#define I915_ALLOC_CONTIGUOUS BIT(1)
+#define I915_ALLOC_CONTIGUOUS BIT(0)
#define for_each_memory_region(mr, i915, id) \
for (id = 0; id < ARRAY_SIZE((i915)->mm.regions); id++) \
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 23a1336d2335..ad43ca90a46b 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -153,7 +153,7 @@ intel_region_ttm_node_alloc(struct intel_memory_region *mem,
int ret;
mock_bo.base.size = size;
- mock_bo.page_alignment = 1;
+ mock_bo.page_alignment = mem->min_page_size >> PAGE_SHIFT;
place.flags = flags;
ret = man->func->alloc(man, &mock_bo, &place, &res);
diff --git a/drivers/gpu/drm/i915/selftests/mock_region.c
b/drivers/gpu/drm/i915/selftests/mock_region.c
index d3e4e6573cb9..6ce0f9dacad7 100644
--- a/drivers/gpu/drm/i915/selftests/mock_region.c
+++ b/drivers/gpu/drm/i915/selftests/mock_region.c
@@ -28,7 +28,7 @@ static int mock_region_get_pages(struct drm_i915_gem_object
*obj)
struct sg_table *pages;
int err;
- flags = I915_ALLOC_MIN_PAGE_SIZE;
+ flags = 0;
if (obj->flags & I915_BO_ALLOC_CONTIGUOUS)
flags |= TTM_PL_FLAG_CONTIGUOUS;
--
2.26.3
Re: [Intel-gfx] [RFC PATCH 36/97] drm/i915/guc: Add non blocking CTB send function
On Tue, Jun 8, 2021 at 10:39 AM Tvrtko Ursulin
wrote:
>
>
> On 07/06/2021 18:31, Matthew Brost wrote:
> > On Thu, May 27, 2021 at 04:11:50PM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 27/05/2021 15:35, Matthew Brost wrote:
> >>> On Thu, May 27, 2021 at 11:02:24AM +0100, Tvrtko Ursulin wrote:
>
> On 26/05/2021 19:10, Matthew Brost wrote:
>
> [snip]
>
> > +static int ct_send_nb(struct intel_guc_ct *ct,
> > + const u32 *action,
> > + u32 len,
> > + u32 flags)
> > +{
> > + struct intel_guc_ct_buffer *ctb = &ct->ctbs.send;
> > + unsigned long spin_flags;
> > + u32 fence;
> > + int ret;
> > +
> > + spin_lock_irqsave(&ctb->lock, spin_flags);
> > +
> > + ret = ctb_has_room(ctb, len + 1);
> > + if (unlikely(ret))
> > + goto out;
> > +
> > + fence = ct_get_next_fence(ct);
> > + ret = ct_write(ct, action, len, fence, flags);
> > + if (unlikely(ret))
> > + goto out;
> > +
> > + intel_guc_notify(ct_to_guc(ct));
> > +
> > +out:
> > + spin_unlock_irqrestore(&ctb->lock, spin_flags);
> > +
> > + return ret;
> > +}
> > +
> > static int ct_send(struct intel_guc_ct *ct,
> > const u32 *action,
> > u32 len,
> > @@ -473,6 +541,7 @@ static int ct_send(struct intel_guc_ct *ct,
> > u32 response_buf_size,
> > u32 *status)
> > {
> > + struct intel_guc_ct_buffer *ctb = &ct->ctbs.send;
> > struct ct_request request;
> > unsigned long flags;
> > u32 fence;
> > @@ -482,8 +551,20 @@ static int ct_send(struct intel_guc_ct *ct,
> > GEM_BUG_ON(!len);
> > GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
> > GEM_BUG_ON(!response_buf && response_buf_size);
> > + might_sleep();
>
> Sleep is just cond_resched below or there is more?
>
> >>>
> >>> Yes, the cond_resched.
> >>>
> > + /*
> > + * We use a lazy spin wait loop here as we believe that if
> > the CT
> > + * buffers are sized correctly the flow control condition
> > should be
> > + * rare.
> > + */
> > +retry:
> > spin_lock_irqsave(&ct->ctbs.send.lock, flags);
> > + if (unlikely(!ctb_has_room(ctb, len + 1))) {
> > + spin_unlock_irqrestore(&ct->ctbs.send.lock, flags);
> > + cond_resched();
> > + goto retry;
> > + }
>
> If this patch is about adding a non-blocking send function, and
> below we can
> see that it creates a fork:
>
> intel_guc_ct_send:
> ...
> if (flags & INTEL_GUC_SEND_NB)
> return ct_send_nb(ct, action, len, flags);
>
> ret = ct_send(ct, action, len, response_buf,
> response_buf_size, &status);
>
> Then why is there a change in ct_send here, which is not the new
> non-blocking path?
>
> >>>
> >>> There is not a change to ct_send(), just to intel_guc_ct_send.
> >>
> >> I was doing by the diff which says:
> >>
> >> static int ct_send(struct intel_guc_ct *ct,
> >> const u32 *action,
> >> u32 len,
> >> @@ -473,6 +541,7 @@ static int ct_send(struct intel_guc_ct *ct,
> >> u32 response_buf_size,
> >> u32 *status)
> >> {
> >> +struct intel_guc_ct_buffer *ctb = &ct->ctbs.send;
> >> struct ct_request request;
> >> unsigned long flags;
> >> u32 fence;
> >> @@ -482,8 +551,20 @@ static int ct_send(struct intel_guc_ct *ct,
> >> GEM_BUG_ON(!len);
> >> GEM_BUG_ON(len & ~GUC_CT_MSG_LEN_MASK);
> >> GEM_BUG_ON(!response_buf && response_buf_size);
> >> +might_sleep();
> >> +/*
> >> + * We use a lazy spin wait loop here as we believe that if
> >> the CT
> >> + * buffers are sized correctly the flow control condition
> >> should be
> >> + * rare.
> >> + */
> >> +retry:
> >> spin_lock_irqsave(&ct->ctbs.send.lock, flags);
> >> +if (unlikely(!ctb_has_room(ctb, len + 1))) {
> >> +spin_unlock_irqrestore(&ct->ctbs.send.lock, flags);
> >> +
Re: [PATCH V6 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
Hey Neil, On Tue, 8 Jun 2021 at 10:10, Neil Armstrong wrote: > > Hi, > > On 07/06/2021 19:42, Marek Vasut wrote: > > Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge > > and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS > > bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on, > > but easy to add. > > > > The driver operates the chip via I2C bus. Currently the LVDS clock are > > always derived from DSI clock lane, which is the usual mode of operation. > > Support for clock from external oscillator is not implemented, but it is > > easy to add if ever needed. Only RGB888 pixel format is implemented, the > > LVDS666 is not supported, but could be added if needed. > > > > Reviewed-by: Linus Walleij > > Reviewed-by: Frieder Schrempf > > Tested-by: Frieder Schrempf > > Tested-by: Adam Ford > > Signed-off-by: Marek Vasut > > Cc: Douglas Anderson > > Cc: Jagan Teki > > Cc: Laurent Pinchart > > Cc: Linus Walleij > > Cc: Loic Poulain > > Cc: Philippe Schenker > > Cc: Sam Ravnborg > > Cc: Stephen Boyd > > Cc: Valentin Raevsky > > To: dri-devel@lists.freedesktop.org > > --- > > V2: - Use dev_err_probe() > > - Set REG_RC_RESET as volatile > > - Wait for PLL stabilization by polling REG_RC_LVDS_PLL > > - Use ctx->mode = *adj instead of *mode in sn65dsi83_mode_set > > - Add tested DSI84 support in dual-link mode > > - Correctly set VCOM > > - Fill in missing DSI CHB and LVDS CHB bits from DSI84 and DSI85 > > datasheets, with that all the reserved bits make far more sense > > as the DSI83 and DSI84 seems to be reduced version of DSI85 > > V3: - Handle the dual-link LVDS with two port panel or bridge > > V4: - Add RB from Linus Walleij > > - Rename REG_DSI_LANE_LVDS_LINK_CFG_DUAL to > > REG_DSI_LANE_DSI_CHANNEL_MODE_SINGLE and fill in the remaining > > DSI link options from DSI85 datasheet. DSI85 can do dual and 2x > > single DSI mode, but DSI85 is currently unsupported by the > > driver. Add a comment about DSI85, so that all the places which > > need to be adjusted for DSI85 are marked accordingly. > > - Add REG_DSI_LANE_LEFT_RIGHT_PIXELS bit for DSI > > - Add handling for JEIDA18/JEIDA24/SPWG24 LVDS formats. Use SPWG24 > > as fallback on output bridges until they are all fixed. > > - Patch DSI bus format to fixed RGB888_1X24 instead of passing > > through the LVDS bus format. > > V5: - Move bus format patching to mode_fixup > > - Use cpu_to_le16() to guarantee endianness in regmap_bulk_write() > > V6: - Cast of_device_get_match_data() output to uintptr_t first > > --- > > drivers/gpu/drm/bridge/Kconfig| 10 + > > drivers/gpu/drm/bridge/Makefile | 1 + > > drivers/gpu/drm/bridge/ti-sn65dsi83.c | 709 ++ > > 3 files changed, 720 insertions(+) > > create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c > > > > Looks complete & well reviewed, LGTM > > Rob, Laurent ? is it ok for you ? This does look like it is ready. I was just about to merge it, but found some checkpatch --strict formatting warnings. Do you mind fixing those in a real quick v7?
[PATCH] drm/vc4: fix vc4_atomic_commit_tail() logic
In vc4_atomic_commit_tail() we iterate of the set of old CRTCs, and attempt to wait on any channels which are still in use. When we iterate over the CRTCs, we have: * `i` - the index of the CRTC * `channel` - the channel a CRTC is using When we check the channel state, we consult: old_hvs_state->fifo_state[channel].in_use ... but when we wait for the channel, we erroneously wait on: old_hvs_state->fifo_state[i].pending_commit ... rather than: old_hvs_state->fifo_state[channel].pending_commit ... and this bogus access has been observed to result in boot-time hangs on some arm64 configurations, and can be detected using KASAN. FIx this by using the correct index. I've tested this on a Raspberry Pi 3 model B v1.2 with KASAN. Trimmed KASAN splat: | == | BUG: KASAN: slab-out-of-bounds in vc4_atomic_commit_tail+0x1cc/0x910 | Read of size 8 at addr 07360440 by task kworker/u8:0/7 | CPU: 2 PID: 7 Comm: kworker/u8:0 Not tainted 5.13.0-rc3-9-g694c523e7267 #3 | | Hardware name: Raspberry Pi 3 Model B (DT) | Workqueue: events_unbound deferred_probe_work_func | Call trace: | dump_backtrace+0x0/0x2b4 | show_stack+0x1c/0x30 | dump_stack+0xfc/0x168 | print_address_description.constprop.0+0x2c/0x2c0 | kasan_report+0x1dc/0x240 | __asan_load8+0x98/0xd4 | vc4_atomic_commit_tail+0x1cc/0x910 | commit_tail+0x100/0x210 | ... | | Allocated by task 7: | kasan_save_stack+0x2c/0x60 | __kasan_kmalloc+0x90/0xb4 | vc4_hvs_channels_duplicate_state+0x60/0x1a0 | drm_atomic_get_private_obj_state+0x144/0x230 | vc4_atomic_check+0x40/0x73c | drm_atomic_check_only+0x998/0xe60 | drm_atomic_commit+0x34/0x94 | drm_client_modeset_commit_atomic+0x2f4/0x3a0 | drm_client_modeset_commit_locked+0x8c/0x230 | drm_client_modeset_commit+0x38/0x60 | drm_fb_helper_set_par+0x104/0x17c | fbcon_init+0x43c/0x970 | visual_init+0x14c/0x1e4 | ... | | The buggy address belongs to the object at 07360400 | which belongs to the cache kmalloc-128 of size 128 | The buggy address is located 64 bytes inside of | 128-byte region [07360400, 07360480) | The buggy address belongs to the page: | page:(ptrval) refcount:1 mapcount:0 mapping: index:0x0 pfn:0x7360 | flags: 0x3fffc000200(slab|node=0|zone=0|lastcpupid=0x) | raw: 03fffc000200 dead0100 dead0122 04c02300 | raw: 00100010 0001 | page dumped because: kasan: bad access detected | | Memory state around the buggy address: | 07360300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb | 07360380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc | >07360400: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc |^ | 07360480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc | 07360500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb | == Link: https://lore.kernel.org/r/4d0c8318-bad8-2be7-e292-fc8f70c19...@samsung.com Link: https://lore.kernel.org/linux-arm-kernel/20210607151740.moncryl5zv3ahq4s@gilmour Signed-off-by: Mark Rutland Reported-by: Marek Szyprowski Cc: Arnd Bergmann Cc: Catalin Marinas Cc: Daniel Vetter Cc: David Airlie Cc: Emma Anholt Cc: Maxime Ripard Cc: Will Deacon Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/vc4/vc4_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c index bb5529a7a9c2..948b3a58aad1 100644 --- a/drivers/gpu/drm/vc4/vc4_kms.c +++ b/drivers/gpu/drm/vc4/vc4_kms.c @@ -372,7 +372,7 @@ static void vc4_atomic_commit_tail(struct drm_atomic_state *state) if (!old_hvs_state->fifo_state[channel].in_use) continue; - ret = drm_crtc_commit_wait(old_hvs_state->fifo_state[i].pending_commit); + ret = drm_crtc_commit_wait(old_hvs_state->fifo_state[channel].pending_commit); if (ret) drm_err(dev, "Timed out waiting for commit\n"); } -- 2.11.0
Re: [PATCH] arm64: cache: Lower ARCH_DMA_MINALIGN to 64 (L1_CACHE_BYTES)
On Mon, Jun 07, 2021 at 05:50:57PM +0200, Arnd Bergmann wrote:
> On Mon, Jun 7, 2021 at 5:17 PM Maxime Ripard wrote:
> > On Mon, Jun 07, 2021 at 03:57:41PM +0200, Arnd Bergmann wrote:
> > > On Mon, Jun 7, 2021 at 3:39 PM Will Deacon wrote:
> > > > On Mon, Jun 07, 2021 at 02:08:59PM +0100, Mark Rutland wrote:
> > > > > On Mon, Jun 07, 2021 at 01:01:18PM +0100, Mark Rutland wrote:
> > > > > > On Mon, Jun 07, 2021 at 11:58:32AM +0200, Marek Szyprowski wrote:
> > > I notice that it checks index 'fifos_state[channel].in_use', but then
> > > uses a different index 'i' for looking at the 'pending_commit' field
> > > beyond the end of the array.
> > >
> > > This code was introduced by Maxime Ripard in commit 9ec03d7f1ed3
> > > ("drm/vc4: kms: Wait on previous FIFO users before a commit").
> >
> > Awesome, I tried to find out that bug a few weeks ago but couldn't
> > reproduce the KASAN spat. You're right, it should be channel here
> > instead of i. Since you did the whole work, do you want to send the
> > patch?
>
> Marek and Mark did most of the work finding the problem, I just looked
> in the right place a few times (and a bit in the wrong place). I'd suggest
> you send that patch with the corresponding Reported-by/Analyzed-by/
> Tested-by tags.
I've sent:
https://lore.kernel.org/r/20210608085513.2069-1-mark.rutl...@arm.com
Thanks,
Mark.
[PATCH] drm: Don't test for IRQ support in VBLANK ioctls
Replace the IRQ check in VBLANK ioctls with a check for vblank support. IRQs might be enabled wthout vblanking being supported. This change also removes the DRM framework's only dependency on IRQ state for non-legacy drivers. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_irq.c| 10 +++--- drivers/gpu/drm/drm_vblank.c | 6 +++--- 2 files changed, 6 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index c3bd664ea733..1d7785721323 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -74,10 +74,8 @@ * only supports devices with a single interrupt on the main device stored in * &drm_device.dev and set as the device paramter in drm_dev_alloc(). * - * These IRQ helpers are strictly optional. Drivers which roll their own only - * need to set &drm_device.irq_enabled to signal the DRM core that vblank - * interrupts are working. Since these helpers don't automatically clean up the - * requested interrupt like e.g. devm_request_irq() they're not really + * These IRQ helpers are strictly optional. Since these helpers don't automatically + * clean up the requested interrupt like e.g. devm_request_irq() they're not really * recommended. */ @@ -91,9 +89,7 @@ * and after the installation. * * This is the simplified helper interface provided for drivers with no special - * needs. Drivers which need to install interrupt handlers for multiple - * interrupts must instead set &drm_device.irq_enabled to signal the DRM core - * that vblank interrupts are available. + * needs. * * @irq must match the interrupt number that would be passed to request_irq(), * if called directly instead of using this helper function. diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index 3417e1ac7918..165286fef478 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/drivers/gpu/drm/drm_vblank.c @@ -1748,7 +1748,7 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void *data, unsigned int pipe_index; unsigned int flags, pipe, high_pipe; - if (!dev->irq_enabled) + if (!drm_dev_has_vblank(dev)) return -EOPNOTSUPP; if (vblwait->request.type & _DRM_VBLANK_SIGNAL) @@ -2023,7 +2023,7 @@ int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data, if (!drm_core_check_feature(dev, DRIVER_MODESET)) return -EOPNOTSUPP; - if (!dev->irq_enabled) + if (!drm_dev_has_vblank(dev)) return -EOPNOTSUPP; crtc = drm_crtc_find(dev, file_priv, get_seq->crtc_id); @@ -2082,7 +2082,7 @@ int drm_crtc_queue_sequence_ioctl(struct drm_device *dev, void *data, if (!drm_core_check_feature(dev, DRIVER_MODESET)) return -EOPNOTSUPP; - if (!dev->irq_enabled) + if (!drm_dev_has_vblank(dev)) return -EOPNOTSUPP; crtc = drm_crtc_find(dev, file_priv, queue_seq->crtc_id); -- 2.31.1
Re: [PATCH v6 1/3] drm/hyperv: Add DRM driver for hyperv synthetic video device
Hi Am 07.06.21 um 17:13 schrieb Deepak Rawat: On Thu, 2021-05-27 at 15:35 +0200, Thomas Zimmermann wrote: Hi if no further comments come in, this can be moved in a few days. Since you'll be the maintainer, you should request commit access to the drm-misc repository. See https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html and https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html Best regards Thomas Hi Thomas, I have merged the patches to drm-mics-next. Thanks for your help. Oh, you already had commit rights. Thanks for working on this driver. Best regards Thomas Deepak -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] drm/vc4: fix vc4_atomic_commit_tail() logic
On Tue, Jun 8, 2021 at 10:56 AM Mark Rutland wrote: > > In vc4_atomic_commit_tail() we iterate of the set of old CRTCs, and > attempt to wait on any channels which are still in use. When we iterate > over the CRTCs, we have: > > * `i` - the index of the CRTC > * `channel` - the channel a CRTC is using > > When we check the channel state, we consult: > > old_hvs_state->fifo_state[channel].in_use > > ... but when we wait for the channel, we erroneously wait on: > > old_hvs_state->fifo_state[i].pending_commit > > ... rather than: > >old_hvs_state->fifo_state[channel].pending_commit > > ... and this bogus access has been observed to result in boot-time hangs > on some arm64 configurations, and can be detected using KASAN. FIx this > by using the correct index. > > I've tested this on a Raspberry Pi 3 model B v1.2 with KASAN. ... > > Link: > https://lore.kernel.org/r/4d0c8318-bad8-2be7-e292-fc8f70c19...@samsung.com > Link: > https://lore.kernel.org/linux-arm-kernel/20210607151740.moncryl5zv3ahq4s@gilmour > Signed-off-by: Mark Rutland > Reported-by: Marek Szyprowski > Cc: Arnd Bergmann Acked-by: Arnd Bergmann
Re: [PATCH] drm: Don't test for IRQ support in VBLANK ioctls
On Tue, Jun 08, 2021 at 11:03:01AM +0200, Thomas Zimmermann wrote: > Replace the IRQ check in VBLANK ioctls with a check for vblank > support. IRQs might be enabled wthout vblanking being supported. Nah, or if they are, that's a broken driver. irq_enabled here really only means vblank_irq_enabled (maybe we should rename it). I'd like to understand the motivation here a bit better to make sure we'r not just papering over a driver bug. Also as-is this breaks legacy drivers, which do enable/disable irqs at runtime with the legacy IRQ_CONTROL ioctl, so we can't just throw this out. Hence this cleanup here is only ok for non-legacy drivers. Finally if you do this cleanup I think we should go through drivers and drop the irq_enabled = true settings that are littered around. For that cleanup I think this patch makes sense. -Daniel > > This change also removes the DRM framework's only dependency on > IRQ state for non-legacy drivers. > > Signed-off-by: Thomas Zimmermann > --- > drivers/gpu/drm/drm_irq.c| 10 +++--- > drivers/gpu/drm/drm_vblank.c | 6 +++--- > 2 files changed, 6 insertions(+), 10 deletions(-) > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c > index c3bd664ea733..1d7785721323 100644 > --- a/drivers/gpu/drm/drm_irq.c > +++ b/drivers/gpu/drm/drm_irq.c > @@ -74,10 +74,8 @@ > * only supports devices with a single interrupt on the main device stored in > * &drm_device.dev and set as the device paramter in drm_dev_alloc(). > * > - * These IRQ helpers are strictly optional. Drivers which roll their own only > - * need to set &drm_device.irq_enabled to signal the DRM core that vblank > - * interrupts are working. Since these helpers don't automatically clean up > the > - * requested interrupt like e.g. devm_request_irq() they're not really > + * These IRQ helpers are strictly optional. Since these helpers don't > automatically > + * clean up the requested interrupt like e.g. devm_request_irq() they're not > really > * recommended. > */ > > @@ -91,9 +89,7 @@ > * and after the installation. > * > * This is the simplified helper interface provided for drivers with no > special > - * needs. Drivers which need to install interrupt handlers for multiple > - * interrupts must instead set &drm_device.irq_enabled to signal the DRM core > - * that vblank interrupts are available. > + * needs. > * > * @irq must match the interrupt number that would be passed to > request_irq(), > * if called directly instead of using this helper function. > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > index 3417e1ac7918..165286fef478 100644 > --- a/drivers/gpu/drm/drm_vblank.c > +++ b/drivers/gpu/drm/drm_vblank.c > @@ -1748,7 +1748,7 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void > *data, > unsigned int pipe_index; > unsigned int flags, pipe, high_pipe; > > - if (!dev->irq_enabled) > + if (!drm_dev_has_vblank(dev)) > return -EOPNOTSUPP; > > if (vblwait->request.type & _DRM_VBLANK_SIGNAL) > @@ -2023,7 +2023,7 @@ int drm_crtc_get_sequence_ioctl(struct drm_device *dev, > void *data, > if (!drm_core_check_feature(dev, DRIVER_MODESET)) > return -EOPNOTSUPP; > > - if (!dev->irq_enabled) > + if (!drm_dev_has_vblank(dev)) > return -EOPNOTSUPP; > > crtc = drm_crtc_find(dev, file_priv, get_seq->crtc_id); > @@ -2082,7 +2082,7 @@ int drm_crtc_queue_sequence_ioctl(struct drm_device > *dev, void *data, > if (!drm_core_check_feature(dev, DRIVER_MODESET)) > return -EOPNOTSUPP; > > - if (!dev->irq_enabled) > + if (!drm_dev_has_vblank(dev)) > return -EOPNOTSUPP; > > crtc = drm_crtc_find(dev, file_priv, queue_seq->crtc_id); > -- > 2.31.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drm: Don't test for IRQ support in VBLANK ioctls
On Tue, Jun 8, 2021 at 11:18 AM Daniel Vetter wrote: > > On Tue, Jun 08, 2021 at 11:03:01AM +0200, Thomas Zimmermann wrote: > > Replace the IRQ check in VBLANK ioctls with a check for vblank > > support. IRQs might be enabled wthout vblanking being supported. > > Nah, or if they are, that's a broken driver. irq_enabled here really only > means vblank_irq_enabled (maybe we should rename it). I'd like to > understand the motivation here a bit better to make sure we'r not just > papering over a driver bug. > > Also as-is this breaks legacy drivers, which do enable/disable irqs at > runtime with the legacy IRQ_CONTROL ioctl, so we can't just throw this > out. Hence this cleanup here is only ok for non-legacy drivers. > > Finally if you do this cleanup I think we should go through drivers and > drop the irq_enabled = true settings that are littered around. For that > cleanup I think this patch makes sense. I forgot to add: We already do this check that you're adding here because later on we validate the provided crtc index against dev->num_crtcs. vblank support is confusing because it lives both in a kms and legacy driver world. -Daniel > > This change also removes the DRM framework's only dependency on > > IRQ state for non-legacy drivers. > > > > Signed-off-by: Thomas Zimmermann > > --- > > drivers/gpu/drm/drm_irq.c| 10 +++--- > > drivers/gpu/drm/drm_vblank.c | 6 +++--- > > 2 files changed, 6 insertions(+), 10 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c > > index c3bd664ea733..1d7785721323 100644 > > --- a/drivers/gpu/drm/drm_irq.c > > +++ b/drivers/gpu/drm/drm_irq.c > > @@ -74,10 +74,8 @@ > > * only supports devices with a single interrupt on the main device stored > > in > > * &drm_device.dev and set as the device paramter in drm_dev_alloc(). > > * > > - * These IRQ helpers are strictly optional. Drivers which roll their own > > only > > - * need to set &drm_device.irq_enabled to signal the DRM core that vblank > > - * interrupts are working. Since these helpers don't automatically clean > > up the > > - * requested interrupt like e.g. devm_request_irq() they're not really > > + * These IRQ helpers are strictly optional. Since these helpers don't > > automatically > > + * clean up the requested interrupt like e.g. devm_request_irq() they're > > not really > > * recommended. > > */ > > > > @@ -91,9 +89,7 @@ > > * and after the installation. > > * > > * This is the simplified helper interface provided for drivers with no > > special > > - * needs. Drivers which need to install interrupt handlers for multiple > > - * interrupts must instead set &drm_device.irq_enabled to signal the DRM > > core > > - * that vblank interrupts are available. > > + * needs. > > * > > * @irq must match the interrupt number that would be passed to > > request_irq(), > > * if called directly instead of using this helper function. > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > index 3417e1ac7918..165286fef478 100644 > > --- a/drivers/gpu/drm/drm_vblank.c > > +++ b/drivers/gpu/drm/drm_vblank.c > > @@ -1748,7 +1748,7 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, > > void *data, > > unsigned int pipe_index; > > unsigned int flags, pipe, high_pipe; > > > > - if (!dev->irq_enabled) > > + if (!drm_dev_has_vblank(dev)) > > return -EOPNOTSUPP; > > > > if (vblwait->request.type & _DRM_VBLANK_SIGNAL) > > @@ -2023,7 +2023,7 @@ int drm_crtc_get_sequence_ioctl(struct drm_device > > *dev, void *data, > > if (!drm_core_check_feature(dev, DRIVER_MODESET)) > > return -EOPNOTSUPP; > > > > - if (!dev->irq_enabled) > > + if (!drm_dev_has_vblank(dev)) > > return -EOPNOTSUPP; > > > > crtc = drm_crtc_find(dev, file_priv, get_seq->crtc_id); > > @@ -2082,7 +2082,7 @@ int drm_crtc_queue_sequence_ioctl(struct drm_device > > *dev, void *data, > > if (!drm_core_check_feature(dev, DRIVER_MODESET)) > > return -EOPNOTSUPP; > > > > - if (!dev->irq_enabled) > > + if (!drm_dev_has_vblank(dev)) > > return -EOPNOTSUPP; > > > > crtc = drm_crtc_find(dev, file_priv, queue_seq->crtc_id); > > -- > > 2.31.1 > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 0/9] Prereqs for TTM accelerated migration
A couple of patches from Chris which implement pipelined migration and clears by atomically writing the PTEs in place before performing the actual blit. Some ww utilities mainly for the accompanying selftests added by Thomas, as well as modified the above patches for ww locking- and lmem support. The actual hook up to the i915 ttm backend is being worked on and not included yet, so this is considered to be an early review opportunity. Chris Wilson (6): drm/i915/gt: Add an insert_entry for gen8_ppgtt drm/i915/gt: Add a routine to iterate over the pagetables of a GTT drm/i915/gt: Export the pinned context constructor drm/i915/gt: Pipelined page migration drm/i915/gt: Pipelined clear drm/i915/gt: Setup a default migration context on the GT Thomas Hellström (3): drm/i915: Reference objects on the ww object list drm/i915: Break out dma_resv ww locking utilities to separate files drm/i915: Introduce a ww transaction helper drivers/gpu/drm/i915/Makefile | 2 + drivers/gpu/drm/i915/gem/i915_gem_object.h| 9 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 68 ++ drivers/gpu/drm/i915/gt/intel_engine.h| 10 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 21 +- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 + drivers/gpu/drm/i915/gt/intel_gt.c| 4 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 + drivers/gpu/drm/i915/gt/intel_gtt.h | 7 + drivers/gpu/drm/i915/gt/intel_migrate.c | 684 ++ drivers/gpu/drm/i915/gt/intel_migrate.h | 65 ++ drivers/gpu/drm/i915/gt/intel_migrate_types.h | 15 + drivers/gpu/drm/i915/gt/intel_renderstate.h | 1 + drivers/gpu/drm/i915/gt/intel_ring.h | 1 + drivers/gpu/drm/i915/gt/selftest_migrate.c| 671 + drivers/gpu/drm/i915/i915_gem.c | 52 -- drivers/gpu/drm/i915/i915_gem.h | 12 - drivers/gpu/drm/i915/i915_gem_ww.c| 63 ++ drivers/gpu/drm/i915/i915_gem_ww.h| 50 ++ .../drm/i915/selftests/i915_live_selftests.h | 1 + .../drm/i915/selftests/i915_perf_selftests.h | 1 + 21 files changed, 1669 insertions(+), 73 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/intel_migrate.c create mode 100644 drivers/gpu/drm/i915/gt/intel_migrate.h create mode 100644 drivers/gpu/drm/i915/gt/intel_migrate_types.h create mode 100644 drivers/gpu/drm/i915/gt/selftest_migrate.c create mode 100644 drivers/gpu/drm/i915/i915_gem_ww.c create mode 100644 drivers/gpu/drm/i915/i915_gem_ww.h -- 2.31.1
[PATCH 1/9] drm/i915: Reference objects on the ww object list
Since the ww transaction endpoint easily end up far out-of-scope of
the objects on the ww object list, particularly for contending lock
objects, make sure we reference objects on the list so they don't
disappear under us.
This comes with a performance penalty so it's been debated whether this
is really needed. But I think this is motivated by the fact that locking
is typically difficult to get right, and whatever we can do to make it
simpler for developers moving forward should be done, unless the
performance impact is far too high.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 8 ++--
drivers/gpu/drm/i915/i915_gem.c| 4
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 7c0eb425cb3b..1fafcc89ecee 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -169,13 +169,17 @@ static inline int __i915_gem_object_lock(struct
drm_i915_gem_object *obj,
else
ret = dma_resv_lock(obj->base.resv, ww ? &ww->ctx : NULL);
- if (!ret && ww)
+ if (!ret && ww) {
+ i915_gem_object_get(obj);
list_add_tail(&obj->obj_link, &ww->obj_list);
+ }
if (ret == -EALREADY)
ret = 0;
- if (ret == -EDEADLK)
+ if (ret == -EDEADLK) {
+ i915_gem_object_get(obj);
ww->contended = obj;
+ }
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 589388dec48a..3f060ab58c5d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1219,6 +1219,7 @@ static void i915_gem_ww_ctx_unlock_all(struct
i915_gem_ww_ctx *ww)
while ((obj = list_first_entry_or_null(&ww->obj_list, struct
drm_i915_gem_object, obj_link))) {
list_del(&obj->obj_link);
i915_gem_object_unlock(obj);
+ i915_gem_object_put(obj);
}
}
@@ -1226,6 +1227,7 @@ void i915_gem_ww_unlock_single(struct drm_i915_gem_object
*obj)
{
list_del(&obj->obj_link);
i915_gem_object_unlock(obj);
+ i915_gem_object_put(obj);
}
void i915_gem_ww_ctx_fini(struct i915_gem_ww_ctx *ww)
@@ -1250,6 +1252,8 @@ int __must_check i915_gem_ww_ctx_backoff(struct
i915_gem_ww_ctx *ww)
if (!ret)
list_add_tail(&ww->contended->obj_link, &ww->obj_list);
+ else
+ i915_gem_object_put(ww->contended);
ww->contended = NULL;
--
2.31.1
[PATCH 2/9] drm/i915: Break out dma_resv ww locking utilities to separate files
As we're about to add more ww-related functionality,
break out the dma_resv ww locking utilities to their own files
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
drivers/gpu/drm/i915/gt/intel_renderstate.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 56 --
drivers/gpu/drm/i915/i915_gem.h | 12
drivers/gpu/drm/i915/i915_gem_ww.c | 63 +
drivers/gpu/drm/i915/i915_gem_ww.h | 21 +++
7 files changed, 87 insertions(+), 68 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_gem_ww.c
create mode 100644 drivers/gpu/drm/i915/i915_gem_ww.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4f22cac1c49b..ea8ee4b3e018 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -45,6 +45,7 @@ i915-y += i915_drv.o \
i915_switcheroo.o \
i915_sysfs.o \
i915_utils.o \
+ i915_gem_ww.o \
intel_device_info.o \
intel_dram.o \
intel_memory_region.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 1fafcc89ecee..789529b424c1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -15,6 +15,7 @@
#include "i915_gem_object_types.h"
#include "i915_gem_gtt.h"
#include "i915_vma_types.h"
+#include "i915_gem_ww.h"
/*
* XXX: There is a prevalence of the assumption that we fit the
diff --git a/drivers/gpu/drm/i915/gt/intel_renderstate.h
b/drivers/gpu/drm/i915/gt/intel_renderstate.h
index 48f009203917..4da4c5234ef0 100644
--- a/drivers/gpu/drm/i915/gt/intel_renderstate.h
+++ b/drivers/gpu/drm/i915/gt/intel_renderstate.h
@@ -8,6 +8,7 @@
#include
#include "i915_gem.h"
+#include "i915_gem_ww.h"
struct i915_request;
struct intel_context;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3f060ab58c5d..ce64d3005cf2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1204,62 +1204,6 @@ int i915_gem_open(struct drm_i915_private *i915, struct
drm_file *file)
return ret;
}
-void i915_gem_ww_ctx_init(struct i915_gem_ww_ctx *ww, bool intr)
-{
- ww_acquire_init(&ww->ctx, &reservation_ww_class);
- INIT_LIST_HEAD(&ww->obj_list);
- ww->intr = intr;
- ww->contended = NULL;
-}
-
-static void i915_gem_ww_ctx_unlock_all(struct i915_gem_ww_ctx *ww)
-{
- struct drm_i915_gem_object *obj;
-
- while ((obj = list_first_entry_or_null(&ww->obj_list, struct
drm_i915_gem_object, obj_link))) {
- list_del(&obj->obj_link);
- i915_gem_object_unlock(obj);
- i915_gem_object_put(obj);
- }
-}
-
-void i915_gem_ww_unlock_single(struct drm_i915_gem_object *obj)
-{
- list_del(&obj->obj_link);
- i915_gem_object_unlock(obj);
- i915_gem_object_put(obj);
-}
-
-void i915_gem_ww_ctx_fini(struct i915_gem_ww_ctx *ww)
-{
- i915_gem_ww_ctx_unlock_all(ww);
- WARN_ON(ww->contended);
- ww_acquire_fini(&ww->ctx);
-}
-
-int __must_check i915_gem_ww_ctx_backoff(struct i915_gem_ww_ctx *ww)
-{
- int ret = 0;
-
- if (WARN_ON(!ww->contended))
- return -EINVAL;
-
- i915_gem_ww_ctx_unlock_all(ww);
- if (ww->intr)
- ret =
dma_resv_lock_slow_interruptible(ww->contended->base.resv, &ww->ctx);
- else
- dma_resv_lock_slow(ww->contended->base.resv, &ww->ctx);
-
- if (!ret)
- list_add_tail(&ww->contended->obj_link, &ww->obj_list);
- else
- i915_gem_object_put(ww->contended);
-
- ww->contended = NULL;
-
- return ret;
-}
-
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/mock_gem_device.c"
#include "selftests/i915_gem.c"
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 440c35f1abc9..d0752e5553db 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -123,16 +123,4 @@ static inline bool __tasklet_is_scheduled(struct
tasklet_struct *t)
return test_bit(TASKLET_STATE_SCHED, &t->state);
}
-struct i915_gem_ww_ctx {
- struct ww_acquire_ctx ctx;
- struct list_head obj_list;
- bool intr;
- struct drm_i915_gem_object *contended;
-};
-
-void i915_gem_ww_ctx_init(struct i915_gem_ww_ctx *ctx, bool intr);
-void i915_gem_ww_ctx_fini(struct i915_gem_ww_ctx *ctx);
-int __must_check i915_gem_ww_ctx_backoff(struct i915_gem_ww_ctx *ctx);
-void i915_gem_ww_unlock_single(struct drm_i915_gem_object *obj);
-
#endif /* __I915_GEM_H__ */
diff --git a/drivers/gpu/drm/i915/i915_gem_ww.c
b/drivers/gpu/drm/i915/i915_gem_ww.c
new file mode 100644
index ..3f6ff139478e
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_gem_ww.c
@@ -0,0 +1,63 @@
+// SPDX-License-Id
[PATCH 3/9] drm/i915: Introduce a ww transaction helper
Introduce a for_i915_gem_ww(){} utility to help make the code
around a ww transaction more readable.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_gem_ww.h | 31 +-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_ww.h
b/drivers/gpu/drm/i915/i915_gem_ww.h
index f2d8769e4118..f6b1a796667b 100644
--- a/drivers/gpu/drm/i915/i915_gem_ww.h
+++ b/drivers/gpu/drm/i915/i915_gem_ww.h
@@ -11,11 +11,40 @@ struct i915_gem_ww_ctx {
struct ww_acquire_ctx ctx;
struct list_head obj_list;
struct drm_i915_gem_object *contended;
- bool intr;
+ unsigned short intr;
+ unsigned short loop;
};
void i915_gem_ww_ctx_init(struct i915_gem_ww_ctx *ctx, bool intr);
void i915_gem_ww_ctx_fini(struct i915_gem_ww_ctx *ctx);
int __must_check i915_gem_ww_ctx_backoff(struct i915_gem_ww_ctx *ctx);
void i915_gem_ww_unlock_single(struct drm_i915_gem_object *obj);
+
+/* Internal functions used by the inlines! Don't use. */
+static inline int __i915_gem_ww_fini(struct i915_gem_ww_ctx *ww, int err)
+{
+ ww->loop = 0;
+ if (err == -EDEADLK) {
+ err = i915_gem_ww_ctx_backoff(ww);
+ if (!err)
+ ww->loop = 1;
+ }
+
+ if (!ww->loop)
+ i915_gem_ww_ctx_fini(ww);
+
+ return err;
+}
+
+static inline void
+__i915_gem_ww_init(struct i915_gem_ww_ctx *ww, bool intr)
+{
+ i915_gem_ww_ctx_init(ww, intr);
+ ww->loop = 1;
+}
+
+#define for_i915_gem_ww(_ww, _err, _intr) \
+ for (__i915_gem_ww_init(_ww, _intr); (_ww)->loop; \
+_err = __i915_gem_ww_fini(_ww, _err))
+
#endif
--
2.31.1
[PATCH 5/9] drm/i915/gt: Add a routine to iterate over the pagetables of a GTT
From: Chris Wilson
In the next patch, we will want to look at the dma addresses of
individual page tables, so add a routine to iterate over them.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 49
drivers/gpu/drm/i915/gt/intel_gtt.h | 7
2 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 1b676d7700bf..3d02c726c746 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -361,6 +361,54 @@ static void gen8_ppgtt_alloc(struct i915_address_space *vm,
&start, start + length, vm->top);
}
+static void __gen8_ppgtt_foreach(struct i915_address_space *vm,
+struct i915_page_directory *pd,
+u64 *start, u64 end, int lvl,
+void (*fn)(struct i915_address_space *vm,
+ struct i915_page_table *pt,
+ void *data),
+void *data)
+{
+ unsigned int idx, len;
+
+ len = gen8_pd_range(*start, end, lvl--, &idx);
+
+ spin_lock(&pd->lock);
+ do {
+ struct i915_page_table *pt = pd->entry[idx];
+
+ atomic_inc(&pt->used);
+ spin_unlock(&pd->lock);
+
+ if (lvl) {
+ __gen8_ppgtt_foreach(vm, as_pd(pt), start, end, lvl,
+fn, data);
+ } else {
+ fn(vm, pt, data);
+ *start += gen8_pt_count(*start, end);
+ }
+
+ spin_lock(&pd->lock);
+ atomic_dec(&pt->used);
+ } while (idx++, --len);
+ spin_unlock(&pd->lock);
+}
+
+static void gen8_ppgtt_foreach(struct i915_address_space *vm,
+ u64 start, u64 length,
+ void (*fn)(struct i915_address_space *vm,
+ struct i915_page_table *pt,
+ void *data),
+ void *data)
+{
+ start >>= GEN8_PTE_SHIFT;
+ length >>= GEN8_PTE_SHIFT;
+
+ __gen8_ppgtt_foreach(vm, i915_vm_to_ppgtt(vm)->pd,
+&start, start + length, vm->top,
+fn, data);
+}
+
static __always_inline u64
gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
struct i915_page_directory *pdp,
@@ -755,6 +803,7 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt)
ppgtt->vm.insert_page = gen8_ppgtt_insert_entry;
ppgtt->vm.allocate_va_range = gen8_ppgtt_alloc;
ppgtt->vm.clear_range = gen8_ppgtt_clear;
+ ppgtt->vm.foreach = gen8_ppgtt_foreach;
ppgtt->vm.pte_encode = gen8_pte_encode;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index edea95b97c36..9bd89f2a01ff 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -296,6 +296,13 @@ struct i915_address_space {
u32 flags);
void (*cleanup)(struct i915_address_space *vm);
+ void (*foreach)(struct i915_address_space *vm,
+ u64 start, u64 length,
+ void (*fn)(struct i915_address_space *vm,
+ struct i915_page_table *pt,
+ void *data),
+ void *data);
+
struct i915_vma_ops vma_ops;
I915_SELFTEST_DECLARE(struct fault_attr fault_attr);
--
2.31.1
[PATCH 6/9] drm/i915/gt: Export the pinned context constructor
From: Chris Wilson
Allow internal clients to create a pinned context.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine.h| 9 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 21 ++---
2 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 8d9184920c51..0862c42b4cac 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -19,7 +19,9 @@
#include "intel_workarounds.h"
struct drm_printer;
+struct intel_context;
struct intel_gt;
+struct lock_class_key;
/* Early gen2 devices have a cacheline of just 32 bytes, using 64 is overkill,
* but keeps the logic simple. Indeed, the whole purpose of this macro is just
@@ -256,6 +258,13 @@ struct i915_request *
intel_engine_find_active_request(struct intel_engine_cs *engine);
u32 intel_engine_context_size(struct intel_gt *gt, u8 class);
+struct intel_context *
+intel_engine_create_pinned_context(struct intel_engine_cs *engine,
+ struct i915_address_space *vm,
+ unsigned int ring_size,
+ unsigned int hwsp,
+ struct lock_class_key *key,
+ const char *name);
void intel_engine_init_active(struct intel_engine_cs *engine,
unsigned int subclass);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 9ceddfbb1687..ac32fd29d7ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -810,11 +810,13 @@ intel_engine_init_active(struct intel_engine_cs *engine,
unsigned int subclass)
#endif
}
-static struct intel_context *
-create_pinned_context(struct intel_engine_cs *engine,
- unsigned int hwsp,
- struct lock_class_key *key,
- const char *name)
+struct intel_context *
+intel_engine_create_pinned_context(struct intel_engine_cs *engine,
+ struct i915_address_space *vm,
+ unsigned int ring_size,
+ unsigned int hwsp,
+ struct lock_class_key *key,
+ const char *name)
{
struct intel_context *ce;
int err;
@@ -825,6 +827,10 @@ create_pinned_context(struct intel_engine_cs *engine,
__set_bit(CONTEXT_BARRIER_BIT, &ce->flags);
ce->timeline = page_pack_bits(NULL, hwsp);
+ ce->ring = __intel_context_ring_size(ring_size);
+
+ i915_vm_put(ce->vm);
+ ce->vm = i915_vm_get(vm);
err = intel_context_pin(ce); /* perma-pin so it is always available */
if (err) {
@@ -863,8 +869,9 @@ create_kernel_context(struct intel_engine_cs *engine)
{
static struct lock_class_key kernel;
- return create_pinned_context(engine, I915_GEM_HWS_SEQNO_ADDR,
-&kernel, "kernel_context");
+ return intel_engine_create_pinned_context(engine, engine->gt->vm, SZ_4K,
+ I915_GEM_HWS_SEQNO_ADDR,
+ &kernel, "kernel_context");
}
/**
--
2.31.1
[PATCH 4/9] drm/i915/gt: Add an insert_entry for gen8_ppgtt
From: Chris Wilson
In the next patch, we will want to write a PTE for an explicit
dma address, outside of the usual vma.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 21c8b7350b7a..1b676d7700bf 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -555,6 +555,24 @@ static void gen8_ppgtt_insert(struct i915_address_space
*vm,
}
}
+static void gen8_ppgtt_insert_entry(struct i915_address_space *vm,
+ dma_addr_t addr,
+ u64 offset,
+ enum i915_cache_level level,
+ u32 flags)
+{
+ u64 idx = offset >> GEN8_PTE_SHIFT;
+ struct i915_page_directory * const pdp =
+ gen8_pdp_for_page_index(vm, idx);
+ struct i915_page_directory *pd =
+ i915_pd_entry(pdp, gen8_pd_index(idx, 2));
+ gen8_pte_t *vaddr;
+
+ vaddr = px_vaddr(i915_pt_entry(pd, gen8_pd_index(idx, 1)));
+ vaddr[gen8_pd_index(idx, 0)] = gen8_pte_encode(addr, level, flags);
+ clflush_cache_range(&vaddr[gen8_pd_index(idx, 0)], sizeof(*vaddr));
+}
+
static int gen8_init_scratch(struct i915_address_space *vm)
{
u32 pte_flags;
@@ -734,6 +752,7 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt)
ppgtt->vm.bind_async_flags = I915_VMA_LOCAL_BIND;
ppgtt->vm.insert_entries = gen8_ppgtt_insert;
+ ppgtt->vm.insert_page = gen8_ppgtt_insert_entry;
ppgtt->vm.allocate_va_range = gen8_ppgtt_alloc;
ppgtt->vm.clear_range = gen8_ppgtt_clear;
--
2.31.1
[PATCH 7/9] drm/i915/gt: Pipelined page migration
From: Chris Wilson
If we pipeline the PTE updates and then do the copy of those pages
within a single unpreemptible command packet, we can submit the copies
and leave them to be scheduled without having to synchronously wait
under a global lock. In order to manage migration, we need to
preallocate the page tables (and keep them pinned and available for use
at any time), causing a bottleneck for migrations as all clients must
contend on the limited resources. By inlining the ppGTT updates and
performing the blit atomically, each client only owns the PTE while in
use, and so we can reschedule individual operations however we see fit.
And most importantly, we do not need to take a global lock on the shared
vm, and wait until the operation is complete before releasing the lock
for others to claim the PTE for themselves.
Signed-off-by: Chris Wilson
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_engine.h| 1 +
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 +
drivers/gpu/drm/i915/gt/intel_migrate.c | 543 ++
drivers/gpu/drm/i915/gt/intel_migrate.h | 45 ++
drivers/gpu/drm/i915/gt/intel_migrate_types.h | 15 +
drivers/gpu/drm/i915/gt/intel_ring.h | 1 +
drivers/gpu/drm/i915/gt/selftest_migrate.c| 291 ++
.../drm/i915/selftests/i915_live_selftests.h | 1 +
9 files changed, 900 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/intel_migrate.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_migrate.h
create mode 100644 drivers/gpu/drm/i915/gt/intel_migrate_types.h
create mode 100644 drivers/gpu/drm/i915/gt/selftest_migrate.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index ea8ee4b3e018..9f18902be626 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -109,6 +109,7 @@ gt-y += \
gt/intel_gtt.o \
gt/intel_llc.o \
gt/intel_lrc.o \
+ gt/intel_migrate.o \
gt/intel_mocs.o \
gt/intel_ppgtt.o \
gt/intel_rc6.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 0862c42b4cac..949965680c37 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -188,6 +188,7 @@ intel_write_status_page(struct intel_engine_cs *engine, int
reg, u32 value)
#define I915_GEM_HWS_PREEMPT_ADDR (I915_GEM_HWS_PREEMPT * sizeof(u32))
#define I915_GEM_HWS_SEQNO 0x40
#define I915_GEM_HWS_SEQNO_ADDR(I915_GEM_HWS_SEQNO *
sizeof(u32))
+#define I915_GEM_HWS_MIGRATE (0x42 * sizeof(u32))
#define I915_GEM_HWS_SCRATCH 0x80
#define I915_HWS_CSB_BUF0_INDEX0x10
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 2694dbb9967e..1c3af0fc0456 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -123,8 +123,10 @@
#define MI_SEMAPHORE_SAD_NEQ_SDD (5 << 12)
#define MI_SEMAPHORE_TOKEN_MASK REG_GENMASK(9, 5)
#define MI_SEMAPHORE_TOKEN_SHIFT 5
+#define MI_STORE_DATA_IMM MI_INSTR(0x20, 0)
#define MI_STORE_DWORD_IMM MI_INSTR(0x20, 1)
#define MI_STORE_DWORD_IMM_GEN4MI_INSTR(0x20, 2)
+#define MI_STORE_QWORD_IMM_GEN8 (MI_INSTR(0x20, 3) | REG_BIT(21))
#define MI_MEM_VIRTUAL (1 << 22) /* 945,g33,965 */
#define MI_USE_GGTT (1 << 22) /* g4x+ */
#define MI_STORE_DWORD_INDEX MI_INSTR(0x21, 1)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
new file mode 100644
index ..1f60f8ee36f8
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -0,0 +1,543 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include "i915_drv.h"
+#include "intel_context.h"
+#include "intel_gpu_commands.h"
+#include "intel_gt.h"
+#include "intel_gtt.h"
+#include "intel_migrate.h"
+#include "intel_ring.h"
+
+struct insert_pte_data {
+ u64 offset;
+ bool is_lmem;
+};
+
+#define CHUNK_SZ SZ_8M /* ~1ms at 8GiB/s preemption delay */
+
+static bool engine_supports_migration(struct intel_engine_cs *engine)
+{
+ if (!engine)
+ return false;
+
+ /*
+* We need the ability to prevent aribtration (MI_ARB_ON_OFF),
+* the ability to write PTE using inline data (MI_STORE_DATA)
+* and of course the ability to do the block transfer (blits).
+*/
+ GEM_BUG_ON(engine->class != COPY_ENGINE_CLASS);
+
+ return true;
+}
+
+static void insert_pte(struct i915_address_space *vm,
+ struct i915_page_table *pt,
+ void *data)
+{
+ struct insert_pte_data *d = data;
+
+ vm->insert_page(vm, px_dma(pt), d->offset, I915_CACHE_NONE,
+ d->i
[PATCH 8/9] drm/i915/gt: Pipelined clear
From: Chris Wilson
Update the PTE and emit a clear within a single unpreemptible packet
such that we can schedule and pipeline clears.
Signed-off-by: Chris Wilson
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_migrate.c| 141 ++
drivers/gpu/drm/i915/gt/intel_migrate.h| 20 +++
drivers/gpu/drm/i915/gt/selftest_migrate.c | 163 +
3 files changed, 324 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 1f60f8ee36f8..9b8178a79ad3 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -488,6 +488,112 @@ intel_context_migrate_copy(struct intel_context *ce,
return err;
}
+static int emit_clear(struct i915_request *rq, int size, u32 value)
+{
+ const int gen = INTEL_GEN(rq->engine->i915);
+ u32 *cs;
+
+ GEM_BUG_ON(size >> PAGE_SHIFT > S16_MAX);
+
+ cs = intel_ring_begin(rq, gen >= 8 ? 8 : 6);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ if (gen >= 8) {
+ *cs++ = XY_COLOR_BLT_CMD | BLT_WRITE_RGBA | (7 - 2);
+ *cs++ = BLT_DEPTH_32 | BLT_ROP_COLOR_COPY | PAGE_SIZE;
+ *cs++ = 0;
+ *cs++ = size >> PAGE_SHIFT << 16 | PAGE_SIZE / 4;
+ *cs++ = 0; /* offset */
+ *cs++ = 0;
+ *cs++ = value;
+ *cs++ = MI_NOOP;
+ } else {
+ *cs++ = XY_COLOR_BLT_CMD | BLT_WRITE_RGBA | (6 - 2);
+ *cs++ = BLT_DEPTH_32 | BLT_ROP_COLOR_COPY | PAGE_SIZE;
+ *cs++ = 0;
+ *cs++ = size >> PAGE_SHIFT << 16 | PAGE_SIZE / 4;
+ *cs++ = 0;
+ *cs++ = value;
+ }
+
+ intel_ring_advance(rq, cs);
+ return 0;
+}
+
+int
+intel_context_migrate_clear(struct intel_context *ce,
+ struct dma_fence *await,
+ struct scatterlist *sg,
+ enum i915_cache_level cache_level,
+ bool is_lmem,
+ u32 value,
+ struct i915_request **out)
+{
+ struct sgt_dma it = sg_sgt(sg);
+ struct i915_request *rq;
+ int err;
+
+ *out = NULL;
+
+ GEM_BUG_ON(ce->ring->size < SZ_64K);
+
+ do {
+ int len;
+
+ rq = i915_request_create(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_ce;
+ }
+
+ if (await) {
+ err = i915_request_await_dma_fence(rq, await);
+ if (err)
+ goto out_rq;
+
+ if (rq->engine->emit_init_breadcrumb) {
+ err = rq->engine->emit_init_breadcrumb(rq);
+ if (err)
+ goto out_rq;
+ }
+
+ await = NULL;
+ }
+
+ /* The PTE updates + clear must not be interrupted. */
+ err = emit_no_arbitration(rq);
+ if (err)
+ goto out_rq;
+
+ len = emit_pte(rq, &it, cache_level, is_lmem, 0, CHUNK_SZ);
+ if (len <= 0) {
+ err = len;
+ goto out_rq;
+ }
+
+ err = rq->engine->emit_flush(rq, EMIT_INVALIDATE);
+ if (err)
+ goto out_rq;
+
+ err = emit_clear(rq, len, value);
+
+ /* Arbitration is re-enabled between requests. */
+out_rq:
+ if (*out)
+ i915_request_put(*out);
+ *out = i915_request_get(rq);
+ i915_request_add(rq);
+ if (err || !it.sg || !sg_dma_len(it.sg))
+ break;
+
+ cond_resched();
+ } while (1);
+
+out_ce:
+ return err;
+}
+
int intel_migrate_copy(struct intel_migrate *m,
struct i915_gem_ww_ctx *ww,
struct dma_fence *await,
@@ -526,6 +632,41 @@ int intel_migrate_copy(struct intel_migrate *m,
return err;
}
+int
+intel_migrate_clear(struct intel_migrate *m,
+ struct i915_gem_ww_ctx *ww,
+ struct dma_fence *await,
+ struct scatterlist *sg,
+ enum i915_cache_level cache_level,
+ bool is_lmem,
+ u32 value,
+ struct i915_request **out)
+{
+ struct intel_context *ce;
+ int err;
+
+ *out = NULL;
+ if (!m->context)
+ return -ENODEV;
+
+ ce = intel_migrate_create_context(m);
+ if (IS_ERR(ce))
+ ce = intel_context_get(m->context);
+ GEM_BUG_ON(IS_ERR(ce));
+
+
[PATCH 9/9] drm/i915/gt: Setup a default migration context on the GT
From: Chris Wilson
Set up a default migration context on the GT and use it from the
selftests.
Add a perf selftest and make sure we exercise LMEM if available.
Signed-off-by: Chris Wilson
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/intel_gt.c| 4 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +
drivers/gpu/drm/i915/gt/intel_migrate.c | 4 +-
drivers/gpu/drm/i915/gt/selftest_migrate.c| 227 +-
.../drm/i915/selftests/i915_perf_selftests.h | 1 +
5 files changed, 232 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 2161bf01ef8b..67ef057ae918 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -13,6 +13,7 @@
#include "intel_gt_clock_utils.h"
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
+#include "intel_migrate.h"
#include "intel_mocs.h"
#include "intel_rc6.h"
#include "intel_renderstate.h"
@@ -626,6 +627,8 @@ int intel_gt_init(struct intel_gt *gt)
if (err)
goto err_gt;
+ intel_migrate_init(>->migrate, gt);
+
goto out_fw;
err_gt:
__intel_gt_disable(gt);
@@ -649,6 +652,7 @@ void intel_gt_driver_remove(struct intel_gt *gt)
{
__intel_gt_disable(gt);
+ intel_migrate_fini(>->migrate);
intel_uc_driver_remove(>->uc);
intel_engines_release(gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index fecfacf551d5..7450935f2ca8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -24,6 +24,7 @@
#include "intel_reset_types.h"
#include "intel_rc6_types.h"
#include "intel_rps_types.h"
+#include "intel_migrate_types.h"
#include "intel_wakeref.h"
struct drm_i915_private;
@@ -145,6 +146,8 @@ struct intel_gt {
struct i915_vma *scratch;
+ struct intel_migrate migrate;
+
struct intel_gt_info {
intel_engine_mask_t engine_mask;
u8 num_engines;
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 9b8178a79ad3..a7d196a6f3eb 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -416,10 +416,9 @@ intel_context_migrate_copy(struct intel_context *ce,
struct i915_request *rq;
int err;
+ GEM_BUG_ON(ce->vm != ce->engine->gt->migrate.context->vm);
*out = NULL;
- /* GEM_BUG_ON(ce->vm != migrate_vm); */
-
GEM_BUG_ON(ce->ring->size < SZ_64K);
do {
@@ -534,6 +533,7 @@ intel_context_migrate_clear(struct intel_context *ce,
struct i915_request *rq;
int err;
+ GEM_BUG_ON(ce->vm != ce->engine->gt->migrate.context->vm);
*out = NULL;
GEM_BUG_ON(ce->ring->size < SZ_64K);
diff --git a/drivers/gpu/drm/i915/gt/selftest_migrate.c
b/drivers/gpu/drm/i915/gt/selftest_migrate.c
index 159c8656e1b0..396c81364399 100644
--- a/drivers/gpu/drm/i915/gt/selftest_migrate.c
+++ b/drivers/gpu/drm/i915/gt/selftest_migrate.c
@@ -3,6 +3,8 @@
* Copyright © 2020 Intel Corporation
*/
+#include
+
#include "selftests/i915_random.h"
static const unsigned int sizes[] = {
@@ -441,14 +443,229 @@ int intel_migrate_live_selftests(struct drm_i915_private
*i915)
SUBTEST(thread_global_copy),
SUBTEST(thread_global_clear),
};
- struct intel_migrate m;
+ struct intel_gt *gt = &i915->gt;
+
+ if (!gt->migrate.context)
+ return 0;
+
+ return i915_subtests(tests, >->migrate);
+}
+
+static struct drm_i915_gem_object *
+create_init_lmem_internal(struct intel_gt *gt, size_t sz, bool try_lmem)
+{
+ struct drm_i915_gem_object *obj = NULL;
int err;
- if (intel_migrate_init(&m, &i915->gt))
+ if (try_lmem && HAS_LMEM(gt->i915))
+ obj = i915_gem_object_create_lmem(gt->i915, sz, 0);
+
+ if (IS_ERR_OR_NULL(obj)) {
+ obj = i915_gem_object_create_internal(gt->i915, sz);
+ if (IS_ERR(obj))
+ return obj;
+ }
+
+ i915_gem_object_trylock(obj);
+ err = i915_gem_object_pin_pages(obj);
+ if (err) {
+ i915_gem_object_unlock(obj);
+ i915_gem_object_put(obj);
+ return ERR_PTR(err);
+ }
+
+ return obj;
+}
+
+static int wrap_ktime_compare(const void *A, const void *B)
+{
+ const ktime_t *a = A, *b = B;
+
+ return ktime_compare(*a, *b);
+}
+
+static int __perf_clear_blt(struct intel_context *ce,
+ struct scatterlist *sg,
+ enum i915_cache_level cache_level,
+ bool is_lmem,
+ size_t sz)
+{
+ ktime_t t[5];
+ int pass;
+ int err = 0;
+
+ for (pass = 0
Re: [PATCH V6 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
On 6/8/21 10:51 AM, Robert Foss wrote: Hey Neil, On Tue, 8 Jun 2021 at 10:10, Neil Armstrong wrote: Hi, On 07/06/2021 19:42, Marek Vasut wrote: Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on, but easy to add. The driver operates the chip via I2C bus. Currently the LVDS clock are always derived from DSI clock lane, which is the usual mode of operation. Support for clock from external oscillator is not implemented, but it is easy to add if ever needed. Only RGB888 pixel format is implemented, the LVDS666 is not supported, but could be added if needed. Reviewed-by: Linus Walleij Reviewed-by: Frieder Schrempf Tested-by: Frieder Schrempf Tested-by: Adam Ford Signed-off-by: Marek Vasut Cc: Douglas Anderson Cc: Jagan Teki Cc: Laurent Pinchart Cc: Linus Walleij Cc: Loic Poulain Cc: Philippe Schenker Cc: Sam Ravnborg Cc: Stephen Boyd Cc: Valentin Raevsky To: dri-devel@lists.freedesktop.org --- V2: - Use dev_err_probe() - Set REG_RC_RESET as volatile - Wait for PLL stabilization by polling REG_RC_LVDS_PLL - Use ctx->mode = *adj instead of *mode in sn65dsi83_mode_set - Add tested DSI84 support in dual-link mode - Correctly set VCOM - Fill in missing DSI CHB and LVDS CHB bits from DSI84 and DSI85 datasheets, with that all the reserved bits make far more sense as the DSI83 and DSI84 seems to be reduced version of DSI85 V3: - Handle the dual-link LVDS with two port panel or bridge V4: - Add RB from Linus Walleij - Rename REG_DSI_LANE_LVDS_LINK_CFG_DUAL to REG_DSI_LANE_DSI_CHANNEL_MODE_SINGLE and fill in the remaining DSI link options from DSI85 datasheet. DSI85 can do dual and 2x single DSI mode, but DSI85 is currently unsupported by the driver. Add a comment about DSI85, so that all the places which need to be adjusted for DSI85 are marked accordingly. - Add REG_DSI_LANE_LEFT_RIGHT_PIXELS bit for DSI - Add handling for JEIDA18/JEIDA24/SPWG24 LVDS formats. Use SPWG24 as fallback on output bridges until they are all fixed. - Patch DSI bus format to fixed RGB888_1X24 instead of passing through the LVDS bus format. V5: - Move bus format patching to mode_fixup - Use cpu_to_le16() to guarantee endianness in regmap_bulk_write() V6: - Cast of_device_get_match_data() output to uintptr_t first --- drivers/gpu/drm/bridge/Kconfig| 10 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ti-sn65dsi83.c | 709 ++ 3 files changed, 720 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c Looks complete & well reviewed, LGTM Rob, Laurent ? is it ok for you ? This does look like it is ready. I was just about to merge it, but found some checkpatch --strict formatting warnings. Do you mind fixing those in a real quick v7? We already discussed this thing with open parenthesis alignment before in one of the previous versions of this series, and the readability of the driver was worse with that change in place. Is this change now a blocker ?
Re: [PATCH 01/10] drm/ttm: allocate resource object instead of embedding it v2
On 6/8/2021 9:21 AM, Christian König wrote: Am 08.06.21 um 09:17 schrieb Thomas Hellström (Intel): [SNIP] Do you have the log to double check? Unfortunately not, but IIRC it was directly from vmw_move(). Nirmoy do you still have your vmwgfx test environment? Yes! Thanks, Christian. /Thomas
Re: linux-next: build failure after merge of the drm-misc tree
Hi Christian,
I based amdgpu_preempt_mgr on amdgpu_gtt_mgr and now I'm looking at what
changed there. Looks like I'll need to create a dummy node in
amdgpu_preempt_mgr_new to satisfy TTM, and free it in
amdgpu_preempt_mgr_del.
Thanks,
Felix
Am 2021-06-07 um 10:50 p.m. schrieb Stephen Rothwell:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c: In function
> 'amdgpu_preempt_mgr_new':
> drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:75:5: error: 'struct
> ttm_resource' has no member named 'mm_node'
>75 | mem->mm_node = NULL;
> | ^~
> drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c: At top level:
> drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:129:11: error: initialization
> of 'int (*)(struct ttm_resource_manager *, struct ttm_buffer_object *, const
> struct ttm_place *, struct ttm_resource **)' from incompatible pointer type
> 'int (*)(struct ttm_resource_manager *, struct ttm_buffer_object *, const
> struct ttm_place *, struct ttm_resource *)'
> [-Werror=incompatible-pointer-types]
> 129 | .alloc = amdgpu_preempt_mgr_new,
> | ^~
> drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:129:11: note: (near
> initialization for 'amdgpu_preempt_mgr_func.alloc')
>
> Caused by commit
>
> cb1c81467af3 ("drm/ttm: flip the switch for driver allocated resources v2")
>
> from the drm-misc tree interacting with commit
>
> b453e42a6e8b ("drm/amdgpu: Add new placement for preemptible SG BOs")
>
> from the drm tree.
>
> I don't know how to fix this, so I added the following hack (a better
> fix would be nice):
>
> From: Stephen Rothwell
> Date: Tue, 8 Jun 2021 12:41:16 +1000
> Subject: [PATCH] hack fix up for needed amdgpu_preempt_mgr_new() fix up
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
> index d607f314cc1b..e1a7b3e967b9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
> @@ -66,14 +66,16 @@ static DEVICE_ATTR_RO(mem_info_preempt_used);
> static int amdgpu_preempt_mgr_new(struct ttm_resource_manager *man,
> struct ttm_buffer_object *tbo,
> const struct ttm_place *place,
> - struct ttm_resource *mem)
> + struct ttm_resource **res)
> {
> +#if 0
> struct amdgpu_preempt_mgr *mgr = to_preempt_mgr(man);
>
> atomic64_add(mem->num_pages, &mgr->used);
>
> mem->mm_node = NULL;
> mem->start = AMDGPU_BO_INVALID_OFFSET;
> +#endif
> return 0;
> }
>
Re: [PATCH 01/10] drm/ttm: allocate resource object instead of embedding it v2
On 6/8/2021 11:38 AM, Das, Nirmoy wrote: On 6/8/2021 9:21 AM, Christian König wrote: Am 08.06.21 um 09:17 schrieb Thomas Hellström (Intel): [SNIP] Do you have the log to double check? Unfortunately not, but IIRC it was directly from vmw_move(). Nirmoy do you still have your vmwgfx test environment? Yes! I will test this series on my vmwgfx setup. Thanks, Christian. /Thomas
[PATCH V7 1/2] dt-bindings: drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 bindings
Add DT binding document for TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge.
Reviewed-by: Linus Walleij
Reviewed-by: Rob Herring
Signed-off-by: Marek Vasut
Cc: Douglas Anderson
Cc: Jagan Teki
Cc: Laurent Pinchart
Cc: Linus Walleij
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: Stephen Boyd
Cc: devicet...@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
V2: Add compatible string for SN65DSI84, since this is now tested on it
V3: - Add 0x2c as valid i2c address
- Switch to schemas/graph.yaml
- Constraint data-lanes to <1>, <1 2>, <1 2 3>, <1 2 3 4> only
- Indent example by 4 spaces
- Handle dual-link LVDS with two ports and describe the second DSI
channel-B port as well. Based on the register defaults of DSI83
and DSI84, it is likely that the LVDS-channel-B and DSI-channel-B
hardware is present in all the chips, so just reuse port@0 and 2
for DSI83, port@0,2,3 for DSI84 and all of 0,1,2,3 for DSI85 when
that is supported
V4: - Fix typo in port@3 description
- Add RB from Linus Walleij
- Replace oneOf: and const with enum:
- ref /schemas/media/video-interfaces.yaml#
- Drop empty endpoint: and properties:
V5: - Add RB from Rob Herring
V6: - No change
V7: - No change
---
.../bindings/display/bridge/ti,sn65dsi83.yaml | 159 ++
1 file changed, 159 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
new file mode 100644
index ..d101233ae17f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
@@ -0,0 +1,159 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi83.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SN65DSI83 and SN65DSI84 DSI to LVDS bridge chip
+
+maintainers:
+ - Marek Vasut
+
+description: |
+ Texas Instruments SN65DSI83 1x Single-link MIPI DSI
+ to 1x Single-link LVDS
+ https://www.ti.com/lit/gpn/sn65dsi83
+ Texas Instruments SN65DSI84 1x Single-link MIPI DSI
+ to 1x Dual-link or 2x Single-link LVDS
+ https://www.ti.com/lit/gpn/sn65dsi84
+
+properties:
+ compatible:
+enum:
+ - ti,sn65dsi83
+ - ti,sn65dsi84
+
+ reg:
+enum:
+ - 0x2c
+ - 0x2d
+
+ enable-gpios:
+maxItems: 1
+description: GPIO specifier for bridge_en pin (active high).
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for MIPI DSI Channel-A input
+
+properties:
+ endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+unevaluatedProperties: false
+
+properties:
+ data-lanes:
+description: array of physical DSI data lane indexes.
+minItems: 1
+maxItems: 4
+items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for MIPI DSI Channel-B input
+
+properties:
+ endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+unevaluatedProperties: false
+
+properties:
+ data-lanes:
+description: array of physical DSI data lane indexes.
+minItems: 1
+maxItems: 4
+items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+ port@2:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for LVDS Channel-A output (panel or bridge).
+
+ port@3:
+$ref: /schemas/graph.yaml#/properties/port
+description: Video port for LVDS Channel-B output (panel or bridge).
+
+required:
+ - port@0
+ - port@2
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - ports
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: ti,sn65dsi83
+then:
+ properties:
+ports:
+ properties:
+port@1: false
+port@3: false
+
+ - if:
+ properties:
+compatible:
+ contains:
+const: ti,sn65dsi84
+then:
+ properties:
+ports:
+ properties:
+port@1: false
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+bridge@2d {
+compatible = "ti,sn65dsi83";
+reg = <0x2d>;
+
+enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
+
+ports
[PATCH V7 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on, but easy to add. The driver operates the chip via I2C bus. Currently the LVDS clock are always derived from DSI clock lane, which is the usual mode of operation. Support for clock from external oscillator is not implemented, but it is easy to add if ever needed. Only RGB888 pixel format is implemented, the LVDS666 is not supported, but could be added if needed. Reviewed-by: Linus Walleij Reviewed-by: Frieder Schrempf Tested-by: Frieder Schrempf Tested-by: Adam Ford Signed-off-by: Marek Vasut Cc: Douglas Anderson Cc: Jagan Teki Cc: Laurent Pinchart Cc: Linus Walleij Cc: Loic Poulain Cc: Philippe Schenker Cc: Sam Ravnborg Cc: Stephen Boyd Cc: Valentin Raevsky To: dri-devel@lists.freedesktop.org --- V2: - Use dev_err_probe() - Set REG_RC_RESET as volatile - Wait for PLL stabilization by polling REG_RC_LVDS_PLL - Use ctx->mode = *adj instead of *mode in sn65dsi83_mode_set - Add tested DSI84 support in dual-link mode - Correctly set VCOM - Fill in missing DSI CHB and LVDS CHB bits from DSI84 and DSI85 datasheets, with that all the reserved bits make far more sense as the DSI83 and DSI84 seems to be reduced version of DSI85 V3: - Handle the dual-link LVDS with two port panel or bridge V4: - Add RB from Linus Walleij - Rename REG_DSI_LANE_LVDS_LINK_CFG_DUAL to REG_DSI_LANE_DSI_CHANNEL_MODE_SINGLE and fill in the remaining DSI link options from DSI85 datasheet. DSI85 can do dual and 2x single DSI mode, but DSI85 is currently unsupported by the driver. Add a comment about DSI85, so that all the places which need to be adjusted for DSI85 are marked accordingly. - Add REG_DSI_LANE_LEFT_RIGHT_PIXELS bit for DSI - Add handling for JEIDA18/JEIDA24/SPWG24 LVDS formats. Use SPWG24 as fallback on output bridges until they are all fixed. - Patch DSI bus format to fixed RGB888_1X24 instead of passing through the LVDS bus format. V5: - Move bus format patching to mode_fixup - Use cpu_to_le16() to guarantee endianness in regmap_bulk_write() V6: - Cast of_device_get_match_data() output to uintptr_t first V7: - Fix checkpatch --strict CHECKs --- drivers/gpu/drm/bridge/Kconfig| 10 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ti-sn65dsi83.c | 709 ++ 3 files changed, 720 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 8e15b387e013..1df1704262d0 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -300,6 +300,16 @@ config DRM_TI_TFP410 help Texas Instruments TFP410 DVI/HDMI Transmitter driver +config DRM_TI_SN65DSI83 + tristate "TI SN65DSI83 and SN65DSI84 DSI to LVDS bridge" + depends on OF + select DRM_KMS_HELPER + select REGMAP_I2C + select DRM_PANEL + select DRM_MIPI_DSI + help + Texas Instruments SN65DSI83 and SN65DSI84 DSI to LVDS Bridge driver + config DRM_TI_SN65DSI86 tristate "TI SN65DSI86 DSI to eDP bridge" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index e2218e40b3b3..61302be291af 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -25,6 +25,7 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ +obj-$(CONFIG_DRM_TI_SN65DSI83) += ti-sn65dsi83.o obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c new file mode 100644 index ..750f2172ef08 --- /dev/null +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -0,0 +1,709 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * TI SN65DSI83,84,85 driver + * + * Currently supported: + * - SN65DSI83 + * = 1x Single-link DSI ~ 1x Single-link LVDS + * - Supported + * - Single-link LVDS mode tested + * - SN65DSI84 + * = 1x Single-link DSI ~ 2x Single-link or 1x Dual-link LVDS + * - Supported + * - Dual-link LVDS mode tested + * - 2x Single-link LVDS mode unsupported + * (should be easy to add by someone who has the HW) + * - SN65DSI85 + * = 2x Single-link or 1x Dual-link DSI ~ 2x Single-link or 1x Dual-link LVDS + * - Unsupported + * (should be easy to add by someone who has the HW) + * + * Copyright (C) 2021 Marek Vasut + * + * Based on previous work of: + * Valentin Raevsky + * Philippe Schenker + */ + +#include +#include +#include +#include +#inclu
Re: [PATCH 01/10] drm/ttm: allocate resource object instead of embedding it v2
Am 08.06.21 um 11:40 schrieb Das, Nirmoy: On 6/8/2021 11:38 AM, Das, Nirmoy wrote: On 6/8/2021 9:21 AM, Christian König wrote: Am 08.06.21 um 09:17 schrieb Thomas Hellström (Intel): [SNIP] Do you have the log to double check? Unfortunately not, but IIRC it was directly from vmw_move(). Nirmoy do you still have your vmwgfx test environment? Yes! I will test this series on my vmwgfx setup. Since it is already pushed (and we fixed a bunch of its fallout) can you please test drm-misc-next instead? Thanks, Christian. Thanks, Christian. /Thomas
Re: [PATCH V6 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
On Tue, 8 Jun 2021 at 11:34, Marek Vasut wrote: > > On 6/8/21 10:51 AM, Robert Foss wrote: > > Hey Neil, > > > > On Tue, 8 Jun 2021 at 10:10, Neil Armstrong wrote: > >> > >> Hi, > >> > >> On 07/06/2021 19:42, Marek Vasut wrote: > >>> Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge > >>> and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS > >>> bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on, > >>> but easy to add. > >>> > >>> The driver operates the chip via I2C bus. Currently the LVDS clock are > >>> always derived from DSI clock lane, which is the usual mode of operation. > >>> Support for clock from external oscillator is not implemented, but it is > >>> easy to add if ever needed. Only RGB888 pixel format is implemented, the > >>> LVDS666 is not supported, but could be added if needed. > >>> > >>> Reviewed-by: Linus Walleij > >>> Reviewed-by: Frieder Schrempf > >>> Tested-by: Frieder Schrempf > >>> Tested-by: Adam Ford > >>> Signed-off-by: Marek Vasut > >>> Cc: Douglas Anderson > >>> Cc: Jagan Teki > >>> Cc: Laurent Pinchart > >>> Cc: Linus Walleij > >>> Cc: Loic Poulain > >>> Cc: Philippe Schenker > >>> Cc: Sam Ravnborg > >>> Cc: Stephen Boyd > >>> Cc: Valentin Raevsky > >>> To: dri-devel@lists.freedesktop.org > >>> --- > >>> V2: - Use dev_err_probe() > >>> - Set REG_RC_RESET as volatile > >>> - Wait for PLL stabilization by polling REG_RC_LVDS_PLL > >>> - Use ctx->mode = *adj instead of *mode in sn65dsi83_mode_set > >>> - Add tested DSI84 support in dual-link mode > >>> - Correctly set VCOM > >>> - Fill in missing DSI CHB and LVDS CHB bits from DSI84 and DSI85 > >>>datasheets, with that all the reserved bits make far more sense > >>>as the DSI83 and DSI84 seems to be reduced version of DSI85 > >>> V3: - Handle the dual-link LVDS with two port panel or bridge > >>> V4: - Add RB from Linus Walleij > >>> - Rename REG_DSI_LANE_LVDS_LINK_CFG_DUAL to > >>>REG_DSI_LANE_DSI_CHANNEL_MODE_SINGLE and fill in the remaining > >>>DSI link options from DSI85 datasheet. DSI85 can do dual and 2x > >>>single DSI mode, but DSI85 is currently unsupported by the > >>>driver. Add a comment about DSI85, so that all the places which > >>>need to be adjusted for DSI85 are marked accordingly. > >>> - Add REG_DSI_LANE_LEFT_RIGHT_PIXELS bit for DSI > >>> - Add handling for JEIDA18/JEIDA24/SPWG24 LVDS formats. Use SPWG24 > >>>as fallback on output bridges until they are all fixed. > >>> - Patch DSI bus format to fixed RGB888_1X24 instead of passing > >>>through the LVDS bus format. > >>> V5: - Move bus format patching to mode_fixup > >>> - Use cpu_to_le16() to guarantee endianness in regmap_bulk_write() > >>> V6: - Cast of_device_get_match_data() output to uintptr_t first > >>> --- > >>> drivers/gpu/drm/bridge/Kconfig| 10 + > >>> drivers/gpu/drm/bridge/Makefile | 1 + > >>> drivers/gpu/drm/bridge/ti-sn65dsi83.c | 709 ++ > >>> 3 files changed, 720 insertions(+) > >>> create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c > >>> > >> > >> Looks complete & well reviewed, LGTM > >> > >> Rob, Laurent ? is it ok for you ? > > > > This does look like it is ready. I was just about to merge it, but > > found some checkpatch --strict formatting warnings. Do you mind fixing > > those in a real quick v7? > > We already discussed this thing with open parenthesis alignment before > in one of the previous versions of this series, and the readability of > the driver was worse with that change in place. > > Is this change now a blocker ? Ah, sorry I missed that part of the conversation. In that case no. Let's go ahead.
Re: [PATCH] drm/vc4: fix vc4_atomic_commit_tail() logic
On 08.06.2021 10:55, Mark Rutland wrote: > In vc4_atomic_commit_tail() we iterate of the set of old CRTCs, and > attempt to wait on any channels which are still in use. When we iterate > over the CRTCs, we have: > > * `i` - the index of the CRTC > * `channel` - the channel a CRTC is using > > When we check the channel state, we consult: > >old_hvs_state->fifo_state[channel].in_use > > ... but when we wait for the channel, we erroneously wait on: > >old_hvs_state->fifo_state[i].pending_commit > > ... rather than: > > old_hvs_state->fifo_state[channel].pending_commit > > ... and this bogus access has been observed to result in boot-time hangs > on some arm64 configurations, and can be detected using KASAN. FIx this > by using the correct index. > > I've tested this on a Raspberry Pi 3 model B v1.2 with KASAN. > > Trimmed KASAN splat: > > | == > | BUG: KASAN: slab-out-of-bounds in vc4_atomic_commit_tail+0x1cc/0x910 > | Read of size 8 at addr 07360440 by task kworker/u8:0/7 > | CPU: 2 PID: 7 Comm: kworker/u8:0 Not tainted 5.13.0-rc3-9-g694c523e7267 > #3 > | > | Hardware name: Raspberry Pi 3 Model B (DT) > | Workqueue: events_unbound deferred_probe_work_func > | Call trace: > | dump_backtrace+0x0/0x2b4 > | show_stack+0x1c/0x30 > | dump_stack+0xfc/0x168 > | print_address_description.constprop.0+0x2c/0x2c0 > | kasan_report+0x1dc/0x240 > | __asan_load8+0x98/0xd4 > | vc4_atomic_commit_tail+0x1cc/0x910 > | commit_tail+0x100/0x210 > | ... > | > | Allocated by task 7: > | kasan_save_stack+0x2c/0x60 > | __kasan_kmalloc+0x90/0xb4 > | vc4_hvs_channels_duplicate_state+0x60/0x1a0 > | drm_atomic_get_private_obj_state+0x144/0x230 > | vc4_atomic_check+0x40/0x73c > | drm_atomic_check_only+0x998/0xe60 > | drm_atomic_commit+0x34/0x94 > | drm_client_modeset_commit_atomic+0x2f4/0x3a0 > | drm_client_modeset_commit_locked+0x8c/0x230 > | drm_client_modeset_commit+0x38/0x60 > | drm_fb_helper_set_par+0x104/0x17c > | fbcon_init+0x43c/0x970 > | visual_init+0x14c/0x1e4 > | ... > | > | The buggy address belongs to the object at 07360400 > | which belongs to the cache kmalloc-128 of size 128 > | The buggy address is located 64 bytes inside of > | 128-byte region [07360400, 07360480) > | The buggy address belongs to the page: > | page:(ptrval) refcount:1 mapcount:0 mapping: > index:0x0 pfn:0x7360 > | flags: 0x3fffc000200(slab|node=0|zone=0|lastcpupid=0x) > | raw: 03fffc000200 dead0100 dead0122 04c02300 > | raw: 00100010 0001 > | page dumped because: kasan: bad access detected > | > | Memory state around the buggy address: > | 07360300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > | 07360380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > | >07360400: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc > |^ > | 07360480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > | 07360500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > | == > > Link: > https://lore.kernel.org/r/4d0c8318-bad8-2be7-e292-fc8f70c19...@samsung.com > Link: > https://lore.kernel.org/linux-arm-kernel/20210607151740.moncryl5zv3ahq4s@gilmour > Signed-off-by: Mark Rutland > Reported-by: Marek Szyprowski > Cc: Arnd Bergmann > Cc: Catalin Marinas > Cc: Daniel Vetter > Cc: David Airlie > Cc: Emma Anholt > Cc: Maxime Ripard > Cc: Will Deacon > Cc: dri-devel@lists.freedesktop.org Tested-by: Marek Szyprowski > --- > drivers/gpu/drm/vc4/vc4_kms.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c > index bb5529a7a9c2..948b3a58aad1 100644 > --- a/drivers/gpu/drm/vc4/vc4_kms.c > +++ b/drivers/gpu/drm/vc4/vc4_kms.c > @@ -372,7 +372,7 @@ static void vc4_atomic_commit_tail(struct > drm_atomic_state *state) > if (!old_hvs_state->fifo_state[channel].in_use) > continue; > > - ret = > drm_crtc_commit_wait(old_hvs_state->fifo_state[i].pending_commit); > + ret = > drm_crtc_commit_wait(old_hvs_state->fifo_state[channel].pending_commit); > if (ret) > drm_err(dev, "Timed out waiting for commit\n"); > } Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
Re: [PATCH V6 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
On 6/8/21 11:42 AM, Robert Foss wrote: On Tue, 8 Jun 2021 at 11:34, Marek Vasut wrote: On 6/8/21 10:51 AM, Robert Foss wrote: Hey Neil, On Tue, 8 Jun 2021 at 10:10, Neil Armstrong wrote: Hi, On 07/06/2021 19:42, Marek Vasut wrote: Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on, but easy to add. The driver operates the chip via I2C bus. Currently the LVDS clock are always derived from DSI clock lane, which is the usual mode of operation. Support for clock from external oscillator is not implemented, but it is easy to add if ever needed. Only RGB888 pixel format is implemented, the LVDS666 is not supported, but could be added if needed. Reviewed-by: Linus Walleij Reviewed-by: Frieder Schrempf Tested-by: Frieder Schrempf Tested-by: Adam Ford Signed-off-by: Marek Vasut Cc: Douglas Anderson Cc: Jagan Teki Cc: Laurent Pinchart Cc: Linus Walleij Cc: Loic Poulain Cc: Philippe Schenker Cc: Sam Ravnborg Cc: Stephen Boyd Cc: Valentin Raevsky To: dri-devel@lists.freedesktop.org --- V2: - Use dev_err_probe() - Set REG_RC_RESET as volatile - Wait for PLL stabilization by polling REG_RC_LVDS_PLL - Use ctx->mode = *adj instead of *mode in sn65dsi83_mode_set - Add tested DSI84 support in dual-link mode - Correctly set VCOM - Fill in missing DSI CHB and LVDS CHB bits from DSI84 and DSI85 datasheets, with that all the reserved bits make far more sense as the DSI83 and DSI84 seems to be reduced version of DSI85 V3: - Handle the dual-link LVDS with two port panel or bridge V4: - Add RB from Linus Walleij - Rename REG_DSI_LANE_LVDS_LINK_CFG_DUAL to REG_DSI_LANE_DSI_CHANNEL_MODE_SINGLE and fill in the remaining DSI link options from DSI85 datasheet. DSI85 can do dual and 2x single DSI mode, but DSI85 is currently unsupported by the driver. Add a comment about DSI85, so that all the places which need to be adjusted for DSI85 are marked accordingly. - Add REG_DSI_LANE_LEFT_RIGHT_PIXELS bit for DSI - Add handling for JEIDA18/JEIDA24/SPWG24 LVDS formats. Use SPWG24 as fallback on output bridges until they are all fixed. - Patch DSI bus format to fixed RGB888_1X24 instead of passing through the LVDS bus format. V5: - Move bus format patching to mode_fixup - Use cpu_to_le16() to guarantee endianness in regmap_bulk_write() V6: - Cast of_device_get_match_data() output to uintptr_t first --- drivers/gpu/drm/bridge/Kconfig| 10 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/ti-sn65dsi83.c | 709 ++ 3 files changed, 720 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c Looks complete & well reviewed, LGTM Rob, Laurent ? is it ok for you ? This does look like it is ready. I was just about to merge it, but found some checkpatch --strict formatting warnings. Do you mind fixing those in a real quick v7? We already discussed this thing with open parenthesis alignment before in one of the previous versions of this series, and the readability of the driver was worse with that change in place. Is this change now a blocker ? Ah, sorry I missed that part of the conversation. In that case no. Let's go ahead. Nevermind, I sent V7. Apparently line over 80 is no longer an issue and line over 100 is, so the result doesn't look so bad. Pick the V7 please.
Re: [PATCH V6 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
Pushed to drm-misc-next. https://cgit.freedesktop.org/drm/drm-misc/commit/?id=db2aad0ffa7dfec31ddf715017a6ae57aa162045 On Tue, 8 Jun 2021 at 11:42, Robert Foss wrote: > > On Tue, 8 Jun 2021 at 11:34, Marek Vasut wrote: > > > > On 6/8/21 10:51 AM, Robert Foss wrote: > > > Hey Neil, > > > > > > On Tue, 8 Jun 2021 at 10:10, Neil Armstrong > > > wrote: > > >> > > >> Hi, > > >> > > >> On 07/06/2021 19:42, Marek Vasut wrote: > > >>> Add driver for TI SN65DSI83 Single-link DSI to Single-link LVDS bridge > > >>> and TI SN65DSI84 Single-link DSI to Dual-link or 2x Single-link LVDS > > >>> bridge. TI SN65DSI85 is unsupported due to lack of hardware to test on, > > >>> but easy to add. > > >>> > > >>> The driver operates the chip via I2C bus. Currently the LVDS clock are > > >>> always derived from DSI clock lane, which is the usual mode of > > >>> operation. > > >>> Support for clock from external oscillator is not implemented, but it is > > >>> easy to add if ever needed. Only RGB888 pixel format is implemented, the > > >>> LVDS666 is not supported, but could be added if needed. > > >>> > > >>> Reviewed-by: Linus Walleij > > >>> Reviewed-by: Frieder Schrempf > > >>> Tested-by: Frieder Schrempf > > >>> Tested-by: Adam Ford > > >>> Signed-off-by: Marek Vasut > > >>> Cc: Douglas Anderson > > >>> Cc: Jagan Teki > > >>> Cc: Laurent Pinchart > > >>> Cc: Linus Walleij > > >>> Cc: Loic Poulain > > >>> Cc: Philippe Schenker > > >>> Cc: Sam Ravnborg > > >>> Cc: Stephen Boyd > > >>> Cc: Valentin Raevsky > > >>> To: dri-devel@lists.freedesktop.org > > >>> --- > > >>> V2: - Use dev_err_probe() > > >>> - Set REG_RC_RESET as volatile > > >>> - Wait for PLL stabilization by polling REG_RC_LVDS_PLL > > >>> - Use ctx->mode = *adj instead of *mode in sn65dsi83_mode_set > > >>> - Add tested DSI84 support in dual-link mode > > >>> - Correctly set VCOM > > >>> - Fill in missing DSI CHB and LVDS CHB bits from DSI84 and DSI85 > > >>>datasheets, with that all the reserved bits make far more sense > > >>>as the DSI83 and DSI84 seems to be reduced version of DSI85 > > >>> V3: - Handle the dual-link LVDS with two port panel or bridge > > >>> V4: - Add RB from Linus Walleij > > >>> - Rename REG_DSI_LANE_LVDS_LINK_CFG_DUAL to > > >>>REG_DSI_LANE_DSI_CHANNEL_MODE_SINGLE and fill in the remaining > > >>>DSI link options from DSI85 datasheet. DSI85 can do dual and 2x > > >>>single DSI mode, but DSI85 is currently unsupported by the > > >>>driver. Add a comment about DSI85, so that all the places which > > >>>need to be adjusted for DSI85 are marked accordingly. > > >>> - Add REG_DSI_LANE_LEFT_RIGHT_PIXELS bit for DSI > > >>> - Add handling for JEIDA18/JEIDA24/SPWG24 LVDS formats. Use SPWG24 > > >>>as fallback on output bridges until they are all fixed. > > >>> - Patch DSI bus format to fixed RGB888_1X24 instead of passing > > >>>through the LVDS bus format. > > >>> V5: - Move bus format patching to mode_fixup > > >>> - Use cpu_to_le16() to guarantee endianness in regmap_bulk_write() > > >>> V6: - Cast of_device_get_match_data() output to uintptr_t first > > >>> --- > > >>> drivers/gpu/drm/bridge/Kconfig| 10 + > > >>> drivers/gpu/drm/bridge/Makefile | 1 + > > >>> drivers/gpu/drm/bridge/ti-sn65dsi83.c | 709 ++ > > >>> 3 files changed, 720 insertions(+) > > >>> create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi83.c > > >>> > > >> > > >> Looks complete & well reviewed, LGTM > > >> > > >> Rob, Laurent ? is it ok for you ? > > > > > > This does look like it is ready. I was just about to merge it, but > > > found some checkpatch --strict formatting warnings. Do you mind fixing > > > those in a real quick v7? > > > > We already discussed this thing with open parenthesis alignment before > > in one of the previous versions of this series, and the readability of > > the driver was worse with that change in place. > > > > Is this change now a blocker ? > > Ah, sorry I missed that part of the conversation. In that case no. > Let's go ahead.
Re: [PATCH V6 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
On 6/8/21 11:44 AM, Robert Foss wrote: Pushed to drm-misc-next. https://cgit.freedesktop.org/drm/drm-misc/commit/?id=db2aad0ffa7dfec31ddf715017a6ae57aa162045 Well, then I'll just send a follow up patch.
Re: [PATCH V6 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
On Tue, 8 Jun 2021 at 11:45, Marek Vasut wrote: > > On 6/8/21 11:44 AM, Robert Foss wrote: > > Pushed to drm-misc-next. > > > > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=db2aad0ffa7dfec31ddf715017a6ae57aa162045 > > Well, then I'll just send a follow up patch. Thank you!
Re: [PATCH v2 4/6] drm/i915/ttm: pass along the I915_BO_ALLOC_CONTIGUOUS
On 6/8/21 10:44 AM, Matthew Auld wrote: Currently we just ignore the I915_BO_ALLOC_CONTIGUOUS flag, which is fine since everything is already contiguous with the ttm range manager. However in the next patch we want to switch over to the ttm buddy manager, where allocations are by default not contiguous. v2(Thomas): - Forward ALLOC_CONTIG for all regions Signed-off-by: Matthew Auld Cc: Thomas Hellström Reviewed-by: Thomas Hellström
Re: [PATCH 01/10] drm/ttm: allocate resource object instead of embedding it v2
On 6/8/2021 11:42 AM, Christian König wrote: Am 08.06.21 um 11:40 schrieb Das, Nirmoy: On 6/8/2021 11:38 AM, Das, Nirmoy wrote: On 6/8/2021 9:21 AM, Christian König wrote: Am 08.06.21 um 09:17 schrieb Thomas Hellström (Intel): [SNIP] Do you have the log to double check? Unfortunately not, but IIRC it was directly from vmw_move(). Nirmoy do you still have your vmwgfx test environment? Yes! I will test this series on my vmwgfx setup. Since it is already pushed (and we fixed a bunch of its fallout) can you please test drm-misc-next instead? Sure! Nirmoy Thanks, Christian. Thanks, Christian. /Thomas
Re: [PATCH v2 6/6] drm/i915/ttm: restore min_page_size behaviour
On 6/8/21 10:44 AM, Matthew Auld wrote: We now have bo->page_alignment which perfectly describes what we need if we have min page size restrictions for lmem. We can also drop the flag here, since this is the default behaviour for all objects. v2(Thomas): - bo->page_alignment is in page units Signed-off-by: Matthew Auld Cc: Thomas Hellström Reviewed-by: Thomas Hellström
Re: [PATCH v2 5/6] drm/i915/ttm: switch over to ttm_buddy_man
On 6/8/21 10:44 AM, Matthew Auld wrote: Move back to the buddy allocator for managing device local memory, and restore the lost mock selftests. Keep around the range manager related bits, since we likely need this for managing stolen at some point. For stolen we also don't need to reserve anything so no need to support a generic reserve interface. v2(Thomas): - bo->page_alignment is in page units, not bytes Signed-off-by: Matthew Auld Cc: Thomas Hellström Reviewed-by: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 26 +-- drivers/gpu/drm/i915/intel_memory_region.c| 55 +- drivers/gpu/drm/i915/intel_memory_region.h| 17 -- drivers/gpu/drm/i915/intel_region_ttm.c | 100 +++ .../drm/i915/selftests/intel_memory_region.c | 170 -- drivers/gpu/drm/i915/selftests/mock_region.c | 15 +- 6 files changed, 168 insertions(+), 215 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c index c612275c36c9..5bf1d1945dd6 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c @@ -181,11 +181,7 @@ static bool i915_ttm_eviction_valuable(struct ttm_buffer_object *bo, struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo); /* Will do for now. Our pinned objects are still on TTM's LRU lists */ - if (!i915_gem_object_evictable(obj)) - return false; - - /* This isn't valid with a buddy allocator */ - return ttm_bo_eviction_valuable(bo, place); + return i915_gem_object_evictable(obj); } static void i915_ttm_evict_flags(struct ttm_buffer_object *bo, @@ -328,11 +324,15 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj, struct ttm_buffer_object *bo = i915_gem_to_ttm(obj); struct ttm_resource_manager *man = ttm_manager_type(bo->bdev, res->mem_type); + struct intel_memory_region *mr = obj->mm.region; if (man->use_tt) return i915_ttm_tt_get_st(bo->ttm); - return intel_region_ttm_node_to_st(obj->mm.region, res->mm_node); + if (mr->is_range_manager) Did you look at moving this test into intel_region_ttm_node_to_st()) + return intel_region_ttm_node_to_st(mr, res); + else + return i915_sg_from_buddy_resource(res, mr->region.start); } Thanks, Thomas
[PATCH] drm/bridge: ti-sn65dsi83: Fix checkpatch --strict CHECKs
Fix ./scripts/checkpatch.pl --strict -f drivers/gpu/drm/bridge/ti-sn65dsi83.c
CHECKs, no functional change. This is the same modification done to V7 of the
original patch.
Signed-off-by: Marek Vasut
Cc: Adam Ford
Cc: Douglas Anderson
Cc: Frieder Schrempf
Cc: Jagan Teki
Cc: Laurent Pinchart
Cc: Linus Walleij
Cc: Loic Poulain
Cc: Marek Vasut
Cc: Philippe Schenker
Cc: Sam Ravnborg
Cc: Stephen Boyd
Cc: Valentin Raevsky
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 36 +--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index eff35611fabf..750f2172ef08 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -377,19 +377,19 @@ static void sn65dsi83_enable(struct drm_bridge *bridge)
/* Reference clock derived from DSI link clock. */
regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
- REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
- REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
+
REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
+REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
regmap_write(ctx->regmap, REG_DSI_CLK,
- REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx)));
+
REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx)));
regmap_write(ctx->regmap, REG_RC_DSI_CLK,
- REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx)));
+
REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx)));
/* Set number of DSI lanes and LVDS link config. */
regmap_write(ctx->regmap, REG_DSI_LANE,
- REG_DSI_LANE_DSI_CHANNEL_MODE_SINGLE |
- REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)) |
- /* CHB is DSI85-only, set to default on DSI83/DSI84 */
- REG_DSI_LANE_CHB_DSI_LANES(3));
+REG_DSI_LANE_DSI_CHANNEL_MODE_SINGLE |
+REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)) |
+/* CHB is DSI85-only, set to default on DSI83/DSI84 */
+REG_DSI_LANE_CHB_DSI_LANES(3));
/* No equalization. */
regmap_write(ctx->regmap, REG_DSI_EQ, 0x00);
@@ -420,10 +420,10 @@ static void sn65dsi83_enable(struct drm_bridge *bridge)
regmap_write(ctx->regmap, REG_LVDS_FMT, val);
regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x05);
regmap_write(ctx->regmap, REG_LVDS_LANE,
- (ctx->lvds_dual_link_even_odd_swap ?
-REG_LVDS_LANE_EVEN_ODD_SWAP : 0) |
- REG_LVDS_LANE_CHA_LVDS_TERM |
- REG_LVDS_LANE_CHB_LVDS_TERM);
+(ctx->lvds_dual_link_even_odd_swap ?
+ REG_LVDS_LANE_EVEN_ODD_SWAP : 0) |
+REG_LVDS_LANE_CHA_LVDS_TERM |
+REG_LVDS_LANE_CHB_LVDS_TERM);
regmap_write(ctx->regmap, REG_LVDS_CM, 0x00);
val = cpu_to_le16(ctx->mode.hdisplay);
@@ -455,8 +455,8 @@ static void sn65dsi83_enable(struct drm_bridge *bridge)
regmap_write(ctx->regmap, REG_RC_PLL_EN, REG_RC_PLL_EN_PLL_EN);
usleep_range(3000, 4000);
ret = regmap_read_poll_timeout(ctx->regmap, REG_RC_LVDS_PLL, pval,
- pval & REG_RC_LVDS_PLL_PLL_EN_STAT,
- 1000, 10);
+ pval & REG_RC_LVDS_PLL_PLL_EN_STAT,
+ 1000, 10);
if (ret) {
dev_err(ctx->dev, "failed to lock PLL, ret=%i\n", ret);
/* On failure, disable PLL again and exit. */
@@ -513,8 +513,8 @@ static void sn65dsi83_mode_set(struct drm_bridge *bridge,
}
static bool sn65dsi83_mode_fixup(struct drm_bridge *bridge,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adj)
+const struct drm_display_mode *mode,
+struct drm_display_mode *adj)
{
struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
u32 input_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
@@ -546,8 +546,8 @@ static bool sn65dsi83_mode_fixup(struct drm_bridge *bridge,
ctx->lvds_format_24bpp = true;
ctx->lvds_format_jeida = false;
dev_warn(ctx->dev,
- "Unsupported LVDS bus format 0x%04x, please
check output bridge driver. Falling back to SPWG24.\n",
- connector->display_info.bus_formats[0]);
+"Unsupported LVDS bus format 0x%04x, please
check output bridge driver. Falling back to SPWG24.\n",
+connector->display_info.bus_formats[0]);
Re: [PATCH V6 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
On 6/8/21 11:45 AM, Robert Foss wrote: On Tue, 8 Jun 2021 at 11:45, Marek Vasut wrote: On 6/8/21 11:44 AM, Robert Foss wrote: Pushed to drm-misc-next. https://cgit.freedesktop.org/drm/drm-misc/commit/?id=db2aad0ffa7dfec31ddf715017a6ae57aa162045 Well, then I'll just send a follow up patch. Thank you! See [PATCH] drm/bridge: ti-sn65dsi83: Fix checkpatch --strict CHECKs posted to dri-devel
Re: [PATCH] drm/i915/gem/mman: only allow WC for lmem
On 02/06/2021 13:00, Thomas Hellström wrote:
Hi,
On 6/2/21 11:36 AM, Matthew Auld wrote:
For dgfx where we now have lmem and ttm, we can only support single mmap
mode for the lifetime of the object, and for lmem objects this should be
WC, so reject all other mapping modes for mmap_offset, including if the
object can be placed in both smem and lmem.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Maarten Lankhorst
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 4
drivers/gpu/drm/i915/gem/i915_gem_object.c | 22 ++
drivers/gpu/drm/i915/gem/i915_gem_object.h | 4
3 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index fd1c9714f8d8..32f88f236771 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -689,6 +689,10 @@ __assign_mmap_offset(struct drm_file *file,
goto out;
}
+ if (mmap_type != I915_MMAP_TYPE_WC &&
+ i915_gem_object_placements_contain_type(obj,
INTEL_MEMORY_LOCAL))
+ return -ENODEV;
+
I think we will also have the restriction that any other objects on DGFX
can only be mapped cached? At least that's what the TTM code is
implementing currently.
Yeah, with this patch the caching mode should now at least be consistent
for lmem objects, for smem we still need more patches.
mmo = mmap_offset_attach(obj, mmap_type, file);
if (IS_ERR(mmo)) {
err = PTR_ERR(mmo);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 2be6109d0093..d4b0da8ed969 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -403,6 +403,28 @@ int i915_gem_object_read_from_page(struct
drm_i915_gem_object *obj, u64 offset,
return 0;
}
+/**
+ * i915_gem_object_placements_contain_type - Check whether the object
can be
+ * placed at certain memory type
+ * @obj: Pointer to the object
+ * @type: The memory type to check
+ *
+ * Return: True if the object can be placed in @type. False otherwise.
+ */
+bool i915_gem_object_placements_contain_type(struct
drm_i915_gem_object *obj,
+ enum intel_memory_type type)
+{
+ unsigned int i;
+
+ /* TODO: consider maybe storing as a mask when doing
gem_create_ext */
+ for (i = 0; i < obj->mm.n_placements; i++) {
+ if (obj->mm.placements[i]->type == type)
+ return true;
+ }
+
+ return false;
+}
+
Do we need something for the in-kernel mappings as well? Or just return
a mapping with the only allowed caching mode?
For lmem everything should already be WC for in-kernel mappings. For
everything else which uses pin_map() we will need to default to cached.
I guess just add a different helper for this? We should probably also
adjust the obj->cache_level for dg1.
/Thomas
Re: [PATCH] drm/i915/gem/mman: only allow WC for lmem
On Tue, 2021-06-08 at 10:57 +0100, Matthew Auld wrote:
> On 02/06/2021 13:00, Thomas Hellström wrote:
> > Hi,
> >
> > On 6/2/21 11:36 AM, Matthew Auld wrote:
> > > For dgfx where we now have lmem and ttm, we can only support
> > > single mmap
> > > mode for the lifetime of the object, and for lmem objects this
> > > should be
> > > WC, so reject all other mapping modes for mmap_offset, including
> > > if the
> > > object can be placed in both smem and lmem.
> > >
> > > Signed-off-by: Matthew Auld
> > > Cc: Thomas Hellström
> > > Cc: Maarten Lankhorst
> > > Cc: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 4
> > > drivers/gpu/drm/i915/gem/i915_gem_object.c | 22
> > > ++
> > > drivers/gpu/drm/i915/gem/i915_gem_object.h | 4
> > > 3 files changed, 30 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > index fd1c9714f8d8..32f88f236771 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > @@ -689,6 +689,10 @@ __assign_mmap_offset(struct drm_file *file,
> > > goto out;
> > > }
> > > + if (mmap_type != I915_MMAP_TYPE_WC &&
> > > + i915_gem_object_placements_contain_type(obj,
> > > INTEL_MEMORY_LOCAL))
> > > + return -ENODEV;
> > > +
> >
> > I think we will also have the restriction that any other objects on
> > DGFX
> > can only be mapped cached? At least that's what the TTM code is
> > implementing currently.
>
> Yeah, with this patch the caching mode should now at least be
> consistent
> for lmem objects, for smem we still need more patches.
>
> >
> >
> > > mmo = mmap_offset_attach(obj, mmap_type, file);
> > > if (IS_ERR(mmo)) {
> > > err = PTR_ERR(mmo);
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > > index 2be6109d0093..d4b0da8ed969 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > > @@ -403,6 +403,28 @@ int i915_gem_object_read_from_page(struct
> > > drm_i915_gem_object *obj, u64 offset,
> > > return 0;
> > > }
> > > +/**
> > > + * i915_gem_object_placements_contain_type - Check whether the
> > > object
> > > can be
> > > + * placed at certain memory type
> > > + * @obj: Pointer to the object
> > > + * @type: The memory type to check
> > > + *
> > > + * Return: True if the object can be placed in @type. False
> > > otherwise.
> > > + */
> > > +bool i915_gem_object_placements_contain_type(struct
> > > drm_i915_gem_object *obj,
> > > + enum intel_memory_type type)
> > > +{
> > > + unsigned int i;
> > > +
> > > + /* TODO: consider maybe storing as a mask when doing
> > > gem_create_ext */
> > > + for (i = 0; i < obj->mm.n_placements; i++) {
> > > + if (obj->mm.placements[i]->type == type)
> > > + return true;
> > > + }
> > > +
> > > + return false;
> > > +}
> > > +
> >
> > Do we need something for the in-kernel mappings as well? Or just
> > return
> > a mapping with the only allowed caching mode?
>
> For lmem everything should already be WC for in-kernel mappings. For
> everything else which uses pin_map() we will need to default to
> cached.
> I guess just add a different helper for this? We should probably also
> adjust the obj->cache_level for dg1.
Note that objects that have LMEM in the allowed placement list, but are
migrated to SMEM for some reason (we haven't really decided the policy
for this yet, but perhaps for dma-buf export reasons or just being
evicted with smem as an allowable placement) will still be WC-only,
which was Daniel's recommendation to begin with, (but we can flip
caching mode on eviction / migration if we'd want to).
Currently we don't flip GEM region when evicting even if SMEM is an
allowed placement, because the object may then end up stuck in SMEM.
Not sure if we want to expose a user-space madvise-type hint for this?
/Thomas
>
> >
> > /Thomas
> >
> >
Re: [PATCH 4/4] ARM: boot: dts: bcm2711: Add BCM2711 VEC compatible
On Thu, 2021-05-20 at 17:03 +0200, Maxime Ripard wrote: > From: Mateusz Kwiatkowski > > The BCM2711 has a slightly different VEC than the one found in the older > SoCs. Now that we support the new variant, add its compatible to the > device tree. > > Signed-off-by: Mateusz Kwiatkowski > Signed-off-by: Maxime Ripard > --- Aplied for-next, Regards, Nicolas
Re: [PATCH v2 5/6] drm/i915/ttm: switch over to ttm_buddy_man
On 08/06/2021 10:53, Thomas Hellström wrote: On 6/8/21 10:44 AM, Matthew Auld wrote: Move back to the buddy allocator for managing device local memory, and restore the lost mock selftests. Keep around the range manager related bits, since we likely need this for managing stolen at some point. For stolen we also don't need to reserve anything so no need to support a generic reserve interface. v2(Thomas): - bo->page_alignment is in page units, not bytes Signed-off-by: Matthew Auld Cc: Thomas Hellström Reviewed-by: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 26 +-- drivers/gpu/drm/i915/intel_memory_region.c | 55 +- drivers/gpu/drm/i915/intel_memory_region.h | 17 -- drivers/gpu/drm/i915/intel_region_ttm.c | 100 +++ .../drm/i915/selftests/intel_memory_region.c | 170 -- drivers/gpu/drm/i915/selftests/mock_region.c | 15 +- 6 files changed, 168 insertions(+), 215 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c index c612275c36c9..5bf1d1945dd6 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c @@ -181,11 +181,7 @@ static bool i915_ttm_eviction_valuable(struct ttm_buffer_object *bo, struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo); /* Will do for now. Our pinned objects are still on TTM's LRU lists */ - if (!i915_gem_object_evictable(obj)) - return false; - - /* This isn't valid with a buddy allocator */ - return ttm_bo_eviction_valuable(bo, place); + return i915_gem_object_evictable(obj); } static void i915_ttm_evict_flags(struct ttm_buffer_object *bo, @@ -328,11 +324,15 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj, struct ttm_buffer_object *bo = i915_gem_to_ttm(obj); struct ttm_resource_manager *man = ttm_manager_type(bo->bdev, res->mem_type); + struct intel_memory_region *mr = obj->mm.region; if (man->use_tt) return i915_ttm_tt_get_st(bo->ttm); - return intel_region_ttm_node_to_st(obj->mm.region, res->mm_node); + if (mr->is_range_manager) Did you look at moving this test into intel_region_ttm_node_to_st()) I guess I didn't like the _node since that seems to suggest drm_mm_node to me. What about something like: i915_ttm_resource_to_st(res, mr) intel_region_ttm_resource_to_st(mr, res) ? + return intel_region_ttm_node_to_st(mr, res); + else + return i915_sg_from_buddy_resource(res, mr->region.start); } Thanks, Thomas
Re: [PATCH v2 5/6] drm/i915/ttm: switch over to ttm_buddy_man
On Tue, 2021-06-08 at 11:08 +0100, Matthew Auld wrote: > On 08/06/2021 10:53, Thomas Hellström wrote: > > > > On 6/8/21 10:44 AM, Matthew Auld wrote: > > > Move back to the buddy allocator for managing device local > > > memory, and > > > restore the lost mock selftests. Keep around the range manager > > > related > > > bits, since we likely need this for managing stolen at some > > > point. For > > > stolen we also don't need to reserve anything so no need to > > > support a > > > generic reserve interface. > > > > > > v2(Thomas): > > > - bo->page_alignment is in page units, not bytes > > > > > > Signed-off-by: Matthew Auld > > > Cc: Thomas Hellström > > > Reviewed-by: Thomas Hellström > > > --- > > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 26 +-- > > > drivers/gpu/drm/i915/intel_memory_region.c | 55 +- > > > drivers/gpu/drm/i915/intel_memory_region.h | 17 -- > > > drivers/gpu/drm/i915/intel_region_ttm.c | 100 +++ > > > .../drm/i915/selftests/intel_memory_region.c | 170 > > > -- > > > drivers/gpu/drm/i915/selftests/mock_region.c | 15 +- > > > 6 files changed, 168 insertions(+), 215 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > > index c612275c36c9..5bf1d1945dd6 100644 > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > > > @@ -181,11 +181,7 @@ static bool > > > i915_ttm_eviction_valuable(struct > > > ttm_buffer_object *bo, > > > struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo); > > > /* Will do for now. Our pinned objects are still on TTM's > > > LRU > > > lists */ > > > - if (!i915_gem_object_evictable(obj)) > > > - return false; > > > - > > > - /* This isn't valid with a buddy allocator */ > > > - return ttm_bo_eviction_valuable(bo, place); > > > + return i915_gem_object_evictable(obj); > > > } > > > static void i915_ttm_evict_flags(struct ttm_buffer_object *bo, > > > @@ -328,11 +324,15 @@ i915_ttm_resource_get_st(struct > > > drm_i915_gem_object *obj, > > > struct ttm_buffer_object *bo = i915_gem_to_ttm(obj); > > > struct ttm_resource_manager *man = > > > ttm_manager_type(bo->bdev, res->mem_type); > > > + struct intel_memory_region *mr = obj->mm.region; > > > if (man->use_tt) > > > return i915_ttm_tt_get_st(bo->ttm); > > > - return intel_region_ttm_node_to_st(obj->mm.region, res- > > > >mm_node); > > > + if (mr->is_range_manager) > > > > Did you look at moving this test into > > intel_region_ttm_node_to_st()) > > I guess I didn't like the _node since that seems to suggest > drm_mm_node > to me. > > What about something like: > i915_ttm_resource_to_st(res, mr) > intel_region_ttm_resource_to_st(mr, res) intel_region_ttm_resource_to_st() would be nice I think. I think it would be nice if the region ttm code could hide the manager selection. /Thomas
Re: [PATCH] drm/bridge: ti-sn65dsi83: Fix checkpatch --strict CHECKs
Thanks for submitting this.
Fix ./scripts/checkpatch.pl --strict -f drivers/gpu/drm/bridge/ti-sn65dsi83.c
CHECKs, no functional change. This is the same modification done to V7 of the
original patch.
Signed-off-by: Marek Vasut
Cc: Adam Ford
Cc: Douglas Anderson
Cc: Frieder Schrempf
Cc: Jagan Teki
Cc: Laurent Pinchart
Cc: Linus Walleij
Cc: Loic Poulain
Cc: Marek Vasut
Cc: Philippe Schenker
Cc: Sam Ravnborg
Cc: Stephen Boyd
Cc: Valentin Raevsky
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 36 +--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index eff35611fabf..750f2172ef08 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -377,19 +377,19 @@ static void sn65dsi83_enable(struct drm_bridge *bridge)
/* Reference clock derived from DSI link clock. */
regmap_write(ctx->regmap, REG_RC_LVDS_PLL,
- REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
- REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
+
REG_RC_LVDS_PLL_LVDS_CLK_RANGE(sn65dsi83_get_lvds_range(ctx)) |
+REG_RC_LVDS_PLL_HS_CLK_SRC_DPHY);
regmap_write(ctx->regmap, REG_DSI_CLK,
- REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx)));
+
REG_DSI_CLK_CHA_DSI_CLK_RANGE(sn65dsi83_get_dsi_range(ctx)));
regmap_write(ctx->regmap, REG_RC_DSI_CLK,
- REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx)));
+
REG_RC_DSI_CLK_DSI_CLK_DIVIDER(sn65dsi83_get_dsi_div(ctx)));
/* Set number of DSI lanes and LVDS link config. */
regmap_write(ctx->regmap, REG_DSI_LANE,
- REG_DSI_LANE_DSI_CHANNEL_MODE_SINGLE |
- REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)) |
- /* CHB is DSI85-only, set to default on DSI83/DSI84 */
- REG_DSI_LANE_CHB_DSI_LANES(3));
+REG_DSI_LANE_DSI_CHANNEL_MODE_SINGLE |
+REG_DSI_LANE_CHA_DSI_LANES(~(ctx->dsi_lanes - 1)) |
+/* CHB is DSI85-only, set to default on DSI83/DSI84 */
+REG_DSI_LANE_CHB_DSI_LANES(3));
/* No equalization. */
regmap_write(ctx->regmap, REG_DSI_EQ, 0x00);
@@ -420,10 +420,10 @@ static void sn65dsi83_enable(struct drm_bridge *bridge)
regmap_write(ctx->regmap, REG_LVDS_FMT, val);
regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x05);
regmap_write(ctx->regmap, REG_LVDS_LANE,
- (ctx->lvds_dual_link_even_odd_swap ?
-REG_LVDS_LANE_EVEN_ODD_SWAP : 0) |
- REG_LVDS_LANE_CHA_LVDS_TERM |
- REG_LVDS_LANE_CHB_LVDS_TERM);
+(ctx->lvds_dual_link_even_odd_swap ?
+ REG_LVDS_LANE_EVEN_ODD_SWAP : 0) |
+REG_LVDS_LANE_CHA_LVDS_TERM |
+REG_LVDS_LANE_CHB_LVDS_TERM);
regmap_write(ctx->regmap, REG_LVDS_CM, 0x00);
val = cpu_to_le16(ctx->mode.hdisplay);
@@ -455,8 +455,8 @@ static void sn65dsi83_enable(struct drm_bridge *bridge)
regmap_write(ctx->regmap, REG_RC_PLL_EN, REG_RC_PLL_EN_PLL_EN);
usleep_range(3000, 4000);
ret = regmap_read_poll_timeout(ctx->regmap, REG_RC_LVDS_PLL, pval,
- pval & REG_RC_LVDS_PLL_PLL_EN_STAT,
- 1000, 10);
+ pval & REG_RC_LVDS_PLL_PLL_EN_STAT,
+ 1000, 10);
if (ret) {
dev_err(ctx->dev, "failed to lock PLL, ret=%i\n", ret);
/* On failure, disable PLL again and exit. */
@@ -513,8 +513,8 @@ static void sn65dsi83_mode_set(struct drm_bridge *bridge,
}
static bool sn65dsi83_mode_fixup(struct drm_bridge *bridge,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adj)
+const struct drm_display_mode *mode,
+struct drm_display_mode *adj)
{
struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
u32 input_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
@@ -546,8 +546,8 @@ static bool sn65dsi83_mode_fixup(struct drm_bridge *bridge,
ctx->lvds_format_24bpp = true;
ctx->lvds_format_jeida = false;
dev_warn(ctx->dev,
- "Unsupported LVDS bus format 0x%04x, please check
output bridge driver. Falling back to SPWG24.\n",
- connector->display_info.bus_formats[0]);
+"Unsupported LVDS bus format 0x%04x, please check
output bridge driver. Falling back to SPWG24.\n",
+connector->di
[PATCH] drm/amd/display: Fix error code on failure to set brightness
The backlight_ops.update_status function is required to return a negative error code on failure. Returning a positive code may be interpreted as a success. This is true for the 'brightness' sysfs file, which passes through a non-zero value as the return value of the write() syscall. This is interpreted in user-space as a successful write of 1 character, which is obviously wrong. It's not clear exactly what error code to use, but EINVAL should be reasonable. Signed-off-by: Anand K Mistry --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 652cc1a0e450..ad322613390d 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -3431,7 +3431,7 @@ static int amdgpu_dm_backlight_update_status(struct backlight_device *bd) else rc = dc_link_set_backlight_level(dm->backlight_link, brightness, 0); - return rc ? 0 : 1; + return rc ? 0 : -EINVAL; } static int amdgpu_dm_backlight_get_brightness(struct backlight_device *bd) -- 2.32.0.rc1.229.g3e70b5a671-goog
Re: [Mesa-dev] XDC 2021: Registration & Call for Proposals now open!
Kind reminder. Deadline is Sunday, 4 July 2021 :-) Sam On Thu, 2021-05-20 at 10:01 +, Szwichtenberg, Radoslaw wrote: > Hello! > > Registration & Call for Proposals are now open for XDC 2021, which > will > take place on September 15-17, 2021. This year we will repeat as > virtual event. > > https://indico.freedesktop.org/event/1/ > > As usual, the conference is free of charge and open to the general > public. If you plan on attending, please make sure to register as > early > as possible! > > In order to register as attendee, you will therefore need to register > via the XDC website. As XDC moved to a new Indico infrastructure, if > you previously registered on the XDC website, you need to create a > new > account again. > > https://indico.freedesktop.org/event/1/registrations/1/ > > In addition to registration, the CfP is now open for talks, workshops > and demos at XDC 2021. While any serious proposal will be gratefully > considered, topics of interest to X.Org and freedesktop.org > developers > are encouraged. The program focus is on new development, ongoing > challenges and anything else that will spark discussions among > attendees in the hallway track. > > We are open to talks across all layers of the graphics stack, from > the > kernel to desktop environments / graphical applications and about how > to make things better for the developers who build them. Head to the > CfP page to learn more: > > https://indico.freedesktop.org/event/1/abstracts/ > > The deadline for submissions is Sunday, 4 July 2021. > > Last year we modified our Reimbursement Policy to accept speaker > expenses for X.Org virtual events like XDC 2021. Check it out here: > > https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ > > If you have any questions, please send me an email to > radoslaw.szwichtenb...@intel.com, adding on CC the X.org board > (board > at foundation.x.org). > > And don't forget, you can follow us on Twitter for all the latest > updates and to stay connected: > > > https://twitter.com/XOrgDevConf > > Best, > > Radek > > P.S: a DNS redirection (xdc2021.x.org) is work in progress. Please > use > the mentioned links for the moment. > > > Radosław Szwichtenberg > - > Intel Technology Poland sp. z o.o. > ul. Slowackiego 173, 80-298 Gdansk > KRS 101882 - NIP 957-07-52-316 > > ___ > mesa-dev mailing list > mesa-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: This is a digitally signed message part
Re: [PATCH v3] drm/msm/dsi: add continuous clock support for 7nm PHY
On 08/06/2021 04:28, abhin...@codeaurora.org wrote:
On 2021-06-07 16:00, Dmitry Baryshkov wrote:
Unlike previous generations, 7nm PHYs are required to collaborate with
the host for conitnuos clock mode. Add changes neccessary to enable
"the host for continuous clock mode"
Thanks!
continuous clock mode in the 7nm DSI PHYs.
Signed-off-by: Dmitry Baryshkov
---
Changes since v2:
- Really drop msm_dsi_phy_needs_hs_phy_sel()
Changes since v1:
- Remove the need for a separate msm_dsi_phy_needs_hs_phy_sel() call
- Fix setting continuous clock for a dual DSI case.
Maybe I am missing something but I cannot find this part of the change.
What has been fixed for dual DSI?
I have been passing wrong phy for the slave in dual DSI case.
---
drivers/gpu/drm/msm/dsi/dsi.h | 3 ++-
drivers/gpu/drm/msm/dsi/dsi.xml.h | 1 +
drivers/gpu/drm/msm/dsi/dsi_host.c | 12
drivers/gpu/drm/msm/dsi/dsi_manager.c | 4 ++--
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 9 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 1 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 17 +
7 files changed, 40 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h
b/drivers/gpu/drm/msm/dsi/dsi.h
index 7abfeab08165..5be458c701d2 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -108,7 +108,7 @@ int msm_dsi_host_enable(struct mipi_dsi_host *host);
int msm_dsi_host_disable(struct mipi_dsi_host *host);
int msm_dsi_host_power_on(struct mipi_dsi_host *host,
struct msm_dsi_phy_shared_timings *phy_shared_timings,
- bool is_dual_dsi);
+ bool is_dual_dsi, struct msm_dsi_phy *phy);
int msm_dsi_host_power_off(struct mipi_dsi_host *host);
int msm_dsi_host_set_display_mode(struct mipi_dsi_host *host,
const struct drm_display_mode *mode);
@@ -173,6 +173,7 @@ int msm_dsi_phy_get_clk_provider(struct
msm_dsi_phy *phy,
struct clk **byte_clk_provider, struct clk **pixel_clk_provider);
void msm_dsi_phy_pll_save_state(struct msm_dsi_phy *phy);
int msm_dsi_phy_pll_restore_state(struct msm_dsi_phy *phy);
+bool msm_dsi_phy_set_continuous_clock(struct msm_dsi_phy *phy, bool
enable);
#endif /* __DSI_CONNECTOR_H__ */
diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h
b/drivers/gpu/drm/msm/dsi/dsi.xml.h
index 50eb4d1b8fdd..9762af6035e9 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.xml.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.xml.h
@@ -510,6 +510,7 @@ static inline uint32_t
DSI_CLKOUT_TIMING_CTRL_T_CLK_POST(uint32_t val)
#define DSI_LANE_STATUS_DLN0_DIRECTION 0x0001
#define REG_DSI_LANE_CTRL 0x00a8
+#define DSI_LANE_CTRL_HS_REQ_SEL_PHY 0x0100
#define DSI_LANE_CTRL_CLKLN_HS_FORCE_REQUEST 0x1000
#define REG_DSI_LANE_SWAP_CTRL 0x00ac
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 41e1d0f7ab6e..50be935edcad 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -835,7 +835,7 @@ static inline enum dsi_cmd_dst_format
dsi_get_cmd_fmt(
}
static void dsi_ctrl_config(struct msm_dsi_host *msm_host, bool enable,
- struct msm_dsi_phy_shared_timings *phy_shared_timings)
+ struct msm_dsi_phy_shared_timings *phy_shared_timings,
struct
msm_dsi_phy *phy)
{
u32 flags = msm_host->mode_flags;
enum mipi_dsi_pixel_format mipi_fmt = msm_host->format;
@@ -930,6 +930,10 @@ static void dsi_ctrl_config(struct msm_dsi_host
*msm_host, bool enable,
if (!(flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)) {
lane_ctrl = dsi_read(msm_host, REG_DSI_LANE_CTRL);
+
+ if (msm_dsi_phy_set_continuous_clock(phy, enable))
+ lane_ctrl |= DSI_LANE_CTRL_HS_REQ_SEL_PHY;
+
Not sure how I missed this in the prev patch but for enabling continuous
clock mode for new PHY, you need to clear bit 24
and not set it. If you set it, it goes back to legacy mode ( older
method of continuous clock mode )
Oops. I've most probably missed the inversion in the downstream code at
some point. I'll send v4 later.
dsi_write(msm_host, REG_DSI_LANE_CTRL,
lane_ctrl | DSI_LANE_CTRL_CLKLN_HS_FORCE_REQUEST);
}
@@ -2360,7 +2364,7 @@ static void msm_dsi_sfpb_config(struct
msm_dsi_host *msm_host, bool enable)
int msm_dsi_host_power_on(struct mipi_dsi_host *host,
struct msm_dsi_phy_shared_timings *phy_shared_timings,
- bool is_dual_dsi)
+ bool is_dual_dsi, struct msm_dsi_phy *phy)
{
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
@@ -2400,7 +2404,7 @@ int msm_dsi_host_power_on(struct mipi_dsi_host
*host,
dsi_timing_setup(msm_host, is_dual_dsi);
dsi_sw_reset(msm_host);
- dsi_ctrl_config(msm_host, true, phy_shared_timings);
+ dsi_ctrl_config(msm_host, true,
[syzbot] BUG: unable to handle kernel NULL pointer dereference in fbcon_putcs
Hello, syzbot found the following issue on: HEAD commit:f88cd3fb Merge tag 'vfio-v5.13-rc5' of git://github.com/aw.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=126f13b030 kernel config: https://syzkaller.appspot.com/x/.config?x=ad5040c83f09b8e4 dashboard link: https://syzkaller.appspot.com/bug?extid=4e611f0926f7122c8d34 compiler: Debian clang version 11.0.1-2 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+4e611f0926f7122c8...@syzkaller.appspotmail.com BUG: kernel NULL pointer dereference, address: #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 2cdec067 P4D 2cdec067 PUD 2937a067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 0 PID: 15551 Comm: syz-executor.1 Not tainted 5.13.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c90001bcf630 EFLAGS: 00010292 RAX: RBX: 88801f456000 RCX: 004e RDX: 88801dc61224 RSI: 88801f456000 RDI: 888011879000 RBP: 111003b8c244 R08: 001d R09: 0002 R10: 0002 R11: 888037fb9c40 R12: 88801dc61224 R13: dc00 R14: 001d R15: 888011879000 FS: 7f7816197700() GS:8880b9a0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 22965000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: fbcon_putcs+0x2ae/0x430 drivers/video/fbdev/core/fbcon.c:1296 do_update_region+0x4d6/0x6a0 drivers/tty/vt/vt.c:676 invert_screen+0xc03/0xe30 drivers/tty/vt/vt.c:800 highlight drivers/tty/vt/selection.c:57 [inline] clear_selection+0x55/0x70 drivers/tty/vt/selection.c:84 vc_do_resize+0x6d6/0x1890 drivers/tty/vt/vt.c:1240 fbcon_set_disp+0x9f2/0xf90 drivers/video/fbdev/core/fbcon.c:1405 con2fb_init_display drivers/video/fbdev/core/fbcon.c:808 [inline] set_con2fb_map+0x7f6/0xe90 drivers/video/fbdev/core/fbcon.c:879 fbcon_set_con2fb_map_ioctl+0x1e7/0x300 drivers/video/fbdev/core/fbcon.c:3013 do_fb_ioctl+0x39c/0x7e0 drivers/video/fbdev/core/fbmem.c:1156 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:1069 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:1055 do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665d9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:7f7816197188 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 0056bf80 RCX: 004665d9 RDX: 2000 RSI: 4610 RDI: 0003 RBP: 004bfcb9 R08: R09: R10: R11: 0246 R12: 0056bf80 R13: 7ffe47f399af R14: 7f7816197300 R15: 00022000 Modules linked in: CR2: ---[ end trace 1eae45a248f50072 ]--- RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffd6. RSP: 0018:c90001bcf630 EFLAGS: 00010292 RAX: RBX: 88801f456000 RCX: 004e RDX: 88801dc61224 RSI: 88801f456000 RDI: 888011879000 RBP: 111003b8c244 R08: 001d R09: 0002 R10: 0002 R11: 888037fb9c40 R12: 88801dc61224 R13: dc00 R14: 001d R15: 888011879000 FS: 7f7816197700() GS:8880b9a0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ffd6 CR3: 22965000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: linux-next: build failure after merge of the drm-misc tree
Hi Felix,
that should already be fixed in drm-tip as part of the merge of the TTM
changes.
Regards,
Christian.
Am 08.06.21 um 07:37 schrieb Felix Kuehling:
Hi Christian,
I based amdgpu_preempt_mgr on amdgpu_gtt_mgr and now I'm looking at what
changed there. Looks like I'll need to create a dummy node in
amdgpu_preempt_mgr_new to satisfy TTM, and free it in
amdgpu_preempt_mgr_del.
Thanks,
Felix
Am 2021-06-07 um 10:50 p.m. schrieb Stephen Rothwell:
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c: In function
'amdgpu_preempt_mgr_new':
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:75:5: error: 'struct
ttm_resource' has no member named 'mm_node'
75 | mem->mm_node = NULL;
| ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c: At top level:
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:129:11: error: initialization
of 'int (*)(struct ttm_resource_manager *, struct ttm_buffer_object *, const
struct ttm_place *, struct ttm_resource **)' from incompatible pointer type
'int (*)(struct ttm_resource_manager *, struct ttm_buffer_object *, const
struct ttm_place *, struct ttm_resource *)' [-Werror=incompatible-pointer-types]
129 | .alloc = amdgpu_preempt_mgr_new,
| ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:129:11: note: (near
initialization for 'amdgpu_preempt_mgr_func.alloc')
Caused by commit
cb1c81467af3 ("drm/ttm: flip the switch for driver allocated resources v2")
from the drm-misc tree interacting with commit
b453e42a6e8b ("drm/amdgpu: Add new placement for preemptible SG BOs")
from the drm tree.
I don't know how to fix this, so I added the following hack (a better
fix would be nice):
From: Stephen Rothwell
Date: Tue, 8 Jun 2021 12:41:16 +1000
Subject: [PATCH] hack fix up for needed amdgpu_preempt_mgr_new() fix up
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
index d607f314cc1b..e1a7b3e967b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
@@ -66,14 +66,16 @@ static DEVICE_ATTR_RO(mem_info_preempt_used);
static int amdgpu_preempt_mgr_new(struct ttm_resource_manager *man,
struct ttm_buffer_object *tbo,
const struct ttm_place *place,
- struct ttm_resource *mem)
+ struct ttm_resource **res)
{
+#if 0
struct amdgpu_preempt_mgr *mgr = to_preempt_mgr(man);
atomic64_add(mem->num_pages, &mgr->used);
mem->mm_node = NULL;
mem->start = AMDGPU_BO_INVALID_OFFSET;
+#endif
return 0;
}
[PATCH v3 0/7] Add back the buddy allocator
Needs to be applied on top of: https://patchwork.freedesktop.org/series/90681/ Matthew Auld (6): drm/i915/ttm: add ttm_buddy_man drm/i915/ttm: add i915_sg_from_buddy_resource drm/i915/ttm: pass along the I915_BO_ALLOC_CONTIGUOUS drm/i915/ttm: remove node usage in our naming drm/i915/ttm: switch over to ttm_buddy_man drm/i915/ttm: restore min_page_size behaviour Thomas Hellström (1): drm/i915/ttm: Calculate the object placement at get_pages time drivers/gpu/drm/i915/Makefile | 2 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 5 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 98 ++- drivers/gpu/drm/i915/i915_buddy.c | 412 + drivers/gpu/drm/i915/i915_buddy.h | 133 +++ drivers/gpu/drm/i915/i915_scatterlist.c | 80 ++ drivers/gpu/drm/i915/i915_scatterlist.h | 5 + drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 248 ++ drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 56 ++ drivers/gpu/drm/i915/intel_memory_region.c| 55 +- drivers/gpu/drm/i915/intel_memory_region.h| 20 +- drivers/gpu/drm/i915/intel_region_ttm.c | 139 ++- drivers/gpu/drm/i915/intel_region_ttm.h | 16 +- drivers/gpu/drm/i915/selftests/i915_buddy.c | 789 ++ .../drm/i915/selftests/intel_memory_region.c | 170 ++-- drivers/gpu/drm/i915/selftests/mock_region.c | 28 +- 16 files changed, 2003 insertions(+), 253 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_buddy.c create mode 100644 drivers/gpu/drm/i915/i915_buddy.h create mode 100644 drivers/gpu/drm/i915/i915_ttm_buddy_manager.c create mode 100644 drivers/gpu/drm/i915/i915_ttm_buddy_manager.h create mode 100644 drivers/gpu/drm/i915/selftests/i915_buddy.c -- 2.26.3
[PATCH v3 1/7] drm/i915/ttm: add ttm_buddy_man
Add back our standalone i915_buddy allocator and integrate it into a
ttm_resource_manager. This will plug into our ttm backend for managing
device local-memory in the next couple of patches.
v2(Thomas):
- Return -ENOSPC from the buddy; ttm expects this in order to
trigger eviction
- Drop the unnecessary inline
- bo->page_alignment is in page units
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Acked-by: Thomas Hellström
---
drivers/gpu/drm/i915/Makefile | 2 +
drivers/gpu/drm/i915/i915_buddy.c | 412 +
drivers/gpu/drm/i915/i915_buddy.h | 133 +++
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 248 ++
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 56 ++
drivers/gpu/drm/i915/selftests/i915_buddy.c | 789 ++
6 files changed, 1640 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_buddy.c
create mode 100644 drivers/gpu/drm/i915/i915_buddy.h
create mode 100644 drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
create mode 100644 drivers/gpu/drm/i915/i915_ttm_buddy_manager.h
create mode 100644 drivers/gpu/drm/i915/selftests/i915_buddy.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f57dfc74d6ce..6c84e96ab26a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -162,6 +162,7 @@ gem-y += \
i915-y += \
$(gem-y) \
i915_active.o \
+ i915_buddy.o \
i915_cmd_parser.o \
i915_gem_evict.o \
i915_gem_gtt.o \
@@ -171,6 +172,7 @@ i915-y += \
i915_request.o \
i915_scheduler.o \
i915_trace_points.o \
+ i915_ttm_buddy_manager.o \
i915_vma.o \
intel_wopcm.o
diff --git a/drivers/gpu/drm/i915/i915_buddy.c
b/drivers/gpu/drm/i915/i915_buddy.c
new file mode 100644
index ..29dd7d0310c1
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_buddy.c
@@ -0,0 +1,412 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include
+
+#include "i915_buddy.h"
+
+#include "i915_gem.h"
+#include "i915_utils.h"
+
+static struct i915_buddy_block *i915_block_alloc(struct i915_buddy_mm *mm,
+struct i915_buddy_block
*parent,
+unsigned int order,
+u64 offset)
+{
+ struct i915_buddy_block *block;
+
+ GEM_BUG_ON(order > I915_BUDDY_MAX_ORDER);
+
+ block = kmem_cache_zalloc(mm->slab_blocks, GFP_KERNEL);
+ if (!block)
+ return NULL;
+
+ block->header = offset;
+ block->header |= order;
+ block->parent = parent;
+
+ GEM_BUG_ON(block->header & I915_BUDDY_HEADER_UNUSED);
+ return block;
+}
+
+static void i915_block_free(struct i915_buddy_mm *mm,
+ struct i915_buddy_block *block)
+{
+ kmem_cache_free(mm->slab_blocks, block);
+}
+
+static void mark_allocated(struct i915_buddy_block *block)
+{
+ block->header &= ~I915_BUDDY_HEADER_STATE;
+ block->header |= I915_BUDDY_ALLOCATED;
+
+ list_del(&block->link);
+}
+
+static void mark_free(struct i915_buddy_mm *mm,
+ struct i915_buddy_block *block)
+{
+ block->header &= ~I915_BUDDY_HEADER_STATE;
+ block->header |= I915_BUDDY_FREE;
+
+ list_add(&block->link,
+&mm->free_list[i915_buddy_block_order(block)]);
+}
+
+static void mark_split(struct i915_buddy_block *block)
+{
+ block->header &= ~I915_BUDDY_HEADER_STATE;
+ block->header |= I915_BUDDY_SPLIT;
+
+ list_del(&block->link);
+}
+
+int i915_buddy_init(struct i915_buddy_mm *mm, u64 size, u64 chunk_size)
+{
+ unsigned int i;
+ u64 offset;
+
+ if (size < chunk_size)
+ return -EINVAL;
+
+ if (chunk_size < PAGE_SIZE)
+ return -EINVAL;
+
+ if (!is_power_of_2(chunk_size))
+ return -EINVAL;
+
+ size = round_down(size, chunk_size);
+
+ mm->size = size;
+ mm->chunk_size = chunk_size;
+ mm->max_order = ilog2(size) - ilog2(chunk_size);
+
+ GEM_BUG_ON(mm->max_order > I915_BUDDY_MAX_ORDER);
+
+ mm->slab_blocks = KMEM_CACHE(i915_buddy_block, SLAB_HWCACHE_ALIGN);
+ if (!mm->slab_blocks)
+ return -ENOMEM;
+
+ mm->free_list = kmalloc_array(mm->max_order + 1,
+ sizeof(struct list_head),
+ GFP_KERNEL);
+ if (!mm->free_list)
+ goto out_destroy_slab;
+
+ for (i = 0; i <= mm->max_order; ++i)
+ INIT_LIST_HEAD(&mm->free_list[i]);
+
+ mm->n_roots = hweight64(size);
+
+ mm->roots = kmalloc_array(mm->n_roots,
+ sizeof(struct i915_buddy_block *),
+ GFP_KERNEL);
+ if (!mm->roots)
+ goto out_free_list;
+
+
[PATCH v3 2/7] drm/i915/ttm: add i915_sg_from_buddy_resource
We need to be able to build an sg table from our list of buddy blocks,
so that we can later plug this into our ttm backend, and replace our use
of the range manager.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_scatterlist.c | 80 +
drivers/gpu/drm/i915/i915_scatterlist.h | 5 ++
2 files changed, 85 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.c
b/drivers/gpu/drm/i915/i915_scatterlist.c
index 69e9e6c3135e..0959fe3efbbb 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.c
+++ b/drivers/gpu/drm/i915/i915_scatterlist.c
@@ -6,6 +6,9 @@
#include "i915_scatterlist.h"
+#include "i915_buddy.h"
+#include "i915_ttm_buddy_manager.h"
+
#include
#include
@@ -104,6 +107,83 @@ struct sg_table *i915_sg_from_mm_node(const struct
drm_mm_node *node,
return st;
}
+/**
+ * i915_sg_from_buddy_resource - Create an sg_table from a struct
+ * i915_buddy_block list
+ * @res: The i915_ttm_buddy_resource.
+ * @region_start: An offset to add to the dma addresses of the sg list.
+ *
+ * Create a struct sg_table, initializing it from struct i915_buddy_block list,
+ * taking a maximum segment length into account, splitting into segments
+ * if necessary.
+ *
+ * Return: A pointer to a kmalloced struct sg_table on success, negative
+ * error code cast to an error pointer on failure.
+ */
+struct sg_table *i915_sg_from_buddy_resource(struct ttm_resource *res,
+u64 region_start)
+{
+ struct i915_ttm_buddy_resource *bman_res = to_ttm_buddy_resource(res);
+ struct i915_buddy_mm *mm = bman_res->mm;
+ const u64 size = res->num_pages << PAGE_SHIFT;
+ const u64 max_segment = UINT_MAX;
+ struct list_head *blocks = &bman_res->blocks;
+ struct i915_buddy_block *block;
+ struct scatterlist *sg;
+ struct sg_table *st;
+ resource_size_t prev_end;
+
+ GEM_BUG_ON(list_empty(blocks));
+
+ st = kmalloc(sizeof(*st), GFP_KERNEL);
+ if (!st)
+ return ERR_PTR(-ENOMEM);
+
+ if (sg_alloc_table(st, size >> PAGE_SHIFT, GFP_KERNEL)) {
+ kfree(st);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ sg = st->sgl;
+ st->nents = 0;
+ prev_end = (resource_size_t)-1;
+
+ list_for_each_entry(block, blocks, link) {
+ u64 block_size, offset;
+
+ block_size = min_t(u64, size, i915_buddy_block_size(mm, block));
+ offset = i915_buddy_block_offset(block);
+
+ while (block_size) {
+ u64 len;
+
+ if (offset != prev_end || sg->length >= max_segment) {
+ if (st->nents)
+ sg = __sg_next(sg);
+
+ sg_dma_address(sg) = region_start + offset;
+ sg_dma_len(sg) = 0;
+ sg->length = 0;
+ st->nents++;
+ }
+
+ len = min(block_size, max_segment - sg->length);
+ sg->length += len;
+ sg_dma_len(sg) += len;
+
+ offset += len;
+ block_size -= len;
+
+ prev_end = offset;
+ }
+ }
+
+ sg_mark_end(sg);
+ i915_sg_trim(st);
+
+ return st;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/scatterlist.c"
#endif
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
b/drivers/gpu/drm/i915/i915_scatterlist.h
index 5acca45ea981..b8bd5925b03f 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.h
+++ b/drivers/gpu/drm/i915/i915_scatterlist.h
@@ -14,6 +14,7 @@
#include "i915_gem.h"
struct drm_mm_node;
+struct ttm_resource;
/*
* Optimised SGL iterator for GEM objects
@@ -145,4 +146,8 @@ bool i915_sg_trim(struct sg_table *orig_st);
struct sg_table *i915_sg_from_mm_node(const struct drm_mm_node *node,
u64 region_start);
+
+struct sg_table *i915_sg_from_buddy_resource(struct ttm_resource *res,
+u64 region_start);
+
#endif
--
2.26.3
[PATCH v3 3/7] drm/i915/ttm: Calculate the object placement at get_pages time
From: Thomas Hellström
Instead of relying on a static placement, calculate at get_pages() time.
This should work for LMEM regions and system for now. For stolen we need
to take preallocated range into account. That well be added later.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 69 +
drivers/gpu/drm/i915/intel_region_ttm.c | 8 ++-
drivers/gpu/drm/i915/intel_region_ttm.h | 2 +
3 files changed, 68 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 9dd6e4f69d53..73d52df8f2be 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -24,6 +24,11 @@
#define I915_TTM_PRIO_NO_PAGES 1
#define I915_TTM_PRIO_HAS_PAGES 2
+/*
+ * Size of struct ttm_place vector in on-stack struct ttm_placement allocs
+ */
+#define I915_TTM_MAX_PLACEMENTS 10
+
/**
* struct i915_ttm_tt - TTM page vector with additional private information
* @ttm: The base TTM page vector.
@@ -56,13 +61,6 @@ static const struct ttm_place lmem0_sys_placement_flags[] = {
}
};
-static struct ttm_placement i915_lmem0_placement = {
- .num_placement = 1,
- .placement = &lmem0_sys_placement_flags[0],
- .num_busy_placement = 1,
- .busy_placement = &lmem0_sys_placement_flags[0],
-};
-
static struct ttm_placement i915_sys_placement = {
.num_placement = 1,
.placement = &lmem0_sys_placement_flags[1],
@@ -72,6 +70,55 @@ static struct ttm_placement i915_sys_placement = {
static void i915_ttm_adjust_lru(struct drm_i915_gem_object *obj);
+static enum ttm_caching
+i915_ttm_select_tt_caching(const struct drm_i915_gem_object *obj)
+{
+ /*
+* Objects only allowed in system get cached cpu-mappings.
+* Other objects get WC mapping for now. Even if in system.
+*/
+ if (obj->mm.region->type == INTEL_MEMORY_SYSTEM &&
+ obj->mm.n_placements <= 1)
+ return ttm_cached;
+
+ return ttm_write_combined;
+}
+
+static void
+i915_ttm_place_from_region(const struct intel_memory_region *mr,
+ struct ttm_place *place)
+{
+ memset(place, 0, sizeof(*place));
+ place->mem_type = intel_region_to_ttm_type(mr);
+}
+
+static void
+i915_ttm_placement_from_obj(const struct drm_i915_gem_object *obj,
+ struct ttm_place *requested,
+ struct ttm_place *busy,
+ struct ttm_placement *placement)
+{
+ unsigned int i;
+ unsigned int num_allowed = obj->mm.n_placements;
+
+ placement->num_placement = 1;
+ i915_ttm_place_from_region(num_allowed ? obj->mm.placements[0] :
+ obj->mm.region, requested);
+
+ /* Cache this on object? */
+ placement->num_busy_placement = num_allowed;
+ for (i = 0; i < placement->num_busy_placement; ++i)
+ i915_ttm_place_from_region(obj->mm.placements[i], busy + i);
+
+ if (num_allowed == 0) {
+ *busy = *requested;
+ placement->num_busy_placement = 1;
+ }
+
+ placement->placement = requested;
+ placement->busy_placement = busy;
+}
+
static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
uint32_t page_flags)
{
@@ -89,7 +136,8 @@ static struct ttm_tt *i915_ttm_tt_create(struct
ttm_buffer_object *bo,
man->use_tt)
page_flags |= TTM_PAGE_FLAG_ZERO_ALLOC;
- ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags, ttm_write_combined);
+ ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags,
+ i915_ttm_select_tt_caching(obj));
if (ret) {
kfree(i915_tt);
return NULL;
@@ -414,10 +462,13 @@ static int i915_ttm_get_pages(struct drm_i915_gem_object
*obj)
.no_wait_gpu = false,
};
struct sg_table *st;
+ struct ttm_place requested, busy[I915_TTM_MAX_PLACEMENTS];
+ struct ttm_placement placement;
int ret;
/* Move to the requested placement. */
- ret = ttm_bo_validate(bo, &i915_lmem0_placement, &ctx);
+ i915_ttm_placement_from_obj(obj, &requested, busy, &placement);
+ ret = ttm_bo_validate(bo, &placement, &ctx);
if (ret)
return ret == -ENOSPC ? -ENXIO : ret;
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 27fe0668d094..5a664f6cc93f 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -50,12 +50,16 @@ void intel_region_ttm_device_fini(struct drm_i915_private
*dev_priv)
* driver-private types for now, reserving TTM_PL_VRAM for stolen
* memory and TTM_PL_TT for GGTT use if decided to implement this.
*/
-static int intel_region_to_ttm_type(struct intel_memory_region *mem)
+
[PATCH v3 4/7] drm/i915/ttm: pass along the I915_BO_ALLOC_CONTIGUOUS
Currently we just ignore the I915_BO_ALLOC_CONTIGUOUS flag, which is
fine since everything is already contiguous with the ttm range manager.
However in the next patch we want to switch over to the ttm buddy
manager, where allocations are by default not contiguous.
v2(Thomas):
- Forward ALLOC_CONTIG for all regions
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 73d52df8f2be..c612275c36c9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -86,10 +86,14 @@ i915_ttm_select_tt_caching(const struct drm_i915_gem_object
*obj)
static void
i915_ttm_place_from_region(const struct intel_memory_region *mr,
- struct ttm_place *place)
+ struct ttm_place *place,
+ unsigned int flags)
{
memset(place, 0, sizeof(*place));
place->mem_type = intel_region_to_ttm_type(mr);
+
+ if (flags & I915_BO_ALLOC_CONTIGUOUS)
+ place->flags = TTM_PL_FLAG_CONTIGUOUS;
}
static void
@@ -100,15 +104,16 @@ i915_ttm_placement_from_obj(const struct
drm_i915_gem_object *obj,
{
unsigned int i;
unsigned int num_allowed = obj->mm.n_placements;
+ unsigned int flags = obj->flags;
placement->num_placement = 1;
i915_ttm_place_from_region(num_allowed ? obj->mm.placements[0] :
- obj->mm.region, requested);
+ obj->mm.region, requested, flags);
/* Cache this on object? */
placement->num_busy_placement = num_allowed;
for (i = 0; i < placement->num_busy_placement; ++i)
- i915_ttm_place_from_region(obj->mm.placements[i], busy + i);
+ i915_ttm_place_from_region(obj->mm.placements[i], busy + i,
flags);
if (num_allowed == 0) {
*busy = *requested;
--
2.26.3
[PATCH v3 5/7] drm/i915/ttm: remove node usage in our naming
Now that ttm_resource_manager just returns a generic ttm_resource we
don't need to reference the mm_node stuff anymore which mostly only
makes sense for drm_mm_node. In the next few patches we want switch over
to the ttm_buddy_man which is just another type of ttm_resource so
reflect that in the naming.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 5 ++--
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
drivers/gpu/drm/i915/intel_region_ttm.c | 30 +--
drivers/gpu/drm/i915/intel_region_ttm.h | 14 -
drivers/gpu/drm/i915/selftests/mock_region.c | 16 +-
5 files changed, 34 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 2a23b77424b3..3a2d9ecf8e03 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -265,9 +265,10 @@ struct drm_i915_gem_object {
struct intel_memory_region *region;
/**
-* Memory manager node allocated for this object.
+* Memory manager resource allocated for this object. Only
+* needed for the mock region.
*/
- void *st_mm_node;
+ struct ttm_resource *res;
/**
* Element within memory_region->objects or region->purgeable
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index c612275c36c9..55045310a300 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -332,7 +332,7 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
if (man->use_tt)
return i915_ttm_tt_get_st(bo->ttm);
- return intel_region_ttm_node_to_st(obj->mm.region, res->mm_node);
+ return intel_region_ttm_resource_to_st(obj->mm.region, res);
}
static int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 5a664f6cc93f..f9d616544728 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -68,7 +68,7 @@ int intel_region_to_ttm_type(const struct intel_memory_region
*mem)
}
static struct ttm_resource *
-intel_region_ttm_node_reserve(struct intel_memory_region *mem,
+intel_region_ttm_resource_reserve(struct intel_memory_region *mem,
resource_size_t offset,
resource_size_t size)
{
@@ -100,12 +100,12 @@ intel_region_ttm_node_reserve(struct intel_memory_region
*mem,
}
/**
- * intel_region_ttm_node_free - Free a node allocated from a resource manager
- * @mem: The region the node was allocated from.
- * @node: The opaque node representing an allocation.
+ * intel_region_ttm_resource_free - Free a resource allocated from a resource
manager
+ * @mem: The region the resource was allocated from.
+ * @res: The opaque resource representing an allocation.
*/
-void intel_region_ttm_node_free(struct intel_memory_region *mem,
- struct ttm_resource *res)
+void intel_region_ttm_resource_free(struct intel_memory_region *mem,
+ struct ttm_resource *res)
{
struct ttm_resource_manager *man = mem->region_private;
@@ -113,8 +113,8 @@ void intel_region_ttm_node_free(struct intel_memory_region
*mem,
}
static const struct intel_memory_region_private_ops priv_ops = {
- .reserve = intel_region_ttm_node_reserve,
- .free = intel_region_ttm_node_free,
+ .reserve = intel_region_ttm_resource_reserve,
+ .free = intel_region_ttm_resource_free,
};
int intel_region_ttm_init(struct intel_memory_region *mem)
@@ -157,10 +157,10 @@ void intel_region_ttm_fini(struct intel_memory_region
*mem)
}
/**
- * intel_region_ttm_node_to_st - Convert an opaque TTM resource manager node
+ * intel_region_ttm_resource_to_st - Convert an opaque TTM resource manager
resource
* to an sg_table.
* @mem: The memory region.
- * @node: The resource manager node obtained from the TTM resource manager.
+ * @res: The resource manager resource obtained from the TTM resource manager.
*
* The gem backends typically use sg-tables for operations on the underlying
* io_memory. So provide a way for the backends to translate the
@@ -168,8 +168,8 @@ void intel_region_ttm_fini(struct intel_memory_region *mem)
*
* Return: A malloced sg_table on success, an error pointer on failure.
*/
-struct sg_table *intel_region_ttm_node_to_st(struct intel_memory_region *mem,
-struct ttm_resource *res)
+struct sg_table *intel_region_ttm_resource_to_st(struct intel_memory_region
*mem,
+struct ttm_resource *res)
[PATCH v3 6/7] drm/i915/ttm: switch over to ttm_buddy_man
Move back to the buddy allocator for managing device local memory, and
restore the lost mock selftests. Keep around the range manager related
bits, since we likely need this for managing stolen at some point. For
stolen we also don't need to reserve anything so no need to support a
generic reserve interface.
v2(Thomas):
- bo->page_alignment is in page units, not bytes
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 20 +--
drivers/gpu/drm/i915/intel_memory_region.c| 55 +-
drivers/gpu/drm/i915/intel_memory_region.h| 17 --
drivers/gpu/drm/i915/intel_region_ttm.c | 117 +---
.../drm/i915/selftests/intel_memory_region.c | 170 --
drivers/gpu/drm/i915/selftests/mock_region.c | 12 +-
6 files changed, 177 insertions(+), 214 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 55045310a300..6e45e564e732 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -181,11 +181,7 @@ static bool i915_ttm_eviction_valuable(struct
ttm_buffer_object *bo,
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
/* Will do for now. Our pinned objects are still on TTM's LRU lists */
- if (!i915_gem_object_evictable(obj))
- return false;
-
- /* This isn't valid with a buddy allocator */
- return ttm_bo_eviction_valuable(bo, place);
+ return i915_gem_object_evictable(obj);
}
static void i915_ttm_evict_flags(struct ttm_buffer_object *bo,
@@ -657,20 +653,8 @@ int __i915_gem_ttm_object_init(struct intel_memory_region
*mem,
static struct lock_class_key lock_class;
struct drm_i915_private *i915 = mem->i915;
enum ttm_bo_type bo_type;
- size_t alignment = 0;
int ret;
- /* Adjust alignment to GPU- and CPU huge page sizes. */
-
- if (mem->is_range_manager) {
- if (size >= SZ_1G)
- alignment = SZ_1G >> PAGE_SHIFT;
- else if (size >= SZ_2M)
- alignment = SZ_2M >> PAGE_SHIFT;
- else if (size >= SZ_64K)
- alignment = SZ_64K >> PAGE_SHIFT;
- }
-
drm_gem_private_object_init(&i915->drm, &obj->base, size);
i915_gem_object_init(obj, &i915_gem_ttm_obj_ops, &lock_class, flags);
i915_gem_object_init_memory_region(obj, mem);
@@ -692,7 +676,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region
*mem,
*/
obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
ret = ttm_bo_init(&i915->bdev, i915_gem_to_ttm(obj), size,
- bo_type, &i915_sys_placement, alignment,
+ bo_type, &i915_sys_placement, 1,
true, NULL, NULL, i915_ttm_bo_destroy);
if (!ret)
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
b/drivers/gpu/drm/i915/intel_memory_region.c
index 12fb5423fd5e..df59f884d37c 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -5,6 +5,7 @@
#include "intel_memory_region.h"
#include "i915_drv.h"
+#include "i915_ttm_buddy_manager.h"
static const struct {
u16 class;
@@ -28,11 +29,6 @@ static const struct {
},
};
-struct intel_region_reserve {
- struct list_head link;
- struct ttm_resource *res;
-};
-
struct intel_memory_region *
intel_memory_region_lookup(struct drm_i915_private *i915,
u16 class, u16 instance)
@@ -63,27 +59,6 @@ intel_memory_region_by_type(struct drm_i915_private *i915,
return NULL;
}
-/**
- * intel_memory_region_unreserve - Unreserve all previously reserved
- * ranges
- * @mem: The region containing the reserved ranges.
- */
-void intel_memory_region_unreserve(struct intel_memory_region *mem)
-{
- struct intel_region_reserve *reserve, *next;
-
- if (!mem->priv_ops || !mem->priv_ops->free)
- return;
-
- mutex_lock(&mem->mm_lock);
- list_for_each_entry_safe(reserve, next, &mem->reserved, link) {
- list_del(&reserve->link);
- mem->priv_ops->free(mem, reserve->res);
- kfree(reserve);
- }
- mutex_unlock(&mem->mm_lock);
-}
-
/**
* intel_memory_region_reserve - Reserve a memory range
* @mem: The region for which we want to reserve a range.
@@ -96,28 +71,11 @@ int intel_memory_region_reserve(struct intel_memory_region
*mem,
resource_size_t offset,
resource_size_t size)
{
- int ret;
- struct intel_region_reserve *reserve;
-
- if (!mem->priv_ops || !mem->priv_ops->reserve)
- return -EINVAL;
-
- reserve = kzalloc(sizeof(*reserve), GFP_KERNEL);
- if (!reserve)
- return -ENOMEM;
+ struct
[PATCH v3 7/7] drm/i915/ttm: restore min_page_size behaviour
We now have bo->page_alignment which perfectly describes what we need if
we have min page size restrictions for lmem. We can also drop the flag
here, since this is the default behaviour for all objects.
v2(Thomas):
- bo->page_alignment is in page units
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 4 ++--
drivers/gpu/drm/i915/intel_memory_region.h | 3 +--
drivers/gpu/drm/i915/intel_region_ttm.c | 2 +-
drivers/gpu/drm/i915/selftests/mock_region.c | 2 +-
4 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 6e45e564e732..76a3b75b716d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -676,9 +676,9 @@ int __i915_gem_ttm_object_init(struct intel_memory_region
*mem,
*/
obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
ret = ttm_bo_init(&i915->bdev, i915_gem_to_ttm(obj), size,
- bo_type, &i915_sys_placement, 1,
+ bo_type, &i915_sys_placement,
+ mem->min_page_size >> PAGE_SHIFT,
true, NULL, NULL, i915_ttm_bo_destroy);
-
if (!ret)
obj->ttm.created = true;
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h
b/drivers/gpu/drm/i915/intel_memory_region.h
index b04fb22726d9..2be8433d373a 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -40,8 +40,7 @@ enum intel_region_id {
#define REGION_STOLEN_SMEM BIT(INTEL_REGION_STOLEN_SMEM)
#define REGION_STOLEN_LMEM BIT(INTEL_REGION_STOLEN_LMEM)
-#define I915_ALLOC_MIN_PAGE_SIZE BIT(0)
-#define I915_ALLOC_CONTIGUOUS BIT(1)
+#define I915_ALLOC_CONTIGUOUS BIT(0)
#define for_each_memory_region(mr, i915, id) \
for (id = 0; id < ARRAY_SIZE((i915)->mm.regions); id++) \
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 816e08239a28..d3de1a2113e5 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -166,7 +166,7 @@ intel_region_ttm_resource_alloc(struct intel_memory_region
*mem,
int ret;
mock_bo.base.size = size;
- mock_bo.page_alignment = 1;
+ mock_bo.page_alignment = mem->min_page_size >> PAGE_SHIFT;
place.flags = flags;
ret = man->func->alloc(man, &mock_bo, &place, &res);
diff --git a/drivers/gpu/drm/i915/selftests/mock_region.c
b/drivers/gpu/drm/i915/selftests/mock_region.c
index 69e21914edee..8a096a40e0d0 100644
--- a/drivers/gpu/drm/i915/selftests/mock_region.c
+++ b/drivers/gpu/drm/i915/selftests/mock_region.c
@@ -28,7 +28,7 @@ static int mock_region_get_pages(struct drm_i915_gem_object
*obj)
struct sg_table *pages;
int err;
- flags = I915_ALLOC_MIN_PAGE_SIZE;
+ flags = 0;
if (obj->flags & I915_BO_ALLOC_CONTIGUOUS)
flags |= TTM_PL_FLAG_CONTIGUOUS;
--
2.26.3
RE: [PATCH] drm/ttm: fix deref of bo->ttm without holding the lock v2
Looks good for me.
Reviewed-by: Huang Rui
-Original Message-
From: Christian König
Sent: Monday, June 7, 2021 8:52 PM
To: dri-devel@lists.freedesktop.org; Pan, Xinhui ; Das,
Nirmoy ; Huang, Ray
Cc: Thomas Hellström
Subject: Re: [PATCH] drm/ttm: fix deref of bo->ttm without holding the lock v2
Am 28.05.21 um 15:06 schrieb Thomas Hellström:
>
> On 5/28/21 3:00 PM, Christian König wrote:
>> We need to grab the resv lock first before doing that check.
>>
>> v2 (chk): simplify the change for -fixes
>>
>> Signed-off-by: Christian König
>> Signed-off-by: Thomas Hellström
>
> Hmm, OK, but this doesn't fix the swapped-bo-not-on-lru and
> unpopulating from swap_notify issues. Are you planning a follow up
> patch for those?
As discussed in a separate thread this needs to be applied as needed when the
DG1 branch is merged.
Xinhui, Nirmoy, Rui can anybody give be an rb/ab so that I can push this?
Thanks,
Christian.
>
> Thanks,
>
> Thomas
>
>> ---
>> drivers/gpu/drm/ttm/ttm_bo.c | 5 -
>> drivers/gpu/drm/ttm/ttm_device.c | 8 +---
>> 2 files changed, 5 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
>> b/drivers/gpu/drm/ttm/ttm_bo.c index cfd0b9292397..ebcffe794adb
>> 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -1172,7 +1172,10 @@ int ttm_bo_swapout(struct ttm_buffer_object
>> *bo, struct ttm_operation_ctx *ctx,
>> if (!ttm_bo_evict_swapout_allowable(bo, ctx, &locked, NULL))
>> return -EBUSY;
>> - if (!ttm_bo_get_unless_zero(bo)) {
>> + if (!bo->ttm || !ttm_tt_is_populated(bo->ttm) ||
>> + bo->ttm->page_flags & TTM_PAGE_FLAG_SG ||
>> + bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED ||
>> + !ttm_bo_get_unless_zero(bo)) {
>> if (locked)
>> dma_resv_unlock(bo->base.resv);
>> return -EBUSY;
>> diff --git a/drivers/gpu/drm/ttm/ttm_device.c
>> b/drivers/gpu/drm/ttm/ttm_device.c
>> index a1dcf7d55c90..3d9c62b93e29 100644
>> --- a/drivers/gpu/drm/ttm/ttm_device.c
>> +++ b/drivers/gpu/drm/ttm/ttm_device.c
>> @@ -143,14 +143,8 @@ int ttm_device_swapout(struct ttm_device *bdev,
>> struct ttm_operation_ctx *ctx,
>> for (j = 0; j < TTM_MAX_BO_PRIORITY; ++j) {
>> list_for_each_entry(bo, &man->lru[j], lru) {
>> - uint32_t num_pages;
>> + uint32_t num_pages = PFN_UP(bo->base.size);
>> - if (!bo->ttm || !ttm_tt_is_populated(bo->ttm) ||
>> - bo->ttm->page_flags & TTM_PAGE_FLAG_SG ||
>> - bo->ttm->page_flags & TTM_PAGE_FLAG_SWAPPED)
>> - continue;
>> -
>> - num_pages = bo->ttm->num_pages;
>> ret = ttm_bo_swapout(bo, ctx, gfp_flags);
>> /* ttm_bo_swapout has dropped the lru_lock */
>> if (!ret)
Re: linux-next: build failure after merge of the drm-misc tree
Am 2021-06-08 um 2:55 a.m. schrieb Christian König:
> Hi Felix,
>
> that should already be fixed in drm-tip as part of the merge of the
> TTM changes.
No, the preempt_mgr doesn't exist in drm-misc-next. It does exist in
drm-next, but that doesn't seem to have the TTM changes yet.
Is there another DRM branch or repository that you're referring to with
drm-tip?
Regards,
Felix
>
> Regards,
> Christian.
>
> Am 08.06.21 um 07:37 schrieb Felix Kuehling:
>> Hi Christian,
>>
>> I based amdgpu_preempt_mgr on amdgpu_gtt_mgr and now I'm looking at what
>> changed there. Looks like I'll need to create a dummy node in
>> amdgpu_preempt_mgr_new to satisfy TTM, and free it in
>> amdgpu_preempt_mgr_del.
>>
>> Thanks,
>> Felix
>>
>>
>> Am 2021-06-07 um 10:50 p.m. schrieb Stephen Rothwell:
>>> Hi all,
>>>
>>> After merging the drm-misc tree, today's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>>
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c: In function
>>> 'amdgpu_preempt_mgr_new':
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:75:5: error: 'struct
>>> ttm_resource' has no member named 'mm_node'
>>> 75 | mem->mm_node = NULL;
>>> | ^~
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c: At top level:
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:129:11: error:
>>> initialization of 'int (*)(struct ttm_resource_manager *, struct
>>> ttm_buffer_object *, const struct ttm_place *, struct ttm_resource
>>> **)' from incompatible pointer type 'int (*)(struct
>>> ttm_resource_manager *, struct ttm_buffer_object *, const struct
>>> ttm_place *, struct ttm_resource *)'
>>> [-Werror=incompatible-pointer-types]
>>> 129 | .alloc = amdgpu_preempt_mgr_new,
>>> | ^~
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:129:11: note: (near
>>> initialization for 'amdgpu_preempt_mgr_func.alloc')
>>>
>>> Caused by commit
>>>
>>> cb1c81467af3 ("drm/ttm: flip the switch for driver allocated
>>> resources v2")
>>>
>>> from the drm-misc tree interacting with commit
>>>
>>> b453e42a6e8b ("drm/amdgpu: Add new placement for preemptible SG
>>> BOs")
>>>
>>> from the drm tree.
>>>
>>> I don't know how to fix this, so I added the following hack (a better
>>> fix would be nice):
>>>
>>> From: Stephen Rothwell
>>> Date: Tue, 8 Jun 2021 12:41:16 +1000
>>> Subject: [PATCH] hack fix up for needed amdgpu_preempt_mgr_new() fix up
>>>
>>> Signed-off-by: Stephen Rothwell
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
>>> index d607f314cc1b..e1a7b3e967b9 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
>>> @@ -66,14 +66,16 @@ static DEVICE_ATTR_RO(mem_info_preempt_used);
>>> static int amdgpu_preempt_mgr_new(struct ttm_resource_manager *man,
>>> struct ttm_buffer_object *tbo,
>>> const struct ttm_place *place,
>>> - struct ttm_resource *mem)
>>> + struct ttm_resource **res)
>>> {
>>> +#if 0
>>> struct amdgpu_preempt_mgr *mgr = to_preempt_mgr(man);
>>> atomic64_add(mem->num_pages, &mgr->used);
>>> mem->mm_node = NULL;
>>> mem->start = AMDGPU_BO_INVALID_OFFSET;
>>> +#endif
>>> return 0;
>>> }
>>>
>
Re: [PATCH] drm: Don't test for IRQ support in VBLANK ioctls
Hi Am 08.06.21 um 11:23 schrieb Daniel Vetter: On Tue, Jun 8, 2021 at 11:18 AM Daniel Vetter wrote: On Tue, Jun 08, 2021 at 11:03:01AM +0200, Thomas Zimmermann wrote: Replace the IRQ check in VBLANK ioctls with a check for vblank support. IRQs might be enabled wthout vblanking being supported. Nah, or if they are, that's a broken driver. irq_enabled here really only means vblank_irq_enabled (maybe we should rename it). I'd like to understand the motivation here a bit better to make sure we'r not just papering over a driver bug. It's not about a driver bug. For using simpledrm early during boot, at least some parts of DRM need to be built into the kernel binary. I'm looking for ways to reduce the size of the DRM-core objects. One low-hanging fruit is all the HW mid-layers that are present in DRM. Moving them behind CONFIG_DRM_LEGACY reduces the size of the binary for most of us. Few build with UMS support. The IRQ code is the final HW mid-layer that is still present. I have a patchset that pushes drm_irq_install() et al into KMS drivers and moves drm_irq.o behind CONFIG_DRM_LEGACY. But now all KMS drivers have to maintain the irq_enabled flag, even though it's not used by most of them. And in the DRM core (sans legacy) only these 3 VBLANK ioctls depend on it. The patch attemps to replace the core's dependency, so that KMS drivers don't have to maintain irq_enabled. Most can then use plain request_irq()/free_irq(). VBLANK support is already test-able by calling the rsp function. Or there's per-CRTC state IIRC. If there really is a need for an additional global flag, it should be enabled via drm_vblank_init(), but not drm_irq_install(). Also as-is this breaks legacy drivers, which do enable/disable irqs at runtime with the legacy IRQ_CONTROL ioctl, so we can't just throw this out. Hence this cleanup here is only ok for non-legacy drivers. That only affects drm_wait_vblank_ioctl(). We could have make the test a bit more fancy to only test this field for legacy drivers. Finally if you do this cleanup I think we should go through drivers and drop the irq_enabled = true settings that are littered around. For that cleanup I think this patch makes sense. As I said, it was the initial plan. For a quick grepping, drivers appear to use irq_enabled mostly redundantly to the core. For the few drivers that might need irq_enabled, we could duplicate it in the local device structure. Best regards Thomas I forgot to add: We already do this check that you're adding here because later on we validate the provided crtc index against dev->num_crtcs. vblank support is confusing because it lives both in a kms and legacy driver world. -Daniel This change also removes the DRM framework's only dependency on IRQ state for non-legacy drivers. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_irq.c| 10 +++--- drivers/gpu/drm/drm_vblank.c | 6 +++--- 2 files changed, 6 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index c3bd664ea733..1d7785721323 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -74,10 +74,8 @@ * only supports devices with a single interrupt on the main device stored in * &drm_device.dev and set as the device paramter in drm_dev_alloc(). * - * These IRQ helpers are strictly optional. Drivers which roll their own only - * need to set &drm_device.irq_enabled to signal the DRM core that vblank - * interrupts are working. Since these helpers don't automatically clean up the - * requested interrupt like e.g. devm_request_irq() they're not really + * These IRQ helpers are strictly optional. Since these helpers don't automatically + * clean up the requested interrupt like e.g. devm_request_irq() they're not really * recommended. */ @@ -91,9 +89,7 @@ * and after the installation. * * This is the simplified helper interface provided for drivers with no special - * needs. Drivers which need to install interrupt handlers for multiple - * interrupts must instead set &drm_device.irq_enabled to signal the DRM core - * that vblank interrupts are available. + * needs. * * @irq must match the interrupt number that would be passed to request_irq(), * if called directly instead of using this helper function. diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index 3417e1ac7918..165286fef478 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/drivers/gpu/drm/drm_vblank.c @@ -1748,7 +1748,7 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void *data, unsigned int pipe_index; unsigned int flags, pipe, high_pipe; - if (!dev->irq_enabled) + if (!drm_dev_has_vblank(dev)) return -EOPNOTSUPP; if (vblwait->request.type & _DRM_VBLANK_SIGNAL) @@ -2023,7 +2023,7 @@ int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data, if (!drm_core_check_feature(dev, DRIVER_MODESET))
Re: [RESEND PATCH v4 1/6] iommu/arm-smmu: Add support for driver IOMMU fault handlers
On Wed, Jun 02, 2021 at 09:52:44AM -0700, Rob Clark wrote: > From: Jordan Crouse > > Call report_iommu_fault() to allow upper-level drivers to register their > own fault handlers. > > Signed-off-by: Jordan Crouse > Signed-off-by: Rob Clark > --- > drivers/iommu/arm/arm-smmu/arm-smmu.c | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c > b/drivers/iommu/arm/arm-smmu/arm-smmu.c > index 6f72c4d208ca..b4b32d31fc06 100644 > --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c > +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c > @@ -408,6 +408,7 @@ static irqreturn_t arm_smmu_context_fault(int irq, void > *dev) > struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain); > struct arm_smmu_device *smmu = smmu_domain->smmu; > int idx = smmu_domain->cfg.cbndx; > + int ret; > > fsr = arm_smmu_cb_read(smmu, idx, ARM_SMMU_CB_FSR); > if (!(fsr & ARM_SMMU_FSR_FAULT)) > @@ -417,8 +418,12 @@ static irqreturn_t arm_smmu_context_fault(int irq, void > *dev) > iova = arm_smmu_cb_readq(smmu, idx, ARM_SMMU_CB_FAR); > cbfrsynra = arm_smmu_gr1_read(smmu, ARM_SMMU_GR1_CBFRSYNRA(idx)); > > - dev_err_ratelimited(smmu->dev, > - "Unhandled context fault: fsr=0x%x, iova=0x%08lx, fsynr=0x%x, > cbfrsynra=0x%x, cb=%d\n", > + ret = report_iommu_fault(domain, NULL, iova, > + fsynr & ARM_SMMU_FSYNR0_WNR ? IOMMU_FAULT_WRITE : > IOMMU_FAULT_READ); > + > + if (ret == -ENOSYS) > + dev_err_ratelimited(smmu->dev, > + "Unhandled context fault: fsr=0x%x, iova=0x%08lx, fsynr=0x%x, > cbfrsynra=0x%x, cb=%d\n", > fsr, iova, fsynr, cbfrsynra, idx); Acked-by: Will Deacon Will
Re: linux-next: build failure after merge of the drm-misc tree
Am 08.06.21 um 09:06 schrieb Felix Kuehling:
Am 2021-06-08 um 2:55 a.m. schrieb Christian König:
Hi Felix,
that should already be fixed in drm-tip as part of the merge of the
TTM changes.
No, the preempt_mgr doesn't exist in drm-misc-next. It does exist in
drm-next, but that doesn't seem to have the TTM changes yet.
Is there another DRM branch or repository that you're referring to with
drm-tip?
drm-tip is an integration branch for conflict resolution.
E.g. when we have changes in drm-misc-next which break when we merge
with drm-next I'm informed and need to provide a conflict resolution patch.
This is automatically applied when drm-next and drm-misc-next are merged
together again.
It just looks like that drm-next and drm-misc-next are merged manually
into linux-next and then the conflict resolution doesn't apply and
everything breaks into pieces.
Adding Daniel as well. How should that be handled? Should we merge
drm-misc-next into drm-next now?
Thanks,
Christian.
Regards,
Fel
Regards,
Christian.
Am 08.06.21 um 07:37 schrieb Felix Kuehling:
Hi Christian,
I based amdgpu_preempt_mgr on amdgpu_gtt_mgr and now I'm looking at what
changed there. Looks like I'll need to create a dummy node in
amdgpu_preempt_mgr_new to satisfy TTM, and free it in
amdgpu_preempt_mgr_del.
Thanks,
Felix
Am 2021-06-07 um 10:50 p.m. schrieb Stephen Rothwell:
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c: In function
'amdgpu_preempt_mgr_new':
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:75:5: error: 'struct
ttm_resource' has no member named 'mm_node'
75 | mem->mm_node = NULL;
| ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c: At top level:
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:129:11: error:
initialization of 'int (*)(struct ttm_resource_manager *, struct
ttm_buffer_object *, const struct ttm_place *, struct ttm_resource
**)' from incompatible pointer type 'int (*)(struct
ttm_resource_manager *, struct ttm_buffer_object *, const struct
ttm_place *, struct ttm_resource *)'
[-Werror=incompatible-pointer-types]
129 | .alloc = amdgpu_preempt_mgr_new,
| ^~
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c:129:11: note: (near
initialization for 'amdgpu_preempt_mgr_func.alloc')
Caused by commit
cb1c81467af3 ("drm/ttm: flip the switch for driver allocated
resources v2")
from the drm-misc tree interacting with commit
b453e42a6e8b ("drm/amdgpu: Add new placement for preemptible SG
BOs")
from the drm tree.
I don't know how to fix this, so I added the following hack (a better
fix would be nice):
From: Stephen Rothwell
Date: Tue, 8 Jun 2021 12:41:16 +1000
Subject: [PATCH] hack fix up for needed amdgpu_preempt_mgr_new() fix up
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
index d607f314cc1b..e1a7b3e967b9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c
@@ -66,14 +66,16 @@ static DEVICE_ATTR_RO(mem_info_preempt_used);
static int amdgpu_preempt_mgr_new(struct ttm_resource_manager *man,
struct ttm_buffer_object *tbo,
const struct ttm_place *place,
- struct ttm_resource *mem)
+ struct ttm_resource **res)
{
+#if 0
struct amdgpu_preempt_mgr *mgr = to_preempt_mgr(man);
atomic64_add(mem->num_pages, &mgr->used);
mem->mm_node = NULL;
mem->start = AMDGPU_BO_INVALID_OFFSET;
+#endif
return 0;
}
[PATCH] drm/v3d: Expose performance counters to userspace
The V3D engine has several hardware performance counters that can of
interest for userspace performance analysis tools.
This exposes new ioctls to create and destroy performance monitor
objects, as well as to query the counter values.
Each created performance monitor object has an ID that can be attached
to CL/CSD submissions, so the driver enables the requested counters when
the job is submitted, and updates the performance monitor values when
the job is done.
It is up to the user to ensure all the jobs have been finished before
getting the performance monitor values. It is also up to the user to
properly synchronize BCL jobs when submitting jobs with different
performance monitors attached.
Cc: Daniel Vetter
Cc: David Airlie
Cc: Emma Anholt
To: dri-devel@lists.freedesktop.org
Signed-off-by: Juan A. Suarez Romero
---
drivers/gpu/drm/v3d/Makefile | 1 +
drivers/gpu/drm/v3d/v3d_drv.c | 8 ++
drivers/gpu/drm/v3d/v3d_drv.h | 63 +
drivers/gpu/drm/v3d/v3d_gem.c | 31 +
drivers/gpu/drm/v3d/v3d_perfmon.c | 213 ++
drivers/gpu/drm/v3d/v3d_regs.h| 2 +
drivers/gpu/drm/v3d/v3d_sched.c | 16 +++
include/uapi/drm/v3d_drm.h| 136 +++
8 files changed, 470 insertions(+)
create mode 100644 drivers/gpu/drm/v3d/v3d_perfmon.c
diff --git a/drivers/gpu/drm/v3d/Makefile b/drivers/gpu/drm/v3d/Makefile
index db4cfc155821..e8b314137020 100644
--- a/drivers/gpu/drm/v3d/Makefile
+++ b/drivers/gpu/drm/v3d/Makefile
@@ -9,6 +9,7 @@ v3d-y := \
v3d_gem.o \
v3d_irq.o \
v3d_mmu.o \
+ v3d_perfmon.o \
v3d_trace_points.o \
v3d_sched.o
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 99e22beea90b..9403c3b36aca 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3d/v3d_drv.c
@@ -94,6 +94,9 @@ static int v3d_get_param_ioctl(struct drm_device *dev, void
*data,
case DRM_V3D_PARAM_SUPPORTS_CACHE_FLUSH:
args->value = 1;
return 0;
+ case DRM_V3D_PARAM_SUPPORTS_PERFMON:
+ args->value = (v3d->ver >= 40);
+ return 0;
default:
DRM_DEBUG("Unknown parameter %d\n", args->param);
return -EINVAL;
@@ -121,6 +124,7 @@ v3d_open(struct drm_device *dev, struct drm_file *file)
1, NULL);
}
+ v3d_perfmon_open_file(v3d_priv);
file->driver_priv = v3d_priv;
return 0;
@@ -136,6 +140,7 @@ v3d_postclose(struct drm_device *dev, struct drm_file *file)
drm_sched_entity_destroy(&v3d_priv->sched_entity[q]);
}
+ v3d_perfmon_close_file(v3d_priv);
kfree(v3d_priv);
}
@@ -156,6 +161,9 @@ static const struct drm_ioctl_desc v3d_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(V3D_GET_BO_OFFSET, v3d_get_bo_offset_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(V3D_SUBMIT_TFU, v3d_submit_tfu_ioctl,
DRM_RENDER_ALLOW | DRM_AUTH),
DRM_IOCTL_DEF_DRV(V3D_SUBMIT_CSD, v3d_submit_csd_ioctl,
DRM_RENDER_ALLOW | DRM_AUTH),
+ DRM_IOCTL_DEF_DRV(V3D_PERFMON_CREATE, v3d_perfmon_create_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(V3D_PERFMON_DESTROY, v3d_perfmon_destroy_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(V3D_PERFMON_GET_VALUES, v3d_perfmon_get_values_ioctl,
DRM_RENDER_ALLOW),
};
static const struct drm_driver v3d_drm_driver = {
diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 8a390738d65b..270134779073 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -37,6 +37,40 @@ struct v3d_queue_state {
u64 emit_seqno;
};
+/* Performance monitor object. The perform lifetime is controlled by userspace
+ * using perfmon related ioctls. A perfmon can be attached to a submit_cl
+ * request, and when this is the case, HW perf counters will be activated just
+ * before the submit_cl is submitted to the GPU and disabled when the job is
+ * done. This way, only events related to a specific job will be counted.
+ */
+struct v3d_perfmon {
+ /* Tracks the number of users of the perfmon, when this counter reaches
+* zero the perfmon is destroyed.
+*/
+ refcount_t refcnt;
+
+ /* Protects perfmon stop, as it can be invoked from multiple places. */
+ struct mutex lock;
+
+ /* Number of counters activated in this perfmon instance
+* (should be less than DRM_V3D_MAX_PERF_COUNTERS).
+*/
+ u8 ncounters;
+
+ /* Events counted by the HW perf counters. */
+ u8 counters[DRM_V3D_MAX_PERF_COUNTERS];
+
+ /* Storage for counter values. Counters are incremented by the
+* HW perf counter values every time the perfmon is attached
+* to a GPU job. This way, perfmon users don't have to
+* retrieve the results after each job if they want to track
+* events covering several submissions.
Re: [PATCH 1/2] iommu/arm-smmu-qcom: Skip the TTBR1 quirk for db820c.
On Fri, 26 Mar 2021 16:13:02 -0700, Eric Anholt wrote: > db820c wants to use the qcom smmu path to get HUPCF set (which keeps > the GPU from wedging and then sometimes wedging the kernel after a > page fault), but it doesn't have separate pagetables support yet in > drm/msm so we can't go all the way to the TTBR1 path. Applied to will (for-joerg/arm-smmu/updates), thanks! [1/2] iommu/arm-smmu-qcom: Skip the TTBR1 quirk for db820c. https://git.kernel.org/will/c/a242f4297cfe [2/2] arm64: dts: msm8996: Mark the GPU's SMMU as an adreno one. https://git.kernel.org/will/c/19c07b91f85d Cheers, -- Will https://fixes.arm64.dev https://next.arm64.dev https://will.arm64.dev
Re: [PATCH] drm/ttm: fix pipelined gutting
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.13-rc5 next-20210607]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-fix-pipelined-gutting/20210608-155139
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-s021-20210607 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-341-g8af24329-dirty
#
https://github.com/0day-ci/linux/commit/f7422b929beac0ad1d98db9ede99fa91a73f0360
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Christian-K-nig/drm-ttm-fix-pipelined-gutting/20210608-155139
git checkout f7422b929beac0ad1d98db9ede99fa91a73f0360
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' W=1
ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_pipeline_gutting':
>> drivers/gpu/drm/ttm/ttm_bo_util.c:637:24: error: incompatible type for
>> argument 2 of 'ttm_bo_assign_mem'
637 | ttm_bo_assign_mem(bo, sys_mem);
|^~~
||
|const struct ttm_place
In file included from drivers/gpu/drm/ttm/ttm_bo_util.c:32:
include/drm/ttm/ttm_bo_driver.h:190:31: note: expected 'struct ttm_resource
*' but argument is of type 'const struct ttm_place'
190 | struct ttm_resource *new_mem)
| ~^~~
>> drivers/gpu/drm/ttm/ttm_bo_util.c:644:24: error: passing argument 2 of
>> 'ttm_resource_free' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
644 | ttm_resource_free(bo, &sys_mem);
|^~~~
||
|const struct ttm_place *
In file included from include/drm/ttm/ttm_device.h:30,
from include/drm/ttm/ttm_bo_driver.h:40,
from drivers/gpu/drm/ttm/ttm_bo_util.c:32:
include/drm/ttm/ttm_resource.h:268:76: note: expected 'struct ttm_resource
**' but argument is of type 'const struct ttm_place *'
268 | void ttm_resource_free(struct ttm_buffer_object *bo, struct
ttm_resource **res);
|
~~^~~
cc1: some warnings being treated as errors
vim +/ttm_bo_assign_mem +637 drivers/gpu/drm/ttm/ttm_bo_util.c
569
570 /**
571 * ttm_bo_pipeline_gutting - purge the contents of a bo
572 * @bo: The buffer object
573 *
574 * Purge the contents of a bo, async if the bo is not idle.
575 * After a successful call, the bo is left unpopulated in
576 * system placement. The function may wait uninterruptible
577 * for idle on OOM.
578 *
579 * Return: 0 if successful, negative error code on failure.
580 */
581 int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
582 {
583 static const struct ttm_place sys_mem = { .mem_type =
TTM_PL_SYSTEM };
584 struct ttm_buffer_object *ghost;
585 struct ttm_resource *sys_res;
586 struct ttm_tt *ttm;
587 int ret;
588
589 /* If already idle, no need for ghost object dance. */
590 ret = ttm_bo_wait(bo, false, true);
591 if (ret != -EBUSY) {
592 if (!bo->ttm) {
593 /* See comment below about clearing. */
594 ret = ttm_tt_create(bo, true);
595 if (ret)
596 return ret;
597 } else {
598 ttm_tt_unpopulate(bo->bdev, bo->ttm);
599 if (bo->type == ttm_bo_type_device)
600 ttm_tt_mark_for_clear(bo->ttm);
601 }
602 ttm_resource_free(bo, &bo->resource);
603 return ttm_resource_alloc(bo, &sys_mem, &bo->resource);
604 }
605
606
607 ret = ttm_resource_alloc(bo, &sys_mem, &sys_res);
608
609 /*
610 * We need an un
[PATCH -next] fbdev: convert list_for_each to entry variant
convert list_for_each() to list_for_each_entry() where
applicable.
Reported-by: Hulk Robot
Signed-off-by: Zou Wei
---
drivers/video/fbdev/core/fbsysfs.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/core/fbsysfs.c
b/drivers/video/fbdev/core/fbsysfs.c
index 65dae05..753ecc8 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -130,14 +130,12 @@ static ssize_t store_mode(struct device *device, struct
device_attribute *attr,
struct fb_var_screeninfo var;
struct fb_modelist *modelist;
struct fb_videomode *mode;
- struct list_head *pos;
size_t i;
int err;
memset(&var, 0, sizeof(var));
- list_for_each(pos, &fb_info->modelist) {
- modelist = list_entry(pos, struct fb_modelist, list);
+ list_for_each_entry(modelist, &fb_info->modelist, list) {
mode = &modelist->mode;
i = mode_string(mstr, 0, mode);
if (strncmp(mstr, buf, max(count, i)) == 0) {
@@ -198,13 +196,11 @@ static ssize_t show_modes(struct device *device, struct
device_attribute *attr,
{
struct fb_info *fb_info = dev_get_drvdata(device);
unsigned int i;
- struct list_head *pos;
struct fb_modelist *modelist;
const struct fb_videomode *mode;
i = 0;
- list_for_each(pos, &fb_info->modelist) {
- modelist = list_entry(pos, struct fb_modelist, list);
+ list_for_each_entry(modelist, &fb_info->modelist, list) {
mode = &modelist->mode;
i += mode_string(buf, i, mode);
}
--
2.6.2
Re: [PATCH v3 5/7] drm/i915/ttm: remove node usage in our naming
On Tue, 2021-06-08 at 12:02 +0100, Matthew Auld wrote: > Now that ttm_resource_manager just returns a generic ttm_resource we > don't need to reference the mm_node stuff anymore which mostly only > makes sense for drm_mm_node. In the next few patches we want switch > over > to the ttm_buddy_man which is just another type of ttm_resource so > reflect that in the naming. > > Signed-off-by: Matthew Auld > Cc: Thomas Hellström Reviewed-by: Thomas Hellström
