[PATCH] drm/drm_bridge: adjust bridge module's refcount

Daniel Vetter daniel at ffwll.ch
Wed Nov 30 13:09:15 UTC 2016


On Wed, Nov 30, 2016 at 01:03:20PM +0200, Laurent Pinchart wrote:
> On Wednesday 30 Nov 2016 11:55:20 Daniel Vetter wrote:
> > Why exactly do you want to hotplug encoders? Or bridges fwiw ... since at
> > least only making those hotpluggable will make the uabi story easier since
> > they're not exposed.
> 
> Ideally to avoid disabling the whole display engine when one encoder isn't 
> available/operational. Right now we're waiting for all pieces to be available 
> (using deferred probing or the component framework) before registering the DRM 
> device. This means that if one bridge can't be probed successfully for any 
> reason we'll end up having not display at all. This includes the case where 
> the driver for the bridge is not available. If we could support dynamic 
> hotplug of bridges, we could start with a display engine that supports a 
> subset of the outputs, and add new outputs as they become operational.
> 
> We have a similar issue when unbinding bridge devices from their driver. They 
> obviously can't be used anymore, but we have no solution to handle that apart 
> from unregistering the DRM device completely, as otherwise rebinding the 
> bridge to the driver later can't be handled.

This all sounds pretty cool, but does anyone care? Like what's the
real-world use-case here? Some cosmic ray destroyed the bridge driver on
your android phone and now you want it to magically fall back to hdmi that
no one ever plugs in? Or someone misconfigures their kernel and gets
greeted with a black screen, instead of a ... black screen?

I don't even think project ARA would qualify, since I expect a pluggable
screen to show up as a device on the greybus thing, so would get it's own
drm_device and screen sharing is done through prime.

So yeah I'm a bit sarcastic, but imo this is just one item in a massive
list of fairly-theoretical things which are broken in drm and which we
might want to fix when we're all retired and bored. I'm not yet planning
for that ;-) In case you need more:
- Handle drm_device lifetimes and hot-unplug correctly. Actually somewhat
  relevant because udl.
- Add proper locking for connector_list. Atm we have none.
- Fix up the debugfs lifetime disaster.
- Fix up the prime exported buffer lifetime disaster.
- Fix up the dma_fence lifetime disaster.
- ...

Those are all fundamentally broken things which need design-level changes
throughout the subsystem. And in theory you can even hit them, if you try
hard enough unplugging udl constantly. Encoder hotplug isn't even on my
list here ... because there's a _lot_ more broken with driver unbind even
without making bridges and encoders suddenly hot-add capable.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list