v2: fix rebase onto drm-fixes
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Doesn't seem necessary, the GART table memory should be persistent.
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

These clutter up dmesg during piglit runs. Userspace generally deals
gracefully with this failure.
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We keep a cached version of the edid in radeon_connector which
we use for determining connectedness and when to enable certain
features like hdmi audio, etc.  When the user uses the firmware
interface to override the driver with some other edid the driver's
copy is never updated.  The fetch function will check if there
is a user supplied edid and update the driver's copy if there
is.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=80691Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Split radeon_ddc_get_modes() and move it into
radeon_connectors.c since that is the only place
that uses it.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

No need to continue with the loops once we've matched
the appropriate connector.
See commit 8a992ee1Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Valid values are 1 to 251 for 0 to 500 ms latency, 0 for unknown
and 255 for audio/video unsupported by sink, according to HDMI 1.3 spec.
Also matches Radeon HDA verb 0xf7b documentation.
Signed-off-by: NStefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This was originally un-inlined by Andi Kleen in 2011 citing size concerns.
Indeed, a first attempt at inlining it grew radeon.ko by 7%.

However, 2% of cpu is spent in this function. Simply inlining it gave 1% more fps
in Urban Terror.

v2: We know the minimum MMIO size. Adding it to the if allows the compiler to
optimize the branch out, improving both performance and size.

The v2 patch decreases radeon.ko size by 2%. I didn't re-benchmark, but common sense
says perf is now more than 1% better.

v3: Also change _wreg, make the threshold a define.

Inlining _wreg increased the size a bit compared to v2, so now radeon.ko
is only 1% smaller.
Signed-off-by: NLauri Kasanen <cand@gmx.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

They are identical.

v2: rebase
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This enables the display scaler on all connectors for r5xx
and newer asics.  Previously we only enabled the scaler for
fixed mode displays (eDP or LVDS) since they have to use the
scaler to support non-native modes.  Most other displays
are multi-sync or have a built in scaler to support non-native
modes.  The default scaling mode for non-fixed displays is
none which will use the scaler in the monitor.  Note that
we do not populate any fake modes like we do for fixed
displays so it will only use the modes in the edid.  For
other modes, you'll need to populate them manually.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=80868

v2: properly handle scaling with no modes defined
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Fix checkpatch warning:
WARNING: kfree(NULL) is safe this check is probably not required

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This adds CIK support for the new ucode format.

v2: add size validation, integrate debug info
v3: add support for MEC2 on KV
v4: fix typos
v4: update to latest format
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This adds SI support for the new ucode format.

v2: add size validation, integrate debug info
v3: update to latest version
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

These are needed to properly handle more frequently
updated firmware.

v2: add new firmware helper functions as well.
v3: update to latest format
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This needs some tweaking to be stable with newer
ucode versions.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Some newer boards use SVI2 for voltage control rather
than GPIO.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Commit 7dc19d5a "drivers: convert shrinkers to new count/scan API" added
deadlock warnings that ttm_page_pool_free() and ttm_dma_page_pool_free()
are currently doing GFP_KERNEL allocation.

But these functions did not get updated to receive gfp_t argument.
This patch explicitly passes sc->gfp_mask or GFP_KERNEL to these functions,
and removes the deadlock warning.
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [2.6.35+]
Signed-off-by: NDave Airlie <airlied@redhat.com>

While ttm_dma_pool_shrink_scan() tries to take mutex before doing GFP_KERNEL
allocation, ttm_pool_shrink_scan() does not do it. This can result in stack
overflow if kmalloc() in ttm_page_pool_free() triggered recursion due to
memory pressure.

  shrink_slab()
  => ttm_pool_shrink_scan()
     => ttm_page_pool_free()
        => kmalloc(GFP_KERNEL)
           => shrink_slab()
              => ttm_pool_shrink_scan()
                 => ttm_page_pool_free()
                    => kmalloc(GFP_KERNEL)

Change ttm_pool_shrink_scan() to do like ttm_dma_pool_shrink_scan() does.
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [2.6.35+]
Signed-off-by: NDave Airlie <airlied@redhat.com>

I can observe that RHEL7 environment stalls with 100% CPU usage when a
certain type of memory pressure is given. While the shrinker functions
are called by shrink_slab() before the OOM killer is triggered, the stall
lasts for many minutes.

One of reasons of this stall is that
ttm_dma_pool_shrink_count()/ttm_dma_pool_shrink_scan() are called and
are blocked at mutex_lock(&_manager->lock). GFP_KERNEL allocation with
_manager->lock held causes someone (including kswapd) to deadlock when
these functions are called due to memory pressure. This patch changes
"mutex_lock();" to "if (!mutex_trylock()) return ...;" in order to
avoid deadlock.
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [3.3+]
Signed-off-by: NDave Airlie <airlied@redhat.com>

We can use "unsigned int" instead of "atomic_t" by updating start_pool
variable under _manager->lock. This patch will make it possible to avoid
skipping when choosing a pool to shrink in round-robin style, after next
patch changes mutex_lock(_manager->lock) to !mutex_trylock(_manager->lork).
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [3.3+]
Signed-off-by: NDave Airlie <airlied@redhat.com>

