Electronic – Disabling DisplayPort hot plug detect

I am not an expert on displayport, but from taking a look at the standard, I think I get the gist of what they're trying to accomplish. The goal is to transfer the original stream clock over an asynchronous link by transferring information about the relationship between the original stream clock and the link clock over the link, instead of doing something like deriving the link clock from the stream clock. This information can later be used to regenerate the stream clock at the other end of the link. It also allows for multiple, indpependent stream clocks to be sent down the same link and regenerated. The information transferred is simply the ratio of the two frequencies as a fraction, M/N, either both constant (in a system where the stream clock and the link clock are synchronous) or M measured and time-varying and N constant. The thing to keep in mind is that even though the stream clock and link clock are asynchronous, their frequencies should be relatively stable and hence not drift very quickly with respect to each other, so the measured M value will change slowly. Since M is measured every so many clock cycles, a new value is only available periodically. The whole value is only sent once per frame, but the lower 8 bits are sent more often, which should be sufficient to track the slowly varying value. So long as it varies by less than, say, 128 or so increments between measurements, it is even possible to track variations that cross over to bit 8 (for example, say the last M value was 0x0023f2 and the new LSB is 0x10, the new M is probably 0x002410 as that represents a smaller step than 0x002310).

From your third point, and your talk about 'resets', I think maybe you're confused about how M is measured and what it represents. It is measured using two counters, one counting cycles of LS_Clk (link symbol clock) and one counting cycles of Strm_Clk (stream clock). When the LS_Clk counter overflows after 32768 LS_Clk cycles, the value of the Strm_Clk counter becomes the new M and the counter is reset back to zero. M does not change until the next time the LS_Clk counter overflows. So if the frequency of the link clock and the stream clock do not change with respect to each other, the counter driven by Strm_Clk will always end up at the same value and hence M will not change. If the frequencies drift, then M will change slightly to track the change. The values are then used to drive a PLL at the receiver to generate something very similar to the original stream clock by using LS_Clk as a reference and multiplying it by M/N. M does not continuously increment or decrement in any way, unless the stream clock frequency is slowly increasing or decreasing over time at a continuous rate.

HDMI has a 5V line that can just be connected to the HPD line (a resistor is never a bad idea, just for short protection, 1k or so should do), but you also need to provide EDID (Serial EEPROM with appropriate contents) powered from the 5V line and connected to the I2C lines (I cannot off the top of my head remember if you need to supply the I2C pullup or if this is done on the card).

Further some HDMI parts sense the termination of the clock pair, so you would want to terminate this pair in a manner appropriate to the CML drive).