On Mon, Apr 14, 2014 at 12:24:45PM +0200, Lucas Stach wrote: > Am Montag, den 14.04.2014, 11:09 +0100 schrieb Russell King - ARM Linux: > > Now *you* please go back and read what you said about kms/userspace being > > able to poll the connector, thereby causing an EDID read attempt while > > HPD may not be active. > > > Yes, userspace may trigger an explicit detect because it might suspect > that a sink is present while it has not received any HP event. What > userspace expects to happen in this situation is an explicit poll of the > connector regardless of the HP status. So, if you issue this poll, and the sink has lowered the HPD signal because it wants to update the EDID EEPROM, and is in the middle of doing so. Meanwhile you start an I2C transaction in the DDC bus. Maybe you win the arbitration, maybe you gain access because you manage to get your transaction in while the sink is between two I2C transactions. The result is you can end up reading inconsistent EDID data from the sink. There is no race free way to do this - HPD is the indication on HDMI that the sink is available, and that the EDID can be read by the source. If HPD is not active, then the EDID should *not* be read. > If you then just report the connector as disconnected because you didn't > receive a HP event before, you break the use-case for which userspace is > calling an explicit detect in the first place. What is wrong is that we store the interrupt-generated cached state, rather than reporting the actual HPD signal state when the "detect" method is used. We need to be reporting the real live state of the HPD signal in that function - or, in the case where HPD has not been correctly wired, your fallback of the RXSENSE bits. HPD *is* the signal which says "the HDMI sink is *properly* connected and the EDID data is available for you to read" when it is asserted. When HPD is not asserted, the HDMI sink is saying that the EDID data is not available. -- 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
