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

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

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

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

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

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

This new HBR2 table for TGL-U and TGL-Y is required to pass
DisplayPort compliance.

BSpec: 49291
Cc: Khaled Almahallawy <khaled.almahallawy@intel.com>
Reviewed-by: Khaled Almahallawy<khaled.almahallawy@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200807192629.64134-2-jose.souza@intel.comSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The command register is the PCODE MBOX low register not the high one as
described by the spec. This left the system with the TC-cold power state
being blocked all the time. Fix things by using the correct register.

Also to make sure we retry a request for at least 600usec, when the
PCODE MBOX command itself succeeded, but the TC-cold block command
failed, sleep for 1msec unconditionally after any fail.

The change was tested with JTAG register read of the HW/FW's actual
TC-cold state, which reported the expected states after this change.
Tested-by: NNivedita Swaminathan <nivedita.swaminathan@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200805150056.24248-1-imre.deak@intel.comSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The dependency between power wells is determined by the ordering of the
power well list: when enabling the power wells for a domain, this
happens walking the power well list forward, while disabling them
happens in the reverse direction. Accordingly a power well on the list
must follow any other power well it depends on.

Since the TC AUX power wells depend on TC-cold being blocked, move the
TC-cold off power well before all AUX power wells.

Fixes: 3c02934b ("drm/i915/tc/tgl: Implement TC cold sequences")
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200720232952.16228-1-imre.deak@intel.comSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The hardware team has dropped this workaround from the bspec; it is no
longer needed.

This reverts commit 111822b21be995a3a4a731066db3d820523c57f7.

Bspec: 49291
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200804044024.1931170-1-matthew.d.roper@intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

In the case of calling check_digital_port_conflicts() failed, a
negative error code -EINVAL should be returned.

Fixes: bf5da83e ("drm/i915: Move check_digital_port_conflicts() earier")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NTianjia Zhang <tianjia.zhang@linux.alibaba.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/20200802111535.5200-1-tianjia.zhang@linux.alibaba.comSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

A recent bspec update removed the LPDDR4 single channel entry from the
buddy register table, but added a new four-channel entry.

Workaround 1409767108 hasn't been updated with any guidance for four
channel configurations, so we leave that alternate table unchanged for
now.

Bspec 49218
Fixes: 3fa01d64 ("drm/i915/tgl: Program BW_BUDDY registers during display init")
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200612204734.3674650-1-matthew.d.roper@intel.comReviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

We use i915_active_fini() as a debug check on the i915_active state
before freeing. If we forget to call it, we may end up angering the
debugobjects contained within.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NThomas Hellström <thomas.hellstrom@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200731085015.32368-1-chris@chris-wilson.co.ukSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Avoid a GPF at

