| Age | Commit message (Collapse) | Author | 
 | 
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
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
This needs to be tested thoroughly before pushing to the
kernel.
 |