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 ... > [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 -- 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