list_empty(&_manager->pools) being false before taking _manager->lock
does not guarantee that _manager->npools != 0 after taking _manager->lock
because _manager->npools is updated under _manager->lock.
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [3.3+]
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NDave Airlie <airlied@redhat.com>

Merge branch 'drm_kms_for_next-v8' of git://git.linaro.org/people/benjamin.gaignard/kernel into drm-next

This series of patches add the support of DRM/KMS drivers for STMicroelectronics
chipsets stih416 and stih407.

Hardware is split in two main blocks: Compositor and TVout. Each of them
includes specific hardware IPs and the display timing are controlled by a specific
Video Timing Generator hardware IP (VTG).

Compositor is made of the follow hardware IPs:
 - GDP (Generic Display Pipeline) which is an entry point for graphic (RGB)
   buffers
 - VDP (Video Diplay Pipeline) which is an entry point for video (YUV) buffers
 - HQVDP (High Quality Video Display Processor) that supports scaling,
   deinterlacing and some miscellaneous image quality improvements.
   It fetches the Video decoded buffers from memory, processes them and pushes
   them to the Compositor through a HW dedicated bus.
 - Mixer is responsible of mixing all the entries depending of their
   respective z-order and layout

TVout is divided in 3 parts:
 - HDMI to generate HDMI signals, depending of chipset version HDMI phy can
   change.
 - HDA to generate signals for HD analog TV
 - VIP to control/switch data path coming from Compositor

On stih416 compositor and Tvout are on different dies so a Video Trafic Advance
inter-die Communication mechanism (VTAC) is needed.

+---------------------------------------------+   +----------------------------------------+
| +-------------------------------+   +----+  |   |  +----+   +--------------------------+ |
| |                               |   |    |  |   |  |    |   |  +---------+     +----+  | |
| | +----+              +------+  |   |    |  |   |  |    |   |  | VIP     |---->|HDMI|  | |
| | |GPD +------------->|      |  |   |    |  |   |  |    |   |  |         |     +----+  | |
| | +----+              |Mixer |--|-->|    |  |   |  |    |---|->| switcher|             | |
| |                     |      |  |   |    |  |   |  |    |   |  |         |     +----+  | |
| |                     |      |  |   |    |  |   |  |    |   |  |         |---->|HDA |  | |
| |                     +------+  |   |VTAC|========>|VTAC|   |  +---------+     +----+  | |
| |                               |   |    |  |   |  |    |   |                          | |
| |         Compositor            |   |    |  |   |  |    |   |           TVout          | |
| +-------------------------------+   |    |  |   |  |    |   +--------------------------+ |
|                      ^              |    |  |   |  |    |             ^                  |
|                      |              |    |  |   |  |    |             |                  |
|               +--------------+      |    |  |   |  |    |      +-------------+           |
|               | VTG (master) |----->|    |  |   |  |    |----->| VTG (slave) |           |
|               +--------------+      +----+  |   |  +----+      +-------------+           |
|Digital die                                  |   |                              Analog Die|
+---------------------------------------------+   +----------------------------------------+

On stih407 Compositor and Tvout are on the same die

+-----------------------------------------------------------------+
| +-------------------------------+  +--------------------------+ |
| |                               |  |  +---------+     +----+  | |
| | +----+              +------+  |  |  | VIP     |---->|HDMI|  | |
| | |GPD +------------->|      |  |  |  |         |     +----+  | |
| | +----+              |Mixer |--|--|->| switcher|             | |
| | +----+   +-----+    |      |  |  |  |         |     +----+  | |
| | |VDP +-->+HQVDP+--->|      |  |  |  |         |---->|HDA |  | |
| | +----+   +-----+    +------+  |  |  +---------+     +----+  | |
| |                               |  |                          | |
| |         Compositor            |  |           TVout          | |
| +-------------------------------+  +--------------------------+ |
|                              ^        ^                         |
|                              |        |                         |
|                           +--------------+                      |
|                           |     VTG      |                      |
|                           +--------------+                      |
|Digital die                                                      |
+-----------------------------------------------------------------+

In addition of the drivers for the IPs listed before a thin I2C driver (hdmiddc) is used
by HDMI driver to retrieve EDID for monitor.

To unify interfaces of GDP and VDP we create a "layer" interface called by
compositor to control both GPD and VDP.

Hardware have memory contraints (alignment, contiguous) so we use CMA drm helpers functions
to allocate frame buffer.

File naming convention is:
 - sti_* for IPs drivers
 - sti_drm_* for drm functions implementation.

* 'drm_kms_for_next-v8' of git://git.linaro.org/people/benjamin.gaignard/kernel:
  drm: sti: Add DRM driver itself
  drm: sti: add Compositor
  drm: sti: add Mixer
  drm: sti: add VID layer
  drm: sti: add GDP layer
  drm: sti: add TVOut driver
  drm: sti: add HDA driver
  drm: sti: add HDMI driver
  drm: sti: add VTAC drivers
  drm: sti: add VTG driver
  drm: sti: add bindings for DRM driver

