Sparse enforces that GFP flags are only manipulated inside gfp_t locals.

Fixes: 4d470f73 ("drm/i915: Avoid undefined behaviour of "u32 >> 32"")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170901145729.21363-1-chris@chris-wilson.co.ukReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 0d95c883)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

radix_tree_for_each_slot() wants an __rcu annotated pointer for the
slot. So let's add the annotation.

Fixes the following sparse warnings:
i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces)
i915_gem.c:2217:9:    expected void **slot
i915_gem.c:2217:9:    got void [noderef] <asn:4>**
i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces)
i915_gem.c:2217:9:    expected void **slot
i915_gem.c:2217:9:    got void [noderef] <asn:4>**
i915_gem.c:2217:9: warning: incorrect type in argument 1 (different address spaces)
i915_gem.c:2217:9:    expected void [noderef] <asn:4>**slot
i915_gem.c:2217:9:    got void **slot
i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces)
i915_gem.c:2217:9:    expected void **slot
i915_gem.c:2217:9:    got void [noderef] <asn:4>**

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: 96d77634 ("drm/i915: Use a radixtree for random access to the object's backing storage")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170901171252.31025-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit c23aa71b)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Add back the GEN8_PPAT_WB cache attributes in cnl_setup_private_ppat(),
which are missed on CNL.

Fixes: 4e34935f ("drm/i915/cnl: Setup PAT Index.")
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Suggested-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1504208177-27784-1-git-send-email-zhi.a.wang@intel.com
(cherry picked from commit 6e31cdcf)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Use enum pipe for PCH transcoders also in the FIFO underrun code.

Fixes the following new sparse warnings:
intel_fifo_underrun.c:340:49: warning: mixing different enum types
intel_fifo_underrun.c:340:49:     int enum pipe  versus
intel_fifo_underrun.c:340:49:     int enum transcoder
intel_fifo_underrun.c:344:49: warning: mixing different enum types
intel_fifo_underrun.c:344:49:     int enum pipe  versus
intel_fifo_underrun.c:344:49:     int enum transcoder
intel_fifo_underrun.c:397:57: warning: mixing different enum types
intel_fifo_underrun.c:397:57:     int enum pipe  versus
intel_fifo_underrun.c:397:57:     int enum transcoder
intel_fifo_underrun.c:398:17: warning: mixing different enum types
intel_fifo_underrun.c:398:17:     int enum pipe  versus
intel_fifo_underrun.c:398:17:     int enum transcoder

Cc: Matthias Kaehlcke <mka@chromium.org>
Fixes: a2196033 ("drm/i915: Consistently use enum pipe for PCH transcoders")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170901143123.7590-3-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 41c32e5d)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Make gmbus_lock_ops and proxy_lock_ops static to appease sparse
intel_i2c.c:652:34: warning: symbol 'gmbus_lock_ops' was not declared. Should it be static?
intel_sdvo.c:2981:34: warning: symbol 'proxy_lock_ops' was not declared. Should it be static?

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes: a8506684 ("drm/i915: Rework sdvo proxy i2c locking")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170901143123.7590-2-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 0db1aa42)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Make i9xx_load_ycbcr_conversion_matrix() static to appease sparse:
intel_color.c:110:6: warning: symbol 'i9xx_load_ycbcr_conversion_matrix' was not declared. Should it be static?

Cc: Shashank Sharma <shashank.sharma@intel.com>
Fixes: 25edf915 ("drm/i915: prepare csc unit for YCBCR420 output")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170901143123.7590-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 0abd9976)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

This patch fixes the DP AUX CH timeouts observed during CI runs causing
CI Failures on a specific PCI device. This issue was fixed previously
by adding a quirk but looks like we need to increase this delay even more
in order to get rid all the DP AUX CH timeouts.