<1>[   20.177320] BUG: kernel NULL pointer dereference, address: 000000000000007c
<1>[   20.177322] #PF: supervisor read access in kernel mode
<1>[   20.177323] #PF: error_code(0x0000) - not-present page
<6>[   20.177324] PGD 0 P4D 0
<4>[   20.177327] Oops: 0000 [#1] PREEMPT SMP PTI
<4>[   20.177328] CPU: 1 PID: 944 Comm: debugfs_test Not tainted 5.8.0-rc7-CI-CI_DRM_8814+ #1
<4>[   20.177330] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018
<4>[   20.177372] RIP: 0010:i915_lpsp_capability_show+0x44/0xc0 [i915]
<4>[   20.177374] Code: 0f b6 81 ca 0d 00 00 3c 0b 74 77 76 19 3c 0c 75 44 83 7e 7c 01 7e 2f 48 c7 c6 d7 b9 47 a0 e8 43 df 06 e1 31 c0 c3 3c 09 72 2b <8b> 46 7c 85 c0 75 e6 8b 82 e4 00 00 00 89 c2 83 e2 fb 83 fa 0a 74
<4>[   20.177376] RSP: 0018:ffffc90000cebe38 EFLAGS: 00010246
<4>[   20.177377] RAX: 0000000000000009 RBX: ffff888267fe6a58 RCX: ffff888252d10000
<4>[   20.177378] RDX: ffff88824a9a4000 RSI: 0000000000000000 RDI: ffff888267fe6a30
<4>[   20.177379] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001
<4>[   20.177380] R10: 0000000000000001 R11: 0000000000000000 R12: ffffc90000cebf08
<4>[   20.177381] R13: 00000000ffffffff R14: 0000000000000001 R15: ffff888267fe6a30
<4>[   20.177383] FS:  00007f6f9c6b5e40(0000) GS:ffff888276480000(0000) knlGS:0000000000000000
<4>[   20.177384] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[   20.177385] CR2: 000000000000007c CR3: 0000000255f04006 CR4: 00000000003606e0
<4>[   20.177386] Call Trace:
<4>[   20.177390]  seq_read+0xcb/0x420

which is presumably from having no encoder attached at that time.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2175
Fixes: 8806211f ("drm/i915: Add i915_lpsp_capability debugfs")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200729130912.30093-1-chris@chris-wilson.co.ukSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Fbc is causing random underruns in CI execution on TGL platforms.
Disabling the same while the problem is being debugged and analyzed.

v2: Moved the check below the module param check (Ville)

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NUma Shankar <uma.shankar@intel.com>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716145857.6911-1-uma.shankar@intel.comSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Although the WA description targets the platforms it is a workaround
for the affected PCHs, that is why it is being checked.

v2: excluding DG1 fake PCH from WA

BSpec: 52890
BSpec: 53273
BSpec: 52888
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200727164729.28836-1-jose.souza@intel.comSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

After doing normal PHY-B initialization on Rocket Lake, we need to
manually copy some additional PHY-A register values into PHY-B
registers.

Note that the bspec's combo phy page doesn't specify that this
workaround is restricted to specific platform steppings (and doesn't
even do a very good job of specifying that RKL is the only platform this
is needed on), but the RKL workaround page lists this as relevant only
for A and B steppings, so I'm trusting that information for now.

v2:  Make rkl_combo_phy_b_init_wa() static

v3:
 - Minimize variables in WA function. (Jose)
 - Fix timeout duration (usec vs msec). (Jose)
 - Add verification of workaround. (Jose)
 - Fix stepping bounds in comment.

Bspec: 49291
Bspec: 53273
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716220551.2730644-6-matthew.d.roper@intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

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

v2:
 - Fix minor checkpatch warnings

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

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

Rocket Lake has a third DPLL (called 'DPLL4') that must be used to
enable a third display.  Unlike EHL's variant of DPLL4, the RKL variant
behaves the same as DPLL0/1.  And despite its name, the DPLL4 registers
are offset as if it were DPLL2.

v2:
 - Add new .update_ref_clks() hook.

v3:
 - Renumber TBT PLL to '3' and switch _MMIO_PLL3 to _MMIO_PLL (Lucas)

v4:
 - Don't drop _MMIO_PLL3; although it's now unused, we're going to need
   it very soon again for upcoming DG1 patches.  (Lucas)

v5:
 - Don't re-number TBT PLL and beyond, just use new RKL_DPLL_CFGCR
   macros to lookup the proper registers instead.  Although renumbering
   the PLLs might be something we want to consider down the road, it
   opens a big can of worms right now since a bunch of places in the
   code have an assumption that the PLL table has idx==id and no holes.
   Renumbering creates a hole for TGL, so we'd either need to allow
   holes in the table or break the idx==id invariant, both of which are
   somewhat invasive changes to the design.

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

RKL and TGL share some general gen12 workarounds, but each platform also
has its own platform-specific workarounds.

v2:
 - Add Wa_1604555607 for RKL.  This makes RKL's ctx WA list identical to
   TGL's, so we'll have both functions call the tgl_ function for now;
   this workaround isn't listed for DG1 so we don't want to add it to
   the general gen12_ function.

Cc: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716220551.2730644-3-matthew.d.roper@intel.comSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

RKL uses a slightly different bit layout for the DPCLKA_CFGCR0 register.

v2:
 - Fix inverted mask application when updating ICL_DPCLKA_CFGCR0
 - Checkpatch style fixes

Bspec: 50287
Cc: Aditya Swarup <aditya.swarup@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200716220551.2730644-2-matthew.d.roper@intel.comSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Hours Of Battery Life is a new GEN12+ power-saving feature that allows
supported motherboards to use a special voltage swing table for eDP
panels that uses less power.

So here if supported by HW, OEM will set it in VBT and i915 will try
to train link with HOBL vswing table if link training fails it fall
back to the original table.

intel_ddi_dp_preemph_max() was optimized to only check the HOBL flag
instead of do something like is done in intel_ddi_dp_voltage_max()
because it is only called after the first entry of the voltage swing
table was loaded so the HOBL flag is valid at that point.

v3:
- removed a few parameters of icl_ddi_combo_vswing_program() that
can be taken from encoder

v4:
- using the HOBL vswing table until training fails completely (Ville)

v5:
- not reducing lane or link rate when link training fails with HOBL
active
- duplicated the HOBL voltage swing entry to match DP spec requirement

v6:
- removed the optional VS 3 & pre-emp 0 from HOBL table
- changed from u8:1 to bool to store hobl_failed/active

BSpec: 49291
BSpec: 49399
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200715175637.33763-1-jose.souza@intel.comSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

The value we program to DDI_BUF_CTL changes at the following places:
- At enabling/disabling the output to configure the port width etc, and
  to enable/disable the DDI BUF function.
- At the beginning/end of link re-training to disable/re-enable the DDI
  BUF function.
- On HSW/BDW/SKL to change the voltage swing/pre-emph levels.

Except of the above the value we program to the DDI_BUF_CTL register
(intel_dp->DP) doesn't change, so no need to reprogram the register when
changing the link training patterns (which is programmed via the
DP_TP_CTL register on DDI platforms).

v2:
- Fix the commit message wrt. voltage/pre-emph level values in
  intel_dp->DP. (Ville)
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/20200714153141.10280-2-imre.deak@intel.comSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

According to BSpec this flag should not be changed while the DDI
function is enabled. On BDW+ the DP_TP_CTL register spec also states it
explicitly that the HW takes care of enabling/disabling the scrambling
for training patterns (and it must stay enabled for normal pixel
output). Assume that this HW automatic handling of scrambling is also
true for HSW.

BSpec: 8013, 7557, 50484
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/20200714153141.10280-1-imre.deak@intel.comSigned-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Explicitly check for i830 when assigning the .get_cdclk() vfunc,
and then deal with the case of not having assigned the vfunc
separately. Less confusing, and gets rid of the checkpatch complaint
about using {} on one branch but not the others.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200714152626.380-3-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Some spaces have snuck in where we want tabs. Fix it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200714152626.380-2-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

There's a pointless hole in struct intel_cdclk_vals, get rid of it.
Fortunately we already use named initializers so the order does not
matter.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200714152626.380-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Since g4x the CFB base only takes a 28bit offset into stolen.
Not sure if the CFB is allowed to start below that limit but
then extend beyond it. Let's assume not and just restrict the
allocation to the first 256MiB (in the unlikely case
we have more stolen than that).

v2: s/BIT/BIT_ULL/ (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200714201945.18959-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

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

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

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

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

This fixes the following KASAN splash on module reload:
[  145.136327] ==================================================================
[  145.136502] BUG: KASAN: use-after-free in intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136514] Read of size 8 at addr ffff888216641830 by task kworker/1:1/134

[  145.136535] CPU: 1 PID: 134 Comm: kworker/1:1 Tainted: G     U          T 5.5.0-rc7-valkyria+ #5783
[  145.136539] Hardware name: GIGABYTE GB-BKi3A-7100/MFLP3AP-00, BIOS F1 07/27/2016
[  145.136546] Workqueue: events drm_connector_free_work_fn
[  145.136551] Call Trace:
[  145.136560]  dump_stack+0xa1/0xe0
[  145.136571]  print_address_description.constprop.0+0x1e/0x210
[  145.136639]  ? intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136703]  ? intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136710]  __kasan_report.cold+0x1b/0x37
[  145.136790]  ? intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136863]  ? intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136870]  kasan_report+0x27/0x30
[  145.136881]  __asan_report_load8_noabort+0x1c/0x20
[  145.136946]  intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136954]  drm_connector_free_work_fn+0xd1/0x100
[  145.136967]  process_one_work+0x86e/0x1610
[  145.136987]  ? pwq_dec_nr_in_flight+0x2f0/0x2f0
[  145.137004]  ? move_linked_works+0x128/0x2c0
[  145.137021]  worker_thread+0x63e/0xc90
[  145.137048]  kthread+0x2f6/0x3f0
[  145.137054]  ? calculate_sigpending+0x81/0xa0
[  145.137059]  ? process_one_work+0x1610/0x1610
[  145.137064]  ? kthread_bind+0x40/0x40
[  145.137075]  ret_from_fork+0x24/0x30

[  145.137111] Allocated by task 0:
[  145.137119] (stack is not available)

[  145.137137] Freed by task 5053:
[  145.137147]  save_stack+0x28/0x90
[  145.137152]  __kasan_slab_free+0x136/0x180
[  145.137157]  kasan_slab_free+0x26/0x30
[  145.137161]  kfree+0xe6/0x350
[  145.137242]  intel_ddi_encoder_destroy+0x60/0x80 [i915]
[  145.137252]  drm_mode_config_cleanup+0x11d/0x8f0
[  145.137329]  intel_modeset_driver_remove+0x1f5/0x350 [i915]
[  145.137403]  i915_driver_remove+0xc4/0x130 [i915]
[  145.137482]  i915_pci_remove+0x3e/0x90 [i915]
[  145.137489]  pci_device_remove+0x108/0x2d0
[  145.137494]  device_release_driver_internal+0x1e6/0x4a0
[  145.137499]  driver_detach+0xcb/0x198
[  145.137503]  bus_remove_driver+0xde/0x204
[  145.137508]  driver_unregister+0x6d/0xa0
[  145.137513]  pci_unregister_driver+0x2e/0x230
[  145.137576]  i915_exit+0x1f/0x26 [i915]
[  145.137157]  kasan_slab_free+0x26/0x30
[  145.137161]  kfree+0xe6/0x350
[  145.137242]  intel_ddi_encoder_destroy+0x60/0x80 [i915]
[  145.137252]  drm_mode_config_cleanup+0x11d/0x8f0
[  145.137329]  intel_modeset_driver_remove+0x1f5/0x350 [i915]
[  145.137403]  i915_driver_remove+0xc4/0x130 [i915]
[  145.137482]  i915_pci_remove+0x3e/0x90 [i915]
[  145.137489]  pci_device_remove+0x108/0x2d0
[  145.137494]  device_release_driver_internal+0x1e6/0x4a0
[  145.137499]  driver_detach+0xcb/0x198
[  145.137503]  bus_remove_driver+0xde/0x204
[  145.137508]  driver_unregister+0x6d/0xa0
[  145.137513]  pci_unregister_driver+0x2e/0x230
[  145.137576]  i915_exit+0x1f/0x26 [i915]
[  145.137581]  __x64_sys_delete_module+0x35b/0x470
[  145.137586]  do_syscall_64+0x99/0x4e0
[  145.137591]  entry_SYSCALL_64_after_hwframe+0x49/0xbe

[  145.137606] The buggy address belongs to the object at ffff888216640000
                which belongs to the cache kmalloc-8k of size 8192
[  145.137618] The buggy address is located 6192 bytes inside of
                8192-byte region [ffff888216640000, ffff888216642000)
[  145.137630] The buggy address belongs to the page:
[  145.137640] page:ffffea0008599000 refcount:1 mapcount:0 mapping:ffff888107c02a80 index:0xffff888216644000 compound_mapcount: 0
[  145.137647] raw: 0200000000010200 0000000000000000 0000000100000001 ffff888107c02a80
[  145.137652] raw: ffff888216644000 0000000080020001 00000001ffffffff 0000000000000000
[  145.137656] page dumped because: kasan: bad access detected

[  145.137668] Memory state around the buggy address:
[  145.137678]  ffff888216641700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  145.137687]  ffff888216641780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  145.137697] >ffff888216641800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  145.137706]                                      ^
[  145.137715]  ffff888216641880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  145.137724]  ffff888216641900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  145.137733] ==================================================================
[  145.137742] Disabling lock debugging due to kernel taint

Changes since v1:
- Add fixes tags.
- Use early unregister.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 9c229127 ("drm/i915: hdmi: add CEC notifier to intel_hdmi")
Cc: <stable@vger.kernel.org> # v4.19+
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200212135445.1469133-1-maarten.lankhorst@linux.intel.com
(cherry picked from commit a581483b)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

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

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

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

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

