[haiku-development] Re: intel_extreme rework status
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 26 May 2016 14:30:00 +0000
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 :-)
I could try Linux on my machine to make sure, but I'm pretty sure their driver
will work fine and with correct PLL settings. It must be a problem somewhere in
our version, then.
I sent my conclusions late at night yesterday, I will continue investigating
today if I can spare some more time. But in any case, there clearly is
something wrong with the way we compute the PLL limits. Finding something with
an error above 50% is not the expected outcome. Less than 1% would be ok, and I
think the Intel code in Linux does better than that (and our version did work,
too, in the old driver).
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.
The manuals are quite complete and usually accurate. The information is all
there and I don't feel much need to dig into Linux code. There is the
additional concern that Linux is GPL, and the closer we get to their driver,
the closer we are to a GPL violation since our code is MIT.
Intel does major architecture redesigns every generation. It's difficult to
herd
these cats into a single driver (which we've done somehow)
From my experience, there are not this much change in the PLL computation and
in the mode setting part. We are used to gathering widely different hardware in
a single driver, we do it even for completely unrelated things from different
vendors (usb_serial comes to mind).
A clean C++ architecture with all parts separated helps, but sometimes also get
in the way because hardware is picky and things need to be done in the right
order.
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.
I'm not questionning that, it is a move in the right direction. I think it was
still a bit early to merge it. At least it forces me to dig into it and fix
some issues...
I'm not sure the PLL problems stem from just refactoring the code. We had
something that worked well before, I'll see if I can dig out the old PLL
computation code and plug it into the new architecture, or just use the new
code and try to fix it. Didn't have time to look into this in much details, yet.
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.
I'm a bit annoyed at having to work on this at non-native resolution. All my
computers run Haiku, and all use intel hardware. I used to have a working
driver and now I don't, so I'm going the grumpy way. Patches will come,
eventually.
--
Adrien.
Other related posts:
