| Age | Commit message (Collapse) | Author |
|---|
|
Thanks to Nicolai Haehnle for pointing this out on IRC.
|
|
Thanks to the reworked vblank-rework, we can just use the hardware frame
counter directly, and make the RADEON_PARAM_VBLANK_CRTC getparam just return
what was set by the corresponding setparam.
|
|
All interrupt off vblank count updates are done in drm_vblank_get/put
now, so convert users of the vblank counter over to that interface.
|
|
|
|
|
|
Remove the unused (and broken) "in vblank" code now that the core has
been fixed to use a counter while interrupts are enabled. Also make the
vblank pipe get/set ioctls into dumb stub functions, since with the new
code we can no longer let userspace control whether vblank interrupts
are enabled, or the core code will misbehave.
|
|
modifications to make it work correctly on my test hardware (altered the
backlight write function, made it enable the legacy backlight controller
interrupts on mobile hardware, sorted the interrupt function so we don't
get an excessive number of vblank interrupts). This lets the backlight
keys on my T61 work properly, though there's a 750msec or so delay
between the request and the brightness actually changing - this sounds
awfully like the hardware spinning waiting for a status flag to become
ready, but as far as I can tell they're all set correctly. If anyone can
figure out what's wrong here, it'd be nice to know.
Some of the functions are still stubs and just tell the hardware that
the request was successful. These can be filled in as kernel modesetting
gets integrated. I think it's worth getting this in anyway, since it's
required for backlight control to work properly on some new platforms.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
|
|
|
Various chips have exciting interactions between the CPU and the GPU's
different ways of accessing interleaved memory, so we need some kernel
assistance in determining how it works.
Only fully tested on GM965 so far.
|
|
|
|
Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com>
|
|
When scheduled swaps occur, we need to blit between front & back buffers. I
the buffers are tiled, we need to set the appropriate XY_SRC_COPY tile bit,
only on 965 chips, since it will cause corruption on pre-965 (e.g. 945).
Bug reported by and fix tested by Tomas Janousek <tomi@nomi.cz>.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
We won't get a PFIFO context switch when the same channel ID is recreated if
the hw still thinks the channel is already active, which causes fun issues.
Should allow X to be stopped and started without tearing down the entire
card state in lastclose().
|
|
With the interrupt enable/disable using only the mask register, it was wrong
to use the enable register to detect which pipes had vblank detection
turned on. Also, as we keep a local copy of the mask register around, and
MSI machines smack the hardware during the interrupt handler, it is more
efficient and more correct to use the local copy.
|
|
This shares common code sequences for managing the interrupt register bits
|
|
It would be nice if one day the DRM driver was the canonical source for
register definitions and core macros. To that end, this patch cleans things up
quite a bit, removing redundant definitions (some with different names
referring to the same register) and generally tidying up the header file.
|
|
Clean up queues, free objects. On the next entervt, unmark the hardware to
let the user try again (presumably after resetting the chip). Someday we'll
automatically recover...
|
|
|
|
We depend on the VM fully now for memory protection, separate DMA objects
for VRAM and GART are unneccesary. However, until the next interface break
(soon) a client can't depend on the objects being the same and must still
call NV_OBJ_SET_DMA_* methods appropriately.
|
|
This avoids seeing garbage from engine setup etc before X gets around
to pointing the CRTCs at a new scanout buffer. Not actually a noticable
problem before G80 as PRAMIN is forced to the end of VRAM by the hardware
already.
|
|
See bug 14289
|
|
Noting that the interrupt mask register was more reliable than the interrupt
enable register for managing interrupts in user_irq_on/user_irq_off, this
patch replaces the remaining IER frobbing with IMR instead.
The test which exposes IER related failures is:
$ glxgears & glxgears & glxgears
(reposition the glxgears windows away from the upper left corner)
$ while :; do x11perf -rect100 -reps 800 -repeat 1; sleep 1; done &
$ while :; do runoa; runet; done &
|
|
Another patch adds this to a /proc/dri file for debugging and monitoring.
|
|
This adds gem_active, gem_flushing, gem_inactive, gem_request and gem_seqno
entries to monitor gem operation and help debug issues.
|
|
find_or_create_page doesn't quite set up pages correctly; any newly created
pages aren't hooked into the shmem object quite right; user space mmaps of
those pages end up mapping pages full of zeros which then get written to the
real pages inappropriately. This patch requires that the kernel export
shmem_getpage.
|
|
When a software fallback has completed, usermode must notify the kernel so
that any scanout buffers can be synchronized. This ioctl should be called
whenever a fallback completes to flush CPU and chipset caches.
|
|
|
|
Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com>
|
|
This fixes registration when MSI is set up after the stub function fills in
dev->irq. Otherwise /proc/interrupts would report attachment to the fasteoi
interrupt. dev->irq is still exposed (and updated at IRQ setup)
for the drivers that use it for whatever reason.
|
|
|
|
|
|
|
|
Record the last execbuffer sequence for each client.
Record that sequence in the throttle ioctl as the 'throttle sequence'.
Wait for the last throttle sequence in the throttle ioctl.
|
|
|
|
The interrupt identity register must be writen before any work occurs lest
we drop an interrupt on the floor. This patch just shuffles code around to
make sure that IIR is written as early as possible.
|
|
We want request retirement to occur about once a second when the request
queue is non-empty. This was done with a timer that queued a work_struct,
using a delayed_work instead makes a lot more sense.
|
|
In the short-circuit code for the breadcrumb already being new enough, we
need to update the sarea_priv copy of the breadcrumb just as if we had
waited. Otherwise userland error checking will notice that we returned
too early based on its wrong information, and call wait_irq again (leading
to spinning until someone else comes along and updates the sarea_priv).
This bug was hidden when we had interrupt masking disabled, such as in
master, since the interrupt handler would update sarea_priv.
|
|
This was insufficient once we started masking interrupts to only when someone
was waiting for them (and would thus retire requests themselves). It was
replaced by the retire_timer.
|
|
|
|
This patch should fixe hard lockup and convert them in
softlockup (ie you can ssh the box but the gpu is busted
and we are waiting in loop for it to come back to reason).
|
|
This fixes a regression from commit d434b64f6a760d85295e32298a9a1f3624ee1b69
which could cause us to fail to wake up for user interrupts if we lost a race.
|
|
|
|
According to the hw guys, you should use DSTCACHE_CTLSTAT to flush
the 2D dst cache rather than RB2D_DSTCACHE_CTLSTAT.
|
|
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.
|
|
|
|
GART setup appears to work the same as RS480 chips.
Also RC4xx chips are actually RS400 based, not RS480 based.
|
|
|
|
Reported by vehemens
|
