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

[Laurent Pinchart]

Hi Tomi,

On Thu, Dec 19, 2019 at 11:21:03AM +0200, Tomi Valkeinen wrote:
> 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.

No disagreement as long as we can use drm_bridge :-)

> > +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?

Not much anymore it seems.

> 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?).

I'll drop the lock, it's not needed. The core should serialize calls to
the bridge, at least per output. For different outputs, there's a
possibility I believe of atomic commits being handled concurrently if
they don't share any resource.

-- 
Regards,

Laurent Pinchart