Am Sonntag, den 13.04.2014, 15:58 +0100 schrieb Russell King - ARM
Linux:
> On Fri, Apr 11, 2014 at 04:13:33PM +0200, Lucas Stach wrote:
> > Make sure that we probe for a display on detect regardless
> > of previous hotplug events. Don't handle connector
> > hotplug state ourselves, but let DRM do the right thing
> > for us. This brings our hotplug handling in line with
> > what other DRM drivers do.
> 
> Why should working setups have to pay the price for faulty setups when we
> can adequately detect the hotplug signal on iMX SoCs when it's correctly
> wired?
> 
> By "price" I mean - if we end up having to poll the connector, we end up
> calling the i2c functions, and the i2c functions on iMX use a fixed
> timeout of 100ms.  That means the context which runs the
> imx_hdmi_connector_detect() function is forced to sleep for 100ms.  If
> that's being run as part of a softirq (eg, via a work struct), that's
> bad news because that could be any thread in the system.
> 
> The "price" should only be paid by those implementations where the hotplug
> signal is not correctly wired.
> 
This change is not related to broken systems. It just uses the DRM
framework as intended. The detect() callback, which triggers the EDID
fetch will only be called by DRM when a hotplug event was received, or
if someone (e.g. kms_fb_helper, or userspace) explicitly requests to
poll the connector.

Not doing so is working around the DRM framework, not using it. So as
mentioned this change just brings us in line with what other DRM drivers
do to handle hotplug and connector detect.

Regards,
Lucas

-- 
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reply via email to