linux-stable.git/drivers/gpu/drm, branch v4.14.72

drm/i915: Apply the GTT write flush for all !llc machines

2018-09-26T06:38:14+00:00

commit c5ba5b24657e473b1c64b0a614b168a635a2c935 upstream.

We also see the delayed GTT write issue on i915g/i915gm, so let's
presume that it is a universal problem for all !llc machines, and that we
just haven't yet noticed on g33, gen4 and gen5 machines.

v2: Use a register that exists on all platforms

Testcase: igt/gem_mmap_gtt/coherency # i915gm
References: https://bugs.freedesktop.org/show_bug.cgi?id=102577
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20170907184520.5032-1-chris@chris-wilson.co.uk
Reviewed-by: Ville Syrjälä 
Signed-off-by: Sudip Mukherjee 
Signed-off-by: Greg Kroah-Hartman

drm/panel: type promotion bug in s6e8aa0_read_mtp_id()

2018-09-26T06:38:13+00:00

[ Upstream commit cd0e0ca69109d025b1a1b6609f70682db62138b0 ]

The ARRAY_SIZE() macro is type size_t.  If s6e8aa0_dcs_read() returns a
negative error code, then "ret < ARRAY_SIZE(id)" is false because the
negative error code is type promoted to a high positive value.

Fixes: 02051ca06371 ("drm/panel: add S6E8AA0 driver")
Signed-off-by: Dan Carpenter 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Thierry Reding 
Link: https://patchwork.freedesktop.org/patch/msgid/20180704093807.s3lqsb2v6dg2k43d@kili.mountain
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/amdkfd: Fix error codes in kfd_get_process

2018-09-26T06:38:12+00:00

[ Upstream commit e47cb828eb3fca3e8999a0b9aa053dda18552071 ]

Return ERR_PTR(-EINVAL) if kfd_get_process fails to find the process.
This fixes kernel oopses when a child process calls KFD ioctls with
a file descriptor inherited from the parent process.

Signed-off-by: Wei Lu 
Reviewed-by: Felix Kuehling 
Signed-off-by: Felix Kuehling 
Acked-by: Christian König 
Signed-off-by: Oded Gabbay 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

2018-09-26T06:38:11+00:00

[ Upstream commit b59fb482b52269977ee5de205308e5b236a03917 ]

Depending on the kernel configuration, early ARM architecture setup code
may have attached the GPU to a DMA/IOMMU mapping that transparently uses
the IOMMU to back the DMA API. Tegra requires special handling for IOMMU
backed buffers (a special bit in the GPU's MMU page tables indicates the
memory path to take: via the SMMU or directly to the memory controller).
Transparently backing DMA memory with an IOMMU prevents Nouveau from
properly handling such memory accesses and causes memory access faults.

As a side-note: buffers other than those allocated in instance memory
don't need to be physically contiguous from the GPU's perspective since
the GPU can map them into contiguous buffers using its own MMU. Mapping
these buffers through the IOMMU is unnecessary and will even lead to
performance degradation because of the additional translation. One
exception to this are compressible buffers which need large pages. In
order to enable these large pages, multiple small pages will have to be
combined into one large (I/O virtually contiguous) mapping via the
IOMMU. However, that is a topic outside the scope of this fix and isn't
currently supported. An implementation will want to explicitly create
these large pages in the Nouveau driver, so detaching from a DMA/IOMMU
mapping would still be required.

Signed-off-by: Thierry Reding 
Acked-by: Christoph Hellwig 
Reviewed-by: Robin Murphy 
Tested-by: Nicolas Chauvet 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/debugfs: Wake up GPU before doing any reclocking

2018-09-26T06:38:11+00:00

[ Upstream commit eaeb9010bb4bcdc20e58254fa42f3fe730a7f908 ]

Fixes various reclocking related issues on prime systems.

Signed-off-by: Karol Herbst 
Signed-off-by: Martin Peres 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau: Fix runtime PM leak in drm_open()

2018-09-26T06:38:11+00:00

[ Upstream commit 922a8c82fafdec99688bbaea6c5889f562a42cdc ]

Noticed this as I was skimming through, if we fail to allocate memory
for cli we'll end up returning without dropping the runtime PM ref we
got. Additionally, we'll even return the wrong return code! (ret most
likely will == 0 here, we want -ENOMEM).

Signed-off-by: Lyude Paul 
Reviewed-by: Lukas Wunner 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/i915: set DP Main Stream Attribute for color range on DDI platforms

