This was sort of annoying me:

random:~$ dmesg | tail -1
[523884.039227] [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS.
random:~$ dmesg | grep -c "Reducing the compressed"
47

This patch makes it DRM_INFO_ONCE() just like the similar message
farther down in that function is pr_info_once().

Cc: stable@vger.kernel.org
Signed-off-by: NPeter Jones <pjones@redhat.com>
Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1745
Link: https://patchwork.freedesktop.org/patch/msgid/20180706190424.29194-1-pjones@redhat.com
[vsyrjala: Rebase due to per-device logging]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 6b7fc6a3)
[Rodrigo: port back to DRM_INFO_ONCE]
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

If the FBC is still writing into stolen, it will overwrite any future
users of that stolen region. Check before release, just to ease any
concerns -- we can remove it again later if it is barking up the wrong
tree.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/1635Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200503180034.20010-1-chris@chris-wilson.co.uk

Display WA #1105 says that FBC requires PLANE_STRIDE to be a multiple
of 512 bytes on gen9 and glk.

This is definitely true for glk as certain tests (such as
igt/kms_big_fb/linear-16bpp-rotate-0) are now failing when the
display resolution results in a plane stride which is not a
multiple of 512 bytes.

Curiously I was not able to reproduce this on a KBL. First I
suspected that our use of the FBC override stride explain this,
but after trying to use the override stride on glk the test
still failed. I did try both the old CHICKEN_MISC_4 way and
the new FBC_STRIDE way, neither had any effect on the result.

Anyways, we need this at least on glk. But let's trust the spec
and apply the w/a for all gen9 as well, despite being unable to
reproduce the problem.

v2: s/FBC_CHICKEN/FBC_STRIDE/ in commit msg

Cc: José Roberto de Souza <jose.souza@intel.com>
Fixes: 691f7ba5 ("drm/i915/display/fbc: Make fences a nice-to-have for GEN9+")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429101034.8208-2-ville.syrjala@linux.intel.comReviewed-by: NMatt Roper <matthew.d.roper@intel.com>

This was sort of annoying me:

