For Gen < 8, set M2_N2 registers on every mode set. This is required to make
sure M2_N2 registers are set during boot, resume from sleep for cross-
checking the state. The register is set only if DRRS is supported.

v2: Patch rebased

v3: Daniel's review comments
	- Removed HAS_DRRS(dev) and added bool has_drrs to pipe_config to
	track drrs support

v4: Jesse's review comments
	- Made changes to set m2_n2 in intel_dp_set_m_n()
Signed-off-by: NVandana Kannan <vandana.kannan@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit 521e62e4.

Although POST_SYNC brought a bit of stability to Semaphores on BDW
it didn't solved all issues and some hungs can still occour when
semaphores are enabled on BDW. Also some sloweness can be found on some
igt tests, althoguth it apparently doesn't affect real workloads.

Besides that, no real performance gain was found on our tests with different
and even multiple workloads.

Let's disable it again for now. At least until we are sure it is safe
to re-enable it.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Withtout this, ring initialization fails reliabily during resume with

	[drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head ffffff8804 tail 00000000 start 000e4000

This is not a complete fix, but it is verified to make the ring
initialization failures during resume much less likely.

We were not able to root-cause this bug (likely HW-specific to Gen4 chips)
yet. This is therefore used as a ducttape before problem is fully
understood and proper fix created, so that people don't suffer from
completely unusable systems in the meantime.

The discussion and debugging is happening at

	https://bugs.freedesktop.org/show_bug.cgi?id=76554Signed-off-by: NJiri Kosina <jkosina@suse.cz>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This particular nasty presented itself while trying to register the
intelfb device (intel_fbdev.c). During the process of registering the device
the driver will disable the crtc via i9xx_crtc_disable. These will
also disable the panel using the generic mipi panel functions in
dsi_mod_vbt_generic.c. The stale MIPI generic data sequence pointers would
cause a crash within those functions. However, all of this is happening
while console_lock is held from do_register_framebuffer inside fbcon.c. Which
means that you got kernel log and just the device appearing to reboot/hang for
no apparent reason.

The fault started from the FB_EVENT_FB_REGISTERED event using the
fb_notifier_call_chain call in fbcon.c.

This regression has been introduced in

commit d3b542fc
Author: Shobhit Kumar <shobhit.kumar@intel.com>
Date:   Mon Apr 14 11:00:34 2014 +0530

    drm/i915: Add parsing support for new MIPI blocks in VBT

Cc: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NRafael Barbalho <rafael.barbalho@intel.com>
Reviewed-by: NShobhit Kumar <shobhit.kumar@intel.com>
[danvet: Add regression citation.]
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We might be leaving the PGU Frequency (and thus vnn) high during the suspend.
Flusing the delayed work queue should take care of this.
Signed-off-by: NDeepak S <deepak.s@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

BDW has many other Display Engine interrupts and GT interrupts registers.
Collecting it properly on gpu_error_state.

On debugfs all was properly listed already but besides we were also listing old
DEIER and GTIER that doesn't exist on BDW anymore. This was causing
unclaimed register messages

v2: Fix small issues of first version and don't read DEIER regs when pipe's
    power well is disabled
v3: bikeshed accepted: use enum pipe pipe instead of int i for pipe interection
v4: Ben notice previous version was checking for display_power_enabled without
    using propper locks. Using _unlocked version isn't reliable and we cannot
    get this registers when power well is off. So let's avoid getting all DE_IER
    per pipe for now. If someone think this is an useful information it can be
    added later.
v5: Ben: put back debugfs stuff that might be coverred by pm_get and use
    	 gen >= 8 trying to predict future.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81701
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: N(v3) Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If the actual head has progressed forward inside a batch (request),
don't accumulate hangcheck score.

As the hangcheck score in increased only by acthd jumping backwards,
the result is that we only declare an active batch as stuck if it is
trapped inside a loop. Or that the looping will dominate the batch
progression so that it overcomes the bonus that forward progress gives.

v2: Improved commit message (Chris Wilson)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
[danvet: s/active_loop/active (loop)/ as requested by Chris.]
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On Broadwell, any PIPE_CONTROL with the "State Cache Invalidate" bit set
must be preceded by a PIPE_CONTROL with the "CS Stall" bit set.

Documented on the BSpec 3D workarounds page.
Reviewed-by: NRafael Barbalho <rafael.barbalho@intel.com>
Signed-off-by: NKenneth Graunke <kenneth@whitecape.org>
[vsyrjala: add chv w/a note too]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We'll want to reuse this for a workaround.
Signed-off-by: NKenneth Graunke <kenneth@whitecape.org>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Rmove now unused int.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NDaniel 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: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel 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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel 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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel 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: NPaulo Zanoni <przanoni@gmail.com>
Acked-by: NPaulo Zanoni <przanoni@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Fix signal_offset when recording semaphore state on BDW.
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel 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: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel 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: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel 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: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel 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: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel 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: NPavel Machek <pavel@ucw.cz>
[danvet: Add obligatory /* shuts up gcc */ comment.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NDaniel 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: 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>

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>