The DDL registers can hold 7bit numbers. Make the most of those seven
bits by adjusting the threshold where we switch between the 64 vs. 32
precision multipliers.

Also we compute 'entries' to make the decision about precision, and then
we recompute the same value to calculate the actual drain latency. Just
use the already calculate 'entries' there.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

GTIER and DEIER doesn't have same interface on HSW so this "or" operation
makes the information provided useless.

v2: since we have gtier variable already let's split for everybody
and avoid the strange | op.
    Also avoid overriding the value that was set for vlv. In this case I
    believe that we should reorganize the whole function, but I'll respect
    the comment that ask to not touch the order and let this organization
    work to be done later.
v3: moving VLV check to the right place.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Users often can't do anything about this since their vendors stopped
providing BIOS updates. Also we seem to be able to hack around it
with increased latency values, and thus far the only reports have
been for screens with really high resolutions. So tune it down to a
level where only developers can see it.

Also drop some of the end-user fluff.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Power users spot this and then get adventurous and try to adjust
module driver options. Nothing good ever came out of that, so
hide it better.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Since I've reworked psr support to no longer require x-tiling we don't
check any state protected by the Giant GEM Lock. So drop that check.

Also boo for lockdep_assert_held for not yelling when lockdep is
disabled.

Cc: Paulo Zanoni <przanoni@gmail.com>
Reported-by: Paulo Zanoni <przanoni@gmail.com>
Acked-by: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Fix signal_offset when recording semaphore state on BDW.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Just like during booting the BIOS can leave the VDD bit enabled after
system resume. So apply the same state sanitization there too. This
fixes a problem where after resume the port power domain refcount gets
unbalanced.

v2:
- unchanged
v3:
- call edp sanitizing from the encoder reset handler (Daniel)
Reported-and-tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Check in vlv_crtc_clock_get if DPLL is enabled before calling dpio read.
It will not be enabled for DSI and avoid dpio read WARN dumps.

Absence of ->get_config was causing other WARN dumps as well. Update
dpll_hw_state as well correctly

v2: Address review comments by Daniel
    - Check if DPLL is enabled rather than checking pipe output type
    - set adjusted_mode->flags to 0 in compute_config rather than using
      pipe_config->quirks
    - Add helper function in intel_dsi_pll.c and use that in intel_dsi.c
    - updated dpll_hw_state correctly
    - Updated commit message and title

v3: Address review comments by Imre
    - Proper masking of P1, M1 fields while computing divisors
    - assert in case of bpp mismatch
    - guard for divide by 0 while computing pclk
    - Use ARRAY_SIZE instead of direct calculation
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

This will be needed by an upcoming patch too that needs to sanitize the
VDD state during resume. The additional async disabling is only needed
for the resume path, here it doesn't make a difference since we enable
VDD right after the sanitize call.

v2:
- don't set intel_dp ptr for non-eDP encoders (Ville)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Ensure that the DSI packets for a particular sequence are completely
sent before going ahead in the enabling or disabling of the panel
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Gcc warns that addr might be used uninitialized. It may not, but I see
why gcc gets confused.

Additionally, hiding code with side-effects inside WARN_ON() argument
seems uncool, so I moved it outside.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
[danvet: Add obligatory /* shuts up gcc */ comment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

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: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [2.6.35+]
Signed-off-by: Dave 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: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [2.6.35+]
Signed-off-by: Dave 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: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [3.3+]
Signed-off-by: Dave 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: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [3.3+]
Signed-off-by: Dave 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: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [3.3+]
Signed-off-by: Dave Airlie <airlied@redhat.com>

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

Signed-off-by: Dave 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: Beeresh Gopal <gbeeresh@codeaurora.org>
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Rob Clark <robdclark@gmail.com>

lpm-mux is programmed to enable HDMI connector
on the docking station for S805 chipset based
devices.
Signed-off-by: Beeresh Gopal <gbeeresh@codeaurora.org>
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob 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: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob 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: Rob 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: Rob Clark <robdclark@gmail.com>

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

Signed-off-by: Rob 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: Rob 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: Rob Clark <robdclark@gmail.com>

Signed-off-by: Rob 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: Rob 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: Hai Li <hali@codeaurora.org>
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com> (+ minor comment tweak)

This changes activates the iommu support for MDP5, through the
platform config structure.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>

Mutex is already grabbed in show_locked().. somehow this slipped
through.
Signed-off-by: Rob Clark <robdclark@gmail.com>

Merge tag 'drm-intel-next-2014-07-25-merged' of git://anongit.freedesktop.org/drm-intel into drm-next

Final feature pull for 3.17.

drm-intel-next-2014-07-25:
- Ditch UMS support (well just the config option for now)
- Prep work for future platforms (Sonika Jindal, Damien)
- runtime pm/soix fixes (Paulo, Jesse)
- psr tracking improvements, locking fixes, now enabled by default!
- rps fixes for chv (Deepak, Ville)
- drm core patches for rotation support (Ville, Sagar Kamble) - the i915 parts
  unfortunately didn't make it yet
- userptr fixes (Chris)
- minimum backlight brightness (Jani), acked long ago by Matthew Garret on irc -
  I've forgotten about this patch :(

QA is a bit unhappy about the DP MST stuff since it broke hpd testing a
bit, but otherwise looks sane. I've backmerged drm-next to resolve
conflicts with the mst stuff, which means the new tag itself doesn't
contain the overview as usual.

* tag 'drm-intel-next-2014-07-25-merged' of git://anongit.freedesktop.org/drm-intel: (75 commits)
  drm/i915/userptr: Keep spin_lock/unlock in the same block
  drm/i915: Allow overlapping userptr objects
  drm/i915: Ditch UMS config option
  drm/i915: respect the VBT minimum backlight brightness
  drm/i915: extract backlight minimum brightness from VBT
  drm/i915: Replace HAS_PCH_SPLIT which incorrectly lets some platforms in
  drm/i915: Returning from increase/decrease of pllclock when invalid
  drm/i915: Setting legacy palette correctly for different platforms
  drm/i915: Avoid incorrect returning for some platforms
  drm/i915: Writing proper check for reading of pipe status reg
  drm/i915: Returning the right VGA control reg for platforms
  drm/i915: Allowing changing of wm latencies for valid platforms
  drm/i915: Adding HAS_GMCH_DISPLAY macro
  drm/i915: Fix possible overflow when recording semaphore states.
  drm/i915: Do not unmap object unless no other VMAs reference it
  drm/i915: remove plane/cursor/pipe assertions from intel_crtc_disable
  drm/i915: Reorder ctx unref on ppgtt cleanup
  drm/i915/error: Check the potential ctx obj's vm
  drm/i915: Fix printing proper min/min/rpe values in debugfs
  drm/i915: BDW can also detect unclaimed registers
  ...

Daniel pointed out with hotplug that userspace could be trying to oops us
as root for lols, and that to be correct we shouldn't register the object
with the idr before we have fully set the connector object up.

His proposed solution was a lot more life changing, this seemed like a simpler
proposition to me, get the connector object id from the idr, but don't
register the object until the drm_connector_register callback.

The open question is whether the drm_mode_object_register needs a bigger lock
than just the idr one, but I can't see why it would, but I can be locking
challenged.

v2: fix bool noreg into sane - add comment.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>