This builds upon the previous set of fixes which were pulled on 6th July.
Included in this set are:
- an update from Jean-Francois to add the missing reg documentation entry
  to the device tree documentation.
- conversion of the tda998x driver to the component helpers.

* 'tda998x-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox:
  drm/i2c: tda998x: add component support
  drm/i2c: tda998x: allow re-use of tda998x support code
  drm/i2c: tda998x: fix lack of required reg in DT documentation

Conflicts:
	drivers/gpu/drm/i2c/tda998x_drv.c

This time around we have a mix of new hw enablement (mdp5 v1.3 /
apq8084), plus devicetree and various upstream changes (mostly
adapting to CCF vs downstream clk driver differences) for mdp4 /
apq8064.  With these drm/msm patches plus a few other small patchsets
(from linaro qcom integration branch.. mostly stuff queued up for
3.17) we have the inforce ifc6410 board working, with gpu.  Much nicer
to work with than ancient vendor android branch :-)

* 'msm-next' of git://people.freedesktop.org/~robclark/linux:
  drm/msm/hdmi: fix HDMI_MUX_EN gpio request typo
  drm/msm/hdmi: enable lpm-mux if it is present
  drm/msm/mdp5: add support for MDP5 v1.3
  drm/msm: fix potential deadlock in gpu init
  drm/msm: use upstream iommu
  drm/msm: no mmu is only error if not using vram carveout
  drm/msm: fix BUG_ON() in error cleanup path
  drm/msm/mdp4: add mdp axi clk
  drm/msm: hdmi phy 8960 phy pll
  drm/msm: update generated headers
  drm/msm: DT support for 8960/8064 (v3)
  drm/msm: Implement msm drm fb_mmap callback function
  drm/msm: activate iommu support
  drm/msm: fix double struct_mutex acquire

Linux 3.16

backmerge requested by i915, nouveau and radeon authors

Conflicts:
	drivers/gpu/drm/i915/i915_gem_render_state.c
	drivers/gpu/drm/i915/intel_drv.h

HDMI_MUX_EN gpio is requested. If an error occurs, the same name
should be printed (HDMI_MUX_EN) instead of HDMI_MUX_SEL (typo).
Signed-off-by: NBeeresh Gopal <gbeeresh@codeaurora.org>
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NRob Clark <robdclark@gmail.com>

lpm-mux is programmed to enable HDMI connector
on the docking station for S805 chipset based
devices.
Signed-off-by: NBeeresh Gopal <gbeeresh@codeaurora.org>
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

MDP5 has several functional blocks (ie: VIG/RGB pipes, LMs, ...).
From one revision to another, these blocks' base addresses might
change due to the number of instances present in the MDP5 hw.
A way of dealing with these offset changes is to introduce
dynamic offsets 'per block'.

This change adds support for the new revision of MDP5: v1.3.
The idea is to define one hw config per MDP version and select
either one of them at runtime, after reading the MDP5 version.

Once the MDP version is known, 'per block' dynamic offsets
are initialized through a global pointer, which is then used for
read/write register access.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Somewhere along the way, the firmware loader sprouted another lock
dependency, resulting in possible deadlock scenario:

 &dev->struct_mutex --> &sb->s_type->i_mutex_key#2 --> &mm->mmap_sem

which is problematic vs things like gem mmap.

So introduce a separate mutex to synchronize gpu init.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Downstream kernel IOMMU had a non-standard way of dealing with multiple
devices and multiple ports/contexts.  We don't need that on upstream
kernel, so rip out the crazy.

Note that we have to move the pinning of the ringbuffer to after the
IOMMU is attached.  No idea how that managed to work properly on the
downstream kernel.

For now, I am leaving the IOMMU port name stuff in place, to simplify
things for folks trying to backport latest drm/msm to device kernels.
Once we no longer have to care about pre-DT kernels, we can drop this
and instead backport upstream IOMMU driver.
Signed-off-by: NRob Clark <robdclark@gmail.com>

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

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

Downstream kernel holds this clk via a fake-parent relationship.
Upstream clock framework requires that we hold it explicitly.
Signed-off-by: NRob Clark <robdclark@gmail.com>

On downstream kernel the clk driver directly bangs hdmi phy registers.
For upstream kernel, we need to model this as a clock and register with
the clock framework.
Signed-off-by: NRob Clark <robdclark@gmail.com>

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

Now that we (almost) have enough dependencies in place (MMCC, RPM, etc),
add necessary DT support so that we can use drm/msm on upstream kernel.

v2: update for review comments
v3: rebase on component helper changes
Signed-off-by: NRob Clark <robdclark@gmail.com>

This change implements msm drm specific fb_mmap function for fb device
to properly map the fb address to userspace.
Signed-off-by: NHai Li <hali@codeaurora.org>
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com> (+ minor comment tweak)