Thanks a lot for sending the updated series, Alex! I've looked at all
of the core DRM patches and they all look pretty close to being R-b'ed.
I don't think I'd have time to look at vkms or amdgpu patches. Let me
know if I missed anything!
Simon
I would prefer these functions to be introduced together with the
patches adding functions to create objects and adding the new fields.
That way it's easier to check the symmetry and at no point in the
series there are memory leaks.
Additionally, I would avoid using the name "cleanup", which seems
I'm personally not a fan of such boolean function arguments, especially
when caller and callee are far apart. From the caller side, the meaning
of the boolean argument is not immediately clear.
I would prefer a "flags" argument, which can take a e.g.
DRM_COLOROP_FLAG_ALLOW_BYPASS value.
But I'm n
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
Note, this patch adds new values in the middle of the enum. This is in
general a breaking uAPI change: all enum values afterwards will get
re-numbered.
Maybe this patch should come before the PQ 125 one. In this series it
shouldn't matter either way because we're also introducing the enum, but
(1)
Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
Two nits below, regardless:
Reviewed-by: Simon Ser
> + } else if (property == plane->color_pipeline_property) {
> + /* find DRM colorop object */
> + struct drm_colorop *colorop = NULL;
> +
> + colorop = drm_colorop_find(dev, file_priv, val);
> +
> +
10 matches
Mail list logo
