For GEMINILAKE, dphy param reg values are programmed in terms
of HS byte clock count while for older platforms in terms of
HS ddr clk count.

v2: Added comments to clarify ddr clock count calculation
v3: Use multiplier variable instead of IS_GEMINILAKE()
check everywhere (Jani)
Signed-off-by: NDeepak M <m.deepak@intel.com>
Signed-off-by: NMadhav Chauhan <madhav.chauhan@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487335415-14766-2-git-send-email-madhav.chauhan@intel.com

A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent basis. We do want to disable the
interrupt during normal operations as under high load it may add several
thousand interrupts/s - we have been known in the past to occupy whole
cores with our interrupt handler after accidentally leaving user
interrupts enabled. As a compromise, leave the interrupt enabled until
the next IRQ, or the system is idle. This gives a small window for a
waiter to keep the interrupt active and not be delayed by having to
re-enable the interrupt.

v2: Restore hangcheck/missed-irq detection for continuations
v3: Be more careful restoring the hangcheck timer after reset
v4: Be more careful restoring the fake irq after reset (if required!)
v5: Redo changes to intel_engine_wakeup()
v6: Factor out __intel_engine_wakeup()
v7: Improve commentary for declaring a missed wakeup
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227205850.2828-4-chris@chris-wilson.co.uk

By deferring hangcheck to the fake breadcrumb interrupt, we can simply
the enabling procedure slightly - as by enabling the fake, we then
enable the hangcheck. By always enabling the hangcheck from each fake
interrupt (it will be a no-op for an already queued hangcheck), it will
make restoring the breadcrumbs after a reset simpler in the next patch.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227205850.2828-3-chris@chris-wilson.co.uk

As execlists and other non-semaphore multi-engine devices coordinate
between engines using interrupts, we can shave off a few 10s of
microsecond of scheduling latency by doing the fence signaling from the
interrupt as opposed to a RT kthread. (Realistically the delay adds
about 1% to an individual cross-engine workload.) We only signal the
first fence in order to limit the amount of work we move into the
interrupt handler. We also have to remember that our breadcrumbs may be
unordered with respect to the interrupt and so we still require the
waiter process to perform some heavyweight coherency fixups, as well as
traversing the tree of waiters.

v2: No need for early exit in irq handler - it breaks the flow between
patches and prevents the tracepoint
v3: Restore rcu hold across irq signaling of request
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227205850.2828-2-chris@chris-wilson.co.uk

The two users of the return value from intel_engine_wakeup() are
expecting different results. In the breadcrumbs hangcheck, we are using
it to determine whether wake_up_process() detected the waiter was
currently running (and if so we presume that it hasn't yet missed the
interrupt). However, in the fake_irq path, we are using the return value
as a check as to whether there are any waiters, and so we may
incorrectly stop the fake-irq if that waiter was currently running.

To handle the two different needs, return both bits of information! We
uninline it from the irq path in preparation for the next patch which
makes the irq hotpath special and relegates intel_engine_wakeup() to the
slow fixup paths.

v2: s/ret/result/
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227205850.2828-1-chris@chris-wilson.co.uk

After initiating a sideband transaction, we only want to wait for the
transaction to become idle. If, as we are, we wait for both the busy
and error flag to clear, if an error is raised we just spin until the
timeout. Once the hw is idle, we can then check to see if the hw flagged
an error, and report it distinctly.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223141020.13250-1-chris@chris-wilson.co.ukReviewed-by: NJani Nikula <jani.nikula@intel.com>

No hardware was ever shipped that needed more than 4096 byte alignment
and future hardware will not use this legacy path. So reduce the
alignment to make it easier and quicker to launch workloads.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227135913.8056-3-chris@chris-wilson.co.uk

We are required to reload the TLBs around ppgtt switches. However, we
already do an unconditional TLB invalidate before every batch and a flush
afterwards, so this condition is already satisfied without extra flushes
around the LRI instructions.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227135913.8056-2-chris@chris-wilson.co.uk

We are required to reload the TLBs around context switches
(MI_SET_CONTEXT specifically) and the recommendation is do that before
the MI_SET_CONTEXT so that it is serialised with the switch and not
forgotten:

[DevSNB] If Flush TLB invalidation Mode is enabled it’s the driver’s
responsibility to invalidate the TLBs at least once after the previous
context switch after any GTT mappings changed (including new GTT entries).
This can be done by a pipeline PIPE_CONTROL with TLB inv bit set
immediately before MI_SET_CONTEXT.

However, we already do an unconditional TLB invalidate before every
batch so this condition is satifisfied.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227135913.8056-1-chris@chris-wilson.co.uk

Certain Baytrails, namely the 4 cpu core variants, have been
plaqued by spurious system hangs, mostly occurring with light loads.

Multiple bisects by various people point to a commit which changes the
reclocking strategy for Baytrail to follow its bigger brethen:
commit 8fb55197 ("drm/i915: Agressive downclocking on Baytrail")

There is also a review comment attached to this commit from Deepak S
on avoiding punit access on Cherryview and thus it was excluded on
common reclocking path. By taking the same approach and omitting
the punit access by not tweaking the thresholds when the hardware
has been asked to move into different frequency, considerable gains
in stability have been observed.

With J1900 box, light render/video load would end up in system hang
in usually less than 12 hours. With this patch applied, the cumulative
uptime has now been 34 days without issues. To provoke system hang,
light loads on both render and bsd engines in parallel have been used:
glxgears >/dev/null 2>/dev/null &
mpv --vo=vaapi --hwdec=vaapi --loop=inf vid.mp4

So far, author has not witnessed system hang with above load
and this patch applied. Reports from the tenacious people at
kernel bugzilla are also promising.

Considering that the punit access frequency with this patch is
considerably less, there is a possibility that this will push
the, still unknown, root cause past the triggering point on most loads.

But as we now can reliably reproduce the hang independently,
we can reduce the pain that users are having and use a
static thresholds until a root cause is found.

v3: don't break debugfs and simplification (Chris Wilson)

References: https://bugzilla.kernel.org/show_bug.cgi?id=109051
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: fritsch@xbmc.org
Cc: miku@iki.fi
Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
CC: Michal Feix <michal@feix.cz>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Deepak S <deepak.s@linux.intel.com>
Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.2+
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487166779-26945-1-git-send-email-mika.kuoppala@intel.com

As we track whether a vma has been inserted into the drm_mm using the
vma->flags, if we fail to bind the vma into the GTT we do not update
those bits and will attempt to reinsert the vma into the drm_mm on
future passes. To prevent that, we want to unwind i915_vma_insert() if
we fail in our attempt to bind.

Fixes: 59bfa124 ("drm/i915: Start passing around i915_vma from execbuffer")
Testcase: igt/drv_selftest/live_gtt
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.9+
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227122654.27651-3-chris@chris-wilson.co.uk

If we fail to allocate the ppgtt range after allocating the pages for
the vma, we should unwind the local allocation before reporting back the
failure.

Fixes: ff685975 ("drm/i915: Move allocate_va_range to GTT")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227122654.27651-2-chris@chris-wilson.co.uk

Only if we allocated the layer and the lower level failed should we
remove this layer when unwinding. Otherwise we ignore the overlapping
entries by overwriting the old layer with scratch.

Fixes: c5d092a4 ("drm/i915: Remove bitmap tracking for used-pml4")
Fixes: e2b763ca ("drm/i915: Remove bitmap tracking for used-pdpes")
Reported-by: NMatthew Auld <matthew.william.auld@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99947
Testcase: igt/drv_selftest/live_gtt
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Tested-by: NMatthew Auld <matthew.auld@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227122654.27651-1-chris@chris-wilson.co.uk

The replay bit of the ring mode register is not a valid bit for Gen8+.
Do not write to this bit.
Signed-off-by: NKelvin Gardiner <kelvin.gardiner@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com>
Reviewed-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
[Joonas: Fixed commit message line to be under 72 chars]
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487963724-4824-1-git-send-email-kelvin.gardiner@intel.com

Used by production device:
    Intel(R) Iris(TM) Graphics P555

Cc: <stable@vger.kernel.org>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NMichał Winiarski <michal.winiarski@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227112256.20060-1-michal.winiarski@intel.com

Backmerge the main pull request to sync up with all the newly landed
drivers. Otherwise we'll have chaos even before 4.12 started in
earnest.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

