Replace the previous approach to force compute the initial PSR state
after i915 take over from firmware by the better and recently added
initial_fastset_check() hook.

Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201102221048.104294-1-jose.souza@intel.com

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

If i915.ko is being used as a passthrough device, it does not know if
the host is using intel_iommu. Mixing the iommu and gfx causes a few
issues (such as scanout overfetch) which we need to workaround inside
the driver, so if we detect we are running under a hypervisor, also
assume the device access is being virtualised.
Reported-by: NStefan Fritsch <sf@sfritsch.de>
Suggested-by: NStefan Fritsch <sf@sfritsch.de>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Stefan Fritsch <sf@sfritsch.de>
Cc: stable@vger.kernel.org
Tested-by: NStefan Fritsch <sf@sfritsch.de>
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201019101523.4145-1-chris@chris-wilson.co.uk
(cherry picked from commit f566fdcd)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

If i915.ko is being used as a passthrough device, it does not know if
the host is using intel_iommu. Mixing the iommu and gfx causes a few
issues (such as scanout overfetch) which we need to workaround inside
the driver, so if we detect we are running under a hypervisor, also
assume the device access is being virtualised.
Reported-by: NStefan Fritsch <sf@sfritsch.de>
Suggested-by: NStefan Fritsch <sf@sfritsch.de>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Stefan Fritsch <sf@sfritsch.de>
Cc: stable@vger.kernel.org
Tested-by: NStefan Fritsch <sf@sfritsch.de>
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201019101523.4145-1-chris@chris-wilson.co.uk

Recently we came across requirement to identify EHL and JSL
platform to program them differently. Thus Split the basic
platform definition, macros, and PCI IDs to differentiate
between EHL and JSL platforms. Also, IS_ELKHARTLAKE is replaced
with IS_JSL_EHL everywhere.

Changes since V1 :
	- Rebased to avoid merge conflicts
	- Added missed check for jasperlake in intel_uc_fw.c

Cc : Matt Roper <matthew.d.roper@intel.com>
Cc : Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NTejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201013192948.63470-1-tejaskumarx.surendrakumar.upadhyay@intel.com

Implement the pci .shutdown() hook in order to quiesce the
hardware prior to reboot. The main purpose here is to turn
all displays off. Some displays/other drivers tend to get
confused if the state after reboot isn't exactly as they
expected.

One specific example was the Dell UP2414Q in MST mode.
It would require me to pull the power cord after a reboot
or else it would just not come back to life. Sadly I don't
have that at hand anymore so not sure if it's still
misbehaving without the graceful shutdown, or if we
managed to fix something else since I last tested it.

For good measure we do a gem suspend as well, so that
we match the suspend flow more closely. Also stopping
all DMA and whatnot is probably a good idea for kexec.
I would expect that some kind of GT reset happens on
normal reboot so probably not totally necessary there.

v2: Use the pci .shutdown() hook instead of a reboot notifier (Lukas)
    Do the gem suspend for kexec (Chris)

Cc: Lukas Wunner <lukas@wunner.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-1-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Be consistent and use unsigned long throughout the chunk copies to
avoid the inherent clumsiness of mixing integer types of different
widths and signs. Failing to take acount of a wider unsigned type when
using min_t can lead to treating it as a negative, only for it flip back
to a large unsigned value after passing a boundary check.

Fixes: ed13033f ("drm/i915/cmdparser: Only cache the dst vmap")
Testcase: igt/gen9_exec_parse/bb-large
Reported-by: N"Candelaria, Jared" <jared.candelaria@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: "Candelaria, Jared" <jared.candelaria@intel.com>
Cc: "Bloomfield, Jon" <jon.bloomfield@intel.com>
Cc: <stable@vger.kernel.org> # v4.9+
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200928215942.31917-1-chris@chris-wilson.co.uk
(cherry picked from commit b7eeb2b4)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Make a clean split between hpd pins for DDI vs. TC. This matches
how the actual hardware is split.

And with this we move the DDI/PHY->HPD pin mapping into the encoder
init instead of having to remap yet again in the interrupt code.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-11-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The CACHE_MODE_0 save/restore was added without explanation in
commit 1f84e550 ("drm/i915 more registers for S3 (DSPCLK_GATE_D,
CACHE_MODE_0, MI_ARB_STATE)"). If there are any bits we care about
those should be set explicitly during some appropriate init function.
Let's assume it's all good and just nuke this magic save/restore.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200908140210.31048-4-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>