This fixes the following KASAN splash on module reload:
[  145.136327] ==================================================================
[  145.136502] BUG: KASAN: use-after-free in intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136514] Read of size 8 at addr ffff888216641830 by task kworker/1:1/134

[  145.136535] CPU: 1 PID: 134 Comm: kworker/1:1 Tainted: G     U          T 5.5.0-rc7-valkyria+ #5783
[  145.136539] Hardware name: GIGABYTE GB-BKi3A-7100/MFLP3AP-00, BIOS F1 07/27/2016
[  145.136546] Workqueue: events drm_connector_free_work_fn
[  145.136551] Call Trace:
[  145.136560]  dump_stack+0xa1/0xe0
[  145.136571]  print_address_description.constprop.0+0x1e/0x210
[  145.136639]  ? intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136703]  ? intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136710]  __kasan_report.cold+0x1b/0x37
[  145.136790]  ? intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136863]  ? intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136870]  kasan_report+0x27/0x30
[  145.136881]  __asan_report_load8_noabort+0x1c/0x20
[  145.136946]  intel_hdmi_destroy+0x74/0x80 [i915]
[  145.136954]  drm_connector_free_work_fn+0xd1/0x100
[  145.136967]  process_one_work+0x86e/0x1610
[  145.136987]  ? pwq_dec_nr_in_flight+0x2f0/0x2f0
[  145.137004]  ? move_linked_works+0x128/0x2c0
[  145.137021]  worker_thread+0x63e/0xc90
[  145.137048]  kthread+0x2f6/0x3f0
[  145.137054]  ? calculate_sigpending+0x81/0xa0
[  145.137059]  ? process_one_work+0x1610/0x1610
[  145.137064]  ? kthread_bind+0x40/0x40
[  145.137075]  ret_from_fork+0x24/0x30

[  145.137111] Allocated by task 0:
[  145.137119] (stack is not available)

[  145.137137] Freed by task 5053:
[  145.137147]  save_stack+0x28/0x90
[  145.137152]  __kasan_slab_free+0x136/0x180
[  145.137157]  kasan_slab_free+0x26/0x30
[  145.137161]  kfree+0xe6/0x350
[  145.137242]  intel_ddi_encoder_destroy+0x60/0x80 [i915]
[  145.137252]  drm_mode_config_cleanup+0x11d/0x8f0
[  145.137329]  intel_modeset_driver_remove+0x1f5/0x350 [i915]
[  145.137403]  i915_driver_remove+0xc4/0x130 [i915]
[  145.137482]  i915_pci_remove+0x3e/0x90 [i915]
[  145.137489]  pci_device_remove+0x108/0x2d0
[  145.137494]  device_release_driver_internal+0x1e6/0x4a0
[  145.137499]  driver_detach+0xcb/0x198
[  145.137503]  bus_remove_driver+0xde/0x204
[  145.137508]  driver_unregister+0x6d/0xa0
[  145.137513]  pci_unregister_driver+0x2e/0x230
[  145.137576]  i915_exit+0x1f/0x26 [i915]
[  145.137157]  kasan_slab_free+0x26/0x30
[  145.137161]  kfree+0xe6/0x350
[  145.137242]  intel_ddi_encoder_destroy+0x60/0x80 [i915]
[  145.137252]  drm_mode_config_cleanup+0x11d/0x8f0
[  145.137329]  intel_modeset_driver_remove+0x1f5/0x350 [i915]
[  145.137403]  i915_driver_remove+0xc4/0x130 [i915]
[  145.137482]  i915_pci_remove+0x3e/0x90 [i915]
[  145.137489]  pci_device_remove+0x108/0x2d0
[  145.137494]  device_release_driver_internal+0x1e6/0x4a0
[  145.137499]  driver_detach+0xcb/0x198
[  145.137503]  bus_remove_driver+0xde/0x204
[  145.137508]  driver_unregister+0x6d/0xa0
[  145.137513]  pci_unregister_driver+0x2e/0x230
[  145.137576]  i915_exit+0x1f/0x26 [i915]
[  145.137581]  __x64_sys_delete_module+0x35b/0x470
[  145.137586]  do_syscall_64+0x99/0x4e0
[  145.137591]  entry_SYSCALL_64_after_hwframe+0x49/0xbe

