Re: [PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux