As per the Bspec, port mapping is fixed for mipi dsi.

v2: Reuse the existing function (Jani)
Signed-off-by: NVandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191119072004.4093-1-vandita.kulkarni@intel.com

The bspec was recently updated with new cdclk -> voltage level tables to
accommodate the new 324/326.4 cdclk values.

Bspec: 21809
Fixes: 63c9dae7 ("drm/i915/ehl: Add voltage level requirement table")
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Vivek Kasireddy <vivek.kasireddy@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191118164412.26216-1-matthew.d.roper@intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

When we call intel_dsb_get(), the dsb initialization may fail for
various reasons. We already log the error message in that path, making
it unnecessary to trigger a warning that refcount == 0 when calling
intel_dsb_put().

So here we simplify the logic and do lazy shutdown: leaving the extra
refcount alive so when we call intel_dsb_put() we end up calling
i915_vma_unpin_and_release().
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/20191111205024.22853-3-lucas.demarchi@intel.com

The current dsb API is not really prepared to handle multithread access.
I was debugging an issue that ended up fixed by commit a096883d
("drm/i915/dsb: Remove PIN_MAPPABLE from the DSB object VMA") and was
puzzled how these atomic operations were guaranteeing atomicity.

	if (atomic_add_return(1, &dsb->refcount) != 1)
		return dsb;

Thread A could still be initializing dsb struct (and even fail in the
middle) while thread B would take a reference and use it (even
derefencing a NULL cmd_buf).

I don't think the atomic operations here will help much if this were
to support multithreaded scenario in future, so just remove them to
avoid confusion.

v2: Use refcount++ != 0 instead of ++refcount != 1 (from Ville)
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/20191111205024.22853-2-lucas.demarchi@intel.com
Link: https://patchwork.freedesktop.org/patch/msgid/20191116011539.18230-1-lucas.demarchi@intel.com

When the connector has VCPI allocated and is being moved to another
pipe it causes drm_dp_atomic_release_vcpi_slots() and
drm_dp_atomic_find_vcpi_slots() to be called in the same atomic check
causing the error bellow.
This happens because at this point Intel's hw.enable(and all other
flags in the same struct) is not set but checking to on the uapi one
it have the expected value.

[  580.804430] ------------[ cut here ]------------
[  580.804436] WARNING: CPU: 0 PID: 1221 at drivers/gpu/drm/drm_dp_mst_topology.c:4094 drm_dp_atomic_find_vcpi_slots+0x157/0x180
[  580.804439] Modules linked in: cdc_ether r8152 i915 prime_numbers snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep asix snd_hda_core x86_pkg_temp_thermal usbnet mei_hdcp coretemp mii mei_me crct10dif_pclmul snd_pcm crc32_pclmul mei ghash_clmulni_intel i2c_i801 [last unloaded: prime_numbers]
[  580.804462] CPU: 0 PID: 1221 Comm: kworker/0:0 Tainted: G        W         5.4.0-rc7-zeh+ #1226
[  580.804465] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.D00.2321.A09.1909250226 09/25/2019
[  580.804470] Workqueue: events output_poll_execute
[  580.804476] RIP: 0010:drm_dp_atomic_find_vcpi_slots+0x157/0x180
[  580.804481] Code: 6a ff ff ff 49 89 6d 08 4c 89 6b 10 4c 89 63 18 49 89 6e 08 e9 55 ff ff ff 41 89 c7 5b 5d 44 89 f8 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 08 73 11 82 48 89 ee 41 bf ea ff ff ff e8 b2 e3 02
[  580.804484] RSP: 0018:ffffc900009b7ab8 EFLAGS: 00010246
[  580.804488] RAX: ffff88848c04ef50 RBX: ffff88848c04ef40 RCX: 0000000000000214
[  580.804492] RDX: ffff88848c04f5e0 RSI: ffff888486eb2c68 RDI: ffff88848e518800
[  580.804495] RBP: ffff88849d339000 R08: 00000000bc4e1092 R09: 0000000000000000
[  580.804498] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88848c04e728
[  580.804501] R13: 0000000000000214 R14: ffff88848c04e720 R15: ffff888486eb2c68
[  580.804504] FS:  0000000000000000(0000) GS:ffff8884a0000000(0000) knlGS:0000000000000000
[  580.804507] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  580.804510] CR2: 00007ff6bf1ba680 CR3: 0000000005210003 CR4: 0000000000760ef0
[  580.804512] PKRU: 55555554
[  580.804515] Call Trace:
[  580.804574]  intel_dp_mst_compute_config+0x193/0x2b0 [i915]
[  580.804636]  intel_atomic_check+0x10cc/0x20b0 [i915]
[  580.804644]  ? drm_atomic_print_old_state+0xf1/0x130
[  580.804655]  drm_atomic_check_only+0x56a/0x810
[  580.804663]  drm_atomic_commit+0xe/0x50
[  580.804668]  drm_client_modeset_commit_atomic+0x18b/0x220
[  580.804680]  drm_client_modeset_commit_force+0x4d/0x180
[  580.804685]  drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0
[  580.804689]  drm_fb_helper_set_par+0x27/0x50
[  580.804692]  drm_fb_helper_hotplug_event.part.0+0xa7/0xc0
[  580.804696]  drm_kms_helper_hotplug_event+0x21/0x30
[  580.804699]  output_poll_execute+0x1a4/0x1c0
[  580.804706]  process_one_work+0x25b/0x5b0
[  580.804713]  worker_thread+0x4b/0x3b0
[  580.804720]  kthread+0x100/0x140
[  580.804723]  ? process_one_work+0x5b0/0x5b0
[  580.804725]  ? kthread_park+0x80/0x80
[  580.804730]  ret_from_fork+0x24/0x50
[  580.804740] irq event stamp: 40988
[  580.804743] hardirqs last  enabled at (40987): [<ffffffff81128567>] console_unlock+0x437/0x590
[  580.804746] hardirqs last disabled at (40988): [<ffffffff81001cfa>] trace_hardirqs_off_thunk+0x1a/0x20
[  580.804749] softirqs last  enabled at (40972): [<ffffffff81c00389>] __do_softirq+0x389/0x47f
[  580.804752] softirqs last disabled at (40959): [<ffffffff810b6f19>] irq_exit+0xa9/0xc0
[  580.804754] ---[ end trace 80052e0c60463c67 ]---
[  580.804758] [drm:drm_dp_atomic_find_vcpi_slots] *ERROR* cannot allocate and release VCPI on [MST PORT:000000007880692e] in the same state
[  580.811370] [drm:intel_dp_hpd_pulse [i915]] got esi2 02 00 00
[  580.817239] [drm:intel_dp_hpd_pulse [i915]] got esi 02 00 00
[  580.817313] ------------[ cut here ]------------
[  580.817318] WARNING: CPU: 0 PID: 1221 at drivers/gpu/drm/drm_dp_mst_topology.c:4094 drm_dp_atomic_find_vcpi_slots+0x157/0x180
[  580.817321] Modules linked in: cdc_ether r8152 i915 prime_numbers snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep asix snd_hda_core x86_pkg_temp_thermal
[  580.817412] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on [ENCODER:306:DDI E] - short
[  580.817413]  usbnet mei_hdcp coretemp mii mei_me crct10dif_pclmul snd_pcm crc32_pclmul
[  580.817490] [drm:intel_dp_hpd_pulse [i915]]  is_mst
[  580.817491]  mei ghash_clmulni_intel i2c_i801 [last unloaded: prime_numbers]
[  580.817498] CPU: 0 PID: 1221 Comm: kworker/0:0 Tainted: G        W         5.4.0-rc7-zeh+ #1226
[  580.817503] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.D00.2321.A09.1909250226 09/25/2019
[  580.817506] Workqueue: events output_poll_execute
[  580.817511] RIP: 0010:drm_dp_atomic_find_vcpi_slots+0x157/0x180
[  580.817514] Code: 6a ff ff ff 49 89 6d 08 4c 89 6b 10 4c 89 63 18 49 89 6e 08 e9 55 ff ff ff 41 89 c7 5b 5d 44 89 f8 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 08 73 11 82 48 89 ee 41 bf ea ff ff ff e8 b2 e3 02
[  580.817516] RSP: 0018:ffffc900009b7ab8 EFLAGS: 00010246
[  580.817519] RAX: ffff88848c04ef50 RBX: ffff88848c04ef40 RCX: 000000000000018f
[  580.817521] RDX: ffff88848c04f5e0 RSI: ffff888486eb2c68 RDI: ffff88848e518800
[  580.817523] RBP: ffff88849d339000 R08: 00000000bc4e1092 R09: 0000000000000000
[  580.817525] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88848c04e728
[  580.817528] R13: 000000000000018f R14: ffff88848c04e720 R15: ffff888486eb2c68
[  580.817532] FS:  0000000000000000(0000) GS:ffff8884a0000000(0000) knlGS:0000000000000000
[  580.817534] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  580.817535] CR2: 00007ff6bf1ba680 CR3: 0000000005210003 CR4: 0000000000760ef0
[  580.817537] PKRU: 55555554
[  580.817538] Call Trace:
[  580.817620]  intel_dp_mst_compute_config+0x193/0x2b0 [i915]
[  580.817690]  intel_atomic_check+0x10cc/0x20b0 [i915]
[  580.817697]  ? drm_atomic_print_old_state+0xf1/0x130
[  580.817711]  drm_atomic_check_only+0x56a/0x810
[  580.817721]  drm_atomic_commit+0xe/0x50
[  580.817726]  drm_client_modeset_commit_atomic+0x18b/0x220
[  580.817744]  drm_client_modeset_commit_force+0x4d/0x180
[  580.817751]  drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0
[  580.817756]  drm_fb_helper_set_par+0x27/0x50
[  580.817762]  drm_fb_helper_hotplug_event.part.0+0xa7/0xc0
[  580.817767]  drm_kms_helper_hotplug_event+0x21/0x30
[  580.817771]  output_poll_execute+0x1a4/0x1c0
[  580.817780]  process_one_work+0x25b/0x5b0
[  580.817791]  worker_thread+0x4b/0x3b0
[  580.817800]  kthread+0x100/0x140
[  580.817804]  ? process_one_work+0x5b0/0x5b0
[  580.817807]  ? kthread_park+0x80/0x80
[  580.817813]  ret_from_fork+0x24/0x50
[  580.817832] irq event stamp: 41028
[  580.817838] hardirqs last  enabled at (41027): [<ffffffff81128567>] console_unlock+0x437/0x590
[  580.817841] hardirqs last disabled at (41028): [<ffffffff81001cfa>] trace_hardirqs_off_thunk+0x1a/0x20
[  580.817846] softirqs last  enabled at (41022): [<ffffffff81c00389>] __do_softirq+0x389/0x47f
[  580.817851] softirqs last disabled at (41013): [<ffffffff810b6f19>] irq_exit+0xa9/0xc0
[  580.817854] ---[ end trace 80052e0c60463c68 ]---
[  580.817858] [drm:drm_dp_atomic_find_vcpi_slots] *ERROR* cannot allocate and release VCPI on [MST PORT:000000007880692e] in the same state
[  580.830767] [drm:intel_dp_mst_compute_config [i915]] failed finding vcpi slots:-22
[  580.830821] [drm:intel_atomic_check [i915]] Encoder config failure: -22

Cc: Lyude Paul <lyude@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115200430.53146-1-jose.souza@intel.com

VBT revision 229 adds a new "Generic DTD" block 58 and deprecates the
old LFP panel mode data in block 42.  Let's start parsing this block to
fill in the panel fixed mode on devices with a >=229 VBT.

v2:
 * Update according to the recent updates:
    - DTD size is now 16 bits instead of 24
    - polarity is now just a single bit for hsync and vsync and is
      properly documented
 * Minor checkpatch fix

v3:
 * Now that panel options are parsed separately from the previous patch,
   move generic DTD parsing into a function parallel to
   parse_lfp_panel_dtd.  We'll still fall back to looking at the legacy
   LVDS timing block if the generic DTD fails.  (Jani)
 * Don't forget to actually set lfp_lvds_vbt_mode!  (Jani)
 * Drop "bdb_" prefix from dtd entry structure.  (Jani)
 * Follow C99 standard for structure's flexible array member.  (Jani)

v4:
 * Add "positive" to polarity field names for clarity.  (Jani)
 * Move VBT version check and fallback to legacy DTD parsing logic to a
   helper to keep top-level VBT parsing uncluttered.  (Jani)
 * Restructure reserved bit packing at end of generic_dtd_entry from
   "u32 rsvd:24" to "u8 rsvd[3]" to prevent copy/paste mistakes in the
   future.  (Jani)

Bspec: 54751
Bspec: 20148
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115165132.9472-3-matthew.d.roper@intel.com

Newer VBT versions will add an alternate way to read panel DTD
information, so let's split parsing of the general panel information
from the timing data in preparation.

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NJesse Barnes <jsbarnes@google.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115165132.9472-2-matthew.d.roper@intel.com

It's supposed to be just a const pointer.

