drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()

Replace instances of drm_framebuffer_reference/unreference() with
*_get/put() suffixes and drm_dev_unref with *_put() suffix
because get/put is shorter and consistent with the
kernel use of *_get/put suffixes.
Done with following coccinelle semantic patch

@@
expression ex;
@@

(
-drm_framebuffer_unreference(ex);
+drm_framebuffer_put(ex);
|
-drm_dev_unref(ex);
+drm_dev_put(ex);
|
-drm_framebuffer_reference(ex);
+drm_framebuffer_get(ex);
)

Signed-off-by: Harsha Sharma <harshasharmaiitr@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171014183644.21990-1-harshasharmaiitr@gmail.com

Merge drm-upstream/drm-next into drm-intel-next-queued

Needed for timer_setup() and drm_dev_{get,put}() conversions in i915.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Fixup userptr mmu notifier registration error handling

Avoid dereferencing the error pointer and also avoid returning NULL
from i915_mmu_notifier_find since the callers do not expect that.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 7741b547b6e0 ("drm/i915: Preallocate our mmu notifier workequeu to unbreak cpu hotplug deadlock")
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171017150908.12840-1-tvrtko.ursulin@linux.intel.com

drm/i915: Use a mask when applying WaProgramL3SqcReg1Default

Otherwise we are blasting other bits in GEN8_L3SQCREG1 that might be important
(although we probably aren't at the moment because 0 seems to be the default
for all the other bits).

v2: Extra parentheses (Michel)

Fixes: 050fc46 ("drm/i915:bxt: implement WaProgramL3SqcReg1DefaultForPerf")
Fixes: 450174f ("drm/i915/chv: Tune L3 SQC credits based on actual latencies")
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1508271945-14961-1-git-send-email-oscar.mateo@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: No need for RING_MAX_NONPRIV_SLOTS space

