mach-msm: misc fixes/hacks needed for drm driver

Get rid of some hacky assignment of clocks to wrong/bogus devices, fix
some compile errors when disabling ION/PMEM, etc..
drm/gem: add drm_gem_create_mmap_offset_size()

Variant of drm_gem_create_mmap_offset() which doesn't make the
assumption that virtual size and physical size (obj->size) are the same.
This is needed in omapdrm to deal with tiled buffers.  And lets us get
rid of a duplicated and slightly modified version of
drm_gem_create_mmap_offset() in omapdrm.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/gem: add shmem get/put page helpers

Basically just extracting some code duplicated in gma500, omapdrm, udl,
and upcoming msm driver.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/gma500: use gem get/put page helpers

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/udl: use gem get/put page helpers

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/omap: kill omap_gem_helpers.c

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm: add flip-work helper

A small helper to queue up work to do, from workqueue context, after a
flip.  Typically useful to defer unreffing buffers that may be read by
the display controller until vblank.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/tilcdc: use flip-work helper

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/omap: use flip-work helper

And simplify how we hold a ref+pin to what is being scanned out by using
fb refcnt'ing.  The previous logic pre-dated fb refcnt, and as a result
was less straightforward than it could have been.  By holding a ref to
the fb, we don't have to care about how many plane's there are and
holding a ref to each color plane's bo.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm: const'ify ioctls table

Because, there is no reason for it not to be const.

Signed-off-by: Rob Clark <robdclark@gmail.com>

Conflicts:
	drivers/gpu/host1x/drm/drm.c
	drivers/staging/imx-drm/imx-drm-core.c
iommu: adjust api to match upstream

Conflicts:
	drivers/gpu/msm/kgsl_iommu.c
drm/msm: add register definitions

Generated from rnndb files in:

https://github.com/freedreno/envytools

Keep this split out as a separate commit to make it easier to review the
actual driver.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: basic KMS driver for snapdragon

The snapdragon chips have multiple different display controllers,
depending on which chip variant/version.  (As far as I can tell, current
devices have either MDP3 or MDP4, and upcoming devices have MDSS.)  And
then external to the display controller are HDMI, DSI, etc. blocks which
may be shared across devices which have different display controller
blocks.

To more easily add support for different display controller blocks, the
display controller specific bits are split out into a "kms" module,
which provides the kms plane/crtc/encoder objects.

The external HDMI, DSI, etc. blocks are part encoder, and part connector
currently.  But I think I will pull in the drm_bridge patches from
chromeos tree, and split them into a bridge+connector, with the
registers that need to be set in modeset handled by the bridge.  This
would remove the 'msm_connector' base class.  But some things need to be
double checked to make sure I could get the correct ON/OFF sequencing..

This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
(part of MDP4 block), and hdmi.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: add register definitions for gpu

Generated from rnndb files in:

https://github.com/freedreno/envytools

Keep this split out as a separate commit to make it easier to review the
actual driver.

Signed-off-by: Rob Clark <robdclark@gmail.com>
drm/msm: add a3xx gpu support

Add initial support for a3xx 3d core.

So far, with hardware that I've seen to date, we can have:
 + zero, one, or two z180 2d cores
 + a3xx or a2xx 3d core, which share a common CP (the firmware
   for the CP seems to implement some different PM4 packet types
   but the basics of cmdstream submission are the same)

Which means that the eventual complete "class" hierarchy, once
support for all past and present hw is in place, becomes:
 + msm_gpu
   + adreno_gpu
     + a3xx_gpu
     + a2xx_gpu
   + z180_gpu

This commit splits out the parts that will eventually be common
between a2xx/a3xx into adreno_gpu, and the parts that are even
common to z180 into msm_gpu.

Note that there is no cmdstream validation required.  All memory access
from the GPU is via IOMMU/MMU.  So as long as you don't map silly things
to the GPU, there isn't much damage that the GPU can do.

Signed-off-by: Rob Clark <robdclark@gmail.com>
WIP: drm/msm: add rd logging debugfs

To ease debugging, add debugfs file which can be cat/tail'd to log
submits, along with fence #.  If GPU hangs, you can look at 'gpu'
debugfs file to find last completed fence and current register state,
and compare with logged rd file to narrow down the DRAW_INDX which
triggered the GPU hang.
WIP: drm/msm: add perf logging debugfs
misc build fixes
WIP: drm/msm: seems mvs regulator is optional.. not present on mako..
drm: Add drm_bridge

This patch adds the notion of a drm_bridge. A bridge is a chained
device which hangs off an encoder. The drm driver using the bridge
should provide the association between encoder and bridge. Once a
bridge is associated with an encoder, it will participate in mode
set, dpms, and optionally connection detection.

Since a connector may not be able to determine the connection state
downstream of the bridge, bridges may implement detect() which will take
precedence over connector detect() if the bridge is already attached
to an encoder and that encoder is already attached to the connector.
In practical terms, this requires the drm driver to make these
associations at init time, which is fine for SoC applications where
this link is static.

Signed-off-by: Sean Paul <seanpaul@chromium.org>