[haiku-development] Re: intel_extreme rework status

  • From: "Alexander von Gluck IV" <kallisti5@xxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 26 May 2016 14:09:39 +0000

May 26 2016 12:24 AM, "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx> wrote:

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_disp
ay.c#n426

It seems we are using ironlake clock limits, since that file doesn't
have the sandy bridge ones.

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_disp
ay.c#n818

The comment here uses exactly the same formula as the spec. The code
seems to be doing a bruteforce search for parameters, and our
implementation doesn't work.

That's the calculation code intel wrote... if you can do better feel free :-)

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.

Why have a log for an harmless problem then? (No, "Linux does it" is not
an acceptable answer).

Technically it could be a problem... I just have no idea about the scope of it 
and
haven't had the free time to dig into the logic there.

I'm a big fan of verbosity on new driver code... better to know than to not.

Linux does it is a perfectly acceptable answer. Unlike the awesome AMD driver 
developers
which will give you a good nudge of help writing a driver for Haiku... I've 
never
gotten any of the Intel international developers in irc to respond to any 
question,
no matter how trivial.  The only real-world guidence we have is the pile of 
Intel
technical manuals that are inconsistent between generations... and the Intel 
linux
kernel code.

Intel does major architecture redesigns every generation. It's difficult to herd
these cats into a single driver (which we've done somehow)

I've gotten comments from the Mesa/DRI developers that Intel's hardware 
engineering
model isn't really compatible with non-intel-developers working on driver code.

Look at the authors... any major work is normally done exclusively by Intel
engineers because only a few of the open source devs understand how subsets of
generations interact within their own project.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/gpu/drm/i915

I'm Not making excuses.. just trying to properly set expectations on what we're 
trying
to accomplish. The rewrite helps isolate code-paths for major generations which
should help us work on generations without impacting other generations. 
Pre-rewrite you
could pretty easily make a change for IronLake and break a i9xx card.

Instead of bitching about how a trace statement doesn't make sense, why not 
submit
patches?  I can't do all of the work myself. I'm not requesting a contract, i'm 
doing
this out of my love for Haiku.

 -- Alex

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 05-2016