This was hidden in a generic void * dev->mm_private. But only ever
used for gem. But thanks to this fake generic pretension no one
noticed that Rob's drm drivers are now all broken.

So just give the offset manager a type pointer and fix up msm, omapdrm
and tilcdc.

v2: Fixup compile fail.

v3: Fixup rebase fail that David spotted.

Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Anyway, nothing big here, Three more code cleanup patches from Rashika
Kheria, and one TTM/vmwgfx patch from me that tightens security around TTM
objects enough for them to opened using prime objects from render nodes:

Previously any client could access a shared buffer using the "name", also
without actually opening it. Now a reference is required, and for render nodes
such a reference is intended to only be obtainable using a prime fd.

vmwgfx-next 2014-01-13 pull request

* tag 'vmwgfx-next-2014-01-13' of git://people.freedesktop.org/~thomash/linux:
  drivers: gpu: Mark functions as static in vmwgfx_fence.c
  drivers: gpu: Mark functions as static in vmwgfx_buffer.c
  drivers: gpu: Mark functions as static in vmwgfx_kms.c
  drm/ttm: ttm object security fixes for render nodes

Some code cleanup by Rashika Keria,
VM stuff for ttm:
-Use PFNMAP instead of MIXEDMAP where possible for performance
-Refuse to fault imported pages, an initial step to support dma-bufs
better from within TTM.
-Correctly set page mapping and -index members. These are needed in various
places in the vm subsystem that we are not using yet, but plan to use soonish:
For example unmap-mapping-range keeping COW pages, and dirty tracking
fbdefio style, but also for PCI memory.

ttm-next 2013-01-14 pull request

* tag 'ttm-next-2014-01-13' of git://people.freedesktop.org/~thomash/linux:
  drivers: gpu: Remove unused function in ttm_lock.c
  drivers: gpu: Mark function as static in ttm_bo_util.c
  drivers: gpu: Mark function as static in ttm_bo.c
  drm/ttm: Correctly set page mapping and -index members
  drm/ttm: Refuse to fault (prime-) imported pages
  drm/ttm: Use VM_PFNMAP for shared bo maps

Xorg fbdev driver requires smem_start/smem_len, otherwise
it tries to map 0 bytes as video memory.

Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=856760Signed-off-by: Martin Koegler <martin.koegler@chello.at>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next

This pull request adds an anon file for exynos specific mmaper
to resolve potential a dead lock issue pointed out by Al Viro,
and fixes build break of drm-next.

* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
  drm/exynos: fix build error caused by removed drm core macros
  drm/exynos: use a new anon file for exynos gem mmaper

This is the drm-next pull for radeon for 3.14. Highlights include:
- dpm rework which fixes some issues and allows us to enable dpm by
default on CIK parts
- enable clockgating on CIK parts
- pci config reset.  This is a bus-level chip reset that can be more
reliable than soft reset in certain cases.  Disabled by default.  Enable
with the hard_reset module option.
- big endian rptr/wrptr update fixes
- lots of debugfs improvements
- some driver cleanup patches from Rashika Kheria
- bug fixes

* 'drm-next-3.14-wip' of git://people.freedesktop.org/~agd5f/linux: (50 commits)
  drm/radeon: implement pci config reset for CIK (v3)
  drm/radeon: implement pci config reset for SI (v2)
  drm/radeon: implement pci config reset for evergreen/cayman (v2)
  drm/radeon: implement pci config reset for r6xx/7xx (v3)
  drm/radeon: add pci config hard reset
  drm/radeon: add hard_reset module parameter
  drm/radeon: skip colorbuffer checking if COLOR_INFO.FORMAT is set to INVALID
  radeon/pm: Guard access to rdev->pm.power_state array
  drivers: gpu: Move prototype declarations to header file radeon_mode.h from radeon_atombios.c and radeon_combios.c
  drivers: gpu: Move prototype declaration to header file radeon_mode.h
  drm/radeon: move com/atombios scratch reg functions to radeon_mode.h
  drm/radeon/dpm: make some functions static for TN
  drm/radeon/dpm: make some functions static for sumo
  drm/radeon/dpm: make some functions static for CI
  drivers: gpu: Include appropriate header file in ci_smc.c
  drivers: gpu: Move prototype declaration to header file radeon_mode.h from atombios_i2c.c
  drivers: gpu: Include appropriate header file in si_smc.c and remove prototype declaration from header file sislands_smc.h
  drivers: gpu: Add static keyword to the definition of KMS_INVALID_IOCTL in radeon_kms.c
  drivers: gpu: Mark function as static in r600_hdmi.c
  drivers: gpu: Mark function as static in radeon_gem.c
  ...

MSM tree from Rob.

* 'msm-next' of git://people.freedesktop.org/~robclark/linux:
  drm/msm: add a330/apq8x74
  drm/msm: add mdp5/apq8x74
  drm/msm: add hdmi support for apq8x74/mdp5
  drm/msm: move irq utils to mdp_kms
  drm/msm: split out msm_kms.h
  drm/msm: mdp4_format -> mdp_format
  drm/msm: resync generated headers
  drm/msm: move mdp4 -> mdp/mdp4
  drm/msm: add support for msm8060ab/bstem
  drm/msm: add support for non-IOMMU systems
  drm/msm: fix bus scaling
  drm/msm: add missing MODULE_FIRMWARE()s
  drm/msm: COMPILE_TEST support

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>

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>

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>

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>

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

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>

resync to latest envytools db, add mdp5 registers
Signed-off-by: Rob Clark <robdclark@gmail.com>

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>

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>

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>

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>

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

With a simple stub, we can get COMPILE_TEST support.
Signed-off-by: Rob Clark <robdclark@gmail.com>

pci config reset is a low level reset that resets
the entire chip from the bus interface.  It can
be more reliable if soft reset fails.

v2: fix rebase
v3: hide behind module parameter
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

pci config reset is a low level reset that resets
the entire chip from the bus interface.  It can
be more reliable if soft reset fails.

v2: hide behind module parameter
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

pci config reset is a low level reset that resets
the entire chip from the bus interface.  It can
be more reliable if soft reset fails.

v2: put behind module parameter
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

pci config reset is a low level reset that resets
the entire chip from the bus interface.  It can
be more reliable if soft reset fails.

There's not much information still available on
r6xx, so r6xx is based on guess-work.

v2: put behind module parameter
v3: add IGP check
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

This is used to hard reset the asic.  If a soft
reset is not able to reset things, a hard reset
can be used.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Enabling this parameter enables pci config reset,
aka hard reset, which is a bus level chip reset.
In some cases this works more reliably than a soft
reset.  Disabled by default.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

This fixes a bug which was causing rejections of valid GPU commands
from userspace.
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

It's never allocated on systems without an ATOMBIOS or COMBIOS ROM.

Should fix an oops I encountered while resetting the GPU after a lockup
on my PowerBook with an RV350.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Mark functions as static because they are not used outside the file
drm/vmwgfx/vmwgfx_fence.c.

This eliminates the following warnings in drm/vmwgfx/vmwgfx_fence.c:
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:274:6: warning: no previous prototype for ‘vmw_fences_perform_actions’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:900:6: warning: no previous prototype for ‘vmw_fence_obj_add_action’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:996:5: warning: no previous prototype for ‘vmw_event_fence_action_create’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>

Mark functions as static because they are not used outside the file
drm/vmwgfx/vmwgfx_buffer.c.

This eliminates the following warnings in drm/vmwgfx/vmwgfx_buffer.c:
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c:520:16: warning: no previous prototype for ‘vmw_ttm_tt_create’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c:549:5: warning: no previous prototype for ‘vmw_invalidate_caches’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c:554:5: warning: no previous prototype for ‘vmw_init_mem_type’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c:592:6: warning: no previous prototype for ‘vmw_evict_flags’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>

Mark functions as static because they are not used outside the file
drm/vmwgfx/vmwgfx_kms.c.

