linux-stable.git/drivers/gpu, branch v5.4.13 Linux kernel stable tree drm/amdgpu: enable gfxoff for raven1 refresh 2020-01-17T18:49:06+00:00 changzhu Changfeng.Zhu@amd.com 2019-12-12T05:46:06+00:00 f1c5e6abd4495bc54055bf3908ad6baa45d12010 [ Upstream commit e0c63812352298efbce2a71483c1dab627d0c288 ] When smu version is larger than 0x41e2b, it will load raven_kicker_rlc.bin.To enable gfxoff for raven_kicker_rlc.bin,it needs to avoid adev->pm.pp_feature &= ~PP_GFXOFF_MASK when it loads raven_kicker_rlc.bin. Signed-off-by: changzhu <Changfeng.Zhu@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit e0c63812352298efbce2a71483c1dab627d0c288 ]

When smu version is larger than 0x41e2b, it will load
raven_kicker_rlc.bin.To enable gfxoff for raven_kicker_rlc.bin,it
needs to avoid adev->pm.pp_feature &= ~PP_GFXOFF_MASK when it loads
raven_kicker_rlc.bin.

Signed-off-by: changzhu <Changfeng.Zhu@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/arm/mali: make malidp_mw_connector_helper_funcs static 2020-01-17T18:49:05+00:00 Ben Dooks (Codethink) ben.dooks@codethink.co.uk 2019-12-17T11:53:09+00:00 f54802bfc97bff552ec4781293f37f7e26be229e [ Upstream commit ac2917b01992c098b8d4e6837115e3ca347fdd90 ] The malidp_mw_connector_helper_funcs is not referenced by name outside of the file it is in, so make it static to avoid the following warning: drivers/gpu/drm/arm/malidp_mw.c:59:41: warning: symbol 'malidp_mw_connector_helper_funcs' was not declared. Should it be static? Signed-off-by: Ben Dooks (Codethink) <ben.dooks@codethink.co.uk> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191217115309.2133503-1-ben.dooks@codethink.co.uk Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit ac2917b01992c098b8d4e6837115e3ca347fdd90 ]

The malidp_mw_connector_helper_funcs is not referenced by name
outside of the file it is in, so make it static to avoid the
following warning:

drivers/gpu/drm/arm/malidp_mw.c:59:41: warning: symbol 'malidp_mw_connector_helper_funcs' was not declared. Should it be static?

Signed-off-by: Ben Dooks (Codethink) <ben.dooks@codethink.co.uk>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191217115309.2133503-1-ben.dooks@codethink.co.uk
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/amdgpu/discovery: reserve discovery data at the top of VRAM 2020-01-17T18:48:51+00:00 Xiaojie Yuan xiaojie.yuan@amd.com 2019-10-10T12:44:20+00:00 0b1eb4058b951daff81ed7d1092b74c8d229a37b commit 5f6a556f98de425fcb7928456839a06f02156633 upstream. IP Discovery data is TMR fenced by the latest PSP BL, so we need to reserve this region. Tested on navi10/12/14 with VBIOS integrated with latest PSP BL. v2: use DISCOVERY_TMR_SIZE macro as bo size use amdgpu_bo_create_kernel_at() to allocate bo Signed-off-by: Xiaojie Yuan <xiaojie.yuan@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 5f6a556f98de425fcb7928456839a06f02156633 upstream.

IP Discovery data is TMR fenced by the latest PSP BL,
so we need to reserve this region.

Tested on navi10/12/14 with VBIOS integrated with latest PSP BL.

v2: use DISCOVERY_TMR_SIZE macro as bo size
    use amdgpu_bo_create_kernel_at() to allocate bo

Signed-off-by: Xiaojie Yuan <xiaojie.yuan@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/amdgpu: cleanup creating BOs at fixed location (v2) 2020-01-17T18:48:51+00:00 Christian König christian.koenig@amd.com 2019-09-13T11:43:15+00:00 1601575529051ee903105054683d202929e07ad5 commit de7b45babd9be25138ff5e4a0c34eefffbb226ff upstream. The placement is something TTM/BO internal and the RAS code should avoid touching that directly. Add a helper to create a BO at a fixed location and use that instead. v2: squash in fixes (Alex) Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit de7b45babd9be25138ff5e4a0c34eefffbb226ff upstream.

The placement is something TTM/BO internal and the RAS code should
avoid touching that directly.

Add a helper to create a BO at a fixed location and use that instead.

