This series provides a bunch of quick updates which should make the
coverage from pcm-test a bit more useful, it adds some support for
skipping tests when the hardware/driver is unable to support the
requested configuration and then expands the set of cases we cover to
include more sample rates and channel counts. This should exercise
switching between 8kHz and 44.1kHz based rates and ensure that clocking
doesn't get confused by non-stereo channel counts, both of which are I
expect common real world errors, at least for embedded cards.
v2:
- Rebase onto Takashi's current tree.
- Tweak the buffer sizes for the newly added cases, don't be quite
so ambitious in how big a buffer we request for 96kHz and don't
go quite so small for 8kHz since some devices start hitting lower
limits on period size and struggle to deliver accurate timing.
Mark Brown (6):
kselftest/alsa: Refactor pcm-test to list the tests to run in a struct
kselftest/alsa: Report failures to set the requested sample rate as
skips
kselftest/alsa: Report failures to set the requested channels as skips
kselftest/alsa: Don't any configuration in the sample config
kselftest/alsa: Provide more meaningful names for tests
kselftest/alsa: Add more coverage of sample rates and channel counts
.../alsa/conf.d/Lenovo_ThinkPad_P1_Gen2.conf | 35 ++++----
tools/testing/selftests/alsa/pcm-test.c | 88 +++++++++++++------
2 files changed, 81 insertions(+), 42 deletions(-)
base-commit: 2133dc91d6658242009177b564ac47c49e08668a
--
2.30.2
On 11/28/22 15:53, Maxime Ripard wrote:
> In order to test the current atomic_check hooks we need to have a DRM
> device that has roughly the same capabilities and layout that the actual
> hardware. We'll also need a bunch of functions to create arbitrary
> atomic states.
>
> Let's create some helpers to create a device that behaves like the real
> one, and some helpers to maintain the atomic state we want to check.
>
> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech>
> ---
[...]
> +
> +config DRM_VC4_KUNIT_TEST
> + bool "KUnit tests for VC4" if !KUNIT_ALL_TESTS
> + depends on DRM_VC4 && KUNIT
shouldn't this depend on DRM_KUNIT_TEST instead ?
[...]
> +static struct vc4_dev *__mock_device(struct kunit *test, bool is_vc5)
> +{
> + struct drm_device *drm;
> + const struct drm_driver *drv = is_vc5 ? &vc5_drm_driver : &vc4_drm_driver;
> + const struct vc4_mock_desc *desc = is_vc5 ? &vc5_mock : &vc4_mock;
> + struct vc4_dev *vc4;
Since it could be vc4 or vc5, maybe can be renamed to just struct vc_dev *vc ?
> +struct vc4_dummy_plane *vc4_dummy_plane(struct kunit *test,
> + struct drm_device *drm,
> + enum drm_plane_type type)
> +{
> + struct vc4_dummy_plane *dummy_plane;
> + struct drm_plane *plane;
> +
> + dummy_plane = drmm_universal_plane_alloc(drm,
> + struct vc4_dummy_plane, plane.base,
> + 0,
> + &vc4_dummy_plane_funcs,
> + vc4_dummy_plane_formats,
> + ARRAY_SIZE(vc4_dummy_plane_formats),
> + NULL,
> + DRM_PLANE_TYPE_PRIMARY,
> + NULL);
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, dummy_plane);
> +
> + plane = &dummy_plane->plane.base;
> + drm_plane_helper_add(plane, &vc4_dummy_plane_helper_funcs);
> +
> + return dummy_plane;
> +}
I guess many of these helpers could grow to be generic, like this one since
most drivers support the DRM_FORMAT_XRGB8888 format for their primary plane.
[...]
>
> +extern const struct vc4_pv_data bcm2835_pv0_data;
> +extern const struct vc4_pv_data bcm2835_pv1_data;
> +extern const struct vc4_pv_data bcm2835_pv2_data;
> +extern const struct vc4_pv_data bcm2711_pv0_data;
> +extern const struct vc4_pv_data bcm2711_pv1_data;
> +extern const struct vc4_pv_data bcm2711_pv2_data;
> +extern const struct vc4_pv_data bcm2711_pv3_data;
> +extern const struct vc4_pv_data bcm2711_pv4_data;
> +
Maybe the driver could expose a helper function to get the pixelvalve data
and avoid having to expose all of these variables? For example you could
define an enum vc4_pixelvalve type and have something like the following:
const struct vc4_pv_data *vc4_crtc_get_pixelvalve_data(enum vc4_pixelvalve pv);
All these are small nits though, the patch looks great to me and I think is
awesome to have this level of testing with KUnit. Hope other drivers follow
your lead.
Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 11/28/22 15:53, Maxime Ripard wrote:
> We'll need to use those helpers from drivers too, so let's move it to a
> more visible location.
>
> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech>
> ---
> drivers/gpu/drm/tests/drm_client_modeset_test.c | 3 +--
> drivers/gpu/drm/tests/drm_kunit_helpers.c | 3 +--
> drivers/gpu/drm/tests/drm_modes_test.c | 3 +--
> drivers/gpu/drm/tests/drm_probe_helper_test.c | 3 +--
> {drivers/gpu/drm/tests => include/drm}/drm_kunit_helpers.h | 0
> 5 files changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c b/drivers/gpu/drm/tests/drm_client_modeset_test.c
> index 52929536a158..ed2f62e92fea 100644
> --- a/drivers/gpu/drm/tests/drm_client_modeset_test.c
> +++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
> @@ -8,12 +8,11 @@
> #include <drm/drm_connector.h>
> #include <drm/drm_edid.h>
> #include <drm/drm_drv.h>
> +#include <drm/drm_kunit_helpers.h>
I wonder if now that this header was moved outside of the tests directory,
if we should add stub functions in the header file that are just defined
but do nothing if CONFIG_DRM_KUNIT_TEST isn't enabled. So that including
it in drivers will be a no-op.
Or do you plan to conditionally include this header file in drivers? So
that is only included when CONFIG_DRM_KUNIT_TEST is enabled?
Another thing that wondered is if we want a different namespace for this
header, i.e: <drm/testing/drm_kunit_helpers.h>, to make it clear that is
not part of the DRM API but just for testing helpers.
But these are open questions really, and they can be done as follow-up:
Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
This patch series adds xfrm metadata helpers using the unstable kfunc
call interface for the TC-BPF hooks.
This allows steering traffic towards different IPsec connections based
on logic implemented in bpf programs.
The helpers are integrated into the xfrm_interface module. For this
purpose the main functionality of this module is moved to
xfrm_interface_core.c.
Eyal Birger (3):
xfrm: interface: rename xfrm_interface.c to xfrm_interface_core.c
xfrm: interface: Add unstable helpers for setting/getting XFRM
metadata from TC-BPF
selftests/bpf: add xfrm_info tests
include/net/dst_metadata.h | 1 +
include/net/xfrm.h | 20 +
net/core/dst.c | 4 +
net/xfrm/Makefile | 8 +
net/xfrm/xfrm_interface_bpf.c | 92 +++++
...xfrm_interface.c => xfrm_interface_core.c} | 15 +
tools/testing/selftests/bpf/config | 2 +
.../selftests/bpf/prog_tests/test_xfrm_info.c | 342 ++++++++++++++++++
.../selftests/bpf/progs/test_xfrm_info_kern.c | 74 ++++
9 files changed, 558 insertions(+)
create mode 100644 net/xfrm/xfrm_interface_bpf.c
rename net/xfrm/{xfrm_interface.c => xfrm_interface_core.c} (98%)
create mode 100644 tools/testing/selftests/bpf/prog_tests/test_xfrm_info.c
create mode 100644 tools/testing/selftests/bpf/progs/test_xfrm_info_kern.c
--
2.34.1