Fixes: c99a259b ("drm/i915/edp: Add a T12 panel delay quirk to fix
DP AUX CH timeouts")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101144Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1502823591-25310-1-git-send-email-manasi.d.navare@intel.com
(cherry picked from commit e8f345e0)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

By using drm_gem_flink/drm_gem_open on an object using the same fd, it
is possible for a client to create multiple handles pointing to the same
object (tied to the same contexts and VMA), as exemplified by
igt::gem_handle_to_libdrm_bo(). Since this duplication has been possible
since forever, we cannot assume that the handle:(fpriv, object) is
unique and so must handle the multiple users of a single VMA.

v2: Added commentary noise.

Testcase: igt/gem_close
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102355
Fixes: d1b48c1e ("drm/i915: Replace execbuf vma ht with an idr")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170822110517.22277-3-chris@chris-wilson.co.ukTested-by: NMarta Lofstedt <marta.lofstedt@intel.com>
Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
(cherry-picked from commit 3ffff017)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The CCS won't have the same stride as the main surface anyway so trying
to guard against the fence stride not matching the CCS stride is
not sensible. Just skip the fence vs. fb alignment check for the aux
plane.

Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Daniel Stone <daniels@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170824191100.10949-3-ville.syrjala@linux.intel.comReviewed-by: NBen Widawsky <ben@bwidawsk.net>
Fixes: 2e2adb05 ("drm/i915: Add render decompression support")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 2ec4cf40)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Userspace wants to treat fb->offsets[] as raw byte offsets into the gem
bo. Adjust the kernel code to match.

Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Daniel Stone <daniels@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170824191100.10949-2-ville.syrjala@linux.intel.comAcked-by: NBen Widawsky <ben@bwidawsk.net>
Fixes: 2e2adb05 ("drm/i915: Add render decompression support")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 303ba695)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Since we hold the device wakeref when writing through the GTT (otherwise
the writes would fail), we presumed that before the device sleeps those
writes would naturally be flushed and that we wouldn't need our mmio
read trick. However, that presumption seems false and a sleepy bxt seems
to require us to always manually flush the GTT writes prior to direct
access.

Fixes: e2a2aa36 ("drm/i915: Check we have an wake device before flushing GTT writes")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829192546.1087-1-chris@chris-wilson.co.uk
(cherry picked from commit b69a784f)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Sometimes we know we are the only user of the bo, but since we take a
protective pin_pages early on, an attempt to change the vmap on the
object is denied because it is busy. i915_gem_object_pin_map() cannot
tell from our single pin_count if the operation is safe. Instead we must
pass that information down from the caller in the manner of
I915_MAP_OVERRIDE.

This issue has existed from the introduction of the mapping, but was
never noticed as the only place where this conflict might happen is for
cached kernel buffers (such as allocated by i915_gem_batch_pool_get()).
Until recently there was only a single user (the cmdparser) so no
conflicts ever occurred. However, we now use it to allocate batches for
different operations (using MAP_WC on !llc for writes) in addition to the
existing shadow batch (using MAP_WB for reads).

We could either keep both mappings cached, or use a different write
mechanism if we detect a MAP_WB already exists (i.e. clflush
afterwards), but as we haven't seen this issue in the wild (it requires
hitting the GPU reloc path in addition to the cmdparser) for simplicity
just allow the mappings to be recreated.

v2: Include the i915_MAP_OVERRIDE bit in the enum so the compiler knows
about all the valid values.

Fixes: 7dd4f672 ("drm/i915: Async GPU relocation processing")
Testcase: igt/gem_lut_handle # byt, completely by accident
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170828104631.8606-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit a575c676)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Since we use a worker to enable FBC on the CRTC, it is possible for the
CRTC to be switched off before we run. In this case, the CRTC will not
allow us to wait upon a vblank, so remove the DRM_ERROR as this is very
much expected.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102410
Fixes: ca18d51d ("drm/i915/fbc: wait for a vblank instead of 50ms when enabling")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170825150215.19236-1-chris@chris-wilson.co.ukReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 908b6e6e)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Signed-off-by: NJason Ekstrand <jason@jlekstrand.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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

The commit 213e08ad
	("drm/i915/bxt: add bxt dsi gpio element support")
enables GPIO support for Broxton based platforms.

While using that API we might get into troubles in the future, because
we can't rely on label name in the driver since vendor firmware might
provide any GPIO pin there, e.g. "reset", and even mark it in _DSD (in
which case the request will fail).

To avoid inconsistency and potential issues we have two options:
a) generate GPIO ACPI mapping table and supply it via
   acpi_dev_add_driver_gpios(), or
b) just pass NULL as connection ID.

The b) approach is much simpler and would work since the driver relies
on GPIO indices only. Moreover, the _CRS fallback mechanism, when
requesting GPIO, has been made stricter, and supplying non-NULL
connection ID when neither _DSD, nor GPIO ACPI mapping is present, is
making request fail.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101921
Fixes: f10e4bf6 ("gpio: acpi: Even more tighten up ACPI GPIO lookups")
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Tested-by: NMika Kahola <mika.kahola@intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170817105541.63914-1-andriy.shevchenko@linux.intel.com

In a synchronous setup, we may retire the last request before we
complete allocating the next request. As the last request is retired, we
queue a timer to mark the device as idle, and promptly have to execute
ad cancel that timer once we complete allocating the request and need to
keep the device awake. If we rearrange the mark_busy() to occur before
we retire the previous request, we can skip this ping-pong.

