On Fri, Aug 9, 2013 at 9:19 AM, Sean Paul <seanpaul@xxxxxxxxxxxx> wrote: > On Thu, Aug 8, 2013 at 8:36 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: >> On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul <seanpaul@xxxxxxxxxxxx> wrote: >>> This patch adds the notion of a drm_bridge. A bridge is a chained >>> device which hangs off an encoder. The drm driver using the bridge >>> should provide the association between encoder and bridge. Once a >>> bridge is associated with an encoder, it will participate in mode >>> set, dpms, and optionally connection detection. >>> >>> Since a connector may not be able to determine the connection state >>> downstream of the bridge, bridges may implement detect() which will take >>> precedence over connector detect() if the bridge is already attached >>> to an encoder and that encoder is already attached to the connector. >>> In practical terms, this requires the drm driver to make these >>> associations at init time, which is fine for SoC applications where >>> this link is static. >>> >>> Signed-off-by: Sean Paul <seanpaul@xxxxxxxxxxxx> >> >> A few comments below. I think overall any such infrastructure simply >> needs to demonstrate viability on a few drivers, that makes it much >> simpler to check whether the interfaces make sense. > > Thanks for your feedback, Daniel. > > As mentioned by Stephane and Rob, there are a few drivers already > using this. In the ChromeOS tree, we have 2 simple DP->LVDS bridges > which quite frankly aren't terribly interesting atm, and we'll be > converting an HDMI->myDP bridge in a couple of weeks (time permitting, > of course). radeon also uses DP->LVDS and DP->VGA bridges on a number of systems. It currently uses a driver specific hack, but it could probably be converted to use the bridge infrastructure. Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
