On Geminilake, sometimes audio card is not getting
detected after reboot. This is a spurious issue happening on
Geminilake. HW codec and HD audio controller link was going
out of sync for which there was a fix in i915 driver but
was not getting invoked for GLK. Extending this fix to GLK as well.

Tested by Du,Wenkai on GLK board.

Bspec: 21829

v2: Instead of checking GEN9_BC, BXT and GLK macros, use IS_GEN9 macro (Jani N)

Cc: <stable@vger.kernel.org> # b651bd2a ("drm/i915/audio: Fix audio enumeration issue on BXT")
Cc: <stable@vger.kernel.org>
Signed-off-by: NGaurav K Singh <gaurav.k.singh@intel.com>
Reviewed-by: NAbhay Kumar <abhay.Kumar@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523989338-29677-1-git-send-email-gaurav.k.singh@intel.com
(cherry picked from commit 82212290)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

We have to cleanup after i915_perf_init(), even on the error path, as it
passes a pointer into the module to the sysfs core. If we fail to
unregister the sysctl table, we leave a dangling pointer which then may
explode anytime later.

Fixes: 9f9b2792 ("drm/i915/perf: reuse timestamp frequency from device info")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180414091233.32224-1-chris@chris-wilson.co.uk
(cherry picked from commit 9f172f6f)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

The VBT contains the DDC pin to use for specific ports. Alas, sometimes
the field appears to contain bogus data, and while we check for it later
on in intel_gmbus_get_adapter() we fail to check the returned NULL on
errors. Oops results.

The simplest approach seems to be to catch and ignore the bogus DDC pins
already at the VBT parsing phase, reverting to fixed per port default
pins. This doesn't guarantee display working, but at least it prevents
the oops. And we continue to be fuzzed by VBT.

One affected machine is Dell Latitude 5590 where a BIOS upgrade added
invalid DDC pins.

Typical backtrace:

[   35.461411] WARN_ON(!intel_gmbus_is_valid_pin(dev_priv, pin))
[   35.461432] WARNING: CPU: 6 PID: 411 at drivers/gpu/drm/i915/intel_i2c.c:844 intel_gmbus_get_adapter+0x32/0x37 [i915]
[   35.461437] Modules linked in: i915 ahci libahci dm_snapshot dm_bufio dm_raid raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
[   35.461445] CPU: 6 PID: 411 Comm: kworker/u16:2 Not tainted 4.16.0-rc7.x64-g1cda370ffded #1
[   35.461447] Hardware name: Dell Inc. Latitude 5590/0MM81M, BIOS 1.1.9 03/13/2018
[   35.461450] Workqueue: events_unbound async_run_entry_fn
[   35.461465] RIP: 0010:intel_gmbus_get_adapter+0x32/0x37 [i915]
[   35.461467] RSP: 0018:ffff9b4e43d47c40 EFLAGS: 00010286
[   35.461469] RAX: 0000000000000000 RBX: ffff98f90639f800 RCX: ffffffffae051960
[   35.461471] RDX: 0000000000000001 RSI: 0000000000000092 RDI: 0000000000000246
[   35.461472] RBP: ffff98f905410000 R08: 0000004d062a83f6 R09: 00000000000003bd
[   35.461474] R10: 0000000000000031 R11: ffffffffad4eda58 R12: ffff98f905410000
[   35.461475] R13: ffff98f9064c1000 R14: ffff9b4e43d47cf0 R15: ffff98f905410000
[   35.461477] FS:  0000000000000000(0000) GS:ffff98f92e580000(0000) knlGS:0000000000000000
[   35.461479] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   35.461481] CR2: 00007f5682359008 CR3: 00000001b700c005 CR4: 00000000003606e0
[   35.461483] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   35.461484] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   35.461486] Call Trace:
[   35.461501]  intel_hdmi_set_edid+0x37/0x27f [i915]
[   35.461515]  intel_hdmi_detect+0x7c/0x97 [i915]
[   35.461518]  drm_helper_probe_single_connector_modes+0xe1/0x6c0
[   35.461521]  drm_setup_crtcs+0x129/0xa6a
[   35.461523]  ? __switch_to_asm+0x34/0x70
[   35.461525]  ? __switch_to_asm+0x34/0x70
[   35.461527]  ? __switch_to_asm+0x40/0x70
[   35.461528]  ? __switch_to_asm+0x34/0x70
[   35.461529]  ? __switch_to_asm+0x40/0x70
[   35.461531]  ? __switch_to_asm+0x34/0x70
[   35.461532]  ? __switch_to_asm+0x40/0x70
[   35.461534]  ? __switch_to_asm+0x34/0x70
[   35.461536]  __drm_fb_helper_initial_config_and_unlock+0x34/0x46f
[   35.461538]  ? __switch_to_asm+0x40/0x70
[   35.461541]  ? _cond_resched+0x10/0x33
[   35.461557]  intel_fbdev_initial_config+0xf/0x1c [i915]
[   35.461560]  async_run_entry_fn+0x2e/0xf5
[   35.461563]  process_one_work+0x15b/0x364
[   35.461565]  worker_thread+0x2c/0x3a0
[   35.461567]  ? process_one_work+0x364/0x364
[   35.461568]  kthread+0x10c/0x122
[   35.461570]  ? _kthread_create_on_node+0x5d/0x5d
[   35.461572]  ret_from_fork+0x35/0x40
[   35.461574] Code: 74 16 89 f6 48 8d 04 b6 48 c1 e0 05 48 29 f0 48 8d 84 c7 e8 11 00 00 c3 48 c7 c6 b0 19 1e c0 48 c7 c7 64 8a 1c c0 e8 47 88 ed ec <0f> 0b 31 c0 c3 8b 87 a4 04 00 00 80 e4 fc 09 c6 89 b7 a4 04 00
[   35.461604] WARNING: CPU: 6 PID: 411 at drivers/gpu/drm/i915/intel_i2c.c:844 intel_gmbus_get_adapter+0x32/0x37 [i915]
[   35.461606] ---[ end trace 4fe1e63e2dd93373 ]---
[   35.461609] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[   35.461613] IP: i2c_transfer+0x4/0x86
[   35.461614] PGD 0 P4D 0
[   35.461616] Oops: 0000 [#1] SMP PTI
[   35.461618] Modules linked in: i915 ahci libahci dm_snapshot dm_bufio dm_raid raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx
[   35.461624] CPU: 6 PID: 411 Comm: kworker/u16:2 Tainted: G        W        4.16.0-rc7.x64-g1cda370ffded #1
[   35.461625] Hardware name: Dell Inc. Latitude 5590/0MM81M, BIOS 1.1.9 03/13/2018
[   35.461628] Workqueue: events_unbound async_run_entry_fn
[   35.461630] RIP: 0010:i2c_transfer+0x4/0x86
[   35.461631] RSP: 0018:ffff9b4e43d47b30 EFLAGS: 00010246
[   35.461633] RAX: ffff9b4e43d47b6e RBX: 0000000000000005 RCX: 0000000000000001
[   35.461635] RDX: 0000000000000002 RSI: ffff9b4e43d47b80 RDI: 0000000000000000
[   35.461636] RBP: ffff9b4e43d47bd8 R08: 0000004d062a83f6 R09: 00000000000003bd
[   35.461638] R10: 0000000000000031 R11: ffffffffad4eda58 R12: 0000000000000002
[   35.461639] R13: 0000000000000001 R14: ffff9b4e43d47b6f R15: ffff9b4e43d47c07
[   35.461641] FS:  0000000000000000(0000) GS:ffff98f92e580000(0000) knlGS:0000000000000000
[   35.461643] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   35.461645] CR2: 0000000000000010 CR3: 00000001b700c005 CR4: 00000000003606e0
[   35.461646] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   35.461647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   35.461649] Call Trace:
[   35.461652]  drm_do_probe_ddc_edid+0xb3/0x128
[   35.461654]  drm_get_edid+0xe5/0x38d
[   35.461669]  intel_hdmi_set_edid+0x45/0x27f [i915]
[   35.461684]  intel_hdmi_detect+0x7c/0x97 [i915]
[   35.461687]  drm_helper_probe_single_connector_modes+0xe1/0x6c0
[   35.461689]  drm_setup_crtcs+0x129/0xa6a
[   35.461691]  ? __switch_to_asm+0x34/0x70
[   35.461693]  ? __switch_to_asm+0x34/0x70
[   35.461694]  ? __switch_to_asm+0x40/0x70
[   35.461696]  ? __switch_to_asm+0x34/0x70
[   35.461697]  ? __switch_to_asm+0x40/0x70
[   35.461698]  ? __switch_to_asm+0x34/0x70
[   35.461700]  ? __switch_to_asm+0x40/0x70
[   35.461701]  ? __switch_to_asm+0x34/0x70
[   35.461703]  __drm_fb_helper_initial_config_and_unlock+0x34/0x46f
[   35.461705]  ? __switch_to_asm+0x40/0x70
[   35.461707]  ? _cond_resched+0x10/0x33
[   35.461724]  intel_fbdev_initial_config+0xf/0x1c [i915]
[   35.461727]  async_run_entry_fn+0x2e/0xf5
[   35.461729]  process_one_work+0x15b/0x364
[   35.461731]  worker_thread+0x2c/0x3a0
[   35.461733]  ? process_one_work+0x364/0x364
[   35.461734]  kthread+0x10c/0x122
[   35.461736]  ? _kthread_create_on_node+0x5d/0x5d
[   35.461738]  ret_from_fork+0x35/0x40
[   35.461739] Code: 5c fa e1 ad 48 89 df e8 ea fb ff ff e9 2a ff ff ff 0f 1f 44 00 00 31 c0 e9 43 fd ff ff 31 c0 45 31 e4 e9 c5 fd ff ff 41 54 55 53 <48> 8b 47 10 48 83 78 10 00 74 70 41 89 d4 48 89 f5 48 89 fb 65
[   35.461756] RIP: i2c_transfer+0x4/0x86 RSP: ffff9b4e43d47b30
[   35.461757] CR2: 0000000000000010
[   35.461759] ---[ end trace 4fe1e63e2dd93374 ]---

Based on a patch by Fei Li.

v2: s/reverting/sticking/ (Chris)

Cc: stable@vger.kernel.org
Cc: Fei Li <fei.li@intel.com>
Co-developed-by: NFei Li <fei.li@intel.com>
Reported-by: NPavel Nakonechnyi <zorg1331@gmail.com>
Reported-and-tested-by: NSeweryn Kokot <sewkokot@gmail.com>
Reported-and-tested-by: NLaszlo Valko <valko@linux.karinthy.hu>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105549
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105961Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180411131519.9091-1-jani.nikula@intel.com
(cherry picked from commit f212bf9a)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests
on some CI machines I have concluded that: a) the PMU readout of RC6 can
race against runtime PM transitions, and b) there are other reasons than
being runtime suspended which can cause intel_runtime_pm_get_if_in_use to
fail.

Therefore when estimating RC6 the code needs to assert we are indeed in
suspended state, and if not, the best we can do is return the last known
RC6 value.

Without this check we can calculate the estimated value based on un-
initialized or inappropriate internal state, which can result in over-
estimation, or in any case incorrect value being returned.

v2:
 * Re-arrange the code a bit to avoid second unlock and return branch.
   (Chris Wilson)

v3:
 * Insert some strategic blank lines and improve commit msg.
   (Chris Wilson)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: 1fe699e3 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105010
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180410112704.24462-1-tvrtko.ursulin@linux.intel.com
(cherry picked from commit 2924bdee)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Along the eb_lookup_vmas() error path, the return value from
kmem_cache_alloc() was freed using kfree(). Fix it to use the proper
kmem_cache_free() instead.

Fixes: d1b48c1e ("drm/i915: Replace execbuf vma ht with an idr")
Signed-off-by: NXidong Wang <wangxidong_97@163.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: <stable@vger.kernel.org> # v4.14+
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/20180404093824.9313-1-chris@chris-wilson.co.uk
(cherry picked from commit 6be1187d)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

When cancelling the requests and clearing out the ports following a
successful preemption completion, also clear the active flag. I had
assumed that all preemptions would be followed by an immediate dequeue
(preserving the active user flag), but under rare circumstances we may
be triggering a preemption for the second port only for it to have
completed before the preemotion kicks in; leaving execlists->active set
even though the system is now idle.

We can clear the flag inside the common execlists_cancel_port_requests()
as the other users also expect the semantics of active being cleared.

Fixes: f6322edd ("drm/i915/preemption: Allow preemption between submission ports")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180324125829.27026-1-chris@chris-wilson.co.uk
(cherry picked from commit eed7ec52)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Add drm_format_mod update, which is omitted.

Fixes: e546e281("drm/i915/gvt: Dmabuf support for GVT-g")
Cc: stable@vger.kernel.org
Signed-off-by: NTina Zhang <tina.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Much error exist in host dmesg during guest boot up with loca display
enabled.
gvt: vgpu 1: invalid range gmadr 0x0 size 0x0

This error happens when qemu get dmabuf info in case that the virtual
display plane is enabled but its base address is an invalid 0, such
case may be true before guest enable its plane. At this moment, its
state is copied from host where the plane may be enabled.

This patch disable primary/sprite/cursor plane at virtual display
initialization, so intel_vgpu_decode_primary/cursor/sprite could
return early as plane is disabled, then plane base check is skipped and
error message disapper.
Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Much error message exist in host dmesg when guest boot up with local
display enabled.
[  167.680011] gvt: vgpu 1: invalid range gmadr 0x0 size 0x0
[  167.680013] gvt: vgpu 1: invalid gma address: 0

The second error line duplicate with the first error line, so this
patch remove this redundant error message and make the next error
message much clearer.
Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Ditto, don't forget ggtt entries during reset.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

We have canceled dma map for ppgtt entries. Also we need to do it for
ggtt entries when them are invalidated.

This can fix task hung issue as:
[13517.791767] INFO: task gvt_service_thr:1081 blocked for more than 120 seconds.
[13517.792584] Not tainted 4.14.15+ #3
[13517.793417] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[13517.794267] gvt_service_thr D 0 1081 2 0x80000000
[13517.795132] Call Trace:
[13517.795996] ? __schedule+0x493/0x77b
[13517.796859] schedule+0x79/0x82
[13517.797740] schedule_preempt_disabled+0x5/0x6
[13517.798614] __mutex_lock.isra.0+0x2b5/0x445
[13517.799504] ? __switch_to_asm+0x24/0x60
[13517.800381] ? intel_gvt_cleanup+0x10/0x10
[13517.801261] ? intel_gvt_schedule+0x19/0x2b9
[13517.802107] intel_gvt_schedule+0x19/0x2b9
[13517.802954] ? intel_gvt_cleanup+0x10/0x10
[13517.803824] gvt_service_thread+0xe3/0x10d
[13517.804704] ? wait_woken+0x68/0x68
[13517.805588] kthread+0x118/0x120
[13517.806478] ? kthread_create_on_node+0x3a/0x3a
[13517.807381] ? call_usermodehelper_exec_async+0x113/0x11a
[13517.808307] ret_from_fork+0x35/0x40

v3: split out ggtt reset case.
v2: also unmap ggtt during reset.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

GVT-g dispatches request to host i915 and depends on i915 notify
ring interrupt mechanism to check completion of request.
For now MI_USER_INTERRUPT in guest requests is passed through
in GVT-g cmd parser and i915 does not use it, which causes
unnecessary interrupt handling in i915.
On the other hand, if several requests from guest are combined into
one request in and contain MI_USER_INTERRUPT in the middle of
combined request. GVT-g still has to wait on the whole request to
complete to inject user interrupts to guest.

This patch makes all the MI_USER_INTERRUPT nop to save some interrupt
handling.

Here is test result to run glmark2 on guest for 10 seconds:
host master interrupts number is reduced from 16021 to 11162
host user interrupts number is reduced from 7936 to 3536

v2:
- revise commit message. (Kevin)
Reviewed-by: NKevin Tian <kevin.tian@intel.com>
Signed-off-by: NZhipeng Gong <zhipeng.gong@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 1466154 ("Missing break in switch")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

After

commit dd9f31c7
Author: Imre Deak <imre.deak@intel.com>
Date:   Wed Aug 16 17:46:07 2017 +0300

    drm/i915/gen9+: Set same power state before hibernation image
    save/restore

during hibernation/suspend the power domain functionality got disabled,
after which resume could leave it incorrectly disabled if the ACPI
target state was S0 during suspend and i915 was not loaded by the loader
kernel.

This was caused by not considering if we resumed from hibernation as the
condition for power domains reiniting.

Fix this by simply tracking if we suspended power domains during system
suspend and reinit power domains accordingly during resume. This will
result in reiniting power domains always when resuming from hibernation,
regardless of the platform and whether or not i915 is loaded by the
loader kernel.

The reason we didn't catch this earlier is that the enabled/disabled
state of power domains during PMSG_FREEZE/PMSG_QUIESCE is platform
and kernel config dependent: on my SKL the target state is S4
during PMSG_FREEZE and (with the driver loaded in the loader kernel)
S0 during PMSG_QUIESCE. On the reporter's machine it's S0 during
PMSG_FREEZE but (contrary to this) power domains are not initialized
during PMSG_QUIESCE since i915 is not loaded in the loader kernel, or
it's loaded but without the DMC firmware being available.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105196
Reported-and-tested-by: amn-bas@hotmail.com
Fixes: dd9f31c7 ("drm/i915/gen9+: Set same power state before hibernation image save/restore")
Cc: amn-bas@hotmail.com
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org>
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/20180322143642.26883-1-imre.deak@intel.com
(cherry picked from commit 0f90603c)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