v2: Joonas pointed out that unreserve_seqno() was now doing more than
doing seqno handling and should be renamed to reflect its wider purpose.
That also highlighted the new asymmetry with reserve_seqno(), so fixup
that and rename both to [un]reserve_engine().
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170817144719.10968-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

The word out was dropped from the sentence across the line break, put it
back.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20170816085210.4199-6-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

This was the competing idea long ago, but it was only with the rewrite
of the idr as an radixtree and using the radixtree directly ourselves,
along with the realisation that we can store the vma directly in the
radixtree and only need a list for the reverse mapping, that made the
patch performant enough to displace using a hashtable. Though the vma ht
is fast and doesn't require any extra allocation (as we can embed the node
inside the vma), it does require a thread for resizing and serialization
and will have the occasional slow lookup. That is hairy enough to
investigate alternatives and favour them if equivalent in peak performance.
One advantage of allocating an indirection entry is that we can support a
single shared bo between many clients, something that was done on a
first-come first-serve basis for shared GGTT vma previously. To offset
the extra allocations, we create yet another kmem_cache for them.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170816085210.4199-5-chris@chris-wilson.co.uk

Since the introduction of being able to perform a lockless lookup of an
object (i915_gem_object_get_rcu() in fbbd37b3 ("drm/i915: Move object
release to a freelist + worker") we no longer need to split the
object/vma lookup into 3 phases and so combine them into a much simpler
single loop.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170816085210.4199-4-chris@chris-wilson.co.uk

When userspace is doing most of the work, avoiding relocs (using
NO_RELOC) and opting out of implicit synchronisation (using ASYNC), we
still spend a lot of time processing the arrays in execbuf, even though
we now should have nothing to do most of the time. One issue that
becomes readily apparent in profiling anv is that iterating over the
large execobj[] is unfriendly to the loop prefetchers of the CPU and it
much prefers iterating over a pair of arrays rather than one big array.

v2: Clear vma[] on construction to handle errors during vma lookup
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170816085210.4199-3-chris@chris-wilson.co.uk

Since we keep the context around across the slow lookup where we may
drop the struct_mutex, we should double check that the context is still
valid upon reacquisition.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170816085210.4199-2-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>

MI_STORE_DWORD_IMM just doesn't work on the video decode engine under
Sandybridge, so refrain from using it. Then switch the selftests over to
using the now common test prior to using MI_STORE_DWORD_IMM.

Fixes: 7dd4f672 ("drm/i915: Async GPU relocation processing")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.13-rc1+
Link: https://patchwork.freedesktop.org/patch/msgid/20170816085210.4199-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>

Forcewake is not affected by the engine reset on gen6+. Indeed the
reason why we added intel_uncore_forcewake_reset() to
gen6_reset_engines() was to keep the bookkeeping intact because the
reset did not touch the forcewake bit (yet we cancelled the forcewake
consumers)!  This was done in commit 521198a2:
    Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    Date:   Fri Aug 23 16:52:30 2013 +0300

	drm/i915: sanitize forcewake registers on reset

	In reset we try to restore the forcewake state to
	pre reset state, using forcewake_count. The reset
	doesn't seem to clear the forcewake bits so we
	get warn on forcewake ack register not clearing.

That futzing of the forcewake bookkeeping was dropped in commit
0294ae7b ("drm/i915: Consolidate forcewake resetting to a single
function"), but it did not make the realisation that the remaining
intel_uncore_forcewake_reset() was redundant.

The new danger with using intel_uncore_forcewake_reset() with per-engine
resets is that the driver and hw are still in an active state as we
perform the reset. We may be using the forcewake to read protected
registers elsewhere and those results may be clobbered by the concurrent
dropping of forcewake.
Reported-by: NMichel Thierry <michel.thierry@intel.com>
Fixes: 142bc7d9 ("drm/i915: Modify error handler for per engine hang recovery")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170817173229.20324-1-chris@chris-wilson.co.ukReviewed-by: NMichel Thierry <michel.thierry@intel.com>
Acked-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>

Cleanup the code. Map the pins in accordance to
individual platforms rather than according to ports.
Create separate functions for platforms.

v2:
 - Add missing condition for CoffeeLake. Make platform
 specific functions static. Add function
 i915_ddc_pin_mapping().

v3:
 - Rename functions to x_port_to_ddc_pin() which directly
   indicates the purpose. Correct default return values on CNP
   and BXT. Rename i915_port_to_ to g4x_port_to since that was
   the first platform to run this. Correct code style. (Paulo)

Sugested-by Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Signed-off-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1502927114-24012-1-git-send-email-anusha.srivatsa@intel.com

Sometimes it would be most enlightening to debug systems by replacing
the VBT to be used. For example, in the referenced bug the BIOS provides
different VBT depending on the boot mode (UEFI vs. legacy). It would be
interesting to try the failing boot mode with the VBT from the working
boot, and see if that makes a difference.

Add a module parameter to load the VBT using the firmware loader, not
unlike the EDID firmware mechanism.

As a starting point for experimenting, one can pick up the BIOS provided
VBT from /sys/kernel/debug/dri/0/i915_opregion/i915_vbt.

v2: clarify firmware load return value check (Bob)

v3: kfree the loaded firmware blob

References: https://bugs.freedesktop.org/show_bug.cgi?id=97822#c83Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170817115209.25912-1-jani.nikula@intel.com

Otherwise it reuses the ilk that has a completely different
wm.

Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170809205248.11917-6-rodrigo.vivi@intel.com

They're slightly different than the gen 9 calculations.

v2: Remove TODO comment. Code matches recent spec.
v3: Rebase on top of latest skl code using new fp16.16 and
    fixing a logic issue. Auto rebase bot has apparently
    made some bad decisions that changed the logic of the
    code. (Noticed by Manesh, updated by Rodrigo).

Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170811233825.32083-1-rodrigo.vivi@intel.com

When LSPCON support was extended to CNL
one part was missed on lspcon_init.

So, instead of adding check per platform on lspcon_init
let's use HAS_LSPCON that is already there for that
purpose.

Fixes: ff15947e ("drm/i915/cnl: LSPCON support is gen9+")
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NShashank Sharma <shashank.sharma@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170816030403.11368-1-rodrigo.vivi@intel.com

Ever since we've parsed VBT child devices, starting from 6acab15a
("drm/i915: use the HDMI DDI buffer translations from VBT"), we've
ignored the child device information if more than one child device
references the same port. The rationale for this seems lost in time.

Since commit 311a2094 ("drm/i915: don't init DP or HDMI when not
supported by DDI port") we started using this information more to skip
HDMI/DP init if the port wasn't there per VBT child devices. However, at
the same time it added port defaults without further explanation.

Thus, if the child device info was skipped due to multiple child devices
referencing the same port, the device info would be retrieved from the
somewhat arbitrary defaults.

Finally, when commit bb1d1329 ("drm/i915/vbt: split out defaults
that are set when there is no VBT") stopped initializing the defaults
whenever VBT is present, thus trusting the VBT more, we stopped
initializing ports which were referenced by more than one child device.

Apparently at least Asus UX305UA, UX305U, and UX306U laptops have VBT
child device blocks which cause this behaviour. Arguably they were
shipped with a broken VBT.

Relax the rules for multiple references to the same port, and use the
first child device info to reference a port. Retain the logic to debug
log about this, though.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101745
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196233
Fixes: bb1d1329 ("drm/i915/vbt: split out defaults that are set when there is no VBT")
Tested-by: NOliver Weißbarth <mail@oweissbarth.de>
Reported-by: NOliver Weißbarth <mail@oweissbarth.de>
Reported-by: NDidier G <didierg-divers@orange.fr>
Reported-by: NGiles Anderson <agander@gmail.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: <stable@vger.kernel.org> # v4.12+
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170811113907.6716-1-jani.nikula@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>

Different from previous platforms, on CNL+ there's separated
registers for separated indexes.

v2: Remove comments regarding uncertainty around the table.
v3: Remove extra line (by Ben)

Cc: Clint Taylor <clinton.a.taylor@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NBen Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170815232539.3562-1-rodrigo.vivi@intel.com

Some fixed resolution panels actually support more than one mode,
with the only thing different being the refresh rate.  Having this
alternate mode available to us is desirable, because it allows us to
test PSR on panels whose setup time at the preferred mode is too long.
With this patch we allow the use of the alternate mode if it's
available and it was specifically requested.

v2 and v3: Rebase
v4: * Fix up some leaky mode stuff (Chris)
    * Rebase
v5: * Fix a NULL pointer derefrence (David Weinehall)
v6: * Whitespace / spelling / checkpatch clean-up; no functional
      change. (David)
    * Rebase

Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Signed-off-by: NJim Bride <jim.bride@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1502308133-26892-1-git-send-email-jim.bride@linux.intel.com

This commit adds support for waiting on or signaling DRM syncobjs as
part of execbuf.  It does so by hijacking the currently unused cliprects
pointer to instead point to an array of i915_gem_exec_fence structs
which containe a DRM syncobj and a flags parameter which specifies
whether to wait on it or to signal it.  This implementation
theoretically allows for both flags to be set in which case it waits on
the dma_fence that was in the syncobj and then immediately replaces it
with the dma_fence from the current execbuf.

v2:
 - Rebase on new syncobj API
v3:
 - Pull everything out into helpers
 - Do all allocation in gem_execbuffer2
 - Pack the flags in the bottom 2 bits of the drm_syncobj*
v4:
 - Prevent a potential race on syncobj->fence

Testcase: igt/gem_exec_fence/syncobj*
Signed-off-by: NJason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/1499289202-25441-1-git-send-email-jason.ekstrand@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20170815145733.4562-1-chris@chris-wilson.co.uk

The wait-ioctl is optionally supplied a timeout with nanosecond
precision in a s64 field. We use nsecs_to_jiffies64() to convert that
into the jiffies consumed by the scheduler, but internally
nsecs_to_jiffies64() does not guard against overflow (as it's purpose is
for use by the scheduler and not drivers!). So we must guard against the
overflow ourselves, and in the process note that we may then return
much earlier than the timeout selected by the user, so don't report
ETIME unless we do hit the timeout. (Woe betold us though if the user
waits for a year (32bit) and the request is still not complete!)

v2: Refine overflow detection (to not include an overffow itself)
Reported-by: NJason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170811105731.9482-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Another month, another story in the cache coherency saga. This time, we
come to the realisation that i915_gem_object_is_coherent() has been
reporting whether we can read from the target without requiring a cache
invalidate; but we were using it in places for testing whether we could
write into the object without requiring a cache flush. So split the
tracking into two, one to decide before reads, one after writes.

See commit e27ab73d ("drm/i915: Mark CPU cache as dirty on every
transition for CPU writes") for the previous entry in this saga.

v2: Be verbose
v3: Remove unused function (i915_gem_object_is_coherent)
v4: Fix inverted coherency check prior to execbuf (from v2)
v5: Add comment for nasty code where we are optimising on gcc's behalf.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101109
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101555
Testcase: igt/kms_mmap_write_crc
Testcase: igt/kms_pwrite_crc
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Dongwon Kim <dongwon.kim@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Tested-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170811111116.10373-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Future platforms increase the number of power wells which require
additional control registers. A convenient way to select the correct
register is to use the high bits of the power well ID as index. This
patch only prepares for this, while upcoming platform enabling patches
will add the actual new power well IDs and corresponding power well
control registers.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Rakshmi Bhatia <rakshmi.bhatia@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NAnimesh Manna <animesh.manna@intel.com>
Reviewed-by: NRakshmi Bhatia <rakshmi.bhatia@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170814151530.24154-2-imre.deak@intel.com

GCC 4.4 can't cope with anonymous union initializers which seems to be a
bug in that version (see the Reference) and is fixed since GCC version
4.6. A workaround which is also used elsewhere in the kernel for the
same purpose is to wrap the initialization in curly braces, so do the
same here.

Fixes: b5565a2e ("drm/i915/bxt, glk: Give a proper name to the power well struct phy field")
Reference: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20170814151530.24154-1-imre.deak@intel.com

variable 'data' may be used uninitialized in this function. thus,
'function dcs_get_backlight' will return unwanted value/fail.

Thus, adding NULL initialized to 'data' variable will solve the return
failure happening.

v2: Change commit message to reflect upstream with proper message

Fixes: 90198355 ("drm/i915/dsi: Add DCS control for Panel PWM")
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Yetunde Adebisi <yetundex.adebisi@intel.com>
Cc: Deepak M <m.deepak@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NBalasubramaniam, Hari Chand <hari.chand.balasubramaniam@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1502762746-191826-1-git-send-email-hari.chand.balasubramaniam@intel.com

Validate the compliance test link parameters when the compliance
test dpcd registers are read. Also validate them in compute_config
before using them since the max values might have been reduced
due to link training fallback.

If either the link rate or lane count is invalid, we still bail
from using the test parameters since the combination would not work
and instead use the fallback values.

v2:
* Added commit message to explain why we still bail when either of
of the params is invalid (Ville Syrjala)
* Add reason for validating in the comment (Jani Nikula)
* Also check if index >= 0 after validating (Jani Nikula)
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Tested-by: NNathan Ciobanu <nathan.d.ciobanu@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1496954463-18038-2-git-send-email-manasi.d.navare@intel.com

This function now takes the link rate and lane ocunt to be validated
as an argument so that this can be used for validating even the
compliance test link parameters.
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@linux.intel.com>
Tested-by: NNathan Ciobanu <nathan.d.ciobanu@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1496954463-18038-1-git-send-email-manasi.d.navare@intel.com