Fixes: 074c77e3 ("drm/i915/tgl: Gen-12 display loses Yf tiling and legacy CCS support")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191115120440.17883-1-jani.nikula@intel.com

Currently we're blindly poking at the frame start delay bits
in PIPECONF when trying to sanitize the hardware state. Those
bits decided to move elsewhere on HSW, so on many platforms
we're not doing anything at all here. Also we're forgetting
about the PCH transcoder entirely.

Add all the bit definitions for the various homes these bits
have had throughout the years, and reset them all to zero.

However I'm not entirely sure this is a safe thing to do. If
not I guess we'd want full readout+statecheck for this stuff.
For now let's stick to the current logic and hope for the
best.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191024122138.25065-3-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>

HDMI_PICTURE_ASPECT_NONE is zero and the connector state is kzalloc()'d
so no need to initialize conn_state->picture_aspect_ratio with it.

Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190620142639.17518-6-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>

HDMI_PICTURE_ASPECT_NONE means "Automatic" so when the user has that
selected we should keep whatever aspect ratio the mode already has.

Also no point in checking for connector->is_hdmi in the SDVO code
since we only attach the property to HDMI connectors.

Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190620142639.17518-5-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>

fbdev uses the physical address of our framebuffer for its fb_mmap()
routine. While we need to adapt this address for the new io BAR, we have
to fix v5.4 first! The simplest fix is to restore the smem back to v5.3
and we will then probably have to implement our fbops->fb_mmap() callback
to handle local memory.
Reported-by: NNeil MacLeod <freedesktop@nmacleod.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112256
Fixes: 5f889b9a ("drm/i915: Disregard drm_mode_config.fb_base")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: NNeil MacLeod <freedesktop@nmacleod.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191113180633.3947-1-chris@chris-wilson.co.uk

Tiger Lake supports HDMI on port A. For other platforms we ignore what
the VBT says regarding HDMI to workaround broken VBTs, see
commit 2ba7d7e0 ("drm/i915/bios: ignore HDMI on port A"). Make this
apply gen12+ so they inherit the TGL behavior.
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/20191113021935.41547-1-lucas.demarchi@intel.com

This register was being enabled after enable TRANS_DDI_FUNC_CTL and
PIPECONF/TRANS_CONF while BSpec states that it should be set when
enabling TRANS_DDI_FUNC_CTL.

BSpec: 49190
BSpec: 22243
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191107214559.77087-3-jose.souza@intel.com

Adding pipe D support to DSI transcoder.
Not adding it for EDP transcoder code paths as only TGL has 4 pipes
and it do not have a EDP transcoder.
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191107214559.77087-2-jose.souza@intel.com

When we call intel_bios_is_valid_vbt(), size may not actually be the
size of the VBT, but rather the size of the blob the VBT is contained
in. For example, when mapping the PCI oprom, size will be the entire
oprom size. We don't want to read beyond what is reported to be the
VBT. So make sure we vbt->vbt_size makes sense and use that for
the latter checks.

v2: check for vbt_size after checking for vbt signature and give it a
more meaningful error message (from Jani)
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191108003602.33526-3-lucas.demarchi@intel.com

oprom is actually a better name to use when using
pci_map_rom(). "bios"  is way too generic and confusing.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191108003602.33526-2-lucas.demarchi@intel.com

The setting of MSA is done by the DDI .pre_enable() hook. And when we are
using MST, the MSA is only set to first mst stream by calling of
DDI .pre_eanble() hook. It raies issues to non-first mst streams.
Wrong MSA or missed MSA packets might show scrambled screen or wrong
screen.

This splits a setting of MSA to MST and SST cases. And In the MST case it
will call a setting of MSA after an allocating of Virtual Channel from
MST encoder pre_enable callback.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112212
Fixes: 0c06fa15 ("drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA")
Fixes: d4a415dc ("drm/i915: Fix MST oops due to MSA changes")
Signed-off-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191106212636.502471-1-gwan-gyeong.mun@intel.comReviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
[vsyrjala: nuke spurious newline]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit bd8c9cca)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191113125241.20547-1-ville.syrjala@linux.intel.com

The warning should be just a warning. Where it is currently is wrong
since we already registered the connector on drm, meaning it dies later
on a NULL pointer deref if the VBT-overriding we have is removed. Move
the warning up.
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/20191108214251.79305-1-lucas.demarchi@intel.com

Using the array is getting clumsy. Make things a bit more dynamic.

Remove early returns on not having child devices when the end result
after "iterating" the empty list would be the same.

v3:
- use list_add_tail to not reverse the child device list (Ville)

v2:
- stick to previous naming of child devices (Ville)
- use kzalloc, handle failure
- initialize list head earlier to keep intel_bios_driver_remove() safe

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3e72da0b412354ed8be6719df55b0e0cc4caa61a.1573227240.git.jani.nikula@intel.com

The pre-initialized magic value is a bit silly, switch to a flag
instead.

v2: Reduce paranoia to a single sanity check (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/74fe24ab6d5f0ea2ff2059cdf044d6d3006080fc.1573227240.git.jani.nikula@intel.com

The setting of MSA is done by the DDI .pre_enable() hook. And when we are
using MST, the MSA is only set to first mst stream by calling of
DDI .pre_eanble() hook. It raies issues to non-first mst streams.
Wrong MSA or missed MSA packets might show scrambled screen or wrong
screen.

This splits a setting of MSA to MST and SST cases. And In the MST case it
will call a setting of MSA after an allocating of Virtual Channel from
MST encoder pre_enable callback.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112212
Fixes: 0c06fa15 ("drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA")
Fixes: d4a415dc ("drm/i915: Fix MST oops due to MSA changes")
Signed-off-by: NGwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191106212636.502471-1-gwan-gyeong.mun@intel.comReviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
[vsyrjala: nuke spurious newline]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

The LUTs are single buffered so in order to program them without
tearing we'd have to do it during vblank (actually to be 100%
effective it has to happen between start of vblank and frame start).
We have no proper mechanism for that at the moment so we just
defer loading them after the vblank waits have happened. That
is not quite sufficient (especially when committing multiple pipes
whose vblanks don't line up) so the LUT load will often leak into
the following frame causing tearing.

However in case the hardware wasn't previously using the LUT we
can preload it before setting the enable bit (which is double
buffered so won't tear). Let's determine if we can do such
preloading and make it happen. Slight variation between the
hardware requires some platforms specifics in the checks.

Hans is seeing ugly colored flash on VLV/CHV macchines (GPD win
and Asus T100HA) when the gamma LUT gets loaded for the first
time as the BIOS has left some junk in the LUT memory.

v2: Deal with uapi vs. hw crtc state split
    s/GCM/CGM/ typo fix

Cc: Hans de Goede <hdegoede@redhat.com>
Fixes: 051a6d8d ("drm/i915: Move LUT programming to happen after vblank waits")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191030190815.7359-1-ville.syrjala@linux.intel.comTested-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
(cherry picked from commit 0ccc42a2)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Make sure we have a crtc before probing its primary plane's
max stride. Initially I thought we can't get this far without
crtcs, but looks like we can via the dumb_create ioctl.

Not sure if we shouldn't disable dumb buffer support entirely
when we have no crtcs, but that would require some amount of work
as the only thing currently being checked is dev->driver->dumb_create
which we'd have to convert to some device specific dynamic thing.

Cc: stable@vger.kernel.org
Reported-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Fixes: aa5ca8b7 ("drm/i915: Align dumb buffer stride to 4k to allow for gtt remapping")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191106172349.11987-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit baea9ffe)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

The intel_dp_link_training.h include has no need or place in
intel_display.h. Include it in intel_display.c instead.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Fixes: eadf6f91 ("drm/i915/display/icl: Enable master-slaves in trans port sync")
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029103947.7535-1-jani.nikula@intel.com
(cherry picked from commit 3c954c41)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Make sure we have a crtc before probing its primary plane's
max stride. Initially I thought we can't get this far without
crtcs, but looks like we can via the dumb_create ioctl.

Not sure if we shouldn't disable dumb buffer support entirely
when we have no crtcs, but that would require some amount of work
as the only thing currently being checked is dev->driver->dumb_create
which we'd have to convert to some device specific dynamic thing.

Cc: stable@vger.kernel.org
Reported-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Fixes: aa5ca8b7 ("drm/i915: Align dumb buffer stride to 4k to allow for gtt remapping")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191106172349.11987-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Rather than just specifying the bullet numbers from the bspec (e.g.,
"4.b") actually include the description of what the bspec wants us to
do.  Steps can be renumbered or moved so including the description will
help us match the code up to the spec.  Plus if we add support for new
platforms, some of the steps may be added/removed so more descriptive
comments will be useful for ensuring all of the bspec requirements are
met.

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191107174527.11165-1-matthew.d.roper@intel.comReviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

The LUTs are single buffered so in order to program them without
tearing we'd have to do it during vblank (actually to be 100%
effective it has to happen between start of vblank and frame start).
We have no proper mechanism for that at the moment so we just
defer loading them after the vblank waits have happened. That
is not quite sufficient (especially when committing multiple pipes
whose vblanks don't line up) so the LUT load will often leak into
the following frame causing tearing.

However in case the hardware wasn't previously using the LUT we
can preload it before setting the enable bit (which is double
buffered so won't tear). Let's determine if we can do such
preloading and make it happen. Slight variation between the
hardware requires some platforms specifics in the checks.

Hans is seeing ugly colored flash on VLV/CHV macchines (GPD win
and Asus T100HA) when the gamma LUT gets loaded for the first
time as the BIOS has left some junk in the LUT memory.

v2: Deal with uapi vs. hw crtc state split
    s/GCM/CGM/ typo fix

Cc: Hans de Goede <hdegoede@redhat.com>
Fixes: 051a6d8d ("drm/i915: Move LUT programming to happen after vblank waits")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191030190815.7359-1-ville.syrjala@linux.intel.comTested-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>

The intel_dp_link_training.h include has no need or place in
intel_display.h. Include it in intel_display.c instead.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Fixes: eadf6f91 ("drm/i915/display/icl: Enable master-slaves in trans port sync")
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029103947.7535-1-jani.nikula@intel.com

Prefer using intel_encoder and pass the base where needed rather than
keeping both encoder and intel_encoder variables around.

v2: actually add all changes to the patch
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191106071715.10613-1-lucas.demarchi@intel.com

The uapi vs. hw state split introduced a bug in
intel_crtc_disable_noatomic() where it's now frobbing an already
freed temp crtc state instead of adjusting the crtc state we
are really left with. Fix that by making a cleaner separation
beteen the two.

This causes explosions on any machine that boots up with pipes
already running but not hooked up to any encoder (typical
behaviour for gen2-4 VBIOS).

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 58d124ea ("drm/i915: Complete crtc hw/uapi split, v6.")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191105171447.22111-1-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

It sounds like the hardware only needs the DSB object to be in global GTT
and not in the mappable region.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: NAnimesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191017155810.21654-1-tvrtko.ursulin@linux.intel.com

Use intel_dsc_ prefix. No functional changes.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191104141439.26312-4-jani.nikula@intel.com

Split out the DP specific parts, making it easier to add DSI specific
configuration. Also move the encoder specific parts towards the end, to
allow overriding generic configuration if needed. This also improves
clarity by making it clear the encoder independent configuration does
not depend on the encoder specific parts.

v2: Rebase

Cc: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191104141439.26312-3-jani.nikula@intel.com

Use a simple pointer to the relevant element instead of duplicating the
array subscription. No functional changes.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191104141439.26312-2-jani.nikula@intel.com

No need for them to be mutable.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191104141439.26312-1-jani.nikula@intel.com

Since CNP it's possible for rawclk to have two different values, 19.2
and 24 MHz. If the value indicated by SFUSE_STRAP register is different
from the power on default for PCH_RAWCLK_FREQ, we'll end up having a
mismatch between the rawclk hardware and software states after
suspend/resume. On previous platforms this used to work by accident,
because the power on defaults worked just fine.

Update the rawclk also on resume. The natural place to do this would be
intel_modeset_init_hw(), however VLV/CHV need it done before
intel_power_domains_init_hw(). Thus put it there even if it feels
slightly out of place.

v2: Call intel_update_rawclck() in intel_power_domains_init_hw() for all
    platforms (Ville).
Reported-by: NShawn Lee <shawn.c.lee@intel.com>
Cc: Shawn Lee <shawn.c.lee@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NShawn Lee <shawn.c.lee@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191101142024.13877-1-jani.nikula@intel.com

Just avoid the additional read in case DP_TP_CTL is enabled:
read it once and save the value.
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/20191030012448.14937-5-lucas.demarchi@intel.com

For MST on Tiger Lake there are different moments when we need to
configure the transcoder clock select. For the first link this is in step
7.a of the spec, before training the link.  For additional streams this
should be done as part of step 8.b after programming receiver VC Payload
ID.

Bspec: 49190
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/20191030012448.14937-4-lucas.demarchi@intel.com

Wrap drm_atomic_get_old_connector_state so we can get the
intel_digital_connector_state and make it easier to migrate to intel
types.
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/20191030012448.14937-3-lucas.demarchi@intel.com