The IDVS group size feature was missing. It is used on some Bifrost and
Valhall GPUs, and is the last kernel-relevant Bifrost feature we're
missing.
This feature adds an extra IDVS group size field to the JM_CONFIG
register. In kbase, the value is configurable via the device tree; kbase
uses 0xF as a default if no value is specified. Until we find a device
demanding otherwise, let's always set the 0xF default on devices which
support this feature mimicking kbase's behaviour.
As JM_CONFIG is …
[View More]an undocumented register, it's not clear to me what
happens if we fail to include this handling. Index-driven vertex shading
already works on Bifrost boards with this feature without this handling.
Perhaps this has performance implications? Patch untested for the
moment, wanted to give Steven a chance to comment.
Applies on top of my feature clean up series which should go in first.
(That's pure cleaunp, this is a behaviour change RFC needing
discussion.)
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig(a)collabora.com>
---
drivers/gpu/drm/panfrost/panfrost_features.h | 3 +++
drivers/gpu/drm/panfrost/panfrost_gpu.c | 3 +++
drivers/gpu/drm/panfrost/panfrost_regs.h | 1 +
3 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_features.h b/drivers/gpu/drm/panfrost/panfrost_features.h
index 34f2bae1ec8c..36fadcf9634e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_features.h
+++ b/drivers/gpu/drm/panfrost/panfrost_features.h
@@ -20,6 +20,7 @@ enum panfrost_hw_feature {
HW_FEATURE_AARCH64_MMU,
HW_FEATURE_TLS_HASHING,
HW_FEATURE_THREAD_GROUP_SPLIT,
+ HW_FEATURE_IDVS_GROUP_SIZE,
HW_FEATURE_3BIT_EXT_RW_L2_MMU_CONFIG,
};
@@ -74,6 +75,7 @@ enum panfrost_hw_feature {
BIT_ULL(HW_FEATURE_FLUSH_REDUCTION) | \
BIT_ULL(HW_FEATURE_PROTECTED_MODE) | \
BIT_ULL(HW_FEATURE_PROTECTED_DEBUG_MODE) | \
+ BIT_ULL(HW_FEATURE_IDVS_GROUP_SIZE) | \
BIT_ULL(HW_FEATURE_COHERENCY_REG))
#define hw_features_g76 (\
@@ -87,6 +89,7 @@ enum panfrost_hw_feature {
BIT_ULL(HW_FEATURE_COHERENCY_REG) | \
BIT_ULL(HW_FEATURE_AARCH64_MMU) | \
BIT_ULL(HW_FEATURE_TLS_HASHING) | \
+ BIT_ULL(HW_FEATURE_IDVS_GROUP_SIZE) | \
BIT_ULL(HW_FEATURE_3BIT_EXT_RW_L2_MMU_CONFIG))
#define hw_features_g31 (\
diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c b/drivers/gpu/drm/panfrost/panfrost_gpu.c
index bbe628b306ee..50c8922694d7 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
@@ -145,6 +145,9 @@ static void panfrost_gpu_init_quirks(struct panfrost_device *pfdev)
quirks |= (COHERENCY_ACE_LITE | COHERENCY_ACE) <<
JM_FORCE_COHERENCY_FEATURES_SHIFT;
+ if (panfrost_has_hw_feature(pfdev, HW_FEATURE_IDVS_GROUP_SIZE))
+ quirks |= JM_DEFAULT_IDVS_GROUP_SIZE << JM_IDVS_GROUP_SIZE_SHIFT;
+
if (quirks)
gpu_write(pfdev, GPU_JM_CONFIG, quirks);
diff --git a/drivers/gpu/drm/panfrost/panfrost_regs.h b/drivers/gpu/drm/panfrost/panfrost_regs.h
index 6c5a11ef1ee8..16e776cc82ea 100644
--- a/drivers/gpu/drm/panfrost/panfrost_regs.h
+++ b/drivers/gpu/drm/panfrost/panfrost_regs.h
@@ -208,6 +208,7 @@
#define JM_MAX_JOB_THROTTLE_LIMIT 0x3F
#define JM_FORCE_COHERENCY_FEATURES_SHIFT 2
#define JM_IDVS_GROUP_SIZE_SHIFT 16
+#define JM_DEFAULT_IDVS_GROUP_SIZE 0xF
#define JM_MAX_IDVS_GROUP_SIZE 0x3F
--
2.34.1
[View Less]
Update a comment stating create_bo took no flags, since it now takes a
bit mask of optional flags NOEXEC and HEAP.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig(a)collabora.com>
---
include/uapi/drm/panfrost_drm.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/uapi/drm/panfrost_drm.h b/include/uapi/drm/panfrost_drm.h
index 061e700dd06c..9e40277d8185 100644
--- a/include/uapi/drm/panfrost_drm.h
+++ b/include/uapi/drm/panfrost_drm.h
@@ -84,14 +84,14 @…
[View More]@ struct drm_panfrost_wait_bo {
__s64 timeout_ns; /* absolute */
};
+/* Valid flags to pass to drm_panfrost_create_bo */
#define PANFROST_BO_NOEXEC 1
#define PANFROST_BO_HEAP 2
/**
* struct drm_panfrost_create_bo - ioctl argument for creating Panfrost BOs.
*
- * There are currently no values for the flags argument, but it may be
- * used in a future extension.
+ * The flags argument is a bit mask of PANFROST_BO_* flags.
*/
struct drm_panfrost_create_bo {
__u32 size;
--
2.34.1
[View Less]
Hi Linus,
There is only the amdgpu runtime pm regression fix in here. I'm going
to be away next week, I'll probably pre-send you the drm-next main PR
before I go, if I can get it done today!
Dave.
drm-fixes-2022-01-07:
drm fixes for 5.16 final
amdgpu:
- suspend/resume fix
- fix runtime PM regression
The following changes since commit c9e6606c7fe92b50a02ce51dda82586ebdf99b48:
Linux 5.16-rc8 (2022-01-02 14:23:25 -0800)
are available in the Git repository at:
git://anongit.freedesktop.…
[View More]org/drm/drm tags/drm-fixes-2022-01-07
for you to fetch changes up to 936a93775b7c4f2293f651f64c4139c82e19a164:
Merge tag 'amd-drm-fixes-5.16-2021-12-31' of
ssh://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2022-01-07
06:46:08 +1000)
----------------------------------------------------------------
drm fixes for 5.16 final
amdgpu:
- suspend/resume fix
- fix runtime PM regression
----------------------------------------------------------------
Alex Deucher (2):
fbdev: fbmem: add a helper to determine if an aperture is used by a fw fb
drm/amdgpu: disable runpm if we are the primary adapter
Dave Airlie (1):
Merge tag 'amd-drm-fixes-5.16-2021-12-31' of
ssh://gitlab.freedesktop.org/agd5f/linux into drm-fixes
Evan Quan (1):
drm/amd/pm: keep the BACO feature enabled for suspend
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 28 ++++++++++++++++++
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 6 ++++
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 8 +++++-
drivers/video/fbdev/core/fbmem.c | 47 +++++++++++++++++++++++++++++++
include/linux/fb.h | 1 +
6 files changed, 90 insertions(+), 1 deletion(-)
[View Less]
This patch series introduces infrastructure for asynchronous vma
unbinding. The single enabled use-case is initially at buffer object
migration where we otherwise sync when unbinding vmas before migration.
This in theory allows us to pipeline any number of migrations, but in
practice the number is restricted by a sync wait when filling the
migration context ring. We might want to look at that moving forward if
needed.
The other main use-case is to be able to pipeline vma evictions, for
example …
[View More]with softpinning where a new vma wants to reuse the vm range
of an already active vma. We can't support this just yet because we
need dma_resv locking around vma eviction for that, which is under
implementation.
Patch 1 introduces vma resource first for error capture purposes
Patch 2 changes the vm backend interface to take vma resources rather than vmas
Patch 3 removes and unneeded page pinning
Patch 4 introduces the async unbinding itself, and finally
Patch 5 introduces a selftest
Patch 6 realizes we have duplicated functionality and removes the vma snapshots
v2:
-- Some kernel test robot reports addressed.
-- kmem cache for vma resources, See patch 4
-- Various fixes all over the place. See separate commit messages.
v3:
-- Re-add a missing i915_vma_resource_put()
-- Remove a stray debug printout
v4:
-- Patch series split in two. This is the second part.
-- Take cache coloring into account when searching for vma_resources
pending unbind. (Matthew Auld)
v5:
-- Add a selftest.
-- Remove page pinning while sync binding.
-- A couple of fixes in i915_vma_resource_bind_dep_await()
v6:
-- Some documentation updates
-- Remove I915_VMA_ALLOC_BIT (Matthew Auld)
-- Change some members of struct i915_vma_resource from unsigned long to u64
(Matthew Auld)
-- Fix up the cache coloring adjustment. (Kernel test robot <lkp(a)intel.com>)
-- Don't allow async unbinding if the vma_res pages are not the same as
the object pages. (Matthew Auld)
Thomas Hellström (6):
drm/i915: Initial introduction of vma resources
drm/i915: Use the vma resource as argument for gtt binding / unbinding
drm/i915: Don't pin the object pages during pending vma binds
drm/i915: Use vma resources for async unbinding
drm/i915: Asynchronous migration selftest
drm/i915: Use struct vma_resource instead of struct vma_snapshot
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/display/intel_dpt.c | 27 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +-
drivers/gpu/drm/i915/gem/i915_gem_object.c | 12 +
drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 +
.../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 11 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 37 +-
.../drm/i915/gem/selftests/i915_gem_migrate.c | 192 +++++++-
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 19 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 37 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 9 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 72 +--
drivers/gpu/drm/i915/gt/intel_gtt.c | 4 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 19 +-
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 22 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 13 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 3 +-
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 12 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 87 ++--
drivers/gpu/drm/i915/i915_module.c | 3 +
drivers/gpu/drm/i915/i915_request.c | 12 +-
drivers/gpu/drm/i915/i915_request.h | 6 +-
drivers/gpu/drm/i915/i915_vma.c | 241 +++++++++-
drivers/gpu/drm/i915/i915_vma.h | 33 +-
drivers/gpu/drm/i915/i915_vma_resource.c | 417 ++++++++++++++++++
drivers/gpu/drm/i915/i915_vma_resource.h | 234 ++++++++++
drivers/gpu/drm/i915/i915_vma_snapshot.c | 134 ------
drivers/gpu/drm/i915/i915_vma_snapshot.h | 112 -----
drivers/gpu/drm/i915/i915_vma_types.h | 19 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 159 ++++---
drivers/gpu/drm/i915/selftests/mock_gtt.c | 12 +-
34 files changed, 1421 insertions(+), 589 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.c
create mode 100644 drivers/gpu/drm/i915/i915_vma_resource.h
delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.c
delete mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.h
--
2.31.1
[View Less]
Previously, short term pinning in execbuf was required because i915_vma was
effectively independent from objects, and has its own refcount, locking,
lifetime rules and pinning.
This series removes the separate locking, by requiring vma->obj->resv to be
held when pinning and unbinding. This will also be required for VM_BIND work.
Some patches have already been merged, but this contains the mremainder of
the conversion.
With pinning required for pinning and unbinding, the lock is enough …
[View More]to prevent
unbinding when trying to pin with the lock held, for example in execbuf.
This makes binding/unbinding similar to ttm_bo_validate()'s use, which just
cares that an object is in a certain place, without pinning it in place.
Having the VMA part of gem bo removes a lot of the vma refcounting, and makes
i915_vma more a part of the bo, instead of its own floating object that just
happens to be part of a bo. This is also required to make it more compatible
with TTM, and migration in general.
For future work, it makes things a lot simpler and clear. We want to end up
with i915_vma just being a specific mapping of the BO, just like is the
case in other drivers. i915_vma->active removal is the next step there,
and makes it when object is destroyed, the bindings are destroyed (after idle),
instead of object being destroyed when bindings are idle.
Maarten Lankhorst (7):
drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent new ENOSPC
errors, v2.
drm/i915: Add locking to i915_gem_evict_vm()
drm/i915: Add object locking to i915_gem_evict_for_node and
i915_gem_evict_something
drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for
i915_vma_unbind, v2.
drm/i915: Remove assert_object_held_shared
drm/i915: Remove support for unlocked i915_vma unbind
drm/i915: Remove short-term pins from execbuf, v6.
drivers/gpu/drm/i915/display/intel_fb_pin.c | 2 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c | 220 +++++++++---------
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 17 +-
drivers/gpu/drm/i915/gem/i915_gem_object.c | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 14 --
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +-
.../i915/gem/selftests/i915_gem_client_blt.c | 2 +-
.../drm/i915/gem/selftests/i915_gem_mman.c | 6 +
drivers/gpu/drm/i915/gt/intel_ggtt.c | 51 +++-
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 1 -
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +-
drivers/gpu/drm/i915/gvt/aperture_gm.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 5 +-
drivers/gpu/drm/i915/i915_gem.c | 2 +
drivers/gpu/drm/i915/i915_gem_evict.c | 64 ++++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 8 +-
drivers/gpu/drm/i915/i915_gem_gtt.h | 4 +
drivers/gpu/drm/i915/i915_vgpu.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 122 +++++-----
drivers/gpu/drm/i915/i915_vma.h | 1 +
.../gpu/drm/i915/selftests/i915_gem_evict.c | 27 ++-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 36 +--
drivers/gpu/drm/i915/selftests/i915_vma.c | 8 +-
25 files changed, 361 insertions(+), 253 deletions(-)
--
2.34.1
[View Less]
Explicit assignment of connector to bridge type during bridge
addition is optional.
Some of the bridges like ICN6211 has panel to be connected and
that panel driver has taken care of associated connector type
of it.
Drop it.
Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com>
---
drivers/gpu/drm/bridge/chipone-icn6211.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c b/drivers/gpu/drm/bridge/chipone-icn6211.c
index 23c34039ac48..…
[View More]c60170865b74 100644
--- a/drivers/gpu/drm/bridge/chipone-icn6211.c
+++ b/drivers/gpu/drm/bridge/chipone-icn6211.c
@@ -238,7 +238,6 @@ static int chipone_probe(struct mipi_dsi_device *dsi)
return ret;
icn->bridge.funcs = &chipone_bridge_funcs;
- icn->bridge.type = DRM_MODE_CONNECTOR_DPI;
icn->bridge.of_node = dev->of_node;
drm_bridge_add(&icn->bridge);
--
2.25.1
[View Less]