* I really hope we can kill head_mode some day
* Break pll code out from mode code
* The LVDS and Digital are smooshed together and
likely need broken apart.
* No impact to non-ValleyView chipsets
* Bump some register locations for VLV
* Only have HDMI port to test with on my ValleyView GPU
and our driver seems to be missing all HDMI and
sideband functionality.
* As ValleyView chipsets seem to be UEFI only, we don't
have VESA fallback, so this shouldn't cause regressions.
(unless we get UEFI framebuffer support)
Intel changed the PCH interrupt bits between Sandy Bridge and Ivy Bridge
to make space for the 3rd display pipe. Take this into account and check
for the correct bits on the newer devices.
Fixes#11522.
https://github.com/druga/haiku-stuff/tree/master/intel_extreme
Rebased against current sources.
* The BIOS video mode sometimes reports a scaled mode instead of the
physical panel dimensions. Get the data from the VBT table as well, and
use it if the reported resolution is bigger.
* On first boot, force the panel native mode so the user doesn't have to
set it manually.
* Only allow a single head at a time on i855gm, as the card can't drive
both heads at the same time.
* Detect when a new requested mode is the same as the current one, and
skip modesetting in that case. Avoids screen flickering when changing
workspaces.
* Fix some cases of misdetecting which pipes to enable
(they are actually reversed), so introduce a find_reg() inline function to map
such regs individually instead. Should fix interrupt storms on SandyBridge.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42870 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Also add the definitions and some specifics for IronLake (ILK), but keep the
IDs disabled as at least the one version I can test with doesn't work yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42869 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Make the pointer style consistent accross all components, which should make it
easier when working all over the place.
* 80 char limits.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42863 a95241bf-73f2-0310-859d-f6bbb57e9c96
control block. Doesn't matter on (G)MCH (they are the same register block tehre)
but fixes mode setting on PCH again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42862 a95241bf-73f2-0310-859d-f6bbb57e9c96
register blocks and we encode their block into the register definition. On
register access these blocks are then translated into the final address.
* Set up the register blocks for (G)MCH and PCH variants.
* Remove most SandyBridge code that was actually PCH specific and is now taken
care of automatically.
* This will temporarily break SandyBridge support again until the right
transcoders are actually programmed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42857 a95241bf-73f2-0310-859d-f6bbb57e9c96
(the one in my new ThinkPad X1). The PLL is still off a bit so it has a few
blurry stripes, but EDID and mode setting basically works.
* Starting with IronLake the north/south bridge or (G)MCH/ICH setup was moved
into a platform control hub (PCH) which means that many registers previously
located in the GMCH are now in the PCH and have a new address.
* I'm committing this mostly because this way the additions are more easy to
follow. It is a bit messy and I'll clean it up more and possibly make it a
bit more generic. Also most of these changes actually apply to IronLake and up
and aren't SandyBridge specific, so a few of those additions will still get a
broader scope and new chips will be added.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42839 a95241bf-73f2-0310-859d-f6bbb57e9c96
* add a INTEL_TYPE_915M type to be used by 0x2592 (mobile version)
* 0x2e32 is actually non mobile, added its brothers 0x2e02, 0x2e12, 0x2e22, 0x2e42, 0x2e92
* 0x27a2 is actually mobile.
* added 0x2972, 0x2982, 0x2992 for INTEL_TYPE_965 type, and 0x2a12 for INTEL_TYPE_965M.
* added corresponding entries in intel_gart.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40838 a95241bf-73f2-0310-859d-f6bbb57e9c96
This allows to use lower resolution screen modes with black border.
Added a set of TODOs :
* The smaller scren is not centered, but aligned top-left
* The base resolution used is the one reported from edid 1.1, because I'm still not sure how to parse EDID 1.2. This resolution is too small on my laptop, but it works.
Also added two ways of setting 8-to-6 dithering for 18-bit LVDS panel. No visible result for me, unfortunately.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38354 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added header for dealing with binary numbers and bitmasks (C++ templates)
these "macro's" might not work well for long words, though
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33749 a95241bf-73f2-0310-859d-f6bbb57e9c96
I've now removed that code, and factored out a retrieve_current_mode()
function that can work on head A and B.
* This fixes Adrien's flickering problem on his laptop - I can't find the
bug ticket, though. Hopefully it does not break other laptop chips. Testing
would be welcome, as I don't have any other machine here.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33633 a95241bf-73f2-0310-859d-f6bbb57e9c96
we now always only use the primary ring buffer.
* Removed secondary ring buffer allocation and member fields.
* Increased size of the primary ring buffer to 65536 bytes.
* The bytes per row register is computed differently for 9xx chips.
* On G33, the overlay does not need a physical address anymore, so we
don't pass B_APERTURE_NEED_PHYSICAL to the allocation anymore for that
device.
* intel_free_memory() accidently added the aperture base to the allocation
and would therefore never free any memory.
* INTEL_RING_BUFFER_SIZE_MASK was shifted one bit to the right, didn't
cause any harm with our buffer sizes, yet, though.
* With these changes, the driver runs stable on a G33 chipset (I have not
yet tested the hardware cursor, though, it might need some work, too).
The only known issue left is that overlay flickers a bit if its buffer
is partially backed up by reserved and allocated memory.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23798 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Now uses the AGP GART module for memory management. This greatly simplifies
the memory handling, and memory is now actually allocated on demand,
instead of a fixed size (stolen memory is not freed, though).
* The Intel GART module should now also work with older chipsets.
* No longer remove the GTT size from the stolen memory; this appears to have
been a mistake in the X driver. Not sure about the BIOS popup yet.
* The AGP module (in combination with the Intel GART module) is now mandatory
to use the Intel driver.
* Removed now superfluous settings (like memory size). Only enabling/disabling
the hardware cursor is still supported.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23781 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added some defines needed when playing with the bridge controller.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23753 a95241bf-73f2-0310-859d-f6bbb57e9c96
* set_gtt_entry() used the wrong index to fill the GTT - this could have never
worked correctly when you specified more memory than the amount of stolen
memory.
* Implementing maintaining resources for emulating overlay using the 3D engine
on i965. I don't yet commit the actual overlay code, as that is a) ugly, and
b) does not work yet.
* Moved AreaKeeper into its own header.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23709 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Implemented mapping the GTT area for i9xx chips other than the i965. This should also fix the
driver working with these chips at all.
* The memory used by the driver now take the GTT area into account - before the GTT could be
overwritten theoretically...
* Added fix for some i965 quirks from the X driver.
* Added some overlay definitions for the i965.
* Started support for G33 overlay (not complete yet).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23220 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Implemented MakeSpace() (not yet tested).
* Changed intel_wait_engine_idle() to spin() between reads and to timeout
after 1 second of waiting (could probably be done way earlier).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23120 a95241bf-73f2-0310-859d-f6bbb57e9c96
acceleration works fine, but overlay doesn't - that's next on my list.
Turns out the i965 differentiates between RGB-32 and RGB-32-alpha, and
didn't like trying to use the latter as display mode (the i865 didn't
care at all)... finding that took me *way* too long, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22780 a95241bf-73f2-0310-859d-f6bbb57e9c96
will happen on earlier i9xx chips for now...). Not yet tested.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22589 a95241bf-73f2-0310-859d-f6bbb57e9c96
not take the VCO limits into account; both could (and would during testing) create invalid
frequencies.
* Also reverted the order in which the PLL divisors are traversed to match the order of what
is used in the X driver to create comparable output (our error computation is based on float,
though, and should therefore create more accurate values).
* The i965 introduced a special register for the surface; the former display base register
is now only used for the view offset. Instead of setting the base manually here and there,
there is now a set_frame_buffer_base() function.
* The DPMS code will now also turn off/on the PLL clock generator.
* The code needs some more cleanup, and while the driver now produces the correct timing on
my i965 system, I'm now greeted by a black screen after startup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22289 a95241bf-73f2-0310-859d-f6bbb57e9c96
nothing is done with the data yet (besides dumping them to the serial output).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22272 a95241bf-73f2-0310-859d-f6bbb57e9c96
