In my last push I forgot to convert users of drm_update_vblank_count
over to drm_vblank_get/put, since that's where any interrupt off->on
update accounting is done now. Since the modeset ioctl did something
similar (an open coded update of the counter) convert it over to using
get/put too, which saves us from having to deal with every combination
of interrupt off & on between calls.
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.
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>
One of our systems has been returning 0xffffffff from all MCHBAR reads, which
means we'll need to figure out why, or add an alternate detection method.
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.
- There is one fb, used for as many outputs as possible.
- Eventually smaller screens will be scaled to see the full console, but for the moment this'll do.
When scheduled swaps occur, we need to blit between front & back buffers. If
the buffers are tiled, we need to set the appropriate XY_SRC_COPY tile bit, but
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>
On 9xx chips, bus mastering needs to be enabled at resume time for much of the
chip to function. With this patch, vblank interrupts will work as expected
on resume, along with other chip functions. Fixes kernel bugzilla #10844.
Signed-off-by: Jie Luo <clotho67@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
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...
While waiting for the hardware to idle on leavevt or lastclose, poll
for the sync sequence number instead of waiting for an interrupt. This
allows the code to bail if the hardware hangs for some reason. Also, this
avoids issues with signals as the exisiting wait function is interruptible.
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.
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
Normally when X is running, panic messages will be invisible and the machine
will just appear to hard hang. This patch adds support for switching back to
the fbcon framebuffer on panic (through the use of a panic notifier
registration) so we can see what happened.
Note that in order to be really useful, X will have to run its VT in something
other than KD_GRAPHICS mode. Also, not all kernel errors result in panics,
some go through BUG() which may trigger another type of event, not resulting in
a switch.
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.
In leavevt_ioctl, queue an MI_FLUSH and then block waiting for it to
complete. This will empty the active and flushing lists. That leaves only
the inactive list to evict.
Pin/unpin need to know whether to remove/add objects from the inactive list,
inactive objects cannot be in any GPU write domain as those would be on the
flushing list instead. However, inactive objects may be in the CPU write
domain.
Now that gem_object_unbind waits for rendering to complete, objects should
not be active when they are being pulled from the GTT. BUG_ON if this is
broken.