According to bspec, the DDI IO power domains should be enabled after
enabling the DPLL and mapping it to the DDI. The current order doesn't
seem to create problems with Skylake and Kabylake, but causes enable
timeouts in Geminilake.

v2: Rebase.
  - Take power domain references before sanitizing encoders. (Imre)
  - Add comment to get_encoder_power_domains() defition. (Ander)

v3: Don't put the domain if called with HSW/BDW's analog encoder. (CI)

v4: Put IO power domain before unmapping DPLL. (Imre)
  - Change return type of intel_ddi_get_power_domains() to u64. (Imre)

Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> # v1
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224141959.5955-1-ander.conselvan.de.oliveira@intel.com

In Geminilake, the DDI IO power domains can't be enabled before a DPLL
is running and mapped to the appropriate DDI. At least on Geminilake,
attempting to enable those during init will lead to a timeout.

The failure to enable the power domain also causes issues with the state
verifier during resume from suspend. After all the init power domains
are enabled, the call to intel_power_domains_sync_hw() from the resume
path will cause the hw_enabled field on the respective power wells to be
false while the usage count remains above zero. Further attempts to
enable the power domain caused by a modeset will simply update the usage
count without doing anything else. When the state verifier attempts to
read the state of a DDI encoder, intel_display_power_get_if_enabled()
returns false, leading to the following WARN:

WARNING: CPU: 3 PID: 1743 at drivers/gpu/drm/i915/intel_display.c:7001 verify_connector_state.isra.80+0x26c/0x2b0 [i915]
attached crtc is active, but connector isn't
Modules linked in: i915(E) tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_broute bridge stp llc ebtable_nat ip6table_mangle ip6table_security ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_raw iptable_mangle iptable_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables x86_pkg_temp_thermal coretemp kvm_intel kvm i2c_algo_bit drm_kms_helper irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drm shpchp tpm_tis tpm_tis_core tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc crc32c_intel serio_raw [last unloaded: i915]
CPU: 3 PID: 1743 Comm: kworker/u8:22 Tainted: G        W   E   4.10.0-rc3ander+ #300
Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0023.B40.1611302145 11/30/2016
Workqueue: events_unbound async_run_entry_fn
Call Trace:
 dump_stack+0x86/0xc3
 __warn+0xcb/0xf0
 warn_slowpath_fmt+0x5f/0x80
 verify_connector_state.isra.80+0x26c/0x2b0 [i915]
 intel_atomic_commit_tail+0x520/0x1000 [i915]
 ? remove_wait_queue+0x70/0x70
 intel_atomic_commit+0x3f8/0x520 [i915]
 ? intel_runtime_pm_put+0x6e/0xa0 [i915]
 drm_atomic_commit+0x4b/0x50 [drm]
 __intel_display_resume+0x72/0xc0 [i915]
 intel_display_resume+0x107/0x150 [i915]
 i915_drm_resume+0xe0/0x180 [i915]
 i915_pm_restore+0x1e/0x30 [i915]
 i915_pm_resume+0xe/0x10 [i915]
 pci_pm_resume+0x64/0xa0
 dpm_run_callback+0xa1/0x2a0
 ? pci_pm_thaw+0x90/0x90
 device_resume+0xe3/0x200
 async_resume+0x1d/0x50
 async_run_entry_fn+0x39/0x170
 process_one_work+0x212/0x670
 ? process_one_work+0x197/0x670
 worker_thread+0x4e/0x490
 kthread+0x101/0x140
 ? process_one_work+0x670/0x670
 ? kthread_create_on_node+0x60/0x60
 ret_from_fork+0x2a/0x40

Cc: David Weinehall <david.weinehall@linux.intel.com>
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170222063431.10060-6-ander.conselvan.de.oliveira@intel.com

Implement WaDDIIOTimeout to avoid a timeout when enabling the DDI IO
power domains.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170222063431.10060-5-ander.conselvan.de.oliveira@intel.com

Don't allow conversion from arbitraty encoder types to a digital port.
Calling enc_to_dig_port() with the wrong encoder may seem far fetched,
but certain paths of the ddi code may be called with hasell's analog
encoder and the conversion is wrong for DP mst encoders too, so safe
guard against it.

