[PATCH v3 45/50] drm/omap: dpi: Register a drm_bridge

[Tomi Valkeinen]

On 11/12/2019 00:57, Laurent Pinchart wrote:
> In order to integrate with a chain of drm_bridge, the internal DPI
> output has to expose its operations through the drm_bridge API.
> Register a bridge at initialisation time to do so and remove the
> omap_dss_device operations that are now unused.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> ---
> Changes since v2:
> 
> - Unregister bridge if port initialisation fails
> ---
>   drivers/gpu/drm/omapdrm/dss/dpi.c | 197 ++++++++++++++++++------------
>   1 file changed, 119 insertions(+), 78 deletions(-)

I don't think DPI is really a bridge, as it's really just direct output from the DISPC (level 
shifted). But that probably doesn't matter, and bridge is a good way to manage the DPI output.

> +static void dpi_bridge_mode_set(struct drm_bridge *bridge,
> +				 const struct drm_display_mode *mode,
> +				 const struct drm_display_mode *adjusted_mode)
> +{
> +	struct dpi_data *dpi = drm_bridge_to_dpi(bridge);
> +
> +	mutex_lock(&dpi->lock);
> +	dpi->pixelclock = adjusted_mode->clock * 1000;
> +	mutex_unlock(&dpi->lock);
> +}

What's the lock protecting? Why do we lock here, but not e.g. in mode_fixup?

Do we ever get drm_bridge_funcs calls from multiple threads at the same time? Is there a difference 
between having a single DPI output, or multiple DPI outputs (i.e. can two different DPI outputs get 
calls simultaneously?).

  Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki