dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Doug Anderson <dianders@chromium.org>
Cc: Rob Clark <robdclark@chromium.org>,
	Philip Chen <philipchen@chromium.org>,
	Jitao Shi <jitao.shi@mediatek.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Jonas Karlman <jonas@kwiboo.se>,
	Robert Foss <robert.foss@linaro.org>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Andrzej Hajda <a.hajda@samsung.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH v1 3/9] drm: add drm_atomic_helper_bridge_dsi_input_bus_fmt
Date: Tue, 8 Feb 2022 02:44:25 +0200	[thread overview]
Message-ID: <YgG86bskmyggAaEF@pendragon.ideasonboard.com> (raw)
In-Reply-To: <CAD=FV=U2MnR895FDw79ATQr0TCjQzAxiZbXVr7sL5hXxH3fz6g@mail.gmail.com>

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@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@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

  reply	other threads:[~2022-02-08  0:44 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-06 15:43 [PATCH v1 0/9] drm/bridge: ps8640 and ti-sn65dsi86 updates Sam Ravnborg
2022-02-06 15:43 ` [PATCH v1 1/9] drm/bridge: add DRM_BRIDGE_STATE_OPS macro Sam Ravnborg
2022-02-07 22:19   ` Doug Anderson
2022-02-08  0:30   ` Laurent Pinchart
2022-02-12 21:15     ` Sam Ravnborg
2022-02-06 15:43 ` [PATCH v1 2/9] drm: add drm specific media-bus-format header file Sam Ravnborg
2022-02-07 22:21   ` Doug Anderson
2022-02-08  0:40   ` Laurent Pinchart
2022-02-06 15:43 ` [PATCH v1 3/9] drm: add drm_atomic_helper_bridge_dsi_input_bus_fmt Sam Ravnborg
2022-02-07 22:32   ` Doug Anderson
2022-02-08  0:44     ` Laurent Pinchart [this message]
2022-02-08 19:06       ` Sam Ravnborg
2022-02-06 15:44 ` [PATCH v1 4/9] drm/bridge: ti-sn65dsi86: Use atomic variants of drm_bridge_funcs Sam Ravnborg
2022-02-07 22:33   ` Doug Anderson
2022-02-08  0:46   ` Laurent Pinchart
2022-02-06 15:44 ` [PATCH v1 5/9] drm/bridge: ti-sn65dsi86: Fetch bpc via drm_bridge_state Sam Ravnborg
2022-02-07 22:34   ` Doug Anderson
2022-02-08 19:08     ` Sam Ravnborg
2022-02-06 15:44 ` [PATCH v1 6/9] drm/bridge: ti-sn65dsi86: Add NO_CONNECTOR support Sam Ravnborg
2022-02-07 22:34   ` Doug Anderson
2022-02-08  1:01     ` Laurent Pinchart
2022-02-08 19:12     ` Sam Ravnborg
2022-03-09 16:52   ` Kieran Bingham
2022-02-06 15:44 ` [PATCH v1 7/9] drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs Sam Ravnborg
2022-02-06 15:44 ` [PATCH v1 8/9] drm/bridge: ps8640: plug atomic_get_input_bus_fmts Sam Ravnborg
2022-02-06 15:44 ` [PATCH v1 9/9] drm/bridge: Drop unused drm_bridge_chain functions Sam Ravnborg
2022-02-08  0:52   ` Laurent Pinchart
2022-02-06 19:09 ` [PATCH v1 0/9] drm/bridge: ps8640 and ti-sn65dsi86 updates Sam Ravnborg
2022-06-22 10:07   ` Kieran Bingham
2022-06-22 16:45     ` Sam Ravnborg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YgG86bskmyggAaEF@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=enric.balletbo@collabora.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=jitao.shi@mediatek.com \
    --cc=jonas@kwiboo.se \
    --cc=narmstrong@baylibre.com \
    --cc=philipchen@chromium.org \
    --cc=robdclark@chromium.org \
    --cc=robert.foss@linaro.org \
    --cc=sam@ravnborg.org \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox