* [Intel-gfx] [PATCH 09/21] drm/i915: split out gem/i915_gem_dmabuf.h from i915_drv.h
From: Jani Nikula @ 2022-01-05 19:56 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula
In-Reply-To: <cover.1641411696.git.jani.nikula@intel.com>
We already have the gem/i915_gem_dmabuf.c file.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.h | 18 ++++++++++++++++++
drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 ++
drivers/gpu/drm/i915/gvt/dmabuf.c | 2 ++
drivers/gpu/drm/i915/i915_driver.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 5 -----
6 files changed, 24 insertions(+), 5 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.h
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 1b526039a60d..29877894352e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -11,6 +11,7 @@
#include <asm/smp.h>
+#include "gem/i915_gem_dmabuf.h"
#include "i915_drv.h"
#include "i915_gem_object.h"
#include "i915_scatterlist.h"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.h b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.h
new file mode 100644
index 000000000000..6e0405d47ce1
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_GEM_DMABUF_H__
+#define __I915_GEM_DMABUF_H__
+
+struct drm_gem_object;
+struct drm_device;
+struct dma_buf;
+
+struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev,
+ struct dma_buf *dma_buf);
+
+struct dma_buf *i915_gem_prime_export(struct drm_gem_object *gem_obj, int flags);
+
+#endif /* __I915_GEM_DMABUF_H__ */
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index d87b508b59b1..6b719368467e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -26,9 +26,11 @@
#include "display/intel_frontbuffer.h"
#include "pxp/intel_pxp.h"
+
#include "i915_drv.h"
#include "i915_gem_clflush.h"
#include "i915_gem_context.h"
+#include "i915_gem_dmabuf.h"
#include "i915_gem_mman.h"
#include "i915_gem_object.h"
#include "i915_gem_ttm.h"
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c b/drivers/gpu/drm/i915/gvt/dmabuf.c
index 8e65cd8258b9..509b6fed0b5b 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.c
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -31,6 +31,8 @@
#include <linux/dma-buf.h>
#include <linux/vfio.h>
+#include "gem/i915_gem_dmabuf.h"
+
#include "i915_drv.h"
#include "gvt.h"
diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c
index 68017a945b3e..5b9355a73f53 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -62,6 +62,7 @@
#include "display/intel_vga.h"
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_dmabuf.h"
#include "gem/i915_gem_ioctls.h"
#include "gem/i915_gem_mman.h"
#include "gem/i915_gem_pm.h"
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cbee09231fdb..50d1fa6c8938 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1661,11 +1661,6 @@ static inline u32 i915_reset_engine_count(struct i915_gpu_error *error,
int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
enum i915_cache_level cache_level);
-struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev,
- struct dma_buf *dma_buf);
-
-struct dma_buf *i915_gem_prime_export(struct drm_gem_object *gem_obj, int flags);
-
static inline struct i915_address_space *
i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id)
{
--
2.30.2
^ permalink raw reply related
* [Intel-gfx] [PATCH 08/21] drm/i915: remove leftover i915_gem_pm.h declarations from i915_drv.h
From: Jani Nikula @ 2022-01-05 19:56 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula
In-Reply-To: <cover.1641411696.git.jani.nikula@intel.com>
Remove the duplicates.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
drivers/gpu/drm/i915/i915_drv.h | 4 ----
drivers/gpu/drm/i915/i915_gem.c | 1 +
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7afe5b3927a4..cbee09231fdb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1658,10 +1658,6 @@ static inline u32 i915_reset_engine_count(struct i915_gpu_error *error,
return atomic_read(&error->reset_engine_count[engine->uabi_class]);
}
-void i915_gem_suspend(struct drm_i915_private *dev_priv);
-void i915_gem_suspend_late(struct drm_i915_private *dev_priv);
-void i915_gem_resume(struct drm_i915_private *dev_priv);
-
int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
enum i915_cache_level cache_level);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5ef959a9f594..7b66d90318ce 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -44,6 +44,7 @@
#include "gem/i915_gem_context.h"
#include "gem/i915_gem_ioctls.h"
#include "gem/i915_gem_mman.h"
+#include "gem/i915_gem_pm.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_userptr.h"
#include "gt/intel_engine_user.h"
--
2.30.2
^ permalink raw reply related
* [Intel-gfx] [PATCH 07/21] drm/i915: split out i915_gem_internal.h from i915_drv.h
From: Jani Nikula @ 2022-01-05 19:56 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula
In-Reply-To: <cover.1641411696.git.jani.nikula@intel.com>
We already have the i915_gem_internal.c file.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
drivers/gpu/drm/i915/display/intel_dsb.c | 2 ++
drivers/gpu/drm/i915/display/intel_overlay.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_internal.h | 23 +++++++++++++++++++
.../gpu/drm/i915/gem/selftests/huge_pages.c | 3 ++-
.../drm/i915/gem/selftests/i915_gem_context.c | 1 +
.../drm/i915/gem/selftests/i915_gem_mman.c | 4 +++-
.../drm/i915/gem/selftests/igt_gem_utils.c | 1 +
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 ++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt.c | 7 +++---
.../gpu/drm/i915/gt/intel_gt_buffer_pool.c | 1 +
drivers/gpu/drm/i915/gt/intel_gtt.c | 1 +
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 ++
drivers/gpu/drm/i915/gt/intel_ring.c | 1 +
.../gpu/drm/i915/gt/intel_ring_submission.c | 2 ++
drivers/gpu/drm/i915/gt/intel_timeline.c | 3 ++-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 1 +
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 1 +
drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 ++
drivers/gpu/drm/i915/gt/selftest_migrate.c | 2 ++
drivers/gpu/drm/i915/gt/selftest_rps.c | 2 ++
.../gpu/drm/i915/gt/selftest_workarounds.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 9 --------
drivers/gpu/drm/i915/i915_perf.c | 1 +
drivers/gpu/drm/i915/selftests/i915_gem.c | 3 ++-
.../gpu/drm/i915/selftests/i915_gem_evict.c | 1 +
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 1 +
drivers/gpu/drm/i915/selftests/i915_request.c | 1 +
drivers/gpu/drm/i915/selftests/i915_vma.c | 1 +
drivers/gpu/drm/i915/selftests/igt_spinner.c | 1 +
31 files changed, 67 insertions(+), 16 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_internal.h
diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c b/drivers/gpu/drm/i915/display/intel_dsb.c
index 83a69a4a4fea..b34a67309976 100644
--- a/drivers/gpu/drm/i915/display/intel_dsb.c
+++ b/drivers/gpu/drm/i915/display/intel_dsb.c
@@ -4,6 +4,8 @@
*
*/
+#include "gem/i915_gem_internal.h"
+
#include "i915_drv.h"
#include "intel_de.h"
#include "intel_display_types.h"
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c b/drivers/gpu/drm/i915/display/intel_overlay.c
index 1a376e9a1ff3..8a283e7dd6d3 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -28,6 +28,7 @@
#include <drm/drm_fourcc.h>
+#include "gem/i915_gem_internal.h"
#include "gem/i915_gem_pm.h"
#include "gt/intel_gpu_commands.h"
#include "gt/intel_ring.h"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index c5150a1ee3d2..c698f95af15f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -10,6 +10,7 @@
#include "i915_drv.h"
#include "i915_gem.h"
+#include "i915_gem_internal.h"
#include "i915_gem_object.h"
#include "i915_scatterlist.h"
#include "i915_utils.h"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.h b/drivers/gpu/drm/i915/gem/i915_gem_internal.h
new file mode 100644
index 000000000000..6664e06112fc
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_GEM_INTERNAL_H__
+#define __I915_GEM_INTERNAL_H__
+
+#include <linux/types.h>
+
+struct drm_i915_gem_object;
+struct drm_i915_gem_object_ops;
+struct drm_i915_private;
+
+struct drm_i915_gem_object *
+i915_gem_object_create_internal(struct drm_i915_private *i915,
+ phys_addr_t size);
+struct drm_i915_gem_object *
+__i915_gem_object_create_internal(struct drm_i915_private *i915,
+ const struct drm_i915_gem_object_ops *ops,
+ phys_addr_t size);
+
+#endif /* __I915_GEM_INTERNAL_H__ */
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 11f0aa65f8a3..6af237aa1854 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -8,9 +8,10 @@
#include "i915_selftest.h"
-#include "gem/i915_gem_region.h"
+#include "gem/i915_gem_internal.h"
#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_pm.h"
+#include "gem/i915_gem_region.h"
#include "gt/intel_gt.h"
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index 3f41fe5ec9d4..3c866a3f74a2 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -6,6 +6,7 @@
#include <linux/prime_numbers.h>
+#include "gem/i915_gem_internal.h"
#include "gem/i915_gem_pm.h"
#include "gt/intel_engine_pm.h"
#include "gt/intel_gt.h"
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 743e6ab2c40b..420f211b4953 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -6,11 +6,13 @@
#include <linux/prime_numbers.h>
+#include "gem/i915_gem_internal.h"
+#include "gem/i915_gem_region.h"
#include "gt/intel_engine_pm.h"
#include "gt/intel_gpu_commands.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
-#include "gem/i915_gem_region.h"
+
#include "huge_gem_object.h"
#include "i915_selftest.h"
#include "selftests/i915_random.h"
diff --git a/drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.c b/drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.c
index b35c1219c852..3c55e77b0f1b 100644
--- a/drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.c
+++ b/drivers/gpu/drm/i915/gem/selftests/igt_gem_utils.c
@@ -7,6 +7,7 @@
#include "igt_gem_utils.h"
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_internal.h"
#include "gem/i915_gem_pm.h"
#include "gt/intel_context.h"
#include "gt/intel_gpu_commands.h"
diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
index 6e9292918bfc..15964c2e8d5c 100644
--- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
@@ -5,6 +5,8 @@
#include <linux/log2.h>
+#include "gem/i915_gem_internal.h"
+
#include "gen6_ppgtt.h"
#include "i915_scatterlist.h"
#include "i915_trace.h"
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 548d599c09dc..bc21d30f7abb 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -6,6 +6,7 @@
#include <drm/drm_print.h>
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_internal.h"
#include "i915_cmd_parser.h"
#include "i915_drv.h"
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c b/drivers/gpu/drm/i915/gt/intel_gt.c
index f98f0fb21efb..d2881c2f5c44 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -5,14 +5,16 @@
#include <drm/intel-gtt.h>
-#include "intel_gt_debugfs.h"
-
+#include "gem/i915_gem_internal.h"
#include "gem/i915_gem_lmem.h"
+#include "pxp/intel_pxp.h"
+
#include "i915_drv.h"
#include "intel_context.h"
#include "intel_gt.h"
#include "intel_gt_buffer_pool.h"
#include "intel_gt_clock_utils.h"
+#include "intel_gt_debugfs.h"
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
#include "intel_migrate.h"
@@ -23,7 +25,6 @@
#include "intel_rps.h"
#include "intel_uncore.h"
#include "shmem_utils.h"
-#include "pxp/intel_pxp.h"
void __intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
index 9db3dcbd917f..cadfd85785b1 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c
@@ -3,6 +3,7 @@
* Copyright © 2014-2018 Intel Corporation
*/
+#include "gem/i915_gem_internal.h"
#include "gem/i915_gem_object.h"
#include "i915_drv.h"
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c b/drivers/gpu/drm/i915/gt/intel_gtt.c
index a94be0306464..1eac0254bf6f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -10,6 +10,7 @@
#include <drm/drm_cache.h>
+#include "gem/i915_gem_internal.h"
#include "gem/i915_gem_lmem.h"
#include "i915_trace.h"
#include "intel_gt.h"
diff --git a/drivers/gpu/drm/i915/gt/intel_renderstate.c b/drivers/gpu/drm/i915/gt/intel_renderstate.c
index b575cd6e0b7a..5121e6dc2fa5 100644
--- a/drivers/gpu/drm/i915/gt/intel_renderstate.c
+++ b/drivers/gpu/drm/i915/gt/intel_renderstate.c
@@ -3,6 +3,8 @@
* Copyright © 2014 Intel Corporation
*/
+#include "gem/i915_gem_internal.h"
+
#include "i915_drv.h"
#include "intel_renderstate.h"
#include "intel_context.h"
diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c b/drivers/gpu/drm/i915/gt/intel_ring.c
index 2fdd52b62092..91c6a1881d18 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -3,6 +3,7 @@
* Copyright © 2019 Intel Corporation
*/
+#include "gem/i915_gem_internal.h"
#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_object.h"
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 3e6fac0340ef..40a008d71795 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -3,6 +3,8 @@
* Copyright © 2008-2021 Intel Corporation
*/
+#include "gem/i915_gem_internal.h"
+
#include "gen2_engine_cs.h"
#include "gen6_engine_cs.h"
#include "gen6_ppgtt.h"
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 438bbc7b8147..2962be6d4d00 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -3,9 +3,10 @@
* Copyright © 2016-2018 Intel Corporation
*/
-#include "i915_drv.h"
+#include "gem/i915_gem_internal.h"
#include "i915_active.h"
+#include "i915_drv.h"
#include "i915_syncmap.h"
#include "intel_gt.h"
#include "intel_ring.h"
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index e10da897e07a..72d5faab8f9a 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -5,6 +5,7 @@
#include <linux/prime_numbers.h>
+#include "gem/i915_gem_internal.h"
#include "gem/i915_gem_pm.h"
#include "gt/intel_engine_heartbeat.h"
#include "gt/intel_reset.h"
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 4a20ba63446c..9e9ccb139ba7 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -6,6 +6,7 @@
#include <linux/kthread.h>
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_internal.h"
#include "i915_gem_evict.h"
#include "intel_gt.h"
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 618c905daa19..21c29d315cc0 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -5,6 +5,8 @@
#include <linux/prime_numbers.h>
+#include "gem/i915_gem_internal.h"
+
#include "i915_selftest.h"
#include "intel_engine_heartbeat.h"
#include "intel_engine_pm.h"
diff --git a/drivers/gpu/drm/i915/gt/selftest_migrate.c b/drivers/gpu/drm/i915/gt/selftest_migrate.c
index fa4293d2944f..c9c4f391c5cc 100644
--- a/drivers/gpu/drm/i915/gt/selftest_migrate.c
+++ b/drivers/gpu/drm/i915/gt/selftest_migrate.c
@@ -5,6 +5,8 @@
#include <linux/sort.h>
+#include "gem/i915_gem_internal.h"
+
#include "selftests/i915_random.h"
static const unsigned int sizes[] = {
diff --git a/drivers/gpu/drm/i915/gt/selftest_rps.c b/drivers/gpu/drm/i915/gt/selftest_rps.c
index 7ee2513e15f9..a85bda53b767 100644
--- a/drivers/gpu/drm/i915/gt/selftest_rps.c
+++ b/drivers/gpu/drm/i915/gt/selftest_rps.c
@@ -6,6 +6,8 @@
#include <linux/pm_qos.h>
#include <linux/sort.h>
+#include "gem/i915_gem_internal.h"
+
#include "intel_engine_heartbeat.h"
#include "intel_engine_pm.h"
#include "intel_gpu_commands.h"
diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
index 0287c2573c51..67a9aab801dd 100644
--- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
@@ -3,6 +3,7 @@
* Copyright © 2018 Intel Corporation
*/
+#include "gem/i915_gem_internal.h"
#include "gem/i915_gem_pm.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_gt.h"
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6c5122659b9d..7afe5b3927a4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1684,15 +1684,6 @@ i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id)
return vm;
}
-/* i915_gem_internal.c */
-struct drm_i915_gem_object *
-i915_gem_object_create_internal(struct drm_i915_private *dev_priv,
- phys_addr_t size);
-struct drm_i915_gem_object *
-__i915_gem_object_create_internal(struct drm_i915_private *dev_priv,
- const struct drm_i915_gem_object_ops *ops,
- phys_addr_t size);
-
/* i915_gem_tiling.c */
static inline bool i915_gem_object_needs_bit17_swizzle(struct drm_i915_gem_object *obj)
{
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 170bba913c30..fdccc904805d 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -196,6 +196,7 @@
#include <linux/uuid.h>
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_internal.h"
#include "gt/intel_engine_pm.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_execlists_submission.h"
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c b/drivers/gpu/drm/i915/selftests/i915_gem.c
index b5576888cd78..6a7328d9c361 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
@@ -6,9 +6,10 @@
#include <linux/random.h>
+#include "gem/i915_gem_internal.h"
+#include "gem/i915_gem_pm.h"
#include "gem/selftests/igt_gem_utils.h"
#include "gem/selftests/mock_context.h"
-#include "gem/i915_gem_pm.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
index 75b709c26dd3..74a1b2ecf48f 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
@@ -22,6 +22,7 @@
*
*/
+#include "gem/i915_gem_internal.h"
#include "gem/i915_gem_pm.h"
#include "gem/selftests/igt_gem_utils.h"
#include "gem/selftests/mock_context.h"
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 575705c3bce9..1b508c89468c 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -26,6 +26,7 @@
#include <linux/prime_numbers.h>
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_internal.h"
#include "gem/selftests/mock_context.h"
#include "gt/intel_context.h"
#include "gt/intel_gpu_commands.h"
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c b/drivers/gpu/drm/i915/selftests/i915_request.c
index 92a859b34190..3e673fd1ea4f 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -26,6 +26,7 @@
#include <linux/pm_qos.h>
#include <linux/sort.h>
+#include "gem/i915_gem_internal.h"
#include "gem/i915_gem_pm.h"
#include "gem/selftests/mock_context.h"
diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c b/drivers/gpu/drm/i915/selftests/i915_vma.c
index 5c5809dfe9b2..cc6f9af679fb 100644
--- a/drivers/gpu/drm/i915/selftests/i915_vma.c
+++ b/drivers/gpu/drm/i915/selftests/i915_vma.c
@@ -25,6 +25,7 @@
#include <linux/prime_numbers.h>
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_internal.h"
#include "gem/selftests/mock_context.h"
#include "i915_scatterlist.h"
diff --git a/drivers/gpu/drm/i915/selftests/igt_spinner.c b/drivers/gpu/drm/i915/selftests/igt_spinner.c
index 24d87d0fc747..0c22594ae274 100644
--- a/drivers/gpu/drm/i915/selftests/igt_spinner.c
+++ b/drivers/gpu/drm/i915/selftests/igt_spinner.c
@@ -6,6 +6,7 @@
#include "gt/intel_gpu_commands.h"
#include "gt/intel_gt.h"
+#include "gem/i915_gem_internal.h"
#include "gem/selftests/igt_gem_utils.h"
#include "igt_spinner.h"
--
2.30.2
^ permalink raw reply related
* [Intel-gfx] [PATCH 06/21] drm/i915: split out i915_gem.h declarations from i915_drv.h
From: Jani Nikula @ 2022-01-05 19:56 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula
In-Reply-To: <cover.1641411696.git.jani.nikula@intel.com>
i915_gem.h should be the place for declarations for i915_gem.c, but
looks like it's filled with all sorts of cruft. Even so, move the
declarations where they belong.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
drivers/gpu/drm/i915/i915_drv.h | 32 -----------------------------
drivers/gpu/drm/i915/i915_gem.h | 36 +++++++++++++++++++++++++++++++++
2 files changed, 36 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bb48ab725a44..6c5122659b9d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1605,9 +1605,6 @@ intel_vm_no_concurrent_access_wa(struct drm_i915_private *i915)
}
/* i915_gem.c */
-void i915_gem_init_early(struct drm_i915_private *dev_priv);
-void i915_gem_cleanup_early(struct drm_i915_private *dev_priv);
-
static inline void i915_gem_drain_freed_objects(struct drm_i915_private *i915)
{
/*
@@ -1646,32 +1643,10 @@ static inline void i915_gem_drain_workqueue(struct drm_i915_private *i915)
drain_workqueue(i915->wq);
}
-struct i915_vma * __must_check
-i915_gem_object_ggtt_pin_ww(struct drm_i915_gem_object *obj,
- struct i915_gem_ww_ctx *ww,
- const struct i915_ggtt_view *view,
- u64 size, u64 alignment, u64 flags);
-
-struct i915_vma * __must_check
-i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
- const struct i915_ggtt_view *view,
- u64 size, u64 alignment, u64 flags);
-
-int i915_gem_object_unbind(struct drm_i915_gem_object *obj,
- unsigned long flags);
-#define I915_GEM_OBJECT_UNBIND_ACTIVE BIT(0)
-#define I915_GEM_OBJECT_UNBIND_BARRIER BIT(1)
-#define I915_GEM_OBJECT_UNBIND_TEST BIT(2)
-#define I915_GEM_OBJECT_UNBIND_VM_TRYLOCK BIT(3)
-
-void i915_gem_runtime_suspend(struct drm_i915_private *dev_priv);
-
int i915_gem_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
-int __must_check i915_gem_set_global_seqno(struct drm_device *dev, u32 seqno);
-
static inline u32 i915_reset_count(struct i915_gpu_error *error)
{
return atomic_read(&error->reset_count);
@@ -1683,17 +1658,10 @@ static inline u32 i915_reset_engine_count(struct i915_gpu_error *error,
return atomic_read(&error->reset_engine_count[engine->uabi_class]);
}
-int __must_check i915_gem_init(struct drm_i915_private *dev_priv);
-void i915_gem_driver_register(struct drm_i915_private *i915);
-void i915_gem_driver_unregister(struct drm_i915_private *i915);
-void i915_gem_driver_remove(struct drm_i915_private *dev_priv);
-void i915_gem_driver_release(struct drm_i915_private *dev_priv);
void i915_gem_suspend(struct drm_i915_private *dev_priv);
void i915_gem_suspend_late(struct drm_i915_private *dev_priv);
void i915_gem_resume(struct drm_i915_private *dev_priv);
-int i915_gem_open(struct drm_i915_private *i915, struct drm_file *file);
-
int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
enum i915_cache_level cache_level);
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index d0752e5553db..0ebe32dc6e83 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -27,12 +27,18 @@
#include <linux/bug.h>
#include <linux/interrupt.h>
+#include <linux/types.h>
#include <drm/drm_drv.h>
#include "i915_utils.h"
+struct drm_file;
+struct drm_i915_gem_object;
struct drm_i915_private;
+struct i915_gem_ww_ctx;
+struct i915_ggtt_view;
+struct i915_vma;
#ifdef CONFIG_DRM_I915_DEBUG_GEM
@@ -123,4 +129,34 @@ static inline bool __tasklet_is_scheduled(struct tasklet_struct *t)
return test_bit(TASKLET_STATE_SCHED, &t->state);
}
+void i915_gem_init_early(struct drm_i915_private *i915);
+void i915_gem_cleanup_early(struct drm_i915_private *i915);
+int __must_check i915_gem_init(struct drm_i915_private *i915);
+void i915_gem_driver_register(struct drm_i915_private *i915);
+void i915_gem_driver_unregister(struct drm_i915_private *i915);
+void i915_gem_driver_remove(struct drm_i915_private *i915);
+void i915_gem_driver_release(struct drm_i915_private *i915);
+int i915_gem_open(struct drm_i915_private *i915, struct drm_file *file);
+
+void i915_gem_runtime_suspend(struct drm_i915_private *i915);
+
+struct i915_vma * __must_check
+i915_gem_object_ggtt_pin_ww(struct drm_i915_gem_object *obj,
+ struct i915_gem_ww_ctx *ww,
+ const struct i915_ggtt_view *view,
+ u64 size, u64 alignment, u64 flags);
+
+struct i915_vma * __must_check
+i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
+ const struct i915_ggtt_view *view,
+ u64 size, u64 alignment, u64 flags);
+
+#define I915_GEM_OBJECT_UNBIND_ACTIVE BIT(0)
+#define I915_GEM_OBJECT_UNBIND_BARRIER BIT(1)
+#define I915_GEM_OBJECT_UNBIND_TEST BIT(2)
+#define I915_GEM_OBJECT_UNBIND_VM_TRYLOCK BIT(3)
+
+int i915_gem_object_unbind(struct drm_i915_gem_object *obj,
+ unsigned long flags);
+
#endif /* __I915_GEM_H__ */
--
2.30.2
^ permalink raw reply related
* [Intel-gfx] [PATCH 02/21] drm/i915: split out i915_cmd_parser.h from i915_drv.h
From: Jani Nikula @ 2022-01-05 19:56 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula
In-Reply-To: <cover.1641411696.git.jani.nikula@intel.com>
We already have the i915_cmd_parser.c file.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c | 1 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/i915_cmd_parser.c | 1 +
drivers/gpu/drm/i915/i915_cmd_parser.h | 26 +++++++++++++++++++
drivers/gpu/drm/i915/i915_drv.h | 12 ---------
drivers/gpu/drm/i915/i915_getparam.c | 1 +
6 files changed, 30 insertions(+), 13 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_cmd_parser.h
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index e9541244027a..62387218d9a6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -23,6 +23,7 @@
#include "pxp/intel_pxp.h"
+#include "i915_cmd_parser.h"
#include "i915_drv.h"
#include "i915_gem_clflush.h"
#include "i915_gem_context.h"
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 352254e001b4..548d599c09dc 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -7,8 +7,8 @@
#include "gem/i915_gem_context.h"
+#include "i915_cmd_parser.h"
#include "i915_drv.h"
-
#include "intel_breadcrumbs.h"
#include "intel_context.h"
#include "intel_engine.h"
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c
index e0403ce9ce69..9c90740520a9 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -28,6 +28,7 @@
#include "gt/intel_engine.h"
#include "gt/intel_gpu_commands.h"
+#include "i915_cmd_parser.h"
#include "i915_drv.h"
#include "i915_memcpy.h"
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.h b/drivers/gpu/drm/i915/i915_cmd_parser.h
new file mode 100644
index 000000000000..ba70ac6c97cd
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#ifndef __I915_CMD_PARSER_H__
+#define __I915_CMD_PARSER_H__
+
+#include <linux/types.h>
+
+struct drm_i915_private;
+struct intel_engine_cs;
+struct i915_vma;
+
+int i915_cmd_parser_get_version(struct drm_i915_private *dev_priv);
+int intel_engine_init_cmd_parser(struct intel_engine_cs *engine);
+void intel_engine_cleanup_cmd_parser(struct intel_engine_cs *engine);
+int intel_engine_cmd_parser(struct intel_engine_cs *engine,
+ struct i915_vma *batch,
+ unsigned long batch_offset,
+ unsigned long batch_length,
+ struct i915_vma *shadow,
+ bool trampoline);
+#define I915_CMD_PARSER_TRAMPOLINE_SIZE 8
+
+#endif /* __I915_CMD_PARSER_H__ */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c6a24c6d07b7..5c3a78aa0a7b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1754,18 +1754,6 @@ u32 i915_gem_fence_alignment(struct drm_i915_private *dev_priv, u32 size,
const char *i915_cache_level_str(struct drm_i915_private *i915, int type);
-/* i915_cmd_parser.c */
-int i915_cmd_parser_get_version(struct drm_i915_private *dev_priv);
-int intel_engine_init_cmd_parser(struct intel_engine_cs *engine);
-void intel_engine_cleanup_cmd_parser(struct intel_engine_cs *engine);
-int intel_engine_cmd_parser(struct intel_engine_cs *engine,
- struct i915_vma *batch,
- unsigned long batch_offset,
- unsigned long batch_length,
- struct i915_vma *shadow,
- bool trampoline);
-#define I915_CMD_PARSER_TRAMPOLINE_SIZE 8
-
/* intel_device_info.c */
static inline struct intel_device_info *
mkwrite_device_info(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c b/drivers/gpu/drm/i915/i915_getparam.c
index 70e634106295..dbe49fd87283 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -5,6 +5,7 @@
#include "gem/i915_gem_mman.h"
#include "gt/intel_engine_user.h"
+#include "i915_cmd_parser.h"
#include "i915_drv.h"
#include "i915_getparam.h"
#include "i915_perf.h"
--
2.30.2
^ permalink raw reply related
* [Intel-gfx] [PATCH 05/21] drm/i915: split out gem/i915_gem_tiling.h from i915_drv.h
From: Jani Nikula @ 2022-01-05 19:56 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula
In-Reply-To: <cover.1641411696.git.jani.nikula@intel.com>
We already have the gem/i915_gem_tiling.c file.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_tiling.h | 18 ++++++++++++++++++
drivers/gpu/drm/i915/i915_drv.h | 5 -----
drivers/gpu/drm/i915/i915_vma.c | 2 +-
4 files changed, 20 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_tiling.h
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
index ef4d0f7dc118..cf324329703f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
@@ -12,6 +12,7 @@
#include "i915_gem_ioctls.h"
#include "i915_gem_mman.h"
#include "i915_gem_object.h"
+#include "i915_gem_tiling.h"
/**
* DOC: buffer object tiling
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_tiling.h b/drivers/gpu/drm/i915/gem/i915_gem_tiling.h
new file mode 100644
index 000000000000..9924196a8139
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __I915_GEM_TILING_H__
+#define __I915_GEM_TILING_H__
+
+#include <linux/types.h>
+
+struct drm_i915_private;
+
+u32 i915_gem_fence_size(struct drm_i915_private *i915, u32 size,
+ unsigned int tiling, unsigned int stride);
+u32 i915_gem_fence_alignment(struct drm_i915_private *i915, u32 size,
+ unsigned int tiling, unsigned int stride);
+
+#endif /* __I915_GEM_TILING_H__ */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9cc3b5b9ec39..bb48ab725a44 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1734,11 +1734,6 @@ static inline bool i915_gem_object_needs_bit17_swizzle(struct drm_i915_gem_objec
i915_gem_object_is_tiled(obj);
}
-u32 i915_gem_fence_size(struct drm_i915_private *dev_priv, u32 size,
- unsigned int tiling, unsigned int stride);
-u32 i915_gem_fence_alignment(struct drm_i915_private *dev_priv, u32 size,
- unsigned int tiling, unsigned int stride);
-
const char *i915_cache_level_str(struct drm_i915_private *i915, int type);
/* intel_device_info.c */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 09d3424c9270..81a611b7d36f 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -26,8 +26,8 @@
#include <drm/drm_gem.h>
#include "display/intel_frontbuffer.h"
-
#include "gem/i915_gem_lmem.h"
+#include "gem/i915_gem_tiling.h"
#include "gt/intel_engine.h"
#include "gt/intel_engine_heartbeat.h"
#include "gt/intel_gt.h"
--
2.30.2
^ permalink raw reply related
* [Intel-gfx] [PATCH 04/21] drm/i915: split out gem/i915_gem_userptr.h from i915_drv.h
From: Jani Nikula @ 2022-01-05 19:56 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula
In-Reply-To: <cover.1641411696.git.jani.nikula@intel.com>
We already have the gem/i915_gem_userptr.c file.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_userptr.h | 14 ++++++++++++++
drivers/gpu/drm/i915/i915_drv.h | 2 --
drivers/gpu/drm/i915/i915_gem.c | 1 +
4 files changed, 16 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_userptr.h
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 3cc01c30dd62..6d1a71d6404c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -42,6 +42,7 @@
#include "i915_drv.h"
#include "i915_gem_ioctls.h"
#include "i915_gem_object.h"
+#include "i915_gem_userptr.h"
#include "i915_scatterlist.h"
#ifdef CONFIG_MMU_NOTIFIER
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.h b/drivers/gpu/drm/i915/gem/i915_gem_userptr.h
new file mode 100644
index 000000000000..8dadb2f8436d
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#ifndef __I915_GEM_USERPTR_H__
+#define __I915_GEM_USERPTR_H__
+
+struct drm_i915_private;
+
+int i915_gem_init_userptr(struct drm_i915_private *dev_priv);
+void i915_gem_cleanup_userptr(struct drm_i915_private *dev_priv);
+
+#endif /* __I915_GEM_USERPTR_H__ */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ceecccfd9ccd..9cc3b5b9ec39 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1605,8 +1605,6 @@ intel_vm_no_concurrent_access_wa(struct drm_i915_private *i915)
}
/* i915_gem.c */
-int i915_gem_init_userptr(struct drm_i915_private *dev_priv);
-void i915_gem_cleanup_userptr(struct drm_i915_private *dev_priv);
void i915_gem_init_early(struct drm_i915_private *dev_priv);
void i915_gem_cleanup_early(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 915bf431f320..5ef959a9f594 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -45,6 +45,7 @@
#include "gem/i915_gem_ioctls.h"
#include "gem/i915_gem_mman.h"
#include "gem/i915_gem_region.h"
+#include "gem/i915_gem_userptr.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
--
2.30.2
^ permalink raw reply related
* [Intel-gfx] [PATCH 03/21] drm/i915: split out i915_gem_evict.h from i915_drv.h
From: Jani Nikula @ 2022-01-05 19:56 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula
In-Reply-To: <cover.1641411696.git.jani.nikula@intel.com>
We already have the i915_gem_evicti915.c file.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c | 1 +
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 11 ---------
drivers/gpu/drm/i915/i915_gem_evict.c | 1 +
drivers/gpu/drm/i915/i915_gem_evict.h | 24 +++++++++++++++++++
drivers/gpu/drm/i915/i915_gem_gtt.c | 1 +
drivers/gpu/drm/i915/i915_vma.c | 1 +
7 files changed, 29 insertions(+), 11 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_gem_evict.h
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 62387218d9a6..377aada6269d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -27,6 +27,7 @@
#include "i915_drv.h"
#include "i915_gem_clflush.h"
#include "i915_gem_context.h"
+#include "i915_gem_evict.h"
#include "i915_gem_ioctls.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 15d63435ec4d..4a20ba63446c 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -7,6 +7,7 @@
#include "gem/i915_gem_context.h"
+#include "i915_gem_evict.h"
#include "intel_gt.h"
#include "intel_engine_heartbeat.h"
#include "intel_engine_pm.h"
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5c3a78aa0a7b..ceecccfd9ccd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1718,17 +1718,6 @@ i915_gem_vm_lookup(struct drm_i915_file_private *file_priv, u32 id)
return vm;
}
-/* i915_gem_evict.c */
-int __must_check i915_gem_evict_something(struct i915_address_space *vm,
- u64 min_size, u64 alignment,
- unsigned long color,
- u64 start, u64 end,
- unsigned flags);
-int __must_check i915_gem_evict_for_node(struct i915_address_space *vm,
- struct drm_mm_node *node,
- unsigned int flags);
-int i915_gem_evict_vm(struct i915_address_space *vm);
-
/* i915_gem_internal.c */
struct drm_i915_gem_object *
i915_gem_object_create_internal(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c b/drivers/gpu/drm/i915/i915_gem_evict.c
index 2b73ddb11c66..24eee0c2055f 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -31,6 +31,7 @@
#include "gt/intel_gt_requests.h"
#include "i915_drv.h"
+#include "i915_gem_evict.h"
#include "i915_trace.h"
I915_SELFTEST_DECLARE(static struct igt_evict_ctl {
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.h b/drivers/gpu/drm/i915/i915_gem_evict.h
new file mode 100644
index 000000000000..d4478b6ad11b
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_gem_evict.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#ifndef __I915_GEM_EVICT_H__
+#define __I915_GEM_EVICT_H__
+
+#include <linux/types.h>
+
+struct drm_mm_node;
+struct i915_address_space;
+
+int __must_check i915_gem_evict_something(struct i915_address_space *vm,
+ u64 min_size, u64 alignment,
+ unsigned long color,
+ u64 start, u64 end,
+ unsigned flags);
+int __must_check i915_gem_evict_for_node(struct i915_address_space *vm,
+ struct drm_mm_node *node,
+ unsigned int flags);
+int i915_gem_evict_vm(struct i915_address_space *vm);
+
+#endif /* __I915_GEM_EVICT_H__ */
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index cd5f2348a187..8a7f0d92b56f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -20,6 +20,7 @@
#include "gt/intel_gt_requests.h"
#include "i915_drv.h"
+#include "i915_gem_evict.h"
#include "i915_scatterlist.h"
#include "i915_trace.h"
#include "i915_vgpu.h"
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index be208a8f1ed0..09d3424c9270 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -34,6 +34,7 @@
#include "gt/intel_gt_requests.h"
#include "i915_drv.h"
+#include "i915_gem_evict.h"
#include "i915_sw_fence_work.h"
#include "i915_trace.h"
#include "i915_vma.h"
--
2.30.2
^ permalink raw reply related
* Re: [PATCH] Revert "clk: Detect failure to set defaults"
From: Marek Vasut @ 2022-01-05 19:56 UTC (permalink / raw)
To: Tom Rini; +Cc: Sean Anderson, u-boot, Peng Fan, Simon Glass, Mark Kettenis,
lukma
In-Reply-To: <20220105193708.GC2773246@bill-the-cat>
On 1/5/22 20:37, Tom Rini wrote:
> On Wed, Jan 05, 2022 at 08:35:19PM +0100, Marek Vasut wrote:
>> On 1/1/22 22:41, Sean Anderson wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>>> Please CC clock maintainers for future patches.
>>
>> btw. I'm surprised the commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646 has
>> zero reviews/acks from clock maintainers.
>>
>>> On 1/1/22 1:51 PM, Marek Vasut wrote:
>>>> This reverts commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646.
>>>> The aforementioned patch causes massive breakage on all platforms which
>>>> have 'assigned-clock' DT property in their DT which references any clock
>>>> that are not supported by the platform clock driver. That can easily
>>>> happen either in SPL, or because the clock driver is reduced. Currently
>>>> it seems all iMX8M are affected and fail to boot altogether.
>>>>
>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>> Cc: Peng Fan <peng.fan@oss.nxp.com>
>>>> Cc: Simon Glass <sjg@chromium.org>
>>>> ---
>>>> drivers/clk/clk-uclass.c | 6 +-----
>>>> 1 file changed, 1 insertion(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
>>>> index f2d26427543..094b1abf13c 100644
>>>> --- a/drivers/clk/clk-uclass.c
>>>> +++ b/drivers/clk/clk-uclass.c
>>>> @@ -846,17 +846,13 @@ void devm_clk_put(struct udevice *dev, struct
>>>> clk *clk)
>>>> int clk_uclass_post_probe(struct udevice *dev)
>>>> {
>>>> - int ret;
>>>> -
>>>> /*
>>>> * when a clock provider is probed. Call clk_set_defaults()
>>>> * also after the device is probed. This takes care of cases
>>>> * where the DT is used to setup default parents and rates
>>>> * using assigned-clocks
>>>> */
>>>> - ret = clk_set_defaults(dev, CLK_DEFAULTS_POST);
>>>> - if (ret)
>>>> - return log_ret(ret);
>>>> + clk_set_defaults(dev, CLK_DEFAULTS_POST);
>>>> return 0;
>>>> }
>>>>
>>>
>>> See [1] for previous discussion. For more background,
>>>
>>> - Device trees for i.MX are sync'd with Linux.
>>> - General clock assignments may live in the clock-controller node,
>>
>> clock assignments can be anywhere, even in non-clock-controller nodes.
>>
>>> including those which U-Boot does not implement, but which Linux does.
>>> It's OK to not set up these clocks, but U-Boot doesn't know that and
>>> fails.
>>>
>>> We don't necessarily need to revert this commit, but we do need a way to
>>> say "it's OK not to set the defaults, since we can function without
>>> them". Tom suggested doing this in the clock driver last time. I think a
>>> Kconfig or a device tree property would work, perhaps something like
>>> 'u-boot,clock-defaults-optional'.
>>
>> We didn't need custom DT properties before, Linux doesn't need them either,
>> so that approach seems wrong.
>>
>> If the clock driver could say "skip unimplemented clock, because I don't
>> implement them and that is OK", that sounds like the right approach.
>>
>> Unless the 2022.01 release should be completely broken for a lot of
>> platforms, I would propose we revert the clock uclass patch now and re-add
>> it right after the release, so we would not roll out a completely broken
>> release and would have more time to fix this properly.
>
> It'll be no more broken than v2021.10 was for whatever platforms have
> problems here, yes? Since that's what has the problematic commit.
So it seems. Does that mean we are OK with releasing such a broken
release, even though there is an easy way to improve the situation ?
^ permalink raw reply
* [Intel-gfx] [PATCH 01/21] drm/i915: split out i915_getparam.h from i915_drv.h
From: Jani Nikula @ 2022-01-05 19:56 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula
In-Reply-To: <cover.1641411696.git.jani.nikula@intel.com>
We already have the i915_getparam.c file.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
drivers/gpu/drm/i915/i915_driver.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 4 ----
drivers/gpu/drm/i915/i915_getparam.c | 1 +
drivers/gpu/drm/i915/i915_getparam.h | 15 +++++++++++++++
drivers/gpu/drm/i915/i915_ioc32.c | 1 +
5 files changed, 18 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_getparam.h
diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c
index 95174938b160..68017a945b3e 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -74,6 +74,7 @@
#include "i915_debugfs.h"
#include "i915_driver.h"
#include "i915_drv.h"
+#include "i915_getparam.h"
#include "i915_ioc32.h"
#include "i915_irq.h"
#include "i915_memcpy.h"
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3967748ba347..c6a24c6d07b7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1604,10 +1604,6 @@ intel_vm_no_concurrent_access_wa(struct drm_i915_private *i915)
return IS_CHERRYVIEW(i915) || intel_ggtt_update_needs_vtd_wa(i915);
}
-/* i915_getparam.c */
-int i915_getparam_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv);
-
/* i915_gem.c */
int i915_gem_init_userptr(struct drm_i915_private *dev_priv);
void i915_gem_cleanup_userptr(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_getparam.c b/drivers/gpu/drm/i915/i915_getparam.c
index 7f80ad247bc8..70e634106295 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -6,6 +6,7 @@
#include "gt/intel_engine_user.h"
#include "i915_drv.h"
+#include "i915_getparam.h"
#include "i915_perf.h"
int i915_getparam_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_getparam.h b/drivers/gpu/drm/i915/i915_getparam.h
new file mode 100644
index 000000000000..18e4752e8f70
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_getparam.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#ifndef __I915_GETPARAM_H__
+#define __I915_GETPARAM_H__
+
+struct drm_device;
+struct drm_file;
+
+int i915_getparam_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
+
+#endif /* __I915_GETPARAM_H__ */
diff --git a/drivers/gpu/drm/i915/i915_ioc32.c b/drivers/gpu/drm/i915/i915_ioc32.c
index 55b97c3a3dde..33348960f623 100644
--- a/drivers/gpu/drm/i915/i915_ioc32.c
+++ b/drivers/gpu/drm/i915/i915_ioc32.c
@@ -31,6 +31,7 @@
#include <drm/drm_ioctl.h>
#include "i915_drv.h"
+#include "i915_getparam.h"
#include "i915_ioc32.h"
struct drm_i915_getparam32 {
--
2.30.2
^ permalink raw reply related
* [Intel-gfx] [PATCH 00/21] drm/i915: clean up i915_drv.h
From: Jani Nikula @ 2022-01-05 19:56 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula
In a long overdue cleanup, split out a bunch of headers and declarations
out of i915_drv.h, and reduce includes all over the place.
I feel pretty strongly that declarations for functions in some_file.c
need to be placed in some_file.h. This does not generally seem to be the
case in gem/gt land. I create a number of such files here to place the
declarations extracted from i915_drv.h in them. I limit myself to
i915_drv.h cleanup here, and leave further cleanup for follow-up.
i915_drv.h is a painful file to deal with. Due to the massive amount of
headers it includes, and the massive amount of files it gets included
from, it basically causes the entire driver to be rebuilt whenever
almost any header gets changed in include/linux, include/drm, or i915
itself. Just build and sparse testing each commit takes eons.
This series is far from fixing everything, but it moves things forward a
few strides.
BR,
Jani.
Jani Nikula (21):
drm/i915: split out i915_getparam.h from i915_drv.h
drm/i915: split out i915_cmd_parser.h from i915_drv.h
drm/i915: split out i915_gem_evict.h from i915_drv.h
drm/i915: split out gem/i915_gem_userptr.h from i915_drv.h
drm/i915: split out gem/i915_gem_tiling.h from i915_drv.h
drm/i915: split out i915_gem.h declarations from i915_drv.h
drm/i915: split out i915_gem_internal.h from i915_drv.h
drm/i915: remove leftover i915_gem_pm.h declarations from i915_drv.h
drm/i915: split out gem/i915_gem_dmabuf.h from i915_drv.h
drm/i915: split out gem/i915_gem_create.h from i915_drv.h
drm/i915: split out gem/i915_gem_domain.h from i915_drv.h
drm/i915: move i915_cache_level_str() static in i915_debugfs.c
drm/i915: move i915_gem_vm_lookup() where it's used
drm/i915: move i915_reset_count()/i915_reset_engine_count() out of
i915_drv.h
drm/i915: split out i915_file_private.h from i915_drv.h
drm/i915: don't include drm_cache.h in i915_drv.h
drm/i915: include shmem_fs.h only where needed
drm/i915: include some drm headers only where needed
drm/i915: axe lots of unnecessary includes from i915_drv.h
drm/i915: fix drm_i915.h include grouping and sorting
drm/i915: group drm_i915.h forward declarations together
drivers/gpu/drm/i915/display/intel_dpt.c | 4 +-
drivers/gpu/drm/i915/display/intel_dsb.c | 2 +
drivers/gpu/drm/i915/display/intel_fb_pin.c | 1 +
drivers/gpu/drm/i915/display/intel_overlay.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 2 +
drivers/gpu/drm/i915/gem/i915_gem_context.c | 17 +
drivers/gpu/drm/i915/gem/i915_gem_create.c | 3 +
drivers/gpu/drm/i915/gem/i915_gem_create.h | 17 +
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.h | 18 ++
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 5 +-
drivers/gpu/drm/i915/gem/i915_gem_domain.h | 15 +
.../gpu/drm/i915/gem/i915_gem_execbuffer.c | 3 +
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_internal.h | 23 ++
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +
drivers/gpu/drm/i915/gem/i915_gem_object.c | 5 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 2 +
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 3 +
drivers/gpu/drm/i915/gem/i915_gem_throttle.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_tiling.h | 18 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_userptr.h | 14 +
.../gpu/drm/i915/gem/selftests/huge_pages.c | 3 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 1 +
.../drm/i915/gem/selftests/i915_gem_mman.c | 4 +-
.../drm/i915/gem/selftests/igt_gem_utils.c | 1 +
.../gpu/drm/i915/gem/selftests/mock_context.c | 1 +
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 7 +-
.../gpu/drm/i915/gt/intel_gt_buffer_pool.c | 1 +
drivers/gpu/drm/i915/gt/intel_gtt.c | 1 +
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +
drivers/gpu/drm/i915/gt/intel_reset.c | 1 +
drivers/gpu/drm/i915/gt/intel_ring.c | 1 +
.../gpu/drm/i915/gt/intel_ring_submission.c | 4 +
drivers/gpu/drm/i915/gt/intel_timeline.c | 5 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 1 +
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +
drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +
drivers/gpu/drm/i915/gt/selftest_migrate.c | 2 +
drivers/gpu/drm/i915/gt/selftest_rps.c | 2 +
.../gpu/drm/i915/gt/selftest_workarounds.c | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 2 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 2 +
drivers/gpu/drm/i915/gvt/dmabuf.c | 5 +
drivers/gpu/drm/i915/i915_cmd_parser.c | 3 +
drivers/gpu/drm/i915/i915_cmd_parser.h | 26 ++
drivers/gpu/drm/i915/i915_debugfs.c | 11 +
drivers/gpu/drm/i915/i915_driver.c | 4 +
drivers/gpu/drm/i915/i915_drv.h | 297 ++----------------
drivers/gpu/drm/i915/i915_file_private.h | 108 +++++++
drivers/gpu/drm/i915/i915_gem.c | 8 +-
drivers/gpu/drm/i915/i915_gem.h | 36 +++
drivers/gpu/drm/i915/i915_gem_evict.c | 1 +
drivers/gpu/drm/i915/i915_gem_evict.h | 24 ++
drivers/gpu/drm/i915/i915_gem_gtt.c | 1 +
drivers/gpu/drm/i915/i915_getparam.c | 2 +
drivers/gpu/drm/i915/i915_getparam.h | 15 +
drivers/gpu/drm/i915/i915_gpu_error.c | 1 +
drivers/gpu/drm/i915/i915_gpu_error.h | 11 +
drivers/gpu/drm/i915/i915_ioc32.c | 1 +
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/i915_perf.c | 2 +
drivers/gpu/drm/i915/i915_vma.c | 3 +-
drivers/gpu/drm/i915/selftests/i915_gem.c | 3 +-
.../gpu/drm/i915/selftests/i915_gem_evict.c | 1 +
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 1 +
drivers/gpu/drm/i915/selftests/i915_request.c | 1 +
drivers/gpu/drm/i915/selftests/i915_vma.c | 1 +
drivers/gpu/drm/i915/selftests/igt_spinner.c | 1 +
74 files changed, 498 insertions(+), 294 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_create.h
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.h
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_domain.h
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_internal.h
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_tiling.h
create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_userptr.h
create mode 100644 drivers/gpu/drm/i915/i915_cmd_parser.h
create mode 100644 drivers/gpu/drm/i915/i915_file_private.h
create mode 100644 drivers/gpu/drm/i915/i915_gem_evict.h
create mode 100644 drivers/gpu/drm/i915/i915_getparam.h
--
2.30.2
^ permalink raw reply
* [PATCH net 4/4] mlx5: Don't accidentally set RTO_ONLINK before mlx5e_route_lookup_ipv4_get()
From: Guillaume Nault @ 2022-01-05 19:56 UTC (permalink / raw)
To: David Miller, Jakub Kicinski
Cc: netdev, Saeed Mahameed, Leon Romanovsky, Vlad Buslov, Or Gerlitz
In-Reply-To: <cover.1641407336.git.gnault@redhat.com>
Mask the ECN bits before calling mlx5e_route_lookup_ipv4_get(). The
tunnel key might have the last ECN bit set. This interferes with the
route lookup process as ip_route_output_key_hash() interpretes this bit
specially (to restrict the route scope).
Found by code inspection, compile tested only.
Fixes: c7b9038d8af6 ("net/mlx5e: TC preparation refactoring for routing update event")
Fixes: 9a941117fb76 ("net/mlx5e: Maximize ip tunnel key usage on the TC offloading path")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c
index a5e450973225..bc5f1dcb75e1 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c
@@ -1,6 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB */
/* Copyright (c) 2018 Mellanox Technologies. */
+#include <net/inet_ecn.h>
#include <net/vxlan.h>
#include <net/gre.h>
#include <net/geneve.h>
@@ -235,7 +236,7 @@ int mlx5e_tc_tun_create_header_ipv4(struct mlx5e_priv *priv,
int err;
/* add the IP fields */
- attr.fl.fl4.flowi4_tos = tun_key->tos;
+ attr.fl.fl4.flowi4_tos = tun_key->tos & ~INET_ECN_MASK;
attr.fl.fl4.daddr = tun_key->u.ipv4.dst;
attr.fl.fl4.saddr = tun_key->u.ipv4.src;
attr.ttl = tun_key->ttl;
@@ -350,7 +351,7 @@ int mlx5e_tc_tun_update_header_ipv4(struct mlx5e_priv *priv,
int err;
/* add the IP fields */
- attr.fl.fl4.flowi4_tos = tun_key->tos;
+ attr.fl.fl4.flowi4_tos = tun_key->tos & ~INET_ECN_MASK;
attr.fl.fl4.daddr = tun_key->u.ipv4.dst;
attr.fl.fl4.saddr = tun_key->u.ipv4.src;
attr.ttl = tun_key->ttl;
--
2.21.3
^ permalink raw reply related
* [PATCH net 3/4] libcxgb: Don't accidentally set RTO_ONLINK in cxgb_find_route()
From: Guillaume Nault @ 2022-01-05 19:56 UTC (permalink / raw)
To: David Miller, Jakub Kicinski; +Cc: netdev, Varun Prakash
In-Reply-To: <cover.1641407336.git.gnault@redhat.com>
Mask the ECN bits before calling ip_route_output_ports(). The tos
variable might be passed directly from an IPv4 header, so it may have
the last ECN bit set. This interferes with the route lookup process as
ip_route_output_key_hash() interpretes this bit specially (to restrict
the route scope).
Found by code inspection, compile tested only.
Fixes: 804c2f3e36ef ("libcxgb,iw_cxgb4,cxgbit: add cxgb_find_route()")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
---
drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.c b/drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.c
index d04a6c163445..da8d10475a08 100644
--- a/drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.c
+++ b/drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.c
@@ -32,6 +32,7 @@
#include <linux/tcp.h>
#include <linux/ipv6.h>
+#include <net/inet_ecn.h>
#include <net/route.h>
#include <net/ip6_route.h>
@@ -99,7 +100,7 @@ cxgb_find_route(struct cxgb4_lld_info *lldi,
rt = ip_route_output_ports(&init_net, &fl4, NULL, peer_ip, local_ip,
peer_port, local_port, IPPROTO_TCP,
- tos, 0);
+ tos & ~INET_ECN_MASK, 0);
if (IS_ERR(rt))
return NULL;
n = dst_neigh_lookup(&rt->dst, &peer_ip);
--
2.21.3
^ permalink raw reply related
* [PATCH net 1/4] xfrm: Don't accidentally set RTO_ONLINK in decode_session4()
From: Guillaume Nault @ 2022-01-05 19:56 UTC (permalink / raw)
To: David Miller, Jakub Kicinski; +Cc: netdev, Steffen Klassert, Herbert Xu
In-Reply-To: <cover.1641407336.git.gnault@redhat.com>
Similar to commit 94e2238969e8 ("xfrm4: strip ECN bits from tos field"),
clear the ECN bits from iph->tos when setting ->flowi4_tos.
This ensures that the last bit of ->flowi4_tos is cleared, so
ip_route_output_key_hash() isn't going to restrict the scope of the
route lookup.
Use ~INET_ECN_MASK instead of IPTOS_RT_MASK, because we have no reason
to clear the high order bits.
Found by code inspection, compile tested only.
Fixes: 4da3089f2b58 ("[IPSEC]: Use TOS when doing tunnel lookups")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
---
net/xfrm/xfrm_policy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 1a06585022ab..0bb82df0f569 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -31,6 +31,7 @@
#include <linux/if_tunnel.h>
#include <net/dst.h>
#include <net/flow.h>
+#include <net/inet_ecn.h>
#include <net/xfrm.h>
#include <net/ip.h>
#if IS_ENABLED(CONFIG_IPV6_MIP6)
@@ -3294,7 +3295,7 @@ decode_session4(struct sk_buff *skb, struct flowi *fl, bool reverse)
fl4->flowi4_proto = iph->protocol;
fl4->daddr = reverse ? iph->saddr : iph->daddr;
fl4->saddr = reverse ? iph->daddr : iph->saddr;
- fl4->flowi4_tos = iph->tos;
+ fl4->flowi4_tos = iph->tos & ~INET_ECN_MASK;
if (!ip_is_fragment(iph)) {
switch (iph->protocol) {
--
2.21.3
^ permalink raw reply related
* [PATCH net 2/4] gre: Don't accidentally set RTO_ONLINK in gre_fill_metadata_dst()
From: Guillaume Nault @ 2022-01-05 19:56 UTC (permalink / raw)
To: David Miller, Jakub Kicinski
Cc: netdev, Hideaki YOSHIFUJI, David Ahern, wenxu
In-Reply-To: <cover.1641407336.git.gnault@redhat.com>
Mask the ECN bits before initialising ->flowi4_tos. The tunnel key may
have the last ECN bit set, which will interfere with the route lookup
process as ip_route_output_key_hash() interpretes this bit specially
(to restrict the route scope).
Found by code inspection, compile tested only.
Fixes: 962924fa2b7a ("ip_gre: Refactor collect metatdata mode tunnel xmit to ip_md_tunnel_xmit")
Signed-off-by: Guillaume Nault <gnault@redhat.com>
---
net/ipv4/ip_gre.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 2ac2b95c5694..99db2e41ed10 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -604,8 +604,9 @@ static int gre_fill_metadata_dst(struct net_device *dev, struct sk_buff *skb)
key = &info->key;
ip_tunnel_init_flow(&fl4, IPPROTO_GRE, key->u.ipv4.dst, key->u.ipv4.src,
- tunnel_id_to_key32(key->tun_id), key->tos, 0,
- skb->mark, skb_get_hash(skb));
+ tunnel_id_to_key32(key->tun_id),
+ key->tos & ~INET_ECN_MASK, 0, skb->mark,
+ skb_get_hash(skb));
rt = ip_route_output_key(dev_net(dev), &fl4);
if (IS_ERR(rt))
return PTR_ERR(rt);
--
2.21.3
^ permalink raw reply related
* [PATCH net 0/4] ipv4: Fix accidental RTO_ONLINK flags passed to ip_route_output_key_hash()
From: Guillaume Nault @ 2022-01-05 19:56 UTC (permalink / raw)
To: David Miller, Jakub Kicinski
Cc: netdev, Steffen Klassert, Herbert Xu, Hideaki YOSHIFUJI,
David Ahern, wenxu, Varun Prakash, Saeed Mahameed,
Leon Romanovsky, Vlad Buslov, Or Gerlitz
The IPv4 stack generally uses the last bit of ->flowi4_tos as a flag
indicating link scope for route lookups (RTO_ONLINK). Therefore, we
have to be careful when copying a TOS value to ->flowi4_tos. In
particular, the ->tos field of IPv4 packets may have this bit set
because of ECN. Also tunnel keys generally accept any user value for
the tos.
This series fixes several places where ->flowi4_tos was set from
non-sanitised values and the flowi4 structure was later used by
ip_route_output_key_hash().
Note that the IPv4 stack usually clears the RTO_ONLINK bit using
RT_TOS(). However this macro is based on an obsolete interpretation of
the old IPv4 TOS field (RFC 1349) and clears the three high order bits.
Since we don't need to clear these bits and since it doesn't make sense
to clear only one of the ECN bits, this patch series uses INET_ECN_MASK
instead.
All patches were compile tested only.
Guillaume Nault (4):
xfrm: Don't accidentally set RTO_ONLINK in decode_session4()
gre: Don't accidentally set RTO_ONLINK in gre_fill_metadata_dst()
libcxgb: Don't accidentally set RTO_ONLINK in cxgb_find_route()
mlx5: Don't accidentally set RTO_ONLINK before
mlx5e_route_lookup_ipv4_get()
drivers/net/ethernet/chelsio/libcxgb/libcxgb_cm.c | 3 ++-
drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c | 5 +++--
net/ipv4/ip_gre.c | 5 +++--
net/xfrm/xfrm_policy.c | 3 ++-
4 files changed, 10 insertions(+), 6 deletions(-)
--
2.21.3
^ permalink raw reply
* Re: [PATCH] meson.build: Print gtk version in the summary info
From: Philippe Mathieu-Daudé @ 2022-01-05 19:55 UTC (permalink / raw)
To: Thomas Huth, qemu-devel; +Cc: qemu-trivial, Paolo Bonzini
In-Reply-To: <20220105190804.649316-1-thuth@redhat.com>
On 5/1/22 20:08, Thomas Huth wrote:
> The "gtk" variable is re-declared as "dependencies: [gtk, gtkx11]",
> so there is just a "YES" in the summary info if gtk has been found.
> Let's use the info from the library detection instead so that the
> library version is printed in the summary instead.
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
> meson.build | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
^ permalink raw reply
* Re: [PATCH v2] drm/bridge: analogix_dp: Grab runtime PM reference for DP-AUX
From: Brian Norris @ 2022-01-05 19:55 UTC (permalink / raw)
To: Neil Armstrong, Andrzej Hajda
Cc: Sean Paul, Jonas Karlman, Linux Kernel, Jernej Skrabec,
Laurent Pinchart, dri-devel, open list:ARM/Rockchip SoC...,
stable, Tomeu Vizoso
In-Reply-To: <20211001144212.v2.1.I773a08785666ebb236917b0c8e6c05e3de471e75@changeid>
(updating Andrzej's email)
On Fri, Oct 1, 2021 at 2:50 PM Brian Norris <briannorris@chromium.org> wrote:
> If the display is not enable()d, then we aren't holding a runtime PM
> reference here. Thus, it's easy to accidentally cause a hang, if user
> space is poking around at /dev/drm_dp_aux0 at the "wrong" time.
>
> Let's get the panel and PM state right before trying to talk AUX.
>
> Fixes: 0d97ad03f422 ("drm/bridge: analogix_dp: Remove duplicated code")
> Cc: <stable@vger.kernel.org>
> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
>
> Changes in v2:
> - Fix spelling in Subject
> - DRM_DEV_ERROR() -> drm_err()
> - Propagate errors from un-analogix_dp_prepare_panel()
>
> .../drm/bridge/analogix/analogix_dp_core.c | 21 ++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
Ping? Do I need to do anything more here?
Thanks,
Brian
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v2] drm/bridge: analogix_dp: Grab runtime PM reference for DP-AUX
From: Brian Norris @ 2022-01-05 19:55 UTC (permalink / raw)
To: Neil Armstrong, Andrzej Hajda
Cc: Sean Paul, Jonas Karlman, Linux Kernel, Jernej Skrabec,
Laurent Pinchart, dri-devel, open list:ARM/Rockchip SoC...,
stable, Tomeu Vizoso
In-Reply-To: <20211001144212.v2.1.I773a08785666ebb236917b0c8e6c05e3de471e75@changeid>
(updating Andrzej's email)
On Fri, Oct 1, 2021 at 2:50 PM Brian Norris <briannorris@chromium.org> wrote:
> If the display is not enable()d, then we aren't holding a runtime PM
> reference here. Thus, it's easy to accidentally cause a hang, if user
> space is poking around at /dev/drm_dp_aux0 at the "wrong" time.
>
> Let's get the panel and PM state right before trying to talk AUX.
>
> Fixes: 0d97ad03f422 ("drm/bridge: analogix_dp: Remove duplicated code")
> Cc: <stable@vger.kernel.org>
> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
>
> Changes in v2:
> - Fix spelling in Subject
> - DRM_DEV_ERROR() -> drm_err()
> - Propagate errors from un-analogix_dp_prepare_panel()
>
> .../drm/bridge/analogix/analogix_dp_core.c | 21 ++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
Ping? Do I need to do anything more here?
Thanks,
Brian
^ permalink raw reply
* Re: [PATCH v2] drm/bridge: analogix_dp: Grab runtime PM reference for DP-AUX
From: Brian Norris @ 2022-01-05 19:55 UTC (permalink / raw)
To: Neil Armstrong, Andrzej Hajda
Cc: Jernej Skrabec, Tomeu Vizoso, Jonas Karlman, Linux Kernel,
dri-devel, open list:ARM/Rockchip SoC..., Laurent Pinchart,
stable, Sean Paul
In-Reply-To: <20211001144212.v2.1.I773a08785666ebb236917b0c8e6c05e3de471e75@changeid>
(updating Andrzej's email)
On Fri, Oct 1, 2021 at 2:50 PM Brian Norris <briannorris@chromium.org> wrote:
> If the display is not enable()d, then we aren't holding a runtime PM
> reference here. Thus, it's easy to accidentally cause a hang, if user
> space is poking around at /dev/drm_dp_aux0 at the "wrong" time.
>
> Let's get the panel and PM state right before trying to talk AUX.
>
> Fixes: 0d97ad03f422 ("drm/bridge: analogix_dp: Remove duplicated code")
> Cc: <stable@vger.kernel.org>
> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
>
> Changes in v2:
> - Fix spelling in Subject
> - DRM_DEV_ERROR() -> drm_err()
> - Propagate errors from un-analogix_dp_prepare_panel()
>
> .../drm/bridge/analogix/analogix_dp_core.c | 21 ++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
Ping? Do I need to do anything more here?
Thanks,
Brian
^ permalink raw reply
* Re: [PATCH] net: usb: r8152: Check used MAC passthrough address
From: Florian Fainelli @ 2022-01-05 19:55 UTC (permalink / raw)
To: Aaron Ma, Henning Schild
Cc: kuba, linux-usb, netdev, linux-kernel, davem, hayeswang, tiwai
In-Reply-To: <ba9f12b7-872f-8974-8865-9a2de539e09a@canonical.com>
On 1/5/22 12:37 AM, Aaron Ma wrote:
>
>
> On 1/5/22 16:32, Henning Schild wrote:
>> Am Wed, 5 Jan 2022 16:01:24 +0800
>> schrieb Aaron Ma <aaron.ma@canonical.com>:
>>
>>> On 1/5/22 15:55, Henning Schild wrote:
>>>> Am Wed, 5 Jan 2022 15:38:51 +0800
>>>> schrieb Aaron Ma <aaron.ma@canonical.com>:
>>>>
>>>>> On 1/5/22 15:32, Henning Schild wrote:
>>>>>> Am Wed, 5 Jan 2022 08:23:55 +0100
>>>>>> schrieb Henning Schild <henning.schild@siemens.com>:
>>>>>>
>>>>>>> Hi Aaron,
>>>>>>>
>>>>>>> if this or something similar goes in, please add another patch to
>>>>>>> remove the left-over defines.
>>>>>>>
>>>>>
>>>>> Sure, I will do it.
>>>>>
>>>>>>> Am Wed, 5 Jan 2022 14:17:47 +0800
>>>>>>> schrieb Aaron Ma <aaron.ma@canonical.com>:
>>>>>>>
>>>>>>>> When plugin multiple r8152 ethernet dongles to Lenovo Docks
>>>>>>>> or USB hub, MAC passthrough address from BIOS should be
>>>>>>>> checked if it had been used to avoid using on other dongles.
>>>>>>>>
>>>>>>>> Currently builtin r8152 on Dock still can't be identified.
>>>>>>>> First detected r8152 will use the MAC passthrough address.
>>>>>>>>
>>>>>>>> Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
>>>>>>>> ---
>>>>>>>> drivers/net/usb/r8152.c | 10 ++++++++++
>>>>>>>> 1 file changed, 10 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
>>>>>>>> index f9877a3e83ac..77f11b3f847b 100644
>>>>>>>> --- a/drivers/net/usb/r8152.c
>>>>>>>> +++ b/drivers/net/usb/r8152.c
>>>>>>>> @@ -1605,6 +1605,7 @@ static int
>>>>>>>> vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr
>>>>>>>> *sa) char *mac_obj_name; acpi_object_type mac_obj_type;
>>>>>>>> int mac_strlen;
>>>>>>>> + struct net_device *ndev;
>>>>>>>> if (tp->lenovo_macpassthru) {
>>>>>>>> mac_obj_name = "\\MACA";
>>>>>>>> @@ -1662,6 +1663,15 @@ static int
>>>>>>>> vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr
>>>>>>>> *sa) ret = -EINVAL; goto amacout;
>>>>>>>> }
>>>>>>>> + rcu_read_lock();
>>>>>>>> + for_each_netdev_rcu(&init_net, ndev) {
>>>>>>>> + if (strncmp(buf, ndev->dev_addr, 6) == 0) {
>>>>>>>> + rcu_read_unlock();
>>>>>>>> + goto amacout;
>>>>>>>
>>>>>>> Since the original PCI netdev will always be there, that would
>>>>>>> disable inheritance would it not?
>>>>>>> I guess a strncmp(MODULE_NAME, info->driver, strlen(MODULE_NAME))
>>>>>>> is needed as well.
>>>>>>>
>>>>>
>>>>> PCI ethernet could be a builtin one on dock since there will be
>>>>> TBT4 dock.
>>>>
>>>> In my X280 there is a PCI device in the laptop, always there. And
>>>> its MAC is the one found in ACPI. Did not try but i think for such
>>>> devices there would never be inheritance even if one wanted and
>>>> used a Lenovo dock that is supposed to do it.
>>>>
>>>
>>> There will more TBT4 docks in market, the new ethernet is just the
>>> same as PCI device, connected by thunderbolt.
>>>
>>> For exmaple, connect a TBT4 dock which uses i225 pcie base ethernet,
>>> then connect another TBT3 dock which uses r8152.
>>> If skip PCI check, then i225 and r8152 will use the same MAC.
>>
>> In current 5.15 i have that sort of collision already. All r8152s will
>> happily grab the MAC of the I219. In fact i have only ever seen it with
>> one r8152 at a time but while the I219 was actively in use.
>> While this patch will probably solve that, i bet it would defeat MAC
>> pass-thru altogether. Even when turned on in the BIOS.
>> Or does that iterator take "up"/"down" state into consideration? But
>> even if, the I219 could become "up" any time later.
>>
>
> No, that's different, I219 got MAC from their own space.
> MAC passthrough got MAC from ACPI "\MACA".
>
>> These collisions are simply bound to happen and probably very hard to
>> avoid once you have set your mind on allowing pass-thru in the first
>> place. Not sure whether that even has potential to disturb network
>> equipment like switches.
>>
>
> After check MAC address, it will be more safe.
Sorry to just do a drive by review here, but why is passing through the
MAC a kernel problem and not something that you punt to user-space entirely?
--
Florian
^ permalink raw reply
* Re: slow snd_rawmidi_drain() for VirMidi devcies
From: Stefan Sauer @ 2022-01-05 19:53 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5hlezui82s.wl-tiwai@suse.de>
From 6b97042bc91ebee267cbb05e6b937cbab5502f61 Mon Sep 17 00:00:00 2001
From: Stefan Sauer <ensonic@google.com>
Date: Wed, 5 Jan 2022 20:44:57 +0100
Subject: [PATCH] ALSA: seq: virmidi: Add a drain operation
If a driver does not supply a drain operation for outputs, a default code
path will execute msleep(50). Especially for a virtual midi device
this severely limits the throughput.
This implementation for the virtual midi driver simply flushes the output
workqueue.
---
sound/core/seq/seq_virmidi.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/sound/core/seq/seq_virmidi.c b/sound/core/seq/seq_virmidi.c
index 4abc38c70cae..1d708dc20443 100644
--- a/sound/core/seq/seq_virmidi.c
+++ b/sound/core/seq/seq_virmidi.c
@@ -262,6 +262,16 @@ static int snd_virmidi_output_close(struct
snd_rawmidi_substream *substream)
return 0;
}
+/*
+ * drain output work queue
+ */
+static void snd_virmidi_output_drain(struct snd_rawmidi_substream
*substream)
+{
+ struct snd_virmidi *vmidi = substream->runtime->private_data;
+
+ flush_work(&vmidi->output_work);
+}
+
/*
* subscribe callback - allow output to rawmidi device
*/
@@ -336,6 +346,7 @@ static const struct snd_rawmidi_ops
snd_virmidi_output_ops = {
.open = snd_virmidi_output_open,
.close = snd_virmidi_output_close,
.trigger = snd_virmidi_output_trigger,
+ .drain = snd_virmidi_output_drain,
};
/*
--
2.34.1
Am Mi., 5. Jan. 2022 um 15:13 Uhr schrieb Takashi Iwai <tiwai@suse.de>:
>
> On Wed, 05 Jan 2022 14:39:05 +0100,
> Stefan Sauer wrote:
> >
> > - 28,78% 0,00% rawmidi_alsa [snd_rawmidi] [k]
> > snd_rawmidi_drain_output
> > - snd_rawmidi_drain_output
> > - 26,59% msleep
> > schedule_timeout
> > schedule
> > + __schedule
> > + 2,13% schedule_timeout
> >
> > Seems to be because of:
> > https://github.com/torvalds/linux/blob/master/sound/core/rawmidi.c#L244
> > if (substream->ops->drain)
> > substream->ops->drain(substream);
> > else
> > msleep(50);
> >
> > It see what fileops have no drain impl:
> > https://github.com/torvalds/linux/blob/master/sound/core/rawmidi.c#L1708
> > and I see
> >
https://github.com/torvalds/linux/blob/master/sound/core/seq/seq_virmidi.c#L329
> > that define no drain op. Not which ones are actually used here :/
> >
> > The docs confirm teh 50 ms wait though:
> >
https://github.com/torvalds/linux/blob/master/Documentation/sound/kernel-api/writing-an-alsa-driver.rst#drain-callback
> >
> > would it make sense to have a dummy drain function for the seq_virmidi
output
> > ops?
>
> Yes, a proper drain implementation is definitely better.
> I guess just calling flush_work(&vmidi->output_work) there would
> suffice.
>
>
> thanks,
>
> Takashi
>
> >
> > Stefan
> >
> > Am Di., 4. Jan. 2022 um 16:54 Uhr schrieb Takashi Iwai <tiwai@suse.de>:
> >
> > On Sat, 01 Jan 2022 12:49:13 +0100,
> > Stefan Sauer wrote:
> > >
> > > hi,
> > >
> > > I've tried to link BitwigStudio to the webapp cables.gl over
virmidi.
> > > Unfortunately Bitwig Studio only supports rawmidi. What I
discovered is
> > > that there is a strange slowness when sending data to virmidi
caused
> > > by snd_rawmidi_drain().
> > >
> > > I've posted two tiny, self-contained c apps to:
> > > https://gist.github.com/ensonic/c7588b87fa6c1fa94a8f753b1e0aa394
> > > See some examples below. 2 observations:
> > > * snd_rawmidi_type() is *not* reporting virmidi as VIRTUAL
> > > * snd_rawmidi_drain() takes about 60ms! on virtual vs. less that
0.1 ms
> > on
> > > usb midi (I checked all my hw midi and the worst was avg=1ms on
physical
> > > midi image unitor8)
> > >
> > > When comparing the implementations:
> > >
> >
https://github.com/alsa-project/alsa-lib/blob/master/src/rawmidi/rawmidi_virt.c#L173
> > >
> >
https://github.com/alsa-project/alsa-lib/blob/master/src/rawmidi/rawmidi_hw.c#L164
> > > I see that the hw one results in an IOCTL which I can see when
striking
> > the
> > > code and I wonder if this is the root cause? Why is
rawmidi_virt.c not
> > used
> > > for virmidi?
> > > >From poking at snd_rawmidi_open_conf() I have not yet figured
where
> > this is
> > > decided ....
> > >
> > > Stefan
> > >
> > > > amidi -l
> > > Dir Device Name
> > > IO hw:0,0,0 Scarlett 18i20 USB MIDI 1
> > > IO hw:3,0,0 nanoKEY2 nanoKEY2 _ KEYBOARD
> > > IO hw:5,0,0 nanoKONTROL nanoKONTROL _ SLIDE
> > > IO hw:10,0 Virtual Raw MIDI (16 subdevices)
> > > IO hw:11,0 Virtual Raw MIDI (16 subdevices)
> > >
> > > # using direct i/o to virmidi - all good
> > > > ./rawmidi_oss /dev/midi11 0
> > > Using device '/dev/midi11' without draining
> > > write took min= 0.0015 ms, avg= 0.0016 ms, max= 0.0110 ms
> > > > ./rawmidi_oss /dev/midi11 1
> > > Using device '/dev/midi11' with draining
> > > write took min= 0.0015 ms, avg= 0.0017 ms, max= 0.0101 ms
> > > drain took min= 0.0001 ms, avg= 0.0001 ms, max= 0.0008 ms
> > >
> > > # using snd_rawmidi to virmidi - slow drain operations
> > > > ./rawmidi_alsa hw:11,0 0
> > > Using device 'hw:11,0' without draining
> > > SND_RAWMIDI_TYPE_HW
> > > write took min= 0.0010 ms, avg= 0.0011 ms, max= 0.0056 ms
> > > > ./rawmidi_alsa hw:11,0 1
> > > Using device 'hw:11,0' with draining
> > > SND_RAWMIDI_TYPE_HW
> > > write took min= 0.0016 ms, avg= 0.0040 ms, max= 0.0077 ms
> > > drain took min= 55.9951 ms, avg= 60.4330 ms, max= 64.0653 ms
> > >
> > > # using snd_rawmidi to usb hw - all good
> > > > ./rawmidi_alsa hw:3,0 0
> > > Using device 'hw:3,0' without draining
> > > SND_RAWMIDI_TYPE_HW
> > > write took min= 0.0012 ms, avg= 0.0015 ms, max= 0.0121 ms
> > > > ./rawmidi_alsa hw:3,0 1
> > > Using device 'hw:3,0' with draining
> > > SND_RAWMIDI_TYPE_HW
> > > write took min= 0.0024 ms, avg= 0.0032 ms, max= 0.0110 ms
> > > drain took min= 0.0293 ms, avg= 0.0636 ms, max= 0.2277 ms
> >
> > This kind of thing needs profiling. You can try perf or whatever
> > available, and identify which call takes long. My wild guess is
> > something about snd_seq_sync_output_queue(), maybe poll syscall
takes
> > unexpected long.
> >
> > thanks,
> >
> > Takashi
> >
> >
^ permalink raw reply related
* Re: qemu-xen is unavailable
From: Christian Kujau @ 2022-01-05 19:53 UTC (permalink / raw)
To: Anthony PERARD; +Cc: xen-users, xen-devel, George Dunlap
In-Reply-To: <YdXHDCUqpqV+E2hO@perard>
On Wed, 5 Jan 2022, Anthony PERARD wrote:
> Looking at the original email, the domain config file has type="pvh", so
> I don't think qemu is actually needed. And the domain is starting fine,
> so this message isn't really needed and would be a bug I guess.
Thanks for responding. Indeed, the "qemu" package is not installed on this
machine, and looking closer, the Alpine folks did something to their
Xen/Qemu packagesp[0][1]. I can't check right now but I'll test if the
warning goes away with the "qemu" package installed.
Thanks again,
Christian.
[0] https://git.alpinelinux.org/aports/commit/?id=9f064ced3
[1] https://git.alpinelinux.org/aports/commit/?id=55d655af7
> I think it comes from libxl trying to figure out which QEMU to use even
> if it isn't going to be needed. And since there's no qemu to be found,
> the message is printed, even when qemu isn't needed.
>
> I guess you have this message because you didn't install a qemu package
> (or qemu-xen), but you don't need the package as you are only starting a
> PVH guest.
>
> The bug here is that libxl shouldn't print this message for PVH guest
> because it's confusing.
--
BOFH excuse #244:
Your cat tried to eat the mouse.
^ permalink raw reply
* [PATCH] xfs/220: fix quotarm syscall test
From: Darrick J. Wong @ 2022-01-05 19:53 UTC (permalink / raw)
To: Eryu Guan; +Cc: Christoph Hellwig, xuyang2018.jy@fujitsu.com, xfs, fstests
From: Darrick J. Wong <djwong@kernel.org>
In commit 6ba125c9, we tried to adjust this fstest to deal with the
removal of the ability to turn off quota accounting via the Q_XQUOTAOFF
system call.
Unfortunately, the changes made to this test make it nonfunctional on
those newer kernels, since the Q_XQUOTARM command returns EINVAL if
quota accounting is turned on, and the changes filter out the EINVAL
error string.
Doing this wasn't /incorrect/, because, very narrowly speaking, the
intent of this test is to guard against Q_XQUOTARM returning ENOSYS when
quota has been enabled. However, this also means that we no longer test
Q_XQUOTARM's ability to truncate the quota files at all.
So, fix this test to deal with the loss of quotaoff in the same way that
the others do -- if accounting is still enabled after the 'off' command,
cycle the mount so that Q_XQUOTARM actually truncates the files.
While we're at it, enhance the test to check that XQUOTARM actually
truncated the quota files.
Fixes: 6ba125c9 ("xfs/220: avoid failure when disabling quota accounting is not supported")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
tests/xfs/220 | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/tests/xfs/220 b/tests/xfs/220
index 241a7abd..cfa90d3a 100755
--- a/tests/xfs/220
+++ b/tests/xfs/220
@@ -52,14 +52,28 @@ _scratch_mkfs_xfs >/dev/null 2>&1
# mount with quotas enabled
_scratch_mount -o uquota
-# turn off quota and remove space allocated to the quota files
+# turn off quota accounting...
+$XFS_QUOTA_PROG -x -c off $SCRATCH_DEV
+
+# ...but if the kernel doesn't support turning off accounting, remount with
+# noquota option to turn it off...
+if $XFS_QUOTA_PROG -x -c 'state -u' $SCRATCH_DEV | grep -q 'Accounting: ON'; then
+ _scratch_unmount
+ _scratch_mount -o noquota
+fi
+
+before_freesp=$(_get_available_space $SCRATCH_MNT)
+
+# ...and remove space allocated to the quota files
# (this used to give wrong ENOSYS returns in 2.6.31)
-#
-# The sed expression below replaces a notrun to cater for kernels that have
-# removed the ability to disable quota accounting at runtime. On those
-# kernel this test is rather useless, and in a few years we can drop it.
-$XFS_QUOTA_PROG -x -c off -c remove $SCRATCH_DEV 2>&1 | \
- sed -e '/XFS_QUOTARM: Invalid argument/d'
+$XFS_QUOTA_PROG -x -c remove $SCRATCH_DEV
+
+# Make sure we actually freed the space used by dquot 0
+after_freesp=$(_get_available_space $SCRATCH_MNT)
+if [ $before_freesp -ge $after_freesp ]; then
+ echo "before: $before_freesp; after: $after_freesp" >> $seqres.full
+ echo "expected more free space after Q_XQUOTARM"
+fi
# and unmount again
_scratch_unmount
^ permalink raw reply related
* [PATCH v2] xfs: take the ILOCK when accessing the inode core
From: Darrick J. Wong @ 2022-01-05 19:52 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-xfs
From: Darrick J. Wong <djwong@kernel.org>
I was poking around in the directory code while diagnosing online fsck
bugs, and noticed that xfs_readdir doesn't actually take the directory
ILOCK when it calls xfs_dir2_isblock. xfs_dir_open most probably loaded
the data fork mappings and the VFS took i_rwsem (aka IOLOCK_SHARED) so
we're protected against writer threads, but we really need to follow the
locking model like we do in other places.
To avoid unnecessarily cycling the ILOCK for fairly small directories,
change the block/leaf _getdents functions to consume the ILOCK hold that
the parent readdir function took to decide on a _getdents implementation.
It is ok to cycle the ILOCK in readdir because the VFS takes the IOLOCK
in the appropriate mode during lookups and writes, and we don't want to
be holding the ILOCK when we copy directory entries to userspace in case
there's a page fault. We really only need it to protect against data
fork lookups, like we do for other files.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
v2: reduce the scope of the locked region, and reduce lock cycling
---
fs/xfs/xfs_dir2_readdir.c | 52 +++++++++++++++++++++++++++++----------------
1 file changed, 33 insertions(+), 19 deletions(-)
diff --git a/fs/xfs/xfs_dir2_readdir.c b/fs/xfs/xfs_dir2_readdir.c
index 8310005af00f..74844edd86a7 100644
--- a/fs/xfs/xfs_dir2_readdir.c
+++ b/fs/xfs/xfs_dir2_readdir.c
@@ -138,7 +138,8 @@ xfs_dir2_sf_getdents(
STATIC int
xfs_dir2_block_getdents(
struct xfs_da_args *args,
- struct dir_context *ctx)
+ struct dir_context *ctx,
+ unsigned int *lock_mode)
{
struct xfs_inode *dp = args->dp; /* incore directory inode */
struct xfs_buf *bp; /* buffer for block */
@@ -146,7 +147,6 @@ xfs_dir2_block_getdents(
int wantoff; /* starting block offset */
xfs_off_t cook;
struct xfs_da_geometry *geo = args->geo;
- int lock_mode;
unsigned int offset, next_offset;
unsigned int end;
@@ -156,12 +156,13 @@ xfs_dir2_block_getdents(
if (xfs_dir2_dataptr_to_db(geo, ctx->pos) > geo->datablk)
return 0;
- lock_mode = xfs_ilock_data_map_shared(dp);
error = xfs_dir3_block_read(args->trans, dp, &bp);
- xfs_iunlock(dp, lock_mode);
if (error)
return error;
+ xfs_iunlock(dp, *lock_mode);
+ *lock_mode = 0;
+
/*
* Extract the byte offset we start at from the seek pointer.
* We'll skip entries before this.
@@ -344,7 +345,8 @@ STATIC int
xfs_dir2_leaf_getdents(
struct xfs_da_args *args,
struct dir_context *ctx,
- size_t bufsize)
+ size_t bufsize,
+ unsigned int *lock_mode)
{
struct xfs_inode *dp = args->dp;
struct xfs_mount *mp = dp->i_mount;
@@ -356,7 +358,6 @@ xfs_dir2_leaf_getdents(
xfs_dir2_off_t curoff; /* current overall offset */
int length; /* temporary length value */
int byteoff; /* offset in current block */
- int lock_mode;
unsigned int offset = 0;
int error = 0; /* error return value */
@@ -390,13 +391,16 @@ xfs_dir2_leaf_getdents(
bp = NULL;
}
- lock_mode = xfs_ilock_data_map_shared(dp);
+ if (*lock_mode == 0)
+ *lock_mode = xfs_ilock_data_map_shared(dp);
error = xfs_dir2_leaf_readbuf(args, bufsize, &curoff,
&rablk, &bp);
- xfs_iunlock(dp, lock_mode);
if (error || !bp)
break;
+ xfs_iunlock(dp, *lock_mode);
+ *lock_mode = 0;
+
xfs_dir3_data_check(dp, bp);
/*
* Find our position in the block.
@@ -507,8 +511,9 @@ xfs_readdir(
size_t bufsize)
{
struct xfs_da_args args = { NULL };
- int rval;
- int v;
+ unsigned int lock_mode;
+ int isblock;
+ int error;
trace_xfs_readdir(dp);
@@ -523,13 +528,22 @@ xfs_readdir(
args.trans = tp;
if (dp->i_df.if_format == XFS_DINODE_FMT_LOCAL)
- rval = xfs_dir2_sf_getdents(&args, ctx);
- else if ((rval = xfs_dir2_isblock(&args, &v)))
- ;
- else if (v)
- rval = xfs_dir2_block_getdents(&args, ctx);
- else
- rval = xfs_dir2_leaf_getdents(&args, ctx, bufsize);
-
- return rval;
+ return xfs_dir2_sf_getdents(&args, ctx);
+
+ lock_mode = xfs_ilock_data_map_shared(dp);
+ error = xfs_dir2_isblock(&args, &isblock);
+ if (error)
+ goto out_unlock;
+
+ if (isblock) {
+ error = xfs_dir2_block_getdents(&args, ctx, &lock_mode);
+ goto out_unlock;
+ }
+
+ error = xfs_dir2_leaf_getdents(&args, ctx, bufsize, &lock_mode);
+
+out_unlock:
+ if (lock_mode)
+ xfs_iunlock(dp, lock_mode);
+ return error;
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.