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

[Daniel Vetter]

On Thu, Dec 01, 2016 at 08:07:29AM +0100, Andrzej Hajda wrote:
> On 30.11.2016 14:09, Daniel Vetter wrote:
> > 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?
> 
> Real use case is that we need to always load hdmi path drivers at phone
> startup just in case somebody will use it.
> This way we are wasting space and more importantly boot time, for code
> which won't be used by 99% users of phones.
> Putting them into modules an loading on MHL/HDMI cable plug-in would be
> more optimal, I guess.

Do we have numbers for this? What part of the overhead is the edid probing
and reading, which we probably should optimize either way ... optimize as
in make sure we never ever stall anything for edid reads.

And if you never load the hdmi driver, how do you know when to load it
because the user plugged in the cable?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch