On Sat, Aug 8, 2015 at 1:04 PM, Russell King <rmk+kernel@xxxxxxxxxxxxxxxx> wrote: > HDMI sinks are permitted to de-assert and re-assert the HPD signal to > indicate that their EDID has been updated, which may not involve a > change of video information. > > An example of where such a situation can arise is when an AV receiver > is connected between the source and the display device. Events which > can cause the HPD to be deasserted include: > > * turning on or switching to standby the AV receiver. > * turning on or switching to standby the display device. > > Each of these can change the entire EDID data, or just a part of the > EDID data - it's up to the connected HDMI sink to do what they desire > here. For example > > - with the AV receiver and display device both in standby, a source > connected to the AV receiver may provide its own EDID to the source. > - turning on the display device causes the display device's EDID to be > made available in an unmodified form to the source. > - subsequently turning on the AV receiver then provides a modified > version of the display device's EDID. > > Moreover, HPD doesn't tell us whether something is actually listening > on the HDMI TDMS signals. The phy gives us a set of RXSENSE indications > which tell us whether there is a sink connected to the TMDS signals. > > Currently, we use the HPD signal to enable or disable the HDMI block, > which is questionable when HPD is used in this manner. Using the > RXSENSE would be more appropriate, but there is some bad behaviour > which needs to be coped with. The iMX6 implementation lets the TMDS > signals float when the phy is "powered down", which cause spurious > interrupts. Rather than just using RXSENSE, use RXSENSE and HPD > becoming both active to signal the presence of a device, but loss > of RXSENSE to indicate that the device has been unplugged. > > The side effect of this change is that a sink deasserting the HPD > signal to cause a re-read of the EDID data will not cause the bridge > to immediately disable the video signal. > > Signed-off-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxxx> Reviewed-by: Fabio Estevam <fabio.estevam@xxxxxxxxxxxxx> _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
