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@xxxxxxxxxxxxxxxx>
---
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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
