| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This removes all the TTM userspace API and all userspace objects.
It also removes the drm_bo_lock.c code
|
|
This is an initial import of the atom bios parser with modesetting support
for r500 hw using atombios. It also includes a simple memory manager
layer that translates a radeon GEM style interface onto TTM internally.
So far this memory manager has only been used for pinned object allocation
for the DDX to test modesetting.
|
|
Conflicts:
linux-core/drmP.h
linux-core/drm_drv.c
linux-core/drm_stub.c
linux-core/i915_drv.c
linux-core/i915_gem.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
|
|
This allows device drivers to add proc files
|
|
Lots of conflicts, seems to load ok, but I'm sure some bugs snuck in.
Conflicts:
linux-core/drmP.h
linux-core/drm_lock.c
linux-core/i915_gem.c
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
|
|
Not quite portable, but these are useful for intel. Some more general
mechanism could be done...
|
|
We no longer need to use it to protect against shared ringbuffer access.
|
|
This is the create (may want location flags), pread/pwrite/mmap
(performance tuning hints), and set_domain (will 32 bits be enough for
everyone?) ioctls. Left in the generic set are just flink/open/close.
The 2D driver must be updated for this change, and API but not ABI is broken
for 3D. The driver version is bumped to mark this.
|
|
Use new GEM based ring buffer initialization. Still need to init GEM & use it
for framebuffer allocation etc.
Conflicts:
shared-core/i915_dma.c
shared-core/i915_drv.h
|
|
This requires that the X Server use the execbuf interface for buffer
submission, as it no longer has direct access to the ring. This is
therefore a flag day for the gem interface.
This also adds enter/leavevt ioctls for use by the X Server. These would
get stubbed out in a modesetting implementation, but are required while
in an environment where the device's state is only managed by the DRM while
X has the VT.
|
|
Passed the compile test; it's ready to ship.
Conflicts:
libdrm/Makefile.am
linux-core/Makefile.kernel
linux-core/drmP.h
linux-core/drm_memrange.c
linux-core/drm_stub.c
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
remove fb callbacks, just probe into the driver to sort it out
|
|
|
|
Move TTM code into the driver
|
|
This creates a default group attached to the legacy drm minor nodes.
It covers all the objects in the set. make set resources only return
objects for this set. Need to fix up other functions to only work on
objects in their allowed set.
|
|
Okay we have crtc, encoder and connectors.
No more outputs exposed beyond driver internals
I've broken intel tv connector stuff.
Really for TV we should have one TV connector, with a sub property for the
type of signal been driven over it
|
|
|
|
drm_crtc->fb may point to NULL, f.e X server will allocate a new fb
and assign it to the CRTC at startup, when X server exits, it will destroy
the allocated fb, making drm_crtc->fb points to NULL.
|
|
pread and pwrite must update the memory domains to ensure consistency with
the GPU. At some point, it should be possible to avoid clflush through this
path, but that isn't working for me.
|
|
Make the API names a bit more consistent.
|
|
|
|
Domain information is about buffer relationships, not buffer contents. That
means a relocation contains the domain information as it knows how the
source buffer references the target buffer.
This also adds the set_domain ioctl so that user space can move buffers to
the cpu domain.
|
|
|
|
I was wrong about how the data structure worked, and didn't care to fix it
to support debugging code.
|
|
This function submits a gem-based execbuffer to the ring.
It doesn't work yet.
|
|
Track named objects in /proc/dri/0/gem_names.
Track total object count in /proc/dri/0/gem_objects.
Initialize device gem data.
return -ENODEV for gem ioctls if the driver doesn't support gem.
Call unlock_page when unbinding from gtt.
Add numerous misssing calls to drm_gem_object_unreference.
|
|
Names are just another unique integer set (from another idr object).
Names are removed when the user refernces (handles) are all destroyed --
this required that handles for objects be counted separately from
internal kernel references (so that we can tell when the handles are all
gone).
|
|
Now that drm_gem_object has a drm_driver * in it, functions don't need both
parameters.
|
|
krefs are way easier than a custom-coded spinlock+int combo.
|
|
|
|
|
|
|
|
|
|
It's not really a graphics memory allocator, just something to track ranges
of address space. It doesn't involve actual allocation, and was consuming
some desired namespace.
|
|
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
|
|
This patch ties outputs, output properties and hotplug events into the
DRM core. Each output has a corresponding directory under the primary
DRM device (usually card0) containing dpms, edid, modes, and connection
status files.
New hotplug change events occur when outputs are added or hotplug events
are detected.
|
|
using contexts for this is bad for multiple masters
|
|
this may not survive long - just need something for testing
|
|
This is the correct fix for the RS690 and hopefully the dma coherent work.
For now we limit everybody to a 32-bit DMA mask but it is possible for
RS690 to use a 40-bit DMA mask for the GART table itself,
and the PCIE cards can use 40-bits for the table entries.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
modesetting-101
Conflicts:
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
|
|
Also adjust i915 irq handling as it follows the 16bit'ism's
of the i8xx series.
|
|
Conflicts:
linux-core/drmP.h
linux-core/drm_drv.c
linux-core/drm_proc.c
linux-core/drm_stub.c
linux-core/drm_sysfs.c
|
|
Rip out the whole head thing and replace it with an idr and drm_minor
structure.
|
|
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
|
|
|
|
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.
|
