On Thu, May 26, 2016 at 01:41:52AM +0000, Alexander von Gluck IV wrote:
Things start to go wrong with the PLL computation. The driver is looking
for 69.3MHz, but only manages to get 31.1429. This is way off the
target.
for reference, as reported by the syslog:
min: p 28 (p1 2 p2 14), n 1, m 79 (m1 12, m2 5)
max: p 112 (p1 8 p2 14), n 3, m 118 (m1 22, m2 9)
found: p = 112, n = 3, m = 109 (m1 = 18, m2 = 7)
I assume this should match with the PLL limits described in SNB volume 3
part 3, section 2.3. But, the limits for M does not seem to match: max M
value could be 127, not 118.
I got those updated values from the linux driver here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/intel_display.c#n426
I'm also not sure how the code computes 31.1429MHz with these settings.
The output frequency is f = (R * M) / ((N+2) * P) with R=100MHz.
With the found settings I only get 19.46MHz, which is even more wrong
than announced.
The limits for N also seem wrong, the datasheet says values 3-8 are
allowed and use (N+2) in the frequency math. I'm not sure if that means
the limits should be 3-8 or 5-10, but I don't see how it could end up
with 1-3.
IronLake and above use some modified frequency math based on intel's work
here:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/intel_display.c#n818
Then I get an error later on when trying to set the display mode:
"LVDS C didn't power on within 100ms!"
I guess this may be caused by the invalid N value preventing the PLL
from locking.
I always see that issue even on working hardware, so I wouldn't mind it for
now.
