The PUNIT FW is currently returning 0 for all memory bandwidth
parameters. Read the values directly from MCHBAR offsets 0x5918 and
0x4000(4).

v2 (Lucas): tidy up checking for ret slightly
v3 (Lucas):
  - Squash change to double the memory bandwidth based on
    MCHBAR Gear_type
  - Move ICL_GEAR_TYPE_MASK to the appropriate place and change prefix
    to DG1
  - Move register definitions to i915_reg.h
  - Make the MCHBAR path permanent for DG1
  - Convert to REG_BIT()/REG_GENMASK()
v4: Drop unneeded initializations

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Jani Saarinen <jani.saarinen@intel.com>
Signed-off-by: NClint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@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/20210708175226.2451260-1-lucas.demarchi@intel.com

On XELPD platforms, color management support is not yet enabled.
Fix wrongly reporting the same through platform info, which was
resulting in incorrect initialization and usage.

Cc: Swati Sharma <swati2.sharma@intel.com>
Signed-off-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NSwati Sharma <swati2.sharma@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210707095253.23848-1-uma.shankar@intel.com

The 'has_cdclk_crawl' field in our device info structure is a boolean
flag and doesn't need a whole u8.  Add it as another 1-bit feature flag
and move it to the display section.  While we're at it, replace the
has_cdclk_crawl() function with a macro for consistency with our
handling of other feature flags.

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210707234206.2002849-1-matthew.d.roper@intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Add a small helper to keep intel_plane_helper_funcs static.
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/20210518132426.7567-1-jani.nikula@intel.com

Now that all the codebase is converted to the new *VER macros, remove
the old GEN ones.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210707181325.2130821-4-lucas.demarchi@intel.com

Commit 161058fb ("drm/i915: Add remaining conversions to GRAPHICS_VER")
did the last conversions to the new macros for version checks, but left
one instance behind and some other changes sneaked in to use INTEL_GEN.
Remove the last users so we can remove the macros.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210707181325.2130821-3-lucas.demarchi@intel.com

Earlier HDCP over MST support was added for TGL Platform.
Extending it to all future platfroms.

v2:
- Remove the platform check and commit log changes. [Jani]
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210705122208.25618-1-anshuman.gupta@intel.com

If we hit the error path here we unconditionally call
i915_gem_stolen_remove_node, even though we only allocate the
compressed_llb on older platforms. Therefore we should first check that
we actually allocated the node before trying to remove it.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/3709
Fixes: 46b2c40e ("drm/i915/fbc: Allocate llb before cfb")
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210701090326.1056452-1-matthew.auld@intel.com

_DG1_DPCLKA0_CFGCR0 maps between DPLL 0 and 1 with one bit for phy A
and B while _DG1_DPCLKA1_CFGCR0 maps between DPLL 2 and 3 with one
bit for phy C and D.

Reusing _cnl_ddi_get_pll() don't take that into cosideration returing
DPLL 0 and 1 for phy C and D.

