On Mon, Jun 09, 2014 at 10:44:14AM -0300, Fabio Estevam wrote: > Russell, > > On Fri, Jun 6, 2014 at 10:56 AM, Russell King > <rmk+kernel@xxxxxxxxxxxxxxxx> wrote: > > The initial state at boot is assumed to be disconnected, and we hope > > to receive an interrupt to update the status. Let's be more explicit > > about the current state - reading the PHY status register tells us > > the current level of the hotplug signal, which we can report back in > > the _detect() method. > > > > Signed-off-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxxx> > > I have applied this patch against 3.15 and I still have the following > issue on a mx6qsabresd: > > If I boot the kernel with the HDMI cable connected, no HDMI image > comes up. In order to get HDMI working I need to remove and then > reconnect the cable. > > Still haven't had a chance to debug this though. Please check the status in /sys/class/drm/card0-HDMI-A-1/status. This should report the current state of the hotplug detection. Remember that this code detects off the HPD signal - if the HPD signal has not been correctly wired up, this patch is not going to help (really it comes down to a hardware fault, which I'm not trying to solve with this patch.) What I'm trying to resolve with this patch is that the state detected on properly wired up systems corresponds with the real initial state of the interface at initialisation time. The problem with the current code is that we start off assuming that the interface is disconnected, and we rely on an interrupt arriving to change that state. If for whatever reason that interrupt does not arrive, then, even if the HPD signal is active, we continue believing that the interface is not connected. I seem to remember discussion in the past that the HPD signal is not wired up on SabreSD. Really, this needs to be a DT flag to indicate that the connectivity on the platform is not correct, and we should fallback to using RXSENSE detection and/or DDC polling (both of which are sub-standard and incorrect to the HDMI spec.) I'd suggest a standard HDMI interface property like: hotplug-detect = "hpd" | "rxsense" | "ddc" defaulting to the standard hpd method. As I've said in the past, my problem with just going with DDC polling for everything is that the connected HDMI sink is permitted to update the EDID EEPROM (when it does, it is required to lower and re-raise the HPD signal.) If we are polling DDC, we may hit the situation where the EDID EEPROM is mid-update and possibly end up with corrupted data (though there's a checksum to save us from this.) While I2C is multi-master, we're talking about consumer stuff here, and I bet I2C arbitration on the DDC bus is not something that is tested. I would not be surprised if the assumption is made that when HPD is lowered, the HDMI sink has exclusive access to the EEPROM and doesn't need to be concerned with arbitration. RXSENSE has the problem that it doesn't detect EDID updates (there's no requirement for a HDMI sink to make RXSENSE on a source go inactive across an EDID update.) So, I would much rather go by the spec, using the HPD signal on devices where that signal is correctly wired, and only fall back to other methods (which cause us to go against the standard) where the hardware is buggy. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
