* They are all over the place.. I give up
* Going off of engineering names and DCE is more accurate
* A lot of this info came from the x.org wiki
* I'd like to transition some of the engineering
name checks to use DCE versions.. they tend to be more
accurate and exact. (in some cases we can't, but most of
the time we can)
* edid1_detailed_timing_raw was missing
a field which threw off the sync bits.
* The result was the monitor will receive
a different sync polarity than it requested.
Most monitors handle this, but it is still
a bug
* Remove non-generic radeon dp_get_lane_count
* Set lane count and link rate at set_display_mode
* Pass entire mode to pll_set vs only pixel clock for DP code
* Add helpers for DP config data to common code
* Obtain more correct link rate
* This puts the registers in a better state and ensures
all model dependant defines are prefixed with card series
* Consolidate evergreen defines into single header
* First steps at getting card command processor wired
up to the ring buffers.
* Code doesn't run yet as I have *no* idea what happens
when these rings are in an invalid state.
* General DisplayPort functions in common dp.cpp
* DP port information struct in common header
* Please don't use this private accelerant common DP
code just yet as it is very early.
* The AtomBIOS timeout fix has made my DP bridge
stop working
* The current DisplayPort code is a little lacking
on DP link training... I think thats the cause.
* This puts the first steps towards DP training
in place.
* I plan on trying to make some of this DP stuff
common accelerant stuff after it works.
* I'd rather this be common code, but I don't have access
to the DisplayPort specifications. If I added it as common
code I would want to be 100% it was complete and variables
were named properly.
* For now putting in radeon_hd private headers
* add temperature query support for Juniper, Sumo, Evergreen, and North Islands
* add missing thermal defines for evergreen cards
* northern island cards use the evergreen thermal calculations
* add a few missing/needed header defines
* show GPU temp in millidegrees C on r600/r700
* evergreen+ support soon
* function may be moved to driver long term once testing done
* add missing chipset ranges
* add a few more older (X1200) PCI ID's (mostly IGP)
* add code to detect and set frame buffer size on old chipsets
* we get to the connector detection currently and fail due to the
lack of legacy support on my X1200 IGP
* evergreen headers are split due to different
header copyrights
* detect and set up evergreen memory controler
* change the way we manage radeon chipsets to
more closely match drm driver as the chipset
model numbers aren't in order and change from
numbers to names.
* check for evergreen when populating frame buffer
information.
* style cleanup
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@43225 a95241bf-73f2-0310-859d-f6bbb57e9c96
There were a large number if incorrect, duplicated, misplaced
registers that were leading to bugs in the code. This is my first
shot at cleaning them up. Luckly as we are using AtomBIOS the number
of registers we need to know about is shrinking.
* remove registers left over from register banging days
* r770 is less then r710, r720 in the drm sources. Fix in code.
* enable newer radeons for testing
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42930 a95241bf-73f2-0310-859d-f6bbb57e9c96
* don't resize the frame buffer after mapping it.. doesn't make sense
* add memory controller code and program the memory controller for r600
* remove unneeded frame_buffer_int
* don't malloc mc_info, waste of time
* fix scaler setting
* vramStart in mc should be 0... get vertical colored lines however when this
this is set properly (everything in mc_info is the MC view of FB BAR)
When vramStart is the FB physical address... i get proper video on some cards
... thoughts?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42924 a95241bf-73f2-0310-859d-f6bbb57e9c96
* we can now utilize these chipset
flags throughout the driver to better id
cards and features
* remove leftover BIOS size define from intel skel
* no *real* functional change
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42904 a95241bf-73f2-0310-859d-f6bbb57e9c96
* add potential support for IGP chipsets
* igp code is *untested* and should work *in theory*
* potentially resolves#8040 / #8046 ?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42901 a95241bf-73f2-0310-859d-f6bbb57e9c96
* will fix other var names to match style guidelines
shortly
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42891 a95241bf-73f2-0310-859d-f6bbb57e9c96
base intel_extreme driver long ago
* no functional change
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42880 a95241bf-73f2-0310-859d-f6bbb57e9c96
* correct? color mode setting bug
* fix var naming to match style guidelines
* add a few missing register defines
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42879 a95241bf-73f2-0310-859d-f6bbb57e9c96
(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
* 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