random:~$ dmesg | tail -1
[523884.039227] [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS.
random:~$ dmesg | grep -c "Reducing the compressed"
47

This patch makes it DRM_INFO_ONCE() just like the similar message
farther down in that function is pr_info_once().

Cc: stable@vger.kernel.org
Signed-off-by: NPeter Jones <pjones@redhat.com>
Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1745
Link: https://patchwork.freedesktop.org/patch/msgid/20180706190424.29194-1-pjones@redhat.com
[vsyrjala: Rebase due to per-device logging]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

dGFX has local memory so it does not have aperture or support
CPU fences but even for iGFX it have a small number of fences.

As replacement for fences to track frontbuffer modifications by CPU
we have a software tracking that is already in used by FBC and PSR.
PSR don't support fences so it shows that this tracking is reliable.

So lets make fences a nice-to-have to activate FBC for GEN9+, this
will allow us to enable FBC for dGFXs and iGFXs even when there is no
available fence.

We do not set fences to rotated planes but FBC only have restrictions
against 16bpp, so adding it here.

Also adding a new check for the tiling format, fences are only set
to X and Y tiled planes but again FBC don't have any restrictions
against tiling so adding linear as supported as well, other formats
should be added after tested but IGT only supports drawing in thse
3 formats.

intel_fbc_hw_tracking_covers_screen() maybe can also have the same
treatment as fences but BSpec is not clear if the size limitation is
for hardware tracking or general use of FBC and I don't have a 5K
display to test it, so keeping as is for safety.

v2:
- Added tiling and pixel format rotation checks
- Changed the GEN version not requiring fences to 11 from 9, DDX
needs some changes but it don't have support for GEN11+

v3:
- Changed back to GEN9+
- Moved GEN test to inside of tiling_is_valid()

v4:
- moved rotation check to its own functions

v5:
- renamed rotations_is_valid to rotation_is_valid
- moved pre-g4x rotation check to rotation_is_valid()

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200319211535.114625-1-jose.souza@intel.com

This replaces the uses of the printk based drm logging macros with the
struct drm_device based logging macros in i915/display/intel_fbc.c.
This transformation was done using the following coccinelle semantic
patch that matches based on the existence of a drm_i915_private device
pointer:
@@
identifier fn, T;
@@

fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

@@
identifier fn, T;
@@

fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(&T->drm,
...)
|
-DRM_ERROR(
+drm_err(&T->drm,
...)
|
-DRM_WARN(
+drm_warn(&T->drm,
...)
|
-DRM_DEBUG(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(&T->drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(&T->drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(&T->drm,
...)
)
...+>
}

New checkpatch warnings were addressed manually.

v2 by Jani:
- also convert pr_info_once to drm based logging
Signed-off-by: NWambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NWambui Karuga <wambui.karugax@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/32a92f1d4e4d01131605b17bec831517e39c5902.1583766715.git.jani.nikula@intel.com

Platforms without fences don't have FBC host tracking and those
registers are marked as reserved in those platforms.

v2: checking num_fences to write to FBC fence registers (Ville)

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306185833.53984-2-jose.souza@intel.com

Most of the kms_frontbuffer_tracking tests disables the feature being
tested, draw, get the CRC then enable the feature, draw again, get the
CRC and check if it matches.
Some times it is able to do that with a fastset, so
intel_pre_plane_update() is executed but intel_fbc_can_flip_nuke() was
not checking if FBC is now enabled in this CRTC leaving FBC active and
causing the warning bellow in __intel_fbc_disable()

[IGT] kms_frontbuffer_tracking: starting subtest fbc-1p-pri-indfb-multidraw
Setting dangerous option enable_fbc - tainting kernel
i915 0000:00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR debug to f
i915 0000:00:02.0: [drm:intel_psr_debug_set [i915]] Invalid debug mask f
i915 0000:00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR debug to 1
i915 0000:00:02.0: [drm:intel_atomic_check [i915]] [CONNECTOR:215:eDP-1] Limiting display bpp to 24 instead of EDID bpp 24, requested bpp 36, max platform bpp 36
[drm:intel_dp_compute_config [i915]] DP link computation with max lane count 2 max rate 270000 max bpp 24 pixel clock 138120KHz
[drm:intel_dp_compute_config [i915]] Force DSC en = 0
[drm:intel_dp_compute_config [i915]] DP lane count 2 clock 270000 bpp 24
[drm:intel_dp_compute_config [i915]] DP link rate required 414360 available 540000
i915 0000:00:02.0: [drm:intel_atomic_check [i915]] hw max bpp: 24, pipe bpp: 24, dithering: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] [CRTC:91:pipe A] enable: yes [fastset]
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] active: yes, output_types: EDP (0x100), output format: RGB
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] cpu_transcoder: EDP, pipe bpp: 24, dithering: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] dp m_n: lanes: 2; gmch_m: 6436858, gmch_n: 8388608, link_m: 268202, link_n: 524288, tu: 64
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] audio: 0, infoframes: 0, infoframes enabled: 0x0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] requested mode:
[drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] adjusted mode:
[drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa
[drm:intel_dump_pipe_config [i915]] crtc timings: 138120 1920 1968 2018 2052 1080 1084 1086 1122, type: 0x48 flags: 0xa
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] port clock: 270000, pipe src size: 1920x1080, pixel rate 138120
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] linetime: 119, ips linetime: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] num_scalers: 2, scaler_users: 0x0, scaler_id: -1
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] pch pfit: pos: 0x00000000, size: 0x00000000, disabled, force thru: no
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] ips: 0, double wide: 0
[drm:icl_dump_hw_state [i915]] dpll_hw_state: cfgcr0: 0x1c001a5, cfgcr1: 0x8b, mg_refclkin_ctl: 0x0, hg_clktop2_coreclkctl1: 0x0, mg_clktop2_hsclkctl: 0x0, mg_pll_div0: 0x0, mg_pll_div2: 0x0, mg_pll_lf: 0x0, mg_pll_frac_lock: 0x0, mg_pll_ssc: 0x0, mg_pll_bias: 0x0, mg_pll_tdc_coldst_bias: 0x0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] csc_mode: 0x0 gamma_mode: 0x0 gamma_enable: 0 csc_enable: 0
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] MST master transcoder: <invalid>
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] [PLANE:31:plane 1A] fb: [FB:262] 1920x1080 format = XR24 little-endian (0x34325258), visible: yes
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] 	rotation: 0x1, scaler: -1
i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] 	src: 1920.000000x1080.000000+0.000000+0.000000 dst: 1920x1080+0+0
i915 0000:00:02.0: [drm:intel_psr_disable_locked [i915]] Disabling PSR1
i915 0000:00:02.0: [drm:intel_ddi_update_pipe [i915]] Panel doesn't support DRRS
------------[ cut here ]------------
i915 0000:00:02.0: drm_WARN_ON(fbc->active)
WARNING: CPU: 4 PID: 1175 at drivers/gpu/drm/i915/display/intel_fbc.c:973 __intel_fbc_disable+0xa5/0x130 [i915]
Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul snd_hda_intel crc32_pclmul snd_intel_dspcfg snd_hda_codec ghash_clmulni_intel snd_hwdep snd_hda_core cdc_ether e1000e usbnet mii snd_pcm ptp mei_me pps_core mei thunderbolt intel_lpss_pci prime_numbers
CPU: 4 PID: 1175 Comm: kms_frontbuffer Tainted: G     U            5.5.0-CI-Trybot_5651+ #1
Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019
RIP: 0010:__intel_fbc_disable+0xa5/0x130 [i915]
Code: 8b 67 50 4d 85 e4 0f 84 8f 00 00 00 e8 44 33 30 e1 48 c7 c1 72 f6 4c a0 4c 89 e2 48 89 c6 48 c7 c7 42 f6 4c a0 e8 0b 9d ce e0 <0f> 0b eb 90 48 8b 7b 18 4c 8b 67 50 4d 85 e4 74 6d e8 15 33 30 e1
RSP: 0018:ffffc90000613b68 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff8884799d0000 RCX: 0000000000000006
RDX: 0000000000001905 RSI: ffff888495dac970 RDI: ffffffff823731a1
RBP: ffff88847c05d000 R08: ffff888495dac970 R09: 0000000000000000
R10: ffffc90000613b88 R11: 0000000000000000 R12: ffff88849bba7e40
R13: ffff8884799d0000 R14: ffff888498564000 R15: 0000000000000000
FS:  00007f8157f08300(0000) GS:ffff8884a0000000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffdbfea2eb8 CR3: 000000049d1cc001 CR4: 0000000000760ee0
PKRU: 55555554
Call Trace:
 intel_fbc_disable+0x4a/0x50 [i915]
 intel_update_crtc+0x12c/0x1d0 [i915]
 skl_commit_modeset_enables+0x14d/0x600 [i915]
 intel_atomic_commit_tail+0x30d/0x1480 [i915]
 ? queue_work_on+0x31/0x70
 ? intel_atomic_commit_ready+0x3f/0x48 [i915]
 ? __i915_sw_fence_complete+0x1a0/0x250 [i915]
 intel_atomic_commit+0x312/0x390 [i915]
 intel_psr_fastset_force+0x119/0x150 [i915]
 i915_edp_psr_debug_set+0x53/0x70 [i915]
 simple_attr_write+0xb0/0xd0
 full_proxy_write+0x51/0x80
 vfs_write+0xb9/0x1d0
 ksys_write+0x9f/0xe0
 do_syscall_64+0x4f/0x220
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f8157240281
Code: c3 0f 1f 84 00 00 00 00 00 48 8b 05 59 8d 20 00 c3 0f 1f 84 00 00 00 00 00 8b 05 8a d1 20 00 85 c0 75 16 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 41 54 55 49 89 d4 53
RSP: 002b:00007ffdbfea59d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f8157240281
RDX: 0000000000000003 RSI: 00007f8157901152 RDI: 0000000000000008
RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f8157901152
R13: 0000000000000008 R14: 00005589d298dce0 R15: 0000000000000000
irq event stamp: 55208
hardirqs last  enabled at (55207): [<ffffffff8112f3fc>] vprintk_emit+0xcc/0x330
hardirqs last disabled at (55208): [<ffffffff81001ca0>] trace_hardirqs_off_thunk+0x1a/0x1c
softirqs last  enabled at (54926): [<ffffffff81e00385>] __do_softirq+0x385/0x47f
softirqs last disabled at (54915): [<ffffffff810ba15a>] irq_exit+0xba/0xc0
---[ end trace afa50c52e5a512bb ]---
[drm:__intel_fbc_disable [i915]] Disabling FBC on pipe A
i915 0000:00:02.0: [drm:verify_connector_state [i915]] [CONNECTOR:215:eDP-1]
i915 0000:00:02.0: [drm:intel_atomic_commit_tail [i915]] [CRTC:91:pipe A]
[drm:intel_ddi_get_config [i915]] [ENCODER:214:DDI A] Fec status: 0
i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.150 [i915]] DPLL 0