v2: squash in fixes (Alex)

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Guchun Chen <guchun.chen@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "drm/virtio: switch virtio_gpu_wait_ioctl() to gem helper." 2020-01-17T18:48:51+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2020-01-16T19:37:53+00:00 7f57b0b34e21921eda7d56c41a7c82050f7134c8 This reverts commit e6733ec8948475c4b62574e452135dc629294d75 which is commit 29cf12394c0565d7eb1685bf0c1b4749aa6a8b66 upstream. Alistair writes: After updating to 5.4.7 we noticed that virtio_gpu's wait ioctl stopped working correctly. It looks like 29cf12394c05 ("drm/virtio: switch virtio_gpu_wait_ioctl() to gem helper.") was picked up automatically, but it depends on 889165ad6190 ("drm/virtio: pass gem reservation object to ttm init") from earlier in Gerd's series in Linus's tree, which was not picked up. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chia-I Wu <olvaffe@gmail.com> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This reverts commit e6733ec8948475c4b62574e452135dc629294d75 which is
commit 29cf12394c0565d7eb1685bf0c1b4749aa6a8b66 upstream.

Alistair writes:
	After updating to 5.4.7 we noticed that virtio_gpu's wait ioctl
	stopped working correctly.

	It looks like 29cf12394c05 ("drm/virtio: switch
	virtio_gpu_wait_ioctl() to gem helper.") was picked up automatically,
	but it depends on 889165ad6190 ("drm/virtio: pass gem reservation
	object to ttm init") from earlier in Gerd's series in Linus's tree,
	which was not picked up.

Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chia-I Wu <olvaffe@gmail.com>
Cc: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/tegra: Fix ordering of cleanup code 2020-01-17T18:48:23+00:00 Thierry Reding treding@nvidia.com 2019-09-25T11:26:59+00:00 0d03645bc4318fb5488ec5671ab3d2d64cd45c3a commit 051172e8c1ceef8749f19faacc1d3bef65d20d8d upstream. Commit Fixes: b9f8b09ce256 ("drm/tegra: Setup shared IOMMU domain after initialization") changed the initialization order of the IOMMU related bits but didn't update the cleanup path accordingly. This asymmetry can cause failures during error recovery. Fixes: b9f8b09ce256 ("drm/tegra: Setup shared IOMMU domain after initialization") Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 051172e8c1ceef8749f19faacc1d3bef65d20d8d upstream.

Commit Fixes: b9f8b09ce256 ("drm/tegra: Setup shared IOMMU domain after
initialization") changed the initialization order of the IOMMU related
bits but didn't update the cleanup path accordingly. This asymmetry can
cause failures during error recovery.

Fixes: b9f8b09ce256 ("drm/tegra: Setup shared IOMMU domain after initialization")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/i915/gen9: Clear residual context state on context switch 2020-01-14T19:08:40+00:00 Akeem G Abodunrin akeem.g.abodunrin@intel.com 2020-01-08T17:34:16+00:00 53b9bd37af59d1def99b20707536105857eb9bd0 commit bc8a76a152c5f9ef3b48104154a65a68a8b76946 upstream. Intel ID: PSIRT-TA-201910-001 CVEID: CVE-2019-14615 Intel GPU Hardware prior to Gen11 does not clear EU state during a context switch. This can result in information leakage between contexts. For Gen8 and Gen9, hardware provides a mechanism for fast cleardown of the EU state, by issuing a PIPE_CONTROL with bit 27 set. We can use this in a context batch buffer to explicitly cleardown the state on every context switch. As this workaround is already in place for gen8, we can borrow the code verbatim for Gen9. Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Cc: Kumar Valsan Prathap <prathap.kumar.valsan@intel.com> Cc: Chris Wilson <chris.p.wilson@intel.com> Cc: Balestrieri Francesco <francesco.balestrieri@intel.com> Cc: Bloomfield Jon <jon.bloomfield@intel.com> Cc: Dutt Sudeep <sudeep.dutt@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit bc8a76a152c5f9ef3b48104154a65a68a8b76946 upstream.

Intel ID: PSIRT-TA-201910-001
CVEID: CVE-2019-14615

Intel GPU Hardware prior to Gen11 does not clear EU state
during a context switch. This can result in information
leakage between contexts.

For Gen8 and Gen9, hardware provides a mechanism for
fast cleardown of the EU state, by issuing a PIPE_CONTROL
with bit 27 set. We can use this in a context batch buffer
to explicitly cleardown the state on every context switch.

As this workaround is already in place for gen8, we can borrow
the code verbatim for Gen9.

Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Cc: Kumar Valsan Prathap <prathap.kumar.valsan@intel.com>
Cc: Chris Wilson <chris.p.wilson@intel.com>
Cc: Balestrieri Francesco <francesco.balestrieri@intel.com>
Cc: Bloomfield Jon <jon.bloomfield@intel.com>
Cc: Dutt Sudeep <sudeep.dutt@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/i915/gt: Mark up virtual engine uabi_instance 2020-01-14T19:08:26+00:00 Chris Wilson chris@chris-wilson.co.uk 2020-01-06T12:39:21+00:00 e1a17ea063a8bf0d735dbd477694857a1b3f4690 commit 1325008f5c8dbc84aa835d98af8447fa0569bc4d upstream. Be sure to initialise the uabi_instance on the virtual engine to the special invalid value, just in case we ever peek at it from the uAPI. Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 750e76b4f9f6 ("drm/i915/gt: Move the [class][inst] lookup for engines onto the GT") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.4+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200106123921.2543886-1-chris@chris-wilson.co.uk (cherry picked from commit f75fc37b5e70b75f21550410f88e2379648120e2) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 1325008f5c8dbc84aa835d98af8447fa0569bc4d upstream.

Be sure to initialise the uabi_instance on the virtual engine to the
special invalid value, just in case we ever peek at it from the uAPI.

Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: 750e76b4f9f6 ("drm/i915/gt: Move the [class][inst] lookup for engines onto the GT")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: <stable@vger.kernel.org> # v5.4+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200106123921.2543886-1-chris@chris-wilson.co.uk
(cherry picked from commit f75fc37b5e70b75f21550410f88e2379648120e2)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/i915: Add Wa_1407352427:icl,ehl 2020-01-14T19:08:26+00:00 Matt Roper matthew.d.roper@intel.com 2019-12-31T19:07:13+00:00 843f6795576ee240e05f53ffbf2353d677268d4b commit 25b79ad51bf04a8aa67b5bccd631fc05f963b8e0 upstream. The workaround database now indicates we need to disable psdunit clock gating as well. v3: - Rebase on top of other workarounds that have landed. - Restrict cc:stable tag to 5.2+ since that's when ICL was first officially supported. Bspec: 32354 Bspec: 33450 Bspec: 33451 Suggested-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: stable@vger.kernel.org # v5.2+ Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191231190713.1549533-1-matthew.d.roper@intel.com (cherry picked from commit 1cd21a7c5679015352e8a6f46813aced51d71bb8) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 25b79ad51bf04a8aa67b5bccd631fc05f963b8e0 upstream.

The workaround database now indicates we need to disable psdunit clock
gating as well.

v3:
 - Rebase on top of other workarounds that have landed.
 - Restrict cc:stable tag to 5.2+ since that's when ICL was first
   officially supported.

Bspec: 32354
Bspec: 33450
Bspec: 33451
Suggested-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: stable@vger.kernel.org # v5.2+
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191231190713.1549533-1-matthew.d.roper@intel.com
(cherry picked from commit 1cd21a7c5679015352e8a6f46813aced51d71bb8)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ 2020-01-14T19:08:25+00:00 Wayne Lin Wayne.Lin@amd.com 2020-01-03T05:50:01+00:00 59aa28fcf770605911f176a0715fe4c840e84f8a commit c4e4fccc5d52d881afaac11d3353265ef4eccb8b upstream. [Why] According to DP spec, it should shift left 4 digits for NO_STOP_BIT in REMOTE_I2C_READ message. Not 5 digits. In current code, NO_STOP_BIT is always set to zero which means I2C master is always generating a I2C stop at the end of each I2C write transaction while handling REMOTE_I2C_READ sideband message. This issue might have the generated I2C signal not meeting the requirement. Take random read in I2C for instance, I2C master should generate a repeat start to start to read data after writing the read address. This issue will cause the I2C master to generate a stop-start rather than a re-start which is not expected in I2C random read. [How] Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in drm_dp_encode_sideband_req(). Changes since v1:(https://patchwork.kernel.org/patch/11312667/) * Add more descriptions in commit and cc to stable Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200103055001.10287-1-Wayne.Lin@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit c4e4fccc5d52d881afaac11d3353265ef4eccb8b upstream.

[Why]
According to DP spec, it should shift left 4 digits for NO_STOP_BIT
in REMOTE_I2C_READ message. Not 5 digits.

In current code, NO_STOP_BIT is always set to zero which means I2C
master is always generating a I2C stop at the end of each I2C write
transaction while handling REMOTE_I2C_READ sideband message. This issue
might have the generated I2C signal not meeting the requirement. Take
random read in I2C for instance, I2C master should generate a repeat
start to start to read data after writing the read address. This issue
will cause the I2C master to generate a stop-start rather than a
re-start which is not expected in I2C random read.

[How]
Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in
drm_dp_encode_sideband_req().

Changes since v1:(https://patchwork.kernel.org/patch/11312667/)
* Add more descriptions in commit and cc to stable

Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)")
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200103055001.10287-1-Wayne.Lin@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>