We were relying on the uncached reads when processing the CSB to provide
ourselves with the serialisation with the interrupt handler (so we could
detect new interrupts in the middle of processing the old one). However,
in commit 767a983a ("drm/i915/execlists: Read the context-status HEAD
from the HWSP") those uncached reads were eliminated (on one path at
least) and along with them our serialisation. The result is that we
would very rarely miss notification of a new interrupt and leave a
context-switch unprocessed, hanging the GPU.

Fixes: 767a983a ("drm/i915/execlists: Read the context-status HEAD from the HWSP")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180321091027.21034-1-chris@chris-wilson.co.uk
(cherry picked from commit 9153e6b7)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

If the GPU is stuck waiting for an event or for a semaphore, we need to
reset the GPU in order to recover. We have to tell the reset routine
which engines we want reset, but we were still using the old interface
and declaring it as "not-fatal".

Fixes: 14b730fc ("drm/i915/tdr: Prepare error handler to accept mask of hung engines")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180320100449.1360-1-chris@chris-wilson.co.uk
(cherry picked from commit ca98317b)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

If bios sets up an MST output and hardware state readout code sees this is
an SST configuration, when disabling the encoder we end up calling
->post_disable_dp() hook instead of the MST version. Consequently, we write
to the DP_SET_POWER dpcd to set it D3 state. Further along when we try
enable the encoder in MST mode, POWER_UP_PHY transaction fails to power up
the MST hub. This results in continuous link training failures which keep
the system busy delaying boot. We could identify bios MST boot discrepancy
and handle it accordingly but a simple way to solve this is to write to the
DP_SET_POWER dpcd for MST too.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105470
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reported-by: NLaura Abbott <labbott@redhat.com>
Cc: stable@vger.kernel.org
Fixes: 5ea2355a ("drm/i915/mst: Use MST sideband message transactions for dpms control")
Tested-by: NLaura Abbott <labbott@redhat.com>
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180314054825.1718-1-dhinakaran.pandiyan@intel.com
(cherry picked from commit ad260ab3)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

On unknown/unhandled ioctls the driver should return an error, so
userspace knows it tried to use something unsupported.

Cc: stable@vger.kernel.org
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

If the GPU is stuck waiting for an event or for a semaphore, we need to
reset the GPU in order to recover. We have to tell the reset routine
which engines we want reset, but we were still using the old interface
and declaring it as "not-fatal".

Fixes: 14b730fc ("drm/i915/tdr: Prepare error handler to accept mask of hung engines")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180320100449.1360-1-chris@chris-wilson.co.uk
(cherry picked from commit ca98317b)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

If bios sets up an MST output and hardware state readout code sees this is
an SST configuration, when disabling the encoder we end up calling
->post_disable_dp() hook instead of the MST version. Consequently, we write
to the DP_SET_POWER dpcd to set it D3 state. Further along when we try
enable the encoder in MST mode, POWER_UP_PHY transaction fails to power up
the MST hub. This results in continuous link training failures which keep
the system busy delaying boot. We could identify bios MST boot discrepancy
and handle it accordingly but a simple way to solve this is to write to the
DP_SET_POWER dpcd for MST too.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105470
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reported-by: NLaura Abbott <labbott@redhat.com>
Cc: stable@vger.kernel.org
Fixes: 5ea2355a ("drm/i915/mst: Use MST sideband message transactions for dpms control")
Tested-by: NLaura Abbott <labbott@redhat.com>
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180314054825.1718-1-dhinakaran.pandiyan@intel.com
(cherry picked from commit ad260ab3)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Our shadow context content is from guest but with masked control reg like
CTX_CONTEXT_CONTROL, we need to make sure all settings from guest would be set
when this context is on hw, this trys to force mask enable bits for all to
ensure every bits setting would be effective on hw.

One regression found related to once inhibit bit is set, gpu engine are working
on inhibit state until MI_LOAD_REG_IMM command or context image clear inhibit
bit with mask bit set to 1, and val bit set to 0. In gvt-g currently workload
has the highest priority, so gvt-g workload could trigger preempt context
easily, preempt context set inhibit bit, then gvt-g workload is scheduled in,
but gvt-g workload shadow context image usually doesn't set inhibit mask bit,
so gpu is still in inhibit state when gvt workload is running. This caused gpu
hang.
Suggested-by: NZhang, Xiong <xiong.y.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: NZhang, Xiong <xiong.y.zhang@intel.com>

