drm/i915/guc: Don't GEM_BUG_ON on corrupted G2H CTB

We should never BUG_ON on any corruption in CTB descriptor as
data there can be also modified by the GuC. Instead we can
use flag "is_in_error" to indicate that we will not process
any further messages over this CTB (until reset). While here
move descriptor error reporting to the function that actually
touches that descriptor.

Note that unexpected content of the specific CT messages, that
still complies with generic CT message format, shall not trigger
disabling whole CTB, as that might just indicate new unsupported
message types.

v2: drop redundant message (Daniele)

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117082039.65644-2-michal.wajdeczko@intel.com

drm/i915: Satisfy smatch that a loop has at least one iteration

Smatch worries that the engine->mask may be 0 leading to the loop being
shortcircuited leaving the next pointer unset,

drivers/gpu/drm/i915/i915_active.c:667 i915_active_acquire_preallocate_barrier() error: uninitialized symbol 'next'.

Assert that mask is not 0 and smatch can then verify that next must be
initialised before use.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117110603.2982286-1-chris@chris-wilson.co.uk

drm/i915: Fix typo in kerneldoc function name

A forgetful copy'n'paste left the name of the old function intact, and
did not introduce the new function 'i915_request_is_ready'

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117101639.2908469-1-chris@chris-wilson.co.uk

drm/i915: Fix i915_error_state_store error defination