v2:
using intel_fbc_can_enable() instead of crtc_state->enable_fbc (Ville)

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

Check the edge case where batch_start_offset sits exactly on the batch
size.

v2: add new range_overflows variant to capture the special case where
the size is permitted to be zero, like with batch_len.

v3: other way around. the common case is the exclusive one which should
just be >=, with that we then just need to convert the three odd ball
cases that don't apply to use the new inclusive _end version.

Testcase: igt/gem_exec_params/invalid-batch-start-offset
Fixes: 0b537272 ("drm/i915/cmdparser: Use cached vmappings")
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306094735.258285-1-matthew.auld@intel.com

Add intel_vgpu_register() abstraction, rename i915_detect_vgpu() to
intel_vgpu_detect() to match other function naming, un-inline
intel_vgpu_active(), intel_vgpu_has_full_ppgtt() and
intel_vgpu_has_huge_gtt() to reduce header interdependencies.

The i915_vgpu.[ch] filename and intel_vgpu_ prefix discrepancy remains.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227144408.24345-1-jani.nikula@intel.com

drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is readily
available.

The conversion was done automatically with below coccinelle semantic
patch.

@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128181603.27767-11-pankaj.laxminarayan.bharadiya@intel.com

Avoid releasing the same stolen nodes causing a use-after-free and/or
explosions as the self-checks fail, as __intel_fbc_cleanup_cfb() may be
called multiple times during module unload.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200130135136.1878646-1-chris@chris-wilson.co.uk

