Electronic – Does DisplayPort support scaling natively

Displayport 1.1 and 1.2 both provide for a 3.3V power pin. Standard Displayport Cables for 1.2 do not wire the pin, but there are cables that do. Regardless of the wiring, if the PIN is present, you can hack the cable:

DP_PWR 3.3V+/-10% / 500mA max, available both on upstream/downstream device connectors

Mainly intended for powering cable adaptors

Standard DisplayPort cable does not have wire connected on DP_PWR pin

Cut the HDP from the downstream device (Monitor), and wire a typical pull-up resistor (4.7k ~ 60k, try experimenting) between the upstream DP_Pwr pin and the upstream HDP pin will work. Of course, this does break some features, as the HDP pin is also used as a signal from the downstream device to the upstream device:

Asserted by a downstream device when it is ready for AUX transaction

HPD line also used for an IRQ assertion by a downstream device

Info gathered from http://www.vesa.org/wp-content/uploads/2010/12/DisplayPort-DevCon-Presentation-DP-1.2-Dec-2010-rev-2b.pdf

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.