The PDPs of a shadow page will only be valid after a vGPU mm is pinned.
So the PDPs in the shadow context should be updated then.
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

As different OSes might handling GVT PPGTT creation/destroy notification
differently during a vGPU reset. A better approach is invalidating all
vGPU PPGTT mm objects during vGPU reset.
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Out-of-memory error must be handled correctly.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Trivial fix to spelling mistake in gvt_err error message text.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Reduntant message prints when:
  - linux guest creating.
  - dma-buf win10 guest boot.
  - xonotic stress testing in linux guest.

Add below registers to default MMIO handler:
    0xd00, RPM_CONFIG0
    0xd40, RC6_LOCATION
    0x65010, HSW_AUD_MISC_CTRL
    0x6671c,
    0x700a0, CUR_FBC_CTL
    0x7239c,

v2:
  - Should init i915_reg_t using uint32_t instead of _MMIO macro.
    (compiling errors)
  - Use defined offset in i915_reg.h
    (zhenyu)
Signed-off-by: NColin Xu <colin.xu@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Avoid all the sizeof(drm_color_lut) business by using
drm_color_lut_size() to convert the blob length into
number of LUT entries.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180223192506.29992-6-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that blob->data is void* again we don't need to cast it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180223192506.29992-5-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Arnd Bergman reports:
"""
The conditional spinlock confuses gcc into thinking the 'flags' value
might contain uninitialized data:

drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read':
arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be used uninitialized in this function [-Werror=maybe-uninitialized]

The code is correct, but it's easy to see how the compiler gets confused
here. This avoids the problem by pulling the lock outside of the function
into its only caller.
"""

On deeper look it seems this is caused by paravirt spinlocks
implementation when CONFIG_PARAVIRT_DEBUG is set, which by being
complicated, manages to convince gcc locked parameter can be changed
externally (impossible).

Work around it by removing the conditional locking parameters altogether.
(It was never the most elegant code anyway.)

Slight penalty we now pay is an additional irqsave spin lock/unlock cycle
on the event enable path. But since enable is not a fast path, that is
preferrable to the alternative solution which was doing MMIO under irqsave
spinlock.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reported-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 1fe699e3 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180314080535.17490-1-tvrtko.ursulin@linux.intel.com
(cherry picked from commit ad055fb8)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

tasklet_kill() will spin waiting for the current tasklet to be executed.
However, if tasklet_disable() has been called, then the tasklet is never
executed but permanently put back onto the runlist until
tasklet_enable() is called. Ergo, we cannot use tasklet_kill() inside a
disable/enable pair. This is the case when we call set-wedge from inside
i915_reset(), and another request was submitted to us concurrent to the
reset.

Fixes: 963ddd63 ("drm/i915: Suspend submission tasklets around wedging")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180307134226.25492-6-chris@chris-wilson.co.uk
(cherry picked from commit 68ad3612)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

Similar to the staging around handling of engine->submit_request, we
need to stop adding to the execlists->queue prior to calling
engine->cancel_requests. cancel_requests will move requests from the
queue onto the timeline, so if we add a request onto the queue after that
point, it will be lost.

Fixes: af7a8ffa ("drm/i915: Use rcu instead of stop_machine in set_wedged")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180307134226.25492-5-chris@chris-wilson.co.uk
(cherry picked from commit 47650db0)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

We don't want to preserve the DDI A 4 lane bit on ICL.

Fixes: 3d2011cf ("drm/i915/icl: remove port A/E lane sharing limitation.")
Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@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/20180306104155.3526-1-jani.nikula@intel.com
(cherry picked from commit 1e6aa7e5)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary
arguments that can be removed by creating separate functins.

Create specific functions for these calls to reduce x86/64 defconfig
size by ~20k.

Modify the existing macros to use the specific calls.

new:
$ size -t drivers/gpu/drm/built-in.a | tail -1
1876562	  44542	    995	19220999	 1d5433	(TOTALS)

old:
$ size -t drivers/gpu/drm/built-in.a | tail -1
1897565	  44542	    995	1943102	 1da63e	(TOTALS)

Miscellanea:

o intel_display requires a change to use the specific calls.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/016b5cb84cede20fd0f91ed6965421d99fd5f2ce.1520978414.git.joe@perches.com

This is to fix warning got as:

[ 6730.476938] ------------[ cut here ]------------
[ 6730.476979] Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLAB object 'gvt-g_vgpu_workload' (offset 120, size 4)!
[ 6730.477021] WARNING: CPU: 2 PID: 441 at mm/usercopy.c:81 usercopy_warn+0x7e/0xa0
[ 6730.477042] Modules linked in: tun(E) bridge(E) stp(E) llc(E) kvmgt(E) x86_pkg_temp_thermal(E) vfio_mdev(E) intel_powerclamp(E) mdev(E) coretemp(E) vfio_iommu_type1(E) vfio(E) kvm_intel(E) kvm(E) hid_generic(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) usbhid(E) i915(E) crc32c_intel(E) hid(E) ghash_clmulni_intel(E) pcbc(E) aesni_intel(E) aes_x86_64(E) crypto_simd(E) cryptd(E) glue_helper(E) intel_cstate(E) idma64(E) evdev(E) virt_dma(E) iTCO_wdt(E) intel_uncore(E) intel_rapl_perf(E) intel_lpss_pci(E) sg(E) shpchp(E) mei_me(E) pcspkr(E) iTCO_vendor_support(E) intel_lpss(E) intel_pch_thermal(E) prime_numbers(E) mei(E) mfd_core(E) video(E) acpi_pad(E) button(E) binfmt_misc(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) fscrypto(E) sd_mod(E) e1000e(E) xhci_pci(E) sdhci_pci(E)
[ 6730.477244]  ptp(E) cqhci(E) xhci_hcd(E) pps_core(E) sdhci(E) mmc_core(E) i2c_i801(E) usbcore(E) thermal(E) fan(E)
[ 6730.477276] CPU: 2 PID: 441 Comm: gvt workload 0 Tainted: G            E    4.16.0-rc1-gvt-staging-0213+ #127
[ 6730.477303] Hardware name:  /NUC6i5SYB, BIOS SYSKLi35.86A.0039.2016.0316.1747 03/16/2016
[ 6730.477326] RIP: 0010:usercopy_warn+0x7e/0xa0
[ 6730.477340] RSP: 0018:ffffba6301223d18 EFLAGS: 00010286
[ 6730.477355] RAX: 0000000000000000 RBX: ffff8f41caae9838 RCX: 0000000000000006
[ 6730.477375] RDX: 0000000000000007 RSI: 0000000000000082 RDI: ffff8f41dad166f0
[ 6730.477395] RBP: 0000000000000004 R08: 0000000000000576 R09: 0000000000000000
[ 6730.477415] R10: ffffffffb1293fb2 R11: 00000000ffffffff R12: 0000000000000001
[ 6730.477447] R13: ffff8f41caae983c R14: ffff8f41caae9838 R15: 00007f183ca2b000
[ 6730.477467] FS:  0000000000000000(0000) GS:ffff8f41dad00000(0000) knlGS:0000000000000000
[ 6730.477489] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6730.477506] CR2: 0000559462817291 CR3: 000000028b46c006 CR4: 00000000003626e0
[ 6730.477526] Call Trace:
[ 6730.477537]  __check_object_size+0x9c/0x1a0
[ 6730.477562]  __kvm_write_guest_page+0x45/0x90 [kvm]
[ 6730.477585]  kvm_write_guest+0x46/0x80 [kvm]
[ 6730.477599]  kvmgt_rw_gpa+0x9b/0xf0 [kvmgt]
[ 6730.477642]  workload_thread+0xa38/0x1040 [i915]
[ 6730.477659]  ? do_wait_intr_irq+0xc0/0xc0
[ 6730.477673]  ? finish_wait+0x80/0x80
[ 6730.477707]  ? clean_workloads+0x120/0x120 [i915]
[ 6730.477722]  kthread+0x111/0x130
[ 6730.477733]  ? _kthread_create_worker_on_cpu+0x60/0x60
[ 6730.477750]  ? exit_to_usermode_loop+0x6f/0xb0
[ 6730.477766]  ret_from_fork+0x35/0x40
[ 6730.477777] Code: 48 c7 c0 20 e3 25 b1 48 0f 44 c2 41 50 51 41 51 48 89 f9 49 89 f1 4d 89 d8 4c 89 d2 48 89 c6 48 c7 c7 78 e3 25 b1 e8 b2 bc e4 ff <0f> ff 48 83 c4 18 c3 48 c7 c6 09 d0 26 b1 49 89 f1 49 89 f3 eb
[ 6730.477849] ---[ end trace cae869c1c323e45a ]---

By whitelist guest page write from workload struct allocated from kmem cache.
Reviewed-by: NHang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
(cherry picked from commit 5627705406874df57fdfad3b4e0c9aedd3b007df)

