We really don't want this all done by ifdeffery - and this isn't any need
as it's fairly easy to sort out.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This differs enough from the Cedarview HDMI sufficiently to want to keep
them separated.
We need to sort out the power management for Oaktrail/Moorestown in order
to plumb this lot into the register handling logic.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
A lot of the intel_display stuff is duplicated, but we will add it first,
clean it up and then investigate the best way to merge stuff.
This first block integrates the various basic chunks of the CDV display setup.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This again is similar to upstream so give it a sensible name ready to look
at any merging or synchronization
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Move this over. In actual fact there are some underlying differences as
some devices have more MMU contexts, but for our 2D purposes we don't
actually care.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We've now sorted them out so they can go into the generic code. In actual
fact only the non MID devices use the functions but they are small and
having the name match i915 is going to help any future merging type work.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is generic for the PC class devices and also very similar to the i915
intel_bios.c so rename it. That way the commonality will be obvious and we
can look at merging them one day, or at least synching them up.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We don't want to carry all the extra gunk around on every device so use the
splitting work so far to tidy this up. Poulsbo is still mandatory as it is
used in bits by the other drivers and not neatly modularised.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The framebuffer code is now clean of device specific code, and passes
checkpatch. Move it to its new name
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Shuffle the naming so this reflects better and we can try and build some
sort of ordering to the naming scheme.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We really want to move towards a completely abstracted interface rather
than having tons of per chip junk in the same files.
Begin with the power code which is probably the worst offender. Add a set
of methods, initialise a dev_priv->ops pointer and rip the chip specifics
out of the power code. While we are it pick up the display init bits.
So we know it's now chip specifics clean remove the psb_ naming from it.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is too big already so lets rip out more of the device specific crud. It
also means we pull the ugly stuff that needs work out of our main line of
cleanup.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This large patch adds all the basics for Medfield support. Lots of clean up
needed in this area still.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add this temporarily so we can keep making progress and also bundle all the
GEM bits we need together in our staging driver while we get them into GEM
itself.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There are two chunks of code we need to do this. The first one is the code
to insert and remove the pages from the GART, the second is the code to build
page table lists from the GEM object. Surprisingly this latter one doesn't seem
to have a nice GEM helper.
While we are at it we can begin dismantling the semi redundant struct pg,
and finish pruning out the old now unused gtt code as well as the last bits
of helper glue from the old driver base.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This puts in place the infrastructure for GEM allocators. Our implementation
is fairly simplistic at this point and we don't deal with things like
evicting objects from the GART to make space, nor compaction.
We extent our gtt_range struct to include a GEM object and that allows GEM
to do all the handle management and most of the memory mapping work for us.
This patch also doesn't load GEM pages into the GART so the GEM side isn't
very useful. Before we can do that a fair bit of work is needed reworking the
internal GTT code.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We are not using TTM, we are not going to use TTM either
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Build the new files now all the changes they need are present. They won't
yet be used but the plumbing is next step.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is taken from Richard Purdie's previous attempt to rip the heart out
of the PVR driver and stake it.
Accelerate copies and fills.
[Revised patch which disables the methods until we can finish debugging them]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is an initial staging driver for the GMA500. It's been stripped out
of the PVR drivers and crunched together from various bits of code and
different kernels.
Currently it's unaccelerated but still pretty snappy even compositing with
the frame buffer X server.
Lots of work is needed to rework the ttm and bo interfaces from being
ripped out and then 2D acceleration wants putting back for framebuffer and
somehow eventually via DRM.
There is no support for the parts without open source userspace (video
accelerators, 3D) as per kernel policy.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan Cox