The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().

Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().

No functional changes.

Generated using the following semantic patch:

@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)

@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)

@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)

@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)

@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf67d57a7d760fb557325690f634799751d36f12.1579871655.git.jani.nikula@intel.com

drivers/gpu/drm/i915/display/intel_atomic.c:185: warning: Function parameter or member 'state' not described in 'intel_connector_needs_modeset'
drivers/gpu/drm/i915/display/intel_atomic.c:185: warning: Function parameter or member 'connector' not described in 'intel_connector_needs_modeset'

drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Function parameter or member 'state' not described in 'intel_fbc_enable'
drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Excess function parameter 'crtc_state' description in 'intel_fbc_enable'
drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Excess function parameter 'plane_state' description in 'intel_fbc_enable'
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200126195654.2172937-1-chris@chris-wilson.co.uk

Add tracepoints which let us know when fbc activates/deactivates/nukes.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191213133453.22152-5-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

fbc_supported() is just a pointless wrapper for HAS_FBC(). Get
rid of it. In places where we're operating on a specific plane
we can replace this with a plane->has_fbc check to avoid
doing anything for crtcs that don't even support fbc.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191213133453.22152-4-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Instead of dealing with the presence/absence of the primary
plane in the higher level pre/post plane update code let's
move all that into the fbc code itself. Now the higher level
code doesn't have to think about FBC details anymore.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191213133453.22152-3-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

icl and tgl are still affected by the modulo 4 PLANE_OFFSET.y
underrun issue. Reject such configurations on all gen9+ platforms.

Can be reproduced easily with the following sequence of
hardware poking:
while {
  write FBC_CTL.enable=1
  wait for vblank

  write PLANE_OFFSET .x=0 .y=32
  write PLANE_SURF
  wait for vblank

  # if PLANE_OFFSET.y is multiple of 4 the underrun won't happen
  write PLANE_OFFSET .x=0 .y=31
  write PLANE_SURF
  wait for vblank

  # extra vblank wait is required here presumably
  # to get FBC into the proper state
  wait for vblank

  write FBC_CTL.enable=0
  # underrun happens some time after FBC disable
  wait for vblank
}

Both 8888 and 565 pixel formats and all tilinga formats
seem affected. Reproduced on KBL/GLK/ICL/TGL. BDW confirmed
not affected.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/792Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191213133453.22152-1-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

We're missing a workaround in the fbc code for all glk+ platforms
which can cause corruption around the top of the screen. So
enabling fbc by default is a bad idea. I'm not keen to backport
the w/a so let's start by disabling fbc by default on all glk+.
We'll lift the restriction once the w/a is in place.

Cc: stable@vger.kernel.org
Cc: Daniel Drake <drake@endlessm.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-2-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
(cherry picked from commit cd8c021b)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

The code assumes we can omit the cfb allocation once fbc
has been enabled once. That's nonsense. Let's try to
reallocate it if we need to.

The code is still a mess, but maybe this is enough to get
fbc going in some cases where it initially underallocates
the cfb and there's no full modeset to fix it up.

Cc: Daniel Drake <drake@endlessm.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-15-ville.syrjala@linux.intel.comTested-by: NDaniel Drake <drake@endlessm.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Now that we have the glk+ w/a for back to back fbc disable + plane
update in place we can once more enable fbc on glk+ by default.

Cc: Daniel Drake <drake@endlessm.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-14-ville.syrjala@linux.intel.comTested-by: NDaniel Drake <drake@endlessm.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

On glk+ the hardware gets confused if we disable FBC while
it's recompressing and we perform a plane update during the
same frame. The result is that top of the screen gets corrupted.

We can avoid that by giving the hardware enough time to finish
the FBC disable before we touch the plane registers. Ie. we need
an extra vblank wait after FBC disable.

v2: Don't do the vblank wait if we never activated FBC in hw
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128150338.12490-1-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

The hardware automagically nukes the cfb on flip. We can use
that whenever the plane/crtc configuration doesn't change too
much. Let's hook that up.

We'll need this for glk+ since we need to introduce an extra
vblank wait after FBC disable. As we're currently disabling
FBC around all plane updates we'd slow them down by an extra
frame. Not a great user experience when your fps is always
capped at vrefres/2. With flip nuke we don't need the extra
vblank wait.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-12-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

fbc.enabled == (fbc.crtc != NULL), so let's just nuke fbc.enabled.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-11-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Replace the 'gen9 && !glk' with the slightly more obvious
'gen9_bc || bxt'.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-10-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

i965gm no longer needs the fence for scanout so we should be
do what we do for ctg+ and only configure a fence for FBC
when we have one.

In theory this should do nothing atm on account of
intel_fbc_can_activate() requiring the fence, but since
we do this for g4x+ let's do it for i965gm as well. We
may want to relax the requirements at some point and allow
FBC without a fence.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-9-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Rather than playing around with vma+flags let's just grab
the fence id from within and stash that directly in the fbc
cache/params.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-8-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Currently the code (ab)uses cache->vma to indicate the plane
visibility. I want to nuke that so let's add a dedicated boolean
for this.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-7-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Precompute the override cfb stride value so that we can check
it when determining if flip nuke can be used or not.

The hardware has 13 bits for this, so we can shrink the storage
to u16 while at it.