Now that we write RING_FORCE_TO_NONPRIV registers directly to hardware,
[commit 32ced39 ("drm/i915: Transform whitelisting WAs into a simple reg
write")] there is no need to save space for them in the list of context
workarounds.

v2: Refer to previous commit in commit message (Michel)

Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1508272071-15125-1-git-send-email-oscar.mateo@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915/uc: Add pretty printer for uc firmware

Debugfs for GuC and HuC load info have similar common part.
Move and update dump of uc_fw to separate helper for reuse.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171017094449.22584-1-michal.wajdeczko@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Handle drm-layer errors in intel_dp_add_mst_connector

Make intel_dp_add_mst_connector handle error returns from the drm_ calls.
Add intel_connector_free to support cleanup on the error path.

v2: Rename new function to avoid confusion, and simplify error
paths (Ville)

v3: Indentation fixup, style fixes (Ville)

v4: Clarify usage of intel_connector_free, and fix usage of
intel_connector_free

v5: Rebase

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171013180144.15865-1-james.ausmus@intel.com

drm/i915/selftests: Silence the compiler for impossible errors

It should be impossible for these tests not to run due to an empty
ppgtt, but if it should happen, let's report ENODEV (our typical
internal error for impossible events).

In file included from drivers/gpu/drm/i915/i915_gem.c:5415:
   drivers/gpu/drm/i915/selftests/huge_pages.c: In function 'igt_mock_ppgtt_huge_fill':
>> drivers/gpu/drm/i915/selftests/huge_pages.c:612: error: 'err' may be used uninitialized in this function
   drivers/gpu/drm/i915/selftests/huge_pages.c: In function 'igt_ppgtt_exhaust_huge':
   drivers/gpu/drm/i915/selftests/huge_pages.c:1159: error: 'err' may be used uninitialized in this function

Reported-by: kbuild-all@01.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171017103723.6933-1-chris@chris-wilson.co.uk
Reviewed-by: Matthew Auld <matthew.auld@intel.com>

drm/i915: Report -EFAULT before pwrite fast path into shmemfs

When pwriting into shmemfs, the fast path pagecache_write does not
notice when it is writing to beyond the end of the truncated shmemfs
inode. Report -EFAULT directly when we try to use pwrite into the
!I915_MADV_WILLNEED object.

Fixes: 7c55e2c5772d ("drm/i915: Use pagecache write to prepopulate shmemfs from pwrite-ioctl")
Testcase: igt/gem_madvise/dontneed-before-pwrite
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016202732.25459-1-chris@chris-wilson.co.uk

drm/i915: Remove mostly duplicated video DIP handling from PSR code

Now that the infoframe hooks are part of the intel_dig_port, we can use
the normal .write_infoframe() hook to update the VSC SDP. We do need to
deal with the size difference between the VSC DIP and the others though.

Another minor snag is that the compiler will complain to use if we keep
using enum hdmi_infoframe_type type and passing in the DP define instead,
so et's just change to unsigned int all over for the inforframe type.

v2: Rebase due to other PSR changes

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171013194051.19286-1-ville.syrjala@linux.intel.com

drm/plane: drop num_overlay_planes (v3)

In order to implement plane leasing we need to count things,
just make the code consistent with the counting code currently
used for counting crtcs/encoders/connectors and drop the need
for num_overlay_planes.

v2: don't forget to assign plane_ptr. (keithp)
v3: use correct bounds check, found by igt.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge tag 'tilcdc-4.15' of https://github.com/jsarha/linux into drm-next

tilcdc changes for v4.15

* tag 'tilcdc-4.15' of https://github.com/jsarha/linux:
  drm/tilcdc: Remove redundant OF_DETACHED flag setting
  drm/tilcdc: Precalculate total frametime in tilcdc_crtc_set_mode()
  drm/tilcdc: Use tilcdc_crtc_shutdown() in tilcdc_crtc_destroy()
  drm/tilcdc: Remove WARN_ON(!drm_modeset_is_locked(&crtc->mutex)) checks
  drm/tilcdc: Turn raster off in crtc reset, if it was on in the HW
  drm/tilcdc: switch to drm_*{get,put} helpers
  drm/tilcdc: tilcdc_tfp410: make of_device_ids const.
  drm/tilcdc: tilcdc_panel: make of_device_ids const.

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

Quick 4.15 misc pull for the build fix:

Cross-subsystem Changes:
- piles an piles of misc/trivial patches all over, some more from
  outreachy applicants

Core Changes:
- build fix for the bridge/of cleanup (Maarten)
- fix vblank count in arm_vblank_event (Ville)
- some kerneldoc typo fixes from Thierry

Driver Changes:
- vc4: Fix T-format tiling scanout, cleanup clock divider w/a (Anholt)
- sun4i: small cleanups and improved code comments all over (Chen-Yu
  Tsai)

* tag 'drm-misc-next-2017-10-16' of git://anongit.freedesktop.org/drm/drm-misc: (21 commits)
  drm/via: use ARRAY_SIZE
  drm/gma500: use ARRAY_SIZE
  drm/sun4i: hdmi: Move PAD_CTRL1 setting to mode_set function
  drm/sun4i: hdmi: Document PAD_CTRL1 output invert bits
  drm/sun4i: backend: Add comment explaining why registers are cleared
  drm/sun4i: backend: Use drm_fb_cma_get_gem_addr() to get display memory
  drm/sun4i: backend: Create regmap after access is possible
  drm/sun4i: don't add components that are already in the queue
  drm/vc4: Fix pitch setup for T-format scanout.
  drm/vc4: Move the DSI clock divider workaround closer to the clock call.
  drm: Replace kzalloc with kcalloc
  drm/tinydrm: Remove explicit .best_encoder assignment
  drm/tinydrm: Replace dev_error with DRM_DEV_ERROR
  drm/drm_of: Move drm_of_panel_bridge_remove_function into header.
  drm/atomic-helper: Fix reference to drm_crtc_send_vblank_event()
  drm/atomic-helper: Fix typo
  drm: Add missing __user annotation to drm_syncobj_array_find()
  drm/rockchip: add PINCTRL dependency for LVDS
  drm/kirin: Checking for IS_ERR() instead of NULL
  driver:gpu: return -ENOMEM on allocation failure.
  ...

drm/i915/cnl: Fix PLL initialization for HDMI.

HDMI Mode selection on CNL is on CFGCR0 for that PLL, not
on in a global CTRL1 as it was on SKL.

The original patch addressed this difference, but leaving behind
this single entry here. So we were checking the wrong bits during
the PLL initialization and consequently avoiding the CFGCR1 setup
during HDMI initialization. Luckly when only HDMI was in use BIOS
had already setup this for us. But the dual display with hot plug
were messed up.

Fixes: a927c927de34 ("drm/i915/cnl: Initialize PLLs")
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Kahola, Mika <mika.kahola@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171003220859.21352-3-rodrigo.vivi@intel.com

drm/i915/cnl: Fix PLL mapping.

On PLL Enable sequence we need to "Configure DPCLKA_CFGCR0 to turn on
the clock for the DDI and map the DPLL to the DDI"

So we first do the map and then we unset DDI_CLK_OFF to turn the clock
on. We do this in 2 separated steps.

However, on this second step where we should only unset the off bit we are
also unmapping the ddi from the pll. So we end up using the pll 0
for almost everything. Consequently breaking cases with more than one
display.

Fixes: 555e38d27317 ("drm/i915/cnl: DDI - PLL mapping")
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Kahola, Mika <mika.kahola@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171003220859.21352-2-rodrigo.vivi@intel.com

drm/i915: Add in-flight request details to intel_engine_dump()

In the intel_engine_cs dumper, we were showing the request details for
the request queue but not of those requests already passed to the hw
(just a summary of the seqno). If we show those details, we can then
eliminate the entirely redundant and forgotten debugfs/i915_gem_request

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jeff McGee <jeff.mcgee@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171015204310.17045-1-chris@chris-wilson.co.uk
Reviewed-by: Jeff McGee <jeff.mcgee@intel.com>

drm/i915: Skip HW reinitialisation on resume if still wedged

If we fail to recover the HW state upon resume (i.e. our attempt to
clear the wedged bit and reset during i915_gem_sanitize() fails), then
skip the HW restart inside i915_gem_init_hw(). We will ultimately do the
HW restart when successfully unwedging and resetting the HW later,
but attempting to restore a wedged device upon resume is risky as the HW
is in an unknown state.

v2: Suppress the error message when detecting the already wedged HW.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103240
Testcase: igt/gem_eio/in-flight-suspend
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171015143725.27764-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

drm/i915: Trim struct_mutex hold duration for i915_gem_free_objects

We free objects in bulk after they wait for their RCU grace period.
Currently, we take struct_mutex and unbind all the objects. This can lead
to a long lock duration during which time those objects have their pages
unfreeable (i.e. the shrinker is prevented from reaping those pages). If
we only process a single object under the struct_mutex and then free the
pages, the number of objects locked away from the shrinker is minimal
and we allow regular clients better access to struct_mutex if they need
it.

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

drm/i915: Only free the oldest stale object before a fresh allocation

Inspired by Tvrtko's critique of the reaping of the stale contexts
before allocating a new one, also limit the freed object reaping to the
oldest stale object before allocating a fresh object. Unlike contexts,
objects may have radically different sizes of backing storage, but
similar to contexts, while we want to prevent starvation due to
excessive freed lists, we also do not want to delay fresh allocations
for too long. Only freeing the oldest on the freed object list before
each allocation is a reasonable compromise.

v2: Only a single consumer of llist_del_first() is allowed (although
multiple llist_add are still allowed in parallel). Unlike
i915_gem_context, i915_gem_flush_free_objects() is itself not serialized
and so we need to add our own spinlock. Otherwise KASAN eventually spots
a use-after-free for the race on *first->next.

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

drm/i915: Set our shrinker->batch to 4096 (~16MiB)

Prefer to defer activating our GEM shrinker until we have a few
megabytes to free; or we have accumulated sufficient mempressure by
deferring the reclaim to force a shrink. The intent is that because our
objects may typically be large, we are too effective at shrinking and
are not rewarded for freeing more pages than the batch. It will also
defer the initial shrinking to hopefully put it at a lower priority than
say the buffer cache (although it will balance out over a number of
reclaims, with GEM being more bursty).

v2: Give it a feedback system to try and tune the batch size towards
an effective size for the available objects.
v3: Start keeping track of shrinker stats in debugfs
v4: Protect against finding no shrinkable objects (div-by-zero)

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

drm/i915: Wire up shrinkctl->nr_scanned

shrink_slab() allows us to report back the number of objects we
successfully scanned (out of the target shrinkctl->nr_to_scan). As
report the number of pages owned by each GEM object as a separate item
to the shrinker, we cannot precisely control the number of shrinker
objects we scan on each pass; and indeed may free more than requested.
If we fail to tell the shrinker about the number of objects we process,
it will continue to hold a grudge against us as any objects left
unscanned are added to the next reclaim -- and so we will keep on
"unfairly" shrinking our own slab in comparison to other slabs.

v2: fixup the misplaced addition, we want to count everything we scan
(to match the number we reported earlier) not just the objects we
successfully validated and freed.

References: 912d572d63b8 ("drm/i915: wire up shrinkctl->nr_scanned")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171013202621.7276-6-chris@chris-wilson.co.uk

drm/i915: Move dev_priv->mm.[un]bound_list to its own lock

Remove the struct_mutex requirement around dev_priv->mm.bound_list and
dev_priv->mm.unbound_list by giving it its own spinlock. This reduces
one more requirement for struct_mutex and in the process gives us
slightly more accurate unbound_list tracking, which should improve the
shrinker - but the drawback is that we drop the retirement before
counting so i915_gem_object_is_active() may be stale and lead us to
underestimate the number of objects that may be shrunk (see commit
bed50aea61df ("drm/i915/shrinker: Flush active on objects before
counting")).

v2: Crosslink the spinlock to the lists it protects, and btw this
changes s/obj->global_link/obj->mm.link/
v3: Fix decoupling of old links in i915_gem_object_attach_phys()
v3.1: Fix the fix, only unlink if it was linked
v3.2: Use a local for to_i915(obj->base.dev)->mm.obj_lock

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

drm/i915: Remove walk over obj->vma_list for the shrinker

In the next patch, we want to reduce the lock coverage within the
shrinker, and one of the dangerous walks we have is over obj->vma_list.
We are only walking the obj->vma_list in order to check whether it has
been permanently pinned by HW access, typically via use on the scanout.
But we have a couple of other long term pins, the context objects for
which we currently have to check the individual vma pin_count. If we
instead mark these using obj->pin_display, we can forgo the dangerous
and sometimes slow list iteration.

v2: Rearrange code to try and avoid confusion from false associations
due to arrangement of whitespace along with rebasing on obj->pin_global.

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

drm/i915: Drop debugfs/i915_gem_pin_display

It has now lost its meaning (it shows more than just pin_display), I do
not believe that we are using in preference to the complete listing from
i915_gem_gtt, or the listing from i915_gem_framebuffer, or the listing
of active display objects in i915_display_info.

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

drm/i915: Rename obj->pin_display to obj->pin_global

In the next patch, we want to extend use of the global pin counter for
semi-permanent pinning of context/ring objects. Given that we plan to
extend the usage to encompass a disparate set of objects, we want a name
that reflects both and should entail less confusion.

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

drm/i915: Refactor testing obj->mm.pages

Since we occasionally stuff an error pointer into obj->mm.pages for a
semi-permanent or even permanent failure, we have to be more careful and
not just test against NULL when deciding if the object has a complete
set of its concurrent pages.

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

drm/i915/cnl: WaRsUseTimeoutMode

Apparently RC6 residency is lower than expected
with EI mode for most of the cases on CNL A0, B0 and C0.

This Wa doesn't solve our lower residency, but I
believe it is better to have it since EI is not
expected to work by HW engineers anyways.

Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170822235828.18322-1-rodrigo.vivi@intel.com

drm/i915/huc: Move fw select function

No functional change. Just place the function closer to related
definitions.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016144724.17244-15-michal.wajdeczko@intel.com

drm/i915/guc: Update Guc messages on load failure

In case of GuC firmware loading failure we were reporting
DRM_ERROR also for case when GuC loading was not strictly
required.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016144724.17244-14-michal.wajdeczko@intel.com

drm/i915/uc: Unify firmware loading

Firmware loading for GuC and HuC are similar. Move common code
into generic function for maximum reuse.

v2: change message levels (Chris)

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016144724.17244-13-michal.wajdeczko@intel.com

drm/i915: Update DMC firmware load error messages

Some of the error messages from DMC load were too generic and
may be confusing for the user. Lets explicitly add DMC words there.
Also as homepage of DMC firmware is same as for the GuC and Huc,
lets reuse URL definition.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016144724.17244-12-michal.wajdeczko@intel.com

drm/i915/uc: Add message with firmware url

In case of firmware fetch failure we should help user
find latest firmware. URL macro duplication from csr.c
will be fixed in upcoming patch.

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016144724.17244-11-michal.wajdeczko@intel.com

drm/i915/uc: Improve debug messages in firmware fetch

Time to remove less important info and make messages clear
and consistent.

v2: change some message levels (Chris)
v3: restore DRM_WARN (Chris)

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #2
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016144724.17244-10-michal.wajdeczko@intel.com

drm/i915/guc: Pick better place for Guc final status message

GuC status message printed right after firmware upload may be too
optimistic, as we may fail on subsequent steps. Move that message
to the end of intel_uc_init_hw where we know the status for sure.

v2: use dev_info (Chris)

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016144724.17244-9-michal.wajdeczko@intel.com

drm/i915/uc: Check all firmwares against WOPCM size

Both GuC and HuC firmwares will be moved into WOPCM so
we can check ucode size early for both cases.

Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016144724.17244-8-michal.wajdeczko@intel.com

drm/i915/guc: Reorder functions in intel_guc_fw.c

Functions should be defined in their use order.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016144724.17244-7-michal.wajdeczko@intel.com

drm/i915/guc: Rename intel_guc_loader.c to intel_guc_fw.c

Remaining functions in intel_guc_loader.c were focused around
GuC firmware. Rename them to match object-verb pattern and
rename file itself.

Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016144724.17244-6-michal.wajdeczko@intel.com

drm/i915/guc: Move doc near related definitions

After GuC code reorg some documentation was left in wrong
place. Move it closer to corresponding definitions.

v2: use consistent name for the GuC (Sagar)

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016144724.17244-5-michal.wajdeczko@intel.com

drm/i915/guc: Small fixups post code move

Existing code needs some style fixes. To avoid polluting
pure move patch, do it now as separate step.

Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016144724.17244-4-michal.wajdeczko@intel.com

drm/i915/guc: Move GuC boot param initialization out of xfer

We want to keep ucode xfer functions separate from other
initialization. Once separated, add explicit forcewake.

v2: use BLITTER domain only and add comment (Daniele)

Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #1
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016144724.17244-3-michal.wajdeczko@intel.com

drm/i915: Move intel_guc_wopcm_size to intel_guc.c

Function intel_guc_wopcm_size didn't fit well in the old place.
With this move upcoming cleanup will be simpler.

Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016144724.17244-2-michal.wajdeczko@intel.com

drm/i915: enable to read CSB and CSB write pointer from HWSP in GVT-g VM

Let GVT-g VM read the CSB and CSB write pointer from virtual HWSP, not all
the host support this feature, need to check the BIT(3) of caps in PVINFO.

v3 : Remove unnecessary comments.
v4 : Separate VM enable patch with GVT-g implementation patch due to code
dependency.
v5 : Use inline for GVT virtual HWSP caps check function.
v6 : Comments refine.

Signed-off-by: Weinan Li <weinan.z.li@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1508039725-1066-1-git-send-email-weinan.z.li@intel.com

drm/via: use ARRAY_SIZE

Using the ARRAY_SIZE macro improves the readability of the code.

Found with Coccinelle with the following semantic patch:
@r depends on (org || report)@
type T;
T[] E;
position p;
@@
(
 (sizeof(E)@p /sizeof(*E))
|
 (sizeof(E)@p /sizeof(E[...]))
|
 (sizeof(E)@p /sizeof(T))
)

Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Jérémy Lefaure <jeremy.lefaure@lse.epita.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016023357.20174-1-jeremy.lefaure@lse.epita.fr

drm/gma500: use ARRAY_SIZE

Using the ARRAY_SIZE macro improves the readability of the code. Also,
it is useless to re-invent it.

Found with Coccinelle with the following semantic patch:
@r depends on (org || report)@
type T;
T[] E;
position p;
@@
(
 (sizeof(E)@p /sizeof(*E))
|
 (sizeof(E)@p /sizeof(E[...]))
|
 (sizeof(E)@p /sizeof(T))
)

Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Jérémy Lefaure <jeremy.lefaure@lse.epita.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016023047.19145-1-jeremy.lefaure@lse.epita.fr

drm/sun4i: hdmi: Move PAD_CTRL1 setting to mode_set function

Initially we configured the PAD_CTRL1 register at probe/bind time.
However it seems the HDMI controller will modify some of the bits
in this register by itself. On the A10 it is particularly annoying
as it toggles the output invert bits, which inverts the colors on
the display output.

The U-boot driver this driver is based on sets this register twice,
though it seems it's only needed for actual display output. Hence
we move it to the mode_set function.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171014040252.9621-8-wens@csie.org

drm/sun4i: hdmi: Document PAD_CTRL1 output invert bits

While debugging inverted color from the HDMI output on the A10, I
found that the lowest 3 bits were set. These were cleared on A20
boards that had normal display output. By manually toggling these
bits the mapping of the color components to these bits was found.

While these are not used anywhere, it would be nice to document
them somewhere.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171014040252.9621-7-wens@csie.org

drm/sun4i: backend: Add comment explaining why registers are cleared

Many of the backend's layer configuration registers have undefined
default values. This poses a risk as we use regmap_update_bits in
some places, and don't overwrite the whole register.

At probe/bind time we explicitly clear all the control registers
by writing 0 to them. This patch adds a more detailed explanation
on why we're doing this.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171014040252.9621-5-wens@csie.org

drm/sun4i: backend: Use drm_fb_cma_get_gem_addr() to get display memory

Commit 4636ce93d5b2 ("drm/fb-cma-helper: Add drm_fb_cma_get_gem_addr()")
adds a new helper, which covers fetching a drm_framebuffer's GEM object
and calculating the buffer address for a given plane.

This patch uses this helper to replace our own open coded version of the
same function.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171014040252.9621-4-wens@csie.org

drm/sun4i: backend: Create regmap after access is possible

The backend has various clocks and reset controls that need to be
enabled and deasserted before register access is possible.

Move the creation of the regmap to after the clocks and reset controls
have been configured where it makes more sense.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171014040252.9621-3-wens@csie.org

drm/sun4i: don't add components that are already in the queue

Even though the components framework can handle duplicate entries,
the extra entries cause a lot more debug messages to be generated,
which would be confusing to developers not familiar with our driver
and the framework in general.

Instead, we can scan the relatively small queue and check if the
component to be added is already queued up. Since the display
pipelines are symmetrical (not considering the third display
pipeline on the A80), and we add components level by level, when
we get to the second instance at the same level, any shared downstream
components would already be in the queue.

Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171014040252.9621-2-wens@csie.org

drm/vc4: Fix pitch setup for T-format scanout.

The documentation said to use src_w here, and I didn't consider that
we actually needed to be using pitch somewhere in our setup.  Fixes
scanout on my DSI panel when X11 does initial setup with 1920x1080
HDMI and 800x480 DSI both at 0,0 of the same framebuffer.

v2: Add some comments requested by Boris

Signed-off-by: Eric Anholt <eric@anholt.net>
Fixes: 98830d91da08 ("drm/vc4: Add T-format scanout support.")
Link: https://patchwork.freedesktop.org/patch/msgid/20170927193209.11870-1-eric@anholt.net
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>

Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into drm-next

Most notable addition this time is the support for the GPU performance
counters by Christian. This has been in the making for some time and it
has matured a lot. Since this is adding UAPI, the corresponding WIP
userspace can be found at [1] mesa/libdrm repos. I expect that
Christian sends out the final userspace patches for this once you have
pulled the kernel bits.

Philipp optimized the probe path, so etnaviv gets out of the way for
systems that want to boot real quick.

I've done mostly cleanups, disentangling etnaviv from the IOMMU API,
with some MMUv1 optimizations on the way.

* 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux: (36 commits)
  drm/etnaviv: remove unnecessary clock stabilization delay
  drm/etnaviv: reduce reset delay
  drm/etnaviv: remove unused function etnaviv_gem_new
  drm/etnaviv: remove stale comment
  drm/etnaviv: submit supports performance monitor requests
  drm/etnaviv: enable debug registers on demand
  drm/etnaviv: need to disable clock gating when doing profiling
  drm/etnaviv: add MC perf domain
  drm/etnaviv: add TX perf domain
  drm/etnaviv: add RA perf domain
  drm/etnaviv: add SE perf domain
  drm/etnaviv: add PA perf domain
  drm/etnaviv: add SH perf domain
  drm/etnaviv: add PE perf domain
  drm/etnaviv: add HI perf domain
  drm/etnaviv: use 'sync points' for performance monitor requests
  drm/etnaviv: clear alloced event
  drm/etnaviv: add 'sync point' support
  drm/etnaviv: add performance monitor request processing
  drm/etnaviv: copy pmrs from userspace
  ...

drm/vc4: Move the DSI clock divider workaround closer to the clock call.

We want the adjusted_mode->clock to be the actual clock we're
expecting to program, so that consumers see the right values for clock
and vrefresh.

Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20170815234722.20700-1-eric@anholt.net
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>

drm/i915: Use bdw_ddi_translations_fdi for Broadwell

The compiler warns:

drivers/gpu/drm/i915/intel_ddi.c:118:35: warning: ‘bdw_ddi_translations_fdi’ defined but not used

Lo and behold, if we look at intel_ddi_get_buf_trans_fdi(), it uses
hsw_ddi_translations_fdi[] for both Haswell and *Broadwell*

Fixes: 7d1c42e679f9 ("drm/i915: Refactor code to select the DDI buf translation table")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.12+
Link: https://patchwork.freedesktop.org/patch/msgid/20171013154735.27163-1-chris@chris-wilson.co.uk
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Always stop the rings before a missing GPU reset

Always try to stop the rings, even if the GPU reset itself has been
disabled (via modparam i915.reset). This should at least stop the hw
from spinning in the background consuming resources (e.g. power and
memory bandwidth) letting the system rest-in-peace.

References: https://bugs.freedesktop.org/show_bug.cgi?id=103260
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171013131218.18013-2-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>

drm/i915: Keep the rings stopped until they have been re-initialized

Before modifying the ring register (RING_START, HEAD, TAIL, CTL) we
first make sure it is stopped (or else the hw may not resample the
registers). However, we do not need to let the hw restart until after we
have reprogrammed all the rings. This should help prevent situations
where pending operations on the ring may resume (because we are trying
to re-initialize following an unsuccessful GPU hang, i.e. from
i915_gem_unset_wedged).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103260
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171013131218.18013-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>

drm/i915: Stop asserting on set-wedged vs nop_submit_request ordering

Since the removal of the stop_machine(), it is allowed and expected for
the nop_submit_request() and nop_complete_submit_request() to run in
parallel to the i915_gem_set_wedged() processing. As such we can no
longer assert that i915_gem_set_wedged() has completed inside the
stop_machine prior to the individual nop_submit_request execution.

Fixes: af7a8ffad9c5 ("drm/i915: Use rcu instead of stop_machine in set_wedged")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171012204019.3557-1-chris@chris-wilson.co.uk
Reviewed-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>

drm: Replace kzalloc with kcalloc

Prefer kcalloc over kzalloc to allocate an array.
This patch fixes checkcpatch issue.

Signed-off-by: Harsha Sharma <harshasharmaiitr@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171013073747.29877-1-harshasharmaiitr@gmail.com
Link: https://patchwork.freedesktop.org/patch/msgid/20171013073747.29877-1-harshasharmaiitr@gmail.com

drm/i915: Split intel_enable_ddi() into DP and HDMI variants

Untangle intel_enable_ddi() by splitting it into DP and HDMI specific
variants.

v2: Keep using intel_ddi_get_encoder_port() for now

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-10-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Plumb crtc_state etc. directly to intel_ddi_pre_enable_{dp,hdmi}()

Rather that plumb the link parameters separately to
intel_ddi_pre_enable_dp() let's just pass the entire crtc state.

intel_ddi_pre_enable_hdmi() already took the crtc state, but for some
reason intel_ddi_pre_enable() still wanted to extract has_infoframe
from therein and pass it in separately. Let's not do that since it's
pointless.

v2: Rebase due to more code getting pulled into the DDI hooks

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Split intel_disable_ddi() into DP vs. HDMI variants

Untangle intel_disable_ddi() by splitting it into DP and HDMI specific
variants.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Remove useless eDP check from intel_ddi_pre_enable_dp()

intel_edp_panel_on() will itself do the is_edp() check, so the caller
doesn't have to bother. Pre-DDI code doesn't bother, so let's follow the
same approach for DDI.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-7-ville.syrjala@linux.intel.com

drm/i915: Split intel_ddi_post_disable() into DP vs. HDMI variants

To clean up the mess in intel_ddi_post_disable() split it into two
clean variants for HDMI and DP.

v2: Rebase due to MST DPMS changes

Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-6-ville.syrjala@linux.intel.com

drm/i915: Inline the required bits of intel_ddi_post_disable() into intel_ddi_fdi_post_disable()

To untangle the mess that is intel_ddi_post_disable() move the the bits
needed by FDI into intel_ddi_fdi_post_disable(). This way we can stop
worrying about FDI in intel_ddi_post_disable().

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-5-ville.syrjala@linux.intel.com

drm/i915: Extract intel_disable_ddi_buf()

Extract the code to disable the DDI_BUF_CTL into small helper. This
will allows us to detangle the encoder type mess in
intel_ddi_post_disable().

v2: Keep using intel_ddi_get_encoder_port() for now

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-4-ville.syrjala@linux.intel.com

drm/i915: Extract intel_ddi_clk_disable()

Pull the code to disable the port clock into a function. We already have
the intel_ddi_clk_select() counterpart.

v2: Keep using intel_ddi_get_encoder_port() for now (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Dump 'output_types' in crtc state dump

To make it easier to debug things let's dump the output types bitmask in
the crtc state dump. And to make life that much better, let's pretty
print it as a a human reaadable string as well.

v2: Have the caller pass in the buffer (Chris)
    #undef OUTPUT_TYPE (Jani)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/tinydrm: Remove explicit .best_encoder assignment

Since the driver is relying on the atomic helpers, remove the explicit
.best_encoder assignment and let the core call
drm_atomic_helper_best_encoder().

Signed-off-by: Haneen Mohammed <hamohammed.sa@gmail.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010205858.GA4806@Haneen

drm/tinydrm: Replace dev_error with DRM_DEV_ERROR

Convert instances of dev_error to DRM_DEV_ERROR as we have
DRM_DEV_ERROR variants of drm print macros.

Signed-off-by: Harsha Sharma <harshasharmaiitr@gmail.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171006221738.30200-1-harshasharmaiitr@gmail.com

drm/drm_of: Move drm_of_panel_bridge_remove_function into header.

Core drm shouldn't depend on anything in drm-kms-helper, or the drm
module will fail to load.

insmod drm fails with
[ 6087.674390] drm: Unknown symbol drm_panel_bridge_remove (err 0)

which is defined in drm_kms_helper.ko

This call was added by commit c70087e8f16f ("drm/drm_of: add
drm_of_panel_bridge_remove function"), and the fix is defining it in the
drm_of.h header, to break the circular dependency.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8f95e623-9480-97dc-2414-77086d8aa49d@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@intel.com> #irc
Fixes: c70087e8f16f ("drm/drm_of: add drm_of_panel_bridge_remove function")
Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>

drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()

Replace instances of drm_framebuffer_reference/unreference() with
*_get/put() suffixes and drm_dev_unref with *_put() suffix
because get/put is shorter and consistent with the
kernel use of *_get/put suffixes.
Done with following coccinelle semantic patch

@@
expression ex;
@@

(
-drm_framebuffer_unreference(ex);
+drm_framebuffer_put(ex);
|
-drm_dev_unref(ex);
+drm_dev_put(ex);
|
-drm_framebuffer_reference(ex);
+drm_framebuffer_get(ex);
)

Signed-off-by: Harsha Sharma <harshasharmaiitr@gmail.com>
[danvet: Drop the drm_dev_put change for now, to make the patch apply
with out a backmerge.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171009120643.11953-1-harshasharmaiitr@gmail.com

drm/i915: Get rid of hardcoded pipes

Favor for_each_pipe() macro when looping through pipes.

Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1507890286-16214-1-git-send-email-mika.kahola@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/atomic-helper: Fix reference to drm_crtc_send_vblank_event()

Fix up this reference so that the proper link is generated in the
documentation and so that people don't go chasing after the wrong
function for an embarrassingly long time.

Acked-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171012140857.9559-1-thierry.reding@gmail.com

drm/atomic-helper: Fix typo

Fix "esay-to-use" to "easy-to-use" typo.

Acked-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171012140616.9002-1-thierry.reding@gmail.com

drm: Add missing __user annotation to drm_syncobj_array_find()

'user_handles' needs a __user annotation for fix the following sparse
warning:
drm_syncobj.c:813:37: warning: incorrect type in argument 2 (different address spaces)
drm_syncobj.c:813:37:    expected void const [noderef] <asn:1>*from
drm_syncobj.c:813:37:    got void *user_handles
drm_syncobj.c:875:38: warning: incorrect type in argument 2 (different address spaces)
drm_syncobj.c:875:38:    expected void *user_handles
drm_syncobj.c:875:38:    got void [noderef] <asn:1>*<noident>
drm_syncobj.c:908:38: warning: incorrect type in argument 2 (different address spaces)
drm_syncobj.c:908:38:    expected void *user_handles
drm_syncobj.c:908:38:    got void [noderef] <asn:1>*<noident>
drm_syncobj.c:941:38: warning: incorrect type in argument 2 (different address spaces)
drm_syncobj.c:941:38:    expected void *user_handles
drm_syncobj.c:941:38:    got void [noderef] <asn:1>*<noident>

Cc: Jason Ekstrand <jason@jlekstrand.net>
Fixes: 3e6fb72d6cef ("drm/syncobj: Add a syncobj_array_find helper")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170901165328.24459-2-ville.syrjala@linux.intel.com
Reviewed-by: Thierry Reding <treding@nvidia.com>

drm/tilcdc: Remove redundant OF_DETACHED flag setting

of_fdt_unflatten_tree() already sets the flag on this node to
OF_DETACHED, because of_fdt_unflatten_tree() calls
__unflatten_device_tree() with the detached bool set to true.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Jyri Sarha <jsarha@ti.com>

drm/tilcdc: Precalculate total frametime in tilcdc_crtc_set_mode()

We need the total frame refresh time to check if we are too close to
vertical sync when updating the two framebuffer DMA registers and risk
a collision. This new method is more accurate that the previous that
based on mode's vrefresh value, which itself is inaccurate or may not
even be initialized.

Reported-by: Kevin Hao <kexin.hao@windriver.com>
Fixes: 11abbc9f39e0 ("drm/tilcdc: Set framebuffer DMA address to HW only if CRTC is enabled")
Cc: <stable@vger.kernel.org> # v4.11+
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm/i915: Add retries for LSPCON detection

We read the dp dual mode Adapter identifier to detect the
LSPCON device. It's been observed from the CI testing that in
few cases, this read can get delayed or fail. For such scenarios,
LSPCON vendors suggest to retry the read operation.

This patch adds retry in the probe function, while reading
LSPCON identifier.

V3: added this patch in the series

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102294
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102295
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102359
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103186
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1507630064-17908-4-git-send-email-shashank.sharma@intel.com

drm/i915: Don't give up waiting on INVALID_MODE

Our current logic to read LSPCON's current mode, stops retries and
breaks wait-loop, if it gets LSPCON_MODE_INVALID as return from the
core function. This doesn't allow us to try reading the mode again.

This patch removes this condition and allows retries reading
the currnt mode until timeout.

This also fixes/prevents some of the noise in form of debug messages
while running IGT CI test cases.

V2: rebase, added r-b
V2: changed some debug message levels from debug->error and
    error->debug in lspcon_get_current_mode function.
V3: Rebase

Cc: Imre Deak <imre.deak@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102294
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102295
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102359
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103186
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Mahesh Kumar <Mahesh1.kumar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1507630064-17908-3-git-send-email-shashank.sharma@intel.com

drm: Add retries for lspcon mode detection

From the CI builds, its been observed that during a driver
reload/insert, dp dual mode read function sometimes fails to
read from LSPCON device over i2c-over-aux channel.

This patch:
- adds some delay and few retries, allowing a scope for these
  devices to settle down and respond.
- changes one error log's level from ERROR->DEBUG as we want
  to call it an error only after all the retries are exhausted.

V2: Addressed review comments from Jani (for loop for retry)
V3: Addressed review comments from Imre (break on partial read too)
V3: Addressed review comments from Ville/Imre (Add the retries
    exclusively for LSPCON, not for all dp_dual_mode devices)
V4: Added r-b from Imre, sending it to dri-devel (Jani)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102294
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102295
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102359
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103186
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1507826408-19322-1-git-send-email-shashank.sharma@intel.com

drm/i915/bdw: Fix DP_AUX_CH_CTL_TIME_OUT setting

Per BSpec, 400us is "BDW+ Do not use this setting." - not just PORT_A.
Set BDW to 600us unconditionally.

v2:
-Split in to two patches (Rodrigo)

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: James Ausmus <james.ausmus@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171012213037.4245-2-james.ausmus@intel.com

drm/i915: Fix DP_AUX_CH_CTL_TIME_OUT naming

Rename DP_AUX_CH_CTL_TIME_OUT_1600us to DP_AUX_CH_CTL_TIME_OUT_MAX, as
the meaning of the (3 << 26) value varies per platform, but it's always the
maximum timeout for that platform. Pre-CNL it means 1600us, and for CNL
it means 3200us.

v2:
-Split in to two patches (Rodrigo)

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: James Ausmus <james.ausmus@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171012213037.4245-1-james.ausmus@intel.com

Merge tag 'omapdrm-4.15' of git://git./linux/kernel/git/tomba/linux into drm-next

omapdrm changes for 4.15

* OMAP4 HDMI CEC support

* tag 'omapdrm-4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
  omapdrm: omapdss_hdmi_ops: add lost_hotplug op
  omapdrm: hdmi4: hook up the HDMI CEC support
  omapdrm: hdmi4_cec: add OMAP4 HDMI CEC support
  omapdrm: hdmi4: refcount hdmi_power_on/off_core
  omapdrm: hdmi4: move hdmi4_core_powerdown_disable to hdmi_power_on_core()
  omapdrm: hdmi4: prepare irq handling for HDMI CEC support
  omapdrm: hdmi4: make low-level functions available
  omapdrm: hdmi.h: extend hdmi_core_data with CEC fields
  omapdrm: encoder-tpd12s015: keep ls_oe_gpio high

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

More 4.15 drm-misc stuff:

Cross-subsystem Changes:
- bridge cleanup refactor (Benjamin Gaignard)

Core Changes:
- less surprising atomic iterators (Maarten), fixes an oops introduced
  in drm-next
- better gem/fb helper docs (Noralf)
- fix dma-buf rcu races (Christian König)

Driver Changes:
- adv7511: CEC support (Hans Verkuil)
- sun4i update from Chen-Yu to improve hdmi and A31 support
- sii8620: add remote control support (Maceiej Purski)

New drivers:
- SiI9234 bridge driver (Maciej Purski)
- 7" rpi touch panel (Eric Anholt)

Note that this contains a topic pull from regmap, needed by the sun4i
changes. Mark Brown sent that out for pulling into drm-misc.

* tag 'drm-misc-next-2017-10-12' of git://anongit.freedesktop.org/drm/drm-misc: (29 commits)
  drm/dp: WARN about invalid/unknown link rates and bw codes
  drm/msm/mdp5: remove less than 0 comparison for unsigned value
  drm/bridge/sii8620: add remote control support
  drm/sun4i: hdmi: Add support for A31's HDMI controller
  drm/sun4i: hdmi: Add A31 specific DDC register definitions
  drm/sun4i: hdmi: Add support for controller hardware variants
  dt-bindings: display: sun4i: Add binding for A31 HDMI controller
  drm/sun4i: hdmi: Allow using second PLL as TMDS clk parent
  drm/sun4i: hdmi: create a regmap for later use
  drm/sun4i: hdmi: Disable clks in bind function error path and unbind function
  drm/sun4i: tcon: Add support for demuxing TCON output on A31
  drm/sun4i: tcon: Add variant callback for TCON output muxing
  drm/bridge/synopsys: dsi :remove is_panel_bridge
  drm/vc4: remove bridge from driver internal structure
  drm/stm: ltdc: remove bridge from driver internal structure
  drm/drm_of: add drm_of_panel_bridge_remove function
  drm/bridge: make drm_panel_bridge_remove more robust
  dma-fence: fix dma_fence_get_rcu_safe v2
  dma-buf: make reservation_object_copy_fences rcu save
  drm/atomic: Unref duplicated drm_atomic_state in drm_atomic_helper_resume()
  ...

drm/rockchip: add PINCTRL dependency for LVDS

The new driver fails to build when CONFIG_PINCTRL is disabled:

drivers/gpu/drm/rockchip/rockchip_lvds.c: In function 'rockchip_lvds_grf_config':
drivers/gpu/drm/rockchip/rockchip_lvds.c:229:39: error: dereferencing pointer to incomplete type 'struct dev_pin_info'
   if (lvds->pins && !IS_ERR(lvds->pins->default_state))

This adds the respective Kconfig dependency.

Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171005120957.485433-1-arnd@arndb.de

drm: vblank: remove drm_timestamp_monotonic parameter

There is a risk of overflowing vblank timestamps in 2038 or 2106 if
someone sets the drm_timestamp_monotonic module parameter to zero.

I found no indication of anyone ever setting the parameter, or
complaining about the default being wrong, after it was introduced
as a way to handle backwards-compatibility with linux prior to
c61eef726a78 ("drm: add support for monotonic vblank timestamps"),
so it's probably safer to just remove the parameter completely
and only allowing the default behavior.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: vblank: use ktime_t instead of timeval

The drm vblank handling uses 'timeval' to store timestamps in either
monotonic or wall-clock time base. In either case, it reads the current
time as a ktime_t in get_drm_timestamp() and converts it from there.

This is a bit suspicious, as users of 'timeval' often suffer from
the time_t overflow in y2038. I have gone through this code and
found that it is unlikely to cause problems here:

- The user space ABI does not use time_t or timeval, but uses
  'u32' and 'long' as the types. This means at least that rebuilding
  user programs against a new libc with 64-bit time_t does not
  change the ABI.

- As of commit c61eef726a78 ("drm: add support for monotonic vblank
  timestamps") in linux-3.8, the monotonic timestamp is the default
  and can only get reverted to wall-clock through a module-parameter.

- With the default monotonic timestamps, there is no problem at all.

- The drm_wait_vblank_ioctl() interface is alway safe on 64-bit
  architectures, on 32-bit it might overflow the 'long' timestamps
  in 2038 with wall-clock timestamps.

- The event handling uses 'u32' seconds, which overflow in 2106
  on both 32-bit and 64-bit machines, when wall-clock timestamps
  are used.

- The effect of overflowing either of the two is only temporary
  (during the overflow, and is likely to keep working again
  afterwards. It is likely the same problem as observing a
  'settimeofday()' call, which was the reason for moving to the
  monotonic timestamps in the first place.

Overall, this seems good enough, so my patch removes the use of
'timeval' from the vblank handling altogether and uses ktime_t
consistently, except for the part where we copy the data to user
space structures in the existing format.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/i915/selftests: Exercise adding requests to a full GGTT

A bug recently encountered involved the issue where are we were
submitting requests to different ppGTT, each would pin a segment of the
GGTT for its logical context and ring. However, this is invisible to
eviction as we do not tie the context/ring VMA to a request and so do
not automatically wait upon it them (instead they are marked as pinned,
preventing eviction entirely). Instead the eviction code must flush those
contexts by switching to the kernel context. This selftest tries to
fill the GGTT with contexts to exercise a path where the
switch-to-kernel-context failed to make forward progress and we fail
with ENOSPC.

v2: Make the hole in the filled GGTT explicit.
v3: Swap out the arbitrary timeout for a private notification from
i915_gem_evict_something()

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171012125726.14736-3-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

drm/i915/selftests: Wrap a timer into a i915_sw_fence

For some selftests, we want to issue requests but delay them going to
hardware. Furthermore, we don't want those requests to block
indefinitely (or else we may hang the driver and block testing) so we
want to employ a timeout. So naturally we want a fence that is
automatically signaled by a timer.

v2: Add kselftests.
v3: Limit the API available to selftests; there isn't an overwhelming
reason to export it universally.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171012125726.14736-2-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

drm/i915: Fix eviction when the GGTT is idle but full

In the full-ppgtt world, we can fill the GGTT full of context objects.
These context objects are currently implicitly tracked by the requests
that pin them i.e. they are only unpinned when the request is completed
and retired, but we do not have the link from the vma to the request
(anymore). In order to unpin those contexts, we have to issue another
request and wait upon the switch to the kernel context.

The bug during eviction was that we assumed that a full GGTT meant we
would have requests on the GGTT timeline, and so we missed situations
where those requests where merely in flight (and when even they have not
yet been submitted to hw yet). The fix employed here is to change the
already-is-idle test to no look at the execution timeline, but count the
outstanding requests and then check that we have switched to the kernel
context. Erring on the side of overkill here just means that we stall a
little longer than may be strictly required, but we only expect to hit
this path in extreme corner cases where returning an erroneous error is
worse than the delay.

v2: Logical inversion when swapping over branches.

Fixes: 80b204bce8f2 ("drm/i915: Enable multiple timelines")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171012125726.14736-1-chris@chris-wilson.co.uk

drm/i915: Start tracking PSR state in crtc state

Add the minimal amount of PSR tracking into the crtc state. This allows
precomputing the possibility of using PSR correctly, and it means we can
safely call the psr enable/disable functions for any DP endcoder.

As a nice bonus we get rid of some more crtc->config usage, which we
want to kill off eventually.

v2: Fix 'goto unlock' fail in intel_psr_enable() (Jani)
    Check intel_dp_is_edp() in is_edp_psr() (Jani)

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171012130201.21318-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

drm/kirin: Checking for IS_ERR() instead of NULL

The of_graph_get_remote_node() function doesn't return error pointers,
it returns NULL on error so I've updated the check.

Fixes: 86418f90a4c1 ("drm: convert drivers to use of_graph_get_remote_node")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171005125751.jvtjms62vbtxuvak@mwanda

drm/i915: Update DRIVER_DATE to 20171012

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

driver:gpu: return -ENOMEM on allocation failure.

Signed-off-by: Allen Pais <allen.lkml@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1505287939-14106-3-git-send-email-allen.lkml@gmail.com

drm/vblank: Fix flip event vblank count

On machines where the vblank interrupt fires some time after the start
of vblank (or we just manage to race with the vblank interrupt handler)
we will currently stuff a stale vblank counter value into the flip event,
and thus we'll prematurely complete the flip.

Switch over to drm_crtc_accurate_vblank_count() to make sure we have an
up to date counter value, crucially also remember to add the +1 so that
the delayed vblank interrupt won't complete the flip prematurely.

Cc: stable@vger.kernel.org
Cc: Daniel Vetter <daniel@ffwll.ch>
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010133322.24029-1-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel@ffwll.ch> #irc

drm/i915: Simplify intel_sanitize_enable_ppgtt

Remove dead code around has_aliasing_ppgtt condition.

Suggested-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010143355.16577-1-joonas.lahtinen@linux.intel.com

drm/i915/userptr: Drop struct_mutex before cleanup

Purely to silence lockdep, as we know that no bo can exist at this time
and so the inversion is impossible. Nevertheless, lockdep currently
warns on unload:

[  137.522565] WARNING: possible circular locking dependency detected
[  137.522568] 4.14.0-rc4-CI-CI_DRM_3209+ #1 Tainted: G     U
[  137.522570] ------------------------------------------------------
[  137.522572] drv_module_relo/1532 is trying to acquire lock:
[  137.522574]  ("i915-userptr-acquire"){+.+.}, at: [<ffffffff8109a831>] flush_workqueue+0x91/0x540
[  137.522581]
               but task is already holding lock:
[  137.522583]  (&dev->struct_mutex){+.+.}, at: [<ffffffffa014fb3f>] i915_gem_fini+0x3f/0xc0 [i915]
[  137.522605]
               which lock already depends on the new lock.

[  137.522608]
               the existing dependency chain (in reverse order) is:
[  137.522611]
               -> #3 (&dev->struct_mutex){+.+.}:
[  137.522615]        __lock_acquire+0x1420/0x15e0
[  137.522618]        lock_acquire+0xb0/0x200
[  137.522621]        __mutex_lock+0x86/0x9b0
[  137.522623]        mutex_lock_interruptible_nested+0x1b/0x20
[  137.522640]        i915_mutex_lock_interruptible+0x51/0x130 [i915]
[  137.522657]        i915_gem_fault+0x20b/0x720 [i915]
[  137.522660]        __do_fault+0x1e/0x80
[  137.522662]        __handle_mm_fault+0xa08/0xed0
[  137.522664]        handle_mm_fault+0x156/0x300
[  137.522666]        __do_page_fault+0x2c5/0x570
[  137.522668]        do_page_fault+0x28/0x250
[  137.522671]        page_fault+0x22/0x30
[  137.522672]
               -> #2 (&mm->mmap_sem){++++}:
[  137.522677]        __lock_acquire+0x1420/0x15e0
[  137.522679]        lock_acquire+0xb0/0x200
[  137.522682]        down_read+0x3e/0x70
[  137.522699]        __i915_gem_userptr_get_pages_worker+0x141/0x240 [i915]
[  137.522701]        process_one_work+0x233/0x660
[  137.522704]        worker_thread+0x4e/0x3b0
[  137.522706]        kthread+0x152/0x190
[  137.522708]        ret_from_fork+0x27/0x40
[  137.522710]
               -> #1 ((&work->work)){+.+.}:
[  137.522714]        __lock_acquire+0x1420/0x15e0
[  137.522717]        lock_acquire+0xb0/0x200
[  137.522719]        process_one_work+0x206/0x660
[  137.522721]        worker_thread+0x4e/0x3b0
[  137.522723]        kthread+0x152/0x190
[  137.522725]        ret_from_fork+0x27/0x40
[  137.522727]
               -> #0 ("i915-userptr-acquire"){+.+.}:
[  137.522731]        check_prev_add+0x430/0x840
[  137.522733]        __lock_acquire+0x1420/0x15e0
[  137.522735]        lock_acquire+0xb0/0x200
[  137.522738]        flush_workqueue+0xb4/0x540
[  137.522740]        drain_workqueue+0xd4/0x1b0
[  137.522742]        destroy_workqueue+0x1c/0x200
[  137.522758]        i915_gem_cleanup_userptr+0x15/0x20 [i915]
[  137.522770]        i915_gem_fini+0x5f/0xc0 [i915]
[  137.522782]        i915_driver_unload+0x122/0x180 [i915]
[  137.522794]        i915_pci_remove+0x19/0x30 [i915]
[  137.522797]        pci_device_remove+0x39/0xb0
[  137.522800]        device_release_driver_internal+0x15d/0x220
[  137.522803]        driver_detach+0x40/0x80
[  137.522805]        bus_remove_driver+0x58/0xd0
[  137.522807]        driver_unregister+0x2c/0x40
[  137.522809]        pci_unregister_driver+0x36/0xb0
[  137.522828]        i915_exit+0x1a/0x8b [i915]
[  137.522831]        SyS_delete_module+0x18c/0x1e0
[  137.522834]        entry_SYSCALL_64_fastpath+0x1c/0xb1
[  137.522835]
               other info that might help us debug this:

[  137.522838] Chain exists of:
                 "i915-userptr-acquire" --> &mm->mmap_sem --> &dev->struct_mutex

[  137.522844]  Possible unsafe locking scenario:

[  137.522846]        CPU0                    CPU1
[  137.522848]        ----                    ----
[  137.522850]   lock(&dev->struct_mutex);
[  137.522852]                                lock(&mm->mmap_sem);
[  137.522854]                                lock(&dev->struct_mutex);
[  137.522857]   lock("i915-userptr-acquire");
[  137.522859]
                *** DEADLOCK ***

[  137.522862] 3 locks held by drv_module_relo/1532:
[  137.522864]  #0:  (&dev->mutex){....}, at: [<ffffffff8161d47b>] device_release_driver_internal+0x2b/0x220
[  137.522869]  #1:  (&dev->mutex){....}, at: [<ffffffff8161d489>] device_release_driver_internal+0x39/0x220
[  137.522873]  #2:  (&dev->struct_mutex){+.+.}, at: [<ffffffffa014fb3f>] i915_gem_fini+0x3f/0xc0 [i915]
[  137.522888]
               stack backtrace:
[  137.522891] CPU: 0 PID: 1532 Comm: drv_module_relo Tainted: G     U          4.14.0-rc4-CI-CI_DRM_3209+ #1
[  137.522894] Hardware name:                  /NUC7i5BNB, BIOS BNKBL357.86A.0048.2017.0704.1415 07/04/2017
[  137.522897] Call Trace:
[  137.522900]  dump_stack+0x68/0x9f
[  137.522902]  print_circular_bug+0x235/0x3c0
[  137.522905]  ? lockdep_init_map_crosslock+0x20/0x20
[  137.522908]  check_prev_add+0x430/0x840
[  137.522919]  ? i915_gem_fini+0x5f/0xc0 [i915]
[  137.522922]  ? __kernel_text_address+0x12/0x40
[  137.522925]  ? __save_stack_trace+0x66/0xd0
[  137.522928]  __lock_acquire+0x1420/0x15e0
[  137.522930]  ? __lock_acquire+0x1420/0x15e0
[  137.522933]  ? lockdep_init_map_crosslock+0x20/0x20
[  137.522936]  ? __this_cpu_preempt_check+0x13/0x20
[  137.522938]  lock_acquire+0xb0/0x200
[  137.522940]  ? flush_workqueue+0x91/0x540
[  137.522943]  flush_workqueue+0xb4/0x540
[  137.522945]  ? flush_workqueue+0x91/0x540
[  137.522948]  ? __mutex_unlock_slowpath+0x43/0x2c0
[  137.522951]  ? trace_hardirqs_on_caller+0xe3/0x1b0
[  137.522954]  drain_workqueue+0xd4/0x1b0
[  137.522956]  ? drain_workqueue+0xd4/0x1b0
[  137.522958]  destroy_workqueue+0x1c/0x200
[  137.522975]  i915_gem_cleanup_userptr+0x15/0x20 [i915]
[  137.522987]  i915_gem_fini+0x5f/0xc0 [i915]
[  137.523000]  i915_driver_unload+0x122/0x180 [i915]
[  137.523015]  i915_pci_remove+0x19/0x30 [i915]
[  137.523018]  pci_device_remove+0x39/0xb0
[  137.523021]  device_release_driver_internal+0x15d/0x220
[  137.523023]  driver_detach+0x40/0x80
[  137.523026]  bus_remove_driver+0x58/0xd0
[  137.523028]  driver_unregister+0x2c/0x40
[  137.523030]  pci_unregister_driver+0x36/0xb0
[  137.523049]  i915_exit+0x1a/0x8b [i915]
[  137.523052]  SyS_delete_module+0x18c/0x1e0
[  137.523055]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[  137.523057] RIP: 0033:0x7f7bd0609287
[  137.523059] RSP: 002b:00007ffef694bc18 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
[  137.523062] RAX: ffffffffffffffda RBX: ffffffff81493f33 RCX: 00007f7bd0609287
[  137.523065] RDX: 0000000000000001 RSI: 0000000000000800 RDI: 0000564f999f9fc8
[  137.523067] RBP: ffffc90005c4ff88 R08: 0000000000000000 R09: 0000000000000080
[  137.523069] R10: 00007f7bd20ef8c0 R11: 0000000000000246 R12: 0000000000000000
[  137.523072] R13: 00007ffef694be00 R14: 0000000000000000 R15: 0000000000000000
[  137.523075]  ? __this_cpu_preempt_check+0x13/0x20

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171011141857.14161-1-chris@chris-wilson.co.uk
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

omapdrm: omapdss_hdmi_ops: add lost_hotplug op

The CEC framework needs to know when the hotplug detect signal
disappears, since that means the CEC physical address has to be
invalidated (i.e. set to f.f.f.f).

Add a lost_hotplug op that is called when the HPD signal goes away.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

omapdrm: hdmi4: hook up the HDMI CEC support

Hook up the HDMI CEC support in the hdmi4 driver.

It add the CEC irq handler, the CEC (un)init calls and tells the CEC
implementation when the physical address changes.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

omapdrm: hdmi4_cec: add OMAP4 HDMI CEC support

Add the source and header for the OMAP4 HDMI CEC support.

This code is not yet hooked up, that will happen in the next patch.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>