2018-09-19T20:43:45+00:00

commit 6209c285e7a5e68dbcdf8fd2456c6dd68433806b upstream.

Since Haswell we have no color range indication either in the pipe or
port registers for DP. Instead, there's a separate register for setting
the DP Main Stream Attributes (MSA) directly. The MSA register
definition makes no references to colorimetry, just a vague reference to
the DP spec. The connection to the color range was lost.

Apparently we've failed to set the proper MSA bit for limited, or CEA,
range ever since the first DDI platforms. We've started setting other
MSA parameters since commit dae847991a43 ("drm/i915: add
intel_ddi_set_pipe_settings").

Without the crucial bit of information, the DP sink has no way of
knowing the source is actually transmitting limited range RGB, leading
to "washed out" colors. With the colorimetry information, compliant
sinks should be able to handle the limited range properly. Native
(i.e. non-LSPCON) HDMI was not affected because we do pass the color
range via AVI infoframes.

Though not the root cause, the problem was made worse for DDI platforms
with commit 55bc60db5988 ("drm/i915: Add "Automatic" mode for the
"Broadcast RGB" property"), which selects limited range RGB
automatically based on the mode, as per the DP, HDMI and CEA specs.

After all these years, the fix boils down to flipping one bit.

[Per testing reports, this fixes DP sinks, but not the LSPCON. My
 educated guess is that the LSPCON fails to turn the CEA range MSA into
 AVI infoframes for HDMI.]

Reported-by: Michał Kopeć 
Reported-by: N. W. 
Reported-by: Nicholas Stommel 
Reported-by: Tom Yan 
Tested-by: Nicholas Stommel 
References: https://bugs.freedesktop.org/show_bug.cgi?id=100023
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107476
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94921
Cc: Paulo Zanoni 
Cc: Rodrigo Vivi 
Cc: Ville Syrjälä 
Cc:  # v3.9+
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Jani Nikula 
Link: https://patchwork.freedesktop.org/patch/msgid/20180814060001.18224-1-jani.nikula@intel.com
(cherry picked from commit dc5977da99ea28094b8fa4e9bacbd29bedc41de5)
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Increase LSPCON timeout

2018-09-15T07:45:35+00:00

commit 299c2a904b1e8d5096d4813df6371357d97a6cd1 upstream.

100 ms is not enough time for the LSPCON adapter on Intel NUC devices to
settle. This causes dropped display modes at boot or screen reconfiguration.
Empirical testing can reproduce the error up to a timeout of 190 ms. Basic
boot and stress testing at 200 ms has not (yet) failed.

Increase timeout to 400 ms to get some margin of error.

Changes from v1:
The initial suggestion of 1000 ms was lowered due to concerns about delaying
valid timeout cases.
Update patch metadata.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107503
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1570392
Fixes: 357c0ae9198a ("drm/i915/lspcon: Wait for expected LSPCON mode to settle")
Cc: Shashank Sharma 
Cc: Imre Deak 
Cc: Jani Nikula 
Cc:  # v4.11+
Reviewed-by: Rodrigo Vivi 
Reviewed-by: Shashank Sharma 
Signed-off-by: Fredrik Schön 
Signed-off-by: Jani Nikula 
Link: https://patchwork.freedesktop.org/patch/msgid/20180817200728.8154-1-fredrik.schon@gmail.com
(cherry picked from commit 59f1c8ab30d6f9042562949f42cbd3f3cf69de94)
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Shashank Sharma 
Signed-off-by: Fredrik Schön 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu:add VCN booting with firmware loaded by PSP

2018-09-15T07:45:34+00:00

commit 4d77c0f676e910fb1f1870738aa4bd168f253621 upstream.

Setup psp firmware loading for VCN, and make VCN block
booting from tmr mac address.

Signed-off-by: James Zhu 
Reviewed-by: Alex Deucher 
Acked-by: Huang Rui 
Reviewed-by: Likun Gao 
Signed-off-by: Likun Gao 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu:add VCN support in PSP driver

2018-09-15T07:45:34+00:00

commit 235ac9de625a0a586093ad81b3de6f7d7ab913ed upstream.

Add VCN support in PSP driver

Signed-off-by: James Zhu 
Reviewed-by: Alex Deucher 
Acked-by: Huang Rui 
Reviewed-by: Likun Gao 
Signed-off-by: Likun Gao 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman