drm/i915/display: hide workaround for broken vbt in intel_bios.c

Instead of poluting the normal code path in intel_display.c, make
intel_bios.c handle the brokenness of the VBT.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430223808.1078010-5-lucas.demarchi@intel.com

drm/i915/display: remove strap checks from gen 9

Direction on gen9+ was to stop reading the straps and only rely on the
VBT for marking the port presence. This happened while dealing with
WaIgnoreDDIAStrap and instead of using it as a WA, it should now be the
normal flow. See commit 885d3e5b6f08 ("drm/i915/display: fix comment on
skl straps").

For gen 10 it's hard to say if this will work or not since I can't test
it, so leave it with the same behavior as before.

For PCH_TGP we should still rely on the VBT to make ports E and F not
available.

v2 (Ville):
  - use display ver >= 9 to make it consistent with the rest of the
    driver instead of checking for == 9
  - also handle CNL and only initialize port F if it is
    IS_CNL_WITH_PORT_F. Eventually CNL may be removed, but while it
    isn't let's keep it consistent everywhere

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430223808.1078010-4-lucas.demarchi@intel.com

drm/i915/display: remove FIXME comment for intended feature

Direction on gen >= 9 was to stop using straps and rely on VBT
indicating if the port is present or not. Remove FIXME comment since
this will never be "fixed".

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430223808.1078010-3-lucas.demarchi@intel.com

drm/i915/display: move vbt check to intel_ddi_init()

Since commit 45c0673aac97 ("drm/i915/bios: start using the
intel_bios_encoder_data directly") we lookup the devdata for each port
in intel_ddi_init() and just return if the port is not present in VBT
(or if we didn't create a fake devdata for it if VBT is not available).

So in intel_display.c we don't have to check
intel_bios_is_port_present(), just rely on the check in
intel_ddi_init().

v2: Rebase on commit 45c0673aac97 ("drm/i915/bios: start using the
intel_bios_encoder_data directly") re-using that check in intel_ddi_init()
instead of adding a new one.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430223808.1078010-2-lucas.demarchi@intel.com

drm/i915/adl_p: Enable remapping to pad DPT FB strides to POT

Enable padding of DPT FB strides to POT, using the FB remapping logic.

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

drm/i915/adl_p: Require a minimum of 8 tiles stride for DPT FBs

The specification only requires DPT FB strides to be POT aligned, but
there seems to be also a minimum of 8 stride tile requirement. Scanning
out FBs with < 8 stride tiles will result in pipe faults (even though
the stride is POT aligned).

Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-10-imre.deak@intel.com

drm/i915/adl_p: Disable support for 90/270 FB rotation

The latest specification removed the support for 90/270 FB rotation on
ADL_P, even though legacy Y-tiled surfaces are supported. Align the code
accordingly.

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

drm/i915/adl_p: Add stride restriction when using DPT

Alderlake-P have a new stride restriction when using DPT and it is used
by non linear framebuffers. Stride needs to be a power of two to take
full DPT rows, but stride is a parameter set by userspace.

What we could do is use a fake stride when doing DPT allocation so
HW requirements are met and userspace don't need to be changed to
met this power of two restrictions but this change will take a while
to be implemented so for now adding this restriction in driver to
reject atomic commits that would cause visual corruptions.

BSpec: 53393
Acked-by: Matt Roper <matthew.d.roper@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-8-imre.deak@intel.com

drm/i915/xelpd: Support 128k plane stride

XE_LPD supports plane strides up to 128KB.

Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-7-imre.deak@intel.com

drm/i915/xelpd: Fallback to plane stride limitations when using DPT

GTT remapping allow us to have planes with strides larger than HW
supports but DPT + GTT remapping is still not properly handled so
falling back to plane HW limitations for now.

This patch can be dropped when DPT + GTT remapping is correctly
handled but until then we need this limitation for all display13
platforms to avoid pipe faults.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Clint Taylor <Clinton.A.Taylor@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-6-imre.deak@intel.com

drm/i915/xelpd: First stab at DPT support

Add support for DPT (display page table). DPT is a
slightly peculiar two level page table scheme used for
tiled scanout buffers (linear uses direct ggtt mapping
still). The plane surface address will point at a page
in the DPT which holds the PTEs for 512 actual pages.
Thus we require 1/512 of the ggttt address space
compared to a direct ggtt mapping.

We create a new DPT address space for each framebuffer and
track two vmas (one for the DPT, another for the ggtt).

TODO:
- Is the i915_address_space approaach sane?
- Maybe don't map the whole DPT to write the PTEs?
- Deal with remapping/rotation? Need to create a
  separate DPT for each remapped/rotated plane I
  guess. Or else we'd need to make the per-fb DPT
  large enough to support potentially several
  remapped/rotated vmas. How large should that be?

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Bommu Krishnaiah <krishnaiah.bommu@intel.com>
Cc: Wilson Chris P <Chris.P.Wilson@intel.com>
Cc: Tang CQ <cq.tang@intel.com>
Cc: Auld Matthew <matthew.auld@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Wilson Chris P <Chris.P.Wilson@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-5-imre.deak@intel.com

drm/i915/adl_p: ADL_P device info enabling

Add ADL-P to the device_info table and support MACROS.

Bspec: 49185, 55372, 55373
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-4-imre.deak@intel.com

drm/i915/adl_p: Add PCI Devices IDs

Add 18 known PCI device IDs

Bspec: 55376
Cc: Caz Yokoyama <caz.yokoyama@intel.com>
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-3-imre.deak@intel.com

drm/i915/xelpd: add XE_LPD display characteristics

Let's start preparing for upcoming platforms that will use an XE_LPD
design.

v2:
 - Use the now-preferred "XE_LPD" term to refer to this design
 - Utilize DISPLAY_VER() rather than a feature flag
 - Drop unused mbus_size field (Lucas)
v3:
 - Adjust for dbuf.{size,slice_mask} (Ville)

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (v2)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506161930.309688-2-imre.deak@intel.com

drm/i915: Reorder skl+ scaler vs. plane updates

When scanning out NV12 if we at any time have the plane enabled
while the scaler is disabled we get a pretty catastrophic
underrun.

Let's reorder the operations so that we try to avoid that happening
even if our vblank evade fails and the scaler enable/disable and
the plane enable/disable get latched during two diffent frames.

This takes care of the most common cases. I suppose there is still
at least a theoretical possibility of hitting this if one plane
takes the scaler away from another plane before the second plane
had a chance to set up another scaler for its use. But that
is starting to get a bit complicated, especially since the plane
commit order already has to be carefully sequenced to avoid any
dbuf overlaps. So plugging this 100% may prove somewhat hard...

Cc: Cooper Chiou <cooper.chiou@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506073836.14848-1-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

drm/i915: Nuke display error state

I doubt anyone has used the display error state since CS flips
went the way of the dodo. Just nuke it.

It might be semi interesting to have something like this for
FIFO underruns and the like, but as it stands this wouldn't
provide a sufficient amount of information. So would need
an extensive rewrite anyway.

The lockless power well handling is also racy, so this could
just be contributing noise to test results if we end up
accessing something with the relevant power well already
disabled.

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

drm/i915/display: Disable PSR2 sel fetch in TGL pre-production

The implementation of two workarounds are missing causing failures
in CI with pre-production HW.

Cc: Gwan-gyeong Mun <gwan-gyeong.mun@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/20210505213801.80772-1-jose.souza@intel.com

drm/i915: Use intel_de_wait_for_*() in cnl+ cdclk programming

Replace the hand rolled PLL lock bit waits with intel_de_wait_for_*().

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

drm/i915: Use intel_de_rmw() in bxt/glk/cnl+ cdclk programming

Replace the hand rolled rmw sequences with intel_de_rmw().

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

drm/i915: Use intel_de_rmw() in skl cdclk programming

Replace the hand rolled rmw sequences with intel_de_rmw().

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

drm/i915: Use intel_de_rmw() in bdw cdclk programming

Replace the hand rolled rmw sequences with intel_de_rmw().

Jani pointed out that intel_de_rmw() skips the write if the
value does not change. That should be totally fine here, but
let's at least acknowledge the change in behaviour in case I'm
somehow wrong...

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

drm/i915: Extract some helpers to compute cdclk register values

Extract a few of the switch statements into helper functions to
reduce the pollution in the cdclk programming functions.

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

drm/i915: Include intel_de_{read,write}_fw() in i915_reg_rw traces

We lost the i915_reg_rw tracepoint for a lot of display registers
when we switched from the heavyweight normal register accessors to
the lightweight _fw() variants. See eg. commit dd584fc0711a
("drm/i915: Use I915_READ_FW for plane updates").

Put the tracepoints back so that the register traces might
actually be useful. Hopefully these should be close to free
when the tracepoint is not enabled and thus not slow down
our vblank critical sections significantly.

v2: Copy paste the same-cacheline-hang warning from
    intel_uncore.h (Anshuman)

Cc: Cooper Chiou <cooper.chiou@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430143945.6776-2-ville.syrjala@linux.intel.com

drm/i915: Don't include intel_de.h from intel_display_types.h

Hoist the intel_de.h include from intel_display_types.h one
level up. I need this in order to untangle the include order
so that I can add tracepoints into intel_de.h.

This little cocci script did most of the work for me:
@find@
@@
(
intel_de_read(...)
|
intel_de_read_fw(...)
|
intel_de_write(...)
|
intel_de_write_fw(...)
)

@has_include@
@@
(
 #include "intel_de.h"
|
 #include "display/intel_de.h"
)

@depends on find && !has_include@
@@
+ #include "intel_de.h"
  #include "intel_display_types.h"

@depends on find && !has_include@
@@
+ #include "display/intel_de.h"
  #include "display/intel_display_types.h"

Cc: Cooper Chiou <cooper.chiou@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430143945.6776-1-ville.syrjala@linux.intel.com

drm/i915/tgl+: Add the missing MC CCS/XYUV8888 format support

Make sure that the XYUV8888 format is handled correctly when it's used
with a MC_CCS modifier framebuffer. Besides this format not working, the
driver will also return an incorrect error value when trying to use it,
indicating that the second color plane in the framebuffer is set
unexpectedly.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210501002853.4132009-1-imre.deak@intel.com

drm/i915: Pass intel_framebuffer instad of drm_framebuffer to intel_fill_fb_info()

Make one step to pass intel_framebuffer to all intel_fb functions.

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

drm/i915/audio: fix indentation, remove extra braces

Cleanup the code. No functional changes.

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

drm/i915/audio: simplify, don't mask out in all branches

Lift the masking outside of the if branches. No functional changes.

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

drm/i915/backlight: use unique backlight device names

Registering multiple backlight devices with intel_backlight name will
obviously fail, regardless of whether they're two connectors in the same
drm device or two different drm devices.

It would be preferrable to switch to completely unique names, and sunset
the generic intel_backlight name. However, there are apparently users
out there that hardcode the name, so the change would break backward
compatibility.

As a compromise, register the first device with intel_backlight name. In
the common case, this is the only backlight device anyway. From the
second device on, use card%d-%s-backlight format, for example
card0-eDP-2-backlight, to make the name unique.

This approach does not preclude us from registering the first device
using the same naming scheme in the future.

v2: Keep using intel_backlight name for first backlight device

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2794
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7dc3f6974711ce44522189dc9db05d1e6e24e6d8.1619604743.git.jani.nikula@intel.com

drm/i915/backlight: clean up backlight device register

Add connector and backlight device name to logging, and propagate error
code from backlight_device_register() instead of flattening to
-ENODEV. Storing the name in an allocated buffer is unnecessary here,
but makes follow-up work on names much cleaner.

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

drm/i915/adl_s: ADL-S platform Update PCI ids for Mobile BGA

As per Bspec: 53655 Update PCI ids for Mobile BGA.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Anand Moon <anandx.ram.moon@intel.com>
Reviewed-by: Aditya Swarup <aditya.swarup@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210203091029.2089-1-anandx.ram.moon@intel.com

drm/i915: Add frontbuffer tracking tracepoints

Add some tracpoints for frontbuffer tracking so we can
try to figure out what's going on.

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

drm/i915: Stop using crtc->index as the pipe

The pipe crc code slipped theough the net when we tried to
eliminate all crtc->index==pipe abuses. Remedy that.

And while at it get rid of those nasty intel_crtc+drm_crtc
pointer aliases.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210426185612.13223-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

drm/i915: Remove stray newlines

A bunch of files have a stray newline at the end. Remove it.

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

drm/i915: Fix pre-skl DP AUX precharge length

DP v1.1+ says:
"The DisplayPort transmitter, which is the driving end for a request
 transaction, pre-charges the AUX-CH+ and AUX-CH- to a common mode
 voltage by transmitting 10 to 16 consecutive 0’s in Manchester II code.
 After the active pre-charge, the transmitter sends an AUX Sync pattern.
 The AUX Sync pattern must be as follows:
 Start with 16 consecutive 0s in Manchester-II code, which results in
 a transition from low to high in the middle of each bit period.
 Including active pre-charge pulses, there shall be 26 to 32
 consecutive 0s before the end of the AUX_SYNC pattern."

BDW bspec says:
"Used to determine the precharge time for the Aux Channel. During this
 time the Aux Channel will drive the SYNC pattern. Every microsecond
 gives one additional SYNC pulse beyond the hard coded 26 SYNC pulses.
 The value is the number of microseconds times 2. Default is 3 decimal
 which gives 6us of precharge which is 6 extra SYN pulses for a total
 of 32."

CPT bspec says the same thing apart from:
"... Default is 5 decimal which gives 10us of precharge which is 10
 extra SYNC pulses for a total of 36."

So it looks like to match the max of 32 of the DP spec we should just
always program this extra precharge time to 3.

Unfortunately g4x/ibx bspec doesn't have this clarification, but
since the cpt default was still the same 5 as for g4x/ibx let's
assume the behaviour was always the same.

I also did a bit more archaeology and found the following:
 commit e3421a189447 ("drm/i915: enable DP/eDP for Sandybridge/Cougarpoint")
  added the precharge==3 for snb
 commit 092945e11c5b ("drm/i915/dp: Use auxch precharge value of 5 everywhere")
  tried to change it to be 5 for snb
 commit 6b4e0a93ff6e ("Revert "drm/i915/dp: Use auxch precharge value of 5 everywhere"")
  went back to 3 for snb due to a regression

So I think the value of 5 was just always wrong, but I guess very
few display actually get upset if we do too many SYNCs. Also DP 1.0
did not specify any max value for this, whereas DP 1.1+ added the
max==32 wording.

Additionally I hooked up a scope to a few machines with the following
findings:
- ibx and cpt both give us the expected 32 total sync pulses with
  precharge==3
- ctg is a bit different, it has the 10 hardcoded precharge sync
  pulses same as later platforms (so we get at least 26 sync
  pulses in total). However the additional precharge length (which
  is what we're changing here) is not done with sync pulses.
  Instead ctg does this part of the precharge with a steady DC
  voltage. If we wanted to 100% match DP 1.1+ here we should perhaps
  set prechange length to 0, but less precharge might make AUX less
  reliable, and so far we're not aware of any problems due to the DC
  precharge. Hence I think precharge==3 is probably the best choice
  here too to make the total length of precharge consistent with
  the later platforms.

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

drm/i915/display: move crtc and dpll declarations where they belong

The definitions are in the crtc and dpll files; move the declarations to
the corresponding headers.

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

drm/i915/hdcp: add intel_dp_hdcp.h and rename init accordingly

Add separate intel_dp_hdcp.h to go with intel_dp_hdcp.c, and rename the
init function intel_dp_hdcp_init() to follow naming where function
prefix matches the file name.

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

drm/i915/display: Disable PSR2 if TGL Display stepping is B1 from A0

TGL PSR2 hardware tracking shows momentary flicker and screen shift if
TGL Display stepping is B1 from A0.
It has been fixed from TGL Display stepping C0.

HSDES: 18015970021
HSDES: 2209313811
BSpec: 55378

v2: Add checking of PSR2 manual tracking (Jose)

Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210422160544.2427123-1-gwan-gyeong.mun@intel.com

drm: Rename DP_PSR_SELECTIVE_UPDATE to better mach eDP spec

DP_PSR_EN_CFG bit 5 aka "Selective Update Region Scan Line Capture
Indication" in eDP spec has a ambiguous name, so renaming to better
match specification.

While at it, replacing bit shit by BIT() macro and adding the version
some registers were added to eDP specification.

Cc: <dri-devel@lists.freedesktop.org>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210421220224.200729-1-jose.souza@intel.com

drm/i915: Simplify CCS and UV plane alignment handling

We can handle the surface alignment of CCS and UV color planes for all
modifiers at one place, so do this. An AUX color plane can be a CCS or a
UV plane, use only the more specific query functions and remove
is_aux_plane() becoming redundant.

While at it add a TODO for linear UV color plane alignments. The spec
requires this to be stride-in-bytes * 64 on all platforms, whereas the
driver uses an alignment of 4k for gen<12 and 256k for gen>=12 for
linear UV planes.

v2:
- Restore previous alignment for linear UV surfaces.

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

drm/i915/dsi: Fix comment typo

Change 'befor' to 'before'.

Signed-off-by: zuoqilin <zuoqilin@yulong.com>
[Jani: Fix comment marker placement while applying.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210317074228.1147-1-zuoqilin1@163.com

drm/i915/display/xelpd: Do not program EDP_Y_COORDINATE_ENABLE

EDP_Y_COORDINATE_ENABLE became a reserved register in display 13.
EDP_Y_COORDINATE_VALID have the same fate as EDP_Y_COORDINATE_ENABLE
but as we don't need it, removing the macro definition of it.

BSpec: 50422
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@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/20210421220224.200729-2-jose.souza@intel.com

drm/i915/dmc: Let's abstract the dmc path.

Although this abstraction removes the convenience of grepping
for the file name, it:
- makes addition easier.
- makes it easier to tweak global path when experiments are needed.
- get in sync with guc/huc, without getting overly abstracted.
- allows future junction with CSR_VERSION for simplicity.
- Enforces dmc file will never change this standard.

v2: define DMC_PATH inside .c (Lucas)

Cc: Fei Yang <fei.yang@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com> #v1
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210421094406.2017733-1-rodrigo.vivi@intel.com

drm/i915/dp: Use slow and wide link training for everything

Screen flickers on Innolux eDP 1.3 panel when clock rate 540000 is in use.

According to the panel vendor, though clock rate 540000 is advertised,
but the max clock rate it really supports is 270000.

Ville Syrjälä mentioned that fast and narrow also breaks some eDP 1.4
panel, so use slow and wide training for all panels to resolve the
issue.

User also confirmed that the new strategy doesn't introduce any
regression on XPS 9380.

v2:
 - Use slow and wide for everything.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3384
References: https://gitlab.freedesktop.org/drm/intel/-/issues/272
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210421052054.1434718-1-kai.heng.feng@canonical.com

drm/i915: Say "enable foo" instead of "set foo to enabled"

Use simpler sentences. Just say "enable foo" instead
of "set foo to enabled" etc.

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

drm/i915: Add enabledisable()

'enable ? "enable" : "disable"' is a fairly common pattern in
our debug prints. Let's introduce a helper for it.

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

drm/i915: Polish for_each_dbuf_slice()

Now that we have the dbuf slice mask stored in the device info
let's use it for for_each_dbuf_slice_in_mask*().

With this we cal also rip out intel_dbuf_size() and
intel_dbuf_num_slices().

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

drm/i915: Use intel_de_rmw() for DBUF_POWER_REQUEST

Use intel_de_rmw() instead of hand rolling it.

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

drm/i915: Use intel_dbuf_slice_size()

Use intel_dbuf_slice_size() instead of hand rolling it.
Also clean up some of the types.

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

drm/i915: Store dbuf slice mask in device info

Let's just store the dbuf slice information as a bitmask
in the device info. Makes life a little easier later.

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

drm/i915: Handle dbuf bypass path allocation earlier

We always reserve the same 4 dbuf blocks for the bypass path
allocation, so might as well do that when declaring the dbuf
size.

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

drm/i915: Collect dbuf device info into a sub-struct

Collect the related dbuf information into a struct.

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

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

This code should propagate the error from intel_overlay_pin_fb()
but currently it returns success.

Fixes: 1b321026e213 ("drm/i915: Pass ww ctx to intel_pin_to_display_plane")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/YHaFcEzcnh/hk1/Q@mwanda

drm/i915/pm: Make the wm parameter of print_wm_latency a pointer

This fixes the following build error with GCC 11:

    In function ‘snb_wm_latency_quirk’,
        inlined from ‘ilk_setup_wm_latency’ at drivers/gpu/drm/i915/intel_pm.c:3109:3,
        inlined from ‘intel_init_pm’ at drivers/gpu/drm/i915/intel_pm.c:7695:3:
    drivers/gpu/drm/i915/intel_pm.c:3058:9: error: ‘intel_print_wm_latency’ reading 16 bytes from a region of size 10 [-Werror=stringop-overread]
     3058 |         intel_print_wm_latency(dev_priv, "Primary", dev_priv->wm.pri_latency);
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/gpu/drm/i915/intel_pm.c: In function ‘intel_init_pm’:
    drivers/gpu/drm/i915/intel_pm.c:3058:9: note: referencing argument 3 of type ‘const u16 *’ {aka ‘const short unsigned int *’}
    drivers/gpu/drm/i915/intel_pm.c:2995:13: note: in a call to function ‘intel_print_wm_latency’
     2995 | static void intel_print_wm_latency(struct drm_i915_private *dev_priv,
          |             ^~~~~~~~~~~~~~~~~~~~~~

As far as I can tell, we don't actually need 8 elements except on SKL
and that uses dev_priv->wm.skl_latency which has enough.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210413173259.472405-1-jason@jlekstrand.net
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Merge tag 'topic/intel-gen-to-ver-2021-04-19' of git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next

Gen to ver conversions across the driver

The main change is Lucas' series [1], with Ville's GLK fixes [2] and a
cherry-pick of Matt's commit [3] from drm-intel-next as a base to avoid
conflicts.

[1] https://patchwork.freedesktop.org/series/88825/
[2] https://patchwork.freedesktop.org/series/88938/
[3] 70bfb30743d5 ("drm/i915/display: Eliminate IS_GEN9_{BC,LP}")

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
# Conflicts:
# drivers/gpu/drm/i915/display/intel_bios.c
# drivers/gpu/drm/i915/display/intel_cdclk.c
# drivers/gpu/drm/i915/display/intel_ddi.c
# drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
# drivers/gpu/drm/i915/display/intel_display.c
# drivers/gpu/drm/i915/display/intel_display_power.c
# drivers/gpu/drm/i915/display/intel_dp.c
# drivers/gpu/drm/i915/display/intel_dpll_mgr.c
# drivers/gpu/drm/i915/display/intel_fbc.c
# drivers/gpu/drm/i915/display/intel_gmbus.c
# drivers/gpu/drm/i915/display/intel_hdcp.c
# drivers/gpu/drm/i915/display/intel_hdmi.c
# drivers/gpu/drm/i915/display/intel_pps.c
# drivers/gpu/drm/i915/intel_pm.c
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/878s5ebny0.fsf@intel.com

drm/i915: Reuse intel_adjusted_rate() for pfit pixel rate adjustment

Replace the hand rolled pfit downscale calculations with
intel_adjusted_rate().

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

drm/i915: Extract intel_adjusted_rate()

Extract a small helper to calculate the downscaling
adjusted pixel rate/data rate/etc.

v2: Drop the plane visibility check and add a comment explaining why

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

drm/i915/display/psr: Fix cppcheck warnings

Fix redundant condition, caught in cppcheck by kernel test robot.

Reported-by: kernel test robot <lkp@intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Fixes: b64d6c51380b ("drm/i915/display: Support PSR Multiple Instances")
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Harish Chegondi <harish.chegondi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210409231738.238682-1-jose.souza@intel.com

drm/i915: Drop redundant address-of op before lttpr_common_caps array

The address-of op in front of an array is just an alias to using the
array on its own, so drop the op.

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

drm/i915: Fix modesetting in case of unexpected AUX timeouts

In case AUX failures happen unexpectedly during a modeset, the driver
should still complete the modeset. In particular the driver should
perform the link training sequence steps even in case of an AUX failure,
as this sequence also includes port initialization steps. Not doing that
can leave the port/pipe in a broken state and lead for instance to a
flip done timeout.

Fix this by continuing with link training (in a no-LTTPR mode) if the
DPRX DPCD readout failed for some reason at the beginning of link
training. After a successful connector detection we already have the
DPCD read out and cached, so the failed repeated read for it should not
cause a problem. Note that a partial AUX read could in theory partly
overwrite the cached DPCD (and return error) but this overwrite should
not happen if the returned values are corrupted (due to a timeout or
some other IO error).

Kudos to Ville to root cause the problem.

Fixes: 264613b406eb ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/3308
Cc: stable@vger.kernel.org # 5.11
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210412232413.2755054-1-imre.deak@intel.com

drm/i915: split dgfx features from gen 12

Make them independent so we can use DGFX_FEATURES more generically.
For future platforms that do not use the GEN nomenclature we will define
graphics, media and display separately, so we avoid setting graphics_ver
with the GEN() macro.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-13-lucas.demarchi@intel.com

drm/i915: add media and display versions to device_info print

Since we are now converting from a single gen version to graphics_ver,
media_ver and display_ver, add the last 2 when printing the device info.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-12-lucas.demarchi@intel.com

drm/i915: finish removal of gen from intel_device_info

Now that it's not being used anymore, finish its removal. Like for
gen_mask, we replace INTEL_GEN() and IS_GEN()  macros to use the new
field.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
[Jani: Minor code comment change while applying.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-11-lucas.demarchi@intel.com

drm/i915: eliminate remaining uses of intel_device_info->gen

Replace gen with the new graphics_ver value and use GRAPHICS_VER()
in those places.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-10-lucas.demarchi@intel.com

drm/i915: finish removal of gen_mask

Now that it's not used anywhere, remove it from struct
intel_device_info. To allow a period in which code will be converted to
the new macro, keep IS_GEN_RANGE() around, just redefining it to use
the new fields. The size advantage from IS_GEN_RANGE() using a mask is
not that big as it has pretty limited use througout the driver:

   text    data     bss     dec     hex filename
2758497   95965    6496 2860958  2ba79e drivers/gpu/drm/i915/i915.ko.old
2758586   95953    6496 2861035  2ba7eb drivers/gpu/drm/i915/i915.ko.new

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
[Jani: Minor code comment change while applying.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-9-lucas.demarchi@intel.com

drm/i915/selftests: eliminate use of gen_mask

Remove the remaining uses of INTEL_GEN_MASK() and the correspondent
gen_mask in struct intel_device_info. This will allow the removal of
gen_mask later since it's incompatible with the new per-IP versioning
scheme.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-8-lucas.demarchi@intel.com

drm/i915/selftests: replace unused mask with simple version

Since its introduction 2 years ago, we never used the mask to span more
than one gen. Replace gen_mask a single number and start using the new
GRAPHICS_VER().

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-7-lucas.demarchi@intel.com

drm/i915/gt: replace gen use in intel_engine_cs

Start using the new fields graphics_version for the previous gen checks.
Here we rename the "gen" field and replace the comparisons using it to
start using the new GRAPHICS_VER(). Other uses of INTEL_GEN() were left
as is for automatic conversion later.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-6-lucas.demarchi@intel.com

drm/i915: add macros for graphics and media versions

Like it was done in
commit 01eb15c9165e ("drm/i915: Add DISPLAY_VER() and related macros")
add the correspondent macros for graphics and media. Going forward we
will prefer checking the versions for the specific IPs (graphics, media
and display) rather than grouping everything under a "gen" version.

For consistency and to make the maintenance easier, it'd be preferred
not to mix the *GEN* macros with the new ones. For older platforms we
can simply consider that the previous "gen" number will extend to all
3 IPs. Then we can start replacing its use in the driver. Right now this
replacement is not done and only the infrastructure is put in place.
We also leave gen and gen_mask inside struct intel_device_info while
it's still being used throughout the code.

v2: Repurpose IS_{GRAPHICS,MEDIA}_VER() macros to work with a range

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[Jani: Minor code comment change while applying.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-5-lucas.demarchi@intel.com

drm/i915/display: rename display version macros

While converting the rest of the driver to use GRAPHICS_VER() and
MEDIA_VER(), following what was done for display, some discussions went
back on what we did for display:

1) Why is the == comparison special that deserves a separate
macro instead of just getting the version and comparing directly
like is done for >, >=, <=?

2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for
brevity. If we remove the current users of IS_DISPLAY_VER(), we
could actually repurpose it for a range check

With (1) there could be an advantage if we used gen_mask since multiple
conditionals be combined by the compiler in a single and instruction and
check the result. However a) INTEL_GEN() doesn't use the mask since it
would make the code bigger everywhere else and b) in the cases it made
sense, it also made sense to convert to the _RANGE() variant.

So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range
like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER()
users to use == and != operators. Aside from the definition changes,
this was done by the following semantic patch:

@@ expression dev_priv, E1; @@
- !IS_DISPLAY_VER(dev_priv, E1)
+ DISPLAY_VER(dev_priv) != E1

@@ expression dev_priv, E1; @@
- IS_DISPLAY_VER(dev_priv, E1)
+ DISPLAY_VER(dev_priv) == E1

@@ expression dev_priv, from, until; @@
- IS_DISPLAY_RANGE(dev_priv, from, until)
+ IS_DISPLAY_VER(dev_priv, from, until)

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
[Jani: Minor conflict resolve while applying.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com

drm/i915: rename display.version to display.ver

The macro we use to check is called DISPLAY_VER(). While using this
macro and the new ones being added in following changes I made the
mistake multiple times when mixing both "ver" and "version". Although
it's usually better to prefer the complete name, the shorhand
DISPLAY_VER() / GRAPHICS_VER / MEDIA_VER are clear and cause less
visual polution.

Another issue is when copying the variable to other places.
"display.version" would be copied to a "display_version" variable which
is long and would make people abbreviate as "version", or "display_ver".
In the first case it's not always clear what version refers to, and in
the second case it just hints it should be the name in the first place.

So, in the same way use used "gen" rather than "generation", use "ver"
instead of "version".

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-3-lucas.demarchi@intel.com

drm/i915/display: use DISPLAY_VER() on remaining users

Commit 989634fb49ad ("drm/i915/audio: set HDA link parameters in driver")
added INTEL_GEN() in the display code, where it should actually be using
DISPLAY_VER(). Switch to the new macro.

Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-2-lucas.demarchi@intel.com

drm/i915: Remove a few redundant glk checks

Now that glk display version is 10 we can drop a few more glk checks.

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

drm/i915: Don't use {skl, cnl}_hpd_pin() for bxt/glk

Just let bxt/glk fall back to intel_hpd_pin_default() instead
of using skl_hpd_pin() or cnl_hpd_pin(). Doesn't really matter
since both functions will end up returning the correct hpd pin
anyway, but I find it a bit less confusing when bxt/glk are
fully separated from the logic for the other platforms.

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

drm/i915: Disable LTTPR detection on GLK once again

The glk display version change is causing us to again attempt
LTTPR detection on glk. We must not do tha since glk doesn't
have a long enough AUX timeout. Restore the correct logic to
skip the detection.

Cc: Matt Roper <matthew.d.roper@intel.com>
Fixes: 2b5a4562edd0 ("drm/i915/display: Simplify GLK display version tests")
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210412054607.18133-4-ville.syrjala@linux.intel.com

drm/i915: Restore lost glk ccs w/a

We lost a CCS related w/a on glk when the display version
became 10 instead of 9. Restore the correct check.

Cc: Matt Roper <matthew.d.roper@intel.com>
Fixes: 2b5a4562edd0 ("drm/i915/display: Simplify GLK display version tests")
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210412054607.18133-3-ville.syrjala@linux.intel.com

drm/i915: Restore lost glk FBC 16bpp w/a

We lost the FBC 16bpp 512byte stride requirement on glk when
we switched from display version 9 to 10. Restore the w/a to
avoid enabling FBC with a bad stride and thus display garbage.

Cc: Matt Roper <matthew.d.roper@intel.com>
Fixes: 2b5a4562edd0 ("drm/i915/display: Simplify GLK display version tests")
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210412054607.18133-2-ville.syrjala@linux.intel.com

drm/i915/display: Eliminate IS_GEN9_{BC,LP}

Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the
display code, we should also kill off our use of the IS_GEN9_* macros
too.  We'll do the conversion manually this time instead of using
Coccinelle since the most logical substitution can depend heavily on the
code context, and sometimes we can keep the code simpler if we make
additional adjustments such as swapping the order of if/else arms.

v2:
 - Restore a lost negation in intel_pll_is_valid().

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210407203945.1432531-1-matthew.d.roper@intel.com
(cherry picked from commit 70bfb30743d5da73058b0a2271e9c127a84fb494)
[Jani: cherry picked to topic branch to reduce conflicts]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Revert "drm/i915/tgl/psr: Fix glitches when doing frontbuffer modifications"

This reverts commit 71c1a4998320962f7b8362b2c5ee36610d49e8fb.

The proper fix is Wa_14013723622, so now we can revert this WA and
get back some power savings.

Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Tested-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408204917.254272-2-jose.souza@intel.com

drm/i915/display: Implement Wa_14013723622

This WA fix some display glitches when the system is under high
memory pressure.

BSpec: 52890
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Tested-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408204917.254272-1-jose.souza@intel.com

drm/i915/display/vlv_dsi: Move panel_pwr_cycle_delay to next panel-on

Instead of sleeping panel_pwr_cycle_delay ms when turning the panel off,
record the time it is turned off and if necessary wait any (remaining)
time when the panel is turned on again.

Also sleep the remaining time on shutdown, because on reboot the
GOP will immediately turn on the panel again.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325114823.44922-2-hdegoede@redhat.com

drm/i915/display/vlv_dsi: Do not skip panel_pwr_cycle_delay when disabling the panel

After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
displays gracefully on reboot"), the DSI panel on a Cherry Trail based
Predia Basic tablet would no longer properly light up after reboot.

I've managed to reproduce this without rebooting by doing:
chvt 3; echo 1 > /sys/class/graphics/fb0/blank;\
echo 0 > /sys/class/graphics/fb0/blank

Which rapidly turns the panel off and back on again.

The vlv_dsi.c code uses an intel_dsi_msleep() helper for the various delays
used for panel on/off, since starting with MIPI-sequences version >= 3 the
delays are already included inside the MIPI-sequences.

The problems exposed by the "Shut down displays gracefully on reboot"
change, show that using this helper for the panel_pwr_cycle_delay is
not the right thing to do. This has not been noticed until now because
normally the panel never is cycled off and directly on again in quick
succession.

Change the msleep for the panel_pwr_cycle_delay to a normal msleep()
call to avoid the panel staying black after a quick off + on cycle.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325114823.44922-1-hdegoede@redhat.com

drm/i915/display: Defeature PSR2 for RKL and ADL-S

PSR2 is defeatured for RKL and ADL-S, no important power impact as
those are desktop CPUs and PSR2 was not even enabled by default yet
in platforms without PSR2 HW tracking.

HSDES: 14011750631
HSDES: 14011741325
BSpec: 53273
Cc: Caz Yokoyama <Caz.Yokoyama@intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408214205.327704-1-jose.souza@intel.com

drm/i915: skip display initialization when there is no display

Display features should not be initialized or de-initialized when there
is no display. Skip modeset initialization, output setup, plane, crtc,
encoder, connector registration, display cdclk and rawclk
initialization, display core initialization, etc.

Skip the functionality at as high level as possible, and remove any
redundant checks. If the functionality is conditional to *other* display
checks, do not add more. If the un-initialization has checks for
initialization, do not add more.

We explicitly do not care about any GMCH/VLV/CHV code paths, as they've
always had and will have display.

Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408203150.237947-3-jose.souza@intel.com

drm/i915: Do not set any power wells when there is no display

Power wells are only part of display block and not necessary when
running a headless driver.

Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408203150.237947-2-jose.souza@intel.com

drm/i915: Skip display interruption setup when display is not available

Return ealier in the functions doing interruption setup for GEN8+ also
adding a warning in gen8_de_irq_handler() to let us know that
something else is still missing.

Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@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>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408203150.237947-1-jose.souza@intel.com

drm/i915/hdcp: Fix uninitialized symbol 'msg_end'

Fix static analysis tool uninitialized symbol error.

v2:
- use ktime_set(0, 0) instead to initialize to zero. [Ankit]

Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210408082642.27066-1-anshuman.gupta@intel.com

drm/i915: Don't zero out the Y plane's watermarks

Don't zero out the watermarks for the Y plane since we've already
computed them when computing the UV plane's watermarks (since the
UV plane always appears before ethe Y plane when iterating through
the planes).

This leads to allocating no DDB for the Y plane since .min_ddb_alloc
also gets zeroed. And that of course leads to underruns when scanning
out planar formats.

Cc: stable@vger.kernel.org
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Fixes: dbf71381d733 ("drm/i915: Nuke intel_atomic_crtc_state_for_each_plane_state() from skl+ wm code")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210327005945.4929-1-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT

Looks like that there actually are another subset of laptops on the market
that don't support the Intel HDR backlight interface, but do advertise
support for the VESA DPCD backlight interface despite the fact it doesn't
seem to work.

Note though I'm not entirely clear on this - on one of the machines where
this issue was observed, I also noticed that we appeared to be rejecting
the VBT defined backlight frequency in
intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that:

/* Use highest possible value of Pn for more granularity of brightness
 * adjustment while satifying the conditions below.
 * ...
 * - FxP is within 25% of desired value.
 *   Note: 25% is arbitrary value and may need some tweak.
 */

So it's possible that this value might just need to be tweaked, but for now
let's just disable the VESA backlight interface unless it's specified in
the VBT just to be safe. We might be able to try enabling this again by
default in the future.

Fixes: 2227816e647a ("drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight")
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210318170204.513000-1-lyude@redhat.com

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

Sync up with topic/i915-gem-next and drm-intel-gt-next.

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

Merge tag 'drm-intel-next-2021-04-01' of git://anongit.freedesktop.org/drm/drm-intel into drm-next

Features:
- Add support for FBs requiring a power-of-two stride padding (Imre)

Refactoring:
- Disassociate display version from gen (Matt)
- Refactor legacy DP and HDMI code to separate files (Ville)
- Refactor FB plane code to a separate file (Imre)
- Refactor VBT child device info parsing and usage (Jani)
- Refactor KBL/TGL/ADL-S display and gt stepping schemes (Jani)

Fixes:
- DP Link-Training Tunable PHY Repeaters (LTTPR) fixes (Imre)
- HDCP fixes (Anshuman)
- DP 2.0 HDMI 2.1 PCON Fixed Rate Link (FRL) fixes (Ankit)
- Set HDA link parameters in driver (Kai)
- Fix enabled_planes bitmask (Ville)
- Fix transposed arguments to skl_plane_wm_level() (Ville)
- Stop adding planes to the commit needlessly (Ville)

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/87v996ml17.fsf@intel.com

Merge tag 'drm-intel-gt-next-2021-04-06' of git://anongit.freedesktop.org/drm/drm-intel into drm-next

Driver Changes:

- Prepare for local/device memory support on DG1 by starting
  to use it for kernel internal allocations: context, ring
  and engine scratch (Matt A, CQ, Abdiel, Imre)
- Sandybridge fix to avoid hard hang on ring resume (Chris)
- Limit imported dma-buf size to int32 (Matt A)
- Double check heartbeat timeout before resetting (Chris)

- Use new tasklet API for execution list (Emil)
- Fix SPDX checkpats warnings (Chris)
- Fixes for various checkpatch warnings (Chris)
- Selftest improvements (Chris)
- Move the defer_request waiter active assertion to correct spot (Chris)
- Make local-memory probing a GT operation (Matt, Tvrtko)
- Protect against request freeing during cancellation on wedging (Chris)
- Retire unexpected starting state error dumping (Chris)
- Distinction of memory regions in debugging (Zbigniew)
- Always flush the submission queue on checking for idle (Chris)

- Consolidate 2big error check to helper (Matt)
- Decrease number of subplatform bits (Tvrtko)
- Remove unused internal request priority levels (Chris)
- Document the unused internal header bits in buddy allocator (Matt)
- Cleanup the region class/instance encoding (Matt)

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/YGxksaZGXHnFxlwg@jlahtine-mobl.ger.corp.intel.com

Merge tag 'mediatek-drm-next-5.13' of https://git./linux/kernel/git/chunkuang.hu/linux into drm-next

Mediatek DRM Next for Linux 5.13

1. Fine tune the line time for EOTp.
2. Add support mt8192 dpi.
3. Make crtc config-updating atomic.
4. Don't support hdmi connector creation.

From: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210405082248.3578-1-chunkuang.hu@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/i915/display: Eliminate IS_GEN9_{BC,LP}

Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the
display code, we should also kill off our use of the IS_GEN9_* macros
too.  We'll do the conversion manually this time instead of using
Coccinelle since the most logical substitution can depend heavily on the
code context, and sometimes we can keep the code simpler if we make
additional adjustments such as swapping the order of if/else arms.

v2:
 - Restore a lost negation in intel_pll_is_valid().

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210407203945.1432531-1-matthew.d.roper@intel.com

drm/i915: Fix invalid access to ACPI _DSM objects

intel_dsm_platform_mux_info() tries to parse the ACPI package data
from _DSM for the debug information, but it assumes the fixed format
without checking what values are stored in the elements actually.
When an unexpected value is returned from BIOS, it may lead to GPF or
NULL dereference, as reported recently.

Add the checks of the contents in the returned values and skip the
values for invalid cases.

v1->v2: Check the info contents before dereferencing, too

BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1184074
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210402082317.871-1-tiwai@suse.de

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

drm-misc-next for 5.13:

UAPI Changes:

Cross-subsystem Changes:

Core Changes:
  - mst: Improve topology logging
  - edid: Rework and improvements for displayid

Driver Changes:
  - anx7625: Regulators support
  - bridge: Support for the Chipone ICN6211, Lontium LT8912B
  - lt9611: Fix 4k panels handling

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210401110552.2b3yetlgsjtlotcn@gilmour

drm/i915/sysfs: convert snprintf to sysfs_emit

Fix the following coccicheck warning:
drivers/gpu/drm/i915//i915_sysfs.c:266:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:285:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:276:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:335:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:390:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:465:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:107:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:75:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:83:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:91:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:99:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/i915//i915_sysfs.c:326:8-16:
WARNING: use scnprintf or sprintf

Signed-off-by: Xuezhi Zhang <zhangxuezhi1@yulong.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210404084103.528211-1-llyz108@163.com

drm/i915/display/psr: Disable DC3CO when the PSR2 is used

Due to the changed sequence of activating/deactivating DC3CO, disable
DC3CO until the changed dc3co activating/deactivating sequence is applied.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/3134
Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210401170237.40472-1-gwan-gyeong.mun@intel.com

drm/i915: Uninit the DMC FW loader state during shutdown

We need to wait for the DMC FW loader work to complete during shutdown,
even if it's unlikely to be still pending by that time, fix this.

This also fixes the wakeref tracking WARN during shutdown about the
leaked reference we hold due to a missing DMC firmware.

While at it add a TODO comment about unifying the shutdown and PM
power-off sequences and later these sequences with the driver remove and
system/runtime suspend sequences.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: https://lore.kernel.org/lkml/20210303055517.GB2708@xsang-OptiPlex-9020
Reported-and-tested-by: kernel test robot <oliver.sang@intel.com>
Reported-and-tested-by: Edward Baker <edward.baker@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210311144529.3059024-1-imre.deak@intel.com

drm/i915: Update plane ratio for icl+

According to bspec icl+ no longer need any extra cdclk guardband
for 64bpp formats. Make it so.

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