v2: Don't explode when crtc_state->enable_fbc lies to us
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-6-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

We don't want to use the FBC hardware render tracking so let's not
enable it. To use the hw tracking properly we'd anyway need to
integrate this into the command submissing path as the register is
context saved, and if rendering happens via the ppgtt we'd have
to configure it with the ppgtt address instead of the ggtt address.
Easier to use software tracking instead.

Note that on pre-ilk we can't actually disable render tracking.
However we can't rely on it because it requires that DSPSURF to
match the render target address, and since we play tricks
with DSPSURF that may not be the case. Hence we shall rely on
software render tracking on all platforms.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-5-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Not sure where the single pipe only restriction came for fbc1.
Nothing I can see that would prevent this.

v2: Nuke no_fbc_on_multiple_pipes() too
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-3-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

We're missing a workaround in the fbc code for all glk+ platforms
which can cause corruption around the top of the screen. So
enabling fbc by default is a bad idea. I'm not keen to backport
the w/a so let's start by disabling fbc by default on all glk+.
We'll lift the restriction once the w/a is in place.

Cc: stable@vger.kernel.org
Cc: Daniel Drake <drake@endlessm.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jian-Hong Pan <jian-hong@endlessm.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127201222.16669-2-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Change the calling convention to just pass the state+crtc and
switch to intel_ types throughout.

We'll also do a quick s/if (old_primary_state)/if (new_primary_state)/
so that we'll be able to eliminate old_primary_state later. This
is fine since we always have either both old and new state or neither.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-5-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Split up plane_state->base to uapi. This is done using the following patch,
ran after the previous commit that splits out any hw references:

@@
struct intel_plane_state *T;
identifier x;
@@
-T->base.x
+T->uapi.x

@@
struct intel_plane_state *T;
@@
-T->base
+T->uapi
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-10-maarten.lankhorst@linux.intel.com

Split up plane_state->base to hw. This is done using the following patch:

@@
struct intel_plane_state *T;
identifier x =~ "^(crtc|fb|alpha|pixel_blend_mode|rotation|color_encoding|color_range)$";
@@
-T->base.x
+T->hw.x
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-9-maarten.lankhorst@linux.intel.com

Split up crtc_state->base to hw where appropriate. This is done using the following patch:

@@
struct intel_crtc_state *T;
identifier x =~ "^(active|enable|degamma_lut|gamma_lut|ctm|mode|adjusted_mode)$";
@@
-T->base.x
+T->hw.x

@@
struct drm_crtc_state *T;
identifier x =~ "^(active|enable|degamma_lut|gamma_lut|ctm|mode|adjusted_mode)$";
@@
-to_intel_crtc_state(T)->base.x
+to_intel_crtc_state(T)->hw.x
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-4-maarten.lankhorst@linux.intel.com

The FBC requires a couple of contiguous buffers, which we allocate from
stolen memory. If stolen memory is unavailable, we cannot allocate those
buffers and so cannot support FBC. Mark it so.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190911175926.31365-1-chris@chris-wilson.co.uk

WA 1409120013 is also valid for TGL, so lets check for ">= 11".

BSpec: 52890

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Clinton Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190904230241.20638-1-jose.souza@intel.com

To reduce the number of explicit dev_priv->uncore calls in the display
code ahead of the introduction of dev_priv->de_uncore, this patch
introduces a wrapper for one of the main usages of it, the register
waits. When we transition to the new uncore, we can just update the
wrapper to point to the appropriate structure.

Since the vast majority of waits are on a set or clear of a bit or mask,
add set & clear flavours of the wrapper to simplify the code.
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190816012343.36433-7-daniele.ceraolospurio@intel.com

Everything about the file is about display, and mostly about types
related to display. Move under display/ as intel_display_types.h to
reflect the facts.

There's still plenty to clean up, but start off with moving the file
where it logically belongs and naming according to contents.

v2: fix the include guard name in the renamed file
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190806113933.11799-1-jani.nikula@intel.com