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