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

[Andrzej Hajda]

On 01.12.2016 16:12, Daniel Vetter wrote:
> On Thu, Dec 01, 2016 at 02:22:18PM +0100, Andrzej Hajda wrote:
>> On 01.12.2016 08:18, Daniel Vetter wrote:
>>> 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?
>> For number of HDMI/MHL users in mobiles, I have no stats :)
>> For display boot delay due to deferring hdmi driver is 2.5-3.5 seconds
>> on peach-pi board for example [1].
> That sounds horrible. We load our entire driver in that time, and it has 3
> hdmi ports. What exactly is that thing doing for 3 seconds?! Until we know
> what's going on I'm not sure it's just a driver that has a dead-slow init
> function ...

As I wrote it is due to deferring probe of hdmi driver. It has nothing
to do with device initialization.

>
>> [1]:
>> https://storage.kernelci.org/ulfh/v4.9-rc7-120-g38cdf7e0bfee/arm-exynos_defconfig/lab-baylibre-seattle/boot-exynos5800-peach-pi.html
>>
>>
>>>  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.
>> As EDID probing should be performed only after detecting sink it seems
>> irrelevant here.
>>
>>> And if you never load the hdmi driver, how do you know when to load it
>>> because the user plugged in the cable?
>> Mobiles often have detection which cable is plugged in. However I am not
>> sure if kernel sends such events to userspace,
>> but this should be simple to do.
> Well, to do that (at least with drm) you need the driver loaded, or at
> least the stuff it supports registered.
> -Daniel

Fortunately, in case of mobiles, cable detection is usually done outside
of DRM
via extcon driver.

Regards
Andrzej