Originally added in commit 1f84e550 ("drm/i915 more registers for
S3 (DSPCLK_GATE_D, CACHE_MODE_0, MI_ARB_STATE)") to fix some underruns.
I suspect that was due to the trickle feed settings getting clobbered
during suspend. We've been disabling trickle feed explicitly since
commit 20f94967 ("drm/i915: Disable trickle feed via MI_ARB_STATE
for the gen4") so this magic save/restore should no longer be needed.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200908140210.31048-3-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

The FBC_CONTROL save restore is there just to preserve the
compression interval setting. Since commit a68ce21b
("drm/i915/fbc: Store the fbc1 compression interval in the params")
we've been explicitly setting the interval to a specific
value, so the sace/restore is now entirely pointless.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200908140210.31048-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

We don't save/restore PCH_PORT_HOTPLUG so no point in reseving
space for the value.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200908140210.31048-1-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

There's no real reason to stash away the DPIO PHY IOSF sideband port
numbers for VLV/CHV. Just compute them at runtime in the sideband code.

Gets rid of the oddball intel_init_dpio() function from the high level
init flow.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200907162709.29579-1-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.

This also requires changing the order of eb_parse slightly, to ensure
we pass ww at a point where we could still handle -EDEADLK safely.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NThomas Hellström <thomas.hellstrom@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200819140904.1708856-15-maarten.lankhorst@linux.intel.comSigned-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

The GEM object is grossly overweight for the practicality of tracking
large numbers of individual pages, yet it is currently our only
abstraction for tracking DMA allocations. Since those allocations need
to be reserved upfront before an operation, and that we need to break
away from simple system memory, we need to ditch using plain struct page
wrappers.

In the process, we drop the WC mapping as we ended up clflushing
everything anyway due to various issues across a wider range of
platforms. Though in a future step, we need to drop the kmap_atomic
approach which suggests we need to pre-map all the pages and keep them
mapped.

v2: Verify our large scratch page is suitably DMA aligned; and manually
clear the scratch since we are allocating plain struct pages full of
prior content.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200729164219.5737-2-chris@chris-wilson.co.ukSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

I915_GEM_THROTTLE dates back to the time before contexts where there was
just a single engine, and therefore a single timeline and request list
globally. That request list was in execution/retirement order, and so
walking it to find a particular aged request made sense and could be
split per file.

That is no more. We now have many timelines with a file, as many as the
user wants to construct (essentially per-engine, per-context). Each of
those run independently and so make the single list futile. Remove the
disordered list, and iterate over all the timelines to find a request to
wait on in each to satisfy the criteria that the CPU is no more than 20ms
ahead of its oldest request.

It should go without saying that the I915_GEM_THROTTLE ioctl is no
longer used as the primary means of throttling, so it makes sense to push
the complication into the ioctl where it only impacts upon its few
irregular users, rather than the execbuf/retire where everybody has to
pay the cost. Fortunately, the few users do not create vast amount of
contexts, so the loops over contexts/engines should be concise.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200728152010.30701-1-chris@chris-wilson.co.ukSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

TGL made stepping a litte mess, workarounds refer to the stepping of
the IP(GT or Display) not of the GPU stepping so it would already
require the same solution as used in commit 96c5a15f
("drm/i915/kbl: Fix revision ID checks").
But to make things even more messy it have a different IP stepping
mapping between SKUs and the same stepping revision of GT do not match
the same HW between TGL U/Y and regular TGL.

So it was required to have 2 different macros to check GT WAs while
for Display we are able to use just one macro that uses the right
revids table.

All TGL workarounds checked and updated accordingly.

v2:
- removed TODO to check if WA 14010919138 applies to regular TGL.
- fixed display stepping in regular TGL (Anusha)

BSpec: 52890
BSpec: 55378
BSpec: 44455
Reviewed-by: NAnusha Srivatsa <anusha.srivtsa@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Penne Lee <penne.y.lee@intel.com>
Cc: Guangyao Bai <guangyao.bai@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200827233943.400946-1-jose.souza@intel.com

Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

All GEN12 platforms supports PSR2 selective fetch but not all GEN12
platforms supports PSR2 hardware tracking(aka RKL).

This feature consists in software programming registers with the
damaged area of each plane this way hardware will only fetch from
memory those areas and sent the PSR2 selective update blocks to panel,
saving even more power.

But as initial step it is only enabling the full frame fetch at
every flip, the actual selective fetch part will come in a future
patch.

Also this is only handling the page flip side, it is still completely
missing frontbuffer modifications, that is why the
enable_psr2_sel_fetch parameter was added.

v3:
- calling intel_psr2_sel_fetch_update() during the atomic check phase
(Ville)

BSpec: 55229
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200810174144.76761-1-jose.souza@intel.comSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

We usually assume that increasing PCI device revision ID's translates to
newer steppings; macros like IS_KBL_REVID() that we use rely on this
behavior.  Unfortunately this turns out to not be true on KBL; the
newer device 2 revision ID's sometimes go backward to older steppings.
The situation is further complicated by different GT and display
steppings associated with each revision ID.

Let's work around this by providing a table to map the revision ID to
specific GT and display steppings, and then perform our comparisons on
the mapped values.

v2:
 - Move the kbl_revids[] array to intel_workarounds.c to avoid compiler
   warnings about an unused variable in files that don't call the
   macros (kernel test robot).

Bspec: 18329
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200811032105.2819370-1-matthew.d.roper@intel.comReviewed-by: NSwathi Dhanavanthri <swathi.dhanavanthri@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

There is no way to differentiate TGL-U from TGL-Y by the PCI ids as
some ids are available in both SKUs.
So here using the root device id in the PCI bus that iGPU is in
to differentiate between U and Y.

BSpec: 44455
Reviewed-by: NSwathi Dhanavanthri <swathi.dhanavanthri@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200807192629.64134-1-jose.souza@intel.comSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

If HTI (also sometimes called HDPORT) is enabled at startup, it may be
using some of the PHYs and DPLLs making them unavailable for general
usage.  Let's read out the HDPORT_STATE register and avoid making use of
resources that HTI is already using.

v2:
 - Fix minor checkpatch warnings

v3:
 - Just readout HDPORT_STATE register once during init and then parse it
   later as needed.
 - Add a 'has_hti' device info flag to track whether we should readout
   HDPORT_STATE or not.  We can skip the platform/flag tests later since
   the hti_state in dev_priv will remain 0 for platforms it does not
   apply to.
 - Move PLL masking into icl_get_combo_phy_dpll() since at the moment
   RKL is the only platform that has HTI.  (Jose)

Bspec: 49189
Bspec: 53707
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716220551.2730644-5-matthew.d.roper@intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

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

Currently we're failing to recalculate the gen9 FBC w/a stride
unless something more drastic than just the modifier itself has
changed. This often leaves us with FBC enabled with the linear
fbdev framebuffer without the w/a stride enabled. That will cause
an immediate underrun and FBC will get promptly disabled.

Fix the problem by checking if the w/a stride is about to change,
and go through the full dance if so. This part of the FBC code
is still pretty much a disaster and will need lots more work.
But this should at least fix the immediate issue.

v2: Deactivate FBC when the modifier changes since that will
    likely require resetting the w/a CFB stride

Cc: stable@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200711080336.13423-1-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
(cherry picked from commit 0428ab01)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Currently we're failing to recalculate the gen9 FBC w/a stride
unless something more drastic than just the modifier itself has
changed. This often leaves us with FBC enabled with the linear
fbdev framebuffer without the w/a stride enabled. That will cause
an immediate underrun and FBC will get promptly disabled.

Fix the problem by checking if the w/a stride is about to change,
and go through the full dance if so. This part of the FBC code
is still pretty much a disaster and will need lots more work.
But this should at least fix the immediate issue.

v2: Deactivate FBC when the modifier changes since that will
    likely require resetting the w/a CFB stride

Cc: stable@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200711080336.13423-1-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Bspec: 33617, 33617

v2: s/intel_dg1_info/dg1_info/ as done for other platforms before and
    try to shut up compiler about ununsed variable that we know
    shouldn't be used (Lucas)
v3: replace explicit attribute with __maybe_unused (Lucas)

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Stuart Summers <stuart.summers@intel.com>
Cc: Vanshidhar Konda <vanshidhar.r.konda@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NAbdiel Janulgue <abdiel.janulgue@linux.intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200713182321.12390-2-lucas.demarchi@intel.com

Add flag to differentiate platforms with and without the master
IRQ control bit.
Signed-off-by: NStuart Summers <stuart.summers@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200713182321.12390-1-lucas.demarchi@intel.com

HOBL means hours of battery life, it is a power-saving feature
were supported motherboards can use a special voltage swing table
that uses less power.

So here parsing the VBT to check if this feature is supported.

BSpec: 20150
Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200708205512.21625-3-jose.souza@intel.com

Since the engines belong to the GT, move the runtime-updated list of
available engines to the intel_gt struct. The original mask has been
renamed to indicate it contains the maximum engine list that can be
found on a matching device.

In preparation for other info being moved to the gt in follow up patches
(sseu), introduce an intel_gt_info structure to group all gt-related
runtime info.

v2: s/max_engine_mask/platform_engine_mask (tvrtko), fix selftest
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Andi Shyti <andi.shyti@intel.com>
Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> #v1
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200708003952.21831-5-daniele.ceraolospurio@intel.com

A follow up patch will move the engine mask under the gt structure,
so get ready for that.

v2: switch the remaining gvt case using dev_priv->gt to gvt->gt (Chris)
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Andi Shyti <andi.shyti@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> #v1
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200708003952.21831-3-daniele.ceraolospurio@intel.com

The current fence_y_offset calculation is broken. I think it more or
less used to do the right thing, but then I changed the plane code
to put the final x/y source offsets back into the src rectangle so
now it's just subtraacting the same value from itself. The code would
never have worked if we allowed the framebuffer to have a non-zero
offset.

Let's do this in a better way by just calculating the fence_y_offset
from the final plane surface offset. Note that we don't align the
plane surface address to fence rows so with horizontal panning there's
often a horizontal offset from the fence start to the surface address
as well. We have no way to tell the hardware about that so we just
ignore it. Based on some quick tests the invlidation still happens
correctly. I presume due to the invalidation nuking at least the full
line (or a segment of multiple lines).

Fixes: 54d4d719 ("drm/i915: Overcome display engine stride limits via GTT remapping")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-4-ville.syrjala@linux.intel.comReviewed-by: NMatt Roper <matthew.d.roper@intel.com>
(cherry picked from commit 5331889b)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

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

Rearrange the allocation of the mm_struct registration to avoid
allocating underneath the i915->mm_lock, so that we avoid tainting the
lock (and in turn many other locks that may be held as i915->mm_lock is
taken, and those locks we may want on the free [shrinker] paths). In
doing so, we convert the lookup to be RCU protected by courtesy of
converting the free-worker to be an rcu_work.

v2: Remember to use hash_rcu variants to protect the list iteration from
concurrent add/del.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200619194038.5088-1-chris@chris-wilson.co.uk

Avoid the FBC_CONTROL rmw and just store the fbc compression
interval in the params/
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-10-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

The current fence_y_offset calculation is broken. I think it more or
less used to do the right thing, but then I changed the plane code
to put the final x/y source offsets back into the src rectangle so
now it's just subtraacting the same value from itself. The code would
never have worked if we allowed the framebuffer to have a non-zero
offset.

Let's do this in a better way by just calculating the fence_y_offset
from the final plane surface offset. Note that we don't align the
plane surface address to fence rows so with horizontal panning there's
often a horizontal offset from the fence start to the surface address
as well. We have no way to tell the hardware about that so we just
ignore it. Based on some quick tests the invlidation still happens
correctly. I presume due to the invalidation nuking at least the full
line (or a segment of multiple lines).

Fixes: 54d4d719 ("drm/i915: Overcome display engine stride limits via GTT remapping")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-4-ville.syrjala@linux.intel.comReviewed-by: NMatt Roper <matthew.d.roper@intel.com>

Start using device specific parameters instead of module parameters for
most things. The module parameters become the immutable initial values
for i915 parameters. The device specific parameters in i915->params
start life as a copy of i915_modparams. Any later changes are only
reflected in the debugfs.

The stragglers are:

* i915.force_probe and i915.modeset. Needed before dev_priv is
  available. This is fine because the parameters are read-only and never
  modified.

* i915.verbose_state_checks. Passing dev_priv to I915_STATE_WARN and
  I915_STATE_WARN_ON would result in massive and ugly churn. This is
  handled by not exposing the parameter via debugfs, and leaving the
  parameter writable in sysfs. This may be fixed up in follow-up work.

* i915.inject_probe_failure. Only makes sense in terms of the module,
  not the device. This is handled by not exposing the parameter via
  debugfs.

v2: Fix uc i915 lookup code (Michał Winiarski)

Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: NMichał Winiarski <michal.winiarski@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200618150402.14022-1-jani.nikula@intel.com

RKL doesn't have PSR2 HW tracking, it was replaced by software/manual
tracking.  The driver is required to track the areas that needs update
and program hardware to send selective updates.

So until the software tracking is implemented, PSR2 needs to be disabled
for platforms without PSR2 HW tracking.

BSpec: 50422
BSpec: 50424

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200603211529.3005059-15-matthew.d.roper@intel.com