[PATCH v1 3/9] drm: add drm_atomic_helper_bridge_dsi_input_bus_fmt

Laurent Pinchart laurent.pinchart at ideasonboard.com
Tue Feb 8 00:44:25 UTC 2022


Hello,

On Mon, Feb 07, 2022 at 02:32:45PM -0800, Doug Anderson wrote:
> On Sun, Feb 6, 2022 at 7:44 AM Sam Ravnborg <sam at ravnborg.org> wrote:
> >
> > There is a number of bridge drivers that supports a single media bus
> > format for DSI. Add a helper to avoid duplicating the code.
> >
> > Signed-off-by: Sam Ravnborg <sam at ravnborg.org>
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c | 41 +++++++++++++++++++++++++++++
> >  include/drm/drm_atomic_helper.h     |  7 +++++
> >  2 files changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > index a7a05e1e26bb..94f313dc196f 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -3549,3 +3549,44 @@ drm_atomic_helper_bridge_propagate_bus_fmt(struct drm_bridge *bridge,
> >         return input_fmts;
> >  }
> >  EXPORT_SYMBOL(drm_atomic_helper_bridge_propagate_bus_fmt);
> > +
> > +/**
> > + * drm_atomic_helper_bridge_dsi_input_bus_fmt - Define one DSI output format
> 
> Is the description right? It's called "input" format but it defines an
> output format?
> 
> 
> > + * @bridge: bridge control structure
> > + * @bridge_state: new bridge state
> > + * @crtc_state: new CRTC state
> > + * @conn_state: new connector state
> > + * @output_fmt: tested output bus format
> > + * @num_input_fmts: will contain the size of the returned array
> 
> Maybe indicate that it's always 1 in the comments?
> 
> > + *
> > + * This helper is an implementation of the
> > + * &drm_bridge_funcs.atomic_get_input_bus_fmts operation for bridges that supports
> > + * a single DSI media bus format MEDIA_BUS_FMT_RGB888_1X24.
> > + *
> > + * RETURNS
> 
> kernel-doc can't parse this return syntax and warns:
> 
> warning: No description found for return value of
> 'drm_atomic_helper_bridge_dsi_input_bus_fmt'
> 
> 
> > + * A format array with one entry containing MEDIA_BUS_FMT_RGB888_1X24,
> > + * or NULL if the allocation failed
> > + */
> > +u32 *
> > +drm_atomic_helper_bridge_dsi_input_bus_fmt(struct drm_bridge *bridge,
> > +                                          struct drm_bridge_state *bridge_state,
> > +                                          struct drm_crtc_state *crtc_state,
> > +                                          struct drm_connector_state *conn_state,
> > +                                          u32 output_fmt,
> > +                                          unsigned int *num_input_fmts)
> > +{
> > +       u32 *input_fmts;
> > +
> > +       *num_input_fmts = 0;
> > +
> > +       input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts), GFP_KERNEL);
> 
> I probably wouldn't have bothered with `kcalloc` for something that's
> always just one value and you're setting it. Why not just
> 
> input_fmts = kmalloc(sizeof(*input_fmts), GFP_KERNEL);
> 
> ...also MAX_INPUT_SEL_FORMATS isn't defined. I guess that's why you
> said it didn't compile?
> 
> Also: if it was common for others to want to provide fixed formats, I
> wonder about adding a helper function that did most of the work here?
> Dunno what it would be named since it's already a bit a of handful,
> but I'd expect to call it like:
> 
> static const u32 formats[] = { MEDIA_BUS_FMT_RGB888_1X24 };
> return my_neat_helper(formats, ARRAY_SIZE(formats), num_output_formats)
> 
> Then my_neat_helper() could do kmemdup() on the array passed and fill
> in "num_output_formats" to be either the array size of 0 (if the
> kmemdup failed).

I quite like that approach. We could even have a wrapper macro that adds
the ARRAY_SIZE() argument automatically.

> > +       if (!input_fmts)
> > +               return NULL;
> > +
> > +       /* This is the DSI-end bus format */
> > +       input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
> 
> I'm not an expert, but I'm curious. Can't DSI run in other formats?
> ...or maybe I'm misunderstanding what this is for. I guess I'm not
> sure how it relates to:
> 
> enum mipi_dsi_pixel_format {
>   MIPI_DSI_FMT_RGB888,
>   MIPI_DSI_FMT_RGB666,
>   MIPI_DSI_FMT_RGB666_PACKED,
>   MIPI_DSI_FMT_RGB565,
> };

-- 
Regards,

Laurent Pinchart


More information about the dri-devel mailing list