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

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210506073836.14848-1-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210505191140.14215-1-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>

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: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210505213801.80772-1-jose.souza@intel.com

Replace the hand rolled PLL lock bit waits with intel_de_wait_for_*().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430153444.29270-6-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Replace the hand rolled rmw sequences with intel_de_rmw().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430153444.29270-5-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Replace the hand rolled rmw sequences with intel_de_rmw().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430153444.29270-4-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430153444.29270-3-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Extract a few of the switch statements into helper functions to
reduce the pollution in the cdclk programming functions.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430153444.29270-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

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 dd584fc0
("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: NAnshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430143945.6776-2-ville.syrjala@linux.intel.com

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: NAnshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430143945.6776-1-ville.syrjala@linux.intel.com

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: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210501002853.4132009-1-imre.deak@intel.com

Make one step to pass intel_framebuffer to all intel_fb functions.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210414155208.3161335-2-imre.deak@intel.com

Cleanup the code. No functional changes.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6c2f6afa4c8866f8c1714b4f8dba9ea2d1509e4a.1620115983.git.jani.nikula@intel.com

Lift the masking outside of the if branches. No functional changes.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a87fd5e66b52c4d52a568888e1b8037841786fd2.1620115982.git.jani.nikula@intel.com

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/2794Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7dc3f6974711ce44522189dc9db05d1e6e24e6d8.1619604743.git.jani.nikula@intel.com

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/271206461d9c0f42755792236330b588df3b532e.1619604743.git.jani.nikula@intel.com

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: NAnand Moon <anandx.ram.moon@intel.com>
Reviewed-by: NAditya Swarup <aditya.swarup@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210203091029.2089-1-anandx.ram.moon@intel.com

Add some tracpoints for frontbuffer tracking so we can
try to figure out what's going on.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210414022309.30898-2-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210426185612.13223-1-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

A bunch of files have a stray newline at the end. Remove it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210318181039.17260-2-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

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 e3421a18 ("drm/i915: enable DP/eDP for Sandybridge/Cougarpoint")
  added the precharge==3 for snb
 commit 092945e1 ("drm/i915/dp: Use auxch precharge value of 5 everywhere")
  tried to change it to be 5 for snb
 commit 6b4e0a93 ("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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210318181039.17260-1-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

The definitions are in the crtc and dpll files; move the declarations to
the corresponding headers.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210427120315.12342-1-jani.nikula@intel.com

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: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210427114520.4740-1-jani.nikula@intel.com

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: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210422160544.2427123-1-gwan-gyeong.mun@intel.com

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: NJosé Roberto de Souza <jose.souza@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210421220224.200729-1-jose.souza@intel.com

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: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210421173220.3587009-1-imre.deak@intel.com

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

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: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210421220224.200729-2-jose.souza@intel.com

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: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com> #v1
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210421094406.2017733-1-rodrigo.vivi@intel.com

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/272Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210421052054.1434718-1-kai.heng.feng@canonical.com

Use simpler sentences. Just say "enable foo" instead
of "set foo to enabled" etc.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416171011.19012-9-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

'enable ? "enable" : "disable"' is a fairly common pattern in
our debug prints. Let's introduce a helper for it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416171011.19012-8-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416171011.19012-7-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Use intel_de_rmw() instead of hand rolling it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416171011.19012-6-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Use intel_dbuf_slice_size() instead of hand rolling it.
Also clean up some of the types.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416171011.19012-5-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Let's just store the dbuf slice information as a bitmask
in the device info. Makes life a little easier later.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416171011.19012-4-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416171011.19012-3-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Collect the related dbuf information into a struct.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416171011.19012-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

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

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