Since commit 742379c0c4001 ("drm/i915: Start chopping up the GPU error
capture"), function 'i915_error_state_store' was defined and used with
only one parameter.

But if no 'CONFIG_DRM_I915_CAPTURE_ERROR', this function was defined
with two parameter.

This may lead compile error. This patch fix it.

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200117073436.6507-1-zhangxiaoxu5@huawei.com

drm/i915: Include the debugfs params header for its own definition

drivers/gpu/drm/i915/i915_debugfs_params.c:228:15: warning: symbol 'i915_debugfs_params' was not declared. Should it be static?
drivers/gpu/drm/i915/i915_debugfs_params.c:228:16: error: no previous prototype for ‘i915_debugfs_params’ [-Werror=missing-prototypes]
  228 | struct dentry *i915_debugfs_params(struct drm_i915_private *i915)

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Fixes: c43c5a8818d4 ("drm/i915/params: add i915 parameters to debugfs")
Link: https://patchwork.freedesktop.org/patch/msgid/20200117102145.2948244-1-chris@chris-wilson.co.uk

drm/i915: Auto detect DPCD backlight support by default

Turns out we actually already have some companies, such as Lenovo,
shipping machines with AMOLED screens that don't allow controlling the
backlight through the usual PWM interface and only allow controlling it
through the standard EDP DPCD interface. One example of one of these
laptops is the X1 Extreme 2nd Generation.

Since we've got systems that need this turned on by default now to have
backlight controls working out of the box, let's start auto-detecting it
for systems by default based on what the VBT tells us. We do this by
changing the default value for the enable_dpcd_backlight module param
from 0 to -1.

Tested-by: AceLan Kao <acelan.kao@canonical.com>
Tested-by: Perry Yuan <pyuan@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200116211623.53799-6-lyude@redhat.com

drm/i915: Fix DPCD register order in intel_dp_aux_enable_backlight()

For eDP panels, it appears it's expected that so long as the panel is in
DPCD control mode that the brightness value is never set to 0. Instead,
if the desired effect is to set the panel's backlight to 0 we're
expected to simply turn off the backlight through the
DP_EDP_DISPLAY_CONTROL_REGISTER.

We already do the latter correctly in intel_dp_aux_disable_backlight().
But, we make the mistake of writing the DPCD registers in the wrong
order when enabling the backlight in intel_dp_aux_enable_backlight()
since we currently enable the backlight through
DP_EDP_DISPLAY_CONTROL_REGISTER before writing the brightness level. On
the X1 Extreme 2nd Generation, this appears to have the potential of
confusing the panel in such a way that further attempts to set the
brightness don't actually change the backlight as expected and leave it
off. Presumably, this happens because the incorrect register writing
order briefly leaves the panel with DPCD mode enabled and a 0 brightness
level set.

So, reverse the order we write the DPCD registers when enabling the
panel backlight so that we write the brightness value first, and enable
the backlight second. This fix appears to be the final bit needed to get
the backlight on the ThinkPad X1 Extreme 2nd Generation's AMOLED screen
working.

Tested-by: AceLan Kao <acelan.kao@canonical.com>
Tested-by: Perry Yuan <pyuan@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200116211623.53799-4-lyude@redhat.com

drm/i915: Assume 100% brightness when not in DPCD control mode

Currently we always determine the initial panel brightness level by
simply reading the value from DP_EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB. This
seems wrong though, because if the panel is not currently in DPCD
control mode there's not really any reason why there would be any
brightness value programmed in the first place.

This appears to be the case on the Lenovo ThinkPad X1 Extreme 2nd
Generation, where the default value in these registers is always 0 on
boot despite the fact the panel runs at max brightness by default.
Getting the initial brightness value correct here is important as well,
since the panel on this laptop doesn't behave well if it's ever put into
DPCD control mode while the brightness level is programmed to 0.

So, let's fix this by checking what the current backlight control mode
is before reading the brightness level. If it's in DPCD control mode, we
return the programmed brightness level. Otherwise we assume 100%
brightness and return the highest possible brightness level. This also
prevents us from accidentally programming a brightness level of 0.

This is one of the many fixes that gets backlight controls working on
the ThinkPad X1 Extreme 2nd Generation with optional 4K AMOLED screen.

Changes since v1:
* s/DP_EDP_DISPLAY_CONTROL_REGISTER/DP_EDP_BACKLIGHT_MODE_SET_REGISTER/
  - Jani

Tested-by: AceLan Kao <acelan.kao@canonical.com>
Tested-by: Perry Yuan <pyuan@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200116211623.53799-3-lyude@redhat.com

drm/i915: Fix eDP DPCD aux max backlight calculations

Max backlight value for the panel was being calculated using byte
count i.e. 0xffff if 2 bytes are supported for backlight brightness
and 0xff if 1 byte is supported. However, EDP_PWMGEN_BIT_COUNT
determines the number of active control bits used for the brightness
setting. Thus, even if the panel uses 2 byte setting, it might not use
all the control bits. Thus, max backlight should be set based on the
value of EDP_PWMGEN_BIT_COUNT instead of assuming 65535 or 255.

Additionally, EDP_PWMGEN_BIT_COUNT was being updated based on the VBT
frequency which results in a different max backlight value. Thus,
setting of EDP_PWMGEN_BIT_COUNT is moved to setup phase instead of
enable so that max backlight can be calculated correctly. Only the
frequency divider is set during the enable phase using the value of
EDP_PWMGEN_BIT_COUNT.

This is based off the original patch series from Furquan Shaikh
<furquan@google.com>:

https://patchwork.freedesktop.org/patch/317255/?series=62326&rev=3

Changes since original patch:
* Remove unused intel_dp variable in intel_dp_aux_setup_backlight()
* Fix checkpatch issues
* Make sure that we rewrite the pwmgen bit count whenever we bring the
  panel out of D3 mode

v2 by Jani:
* rebase
* fix readb return value check

Cc: Furquan Shaikh <furquan@google.com>
Tested-by: AceLan Kao <acelan.kao@canonical.com>
Tested-by: Perry Yuan <pyuan@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200116211623.53799-2-lyude@redhat.com

drm/i915/dsi: Lookup the i2c bus from ACPI NS only if CONFIG_ACPI=y (v2)

Perform the i2c bus/adapter lookup from ACPI Namespace only if ACPI is
enabled in the kernel config. If ACPI is not enabled or if the lookup
fails, we'll fallback to using the VBT for identifying the i2c bus.

v2: Add fixes tag (Jani)

Fixes: 8cbf89db2941 ("drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3)")
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115012305.27395-1-vivek.kasireddy@intel.com

drm/i915/execlists: Offline error capture

Currently, we skip error capture upon forced preemption. We apply forced
preemption when there is a higher priority request that should be
running but is being blocked, and we skip inline error capture so that
the preemption request is not further delayed by a user controlled
capture -- extending the denial of service.

However, preemption reset is also used for heartbeats and regular GPU
hangs. By skipping the error capture, we remove the ability to debug GPU
hangs.

In order to capture the error without delaying the preemption request
further, we can do an out-of-line capture by removing the guilty request
from the execution queue and scheduling a worker to dump that request.
When removing a request, we need to remove the entire context and all
descendants from the execution queue, so that they do not jump past.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/738
Fixes: 3a7a92aba8fb ("drm/i915/execlists: Force preemption")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200116184754.2860848-3-chris@chris-wilson.co.uk

drm/i915/gt: Allow temporary suspension of inflight requests

In order to support out-of-line error capture, we need to remove the
active request from HW and put it to one side while a worker compresses
and stores all the details associated with that request. (As that
compression may take an arbitrary user-controlled amount of time, we
want to let the engine continue running on other workloads while the
hanging request is dumped.) Not only do we need to remove the active
request, but we also have to remove its context and all requests that
were dependent on it (both in flight, queued and future submission).

Finally once the capture is complete, we need to be able to resubmit the
request and its dependents and allow them to execute.

v2: Replace stack recursion with a simple list.
v3: Check all the parents, not just the first, when searching for a
stuck ancestor!

References: https://gitlab.freedesktop.org/drm/intel/issues/738
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>
Link: https://patchwork.freedesktop.org/patch/msgid/20200116184754.2860848-2-chris@chris-wilson.co.uk

drm/i915: Keep track of request among the scheduling lists

If we keep track of when the i915_request.sched.link is on the HW
runlist, or in the priority queue we can simplify our interactions with
the request (such as during rescheduling). This also simplifies the next
patch where we introduce a new in-between list, for requests that are
ready but neither on the run list or in the queue.

v2: Update i915_sched_node.link explanation for current usage where it
is a link on both the queue and on the runlists.

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

drm/i915/psr: Share the computation of idle frames

Both activate functions and the dc3co disable function were doing the
same thing, so better move to a function and share.
Also while at it adding a WARN_ON to catch invalid values.

Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200113214603.52158-1-jose.souza@intel.com

drm/i915: add Wa_14010594013: icl,ehl

The bspec tells us we need to set this bit to avoid potential underruns.

v2: use new register write convention (Anshuman) add bspec 7386 ref.

Bspec: 7386
Bspec: 33450
Bspec: 33451

Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200114041128.11211-1-matthew.s.atwood@intel.com

drm/i915/gt: Drop rogue space in the middle of GT_TRACE

Remove the double space that crept into the fmt stringification.

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

drm/i915/execlists: Leave resetting ring to intel_ring

We need to allow concurrent intel_context_unpin, which means avoiding
doing destructive operations like intel_ring_reset(). This was already
fixed for intel_ring_unpin() in commit 0725d9a31869 ("drm/i915/gt: Make
intel_ring_unpin() safe for concurrent pint"), but I overlooked that
execlists_context_unpin() also made the same mistake.

Reported-by: Matthew Brost <matthew.brost@intel.com>
Fixes: 841350223816 ("drm/i915/gt: Drop mutex serialisation between context pin/unpin")
References: 0725d9a31869 ("drm/i915/gt: Make intel_ring_unpin() safe for concurrent pint")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115175829.2761329-1-chris@chris-wilson.co.uk

drm/i915/tgl: Add Wa_1409825376 to tgl

Workaround database indicates we should disable VRH clockgating
in pre-production hardware.

V2:
 - Use REG_BIT macro
 - Update reference in commit message(Matt)

Bspec: 52890
Bspec: 49424
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200109223727.5630-1-radhakrishna.sripada@intel.com

drm/i915/fbc: Add fbc tracepoints

Add tracepoints which let us know when fbc activates/deactivates/nukes.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191213133453.22152-5-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915/fbc: Nuke fbc_supported()

fbc_supported() is just a pointless wrapper for HAS_FBC(). Get
rid of it. In places where we're operating on a specific plane
we can replace this with a plane->has_fbc check to avoid
doing anything for crtcs that don't even support fbc.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191213133453.22152-4-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915/fbc: Move the plane state check into the fbc functions

Instead of dealing with the presence/absence of the primary
plane in the higher level pre/post plane update code let's
move all that into the fbc code itself. Now the higher level
code doesn't have to think about FBC details anymore.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191213133453.22152-3-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915/gt: Use the BIT when checking the flags, not the index

In converting over to using set_bit()/test_bit(), when manually
inspecting the rq->fence.flags, we need to use BIT().

Fixes: e1c31fb5dde3 ("drm/i915: Merge i915_request.flags with i915_request.fence.flags")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115122509.2673075-1-chris@chris-wilson.co.uk

drm/i915/params: support bool values for int and uint params

It's not uncommon for us to switch param types between bools and ints,
often having otherwise bool semantics but -1 value for platform
default. Allow bool values (such as YyNn) for ints.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c945ac7b08e0eb0827cf647609885f4abdb84f1d.1575560168.git.jani.nikula@intel.com

drm/i915/params: add i915 parameters to debugfs

Add a debugfs subdirectory i915_params with all the i915 module
parameters. This is a first step, with lots of boilerplate, and not much
benefit yet.

This will result in a new device specific debugfs directory at
/sys/kernel/debug/dri/<N>/i915_params duplicating the module specific
sysfs directory at /sys/module/i915/parameters/. Going forward, all
users of the parameters should use the debugfs, with the module
parameters being phased out.

Add debugfs permissions to I915_PARAMS_FOR_EACH(). This duplicates the
mode with module parameter sysfs, but the goal is to make the module
parameters read-only initial values for device specific parameters.

0 mode will bypass debugfs creation. Use it for verbose_state_checks
which will need special attention in follow-up work.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/600101c8433e7caf9303663fc85a9972fa1f05e7.1575560168.git.jani.nikula@intel.com

drm/i915/gen11: Add additional pcode status values

I don't think we've ever hit these new error codes, but they're
documented in the gen11 pcode document, so we might as well add them to
the handler.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200111014511.2988923-1-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

drm/i915/vbt: Rename BDB_LVDS_POWER to BDB_LFP_POWER

Renaming to match the BSpec and struct name.

BSpec: 20150
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110235045.176640-1-jose.souza@intel.com

drm/i915/dp/tgl+: Update combo phy vswing tables

TGL has now a table for RBR and HBR and another table for HBR2 over
combo phys. The HBR2 one has some small changes comparing to the ICL
one, so adding two new tables and adding a function to return TGL
combo phy tables.

v2:
- reordered the tgl_combo_phy_ddi_translations_dp_hbr2 to reduce diff
(Matt)
- removed definition of rates, kept using raw number(Jani and Ville)
- changed code to use icl_get_combo_buf_trans() for non-DP as those
are equal between TGL and ICL(Matt)

BSpec: 49291
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110233902.154960-1-jose.souza@intel.com

drm/i915/selftests: Add a mock i915_vma to the mock_ring

Add a i915_vma to the mock_engine/mock_ring so that the core code can
always assume the presence of ring->vma.

Fixes: 8ccfc20a7d56 ("drm/i915/gt: Mark ring->vma as active while pinned")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200114160030.2468927-1-chris@chris-wilson.co.uk

drm/i915: Make a copy of the ggtt view for slave plane

intel_prepare_plane_fb() will always pin plane_state->hw.fb whenever
it is present. We copy that from the master plane to the slave plane,
but we fail to copy the corresponding ggtt view. Thus when it comes time
to pin the slave plane's fb we use some stale ggtt view left over from
the last time the plane was used as a non-slave plane. If that previous
use involved 90/270 degree rotation or remapping we'll try to shuffle
the pages of the new fb around accordingingly. However the new
fb may be backed by a bo with less pages than what the ggtt view
rotation/remapped info requires, and so we we trip a GEM_BUG().

Steps to reproduce on icl:
1. plane 1: whatever
   plane 6: largish !NV12 fb + 90 degree rotation
2. plane 1: smallish NV12 fb
   plane 6: make invisible so it gets slaved to plane 1
3. GEM_BUG()

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/issues/951
Fixes: 1f594b209fe1 ("drm/i915: Remove special case slave handling during hw programming, v3.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110183228.8199-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915/gem: Take local vma references for the parser

Take and hold a reference to each of the vma (and their objects) as we
process them with the cmdparser. This stops them being freed during the
work if the GEM execbuf is interrupted and the request we expected to
keep the objects alive is incomplete.

Fixes: 686c7c35abc2 ("drm/i915/gem: Asynchronous cmdparser")
Closes: https://gitlab.freedesktop.org/drm/intel/issues/970
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200113154555.1909639-1-chris@chris-wilson.co.uk

drm/i915/guc: Use correct name for last CT fence

While we have function that returns "next fence" that can be used
by new CT request, we internally store value of the last used fence.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200111231114.59208-5-michal.wajdeczko@intel.com

drm/i915/guc: Update CTB helpers to use CT_ERROR

Update GuC CTB action helpers to benefit from new CT_ERROR macro.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200111231114.59208-4-michal.wajdeczko@intel.com

drm/i915/guc: Introduce CT_ERROR

We should start using dev variants of error logging and
to simplify that introduce helper macro that will do any
necessary conversions to obtain pointer to device struct.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200111231114.59208-3-michal.wajdeczko@intel.com

drm/i915/guc: Simpler CT message size calculation

We need CT message size in bytes so just use that in helper var.

Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200111231114.59208-2-michal.wajdeczko@intel.com

drm/i915/gt: Clear rc6 residency trackers across suspend

On suspend, the rc6 residency counters (stored in HW registers) will be
lost and cleared. However, we keep track of the rc6 residency to provide
a continuous 64b sampling, and if we see the HW value go backwards, we
assume it overflowed and add on 32b/40b -- an interesting artifact when
sampling across suspend.

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>
Link: https://patchwork.freedesktop.org/patch/msgid/20200114105648.2172026-2-chris@chris-wilson.co.uk

drm/i915/pmu: Correct the rc6 offset upon enabling

The rc6 residency starts ticking from 0 from BIOS POST, but the kernel
starts measuring the time from its boot. If we start measuruing
I915_PMU_RC6_RESIDENCY while the GT is idle, we start our sampling from
0 and then upon first activity (park/unpark) add in all the rc6
residency since boot. After the first park with the sampler engaged, the
sleep/active counters are aligned.

v2: With a wakeref to be sure

Closes: https://gitlab.freedesktop.org/drm/intel/issues/973
Fixes: df6a42053513 ("drm/i915/pmu: Ensure monotonic rc6")
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>
Link: https://patchwork.freedesktop.org/patch/msgid/20200114105648.2172026-1-chris@chris-wilson.co.uk

drm/i915: Update DRIVER_DATE to 20200114

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

drm/i915/gt: Always reset the timeslice after a context switch

Currently, we reset the timer after a pre-eemption event. This has the
side-effect that the timeslice runs into the second context after the
first is completed after a normal promotion event, causing the second
context to be swapped out early and switched for a third context. To be
more fair, we want to reset the clock after promotion as well.

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>
Link: https://patchwork.freedesktop.org/patch/msgid/20200113214546.1990139-1-chris@chris-wilson.co.uk

drm/i915: Fix too few arguments to function i915_capture_error_state

If 'CONFIG_DRM_I915_CAPTURE_ERROR' not configured, there is an error
when compile the kernel:

drivers/gpu/drm/i915/gt/intel_reset.c:
In function intel_gt_handle_error:
drivers/gpu/drm/i915/gt/intel_reset.c:1233:3:
error: too few arguments to function i915_capture_error_state
   i915_capture_error_state(gt->i915);
   ^~~~~~~~~~~~~~~~~~~~~~~~
In file included
         from ./drivers/gpu/drm/i915/i915_drv.h:97:0,
         from ./drivers/gpu/drm/i915/display/intel_display_types.h:46,
         from drivers/gpu/drm/i915/gt/intel_reset.c:10:
./drivers/gpu/drm/i915/i915_gpu_error.h:267:20: note: declared here
 static inline void i915_capture_error_state(struct drm_i915_private *dev_priv,

Fixes: 742379c0c400 ("drm/i915: Start chopping up the GPU error capture")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200113081942.15982-1-zhangxiaoxu5@huawei.com

drm/i915: Fix multiple definition of 'i915_vma_capture_finish'

If 'CONFIG_DRM_I915_CAPTURE_ERROR' not configured, there are some
errors like:

drivers/gpu/drm/i915/i915_irq.o:
In function `i915_vma_capture_finish':
./drivers/gpu/drm/i915/i915_gpu_error.h:312:
multiple definition of `i915_vma_capture_finish'
drivers/gpu/drm/i915/i915_drv.o:
./drivers/gpu/drm/i915/i915_gpu_error.h:312: first defined here

So, add 'static inline' on the defineation of the 'i915_vma_capture_finish'

Fixes: d713e3ab93fdc("drm/i915: Correct typo in i915_vma_compress_finish stub")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200113104009.13274-1-zhangxiaoxu5@huawei.com

drm/i915: Use the passed in encoder

Just use the passed in encoder instead of digging it out via
the legacy drm_connector->encoder pointer (which we'll want to
stop using).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-5-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>

drm/i915: Pass intel_encoder to enc_to_*()

Lots of enc_to_foo(&encoder->base) around. Simplify by passing
in the intel_encoder instead.

@find@
identifier F =~ "^enc_to_.*";
identifier E;
@@
F(struct drm_encoder *E)
{
...
}

@@
identifier find.F;
identifier find.E;
@@
F(
- struct drm_encoder *E
+ struct intel_encoder *encoder
  )
{
<...
- E
+ &encoder->base
...>
}

@@
identifier find.F;
expression E;
@@
- F(E)
+ F(to_intel_encoder(E))

@@
expression E;
@@
- to_intel_encoder(&E->base)
+ E

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-4-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

drm/i915: Pass intel_connector to intel_attached_*()

Life is usually easier when we pass around intel_ types instead
of drm_ types. In this case it might not be, but I think being
consistent is a good thing anyway. Also some of this might get
cleaned up a bit more later as we keep propagating the intel_
types further.

@find@
identifier F =~ "^intel_attached_.*";
identifier C;
@@
F(struct drm_connector *C)
{
...
}

@@
identifier find.F;
identifier find.C;
@@
F(
- struct drm_connector *C
+ struct intel_connector *connector
  )
{
<...
- C
+ &connector->base
...>
}

@@
identifier find.F;
expression C;
@@
- F(C)
+ F(to_intel_connector(C))

@@
expression C;
@@
- to_intel_connector(&C->base)
+ C

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-3-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>

drm/i915: Bump up CDCLK to eliminate underruns on TGL

There seems to be some undocumented bandwidth
bottleneck/dependency which scales with CDCLK,
causing FIFO underruns when CDCLK is too low,
even when it's correct from BSpec point of view.

Currently for TGL platforms we calculate
min_cdclk initially based on pixel_rate divided
by 2, accounting for also plane requirements,
however in some cases the lowest possible CDCLK
doesn't work and causing the underruns.
We've found experimentally that raising cdclk to
at least  pixel_rate (rather than pixel_rate/2)
eliminates these underruns, so let's use this as a
temporary workaround until the hardware team
can suggest a more precise remedy.

Explicitly stating here that this seems to be currently
rather a Hack, than final solution.

v2: Use clamp operation instead of min(Matt Roper)

v3: - Fixed commit message(Matt Roper)
    - Now using pixel_rate instead of max_cdclk(Jani Nikula)
    - Switched to max from clamp(Ville Syrjälä)
    Hopefully this hybrid satisfies everyone :)

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/issues/402
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200109220547.23817-1-stanislav.lisovskiy@intel.com

drm/i915/pmu: Do not use colons or dashes in PMU names

We use PCI device path in the registered PMU name in order to distinguish
between multiple GPUs. But since tools/perf reserves a special meaning to
dash and colon characters we need to transliterate them to something else.
We choose an underscore.

v2:
 * Use strreplace. (Chris)
 * Dashes are not good either. (Chris)

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reported-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Fixes: 05488673a4d4 ("drm/i915/pmu: Support multiple GPUs")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110113253.12535-1-tvrtko.ursulin@linux.intel.com

drm/i915: Correct typo in i915_vma_compress_finish stub

A copy and paste error in setting up the !CONFIG_DRM_I915_CAPTURE_ERROR
stubs left a conflicting duplicate declaration.

Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200111083007.1619228-1-chris@chris-wilson.co.uk

drm/i915/uc: Add sanitize to to intel_uc_ops

uC sanitization is only meaningful if we are running with uC present
or enabled. Make this function part of the uc_ops.

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

drm/i915/uc: Add init/fini to to intel_uc_ops

uC preparation and cleanup steps are only meaningful if we are
running with uC enabled. Make these functions part of the uc_ops.

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

drm/i915/uc: Add init_fw/fini_fw to to intel_uc_ops

Firmware fetching and cleanup steps are only meaningful if we are
running with uC enabled. Make these functions part of the uc_ops.

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

drm/i915/uc: Add ops to intel_uc

Instead of spreading multiple conditionals across the uC code
to find out current mode of uC operation, start using predefined
set of function pointers that reflect that mode.

Begin with pair of init_hw/fini_hw functions that are responsible
for uC hardware initialization and cleanup.

v2: drop ops_none, use macro to generate ops helpers
v3: reuse __uc_check_hw to avoid redundant comment
v4: forward declare ops struct vs functions

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

drm/i915/gt: Hold rpm wakeref before taking ggtt->vm.mutex

We need to hold the runtime-pm wakeref to update the global PTEs (as
they exist behind a PCI BAR). However, some systems invoke ACPI during
runtime resume and so require allocations, which is verboten inside the
vm->mutex. Ergo, we must not use intel_runtime_pm_get() inside the
mutex, but lift the call outside.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/958
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110144418.1415639-1-chris@chris-wilson.co.uk

drm/i915/dsi: Parse the I2C element from the VBT MIPI sequence block (v3)

Parsing the i2c element is mainly done to transfer the payload from the
MIPI sequence block to the relevant slave device. In some cases, the
commands that are part of the payload can be used to turn on the backlight.

This patch is actually a refactored version of this old patch:
https://lists.freedesktop.org/archives/intel-gfx/2014-December/056897.html

In addition to the refactoring, the original patch is augmented by
looking up the i2c bus from ACPI NS instead of relying on the bus number
provided in the VBT.

This patch was tested on Aava Mobile's Inari 10 tablet. It enabled
turning on the backlight by transferring the payload to the device.

v2:
- Add DRM_DEV_ERROR for invalid adapter and failed transfer and also
  drop the DRM_DEBUG that existed originally. (Hans)
- Add two gotos instead of one to clean things up properly.

v3:
- Identify the device on which this patch was tested in the commit
  message (Ville)

Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110181123.14536-1-vivek.kasireddy@intel.com

drm/i915: Drop request list from error state

The list of requests from after the hang tells little about the hang
itself, only how busy userspace was after the fact. As it pertains
nothing to the HW state, drop it from the error state.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110123059.1348712-4-chris@chris-wilson.co.uk

drm/i915: Drop the shadow ring state from the error capture

The shadow ring regs (ring->head, ring->tail) are meaningless in the
post-mortem dump as they do not related to anything on HW. Remove them
from the coredump.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110123059.1348712-3-chris@chris-wilson.co.uk

drm/i915: Drop the shadow w/a batch buffer

While this is technically the batch as executed by the HW (in part at
least), it is confusing, and only used for a minority of gen.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110123059.1348712-2-chris@chris-wilson.co.uk

drm/i915: Start chopping up the GPU error capture

In the near future, we will want to start a GPU error capture from a new
context, from inside the softirq region of a forced preemption. To do
so requires us to break up the monolithic error capture to provide new
entry points with finer control; in particular focusing on one
engine/gt, and being able to compose an error state from little pieces
of HW capture.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Acked-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110123059.1348712-1-chris@chris-wilson.co.uk

drm/i915/gt: Mark ring->vma as active while pinned

As we use the active state to keep the vma alive while we are reading
its contents during GPU error capture, we need to mark the
ring->vma as active during execution if we want to include the rinbuffer
in the error state.

Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110110402.1231745-3-chris@chris-wilson.co.uk

drm/i915/gt: Mark context->state vma as active while pinned

As we use the active state to keep the vma alive while we are reading
its contents during GPU error capture, we need to mark the
context->state vma as active during execution if we want to include it
in the error state.

Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110110402.1231745-2-chris@chris-wilson.co.uk

drm/i915/gt: Skip trying to unbind in restore_ggtt_mappings

Currently we first to try to unbind the VMA (and lazily rebind on next
use) as an optimisation during restore_ggtt_mappings. Ideally, the only
objects in the GGTT upon resume are the pinned kernel objects which
can't be unbound and need to be restored. As the unbind interferes with
the plan to mark those objects as active for error capture, forgo the
optimisation.

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

drm/i915/uncore: use new struct drm_device based macros.

Convert to the use of new struct drm_device based logging macros to
replace the use of the printk based macros in i915/intel_uncore.c

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7142083e727ab400797c8a90a2196ee37a22c201.1578409433.git.wambui.karugax@gmail.com

drm/i915/sideband: convert to using new struct drm_device logging macros

Replace the use of printk based debugging macros with the struct
drm_device based logging macros in i915/intel_sideband.c.

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ae253ecf3ca878fae7f1f246d75c2136fb6bd72c.1578409433.git.wambui.karugax@gmail.com

drm/i915/lmem: use new struct drm_device based logging macros.

Replace instances of printk based logging macros with the new
struct drm_device logging macros in i915/intel_region_lmem.c.

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7f3df2575ab41a052b7beea86ecc5385edf6f6da.1578409433.git.wambui.karugax@gmail.com

drm/i915/pm: use new struct drm_device logging macros.

This converts various instances of the struct device and printk based
logging macros with the new struct drm_device based logging macros in
i915/intel_pm.c

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8721848f7bcf8b0c3a33969d07e331bb372bd51a.1578409433.git.wambui.karugax@gmail.com

drm/i915/pch: convert to using the drm_dbg_kms() macro.

Convert the use of the DRM_DEBUG_KMS() logging macro to the new struct
drm_device based drm_dbg_kms() logging macro in i915/intel_pch.c.

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b79ee0f6efbf8358cbb4f2e163fa6b5bb04db794.1578409433.git.wambui.karugax@gmail.com

drm/i915/gtt: add missing include file asm/smp.h

Fix build error:
drivers/gpu/drm/i915/gt/intel_ggtt.c: In function ggtt_restore_mappings:
drivers/gpu/drm/i915/gt/intel_ggtt.c:1239:3: error:
implicit declaration of function wbinvd_on_all_cpus; did you mean wrmsr_on_cpus? [-Werror=implicit-function-declaration]
   wbinvd_on_all_cpus();
      ^~~~~~~~~~~~~~~~~~
         wrmsr_on_cpus

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200109012303.153001-1-chenzhou10@huawei.com

drm/i915: Pass cpu_transcoder to assert_pipe_disabled() always

I missed a few assert_pipe_disabled() cases when changing it to
take enum transcoder instead of enum pipe, making sparse unhappy.
Convert the leftovers.

Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108145616.7349-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Fix MST disable sequence

When moving the pipe disable & co. function calls from
haswell_crtc_disable() into the encoder .post_disable() hooks I
neglected to account for the MST vs. DDI interactions properly.
This now leads us to call these functions two times for the last
MST stream (once from the MST code and a second time from the DDI
code). The calls from the DDI code should only be done for SST
and not MST. Add the proper check for that.

This results in an MCE on ICL. My vague theory is that we turn off
the transcoder clock from the MST code and then we proceed to touch
something in the DDI code which still depends on that clock causing
the hardware to become upset. Though I can't really explain why
Stan's hack of omitting the pipe disable in the MST code would avoid
the MCE since we should still be turning off the transcoder clock.
But maybe there's something magic in the hw that keeps the clock on
as long as the pipe is on. Or maybe the clock isn't the problem and
we now touch something in the DDI disable code that really does need
the pipe to be still enabled.

v2: Rebase to latest drm-tip

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Reported-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/issues/901
Fixes: 773b4b54351c ("drm/i915: Move stuff from haswell_crtc_disable() into encoder .post_disable()")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108144550.29280-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

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

Sync with drm-next to get the new logging macros, among other things.

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

drm/i915: use true,false for bool variable in intel_crt.c

Fixes coccicheck warning:

drivers/gpu/drm/i915/display/intel_crt.c:1066:1-28: WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/i915/display/intel_crt.c:928:2-29: WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/i915/display/intel_crt.c:443:2-29: WARNING: Assignment of 0/1 to bool variable

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Ma Feng <mafeng.ma@huawei.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1578013959-31486-4-git-send-email-mafeng.ma@huawei.com

drm/i915/dp: use true,false for bool variable in intel_dp.c

Fixes coccicheck warning:

drivers/gpu/drm/i915/display/intel_dp.c:4950:1-33: WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/i915/display/intel_dp.c:4906:1-33: WARNING: Assignment of 0/1 to bool variable

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Ma Feng <mafeng.ma@huawei.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1578013959-31486-3-git-send-email-mafeng.ma@huawei.com

drm/i915: use true,false for bool variable in i915_debugfs.c

Fixes coccicheck warning:

drivers/gpu/drm/i915/i915_debugfs.c:3078:4-36: WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/i915/i915_debugfs.c:3078:4-36: WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/i915/i915_debugfs.c:3080:4-36: WARNING: Assignment of 0/1 to bool variable
drivers/gpu/drm/i915/i915_debugfs.c:3080:4-36: WARNING: Assignment of 0/1 to bool variable

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Ma Feng <mafeng.ma@huawei.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1578013959-31486-2-git-send-email-mafeng.ma@huawei.com

drm/i915/gt: runtime-pm is no longer required for ce->ops->pin()

Now that we have moved the runtime-pm management out of
intel_context_acctive_acquire, and that itself out of ce->ops->pin(), no
explicit runtime pm wakeref is required in intel_context_pin().

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200109085717.873326-3-chris@chris-wilson.co.uk

drm/i915/gt: Pull context activation into central intel_context_pin()

While this is encroaching on midlayer territory, having already made the
state allocation a previous step in pinning, we can now pull the common
intel_context_active_acquire() into intel_context_pin() itself. This is
a prelude to make the activation a separate step inside pinning, outside
of the ce->pin_mutex

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

drm/i915/gt: Push context state allocation earlier

Allow for knowledgeable users to preallocate the context state, and to
separate the allocation step from the pinning step during
intel_context_pin()

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200109085717.873326-1-chris@chris-wilson.co.uk

drm/i915: Pin the context as we work on it

Since we now allow the intel_context_unpin() to run unserialised, we
risk our operations under the intel_context_lock_pinned() being run as
the context is unpinned (and thus invalidating our state). We can
atomically acquire the pin, testing to see if it is pinned in the
process, thus ensuring that the state remains consistent during the
course of the whole operation.

Fixes: 841350223816 ("drm/i915/gt: Drop mutex serialisation between context pin/unpin")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200109085142.871563-1-chris@chris-wilson.co.uk

drm/i915: Revert "drm/i915/tgl: Wa_1607138340"

This reverts commit 08fff7aeddc9dd72161b4c8fc27fbab12b4b9352.

For some yet unexplained reason not having this improves stability of some
media workloads.

Promise is that the media hang will be root caused properly and in the
meantime absence of this workaround is unlikely to cause problems.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Sudeep Dutt <sudeep.dutt@intel.com>
Cc: Francesco Balestrieri <francesco.balestrieri@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108161954.29739-1-tvrtko.ursulin@linux.intel.com

drm/i915: Reduce warning for i915_vma_pin_iomap() without runtime-pm

Access through the GGTT (iomap) into the vma does require the device to
be awake. However, we often take the i915_vma_pin_iomap() as an early
preparatory step that is long before we use the iomap. Asserting that
the device is awake at pin time does not protect us, and is merely a
nuisance.

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

drm/i915: Early return for no-op i915_vma_pin_fence()

If we have no fence and desire no fence on the vma, return before we try
and take the vm->mutex.

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

drm/i915/gt: Drop a defunct timeline assertion

intel_timeline_enter() has been decoupled from intel_timeline_pin() and
both enter/exit & pin/unpin are allowed [read expected] to run
concurrently with one another. The assertion that they had better not is
stale.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/940
References: a6edbca74b30 ("drm/i915/gt: Close race between engine_park and intel_gt_retire_requests")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200107143826.3298401-1-chris@chris-wilson.co.uk

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

drm-misc-next for v5.6:

UAPI Changes:
- Allow overriding number of bootup penguins in fbcon using fbcon=logo-count:n.

Cross-subsystem Changes:
- fbdev fixes for mmp, and make it work with CONFIG_COMPILE_TEST.
- Use devm_platform_ioremap_resource in fbdev drivers.
- Various small fbdev fixes.

Core Changes:
- Support scanline alignment for dumb buffers.
- Add atomic_check() hook to bridge ops, to support bus format negotiation.
- Add gem_create_object() to vram helpers.

Driver Changes:
- Rockchip: Add support for PX30.
- Use generic fbdev code and dumb helpers in hisilicon/hibmc.
- Add support for Leadtek LTK500HD1829 panel, and xinpeng XPP055C272.
- Clock fixes for atmel-hlcdc.
- Various smaller fixes to all drivers.

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8eff1e3f-ef0a-2dd9-9a14-6273b1d6f963@linux.intel.com

drm: of: Fix linking when CONFIG_OF is not set

The new helper drm_of_lvds_get_dual_link_pixel_order() introduced in
commit 6529007522de has a fallback stub when CONFIG_OF is not set, but
the stub is declared in drm_of.h without a static inline. This causes
multiple definitions of the function to be linked when the CONFIG_OF
option isn't set. Fix it by making the stub static inline.

Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191219103703.8547-1-laurent.pinchart+renesas@ideasonboard.com

drm/i915/display: Fix warning about MST and DDI restrictions

Capturing the restrictions of the BSpec pages bellow:

SKL and CNL do not support MST in DDI E, DDI E only support 2 lanes
and it is mostly used to support a 4 lanes eDP panel together with
DDI A.
ICL's DDI E support MST just like other ports but DDI A is still eDP
and MIPI only.
TGL supports MST in any DDI, including DDI A but TGL has it's own
ddi_pre_enable_dp function already without any warning.

[  215.579791] ------------[ cut here ]------------
[  215.579794] WARN_ON(is_mst && (port == PORT_A || port == PORT_E))
[  215.579875] WARNING: CPU: 0 PID: 268 at drivers/gpu/drm/i915/display/intel_ddi.c:3576 intel_ddi_pre_enable+0x124/0xea0 [i915]
[  215.579878] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 btusb btrtl btbcm btintel bluetooth prime_numbers snd_hda_intel snd_intel_dspcfg snd_hda_codec e1000e snd_hwdep snd_hda_core asix mei_hdcp cdc_ether x86_pkg_temp_thermal mei_me snd_pcm r8152 coretemp usbnet mei crct10dif_pclmul mii ptp ecdh_generic crc32_pclmul i2c_i801 ecc pps_core ghash_clmulni_intel thunderbolt
[  215.579905] CPU: 0 PID: 268 Comm: kworker/0:2 Tainted: G        W         5.4.0-rc8-zeh+ #1307
[  215.579907] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3201.A00.1905140358 05/14/2019
[  215.579912] Workqueue: events_long drm_dp_mst_link_probe_work
[  215.579975] RIP: 0010:intel_ddi_pre_enable+0x124/0xea0 [i915]
[  215.579978] Code: ff 8b 7c 24 10 89 44 24 30 85 ff 74 1f f7 44 24 18 fb ff ff ff 75 15 48 c7 c6 98 fa 48 a0 48 c7 c7 d3 df 4a a0 e8 cf d5 d0 e0 <0f> 0b 0f b6 4c 24 2c 41 8b b5 04 06 00 00 4c 89 e7 41 0f b6 95 0c
[  215.579980] RSP: 0018:ffffc90001a5f990 EFLAGS: 00010286
[  215.579984] RAX: 0000000000000000 RBX: ffff88848356a000 RCX: 0000000000000000
[  215.579986] RDX: 0000000000001df1 RSI: ffff88849340c998 RDI: ffffffff821489c5
[  215.579989] RBP: ffff88848356a000 R08: 00000000c021a419 R09: 0000000000000000
[  215.579991] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88848356a118
[  215.579994] R13: ffff88847f39c000 R14: ffff88847fe70000 R15: ffff88848356a000
[  215.579996] FS:  0000000000000000(0000) GS:ffff88849f800000(0000) knlGS:0000000000000000
[  215.579999] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  215.580001] CR2: 000055d3d5a26bc0 CR3: 0000000480ba6005 CR4: 0000000000760ef0
[  215.580004] PKRU: 55555554
[  215.580006] Call Trace:
[  215.580014]  ? drm_dp_mst_topology_put_port+0x6f/0x130
[  215.580072]  intel_mst_pre_enable_dp+0x14b/0x170 [i915]
[  215.580129]  intel_encoders_pre_enable+0x76/0x90 [i915]
[  215.580191]  haswell_crtc_enable+0x84/0x880 [i915]
[  215.580266]  intel_update_crtc+0x1e4/0x200 [i915]
[  215.580333]  skl_commit_modeset_enables+0x287/0x420 [i915]
[  215.580405]  intel_atomic_commit_tail+0x332/0x14e0 [i915]
[  215.580410]  ? queue_work_on+0x41/0x70
[  215.580489]  intel_atomic_commit+0x31e/0x350 [i915]
[  215.580500]  drm_client_modeset_commit_atomic+0x18b/0x220
[  215.580523]  drm_client_modeset_commit_force+0x4d/0x180
[  215.580531]  drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0
[  215.580538]  drm_fb_helper_set_par+0x27/0x50
[  215.580543]  drm_fb_helper_hotplug_event.part.0+0xa7/0xc0
[  215.580549]  drm_kms_helper_hotplug_event+0x21/0x30
[  215.580553]  process_one_work+0x25b/0x5b0
[  215.580566]  worker_thread+0x4b/0x3b0
[  215.580578]  kthread+0x100/0x140
[  215.580581]  ? process_one_work+0x5b0/0x5b0
[  215.580585]  ? kthread_park+0x80/0x80
[  215.580591]  ret_from_fork+0x24/0x50
[  215.580603] irq event stamp: 1393930
[  215.580606] hardirqs last  enabled at (1393929): [<ffffffff8112a013>] vprintk_emit+0x143/0x330
[  215.580609] hardirqs last disabled at (1393930): [<ffffffff81001cfa>] trace_hardirqs_off_thunk+0x1a/0x20
[  215.580613] softirqs last  enabled at (1393434): [<ffffffff81c00389>] __do_softirq+0x389/0x47f
[  215.580618] softirqs last disabled at (1393423): [<ffffffff810b7199>] irq_exit+0xa9/0xc0
[  215.580621] ---[ end trace afd44ea9caa6373e ]---

BSpec: 4217
BSpec: 14004
BSpec: 20584
BSpec: 50583
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200107170922.153612-2-jose.souza@intel.com

drm/i915/display/icl+: Do not program clockgating

Talked with HW team and this is a left over, driver should not
program clockgating, mg or dekel firmware is reponsible for any
clockgating programing.

Also removing the register and bits definition related to clockgating.

v2:
Added WARN_ON

v3:
Only calling icl_phy_set_clock_gating() on intel_ddi_pre_enable_hdmi
for GEN11

v4:
ICL should also not program clockgating (thanks Matt for catching
this)

BSpec issue: 20885
BSpec: 49292
BSpec: 21735
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200107170922.153612-1-jose.souza@intel.com

drm/i915/display: Force the state compute phase once to enable PSR

Recent improvements in the state tracking in i915 caused PSR to not be
enabled when reusing firmware/BIOS modeset, this is due to all initial
commits returning ealier in intel_atomic_check() as needs_modeset()
is always false.

To fix that here forcing the state compute phase in CRTC that is
driving the eDP that supports PSR once. Enable or disable PSR do not
require a fullmodeset, so user will still experience glitch free boot
process plus the power savings that PSR brings.

It was tried to set mode_changed in intel_initial_commit() but at
this point the connectors are not registered causing a crash when
computing encoder state.

v2:
- removed function return
- change arguments to match intel_hdcp_atomic_check

v3:
- replaced drm includes in intel_psr.h by forward declaration(Jani)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112253
Reported-by: <s.zharkoff@gmail.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200106152128.195171-1-jose.souza@intel.com

drm/i915/gt: Always force restore freshly pinned contexts

It is highly unlikely, but still conceivable, that we submit a context
with the same GGTT address as last active on the HW. In this case, with
a matching LRCA, the HW would not restore the new context image causing
a potential violation of our context isolation.

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

drm/i915/gtt: split up i915_gem_gtt

Attempt to split i915_gem_gtt.[ch] into more manageable chunks.

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

drm/i915/gt: Take responsibility for engine->release as the last step

In order to avoid a double cleanup on error, take ownership of
engine->release past the point of no [error] return.

Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Fixes: e26b6d434147 ("drm/i915/gt: Pull GT initialisation under intel_gt_init()")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Tested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200107143118.3288995-1-chris@chris-wilson.co.uk

drm/i915/display: Use external dependency loop for port sync

This loop was added directly to intel_atomic_check() to be used by
all other features that have external pipe dependencies, so using it
and removing intel_atomic_check_synced_crtcs().

After this changes is_trans_port_sync_master() it not used anywhere,
so removing it.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200106142823.145260-1-jose.souza@intel.com

drm/i915: fix an error code in intel_modeset_all_tiles()

There is a cut and paste bug so we return the wrong error code.

Fixes: a603f5bd1691 ("drm/i915/dp: Make sure all tiled connectors get added to the state with full modeset")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200107130322.gdk5b6jurifr26c2@kili.mountain

drm/i915: Add missing include file <linux/math64.h>

Fix build error:
./drivers/gpu/drm/i915/selftests/i915_random.h: In function i915_prandom_u32_max_state:
./drivers/gpu/drm/i915/selftests/i915_random.h:48:23: error:
 implicit declaration of function mul_u32_u32; did you mean mul_u64_u32_div? [-Werror=implicit-function-declaration]
  return upper_32_bits(mul_u32_u32(prandom_u32_state(state), ep_ro));

Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 7ce5b6850b47 ("drm/i915/selftests: Use mul_u32_u32() for 32b x 32b -> 64b result")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200107135014.36472-1-yuehaibing@huawei.com

drm/i915/tgl: Gen-12 display can decompress surfaces compressed by the media engine

Detect the modifier corresponding to media compression to enable
display decompression for YUV and xRGB packed formats. A new modifier is
added so that the driver can distinguish between media and render
compressed buffers. Unlike render decompression, plane 6 and  plane 7 do not
support media decompression.

v2: Fix checkpatch warnings on code style (Lucas)

From DK:
Separate modifier array for planes that cannot decompress media (Ville)

v3: Support planar formats
v4: Switch plane order
v5:
- Use format block descriptors to get CCS subsampling calculation right
  everywhere.
- Extend the plane state normal view array to accommodate 4 color planes.
- Use helpers to convert between main and CCS planes.
v6: Add missing packed YUV formats to the MC format list. (Yang)
v7: Align UV planes to tile-row size.

Cc: Nanley G Chery <nanley.g.chery@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Yang A Shi <yang.a.shi@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191231233756.18753-8-imre.deak@intel.com

drm/fb: Extend format_info member arrays to handle four planes

addfb() uAPI has supported four planes for a while now, make format_info
compatible with that.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191231233756.18753-7-imre.deak@intel.com

drm/framebuffer: Format modifier for Intel Gen-12 media compression

Gen-12 display can decompress surfaces compressed by the media engine, add
a new modifier as the driver needs to know the surface was compressed by
the media or render engine.

v2: Update code comment describing the color plane order for YUV
    semiplanar formats.

Cc: Nanley G Chery <nanley.g.chery@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191231233756.18753-6-imre.deak@intel.com

drm/i915: Make sure plane dims are correct for UV CCS planes

As intel_fb_plane_get_subsampling() returns the subsampling factor wrt.
its main plane, for a CCS plane we need to apply both the main and the
CCS plane's subsampling factor on the FB's dimensions to get the CCS
plane's dimensions.

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191231233756.18753-5-imre.deak@intel.com

drm/i915: Add debug message for FB plane[0].offset!=0 error

Print a debug message if the FB plane[0] offset is not 0 as expected, to
help understainding an add FB IOCTL fail.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191231233756.18753-4-imre.deak@intel.com

drm/i915/tgl: Make sure a semiplanar UV plane is tile row size aligned

Currently the GGTT offset of a UV plane in a semiplanar YUV FB is tile
size (4kB) aligned. I noticed, that enforcing only this alignment leads
oddly to random memory corruptions on TGL while scanning out Y-tiled
FBs. This issue can be easily reproduced with a UV plane offset that is
not aligned to the plane's tile row size.

Some experiments showed the correct alignment to be tile row size
indeed. This also makes sense, since the de-tiling fence created for the
object - with its own stride and so "left" and "right" edge - applies to
all the planes in the FB, so each tile row of all planes should be tile
row aligned.

In fact BSpec requires this alignment since SKL. On SKL we may enforce
this due to the AUX plane x,y coords check, but on ICL and TGL we don't.
For now enforce this only on TGL; I can follow up with any necessary
change for ICL after more tests.

BSpec requires a stricter alignment for linear UV planes too (kind of a
tile row alignment), but it's unclear whether that's really needed
(couldn't be explained with the de-tiling fence as above) and enforcing
that could break existing user space; so avoid that too for now until
more tests.

v2:
- Clarify the commit log wrt. the address space the alignment applies to.
  (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191231233756.18753-3-imre.deak@intel.com

drm/i915: Add support for non-power-of-2 FB plane alignment

At least one framebuffer plane on TGL - the UV plane of YUV semiplanar
FBs - requires a non-power-of-2 alignment, so add support for this. This
new alignment restriction applies only to an offset within an FB, so the
GEM buffer itself containing the FB must still be power-of-2 aligned.
Add a check for this (in practice plane 0, since the plane 0 offset must
be 0).

v2:
- Fix WARN check for alignment=0.
v3:
- Return error for alignment programming bugs. (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191231233756.18753-2-imre.deak@intel.com

drm/mgag200: Add module parameter to pin all buffers at offset 0

For hardware that does not interpret the startadd field correctly,
add the module parameter 'hw_bug_no_startadd', which enables the
workaround.

v3:
* style and typo fixes
v2:
* ask user for feedback if the option is active

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: John Donnelly <john.p.donnelly@oracle.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191126101950.11989-1-tzimmermann@suse.de

drm/vram-helper: Support struct drm_driver.gem_create_object

Drivers that what to allocate VRAM GEM objects with additional fields
can now do this by implementing struct drm_driver.gem_create_object.

v3:
* separately check allocation failure in if/else branches
  before upcast to gbo
v2:
* only cast to gbo within if branch; set gbo directly
  in else branch

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200106125745.13797-9-tzimmermann@suse.de

drm/vram-helper: Remove BO device from public interface

TTM is an implementation detail of the VRAM helpers and therefore
shouldn't be exposed to the callers. There's only one correct value
for the BO device anyway, which is the one stored in the DRM device.

So remove struct ttm_bo_device from the VRAM-helper interface and
use the device's VRAM manager unconditionally. The GEM initializer
function fails if the VRAM manager has not been initialized.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200106125745.13797-8-tzimmermann@suse.de