[  145.137606] The buggy address belongs to the object at ffff888216640000
                which belongs to the cache kmalloc-8k of size 8192
[  145.137618] The buggy address is located 6192 bytes inside of
                8192-byte region [ffff888216640000, ffff888216642000)
[  145.137630] The buggy address belongs to the page:
[  145.137640] page:ffffea0008599000 refcount:1 mapcount:0 mapping:ffff888107c02a80 index:0xffff888216644000 compound_mapcount: 0
[  145.137647] raw: 0200000000010200 0000000000000000 0000000100000001 ffff888107c02a80
[  145.137652] raw: ffff888216644000 0000000080020001 00000001ffffffff 0000000000000000
[  145.137656] page dumped because: kasan: bad access detected

[  145.137668] Memory state around the buggy address:
[  145.137678]  ffff888216641700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  145.137687]  ffff888216641780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  145.137697] >ffff888216641800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  145.137706]                                      ^
[  145.137715]  ffff888216641880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  145.137724]  ffff888216641900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  145.137733] ==================================================================
[  145.137742] Disabling lock debugging due to kernel taint

Changes since v1:
- Add fixes tags.
- Use early unregister.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 9c229127 ("drm/i915: hdmi: add CEC notifier to intel_hdmi")
Cc: <stable@vger.kernel.org> # v4.19+
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200212135445.1469133-1-maarten.lankhorst@linux.intel.com

According to the DP spec a DPTX must support vswing/pre-emphasis
up to and including level 2. Level 3 is optional (actually DP 1.4a
seems to make even level 3 mandatory for HBR2/3, while leaving it
optional for RBR/HBR1).

WARN if out encoders' .voltage_max()/.preemph_max() return
an illegal value.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.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/20200709145845.18118-1-ville.syrjala@linux.intel.com

So far, max dot clock rate for MST mode rely on physcial
bandwidth limitation. It would caused compatibility issue
if source display resolution exceed MST hub output ability.

For example, source DUT had DP 1.2 output capability.
And MST docking just support HDMI 1.4 spec. When a HDMI 2.0
monitor connected. Source would retrieve EDID from external
and get max resolution 4k@60fps. DP 1.2 can support 4K@60fps
because it did not surpass DP physical bandwidth limitation.
Do modeset to 4k@60fps, source output display data but MST
docking can't output HDMI properly due to this resolution
already over HDMI 1.4 spec.

