drm backport from drm-next a3483353c

Sync to commit:

commit a3483353ca4e6dbeef2ed62ebed01af109b5b27a
Author:     David Herrmann <dh.herrmann@gmail.com>
AuthorDate: Wed Nov 13 11:42:26 2013 +0100
Commit:     Dave Airlie <airlied@gmail.com>
CommitDate: Fri Nov 15 20:49:02 2013 +1000

    drm: check for !kdev in drm_unplug_minor()

Signed-off-by: Rob Clark <robdclark@gmail.com>
fb: make fp_get_options name argument const

drm_get_connector_name now returns a const value, which causes the following
compilation warning:

  drivers/gpu/drm/drm_fb_helper.c: In function ‘drm_fb_helper_parse_command_line’:
  drivers/gpu/drm/drm_fb_helper.c:127:3: warning: passing argument 1 of ‘fb_get_options’ discards ‘const’ qualifier from pointer target type [enabled by default]
  In file included from drivers/gpu/drm/drm_fb_helper.c:35:0:
  include/linux/fb.h:627:12: note: expected ‘char *’ but argument is of type ‘const char *’

As fb_get_options uses its name argument as read only, make it const. This
fixes the aforementioned compilation warning.

Signed-off-by: Vincent Stehlé <vincent.stehle@freescale.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: trivial@kernel.org
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
lockdep: Check if nested lock is actually held

It is considered good form to lock the lock you claim to be nested in.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>

[ removed nest_lock arg to print_lock_nested_lock_not_held in favour
  of hlock->nest_lock, also renamed the lock arg to hlock since its
  a held_lock type ]
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/5051A9E7.5040501@canonical.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
drm backport from v3.14-rc1

Sync to commit:

commit 38dbfb59d1175ef458d006556061adeaa8751b72
Author:     Linus Torvalds <torvalds@linux-foundation.org>
AuthorDate: Sun Feb 2 16:42:13 2014 -0800
Commit:     Linus Torvalds <torvalds@linux-foundation.org>
CommitDate: Sun Feb 2 16:42:13 2014 -0800

    Linus 3.14-rc1
drm/msm: call drm_put_dev directly in ->remove

The drvdata pointer is already assigned to something useful.

Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm/msm: COMPILE_TEST support

With a simple stub, we can get COMPILE_TEST support.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: add missing MODULE_FIRMWARE()s

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: fix bus scaling

This got a bit broken with original patches when re-arranging things to
move dependencies on mach-msm inside #ifndef OF.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: add support for non-IOMMU systems

Add a VRAM carveout that is used for systems which do not have an IOMMU.

The VRAM carveout uses CMA.  The arch code must setup a CMA pool for the
device (preferrably in highmem.. a 256m-512m VRAM pool in lowmem is not
cool).  The user can configure the VRAM pool size using msm.vram module
param.

Technically, the abstraction of IOMMU behind msm_mmu is not strictly
needed, but it simplifies the GEM code a bit, and will be useful later
when I add support for a2xx devices with GPUMMU, so I decided to keep
this part.

It appears to be possible to configure the GPU to restrict access to
addresses within the VRAM pool, but this is not done yet.  So for now
the GPU will refuse to load if there is no sort of mmu.  Once address
based limits are supported and tested to confirm that we aren't giving
the GPU access to arbitrary memory, this restriction can be lifted

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: add support for msm8060ab/bstem

This adds the necessary configuration for the APQ8060A SoC (dual-core
krait + a320 gpu) as found on the bstem board.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: move mdp4 -> mdp/mdp4

There are some little bits and pieces that mdp4 and mdp5 can share, so
move things around so that we can have both in a common parent
directory.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: resync generated headers

resync to latest envytools db, add mdp5 registers

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: mdp4_format -> mdp_format

This can be shared between mdp4 and mdp5.  Both use the same set of
parameters to describe the format to the hw.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: split out msm_kms.h

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: move irq utils to mdp_kms

We'll want basically the same thing for mdp5, so refactor it out so it
can be shared.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: add hdmi support for apq8x74/mdp5

The HDMI block is basically the same between older SoC's with mdp4
display controller, and newer ones with mdp5.

So mostly this consists of better abstracting out the different sets of
regulators, clks, etc.  In particular, for regulators and clks we can
split it up by what is needed for hot plug detect to work, and what is
needed to light up the display.

Also, 8x74 has a new phy.. a very simple one, but split out into a
different mmio space.  And with mdp5, the irq is shared with mdp, so we
don't directly register our own irq handler.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: add mdp5/apq8x74

Add support for the new MDP5 display controller block.  The mapping
between parts of the display controller and KMS is:

  plane   -> PIPE{RGBn,VIGn}             \
  crtc    -> LM (layer mixer)            |-> MDP "device"
  encoder -> INTF                        /
  connector -> HDMI/DSI/eDP/etc          --> other device(s)

Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc.  (Ie. the
register interface is same, just different bases.)

Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.

And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: add a330/apq8x74

Add support for adreno 330.  Not too much different, just a few
differences in initial configuration plus setting OCMEM base.
Userspace support is already in upstream mesa.

Note that the existing DT code is simply using the bindings from
downstream android kernel, to simplify porting of this driver to
existing devices.  These do not constitute any committed/stable
DT ABI.  The addition of proper DT bindings will be a subsequent
patch, at which point (as best as possible) I will try to support
either upstream bindings or what is found in downstream android
kernel, so that existing device DT files can be used.

Signed-off-by: Rob Clark <robdclark@gmail.com>
DOWNSTREAM: drm/msm: use faster downstream iommu APIs

mapping/unmapping by range means less TLB invalidate overhead, which is
good for a few fps in xonotic, for example.
WIP: drm/msm: hacks to build for 8x74