DRM/DRI Update

[Thomas White]

Hi all,

I thought I'd present a bit of an update about how things are progressing
with getting the direct rendering infrastructure working on our hardware.
Some people may have noticed a lot of activity in the drm-tracking branch of
the kernel.  This branch now has the following features:

- Handling of Glamo's command queue done at the kernel level, and access
	from userspace implemented via an ioctl.

- Glamo's VRAM managed in the kernel, with buffers being allocated from
	userspace via a GEM ioctl interface.

- A reorganised Glamo memory map.  MMC cursor and command queue buffers are
	hardcoded and fixed at compile time.  Everything left after taking out
	space for the visible framebuffer, MMC, cursor and cmdq is available
	for allocation as above.

- A few fixes for the MMC and other code to honour the new memory map.

- Minimal decoupling of DRM from PCI.

This all works.  I can draw rectangles on the screen using Glamo's 2D engine,
or render to an offscreen buffer before blitting to the screen.  This can be
done with a relatively simple program such as this:
http://git.bitwiz.org.uk/?p=glamo-dri-tests.git;a=blob;f=gdri-buf-cmdq.c

If you've been wanting to play with Glamo acceleration (2D, 3D, MPEG,
JPEG, ...), but have been put off by the thought of handling the command
queue and memory yourself, now might be a good time to jump in.

For the gory details, including instructions for compiling the userspace
parts you need to make this work, please read here:
http://www.bitwiz.org.uk/wizblog/dri-for-the-freerunner.html

Next, I'm going to be working on moving EXA into this framework so that we
can have accelerated X coexisting with "fun stuff".

Comments welcome, as ever.

Tom