This eliminates the following warnings in drm/vmwgfx/vmwgfx_kms.c:
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:43:6: warning: no previous prototype for ‘vmw_clip_cliprects’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:426:6: warning: no previous prototype for ‘vmw_framebuffer_surface_destroy’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:592:5: warning: no previous prototype for ‘vmw_framebuffer_surface_dirty’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:757:6: warning: no previous prototype for ‘vmw_framebuffer_dmabuf_destroy’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:943:5: warning: no previous prototype for ‘vmw_framebuffer_dmabuf_dirty’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:1666:5: warning: no previous prototype for ‘vmw_du_update_layout’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>

Remove unused function ttm_write_lock_downgrade() from
drm/ttm/ttm_lock.c.

This eliminates the following warning in drm/ttm/ttm_lock.c:
drivers/gpu/drm/ttm/ttm_lock.c:189:6: warning: no previous prototype for ‘ttm_write_lock_downgrade’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

Mark functions as static because they are not used outside the file
drm/ttm/ttm_bo_util.c.

This eliminates the following warnings in drm/ttm/ttm_bo_util.c:
drivers/gpu/drm/ttm/ttm_bo_util.c:190:5: warning: no previous prototype for ‘ttm_mem_reg_ioremap’ [-Wmissing-prototypes]
drivers/gpu/drm/ttm/ttm_bo_util.c:222:6: warning: no previous prototype for ‘ttm_mem_reg_iounmap’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

Mark function as static because it is not used outside file
drm/ttm/ttm_bo.c.

This eliminates the following warning in drm/ttm/ttm_bo.c:
drivers/gpu/drm/ttm/ttm_bo.c:960:5: warning: no previous prototype for ‘ttm_bo_move_buffer’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>

When a client looks up a ttm object, don't look it up through the device hash
table, but rather from the file hash table. That makes sure that the client
has indeed put a reference on the object, or in gem terms, has opened
the object; either using prime or using the global "name".

To avoid a performance loss, make sure the file hash table entries can be
looked up from under an RCU lock, and as a consequence, replace the rwlock
with a spinlock, since we never need to take it in read mode only anymore.

Finally add a ttm object lookup function for the device hash table, that is
intended to be used when we put a ref object on a base object or, in  gem terms,
when we open the object.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

Needed for some vm operations; most notably unmap_mapping_range() with
even_cows = 0.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

This is illegal for at least two reasons:

1) While it may work on some platforms / iommus, obtaining page pointers from
mapped sg-lists is illegal, since the DMA API allows page pointer information
to be destroyed in the sg mapping process.

2) TTM has no way of determining the linear kernel map caching state of the
underlying pages. PTEs with conflicting caching state pointing to the same
pfn is not allowed.

TTM operations touching pages of imported sg-tables should be redirected through
the proper dma-buf operations.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>

VM_PFNMAP is faster than VM_MIXEDMAP due to reduced page administration so
use it for shared maps where we don't have any Copy-On-Write pages. For
private maps, we continue to use VM_MIXEDMAP.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>

drivers: gpu: Move prototype declarations to header file radeon_mode.h from radeon_atombios.c and radeon_combios.c

Move prototype declarations of functions radeon_get_encoder_enum() and
radeon_link_encoder_connector() to header file drm/radeon/radeon_mode.h
because they are used by more than one file.

This eliminates the following warnings in drm/radeon/radeon_encoders.c:
drivers/gpu/drm/radeon/radeon_encoders.c:86:1: warning: no previous prototype for ‘radeon_get_encoder_enum’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_encoders.c:162:1: warning: no previous prototype for ‘radeon_link_encoder_connector’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Move prototype declaration of functions radeon_add_atom_connector() and
radeon_add_legacy_connector() to header file drm/radeon/radeon_mode.h
because  they are used by more than one file.

This eliminates the following warning in drm/radeon/radeon_connectors.c:
drivers/gpu/drm/radeon/radeon_connectors.c:1588:1: warning: no previous prototype for ‘radeon_add_atom_connector’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_connectors.c:2020:1: warning: no previous prototype for ‘radeon_add_legacy_connector’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>