Reviewed-by: Simon Ser
Reviewed-by: Simon Ser
This patch should probably come after all patches introducing the
properties referenced in the docs, e.g. NEXT and COLOR_PIPELINE.
Probably after "[13/45] drm/colorop: Introduce
DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE"?
> +/**
> + * DOC: overview
> + *
> + * A colorop represents a single color operati
Reviewed-by: Simon Ser
> +int
> +drm_atomic_add_affected_colorops(struct drm_atomic_state *state,
> + struct drm_plane *plane)
> +{
> + struct drm_colorop *colorop;
> + struct drm_colorop_state *colorop_state;
> +
> + WARN_ON(!drm_atomic_get_new_plane_state(state, plane));
> +
> +
Two nits below, regardless:
Reviewed-by: Simon Ser
> +static int drm_colorop_create_data_prop(struct drm_device *dev, struct
> drm_colorop *colorop)
> +{
> + struct drm_property *prop;
> +
> + /* data */
> + prop = drm_property_create(dev, DRM_MODE_PROP_ATOMIC |
> DRM_MODE_PROP_BLO
> v4:
> - Don't block setting of COLOR_RANGE and COLOR_ENCODING
>when client cap is set
Can you remind me why these should not be blocked?
We should also add doc comments in the color_range and color_encoding fields,
to document that drivers should ignore these fields when the cap is set.
Reviewed-by: Simon Ser
> +void drm_colorop_set_next_property(struct drm_colorop *colorop, struct
> drm_colorop *next)
> +{
> + if (!colorop->next_property)
> + return;
Why is this early return necessary? Shouldn't this field be always
populated?
Even if that's not the case, I don't think silently ignor
> +static void drm_atomic_colorop_print_state(struct drm_printer *p,
> + const struct drm_colorop_state *state)
> +{
> + struct drm_colorop *colorop = state->colorop;
> +
> + drm_printf(p, "colorop[%u]:\n", colorop->base.id);
> + drm_printf(p, "\ttype=%s\n", drm_get_colorop_
10 matches
Mail list logo
