drm/i915: Track full cdclk state for the logical and actual cdclk frequencies

The current dev_cdclk vs. cdclk vs. atomic_cdclk_freq is quite a mess.
So here I'm introducing the "actual" and "logical" naming for our
cdclk state. "actual" is what we'll bash into the hardware and "logical"
is what everyone should use for state computaion/checking and whatnot.
We'll track both using the intel_cdclk_state as both will need other
differing parameters than just the actual cdclk frequency.

While doing that we can at the same time unify the appearance of the
.modeset_calc_cdclk() implementations a little bit.

v2: Commit dev_priv->cdclk.actual since that already has the
    new state by the time .modeset_commit_cdclk() is called.
v3: s/locical/logical/ and improve the docs a bit

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170120182205.8141-9-ville.syrjala@linux.intel.com

drm/i915: Start moving the cdclk stuff into a distinct state structure

Introduce intel_cdclk state which for now will track the cdclk
frequency, the vco frequency and the reference frequency (not sure we
want the last one, but I put it there anyway). We'll also make the
.get_cdclk() function fill out this state structure rather than
just returning the current cdclk frequency.

One immediate benefit is that calling .get_cdclk() will no longer
clobber state stored under dev_priv unless ex[plicitly told to do
so. Previously it clobbered the vco and reference clocks stored
there on some platforms.

We'll expand the use of this structure to actually precomputing the
state and whatnot later.

v2: Constify intel_cdclk_state_compare()
v3: Document intel_cdclk_state_compare()
v4: Deal with i945gm_get_cdclk()

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170207183345.19763-1-ville.syrjala@linux.intel.com

drm/i915: Pass computed vco to bxt_set_cdclk()

Rather than compute the vco inside bxt_set_cdclk() let's precompute it
outside and pass it in. A small step towards a fully precomputed cdclk
state.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170120182205.8141-7-ville.syrjala@linux.intel.com

drm/i915: Move most cdclk/rawclk related code to intel_cdclk.c

Let's try to shrink intel_display.c a bit by moving the cdclk/rawclk
stuff to a new file. It's all reasonably self contained so we don't
even have to add that many non-static symbols.

We'll also take the opportunity to shuffle around the functions a bit
to get things in a more consistent order based on the platform.

v2: Add kernel-docs (Ander)
v3: Deal with IS_GEN9_BC()
v4: Deal with i945gm_get_cdclk()

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170207183305.19656-1-ville.syrjala@linux.intel.com

drm/i915: Clean up the .get_cdclk() assignment if ladder

Let's clean up the mess we have in the if ladder that assigns the
.get_cdclk() hooks. The grouping of the platforms by the function
results in a thing that's not really legible, so let's do it the
other way around and order the if ladder by platform and duplicate
whatever assignments we need.

To further avoid confusion with the function names let's rename
them to just fixed_<freq>_get_cdclk(). The other option would
be to duplicate the functions entirely but it seems quite
pointless to do that since each one just returns a fixed value.

v2: Deal with i945gm_get_cdclk()

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170207183226.19537-1-ville.syrjala@linux.intel.com

drm/i915: s/get_display_clock_speed/get_cdclk/

Rename the .get_display_clock_speed() hook to .get_cdclk().
.get_cdclk() is more specific (which clock) and it's much
shorter.

v2: Deal with IS_GEN9_BC()
v3: Deal with i945gm_get_display_clock_speed()

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170207183146.19420-1-ville.syrjala@linux.intel.com

drm/i915: Nuke intel_mode_max_pixclk()

ilk_max_pixel_rate() will now give the "correct" pixel rate for all
platforms, so let's rename it to intel_max_pixel_rate() and kill
off intel_mode_max_pixclk().

v2: Fix typo in commit message (Ander)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170120182205.8141-3-ville.syrjala@linux.intel.com

drm/i915: Store the pipe pixel rate in the crtc state

Rather than recomputing the pipe pixel rate on demand everywhere, let's
just stick the precomputed value into the crtc state.

v2: Rebase due to min_pixclk[] code movement
    Document the new pixel_rate struct member (Ander)
    Combine vlv/chv with bdw+ in intel_modeset_readout_hw_state()
v3: Fix typos in commit message (David)

Cc: Ander Conselvan De Oliveira <conselvan2@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126195031.32343-1-ville.syrjala@linux.intel.com

drm/i915/guc: Log significant events at the info level

Currently to establish whether GuC firmware has been loaded or
submission enabled (default DRM log level), one has to detect
the absence of the message saying that the load has been skipped
and infer the opposite.

It is better to log the fact GuC firmware has been loaded and/or
submission enabled explicitly to avoid any guesswork when looking
at the logs.

v2:
  * Log message polish. (Chris)
  * Future proof by reporting found firmware version. (Michal)

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1486457425-32548-1-git-send-email-tvrtko.ursulin@linux.intel.com

drm/i915: Use for_each_power_domain() in i915_power_domain_info()

Macro seems to do exactly the same thing.

Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1486559530-15141-1-git-send-email-joonas.lahtinen@linux.intel.com

drm/i915: Avoid BIT(max) - 1 and use GENMASK(max - 1, 0)

"BIT(max) - 1" will overflow when max = 32, and GCC will complain.
We already have GENMASK for generating the mask, use it!

v2: Majestic off by one spotted (Chris)

Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Always convert incoming exec offsets to non-canonical

We're using non-canonical addresses in drm_mm, and we're making sure that
userspace is using canonical addressing - both in case of softpin
(verifying incoming offset) and when relocating (converting to canonical
when updating offset returned to userspace).
Unfortunately when considering the need for relocations, we're comparing
offset from userspace (in canonical form) with drm_mm node (in
non-canonical form), and as a result, we end up always relocating if our
offsets are in the "problematic" range.
Let's always convert the offsets to avoid the performance impact of
relocations.

Fixes: a5f0edf63bdf ("drm/i915: Avoid writing relocs with addresses in non-canonical form")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Reported-by: Michał Pyrzowski <michal.pyrzowski@intel.com>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170207195559.18798-1-michal.winiarski@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Restore context and pd for ringbuffer submission after reset

Following a reset, the context and page directory registers are lost.
However, the queue of requests that we resubmit after the reset may
depend upon them - the registers are restored from a context image, but
that restore may be inhibited and may simply be absent from the request
if it was in the middle of a sequence using the same context. If we
prime the CCID/PD registers with the first request in the queue (even
for the hung request), we prevent invalid memory access for the
following requests (and continually hung engines).

v2: Magic BIT(8), reserved for future use but still appears unused.
v3: Some commentary on handling innocent vs guilty requests
v4: Add a wait for PD_BASE fetch. The reload appears to be instant on my
Ivybridge, but this bit probably exists for a reason.

Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170207152437.4252-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>

drm/i915: Get correct display clock on 945gm

This is according to Mobile Intel® 945 Express Chipset
Family datasheet.

Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Link: http://patchwork.freedesktop.org/patch/msgid/20170131235026.26003-1-arthur@aheymans.xyz
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Remove overzealous fence warn on runtime suspend

The goal of the WARN was to catch when we are still actively using the
fence as we go into the runtime suspend. However, the reg->pin_count is
too coarse as it does not distinguish between exclusive ownership of the
fence register from activity.

I've not improved on the WARN, nor have we captured this WARN in an
exact igt, but it is showing up regularly in the wild:

[ 1915.935332] WARNING: CPU: 1 PID: 10861 at drivers/gpu/drm/i915/i915_gem.c:2022 i915_gem_runtime_suspend+0x116/0x130 [i915]
[ 1915.935383] WARN_ON(reg->pin_count)[ 1915.935399] Modules linked in:
 snd_hda_intel i915 drm_kms_helper vgem netconsole scsi_transport_iscsi fuse vfat fat x86_pkg_temp_thermal coretemp intel_cstate intel_uncore snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd mei_me mei serio_raw intel_rapl_perf intel_pch_thermal soundcore wmi acpi_pad i2c_algo_bit syscopyarea sysfillrect sysimgblt fb_sys_fops drm r8169 mii video [last unloaded: drm_kms_helper]
[ 1915.935785] CPU: 1 PID: 10861 Comm: kworker/1:0 Tainted: G     U  W       4.9.0-rc5+ #170
[ 1915.935799] Hardware name: LENOVO 80MX/Lenovo E31-80, BIOS DCCN34WW(V2.03) 12/01/2015
[ 1915.935822] Workqueue: pm pm_runtime_work
[ 1915.935845]  ffffc900044fbbf0 ffffffffac3220bc ffffc900044fbc40 0000000000000000
[ 1915.935890]  ffffc900044fbc30 ffffffffac059bcb 000007e6044fbc60 ffff8801626e3198
[ 1915.935937]  ffff8801626e0000 0000000000000002 ffffffffc05e5d4e 0000000000000000
[ 1915.935985] Call Trace:
[ 1915.936013]  [<ffffffffac3220bc>] dump_stack+0x4f/0x73
[ 1915.936038]  [<ffffffffac059bcb>] __warn+0xcb/0xf0
[ 1915.936060]  [<ffffffffac059c4f>] warn_slowpath_fmt+0x5f/0x80
[ 1915.936158]  [<ffffffffc052d916>] i915_gem_runtime_suspend+0x116/0x130 [i915]
[ 1915.936251]  [<ffffffffc04f1c74>] intel_runtime_suspend+0x64/0x280 [i915]
[ 1915.936277]  [<ffffffffac0926f1>] ? dequeue_entity+0x241/0xbc0
[ 1915.936298]  [<ffffffffac36bb85>] pci_pm_runtime_suspend+0x55/0x180
[ 1915.936317]  [<ffffffffac36bb30>] ? pci_pm_runtime_resume+0xa0/0xa0
[ 1915.936339]  [<ffffffffac4514e2>] __rpm_callback+0x32/0x70
[ 1915.936356]  [<ffffffffac451544>] rpm_callback+0x24/0x80
[ 1915.936375]  [<ffffffffac36bb30>] ? pci_pm_runtime_resume+0xa0/0xa0
[ 1915.936392]  [<ffffffffac45222d>] rpm_suspend+0x12d/0x680
[ 1915.936415]  [<ffffffffac69f6d7>] ? _raw_spin_unlock_irq+0x17/0x30
[ 1915.936435]  [<ffffffffac0810b8>] ? finish_task_switch+0x88/0x220
[ 1915.936455]  [<ffffffffac4534bf>] pm_runtime_work+0x6f/0xb0
[ 1915.936477]  [<ffffffffac074353>] process_one_work+0x1f3/0x4d0
[ 1915.936501]  [<ffffffffac074678>] worker_thread+0x48/0x4e0
[ 1915.936523]  [<ffffffffac074630>] ? process_one_work+0x4d0/0x4d0
[ 1915.936542]  [<ffffffffac074630>] ? process_one_work+0x4d0/0x4d0
[ 1915.936559]  [<ffffffffac07a2c9>] kthread+0xd9/0xf0
[ 1915.936580]  [<ffffffffac07a1f0>] ? kthread_park+0x60/0x60
[ 1915.936600]  [<ffffffffac69fe62>] ret_from_fork+0x22/0x30

In the case the register is pinned, it should be present and we will
need to invalidate them to be restored upon resume as we cannot expect
the owner of the pin to call get_fence prior to use after resume.

Fixes: 7c108fd8feac ("drm/i915: Move fence cancellation to runtime suspend")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98804
Reported-by: Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Imre Deak <imre.deak@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.10-rc1+
Link: http://patchwork.freedesktop.org/patch/msgid/20170203125717.8431-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm/i915: Show the current i915_params in debugfs/i915_capabilites

Alongside the hw capabilities, it is useful to know which of those have
been overridden by the user setting module parameters.

v2: Use __always_inline and BUILD_BUG magic

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170206213608.31328-4-chris@chris-wilson.co.uk

drm/i915: Capture module parameters for the GPU error state

They include useful material such as what mode the VM address space is
running in, what submission mode, extra quirks, etc.

v2: Undef the right macro, use type specific pretty printers
v3: Use strcmp(TYPENAME) rather than creating per-type pretty printers
v4: Use __always_inline to force GCC to eliminate the calls to strcmp and
generate the right call to seq_printf for each parameter.
v5: With the strcmp elimination, we can now use BUILD_BUG to ensure
there are no unhandled types, also use __builtin_strcmp to make it look
even more magic.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170206213608.31328-3-chris@chris-wilson.co.uk

drm/i915: Use bool i915_param.alpha_support

The alpha_support module option can only take one of two values, so
assign it to a boolean type. The only advantage is in pretty printing
via /sys/module/i915/parameters/alpha_support and elsewhere.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170206213608.31328-2-chris@chris-wilson.co.uk

drm/i915: Generate i915_params {} using a macro

I want to print the struct from the error state and so would like to use
the existing struct definition as the template ala DEV_INFO*

v2: Use MEMBER() rather than p().

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170206213608.31328-1-chris@chris-wilson.co.uk

drm/i915: Avoid unguarded reads from the request pointer

In commit 86aa7e760a67 ("drm/i915: Assert that the context-switch
completion matches our context") I added a read to the irq tasklet
handler that compared the on-chip status with that of our sw tracking,
using an unguarded read of the request pointer to get the context and
beyond. Whilst we hold a reference to the request, we do not hold
anything on the context and if we are unlucky it may be reaped from a
second thread retiring the request (since it may retire the request as
soon as the breadcrumb is complete, even before we finish processing the
context switch) as we try to read from the context pointer.

Avoid the racy read from underneath the request by storing the expected
result in the execlist_port[].

v2: Include commentary about port[].request being unprotected.

Fixes: 86aa7e760a67 ("drm/i915: Assert that the context-switch completion matches our context")
Reported-by: Mika Kuoppala <mika.kuoppala@intel.com>
Testcase: igt/gem_ctx_create
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170206170502.30944-2-chris@chris-wilson.co.uk

drm/i915: Mark the end of intel_ring_begin() and check in intel_ring_advance()

It is required that the caller declare the exact number of dwords they
wish to write into the ring. This is required for two reasons, we need
to allocate sufficient space for the entire command packet and we need
to be sure that the contents are completely written to avoid executing
stale data. The current interface requires for any bug to be caught in
review, the reader has to carefully count the number of
intel_ring_emit() between intel_ring_begin() and intel_ring_advance().
If we record the end of the packet of each intel_ring_begin() we can
also have CI check for us.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170206170502.30944-1-chris@chris-wilson.co.uk

drm/i915: Let execlist_update_context() cover !FULL_PPGTT mode.

execlist_update_context() will try to update PDPs in a context before a
ELSP submission only for full PPGTT mode, while PDPs was populated during
context initialization. Now the latter code path is removed. Let
execlist_update_context() also cover !FULL_PPGTT mode.

Fixes: 34869776c76b ("drm/i915: check ppgtt validity when init reg state")
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhiyuan Lv <zhiyuan.lv@intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1486377436-15380-1-git-send-email-zhi.a.wang@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915/gen5+, pch: Enable hotplug detection early

To be consistent with the recent change to enable hotplug detection
early on GEN9 platforms do the same on all non-GMCH platforms starting
from GEN5. On GMCH platforms enabling detection without interrupts isn't
trivial, since AUX and HPD have a shared interrupt line. It could be
done there too by using a SW interrupt mask, but I punt on that for now.

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485509961-9010-5-git-send-email-imre.deak@intel.com

drm/i915/lspcon: Remove DPCD compare based resume time workaround

This effectively reverts
commit 489375c866c111f16cea93b2467ebe59c9022cc7
Author: Imre Deak <imre.deak@intel.com>
Date:   Mon Oct 24 19:33:31 2016 +0300

    drm/i915/lspcon: Add workaround for resuming in PCON mode

The workaround was added without considering that HPD is low during
the failed AUX transfers the WA fixed. Since the previous patch we
wait for HPD to get asserted. My tests also show that this happens
_after_ the DPCD reads start to return correct values. This
suggests that we don't need this WA any more, let's try to remove
it to reduce the clutter.

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485509961-9010-4-git-send-email-imre.deak@intel.com

drm/i915/lspcon: Fix resume time initialization due to unasserted HPD

During system resume time initialization the HPD level on LSPCON ports
can stay low for an extended amount of time, leading to failed AUX
transfers and LSPCON initialization. Fix this by waiting for HPD to get
asserted.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99178
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org> # v4.9+
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485509961-9010-3-git-send-email-imre.deak@intel.com

drm/i915/gen9+: Enable hotplug detection early

For LSPCON resume time initialization we need to sample the
corresponding pin's HPD level, but this is only available when HPD
detection is enabled. Currently we enable detection only when enabling
HPD interrupts which is too late, so bring the enabling of detection
earlier.

This is needed by the next patch.

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org> # v4.9+
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485509961-9010-2-git-send-email-imre.deak@intel.com

drm/i915: Use page coloring to provide the guard page at the end of the GTT

As we now mark the reserved hole (drm_mm.head_node) with the special
UNEVICTABLE color, we can use the page coloring to avoid prefetching of
the CS beyond the end of the GTT.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170206084547.27921-3-chris@chris-wilson.co.uk
Reviewed-by: Matthew Auld <matthew.auld@intel.com>

drm/i915: Assign I915_COLOR_UNEVICTABLE to the address space head_node

The drm_mm range manager (within i915_address_space) uses a special
drm_mm_node that excludes the unavailable range (beyond the end of the
drm_mm). However, we play games with the global GTT to use the head_node
to exclude the tail page but tell ourselves that the whole range is
available. This causes an issue when we try to evict using the full
range of the global GTT which is wider than the drm_mm, resulting in
complete confusion and catastrophe. One way to resolve this would be to
use a reserved node to exclude the guard page, or we can treat the
drm_mm's head_node as our guard page and assign it the appropriate
colour.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170206084547.27921-2-chris@chris-wilson.co.uk
Reviewed-by: Matthew Auld <matthew.auld@intel.com>

drm/i915: Manipulate the Global GTT size using I915_GTT_PAGE_SIZE

I incorrectly converted the exclusion of the last 4096 bytes (that avoids
any potential prefetching past the end of the GTT) to PAGE_SIZE and not
to I915_GTT_PAGE_SIZE as it should be.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170206084547.27921-1-chris@chris-wilson.co.uk
Reviewed-by: Matthew Auld <matthew.auld@intel.com>

drm/i915: Print execlists restart after reset

After resetting, show the requests that each engine restarts from in the
debug log.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170204110519.7645-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>

drm/i915: Drain the freed state from the tail of the next commit

If we have any residual freed atomic state from earlier commits, flush
the freed list after performing the current modeset. This prevents the
freed list from ever-growing if userspace manages to starve the kernel
threads (i.e. we are never able to run our free state worker and
eventually the system may even oom).

Fixes: eb955eee27d9 ("drm/i915: Move atomic state free from out of fence release")
Testcase: igt/kms_cursor/legacy/all-pipes-single-bo
Reported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170202204741.18231-1-chris@chris-wilson.co.uk
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm/i915: Update DRIVER_DATE to 20170206

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

drm/i915: refactor register fw read/write macros for recent GENs

The only difference for the more recent of those macros is the version
of the *_reg_<read/write>_fw_domains function. Passing the function
prefix in allows us to re-use the same macro to generate functions for
different GENs and will make it easier to add new accessors in the future

Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1486171409-21542-1-git-send-email-daniele.ceraolospurio@intel.com
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: fix pm refcounting on fence error in execbuf

Fences are creted/checked before the pm ref is taken, so if we jump to
pre_mutex_err we will uncorrectly call intel_runtime_pm_put.

v2: Massage unwind error paths

Fixes: fec0445caa27 (drm/i915: Support explicit fencing for execbuf)
Testcase: igt/gem_exec_params
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1486161930-11764-1-git-send-email-daniele.ceraolospurio@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Allow large objects to be tiled on gen2/3

We now have partial VMA support to break large objects into fence sized
regions and no longer have to restrict tiling to small objects on gen2/3

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170203115036.24743-2-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm/i915: Tidy the tail of i915_tiling_ok()

The current tail breaks the pattern of if (check) return false, which
can catch the reader out. If we move the gen2/3 power-of-two test into
the earlier gen2/3 branch, we can eliminate the contrary tail.

Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170203115036.24743-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>

drm/i915: Reject set-tiling-ioctl with stride==0 and a tiling mode

In commit 957870f93412 ("drm/i915: Split out i915_gem_object_set_tiling()"),
I swapped an alignment check for IS_ALIGNED and in the process removed
the less-than check. That check turns out to be important as it was the
only rejection for stride == 0. Tvrtko did spot it, but I was
overconfident in the IS_ALIGNED() conversion.

Fixes: 957870f93412 ("drm/i915: Split out i915_gem_object_set_tiling()")
Testcase: igt/gem_tiling_max_stride
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170203105652.27819-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

drm/i915/bxt: Add MST support when do DPLL calculation

Add the missing INTEL_OUTPUT_DP_MST case in bxt_get_dpll()
to correctly initialize the crtc_state and port plls when
link training a DP MST monitor on BXT/APL devices.

Fixes: a277ca7dc01d ("drm/i915: Split bxt_ddi_pll_select()")
Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99572
Reviewed-by: Cooper Chiou <cooper.chiou@intel.com>
Reviewed-by: Gary C Wang <gary.c.wang@intel.com>
Reviewed-by: Ciobanu, Nathan D <nathan.d.ciobanu@intel.com>
Reviewed-by: Herbert, Marc <marc.herbert@intel.com>
Reviewed-by: Bride, Jim <jim.bride@intel.com>
Reviewed-by: Navare, Manasi D <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: <stable@vger.kernel.org> # v4.9+
Signed-off-by: Lee, Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1486096329-6255-1-git-send-email-shawn.c.lee@intel.com

drm/i915: remove 512GB allocation warning

Now that we have selftests in place exercising truly huge allocations
we will start to hit the 512GB warning, so now seems like a good time to
remove this user-triggerable WARN.

Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1486047300-13198-1-git-send-email-matthew.auld@intel.com
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Recreate internal objects with single page segments if dmar fails

If we fail to dma-map the object, the most common cause is lack of space
inside the SW-IOTLB due to fragmentation. If we recreate the_sg_table
using segments of PAGE_SIZE (and single page allocations), we may succeed
in remapping the scatterlist.

First became a significant problem for the mock selftests after commit
5584f1b1d73e ("drm/i915: fix i915 running as dom0 under Xen") increased
the max_order.

Fixes: 920cf4194954 ("drm/i915: Introduce an internal allocator for disposable private objects")
Fixes: 5584f1b1d73e ("drm/i915: fix i915 running as dom0 under Xen")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170202132721.12711-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.10-rc1+

drm/i915: don't warn about Skylake CPU - KabyPoint PCH combo

Apparently there are machines out there with Skylake CPU and KabyPoint
PCH. Judging from our driver code, there doesn't seem to be any code
paths that would do anything different between SunrisePoint and
KabyPoint PCHs, so it would seem okay to accept the combo without
warnings.

Fixes: 22dea0be50b2 ("drm/i915: Introduce Kabypoint PCH for Kabylake H/DT.")
References: https://lists.freedesktop.org/archives/intel-gfx/2017-February/118611.html
Reported-by: Rainer Koenig <Rainer.Koenig@ts.fujitsu.com>
Cc: Rainer Koenig <Rainer.Koenig@ts.fujitsu.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: <stable@vger.kernel.org> # v4.8+
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485956769-26015-1-git-send-email-jani.nikula@intel.com

drm/i915: Build DRM range manager selftests for CI

Build the struct drm_mm selftests so that we can trivially run them
within our CI.

"Enable debug, become developer." - Joonas Lahtinen

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125101102.9010-3-chris@chris-wilson.co.uk

drm/i915: fix i915 running as dom0 under Xen

Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
disposable private objects") introduced a regression for the kernel
running as Xen dom0: when switching to graphics mode a GPU HANG
occurred.

Reason seems to be a missing adaption similar to that done in
commit 7453c549f5f648 ("swiotlb: Export swiotlb_max_segment to users")
to i915_gem_object_get_pages_internal().

So limit the maximum page order to be used according to the maximum
swiotlb segment size instead to the complete swiotlb size.

Fixes: 920cf4194954 ("drm/i915: Introduce an internal allocator for disposable private objects")
Signed-off-by: Juergen Gross <jgross@suse.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170202094711.939-1-jgross@suse.com
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.10-rc1+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Fix POWER_DOMAIN_AUDIO refcounting.

If the crtc was brought up with audio before the driver loads,
then crtc_disable will remove a refcount to audio that doesn't exist
before.

Fortunately we already set power domains on readout, so we can just add
the power domain handling to get_crtc_power_domains, which will update
the power domains correctly in all cases.

This was found when testing module reload on CI with the crtc enabled,
which resulted in the following warn after module reload + modeset:

[   24.197041] ------------[ cut here ]------------
[   24.197075] WARNING: CPU: 0 PID: 99 at drivers/gpu/drm/i915/intel_runtime_pm.c:1790 intel_display_power_put+0x134/0x140 [i915]
[   24.197076] Use count on domain AUDIO is already zero
[   24.197098] CPU: 0 PID: 99 Comm: kworker/u8:2 Not tainted 4.9.0-CI-Trybot_393+ #1
[   24.197099] Hardware name:                  /NUC6i5SYB, BIOS SYSKLi35.86A.0042.2016.0409.1246 04/09/2016
[   24.197102] Workqueue: events_unbound async_run_entry_fn
[   24.197105]  ffffc900003c7688 ffffffff81435b35 ffffc900003c76d8 0000000000000000
[   24.197107]  ffffc900003c76c8 ffffffff8107e4d6 000006fe5dc36f28 ffff88025dc30054
[   24.197109]  ffff88025dc36f28 ffff88025dc30000 ffff88025dc30000 0000000000000015
[   24.197110] Call Trace:
[   24.197113]  [<ffffffff81435b35>] dump_stack+0x67/0x92
[   24.197116]  [<ffffffff8107e4d6>] __warn+0xc6/0xe0
[   24.197118]  [<ffffffff8107e53a>] warn_slowpath_fmt+0x4a/0x50
[   24.197149]  [<ffffffffa039b4b4>] intel_display_power_put+0x134/0x140 [i915]
[   24.197187]  [<ffffffffa04217dd>] intel_disable_ddi+0x4d/0x80 [i915]
[   24.197223]  [<ffffffffa03f388f>] intel_encoders_disable.isra.74+0x7f/0x90 [i915]
[   24.197257]  [<ffffffffa03f6c05>] haswell_crtc_disable+0x55/0x170 [i915]
[   24.197292]  [<ffffffffa03fec88>] intel_atomic_commit_tail+0x108/0xfd0 [i915]
[   24.197295]  [<ffffffff810d47c6>] ? __lock_is_held+0x66/0x90
[   24.197330]  [<ffffffffa03fff79>] intel_atomic_commit+0x429/0x560 [i915]
[   24.197332]  [<ffffffff81570186>] ?drm_atomic_add_affected_connectors+0x56/0xf0
[   24.197334]  [<ffffffff8156f726>] drm_atomic_commit+0x46/0x50
[   24.197336]  [<ffffffff81553f87>] restore_fbdev_mode+0x147/0x270
[   24.197337]  [<ffffffff81555bee>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2e/0x70
[   24.197339]  [<ffffffff81555aa8>] drm_fb_helper_set_par+0x28/0x50
[   24.197374]  [<ffffffffa041c7d3>] intel_fbdev_set_par+0x13/0x70 [i915]
[   24.197376]  [<ffffffff8149e07a>] fbcon_init+0x57a/0x600
[   24.197379]  [<ffffffff81514b71>] visual_init+0xd1/0x130
[   24.197381]  [<ffffffff8151603c>] do_bind_con_driver+0x1bc/0x3a0
[   24.197384]  [<ffffffff81516521>] do_take_over_console+0x111/0x180
[   24.197386]  [<ffffffff8149e152>] do_fbcon_takeover+0x52/0xb0
[   24.197387]  [<ffffffff814a12c3>] fbcon_event_notify+0x723/0x850
[   24.197390]  [<ffffffff810a4830>] ?__blocking_notifier_call_chain+0x30/0x70
[   24.197392]  [<ffffffff810a44a4>] notifier_call_chain+0x34/0xa0
[   24.197394]  [<ffffffff810a4848>] __blocking_notifier_call_chain+0x48/0x70
[   24.197397]  [<ffffffff810a4881>] blocking_notifier_call_chain+0x11/0x20
[   24.197398]  [<ffffffff814a4556>] fb_notifier_call_chain+0x16/0x20
[   24.197400]  [<ffffffff814a678c>] register_framebuffer+0x24c/0x330
[   24.197402]  [<ffffffff815558d9>] drm_fb_helper_initial_config+0x219/0x3c0
[   24.197436]  [<ffffffffa041d373>] intel_fbdev_initial_config+0x13/0x30 [i915]
[   24.197438]  [<ffffffff810a5d44>] async_run_entry_fn+0x34/0x140
[   24.197440]  [<ffffffff8109c26c>] process_one_work+0x1ec/0x6b0
[   24.197442]  [<ffffffff8109c1e6>] ? process_one_work+0x166/0x6b0
[   24.197445]  [<ffffffff8109c779>] worker_thread+0x49/0x490
[   24.197447]  [<ffffffff8109c730>] ? process_one_work+0x6b0/0x6b0
[   24.197448]  [<ffffffff810a2a9b>] kthread+0xeb/0x110
[   24.197451]  [<ffffffff810a29b0>] ? kthread_park+0x60/0x60
[   24.197453]  [<ffffffff818241a7>] ret_from_fork+0x27/0x40
[   24.197476] ---[ end trace bda64b683b8e8162 ]---

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1481812185-19098-3-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Disable all crtcs during driver unload, v2.

We may keep the crtc's enabled when userspace unsets all framebuffers but
keeps the crtc active. This exposes a WARN in fbc_global disable, and
a lot of bugs in our hardware readout code. Solve this by disabling
all crtc's for now.

Changes since v1:
- Use lock_all_ctx instead of lock_all.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1481812185-19098-4-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/execlists: Add interrupt-pending check to intel_execlists_idle()

Primarily this serves as a sanity check that the bit has been cleared
before we suspend (and hasn't reappeared after resume).

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Tvrtko Ursulin <tursulin@ursulin.net>
Link: http://patchwork.freedesktop.org/patch/msgid/20170201131222.11882-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>

drm/i915/execlists: Skip resetting RING_CONTEXT_STATUS_PTR

As we now flag when the GPU signals a context-switch and do not read the
status register before we see that signal, we do not have to ensure that
it is cleared upon reset (and can leave it to the GPU to reset it from
the power context).

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Tvrtko Ursulin <tursulin@ursulin.net>
Link: http://patchwork.freedesktop.org/patch/msgid/20170201125338.12932-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>

drm/i915: Add MIPI_IO WA and program DSI regulators

Enable MIPI IO WA for BXT DSI as per bspec and
program the DSI regulators.

v2: Moved IO enable to pre-enable as per Mika's
review comments. Also reused the existing register
definition for BXT_P_CR_GT_DISP_PWRON.

v3: Added Programming the DSI regulators as per disable/enable
sequences.

v4: Restricting regulator changes to BXT as suggested by
Jani/Mika

v5: Removed redundant read/modify for regulator register as
per Jani's comment. Maintain enable/disable symmetry as per spec.

Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Acked-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485353603-11260-1-git-send-email-vidya.srinivas@intel.com

drm/i915: Flush untouched framebuffers before display on !llc

On a non-llc system, the objects are created with .cache_level =
CACHE_NONE and so the transition to uncached for scanout is a no-op.
However, if the object was never written to, it will still be in the CPU
domain (having been zeroed out by shmemfs). Those cachelines need to be
flushed prior to display.

Reported-and-tested-by: Vito Caputo
Fixes: a6a7cc4b7db6 ("drm/i915: Always flush the dirty CPU cache when pinning the scanout")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.10-rc1+
Link: http://patchwork.freedesktop.org/patch/msgid/20170109111932.6342-1-chris@chris-wilson.co.uk
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queued

Chris Wilson wants the new fence tracepoint added in

commit 8c96c678011eeb1676da18f203e90dea7e0d69d2
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jan 24 11:57:58 2017 +0000

    dma/fence: Export enable-signaling tracepoint for emission by drivers

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

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

adding runtime PM support to MIC driver, and including some
cleanups - especially using atomic helper functions
instead of specific ones - and fixups.

* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
  drm/exynos: g2d: prevent integer overflow in
  drm/exynos: fix a timeout loop
  drm/exynos: use atomic helper commit
  drm/exynos: remove unnecessary codes
  drm/exynos: mic: Add runtime PM support
  drm/exynos: Stop using drm_framebuffer_unregister_private
  drm/exynos: mic: Fix parse_dt function
  drm/exynos: mic: Add mode_set callback function

Merge tag 'sunxi-drm-for-4.11' of https://git./linux/kernel/git/mripard/linux into drm-next

Allwinner DRM changes for 4.11

Just one minor fix.

* tag 'sunxi-drm-for-4.11' of https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
  drm/sun4i: Fix a return value in case of error

Merge branch 'drm-vmwgfx-next' of git://people.freedesktop.org/~syeh/repos_linux into drm-next

This is to address what we've discussed, moving some of the minor changes
into a drm-next request.

* 'drm-vmwgfx-next' of git://people.freedesktop.org/~syeh/repos_linux:
  drm/vmwgfx: Use kmemdup instead of kmalloc and memcpy
  drm/vmwgfx: Fix depth input into drm_mode_legacy_fb_format
  drm/vmwgfx: Fix a potential integer overflow
  drm/vmwgfx: Clear an uninitialized struct member
  drm/vmwgfx: Annotate ignored return values
  drm/vmwgfx: Clear uninitialized fields of a parameter

Merge branch 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux into drm-next

This is the main feature pull for radeon and amdgpu for 4.11.  Highlights:
- Power and clockgating improvements
- Preliminary SR-IOV support
- ttm buffer priority support
- ttm eviction fixes
- Removal of the ttm lru callbacks
- Remove SI DPM quirks due to MC firmware issues
- Handle VFCT with multiple vbioses
- Powerplay improvements
- Lots of driver cleanups

* 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux: (120 commits)
  drm/amdgpu: fix amdgpu_bo_va_mapping flags
  drm/amdgpu: access stolen VRAM directly on CZ (v2)
  drm/amdgpu: access stolen VRAM directly on KV/KB (v2)
  drm/amdgpu: fix kernel panic when dpm disabled on Kv.
  drm/amdgpu: fix dpm bug on Kv.
  drm/amd/powerplay: fix regresstion issue can't set manual dpm mode.
  drm/amdgpu: handle vfct with multiple vbios images
  drm/radeon: handle vfct with multiple vbios images
  drm/amdgpu: move misc si headers into amdgpu
  drm/amdgpu: remove unused header si_reg.h
  drm/radeon: drop pitcairn dpm quirks
  drm/amdgpu: drop pitcairn dpm quirks
  drm: radeon: radeon_ttm: Handle return NULL error from ioremap_nocache
  drm/amd/amdgpu/amdgpu_ttm: Handle return NULL error from ioremap_nocache
  drm/amdgpu: add new virtual display ID
  drm/amd/amdgpu: remove the uncessary parameter for ib scheduler
  drm/amdgpu: Bring bo creation in line with radeon driver (v2)
  drm/amd/powerplay: fix misspelling in header guard
  drm/ttm: revert "add optional LRU removal callback v2"
  drm/ttm: revert "implement LRU add callbacks v2"
  ...

Merge tag 'drm-misc-next-2017-01-30' of git://anongit.freedesktop.org/git/drm-misc into drm-next

Another round of -misc stuff:
- Noralf debugfs cleanup cleanup (not yet everything, some more driver
  patches awaiting acks).
- More doc work.
- edid/infoframe fixes from Ville.
- misc 1-patch fixes all over, as usual

Noralf needs this for his tinydrm pull request.

* tag 'drm-misc-next-2017-01-30' of git://anongit.freedesktop.org/git/drm-misc: (48 commits)
  drm/vc4: Remove vc4_debugfs_cleanup()
  dma/fence: Export enable-signaling tracepoint for emission by drivers
  drm/tilcdc: Remove tilcdc_debugfs_cleanup()
  drm/tegra: Remove tegra_debugfs_cleanup()
  drm/sti: Remove drm_debugfs_remove_files() calls
  drm/radeon: Remove drm_debugfs_remove_files() call
  drm/omap: Remove omap_debugfs_cleanup()
  drm/hdlcd: Remove hdlcd_debugfs_cleanup()
  drm/etnaviv: Remove etnaviv_debugfs_cleanup()
  drm/etnaviv: allow build with COMPILE_TEST
  drm/amd/amdgpu: Remove drm_debugfs_remove_files() call
  drm/prime: Clarify DMA-BUF/GEM Object lifetime
  drm/ttm: Make sure BOs being swapped out are cacheable
  drm/atomic: Remove drm_atomic_debugfs_cleanup()
  drm: drm_minor_register(): Clean up debugfs on failure
  drm: debugfs: Remove all files automatically on cleanup
  drm/fourcc: add vivante tiled layout format modifiers
  drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F
  drm/edid: Set AVI infoframe Q even when QS=0
  drm/edid: Introduce drm_hdmi_avi_infoframe_quant_range()
  ...

Merge tag 'drm/atmel-hlcdc/for-4.11' of git://git./linux/kernel/git/bbrezillon/linux into drm-next

Contains a single patch to create the fbdev at driver's registration
time instead of waiting for the connector status change.

* tag 'drm/atmel-hlcdc/for-4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/bbrezillon/linux:
  drm/atmel-hlcdc: Rework the fbdev creation logic

Merge tag 'zxdrm-4.11' of git://git./linux/kernel/git/shawnguo/linux into drm-next

ZTE DRM driver updates for 4.11:
 - Add missing selection of VIDEOMODE_HELPERS in Kconfig, since ZTE DRM
   driver uses drm_display_mode_to_videomode().
 - Enable HDMI audio support through SPDIF interface based on generic
   hdmi-audio-codec driver.
 - Enable VOU VL (Video Layer) to support overlay plane with scaling
   function.
 - Refine zx_vou driver a bit and then add TV Encoder output device
   support.

[airlied: fixup plane format change]

* tag 'zxdrm-4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
  drm: zte: add tvenc driver support
  dt: add bindings for ZTE tvenc device
  drm: zte: add function to configure vou_ctrl dividers
  drm: zte: move struct vou_inf into zx_vou driver
  drm: zte: add interlace mode support
  drm: zte: add overlay plane support
  drm: zte: add .atomic_disable hook to disable graphic layer
  drm: zte: make zx_plane accessible from zx_vou driver
  drm: zte: support hdmi audio through spdif
  drm: zte: select VIDEOMODE_HELPERS in Kconfig

Merge branch 'drm-intel-next' of git://anongit.freedesktop.org/git/drm-intel into drm-next

Updated pull request after I pulled first time :)

* 'drm-intel-next' of git://anongit.freedesktop.org/git/drm-intel:
  drm/i915: Pevent copying uninitialised garbage into vma->ggtt_view

Merge branch 'for-upstream/mali-dp' of git://linux-arm.org/linux-ld into drm-next

Hope I'm not too late before the cutoff for the v4.11 with these patches.
Mostly an asorted set of fixes that we have discovered while playing with
the code and preparing for the next set of features.

* 'for-upstream/mali-dp' of git://linux-arm.org/linux-ld:
  drm: mali-dp: fix stride setting for multi-plane formats
  drm: mali-dp: Add plane offset to the plane's physical start address register
  drm: mali-dp: Check for sufficient address space
  drm: mali-dp: Check hw version matches device-tree
  drm: mali-dp: Rename malidp_input_format to malidp_pixel_format
  drm: mali-dp: fix Lx_CONTROL register fields clobber
  drm: mali-dp: Fix transposed horizontal/vertical flip
  drm: mali-dp: Fix destination size handling when rotating
  drm: mali-dp: Don't force source size == crtc size
  drm: mali-dp: Check more use cases in the plane's ->atomic_check()
  drm: malidp: Remove event_list member from struct malidp_drm
  drm/arm/malidp: Fix possible dereference of NULL

drm/i915: Sanity check the computed size and base of stolen memory

Just do a quick check that the stolen memory address range doesn't
overflow our chosen integer type.

v2: Add add_overflows() to utils with the promise that gcc7 can do this
better than C and then maybe it will have a proper definition in core.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170130134721.5159-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm/i915: Treat stolen memory as DMA addresses

The conversion of stolen to use phys_addr_t (from essentially u32)
sparked an interesting discussion. We treat stolen memory as only
accessible from the GPU (the DMA device) - an attempt to use it from the
CPU will generate a MCE on gen6 onwards, although it is in theory a
physical address that can be dereferenced from the CPU as demonstrated
by earlier generations. As such, using phys_addr_t has the wrong
connotations and as we pass the address into the DMA device via
dma_addr_t (through the scatterlists used to program the GTT entries),
we should treat it as dma_addr_t throughout.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170127165531.28135-1-chris@chris-wilson.co.uk
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>

drm/i915: Be defensive when cleaning up i915_gem_internal pages

If we abort the i915_gem_internal get_pages, we mark the failing sg as
the last. However, that means we iterate upto and including the failing
sg element and results in us trying to free the unallocated sg_page().

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170131104630.3074-1-chris@chris-wilson.co.uk
Reviewed-by: Matthew Auld <matthew.auld@intel.com>

drm/i915: clean up unused vgpu_read/write

Having converted the force_wake_get/_put routines for a vGPU to be no-op,
we can use the common mmio accessors and remove our specialised routines
that simply skipped the calls to control force_wake.

Signed-off-by: Weinan Li <weinan.z.li@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1485408228-12932-1-git-send-email-weinan.z.li@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: noop forcewake get/put when vgpu activated

For a virtualized GPU, the host maintains the forcewake state on the real
device. As we don't control forcewake ourselves, we can simply set
force_wake_get() and force_wake_put() to be no-ops. By setting the vfuncs,
we adjust both the manual control of forcewake and around the mmio
accessors (making our vgpu specific mmio routines redundant and to be
removed in the next patch).

Signed-off-by: Weinan Li <weinan.z.li@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1485408013-12780-1-git-send-email-weinan.z.li@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Record more information about the hanging contexts

Include extra information such as the user_handle and hw_id so that
userspace can identify which of their contexts hung, useful if they are
performing self-diagnositics.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170129092433.10483-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>

drm/i915: Add early BXT sdv to the list of preproduction machines

Extend intel_detect_preproduction_hw() to include BXT A and B steppings.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170130104458.2653-3-chris@chris-wilson.co.uk
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm/i915: Mark the kernel as tainted if we fail the preproduction check

Preproduction sdv are not supported beyond the release of production
hardware, and continued use is ill-advised. Mark the kernel as tainted
to reinforce the error.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170130104458.2653-2-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm/i915: Make intel_detect_preproduction_hw easier to extend

As we add new generations, we should keep detecting new pre-production
system development platforms that were temporarily enabled to facilitate
initial development and now superseded by production systems. To make
it easier to add more platforms, split the if into a series of logical
operations.

v2: s/sdv/pre/ - not all system development vehicles are for
preproduction usage.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170130104458.2653-1-chris@chris-wilson.co.uk
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm/exynos: g2d: prevent integer overflow in

The size computations done in the ioctl function use an integer.
If userspace submits a request with req->cmd_nr or req->cmd_buf_nr
set to INT_MAX, the integer computations overflow later, leading
to potential (kernel) memory corruption.

Prevent this issue by enforcing a limit on the number of submitted
commands, so that we have enough headroom later for the size
computations.

Note that this change has no impact on the currently available
users in userspace, like e.g. libdrm/exynos.

While at it, also make a comment about the size computation more
detailed.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos: fix a timeout loop

We were trying to print an error message if we timed out here, but the
loop actually ends with "tries" set to UINT_MAX and not zero.  Fix this
by changing from tries-- to --tries.

A for loop would actually be the most natural way to do this.  My fix
means we only loop 99 times instead of 100 but that's probably ok.

Fixes: a696394c5224 ('drm/exynos: mixer: simplify loop in vp_win_reset()')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos: use atomic helper commit

This patch replaces specific atomic commit function
with atomic helper commit one.

For this, it removes existing atomic commit function
and relevant code specific to Exynos DRM and makes
atomic helper commit to be used instead.

Below are changes for the use of atomic helper commit:
- add atomic_commit_tail callback specific to Exynos DRM
  . default implemention of atomic helper doesn't mesh well
    with runtime PM so the device driver which supports runtime
    PM should call drm_atomic_helper_commit_modeset_enables function
    prior to drm_atomic_helper_commit_planes function call.
    atomic_commit_tail callback implements this call ordering.
- allow plane commit only in case that CRTC device is enabled.
  . for this, it calls atomic_helper_commit_planes function
    with DRM_PLANE_COMMIT_ACTIVE_ONLY flag in atomic_commit_tail callback.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com>

drm/exynos: remove unnecessary codes

This patch removes exynos_drm_crtc_cancel_page_flip call
when drm is closed because at that time, events will be released
by drm_events_release function.

Changelog v1:
- remove exynos_drm_crtc_cancel_page_flip function also because
  this funtion isn't used anymore.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>

drm/exynos: mic: Add runtime PM support

This patch adds runtime support calls to notify device core when MIC
device is really in use. Runtime PM is implemented by enabling and
disabling clocks like in other Exynos DRM subdrivers. Adding runtime
PM support is needed to let power domain with this device to be turned
off when display is not used.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos: Stop using drm_framebuffer_unregister_private

This is the deprecated function for when you embedded the framebuffer
somewhere else (which breaks refcounting). But exynos is using
drm_framebuffer_remove and a free-standing fb, so this is rendundant.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos: mic: Fix parse_dt function

The OF graph is not necessary because the panel is a child of
dsi. therefore, the parse_dt function of dsi does not need to
check the remote_node connected to the panel. and the whole
parse_dt function should be refactored later.

Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/exynos: mic: Add mode_set callback function

Before applying the patch, used the of_get_videomode function to
parse the display-timings in the panel which is the child driver
of dsi in the devicetree. this is wrong. So removed the
of_get_videomode and fixed to get videomode struct through
mode_set callback function.

Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

drm/i915: use variadic macros and arrays to choose port/pipe based registers

This allows the use of more than 3 ports/pipes/whatever without tricks,
even if the register offsets are not evenly spaced.

There's the risk of out of bounds access if we're not careful; currently
that would "just" lead to the wrong register offset being used. It might
be possible to add build bug ons for build time constant indexing.

We already have ports defined up to E, not sure if we might have bugs
related to them and the current _PORT3() macro.

   text    data     bss     dec     hex filename
1239868   46199    4096 1290163  13afb3 drivers/gpu/drm/i915/i915.ko
1238828   46199    4096 1289123  13aba3 drivers/gpu/drm/i915/i915.ko

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Tvrtko Ursulin <tursulin@ursulin.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485532626-20923-1-git-send-email-jani.nikula@intel.com

drm/i915: Create context desc template when context is created

Move the invariant parts of context desc setup from execlist init
to context creation. This is advantageous when we need to
create different templates based on the context parametrization,
ie. for svm capable contexts.

v2: s/create/default, remove engine->ctx_desc_template

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485522189-31984-1-git-send-email-mika.kuoppala@intel.com

drm/atmel-hlcdc: Rework the fbdev creation logic

Now that we wait for DRM panels to be available before registering the
DRM device (returning -EPROBE_DEFER if the panel has not been probed
yet), we no longer need to put the fbdev creation code in
->output_poll_changed().

This removes the 10 secs delay between DRM dev registration and fbdev
creation (polling period = 10 seconds).

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: Alex Vazquez <avazquez.dev@gmail.com>

drm/vc4: Remove vc4_debugfs_cleanup()

drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so the drm_driver.debugfs_cleanup callback is not
needed.

Cc: eric@anholt.net
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-17-noralf@tronnes.org

drm/i915/glk: Program pipe gamma and degamma tables

The gamma tables in Geminilake were changed. There is no split-gamma
mode. Instead, there is a dedicated degamma table that is enabled
whenever pipe CSC is enabled.

The dedicated gamma table has 16 bit precision but doesn't support
separate channels. Since that doesn't match the per-channel format of
the degamma LUT property, for now only a linear table is loaded and the
property ignored.

v2: Remove empty line. (Ville)
    Reuse broadwell code. (Ville)

v3: Don't write PIPE_CSC_MODE. (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170127090230.20302-1-ander.conselvan.de.oliveira@intel.com

drm/i915: Split broadwell_load_luts() into smaller functions

Split the logic for progamming each LUT out of broadwell_load_luts(), so
we can reuse part of it for geminilake.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485429865-10687-4-git-send-email-ander.conselvan.de.oliveira@intel.com

drm/i915/glk: Plane color correction register changes

In Geminilake, the bits for enabling pipe csc, pipe gamma and plane
gamma moved to a new register. So update the plane update functions
to set the right bits.

Pipe CSC is kept disabled though, since enabling that also enables the
dedicated degamma table, and that is not properly programmed yet,
leading to a black screen.

v2: Use plane_id. (Ville)
    Remove unnecessary variable. (Ville)
    Keep registers in offset order. (Ville)
    Don't set plane gamma disable twice. (Ander)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ander Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485429865-10687-3-git-send-email-ander.conselvan.de.oliveira@intel.com

drm/i915: Disable plane gamma in SKL+ sprite planes

The plane gamma tables are never programmed, so just disable it, like it
is done for the primary plane.

Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485429865-10687-2-git-send-email-ander.conselvan.de.oliveira@intel.com

drm/i915/glk: Turn on workarounds that apply to Geminilake too

Apply workarounds to Geminilake, and annotate those that are applied
unconditionally when they apply to GLK based on the workaround database.

v2: Fix commit message typos. (David)
v3: Rebase.
Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485422218-9102-1-git-send-email-ander.conselvan.de.oliveira@intel.com

drm: zte: add tvenc driver support

It adds the TV Encoder driver to support video output in PAL and NTSC
format.  The driver uses syscon/regmap interface to configure register
bit sitting in SYSCTRL module for DAC power control.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>

dt: add bindings for ZTE tvenc device

It adds bindings doc for ZTE VOU TV Encoder device.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>

drm: zte: add function to configure vou_ctrl dividers

The clock control module (CRM) cannot always provide desired frequency
for all VOU output devices.  That's why VOU integrates a few dividers
to further divide the clocks from CRM.  Let's add an interface for
configuring these dividers.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>

drm: zte: move struct vou_inf into zx_vou driver

Although data in struct vou_inf is defined per output device, it doesn't
belong to the device itself but VOU control module.  All these data can
just be defined in VOU driver, and output device driver only needs to
invoke VOU driver function with device ID to enable/disable specific
output device.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>

drm: zte: add interlace mode support

It adds interlace mode support in VOU TIMING_CTRL and channel control
block, so that VOU driver gets ready to support output device in
interlace mode like TV Encoder.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>

drm: zte: add overlay plane support

It enables VOU VL (Video Layer) to support overlay plane with scaling
function.  VL0 has some quirks on scaling support.  We choose to skip it
and only adds VL1 and VL2 into DRM core for now.

Function zx_plane_atomic_disable() gets moved around with no changes to
save a forward declaration.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>

drm: zte: add .atomic_disable hook to disable graphic layer

There are a few hardware bits for each graphic layer to control main/aux
channel and clock selection, as well as the layer enabling.  These bits
sit outside the layer block itself, but in VOU control glue block.  We
currently set these bits up at CRTC initialization for once, and do not
support disabling the layer.

This patch creates a pair of functions zx_vou_layer_enable[disable] to
be invoked from plane hooks .atomic_update and .atomic_disable to set up
and tear down the layer.  This is generic for both graphic and video
layers, so it will make the overlay plane support to be added later much
easier.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>

drm: zte: make zx_plane accessible from zx_vou driver

Move struct zx_plane from zx_plane.c to zx_plane.h, so that it can be
accessed from zx_vou driver, and we can save the use of struct
zx_layer_data completely.  More importantly, those additional data used
by VOU controller to enable/disable graphic and video layers can later
be added and accessed much more easily from zx_vou driver.

While at it, we make two changes to zx_plane_init() interface:

 - Encode struct device pointer in zx_plane, so that we do not need to
   pass it as a parameter.
 - Change return of zx_plane_init() from struct drm_plane pointer to
   error code, since we can get the pointer from zx_plane in zx_vou
   driver now.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>

drm: zte: support hdmi audio through spdif

It enables HDMI audio support through SPDIF interface based on generic
hdmi-audio-codec driver.  The HDMI hardware supports more audio
interfaces than SPDIF, like I2S, which may be added later.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>

drm: zte: select VIDEOMODE_HELPERS in Kconfig

ZTE DRM driver uses drm_display_mode_to_videomode() in function
zx_crtc_enable().  Select VIDEOMODE_HELPERS in Kconfig to fix the
following link error.

  LD      vmlinux.o
  MODPOST vmlinux.o
drivers/built-in.o: In function `zx_crtc_enable':
:(.text+0xbdeb8): undefined reference to `drm_display_mode_to_videomode'

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>

drm/i915: Support explicit fencing for execbuf

Now that the user can opt-out of implicit fencing, we need to give them
back control over the fencing. We employ sync_file to wrap our
drm_i915_gem_request and provide an fd that userspace can merge with
other sync_file fds and pass back to the kernel to wait upon before
future execution.

Testcase: igt/gem_exec_fence
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Chad Versace <chadversary@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170127094008.27489-2-chris@chris-wilson.co.uk

drm/i915: Enable userspace to opt-out of implicit fencing

Userspace is faced with a dilemma. The kernel requires implicit fencing
to manage resource usage (we always must wait for the GPU to finish
before releasing its PTE) and for third parties. However, userspace may
wish to avoid this serialisation if it is either using explicit fencing
between parties and wants more fine-grained access to buffers (e.g. it
may partition the buffer between uses and track fences on ranges rather
than the implicit fences tracking the whole object). It follows that
userspace needs a mechanism to avoid the kernel's serialisation on its
implicit fences before execbuf execution.

The next question is whether this is an object, execbuf or context flag.
Hybrid users (such as using explicit EGL_ANDROID_native_sync fencing on
shared winsys buffers, but implicit fencing on internal surfaces)
require a per-object level flag. Given that this flag need to be only
set once for the lifetime of the object, this reduces the convenience of
having an execbuf or context level flag (and avoids having multiple
pieces of uABI controlling the same feature).

Incorrect use of this flag will result in rendering corruption and GPU
hangs - but will not result in use-after-free or similar resource
tracking issues.

Serious caveat: write ordering is not strictly correct after setting
this flag on a render target on multiple engines. This affects all
subsequent GEM operations (execbuf, set-domain, pread) and shared
dma-buf operations. A fix is possible - but costly (both in terms of
further ABI changes and runtime overhead).

Testcase: igt/gem_exec_async
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Chad Versace <chadversary@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170127094008.27489-1-chris@chris-wilson.co.uk

dma/fence: Export enable-signaling tracepoint for emission by drivers

Currently this tracepoint is solely used by dma_fence_enable_sw_signaling,
however I have a need to manually perform the hw enabling of the
signaling and would like to emit this tracepoint for completeness.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170124115758.31353-1-chris@chris-wilson.co.uk

drm/amdgpu: fix amdgpu_bo_va_mapping flags

They are 64bit not 32 for a while now.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: access stolen VRAM directly on CZ (v2)

We don't need to use the PCI BAR on APUs. This allows us to access
the full VRAM directly without being limited by the BAR size.

v2: squash in 64bit shift fix

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