[PATCH v2 2/9] drm/bridge: synopsys: dw-mipi-dsi: Add input bus format negotiation support

Ying Liu victor.liu at nxp.com
Sun Jul 30 20:38:52 PDT 2023


On Monday, July 31, 2023 2:44 AM Jagan Teki <jagan at amarulasolutions.com> wrote:
> 
> On Thu, Jul 20, 2023 at 12:40 PM Ying Liu <victor.liu at nxp.com> wrote:
> >
> > Introduce ->get_input_bus_fmts() callback to struct dw_mipi_dsi_plat_data
> > so that vendor drivers can implement specific methods to get input bus
> > formats for Synopsys DW MIPI DSI.
> >
> > While at it, implement a generic callback for -
> >atomic_get_input_bus_fmts(),
> > where we try to get the input bus formats through pdata-
> >get_input_bus_fmts()
> > first.  If it's unavailable, fall back to the only format -
> MEDIA_BUS_FMT_FIXED,
> > which matches the default behavior if ->atomic_get_input_bus_fmts() is
> not
> > implemented as ->atomic_get_input_bus_fmts()'s kerneldoc indicates.
> >
> > Signed-off-by: Liu Ying <victor.liu at nxp.com>
> > ---
> > v1->v2:
> > * No change.
> >
> >  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 30
> +++++++++++++++++++
> >  include/drm/bridge/dw_mipi_dsi.h              | 11 +++++++
> >  2 files changed, 41 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> > index 57eae0fdd970..8580b8a97fb1 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> > @@ -12,6 +12,7 @@
> >  #include <linux/component.h>
> >  #include <linux/debugfs.h>
> >  #include <linux/iopoll.h>
> > +#include <linux/media-bus-format.h>
> >  #include <linux/module.h>
> >  #include <linux/of_device.h>
> >  #include <linux/pm_runtime.h>
> > @@ -536,6 +537,34 @@ static const struct mipi_dsi_host_ops
> dw_mipi_dsi_host_ops = {
> >         .transfer = dw_mipi_dsi_host_transfer,
> >  };
> >
> > +static u32 *
> > +dw_mipi_dsi_bridge_atomic_get_input_bus_fmts(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)
> > +{
> > +       struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
> > +       const struct dw_mipi_dsi_plat_data *pdata = dsi->plat_data;
> > +       u32 *input_fmts;
> > +
> > +       if (pdata->get_input_bus_fmts)
> > +               return pdata->get_input_bus_fmts(pdata->priv_data,
> > +                                                bridge, bridge_state,
> > +                                                crtc_state, conn_state,
> > +                                                output_fmt, num_input_fmts);
> 
> Why do we need platform-controlled bus formats? The supported bridge
> formats are common across all platforms and it is specific to the list
> of formats supported by DW-MIPI DSI. isn't it?

Ideally, yes.  But, if we consider some SoC logics introduced due to
DW MIPI DSI integration(like the DISPLAY_MUX register in i.MX93
media blk-ctrl as a syscon), then pdata->get_input_bus_fmts is handy
to cover the logics. Meson's MIPI_DSI_TOP_CNTL register and stm's
DSI_WCFGR register are the similar cases for integration.  Rockchip
directly sets display controller's output bus format in ->atomic_check().

Granted those SoC logics can be a standalone DRM bridge as the previous
bridge of the DW MIPI DSI bridge.  However, the question is that are the
logics worth a separate DRM bridge driver, considering
pdata->get_input_bus_fmts is quite handy?

Implementing a separate DRM bridge driver for i.MX93 DISPLAY_MUX
to add two DRM bridges is a bit hard, because the single register controls
both external parallel display pixel format and DSI controller input pixel
format with different bit fields.  And, I've already sent a patch series[1]
to add a DRM bridge driver for the external parallel display pixel format
control.

[1] https://patchwork.freedesktop.org/series/113457/

Regards,
Liu Ying

> 
> Thanks,
> Jagan.


More information about the linux-arm-kernel mailing list