v2: Warn if encoder type is unknown and device is not DDI. (Imre)
v3: Remove stray hunk from rebase error. (Ander)
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224141845.5836-1-ander.conselvan.de.oliveira@intel.com

The encoder power domain is obviously tied to the encoder, so store it
in struct intel_encoder. This avoids some indirection.

v2: Rebase
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170222063431.10060-3-ander.conselvan.de.oliveira@intel.com

The aux power domain only makes sense in the DP code. Storing it in
struct intel_dp avoids some indirection.

v2: Rebase
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170222063431.10060-2-ander.conselvan.de.oliveira@intel.com

When advancing onto the next 4th level page table entry, we need to
reset our indices to 0. Currently we restart from the original address
which means we start with an offset into the next PML table.

Fixes: 894ccebe ("drm/i915: Micro-optimise gen8_ppgtt_insert_entries()")
Reported-by: NMatthew Auld <matthew.william.auld@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99948
Testcase: igt/drv_selftest/live_gtt
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Tested-by: NMatthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: NMatthew Auld <matthew.william.auld@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170225181122.4788-4-chris@chris-wilson.co.uk

We rely on the VMA being allocated inside the drm_mm and for its allotted
node being large enough to accommodate all the vma->pages.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: NMatthew Auld <matthew.william.auld@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170225181122.4788-3-chris@chris-wilson.co.uk

Before looking up the page directory entry, check we are still within
bounds.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: NMatthew Auld <matthew.william.auld@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170225181122.4788-2-chris@chris-wilson.co.uk

Double check that we allocated the right amount of scatterlist elements
for our obj->size.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: NMatthew Auld <matthew.william.auld@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170225181122.4788-1-chris@chris-wilson.co.uk

Check for a timeout in the lowlevel_hole GTT before we allocate state
for that pass, as our cleanup phase stops on the iteration before the
timeout.

References: https://bugs.freedesktop.org/show_bug.cgi?id=99947Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224193315.21072-1-chris@chris-wilson.co.ukReviewed-by: NMatthew Auld <matthew.william.auld@gmail.com>

This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0
(indicating the optional feature is not supported), and makes execbuf
always return -EINVAL if the flags are used.

Apparently, no userspace ever shipped which used this optional feature:
I checked the git history of Mesa, xf86-video-intel, libva, and Beignet,
and there were zero commits showing a use of these flags.  Kernel commit
72bfa19c apparently introduced the feature prematurely.  According
to Chris, the intention was to use this in cairo-drm, but "the use was
broken for gen6", so I don't think it ever happened.

'relative_constants_mode' has always been tracked per-device, but this
has actually been wrong ever since hardware contexts were introduced, as
the INSTPM register is saved (and automatically restored) as part of the
render ring context. The software per-device value could therefore get
out of sync with the hardware per-context value.  This meant that using
them is actually unsafe: a client which tried to use them could damage
the state of other clients, causing the GPU to interpret their BO
offsets as absolute pointers, leading to bogus memory reads.

These flags were also never ported to execlist mode, making them no-ops
on Gen9+ (which requires execlists), and Gen8 in the default mode.

On Gen8+, userspace can write these registers directly, achieving the
same effect.  On Gen6-7.5, it likely makes sense to extend the command
parser to support them.  I don't think anyone wants this on Gen4-5.

Based on a patch by Dave Gordon.

v3: Return -ENODEV for the getparam, as this is what we do for other
    obsolete features.  Suggested by Chris Wilson.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92448Signed-off-by: NKenneth Graunke <kenneth@whitecape.org>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170215093446.21291-1-kenneth@whitecape.orgAcked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

At least a ParadTech PS175 LSPCON chip/firmware uses long instead of
short pulses to signal output unplug/plug events. This is contrary to
how branch devices normally work which use short HPD signaling. This
chip will also switch to LS mode after an unplug event, which could be
the consequence of the long HPD signaling semantics and an effort to
save power automatically. Because of this we'll fail to do AUX and
detect the output after a replug event.

To fix this make sure we are in PCON mode during connector detection.

v2:
- Switch the mode in the proper spot.

Cc: raptorteak@gmail.com
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98912
Reported-and-tested-by: raptorteak@gmail.com
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487776252-6288-1-git-send-email-imre.deak@intel.com

