Map the DMA buffers from the same linear address as the vertex bufs. If
dev->agp_buffer_token is not set, mach64 drm maps the DMA buffers from
linear address 0x0.
Initialize the spinlock unconditionally when struct drm_device is filled in,
and return early in drm_locked_tasklet() if the driver doesn't support IRQs.
It looks like 'after a while', I915REG_INT_IDENTITY_R for some reason always has
VSYNC_PIPEB_FLAG set in the interrupt handler, even though pipe B is disabled.
So we only increase dev->vbl_received if the corresponding bit is also set in
dev->vblank_pipe.
Initialize it to default value if it hasn't been set by the X server yet.
In i915_vblank_pipe_set(), only update dev_priv->vblank_pipe and call
i915_enable_interrupt() if the argument passed from userspace is valid to avoid
corrupting dev_priv->vblank_pipe on invalid arguments.
Handle relative as well as absolute target sequence numbers.
Return error if target sequence has already passed, so userspace can deal with
this situation as it sees fit.
On success, return the sequence number of the vertical blank when the buffer
swap is expected to take place.
Also add DRM_IOCTL_I915_VBLANK_SWAP definition for userspace code that may want
to use ioctl() instead of drmCommandWriteRead().
Actually make the existing ioctls for adding and removing drawables do
something useful, and add another ioctl for the X server to update drawable
information. The only kind of drawable information tracked so far is cliprects.
When the vertical blank interrupt is enabled for both pipes, pipe A is
considered primary and pipe B secondary. When it's only enabled for one pipe,
it's always considered primary for backwards compatibility.
This takes up two more ring buffer entries per rectangle blitted but makes sure
the blit is performed top to bottom, reducing the likelyhood of tearing.
First warning result from open-coded PTR_ERR,
the rest is caused by code like this:
*(u32 *) ((u32) buf_priv->kernel_virtual + used)
I've also fixed a missing PTR_ERR in i830_dma.c
From: Denis Vlasenko <vda.linux@googlemail.com>
Signed-off-by: Dave Airlie <airlied@linux.ie>
The overflows could cause valid offsets to get rejected under some
circumstances, e.g. when the framebuffer resides at the very end of the card's
address space.