| Age | Commit message (Collapse) | Author | 
|---|
|  | No solid idea about what these 2 bits do, but nv50 can now survive a few
PGRAPH exceptions just as nv40 does :) | 
|  |  | 
|  | This is possibly temporary.  I can trigger an unending IRQ storm on G8x
in some circumstances, and have no idea how to handle that particular PFIFO
exception correctly yet. | 
|  | Doesn't fix any issue I've seen, but is a potential issue if a FIFO IRQ
occurs during channel creation/takedown. | 
|  | The IRQ handling stuff really is a mess.. On the TODO :) | 
|  |  | 
|  | I swore I'd actually do this properly and not go the horrible route
we did with nv4x, but I won't get around to it just yet with so many
*actually* interesting things to do first.. One day.
Since someone already added nv86, why not! | 
|  | Turns out it's important to save/restore AR14 in particular. | 
|  |  | 
|  | Conflicts:
	linux-core/Makefile.kernel
	linux-core/drm_compat.c
	linux-core/drm_fops.c
	linux-core/drm_lock.c
	shared-core/drm.h
	shared-core/i915_dma.c
	shared-core/i915_drv.h
	shared-core/i915_irq.c | 
|  | Make both crtc and the command argument 32 bits to avoid any 32-on-64 compat
issues. | 
|  | Enum can be of pretty much any size since C leaves the choice of size up to the implementation.  So avoid using it in new interfaces like the vblank pre- & post-modeset ioctl.  Thanks to hch for spotting this. | 
|  | Remove lock functions and use pci_map_rom() instead of pci_map_rom_copy(). | 
|  |  | 
|  | Since it'll be freed at unload time, we should alloc devname rather than
pointing to the DRIVER_NAME string. | 
|  | On my 865G machine, it seems the CPU will receive interrupt before
irq_postinstall is called. This will cause kernel oops because vblank is not
inited at that time. Clear interrupt status before install seems fixing this
problem.
Signed-off-by: Hong Liu <hong.liu@intel.com> | 
|  | From Jesse and Zhenyu originally. | 
|  | The vblank tasklet update code must build 2D blt commands with the
appropriate tiled flags. | 
|  | The batchbuffer submission paths were fixed to use the 965-specific command,
but the vblank tasklet was not. When the older version is sent, the 965 will
lock up. | 
|  | Ported from Xorg intel 2d driver. Changed interfaces definitions, which needed
to be changed later if other device wants to use these DVO stuff. | 
|  |  | 
|  | into modesetting-101 | 
|  |  | 
|  | Doesn't yet work on my i915 test machine, but most of the necessary bits
should be there. | 
|  | into modesetting-101 | 
|  | If the driver is 'modeset' enabled, it'll register it's interrupt
handler at load time.  Set the devname in this case so that
/proc/interrupts makes sense. | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | dude kernel moduless use kernel errors :)
this fixes an oops on init when this codepath hits. | 
|  |  | 
|  |  | 
|  | - Note that this may not work for all nv86. | 
|  |  | 
|  | This interface was defined completely wrong, however userspace has only
ever used 4 values from it (0x1, 0x2, 0x3 and 0x6), so fix the interface to do what userspace actually expected but define new defines for new users to use
it properly. | 
|  | Previously, the R300_CMD_WAIT command would write the passed directly to the
hardware. However this is incorrect because the R300_WAIT_* values used are
internal interface values that do not map directly to the hardware.
The new function I have added translates the R300_WAIT_* values into appropriate
values for the hardware before writing the register.
Thanks to John Bridgman for pointing this out. :-) | 
|  |  | 
|  | The wait functions depend on PTIMER, so write the old (incorrect, but working) values for uninitialised hw | 
|  | Kernel bug 10289. | 
|  |  | 
|  |  | 
|  | More or less a workaround for issues on some chipsets where a context
switch results in critical data in PRAMIN being overwritten by the GPU.
The correct fix is known, but may take some time before it's a feasible
option. | 
|  | Limit frag address to 8 bits | 
|  | into modesetting-101 | 
|  |  | 
|  |  |