[PATCH 1/2] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

Daniel Vetter daniel at ffwll.ch
Wed May 3 09:32:17 UTC 2017


On Wed, May 03, 2017 at 02:53:00PM +0530, Archit Taneja wrote:
> +panel/bridge reviewers.
> 
> This does make things much cleaner, but it seems a bit strange to create
> a drm_bridge when there isn't really a HW bridge in the display chain (i.e,
> when the DSI encoder is directly connected to a DSI panel).
> 
> There are kms drivers that use drm_panel, but don't have simple stub connectors
> that wrap around a drm_panel. They have more complicated connector ops, and
> may call drm_panel_prepare() and related functions a bit differently. We won't
> be able to use drm_panel_bridge for those drivers.
> 
> For msm, we check whether the DSI encoder is connected directly to a panel
> or an external bridge. If it's connected to an external bridge, we skip the
> creation of the stub connector, and rely on the external bridge driver to
> create the connector:
> 
> http://lxr.free-electrons.com/source/drivers/gpu/drm/msm/dsi/dsi.c#L227
> 
> The msm solution isn't very neat, but it avoids the need to create another
> bridge to glue things together.

Since I suggested this, yes I like it. And I think just unconditionally
creating the panel bridge is probably even simpler, after all bridges are
supposed to be chainable. I guess there's always going to be drivers where
we need special handling, but I'm kinda hoping that for most cases simply
plugging in a panel bridge is all that's need to glue drm_panel support
into a driver. The simple pipe helpers do support bridges, and part of the
goal there very much was to make it easy to glue in panel drivers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list