That is a regression introduced in the refactor done in
commit 351221ff ("drm/i915: Move DDI clock readout to
encoder->get_config()").
While at it also dropping the macros previously used, not reusing it
to improve readability.

BSpec: 50286
Fixes: 351221ff ("drm/i915: Move DDI clock readout to encoder->get_config()")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210630210522.162674-1-jose.souza@intel.com

Bring drm-intel-next closer to drm-next and drm-intel-gt-next for a more
feasible baseline for topic branches.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

While reading the SDP infoframe, we are getting filtered with
the encoder type INTEL_OUTPUT_DDI which causes the infoframe
mismatch. This patch will drop encoder->type check as we can
mask individual infoframe type.

[1025.606556] i915 0000:00:02.0: [drm] *ERROR* mismatch in drm infoframe
[1025.607865] i915 0000:00:02.0: [drm] *ERROR* expected:
[1025.607879] i915 0000:00:02.0: HDMI infoframe: Dynamic Range and Mastering, version 1, length 26
[1025.607889] i915 0000:00:02.0: length: 26
[1025.607898] i915 0000:00:02.0: metadata type: 0
[1025.608292] i915 0000:00:02.0: eotf: 2
[1025.608302] i915 0000:00:02.0: x[0]: 35400
[1025.608312] i915 0000:00:02.0: y[0]: 14599
[1025.609115] i915 0000:00:02.0: x[1]: 8500
[1025.609947] i915 0000:00:02.0: y[1]: 39850
[1025.609959] i915 0000:00:02.0: x[2]: 6550
[1025.609970] i915 0000:00:02.0: y[2]: 2300
[1025.609980] i915 0000:00:02.0: white point x: 15634
[1025.609989] i915 0000:00:02.0: white point y: 16450
[1025.610381] i915 0000:00:02.0: max_display_mastering_luminance: 1000
[1025.610392] i915 0000:00:02.0: min_display_mastering_luminance: 500
[1025.610401] i915 0000:00:02.0: max_cll: 500
[1025.610816] i915 0000:00:02.0: max_fall: 1000
[1025.612457] i915 0000:00:02.0: [drm] *ERROR* found:
[1025.614354] ------------[ cut here ]------------
[1025.616244] pipe state doesn't match!
[1025.617640] WARNING: CPU: 6 PID: 2114 at drivers/gpu/drm/i915/display/intel_display.c:9332 intel_atomic_commit_tail+0x14d4/0x17c0 [i915]

V2:
* Drop encoder->type check

V3:
* Remove internal reviews

Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NBhanuprakash Modem <bhanuprakash.modem@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Signed-off-by: NUma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423141609.28568-1-bhanuprakash.modem@intel.com

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

The biggest fix is the restoration of mmap ioctl for gen12 integrated parts
which lack was breaking ADL-P with media stack.
Besides that a small selftest fix and a theoretical overflow on
i915->pipe_to_crtc_mapping.
Signed-off-by: NDave Airlie <airlied@redhat.com>

From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/YNtsfguvCRSROBUZ@intel.com

Merge tag 'drm-misc-next-fixes-2021-06-24' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

Short summary of fixes pull:

 * amdgpu: Fix test for allocation failures
Signed-off-by: NDave Airlie <airlied@redhat.com>

From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/YNQxVybBGdjLMUQJ@linux-uq9g

Removing force probe protection from EHL platform. Did
not observe warnings, errors, flickering or any visual
defects while doing ordinary tasks like browsing and
editing documents in a two monitor setup.

For more info drm-tip idle run results :
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NTejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.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/20210629104954.927151-1-tejaskumarx.surendrakumar.upadhyay@intel.com

Removing force probe protection from JSL platform. Did
not observe warnings, errors, flickering or any visual
defects while doing ordinary tasks like browsing and
editing documents in a two monitor setup.

For more info drm-tip idle run results :
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NTejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.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/20210629105356.927359-1-tejaskumarx.surendrakumar.upadhyay@intel.com

Reinstate the mmap ioctl for all current integrated platforms.
The intention was really to have it disabled for discrete graphics
where we enforce a single mmap mode.

This was reported to break ADL-P with the media stack, which was not the
intention. Although longer term we do still plan to sunset this ioctl
even for integrated, in favour of using mmap_offset instead.

Fixes: 35cbd91e ("drm/i915: Disable mmap ioctl for gen12+")
Signed-off-by: NThomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210624112914.311984-1-thomas.hellstrom@linux.intel.com
(cherry picked from commit d3f3baa3)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Add a single point of truth for figuring out the primary/secondary crtc
for bigjoiner instead of duplicating the magic pipe +/- 1 in multiple
places.

Also fix the pipe validity checks to properly take non-contiguous pipes
into account. The current checks may theoretically overflow
i915->pipe_to_crtc_mapping[pipe], albeit with a warning, due to fused
off pipes, as INTEL_NUM_PIPES() returns the actual number of pipes on
the platform, and the check is for INTEL_NUM_PIPES() == pipe + 1.

Prefer primary/secondary terminology going forward.

v2:
- Improved abstractions for pipe validity etc.

Fixes: 8a029c11 ("drm/i915/dp: Modify VDSC helpers to configure DSC for Bigjoiner slave")
Fixes: d961eb20 ("drm/i915/bigjoiner: atomic commit changes for uncompressed joiner")
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: NManasi Navare <manasi.dl.navare@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210610090528.20511-1-jani.nikula@intel.com
(cherry picked from commit 17203224)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Since we are already loop through the levels to sanitize them, mark what
is the real max_level so it can be used in subsequent loop. This makes
it simpler to later add the adjustment latency to "valid levels". No
change in behavior, just makes the code easier to follow.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210622212210.3746133-2-lucas.demarchi@intel.com

We should no longer increment level 0 by 1usec when we have 16Gb DIMMs.
Instead spec says to add 3usec (as opposed to 2) to each valid level
when punit replies 0 to level 0.

So set wm_lv_0_adjust_needed to false for DISPLAY_VER() >= 12 and set
the proper adjustment value when handling WaWmMemoryReadLatency.

Bspec: 49326, 4381
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210622212210.3746133-1-lucas.demarchi@intel.com

PSR2 is not compatible with DC3CO or VRR in this stepping, so not
enabling PSR2 if VRR will be enabled or not enabling DC3CO if PSR2 is
possible.

BSpec: 54369
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Matt Atwood <matthew.s.atwood@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/20210616203158.118111-5-jose.souza@intel.com

In some modes there is not enough time during hblank to transmit PSR2
SDP plus the pixels CRC SDP, if such case happens PSR2 needs to be
disabled.
But eDP spec 1.4b allows to transmit PSR2 SDP in a prior scanline
alone and than later the CRC SDP, allowing PSR2 to be enabled in
those hblank constrained modes.

BSpec: 49274
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/20210616203158.118111-4-jose.souza@intel.com

Another WA that is required for PSR2.

BSpec: 54369
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Matt Atwood <matthew.s.atwood@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/20210616203158.118111-3-jose.souza@intel.com

The PSR2_CTL io buffer wake and fast wake values do not match
expected in pre production hardware, so here adding a table that
matches with HW to program it with values that HW expect.

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/20210616203158.118111-2-jose.souza@intel.com

We were only handling X and width granularity, what was causing issues
when sink had a granularity different than 4.

While at it, renaming su_x_granularity to su_w_granularity to better
match reality.

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/20210616203158.118111-1-jose.souza@intel.com

Clear out the straggler 'intel_crtc' variables.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210609085632.22026-7-ville.syrjala@linux.intel.comReviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Sort out the mess with the local variables in
intel_fbdev_init_bios(). Get rid of all aliasing pointers,
use standard naming/types, and introduce a few more locals
in the loops to avoid the hard to read long struct walks.

While at we also polish the debugs a bit to use the
canonical [CRTC:%d:%s] style.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210609085632.22026-6-ville.syrjala@linux.intel.comReviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Just pass the full atomic state+crtc to the pre-skl watermark
functions, and clean up the types/variable names around the area.

Note that having both .compute_pipe_wm() and .compute_intermediate_wm()
is entirely redundant now. We could unify them to a single vfunc.
But let's do this one step at a time.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210609085632.22026-5-ville.syrjala@linux.intel.comReviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Sort out the mess with the local variables in
intel_find_initial_plane_obj(). Get rid of all aliasing pointers
and use standard naming/types.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210609085632.22026-4-ville.syrjala@linux.intel.comReviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Sort out the mess with the local variables in
intel_get_load_detect_pipe(). Get rid of all aliasing pointers
and use standard naming/types.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210609085632.22026-3-ville.syrjala@linux.intel.comReviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Use drm_crtc_mask() instead of hand rolling it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210609085632.22026-2-ville.syrjala@linux.intel.comReviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Since the llb allocation has a fixed size, let's grab it before
the potentially variable sized cfb. That should avoid some allocation
failure cases once we allow different compression ratios for FBC1.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210610183237.3920-10-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Write the cfb allocation loop as an actual loop instead of some
hard to read goto thing.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210610183237.3920-9-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Declutter find_compression_limit() a bit by extracting
intel_fbc_stolen_end().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210610183237.3920-8-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Exctract the limit->register value conversion into a common
helper.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210610183237.3920-7-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

The limit++ for the 16bpp case is nonsense since the
compression limit is always supposed to be power of two.
Replace it with <<=1.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210610183237.3920-6-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

No point in passing the mm node explicitly to find_compression_limit()
since it's always the same node for the cfb.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210610183237.3920-5-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Not much point in dynamically allocating the line length
buffer mm node that I can see. Just embed it directly like
we do the for the cfb node. One less failure point to worry
about.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210610183237.3920-4-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Extract the CFB (+LLB) programming into a separate function.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210610183237.3920-3-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Let's call the compression limit the limit.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210610183237.3920-2-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

adls is supposed to use special buf trans tables. Add what's
missing.

v2: Drop the RBR/HBR table since it's the same as for tgl
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210608073603.2408-18-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>