In particular don't destroy static mutexes, it upsets things
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 leaking an io mapping and also referencing stuff directly that
should not be directly accessed. Sort it out
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 can stuff things like the number of pipes and the SGX offset away in
here as well and clean up more conditional code.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Split the 2d properties, name, and various function vectors out so that we
can get rid of more conditional gloop in favour of a per device structure.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We need to initialise the DBI interface and the code for it got missed in
the original merge as it's in a daft place. This will need moving but lets
get it added first.
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>
We also pull out the undo side of the mmap offset processing so we can later
push it into GEM where it belongs
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Eliminate unused stuff and clean up the code ordering.
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>
Tidy up the 2D bits. For the fill case the CPU seems to be able to
outperform the graphics engine for the cases we get, so don't bother
fixing it but throw it out.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We can now make our system frame buffer a GEM object.
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>
We are using the underlying kref in the GEM object so we don't need our own
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Lose all the PSB debug gunge. We can replace it with dev_dbg() like normal
drivers if and when we need debug on stuff.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We have a FIXME to do the power management for which the framework now
exists, and we also need to deal with an erratum. Some operations exactly 8
pixels wide or high fail. The work around is to do two smaller ones (see
the Intel released X driver bits) but for console quite frankly if it's
8bits wide and/or high its not worth it so fall back.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Give the driver its own proper DRM name, clean up copyright headers and so
forth
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If we get a user frame buffer destroyed which is being displayed then clean
up the mess nicely. We can now run a slightly modified modetest including setting
modes, and handling crashes.
Modetest still blows up but this is because libdrm 2.4.25 is busted.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Restructure this to work the same way as the i915 frame buffer does. That
cleans up various chunks of code.
We can now set a mode in modetest but mode restore is a bit iffy
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We need this for the framebuffer in order to ensure that the kernel
framebuffer layer can handle it when using KMS. Except for the base
framebuffer this isn't a concern.
Add an npage field to the gtt as too many copies of the page calculation
are getting spread around the code.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The return variable of psb_gtt_pin() may be used
uninitialized. Also fixed some coding style issues.
Signed-off-by: Andre Bartke <andre.bartke@gmail.com>
[Reapplied by hand due to other changes]
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Squash a hardcoded assumption we shouldn't really make
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Clean up the GTT code a bit, make the pages uncached and go via the proper
interfaces. This avoids any aliasing problems.
On the CPU side we need to access the pages via their true addresses not via
the GTT. This is fine for GEM created fb objects for X. For the kernel fb
when not in stolen RAM we are going to need to use vm_map_ram() and hope we
have enough virtual address space to steal.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Many Linux distributions would enable vesafb in order to display
early stage boot splash. In this case, we will get garbled X
Window screen if running X fbdev on psbfb.
This is because fb0 is occupied by vesafb while psbfb is on fb1.
They tried to drive the same pieces of hardware at the same
time. With unmodified X start-up, it would try to use default
fb0 framebuffer device and unfortunately it is now broken
becaues fb1 supersedes it.
We should let psbfb takeover framebuffer control from vesafb
to get around this problem.
See also commit : 4410f39109
Signed-off-by: Michael Chang <mchang@novell.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On the Fit-PC2 the VBT reports an invalid fixed panel mode for LVDS, this gets
in the way for SDVO. This patch makes VBT parsing skip the invalid mode. When
there is no LVDS output the backlight support crashes so the patch also checks
for this before enabling it.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
GEM wants to mmap the object through the GTT (which avoids aliasing) so we
need to put the object into the GTT before we provide the fault mapping for
it.
While we are at it update the pin interface so that it digs dev out of the
GEM object itself. This provides a rather cleaner API and call environment.
Fix th refcount/on-off confusion in the pin API.
At this point we get a bit further with modetest but if we write to the
new GEM mapping we hang solid and as yet I don't know why.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The initial GMA500 framebuffer is not GEM but stolen memory. We can't
therefore take a GEM handle of it. Stop anyone trying to do this and causing
a crash.
Ideally we need a way to have GEM handles to non GEM objects but it's not
clear how and if GEM and the modesetting/fb interfaces it provides are
supposed to or indeed if they can handle it.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Support mapping of GEM objects. This ought to be a small plumbing change but
instead we have to cut and paste a pile of stuff into the driver. This
really wants to be handled *IN* GEM
You can now allocate, mmap and munmap GEM objects in the driver. You can't
yet map them into the GART or display them however.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The error path from gtt_alloc returns NULL not a ptr error. The underlying
fail is caused by a bug in the size calculation. With these two fixed it
passes kmstest, although it's not really doing anything useful yet.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
