Caused drm_update_vblank_count() not to do its thing when called from
drm_modeset_ctl() -> drm_vblank_get().
The vblank functionality no longer needs to be suspended during a modeset, so
rename the field to vblank_inmodeset.
The current code uses the hw vblank counter exclusively, which can lead
to wakeups during the active period rather than during the vblank period
if the hw counter counts displayed frames rather than vblank periods.
This change coverts the code over to using the counter while interrupts
are enabled, fixing that issue. It also includes a couple of related
changes: one to not enable the new enable/disable behavior until the
modeset ioctl is called (to preserve old client behavior) and another to
account for lost events due to mode setting with the new counter scheme.
BSD will require similar changes to its drm_irq.c code, but they should
be straightforward.
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.
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.
Without kernel modesetting, this requires cooperation of the userspace
modesetting driver. We may have to leave the vblank interrupt enabled otherwise
to avoid problems.
Only compensate when the driver counter actually appears to have moved
backwards.
The compensation deltas need to be incremental instead of absolute; drop the
vblank_offset field and just use atomic_sub().
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.
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.
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).
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.
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>
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.
This header file is shared across linux and bsd, but is not installed
for user space to access. It's the place to put prototypes and data
types that aren't platform or chipset specific, but still internal to
the drm.
Conflicts:
linux-core/drmP.h
linux-core/drm_drv.c
linux-core/drm_irq.c
shared-core/i915_drv.h
shared-core/i915_irq.c
shared-core/mga_drv.h
shared-core/mga_irq.c
shared-core/radeon_drv.h
shared-core/radeon_irq.c
Merge in the latest master bits and update the remaining drivers (except
mach64 which math_b is working on). Also remove the 9xx hack from the i915
driver; it seems to be correct.
Make DRM devices use real Linux devices instead of class devices, which are
going away. While we're at it, clean up some of the interfaces to take
struct drm_device * or struct device * and use the global drm_class where
needed instead of passing it around.
We now always create a drm_ref_object for user objects and this is then the only
things that holds a reference to the user object. This way unreference on will
destroy the user object when the last drm_ref_object goes way.
1. DRM_NOUVEAU_GPUOBJ_FREE
Used to free GPU objects. The obvious usage case is for Gr objects,
but notifiers can also be destroyed in the same way.
GPU objects gain a destructor method and private data fields with
this change, so other specialised cases (like notifiers) can be
implemented on top of gpuobjs.
2. DRM_NOUVEAU_CHANNEL_FREE
3. DRM_NOUVEAU_CARD_INIT
Ideally we'd do init during module load, but this isn't currently
possible. Doing init during firstopen() is bad as X has a love of
opening/closing the DRM many times during startup. Once the
modesetting-101 branch is merged this can go away.
IRQs are enabled in nouveau_card_init() now, rather than having the
X server call drmCtlInstHandler(). We'll need this for when we give
the kernel module its own channel.
4. DRM_NOUVEAU_GETPARAM
Add CHIPSET_ID value, which will return the chipset id derived
from NV_PMC_BOOT_0.
4. Use list_* in a few places, rather than home-brewed stuff.