Le 11/02/2025 à 11:43, José Expósito a écrit :
On Thu, Jan 30, 2025 at 02:48:19PM +0100, Louis Chauvet wrote:On 29/01/25 - 12:00, José Expósito wrote:Add a list of planes to vkms_config and create as many planes as configured during output initialization. For backwards compatibility, add one primary plane and, if configured, one cursor plane and NUM_OVERLAY_PLANES planes to the default configuration. Signed-off-by: Louis Chauvet <louis.chauvet@xxxxxxxxxxx> Signed-off-by: José Expósito <jose.exposito89@xxxxxxxxx>Co-developped-by: Louis Chauvet <louis.chauvet@xxxxxxxxxxx> Signed-off-by: Louis Chauvet <louis.chauvet@xxxxxxxxxxx> Signed-off-by: José Expósito <jose.exposito89@xxxxxxxxx> [...]diff --git a/drivers/gpu/drm/vkms/tests/vkms_config_test.c b/drivers/gpu/drm/vkms/tests/vkms_config_test.c[...]+static void vkms_config_test_get_planes(struct kunit *test) +{ + struct vkms_config *config; + struct vkms_config_plane *plane_cfg1, *plane_cfg2; + struct vkms_config_plane **array; + size_t length; + + config = vkms_config_create("test"); + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, config); + + array = vkms_config_get_planes(config, &length); + KUNIT_ASSERT_EQ(test, length, 0); + KUNIT_ASSERT_NULL(test, array); + + plane_cfg1 = vkms_config_add_plane(config); + array = vkms_config_get_planes(config, &length); + KUNIT_ASSERT_EQ(test, length, 1); + KUNIT_ASSERT_PTR_EQ(test, array[0], plane_cfg1); + kfree(array); + + plane_cfg2 = vkms_config_add_plane(config); + array = vkms_config_get_planes(config, &length); + KUNIT_ASSERT_EQ(test, length, 2); + KUNIT_ASSERT_PTR_EQ(test, array[0], plane_cfg1); + KUNIT_ASSERT_PTR_EQ(test, array[1], plane_cfg2); + kfree(array); + + vkms_config_destroy_plane(plane_cfg1); + array = vkms_config_get_planes(config, &length); + KUNIT_ASSERT_EQ(test, length, 1); + KUNIT_ASSERT_PTR_EQ(test, array[0], plane_cfg2); + kfree(array); + + vkms_config_destroy(config); +}In this test I have the feeling that vkms_config_get_planes always returns a predictable order. It is maybe trivial here, but I would prefer to shows that the order is not stable, for example: bool plane_cfg1_found = false; bool plane_cfg2_found = false; vkms_config_for_each_plane(config, plane_cfg) { if (plane_cfg == plane_cfg1) plane_cfg1_found = true; else if (plane_cfg == plane_cfg2) plane_cfg2_found = true; else KUNIT_FAILS("Unexpected plane"); } KUNIT_ASSERT(test, plane_cfg1_found); KUNIT_ASSERT(test, plane_cfg2_found); [...]+static void vkms_config_test_valid_plane_number(struct kunit *test) +{ + struct vkms_config *config; + struct vkms_config_plane *plane_cfg; + int n; + + config = vkms_config_default_create(false, false, false); + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, config); + + /* Invalid: No planes */ + plane_cfg = list_first_entry(&config->planes, typeof(*plane_cfg), link); + vkms_config_destroy_plane(plane_cfg); + KUNIT_EXPECT_FALSE(test, vkms_config_is_valid(config)); + + /* Invalid: Too many planes */ + for (n = 0; n <= 32; n++) + vkms_config_add_plane(config); + + KUNIT_EXPECT_FALSE(test, vkms_config_is_valid(config)); + + vkms_config_destroy(config); +}For this function, the naming is a bit strange, it says "valid_plane_number", but you test only invalid plane number.The reason for this naming is that it tests the valid_plane_number() function called by vkms_config_is_valid(). The applies for the other valid_* tests.
Hoo, I see, okk!
However, I don't mind changing its name to so it reflects the test rather than the tested function.
I prefer an "implementation independent" name, as the content of vkms_config_is_valid may change over time.
Changed in v2.
Perfect!
Can you rename it to vkms_config_test_invalid_plane_number? [...]diff --git a/drivers/gpu/drm/vkms/vkms_config.c b/drivers/gpu/drm/vkms/vkms_config.c[...]+struct vkms_config_plane **vkms_config_get_planes(const struct vkms_config *config, + size_t *out_length) +{ + struct vkms_config_plane **array; + struct vkms_config_plane *plane_cfg; + size_t length; + int n = 0; + + length = list_count_nodes((struct list_head *)&config->planes); + if (length == 0) { + *out_length = length; + return NULL; + } + + array = kmalloc_array(length, sizeof(*array), GFP_KERNEL); + if (!array) + return ERR_PTR(-ENOMEM); + + list_for_each_entry(plane_cfg, &config->planes, link) { + array[n] = plane_cfg; + n++; + } + + *out_length = length; + return array; +}To join the comment on the test, I am not a big fan of creating a new list to return to the caller, for three reasons: - the caller needs to manage an other pointer; - the caller needs to understand that the content of the array is only valid if: the config is not freed, nobody else removed anything from the planes; - the caller may think this list always have the same order if he looks at the tests. I would prefer a simple macro to do an iteration over the config->planes list: (I did not test this macro, but you have this idea) #define vkms_config_iter_plane(config, plane_cfg) \ list_for_each_entry((plane_cfg), &(config).planes, link) This way: - no new pointer to manage; - if one day we have concurency issue, we just have to protect config, not config+all the planes; - there is no expected order. [...]bool vkms_config_is_valid(struct vkms_config *config) { + if (!valid_plane_number(config)) + return false; + + if (!valid_plane_type(config)) + return false; + return true; }I really like the idea to split the validation function, way simpler! [...]+void vkms_config_destroy_plane(struct vkms_config_plane *plane_cfg) +{ + list_del(&plane_cfg->link); + kfree(plane_cfg); +}I would prefer a "standard" function pair, i.e.: add/remove or create/destroy, not add/destroy. For me it should be create/destroy, you create the plane by using a config, so it is clear it will be attached to it. If you choose add/remove, you should explains in the documentation that remove is also doing kfree. [...]diff --git a/drivers/gpu/drm/vkms/vkms_output.c b/drivers/gpu/drm/vkms/vkms_output.c[...]@@ -11,61 +11,63 @@ int vkms_output_init(struct vkms_device *vkmsdev) struct vkms_connector *connector; struct drm_encoder *encoder; struct vkms_output *output; - struct vkms_plane *primary, *overlay, *cursor = NULL; - int ret; + struct vkms_plane *primary = NULL, *cursor = NULL; + struct vkms_config_plane **plane_cfgs = NULL; + size_t n_planes; + int ret = 0; int writeback; unsigned int n;I think it could be interesting to have a vkms_config_is_valid call here. It will avoid raising DRM errors or create unexpected devices. It will also garantee in a later patch that vkms_config_crtc_get_primary_plane is a valid pointer.- /* - * Initialize used plane. One primary plane is required to perform the composition. - * - * The overlay and cursor planes are not mandatory, but can be used to perform complex - * composition. - */ - primary = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_PRIMARY); - if (IS_ERR(primary)) - return PTR_ERR(primary); + plane_cfgs = vkms_config_get_planes(vkmsdev->config, &n_planes); + if (IS_ERR(plane_cfgs)) + return PTR_ERR(plane_cfgs);If you agree on the iterator implementation, this code could be simplified a lot.- if (vkmsdev->config->cursor) { - cursor = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_CURSOR); - if (IS_ERR(cursor)) - return PTR_ERR(cursor); + for (n = 0; n < n_planes; n++) { + struct vkms_config_plane *plane_cfg; + enum drm_plane_type type; + + plane_cfg = plane_cfgs[n]; + type = vkms_config_plane_get_type(plane_cfg); + + plane_cfg->plane = vkms_plane_init(vkmsdev, type);Can we pass plane_cfg in vkms_plane_init? This way we don't have to touch vkms_output_init when adding new vkms_config_plane members.While it'll be required once we allow to configure more parameters, I don't think we need it right now. To keep things as simple as possible, I'd prefer to delay it until required.
I understand your point, especially since your patch don't add new parameters to vkms_plane_init.
Thanks!
Thanks, Jose+ if (IS_ERR(plane_cfg->plane)) { + DRM_DEV_ERROR(dev->dev, "Failed to init vkms plane\n"); + ret = PTR_ERR(plane_cfg->plane); + goto err_free; + } + + if (type == DRM_PLANE_TYPE_PRIMARY) + primary = plane_cfg->plane; + else if (type == DRM_PLANE_TYPE_CURSOR) + cursor = plane_cfg->plane; }[...]
-- Louis Chauvet, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
