(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
* rename decode_* to get_*
* clean up get_* text when unknown connector/encoder
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42717 a95241bf-73f2-0310-859d-f6bbb57e9c96
(.c to keep compatibility with older C accelerants)
* use functions for decoding video_electronics
* thanks for the guidance Axel!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42668 a95241bf-73f2-0310-859d-f6bbb57e9c96
this seems like it could be useful for more then
just radeon_hd.
* idea from linux drm driver
* feedback / flames welcome
* can move into radeon_hd private defines if requested
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42662 a95241bf-73f2-0310-859d-f6bbb57e9c96
* malloc storage for mc state info
* redo pll range struct
* change to ATOM_ENCODER_MODE for connector info
* redo pll calculations to match AtomBIOS requirements
* some structure changes
* no longer init already posted AtomBIOS as it
causes an infinite loop of AtomBIOS calls
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42644 a95241bf-73f2-0310-859d-f6bbb57e9c96
* when TRACE_ATOM is enabled in bios.c, we dump
each accelerant instance of the AtomBIOS rom
to disk in /boot/common/cache/tmp/ (next to usb
hid descriptors in the same file name format)
* these images can be parsed with the AtomDis application
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42622 a95241bf-73f2-0310-859d-f6bbb57e9c96
* add igp property to pciid map
* add disabled bios pull for r700 and ni cards
* refactor model numbering as >R700 AMD switched
to named card families
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42596 a95241bf-73f2-0310-859d-f6bbb57e9c96
* add missing header for some radeon registers
* begin removing now un-needed direct register calls
* move and refactor crtc functions
* fix function naming to be clearer
* create more AtomBIOS style calls
* this will eat your cat at the moment, don't bother testing
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42582 a95241bf-73f2-0310-859d-f6bbb57e9c96
* implement various methods to pull AtomBIOS from card
* add some missing registers to headers from linux drm driver
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42553 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Point AtomBIOS to PCI rom mapped in memory
* Things no longer crash, but we get an Invalid BIOS Magic error
in the logs.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42543 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Pull pci_rom base address from pci subsystem
* Point AtomBIOS parser to pci rom address
to set up and malloc atom_context
* This is untested! Don't run on an
expensive card until I test it on a cheaper
one!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42541 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Add missing Idle call for connectors
* Reformulate blanking.. this should match what the
register is after the GTF vesa call
* Set FrameBuffer to card internal address
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42509 a95241bf-73f2-0310-859d-f6bbb57e9c96
into a usable function - this has some coding style issues I did not care to
fix.
* _AddBaseMode() now computes the mode in case it is not present in the list
yet.
* This should help with bug #7787.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42420 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Add crtControl global register
* Add grphUpdate storage
* Do some logical reordering of register writes
* Correct crt final power-on checks
* Enhance tracing
* Disable PLL, it is needed but seems to completely break
the modesetting resulting in black-screen-of-doom.
(fixing PLL set/calibration is now priority one)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42380 a95241bf-73f2-0310-859d-f6bbb57e9c96
* pass mapped frame buffer area id to accelerant
* remove my temporary hacked together frame buffer memory mapping
* completely rely on PCI BAR for now for aperture size / location instead of
R6XX_CONFIG_FB_BASE reg.
* Remove my temporary AllocateFB function.
* set grphPrimarySurfaceAddr to physical memory frame buffer location (offset 0)
* fix P/N sync setting.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41722 a95241bf-73f2-0310-859d-f6bbb57e9c96
* make shared memory info naming clearer.
* move frame buffer internal offset read to driver
* remove check of > 512MB as we really should always use frame_buffer_size
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41569 a95241bf-73f2-0310-859d-f6bbb57e9c96
* remove device_type and replace with device_chipset
* change MEMSIZE to >> 10 as r600-r700 store this in bytes (r800 uses MB and will be fixed soon)
* add if statement to select what register locations to use based on chipset
** Maybe use a struct or something to store these in a standardized way?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41525 a95241bf-73f2-0310-859d-f6bbb57e9c96
* add boot item support to radeon hd driver
* add edid storage to shared info
* add pull of active monitor VESA EDID to radeon hd driver (until AtomBios complete)
* EDID pulled in driver now passed to create_display_modes
* move registers to external stock xorg radeon hd register headers (lic. allows it)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41411 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
* whitespace cleanup and renamed log2() to radeon_log2 (conflicts with log2 in math.h)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39620 a95241bf-73f2-0310-859d-f6bbb57e9c96
few warnings. Thanks! I did not apply the hunks about moving
a logging function in the common accelerant code to be static.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39320 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
Supports Banshee, Voodoo3 and Voodoo5 chips.
It will be promoted as older tdfx replacement soon, but not until
my small changes around phys_addr_t are validated.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37241 a95241bf-73f2-0310-859d-f6bbb57e9c96
map_physical_memory()'s physicalAddress parameter type from void* to
phys_addr_t. This breaks source compatibility, but -- as long as
phys_{addr,size}_t remain 32 bit wide -- keeps binary compatibility with
BeOS.
* Adjusted all code using the affected interfaces (Oh what fun!). Added a few
TODOs in places where the wrong types (e.g. void* for physical addresses
are used). Looks like quite a few drivers aren't 64 bit safe and others
will break with PAE.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36960 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
device is not compatible, after all.
* No longer accept color changes if the mode is not an 8 bit one. I think that
BWindowScreen does that after changing the mode, so that is messes up the
colors, at least that's the theory, will test on real iron now.
* Use VGA as a fallback if setting the palette via VBE failed. This brings back
the colors for ParticlesII in Qemu (but not in VirtualBox, which seems to be
completely broken in this regard).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32359 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The vesa driver no longer uses VGA programming if the chip does not support
VGA compatibility.
* The VESA driver now tries to set the DAC to 8 bits per color gun.
* In VESA modes, the driver no longer tries to use VGA programming; introduced
the new vesa_set_indexed_colors() that is now used for palette programming.
This should fix wrong colors of 8 bit BWindowScreen users with VESA on real
hardware (emulators usually didn't mind either way).
* Note that the app_server needs to maintain a palette per 8 bit screen, as
right now, the colors are garbled after a workspace switch. Stefano, are you
looking into that already?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32347 a95241bf-73f2-0310-859d-f6bbb57e9c96
be broken in the app_server now, but I haven't checked yet.
* Fixed typo in vesa.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32141 a95241bf-73f2-0310-859d-f6bbb57e9c96
mode informations are available.
* This is passed to the graphics card when the mode is set in the hopes that it
will be more conforming.
* Not yet tested on real hardware, though, therefore the VESA driver doesn't
do anything like this yet. I will test next, but please report any problems
with this nonetheless.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28390 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The hardware cursor is now disabled at 640x480 with a Virge VX (before it
was just invisible).
* EDID info can now be read for all S3 chips.
* For the Savage IX, Savage MX, and SuperSavage chips the display is no
longer expanded to fill a laptop LCD display when the mode resolution is
less than the size of LCD display.
* Savage IX, Savage MX, and SuperSavage chips will now display mode
1400x1050 on a 1400x1050 laptop LCD display. Previously the display was
blank at that resolution.
* Previously about half the Savage chips would not draw properly at
1400x1050. That is, the image was badly skewed and unusable. All of
them now draw properly at 1400x1050.
* Some code was reorganized to remove unnecessary and redundant code.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27863 a95241bf-73f2-0310-859d-f6bbb57e9c96
be put into a boot_item in frame_buffer_console_init().
* The VESA driver now supports gettings the EDID information as well; this
is necessary now, since the app_server no longer takes over the mode the
boot loader had chosen.
* Note, we might want to do this via vm86 instead in the future, and remove
the kernel part again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25786 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use vm86 mode to call the VESA BIOS to do the actual mode switching by
providing an ioctl in the vesa driver.
* Fix vm86.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25680 a95241bf-73f2-0310-859d-f6bbb57e9c96
Gerald Zajac. Thanks a lot!
* Also put it on the image by default.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25583 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
* Removed "physical" parameter of GART's bind_aperture() - I don't think this
be of use to anyone.
* Fixed binding/unbinding pages in the Intel GART driver; I accidently shifted
the page offset twice.
* Actually forgot handling of allocated memory in Aperture::BindMemory().
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23796 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
* It now also serves as a generic GART manager and accepts bus modules as well
as custom modules of graphics drivers if they want to (could be used for the
Radeon PCI GART stuff, for example).
* Implemented GART support module for Intel i965 and G33 chipsets (the other
Intel chips will come later).
* Renamed agp bus manager to agp_gart to reflect its new functionality (even
though the AGP functionality is already outdated (due to PCIe), the GART
stuff remains current).
* Adapted existing users of the AGP bus manager to the API changes.
* Not very well tested yet...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23754 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
