Hi,
This series introduce Kunit tests to the vc4 KMS driver, but unlike what we
have been doing so far in KMS, it actually tests the atomic modesetting code.
In order to do so, I've had to improve a fair bit on the Kunit helpers already
found in the tree in order to register a full blown and somewhat functional KMS
driver.
It's of course relying on a mock so that we can test it anywhere. The mocking
approach created a number of issues, the main one being that we need to create
a decent mock in the first place, see patch 22. The basic idea is that I
created some structures to provide a decent approximation of the actual
hardware, and that would support both major architectures supported by vc4.
This is of course meant to evolve over time and support more tests, but I've
focused on testing the HVS FIFO assignment code which is fairly tricky (and the
tests have actually revealed one more bug with our current implementation). I
used to have a userspace implementation of those tests, where I would copy and
paste the kernel code and run the tests on a regular basis. It's was obviously
fairly suboptimal, so it seemed like the perfect testbed for that series.
It can be run using:
./tools/testing/kunit/kunit.py run \
--kunitconfig=drivers/gpu/drm/vc4/tests/.kunitconfig \
--cross_compile aarch64-linux-gnu- --arch arm64
Let me know what you think,
Maxime
To: David Airlie <airlied(a)gmail.com>
To: Daniel Vetter <daniel(a)ffwll.ch>
To: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
To: Maxime Ripard <mripard(a)kernel.org>
To: Thomas Zimmermann <tzimmermann(a)suse.de>
Cc: Dave Stevenson <dave.stevenson(a)raspberrypi.com>
Cc: Javier Martinez Canillas <javierm(a)redhat.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Maíra Canal <mairacanal(a)riseup.net>
Cc: Brendan Higgins <brendan.higgins(a)linux.dev>
Cc: David Gow <davidgow(a)google.com>
Cc: linux-kselftest(a)vger.kernel.org
Cc: kunit-dev(a)googlegroups.com
Cc: dri-devel(a)lists.freedesktop.org
Cc: linux-kernel(a)vger.kernel.org
Cc: linux-media(a)vger.kernel.org
Cc: linaro-mm-sig(a)lists.linaro.org
Signed-off-by: Maxime Ripard <maxime(a)cerno.tech>
---
Changes in v2:
- Added some documentation for public functions
- Removed the fake device probe/remove workqueue
- Made sure the tests could be compiled as modules
- Moved the vc4 tests in the vc4 module
- Applied some of the preliminary patches
- Rebased on top of current drm-misc-next branch
- Fixed checkpatch issues
- Introduced BCM2835 (Pi0-3) tests for muxing
- Introduced tests to cover past bugs we had
- Link to v1: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v1-0-051a0bb60a16@cerno.…
---
Maxime Ripard (17):
drm/tests: helpers: Move the helper header to include/drm
drm/tests: helpers: Document drm_kunit_device_init()
drm/tests: helpers: Rename the device init helper
drm/tests: helpers: Remove the name parameter
drm/tests: helpers: Create the device in another function
drm/tests: helpers: Switch to a platform_device
drm/tests: helpers: Make sure the device is bound
drm/tests: helpers: Allow for a custom device struct to be allocated
drm/tests: helpers: Allow to pass a custom drm_driver
drm/tests: Add a test for DRM managed actions
drm/vc4: Move HVS state to main header
drm/vc4: crtc: Introduce a lower-level crtc init helper
drm/vc4: crtc: Make encoder lookup helper public
drm/vc4: hvs: Provide a function to initialize the HVS structure
drm/vc4: tests: Introduce a mocking infrastructure
drm/vc4: tests: Fail the current test if we access a register
drm/vc4: tests: Add unit test suite for the PV muxing
drivers/gpu/drm/tests/Makefile | 1 +
drivers/gpu/drm/tests/drm_client_modeset_test.c | 19 +-
drivers/gpu/drm/tests/drm_kunit_helpers.c | 106 ++-
drivers/gpu/drm/tests/drm_kunit_helpers.h | 11 -
drivers/gpu/drm/tests/drm_managed_test.c | 71 ++
drivers/gpu/drm/tests/drm_modes_test.c | 19 +-
drivers/gpu/drm/tests/drm_probe_helper_test.c | 20 +-
drivers/gpu/drm/vc4/Kconfig | 15 +
drivers/gpu/drm/vc4/Makefile | 7 +
drivers/gpu/drm/vc4/tests/.kunitconfig | 14 +
drivers/gpu/drm/vc4/tests/vc4_mock.c | 200 +++++
drivers/gpu/drm/vc4/tests/vc4_mock.h | 63 ++
drivers/gpu/drm/vc4/tests/vc4_mock_crtc.c | 41 +
drivers/gpu/drm/vc4/tests/vc4_mock_output.c | 138 +++
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 47 +
drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c | 1039 +++++++++++++++++++++++
drivers/gpu/drm/vc4/vc4_crtc.c | 102 ++-
drivers/gpu/drm/vc4/vc4_dpi.c | 13 +-
drivers/gpu/drm/vc4/vc4_drv.c | 4 +-
drivers/gpu/drm/vc4/vc4_drv.h | 91 +-
drivers/gpu/drm/vc4/vc4_dsi.c | 9 +-
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 4 +
drivers/gpu/drm/vc4/vc4_hvs.c | 81 +-
drivers/gpu/drm/vc4/vc4_kms.c | 25 +-
drivers/gpu/drm/vc4/vc4_txp.c | 15 +-
drivers/gpu/drm/vc4/vc4_vec.c | 13 +-
include/drm/drm_kunit_helpers.h | 91 ++
27 files changed, 2087 insertions(+), 172 deletions(-)
---
base-commit: 199557fab92548f8e9d5207e385097213abe0cab
change-id: 20221123-rpi-kunit-tests-87a388492a73
Best regards,
--
Maxime Ripard <maxime(a)cerno.tech>
Hi,
This series introduce Kunit tests to the vc4 KMS driver, but unlike what we
have been doing so far in KMS, it actually tests the atomic modesetting code.
In order to do so, I've had to improve a fair bit on the Kunit helpers already
found in the tree in order to register a full blown and somewhat functional KMS
driver.
It's of course relying on a mock so that we can test it anywhere. The mocking
approach created a number of issues, the main one being that we need to create
a decent mock in the first place, see patch 22. The basic idea is that I
created some structures to provide a decent approximation of the actual
hardware, and that would support both major architectures supported by vc4.
This is of course meant to evolve over time and support more tests, but I've
focused on testing the HVS FIFO assignment code which is fairly tricky (and the
tests have actually revealed one more bug with our current implementation). I
used to have a userspace implementation of those tests, where I would copy and
paste the kernel code and run the tests on a regular basis. It's was obviously
fairly suboptimal, so it seemed like the perfect testbed for that series.
Let me know what you think,
Maxime
To: David Airlie <airlied(a)gmail.com>
To: Daniel Vetter <daniel(a)ffwll.ch>
To: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
To: Maxime Ripard <mripard(a)kernel.org>
To: Thomas Zimmermann <tzimmermann(a)suse.de>
Cc: Dave Stevenson <dave.stevenson(a)raspberrypi.com>
Cc: Javier Martinez Canillas <javierm(a)redhat.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Maíra Canal <mairacanal(a)riseup.net>
Cc: Brendan Higgins <brendan.higgins(a)linux.dev>
Cc: David Gow <davidgow(a)google.com>
Cc: linux-kselftest(a)vger.kernel.org
Cc: kunit-dev(a)googlegroups.com
Cc: dri-devel(a)lists.freedesktop.org
Cc: linux-kernel(a)vger.kernel.org
Cc: linux-media(a)vger.kernel.org
Cc: linaro-mm-sig(a)lists.linaro.org
Signed-off-by: Maxime Ripard <maxime(a)cerno.tech>
---
Maxime Ripard (24):
drm/tests: helpers: Rename the device init helper
drm/tests: helpers: Remove the name parameter
drm/tests: helpers: Create the device in another function
drm/tests: helpers: Switch to a platform_device
drm/tests: helpers: Make sure the device is bound
drm/tests: kunit: Allow for a custom device struct to be allocated
drm/tests: helpers: Allow to pass a custom drm_driver
drm/tests: Add a test for DRM managed actions
drm/atomic: Constify the old/new state accessors
drm/vc4: kms: Sort the CRTCs by output before assigning them
drm/vc4: Constify container_of wrappers
drm/vc4: Move HVS state to main header
drm/vc4: kms: Constify the HVS old/new state helpers
drm/vc4: txp: Reorder the variable assignments
drm/vc4: Add TXP encoder type
drm/vc4: txp: Initialise the CRTC before the encoder and connector
drm/vc4: crtc: Pass the device and data in vc4_crtc_init
drm/vc4: crtc: Introduce a lower-level crtc init helper
drm/vc4: crtc: Make encoder lookup helper public
drm/vc4: crtc: Provide a CRTC name
drm/vc4: hvs: Provide a function to initialize the HVS structure
drm/vc4: tests: Introduce a mocking infrastructure
drm/vc4: tests: Fail the current test if we access a register
drm/vc4: tests: Add unit test suite for the PV muxing
drivers/gpu/drm/drm_atomic.c | 12 +-
drivers/gpu/drm/tests/Makefile | 1 +
drivers/gpu/drm/tests/drm_client_modeset_test.c | 16 +-
drivers/gpu/drm/tests/drm_kunit_helpers.c | 116 +++--
drivers/gpu/drm/tests/drm_kunit_helpers.h | 39 +-
drivers/gpu/drm/tests/drm_managed_test.c | 68 +++
drivers/gpu/drm/vc4/Kconfig | 15 +
drivers/gpu/drm/vc4/Makefile | 1 +
drivers/gpu/drm/vc4/tests/.kunitconfig | 14 +
drivers/gpu/drm/vc4/tests/Makefile | 8 +
drivers/gpu/drm/vc4/tests/vc4_mock.c | 174 +++++++
drivers/gpu/drm/vc4/tests/vc4_mock.h | 58 +++
drivers/gpu/drm/vc4/tests/vc4_mock_crtc.c | 39 ++
drivers/gpu/drm/vc4/tests/vc4_mock_output.c | 97 ++++
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 45 ++
drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c | 624 ++++++++++++++++++++++++
drivers/gpu/drm/vc4/vc4_crtc.c | 119 +++--
drivers/gpu/drm/vc4/vc4_dpi.c | 13 +-
drivers/gpu/drm/vc4/vc4_drv.c | 4 +-
drivers/gpu/drm/vc4/vc4_drv.h | 113 ++++-
drivers/gpu/drm/vc4/vc4_dsi.c | 9 +-
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 4 +
drivers/gpu/drm/vc4/vc4_hvs.c | 81 +--
drivers/gpu/drm/vc4/vc4_kms.c | 138 +++---
drivers/gpu/drm/vc4/vc4_txp.c | 66 ++-
drivers/gpu/drm/vc4/vc4_vec.c | 13 +-
include/drm/drm_atomic.h | 32 +-
27 files changed, 1678 insertions(+), 241 deletions(-)
---
base-commit: 35c3a2d02f0dc153a5f2f304ba33e1436b6a8d8f
change-id: 20221123-rpi-kunit-tests-87a388492a73
Best regards,
--
Maxime Ripard <maxime(a)cerno.tech>
I've been collecting these typo fixes for a while and it feels like
time to send them in.
Signed-off-by: T.J. Mercier <tjmercier(a)google.com>
---
drivers/dma-buf/dma-buf.c | 14 +++++++-------
include/linux/dma-buf.h | 6 +++---
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index dd0f83ee505b..614ccd208af4 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1141,7 +1141,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment, DMA_BUF);
*
* @dmabuf: [in] buffer which is moving
*
- * Informs all attachmenst that they need to destroy and recreated all their
+ * Informs all attachments that they need to destroy and recreate all their
* mappings.
*/
void dma_buf_move_notify(struct dma_buf *dmabuf)
@@ -1159,11 +1159,11 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, DMA_BUF);
/**
* DOC: cpu access
*
- * There are mutliple reasons for supporting CPU access to a dma buffer object:
+ * There are multiple reasons for supporting CPU access to a dma buffer object:
*
* - Fallback operations in the kernel, for example when a device is connected
* over USB and the kernel needs to shuffle the data around first before
- * sending it away. Cache coherency is handled by braketing any transactions
+ * sending it away. Cache coherency is handled by bracketing any transactions
* with calls to dma_buf_begin_cpu_access() and dma_buf_end_cpu_access()
* access.
*
@@ -1190,7 +1190,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, DMA_BUF);
* replace ION buffers mmap support was needed.
*
* There is no special interfaces, userspace simply calls mmap on the dma-buf
- * fd. But like for CPU access there's a need to braket the actual access,
+ * fd. But like for CPU access there's a need to bracket the actual access,
* which is handled by the ioctl (DMA_BUF_IOCTL_SYNC). Note that
* DMA_BUF_IOCTL_SYNC can fail with -EAGAIN or -EINTR, in which case it must
* be restarted.
@@ -1264,10 +1264,10 @@ static int __dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
* preparations. Coherency is only guaranteed in the specified range for the
* specified access direction.
* @dmabuf: [in] buffer to prepare cpu access for.
- * @direction: [in] length of range for cpu access.
+ * @direction: [in] direction of access.
*
* After the cpu access is complete the caller should call
- * dma_buf_end_cpu_access(). Only when cpu access is braketed by both calls is
+ * dma_buf_end_cpu_access(). Only when cpu access is bracketed by both calls is
* it guaranteed to be coherent with other DMA access.
*
* This function will also wait for any DMA transactions tracked through
@@ -1307,7 +1307,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_begin_cpu_access, DMA_BUF);
* actions. Coherency is only guaranteed in the specified range for the
* specified access direction.
* @dmabuf: [in] buffer to complete cpu access for.
- * @direction: [in] length of range for cpu access.
+ * @direction: [in] direction of access.
*
* This terminates CPU access started with dma_buf_begin_cpu_access().
*
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 71731796c8c3..1d61a4f6db35 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -330,7 +330,7 @@ struct dma_buf {
* @lock:
*
* Used internally to serialize list manipulation, attach/detach and
- * vmap/unmap. Note that in many cases this is superseeded by
+ * vmap/unmap. Note that in many cases this is superseded by
* dma_resv_lock() on @resv.
*/
struct mutex lock;
@@ -365,7 +365,7 @@ struct dma_buf {
*/
const char *name;
- /** @name_lock: Spinlock to protect name acces for read access. */
+ /** @name_lock: Spinlock to protect name access for read access. */
spinlock_t name_lock;
/**
@@ -402,7 +402,7 @@ struct dma_buf {
* anything the userspace API considers write access.
*
* - Drivers may just always add a write fence, since that only
- * causes unecessarily synchronization, but no correctness issues.
+ * causes unnecessary synchronization, but no correctness issues.
*
* - Some drivers only expose a synchronous userspace API with no
* pipelining across drivers. These do not set any fences for their
--
2.38.1.584.g0f3c55d4c2-goog
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated devices, where all
buffers are actually all resident system memory, there's a huge
temptation to assume that a struct page is always present and useable
like for any more pagecache backed mmap. This has the potential to
result in a uapi nightmare.
To stop this gap require that DMA buffer mmaps are VM_PFNMAP, which
blocks get_user_pages and all the other struct page based
infrastructure for everyone. In spirit this is the uapi counterpart to
the kernel-internal CONFIG_DMABUF_DEBUG.
Motivated by a recent patch which wanted to swich the system dma-buf
heap to vm_insert_page instead of vm_insert_pfn.
v2:
Jason brought up that we also want to guarantee that all ptes have the
pte_special flag set, to catch fast get_user_pages (on architectures
that support this). Allowing VM_MIXEDMAP (like VM_SPECIAL does) would
still allow vm_insert_page, but limiting to VM_PFNMAP will catch that.
From auditing the various functions to insert pfn pte entires
(vm_insert_pfn_prot, remap_pfn_range and all it's callers like
dma_mmap_wc) it looks like VM_PFNMAP is already required anyway, so
this should be the correct flag to check for.
v3: Change to WARN_ON_ONCE (Thomas Zimmermann)
References: https://lore.kernel.org/lkml/CAKMK7uHi+mG0z0HUmNt13QCCvutuRVjpcR0NjRL12k-Wb…
Acked-by: Christian König <christian.koenig(a)amd.com>
Acked-by: Thomas Zimmermann <tzimmermann(a)suse.de>
Cc: Thomas Zimmermann <tzimmermann(a)suse.de>
Cc: Jason Gunthorpe <jgg(a)ziepe.ca>
Cc: Suren Baghdasaryan <surenb(a)google.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com>
Cc: Sumit Semwal <sumit.semwal(a)linaro.org>
Cc: "Christian König" <christian.koenig(a)amd.com>
Cc: linux-media(a)vger.kernel.org
Cc: linaro-mm-sig(a)lists.linaro.org
--
Ok I entirely forgot about this patch but stumbled over it and checked
what's up with it no. I think it's ready now for merging:
- shmem helper patches to fix up vgem landed
- ttm has been fixed since a while
- I don't think we've had any other open issues
Time to lock down this uapi contract for real?
-Daniel
---
drivers/dma-buf/dma-buf.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index b6c36914e7c6..88718665c3c3 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -150,6 +150,8 @@ static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
ret = dmabuf->ops->mmap(dmabuf, vma);
dma_resv_unlock(dmabuf->resv);
+ WARN_ON_ONCE(!(vma->vm_flags & VM_PFNMAP));
+
return ret;
}
@@ -1495,6 +1497,8 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
ret = dmabuf->ops->mmap(dmabuf, vma);
dma_resv_unlock(dmabuf->resv);
+ WARN_ON_ONCE(!(vma->vm_flags & VM_PFNMAP));
+
return ret;
}
EXPORT_SYMBOL_NS_GPL(dma_buf_mmap, DMA_BUF);
--
2.37.2