We require that the request is completed before the context is switched
away.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223145031.26210-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>

Rather than sprinkling ideas of how big the DDI buf translation tables
are somewhere in intel_dp.c, let's concentrate it all in intel_ddi.c
where the actual tables are defined. To that end we introduce
intel_ddi_dp_voltage_max() which will actually look at the proper
translation table to determine what is the maximum voltage swing level
supported.

v2: Mask out the preemphasis bits from the return value of
    intel_ddi_dp_voltage_max()
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223174901.26749-1-ville.syrjala@linux.intel.com

Convert the big switch statement in translate_signal_level() into a neat
table. The table also serves as documentation for the translation
tables. We'll also have other uses for this table later on.

v2: Remove superfluous space (David)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223173507.17600-2-ville.syrjala@linux.intel.comReviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>

Split the code to select the correct translation table into DP,
eDP and FDI specific helpers. This reduces the clutter in
intel_prepare_dp_ddi_buffers(), and we'll have other uses for some
of these new helper functions later on.

v2: Fix typo in commit message (David)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223173507.17600-1-ville.syrjala@linux.intel.comReviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>

If we cease making progress in finding matching outputs for a tiled
configuration, stop looping over the remaining unconfigured outputs.

v2: Use conn_seq (instead of pass) to only apply tile configuration on
first pass.

Fixes: b0ee9e7f ("drm/fb: add support for tiled monitor configurations. (v2)")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tomasz Lis <tomasz.lis@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: <stable@vger.kernel.org> # v3.19+
Reviewed-by: NTomasz Lis <tomasz.lis@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224114306.4400-1-chris@chris-wilson.co.uk

Linus doesn't like it user selectable, so kill it until
someone needs it for something else.
Signed-off-by: NDave Airlie <airlied@redhat.com>

BACKLIGHT_CLASS_DEVICE was selected in the last version of the
tinydrm patchset to fix the backlight dependency, but the
ifdef CONFIG_BACKLIGHT_CLASS_DEVICE was forgotten. Fix that.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This warning is seen on 64-bit builds in functions:
   'mipi_dbi_typec1_command':
   'mipi_dbi_typec3_command_read':
   'mipi_dbi_typec3_command':

>> drivers/gpu/drm/tinydrm/mipi-dbi.c:65:20: warning: field width specifier '*' expects argument of type 'int', but argument 5 has type 'size_t {aka long unsigned int}' [-Wformat=]
      DRM_DEBUG_DRIVER("cmd=%02x, par=%*ph\n", cmd, len, data); \
                       ^
   include/drm/drmP.h:228:40: note: in definition of macro 'DRM_DEBUG_DRIVER'
     drm_printk(KERN_DEBUG, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
                                           ^~~
>> drivers/gpu/drm/tinydrm/mipi-dbi.c:671:2: note: in expansion of macro 'MIPI_DBI_DEBUG_COMMAND'
     MIPI_DBI_DEBUG_COMMAND(cmd, parameters, num);
     ^~~~~~~~~~~~~~~~~~~~~~

Fix by casting 'len' to int in the macro MIPI_DBI_DEBUG_COMMAND().
There is no chance of overflow.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fix this warning:
drivers/gpu/drm/tinydrm/mipi-dbi.c: In function ‘mipi_dbi_debugfs_command_write’:
drivers/gpu/drm/tinydrm/mipi-dbi.c:905:8: warning: ‘cmd’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  ret = mipi_dbi_command_buf(mipi, cmd, parameters, i);
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

cmd can't be used uninitialized, but to satisfy the compiler,
initialize it to zero.
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If the reserved region of memory has not been setup (most probably
because it has been limited by hardware or virtualisation), don't tell
the user to try and increase the amount of memory reserved for graphics.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223122037.16174-1-chris@chris-wilson.co.ukeviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Some ttm/amd fixes.

* 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux:
  drm/amd/powerplay: fix PSI feature on Polars12.
  drm/amdgpu: refuse to reserve io mem for split VRAM buffers
  drm/ttm: fix use-after-free races in vm fault handling
  drm/amd/amdgpu: post card if there is real hw resetting performed