403 Commits

Author	SHA1	Message	Date
Alan Cox	8c8f1c958a	gma500: introduce the GTT and MMU handling logic ... This fits alongside the GEM support to manage our resources on the card itself. It's not actually clear we need to configure the MMU at all. Further research is needed before removing it entirely. For now we suck it in (slightly abused) from the old semi-free driver. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>	2011-11-16 11:23:38 +00:00
Alan Cox	e32681d66d	gma500: GEM and GEM glue ... The driver uses GEM along with a couple of small bits of wrapping of its own. The only real oddity here is the support for using the 'stolen' memory rather than wasting several MB. We use a simple resource manager as we don't need to manage our space intensively at all as we only do 2D work. We also have a GTT which is entirely GPU facing so in the Cedarview case are not even allocating from host address space. Signed-off-by: Alan Cox <alan@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>	2011-11-16 11:22:36 +00:00
Alan Cox	3abcf41fb1	gma500: Move the basic driver out of staging ... This driver supports unaccelerated KMS display, and accelerated console handling on the Intel Poulsbo, Oaktrail, Cedarview and Medfield hardware. For the initial merge Medfield will be left out as it needs considerable further work to reach a decent standard Begin by adding the Makefiles and Kconfig. These are not yet plumbed into the DRM layer so will have no effect on their own Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>	2011-11-16 11:19:54 +00:00