Refer to commit <fcf46380> ("drm/dp_mst: Use full_pbn
instead of available_pbn for bandwidth checks").
Source driver should refer to full_pbn to evaluate sink
output capability. And filter out the resolution surpass
sink output limitation.

Changes since v1:
* Using mgr->base.lock to protect full_pbn.
Changes since v2:
* Add ctx lock.
Changes since v3:
* s/intel_dp_mst_mode_clock_exceed_pbn_bandwidth/
  intel_dp_mst_mode_clock_exceeds_pbn_bw/
* Use the new drm_connector_helper_funcs.mode_valid_ctx to properly pipe
  down the drm_modeset_acquire_ctx that the probe helpers are using, so
  we can safely grab &mgr->base.lock without deadlocking
Changes since v4:
* Move drm_dp_calc_pbn_mode(mode->clock, bpp, false) > port->full_pbn
  check
* Fix the bpp we use in drm_dp_calc_pbn_mode()
* Drop leftover (!mgr) check
* Don't check for if full_pbn is unset. To be clear - it _can_ be unset,
  but if it is then it's certainly a bug in DRM or a non-compliant sink
  as full_pbn should always be populated by the time we call
  ->mode_valid_ctx.
  We should workaround non-compliant sinks with full_pbn=0, but that
  should happen in the DP MST helpers so we can estimate the full_pbn
  value as best we can.
Tested-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Co-developed-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NLee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: NLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200713170746.254388-3-lyude@redhat.com

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

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

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

This information can be get directly from intel_encoder so no need
of those parameters.
Signed-off-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/20200708205512.21625-2-jose.souza@intel.com

intel_encoder will be needed inside of vswing functions in a future
patch, so here doing this change in all vswing functions since HSW.
Signed-off-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/20200708205512.21625-1-jose.souza@intel.com

Some platforms apply the FBC w/as in .init_clock_gating(), some
in fbc_activate(). Move them all to .init_clock_gating() for
consistentce. Also safer since we don't have to worry about the
RMWs clashing with any other runtime use of the same registers.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200708131223.9519-1-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

.get_modes() is supposed to return the number of modes added to the
probed_modes list (not that anyone actually checks for anything
except zero vs. not zero). Let's do that.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-9-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

.get_modes() is supposed to return the number of modes added to the
probed_modes list (not that anyone actually checks for anything
except zero vs. not zero). Let's do that. Also switch over to using
intel_connector_update_modes() instead of hand rolling it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-8-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

With SDVO the pipe config pixel_multiplier only concerns itself with the
data on the SDVO bus. Any HDMI specific pixel repeat must be handled by
the SDVO device itself. To do that simply configure the SDVO pixel
replication factor appropriately. We already set up the infoframe PRB
values correctly via the infoframe helpers.

There is no cap we can check for this. The spec says that 1X,2X,4X are
mandatory, anything else is optional. 1X and 2X are all we need so
we should be able to assume they work.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-7-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

The code assumes that DRM_MODE_FLAG_DBLCLK means that we enable the
pixel repeat feature. That only works with HDMI since it requires
AVI infoframe to signal the information to the sink. Hence even if
the mode dotclock would be valid we cannot currently assume that
we can just ignore the DBLCLK flag. Reject it for DVI sinks.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-6-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

The SDVO/HDMI port register limited color range bit can only be used
with TMDS encoding and not SDVO encoding, ie. to be used only when
using the port as a HDMI port as opposed to a SDVO port. The SDVO
spec does have a note that some GMCHs might allow that, but gen4
bspec vehemently disagrees. I suppose on ILK+ it might work since
the color range handling is on the CPU side rather than on the PCH
side, so there is no clear linkage between the TMDS vs. SDVO
encoding and color range. Alas, I have no hardware to test that
theory.

To implement limited color range support for SDVO->HDMI we need to
ask the SDVO device to do the range compression. Do so, but first
check if the device even supports the colorimetry selection.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-5-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Fix up the SDVO colorimetry bits to match the spec.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-4-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Based on the platform, Bspec expects us to wait or poll with
timeout for DDI BUF IDLE bit to be set to 0 (non idle) or get active
after enabling DDI_BUF_CTL.

v2:
* Based on platform, fixed delay or poll (Ville)
* Use a helper to do this (Imre, Ville)
v3:
* Add a new function _active for DDI BUF CTL to be non idle (Ville)
v4:
* Use the timeout for GLK (Ville)
v5:
* Add bspec quote, change timeout to 500us (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200701221052.8946-2-manasi.d.navare@intel.com