| Age | Commit message (Collapse) | Author | 
|---|
|  | PCI- or high memory.
This is substantially more efficient than drm_bo_kmap,
since the mapping only lives on a single processor.
Unmapping is done use kunmap_atomic(). Flushes only a single tlb() entry.
Add a support utility int drm_bo_pfn_prot() that returns the
pfn and desired page protection for a given bo offset.
This is all intended for relocations in bound TTMS or vram.
Mapping-accessing-unmapping must be atomic, either using preempt_xx() macros
or a spinlock. | 
|  |  | 
|  | PCI- or high memory.
This is substantially more efficient than drm_bo_kmap,
since the mapping only lives on a single processor.
Unmapping is done use kunmap_atomic(). Flushes only a single tlb() entry.
Add a support utility int drm_bo_pfn_prot() that returns the
pfn and desired page protection for a given bo offset.
This is all intended for relocations in bound TTMS or vram.
Mapping-accessing-unmapping must be atomic, either using preempt_xx() macros
or a spinlock. | 
|  | This change adds a driver feature that for i915 is controlled by a module
parameter. You now need to do insmod i915.ko modeset=1 to enable it the
modesetting paths.
It also fixes up lots of X paths. I can run my new DDX driver on this code
with and without modesetting enabled | 
|  |  | 
|  | modesetting-101
Conflicts:
	shared-core/i915_dma.c | 
|  |  | 
|  |  | 
|  |  | 
|  | Allow mode to be set with fb_id set to -1, meaning set
the mode with the current fb (if we have one bound).
Allow intelfb to hook back up it's fb if modesetting
clears it (maybe temporary).
Move any crtc->fb related register changes to set_base
in intel_fb.
General intelfb cleanups. | 
|  |  | 
|  | Fixes resume from hibernate in some configurations. | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | modesetting-101 | 
|  |  | 
|  | modesetting-101
Conflicts:
	linux-core/drm_sysfs.c | 
|  | This fixes at least two problems:
* The vblank_disable_fn timer callback could get called after the DRM was
  de-initialized, e.g. on X server shutdown.
* Leak of vblank related resources when disabling and re-enabling the IRQ, e.g.
  on an X server reset. | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | fix i915 driver to use state for hibernate save avoidance.
Signed-off-by: Dave Airlie <airlied@redhat.com> | 
|  |  | 
|  | modesetting-101
Conflicts:
	linux-core/i915_fence.c
	linux-core/via_fence.c
	shared-core/i915_dma.c
	shared-core/i915_drv.h
	shared-core/i915_irq.c | 
|  | Failing to preserve the MI_ARB_STATE register was causing FIFO underruns on
the VGA output on my HP 2510p after resume. | 
|  | Ported from xf86-video-intel.  Still need to tie in TV modes somehow, though
preferably w/o using the properties mechanism. | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | Fixup the minor number allocation scheme to use an idr and move the control
nodes up higher. | 
|  | On many chipsets, the checks for DPLL enable or VGA mode will prevent the
pipeconf regs from being restored, which could result in a blank display or X
failing to come back after resume.  So restore them unconditionally along with
actually restoring pipe B's palette correctly. | 
|  | This reverts commit 7af1bb874d9b8b1b8760ad200cee587c41c23434. | 
|  | On resume, if the interrupt state isn't restored correctly, we may end
up with a flood of unexpected or ill-timed interrupts, which could cause
the kernel to disable the interrupt or vblank events to happen at the
wrong time.  So save/restore them properly. | 
|  | There were two problems with the existing callback code:  the vblank
enable callback happened multiple times per disable, making drivers more
complex than they had to be, and there was a race between the final
decrement of the vblank usage counter and the next enable call, which
could have resulted in a put->schedule disable->get->enable->disable
sequence, which would be bad.
So add a new vblank_enabled array to track vblank enable on per-pipe
basis, and add a lock to protect it along with the refcount +
enable/disable calls to fix the race. | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | since a breadcrumb may actually turn up before a corresponding fence object
has been placed on the fence ring. | 
|  |  | 
|  |  | 
|  | sequence number may actually turn up before the corresponding fence
object has been queued on the ring.
Fence drivers can use this member to determine whether a
sequence number must be re-reported. |