Once the ring buffer is copied to ring_scan_buffer and scanned,
the shadow batch buffer start address is only updated into
ring_scan_buffer, not the real ring address allocated through
intel_ring_begin in later copy_workload_to_ring_buffer.

This patch is only to set the right shadow batch buffer address
from Ring buffer, not include the shadow_wa_ctx.

v2:
- refine some comments. (Zhenyu)
v3:
- fix typo in title. (Zhenyu)
v4:
- remove the unnecessary comments. (Zhenyu)
- add comments in bb_start_cmd_va update. (Zhenyu)

Fixes: 0a53bc07 ("drm/i915/gvt: Separate cmd scan from request allocation")
Cc: stable@vger.kernel.org  # v4.15
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Yulei Zhang <yulei.zhang@intel.com>
Signed-off-by: Nfred gao <fred.gao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The boost frequency is only applied from the RPS worker while someone is
waiting on a request and requested a boost. As such, when the user
wishes to change the frequency, we have to kick the worker in order to
re-evaluate whether to apply the boost frequency.

v2: Check num_waiters to decide if we should kick the worker to handle
boosting.

Fixes: 29ecd78d ("drm/i915: Define a separate variable and control for RPS waitboost frequency")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180308142648.4016-1-chris@chris-wilson.co.uk
(cherry picked from commit 59cd31f1)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Currently, we only allow ourselves to prune the fences so long as
all the waits completed (i.e. all the fences we checked were signaled),
and that the reservation snapshot did not change across the wait.
However, if we only waited for a subset of the reservation object, i.e.
just waiting for the last writer to complete as opposed to all readers
as well, then we would erroneously conclude we could prune the fences as
indeed although all of our waits were successful, they did not represent
the totality of the reservation object.

v2: We only need to check the shared fences due to construction (i.e.
all of the shared fences will be later than the exclusive fence, if
any).

Fixes: e54ca977 ("drm/i915: Remove completed fences after a wait")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180307171303.29466-1-chris@chris-wilson.co.uk
(cherry picked from commit fa73055b)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Currently, BXT_PP is hardcoded with value '0'.
It practically disabled eDP backlight on MRB (BXT) platform.

This patch will tell which BXT_PP registers (there are two set of
PP_CONTROL in the spec) to be used as defined in VBT (Video Bios Timing
table) and this will enabled eDP backlight controller on MRB (BXT)
platform.

v2:
 - Remove unnecessary information in commit message.
 - Assign vbt.backlight.controller to a backlight_controller variable and
   return the variable value.
v3:
 - Rebased to latest code base.
 - updated commit title.
Signed-off-by: NMustamin B Mustaffa <mustamin.b.mustaffa@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180227030734.37901-1-mustamin.b.mustaffa@intel.com
(cherry picked from commit 73c0fcac)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

When populating shadow ctx from guest, we should handle oa related
registers in hw ctx, so that they will not be overlapped by guest oa
configs. This patch made it possible to capture oa data from host for
both host and guests.
Signed-off-by: NMin He <min.he@intel.com>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>

If user continuously create vgpu, boot guest, shoutdown guest and destroy
vgpu from remote, the following calltrace exists in dmesg sometimes:
[ 6412.954721] RPM wakelock ref not held during HW access
[ 6412.954795] WARNING: CPU: 7 PID: 11941 at
linux/drivers/gpu/drm/i915/intel_drv.h:1800
intel_uncore_forcewake_get.part.7+0x96/0xa0 [i915]
[ 6412.954915] Call Trace:
[ 6412.954951] intel_uncore_forcewake_get+0x18/0x20 [i915]
[ 6412.954989] intel_gvt_switch_mmio+0x8e/0x770 [i915]
[ 6412.954996] ? __slab_free+0x14d/0x2c0
[ 6412.955001] ? __slab_free+0x14d/0x2c0
[ 6412.955006] ? __slab_free+0x14d/0x2c0
[ 6412.955041] intel_vgpu_stop_schedule+0x92/0xd0 [i915]
[ 6412.955073] intel_gvt_deactivate_vgpu+0x48/0x60 [i915]
[ 6412.955078] __intel_vgpu_release+0x55/0x260 [kvmgt]

when this happens, gvt_switch_mmio is called at vgpu destroy, host i915 is
idle and doesn't hold RPM wakelock, igd is in powersave mode, but
gvt_switch_mmio require igd power on to access register, so
intel_runtime_pm_get should be added to make sure igd power on before
gvt_switch_mmio.

v2: Move runtime_pm_get/put into gvt_switch_mmio.(Zhenyu)
Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>