linux.git/drivers/gpu, branch v4.14.149

drm/amdgpu: Check for valid number of registers to read

2019-10-11T16:18:40+00:00

[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]

Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15 (0x2644-0x2673).

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=111273
Signed-off-by: Trek 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/omap: fix max fclk divider for omap36xx

2019-10-11T16:18:35+00:00

commit e2c4ed148cf3ec8669a1d90dc66966028e5fad70 upstream.

The OMAP36xx and AM/DM37x TRMs say that the maximum divider for DSS fclk
(in CM_CLKSEL_DSS) is 32. Experimentation shows that this is not
correct, and using divider of 32 breaks DSS with a flood or underflows
and sync losts. Dividers up to 31 seem to work fine.

There is another patch to the DT files to limit the divider correctly,
but as the DSS driver also needs to know the maximum divider to be able
to iteratively find good rates, we also need to do the fix in the DSS
driver.

Signed-off-by: Tomi Valkeinen 
Cc: Adam Ford 
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20191002122542.8449-1-tomi.valkeinen@ti.com
Tested-by: Adam Ford 
Reviewed-by: Jyri Sarha 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu/si: fix ASIC tests

2019-10-07T16:55:04+00:00

[ Upstream commit 77efe48a729588527afb4d5811b9e0acb29f5e51 ]

Comparing adev->family with CHIP constants is not correct.
adev->family can only be compared with AMDGPU_FAMILY constants and
adev->asic_type is the struct member to compare with CHIP constants.
They are separate identification spaces.

Signed-off-by: Jean Delvare 
Fixes: 62a37553414a ("drm/amdgpu: add si implementation v10")
Cc: Ken Wang 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: "David (ChunMing) Zhou" 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/nouveau/volt: Fix for some cards having 0 maximum voltage

2019-10-07T16:55:04+00:00

[ Upstream commit a1af2afbd244089560794c260b2d4326a86e39b6 ]

Some, mostly Fermi, vbioses appear to have zero max voltage. That causes Nouveau to not parse voltage entries, thus users not being able to set higher clocks.

When changing this value Nvidia driver still appeared to ignore it, and I wasn't able to find out why, thus the code is ignoring the value if it is zero.

CC: Maarten Lankhorst 
Signed-off-by: Mark Menzynski 
Reviewed-by: Karol Herbst 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin

gpu: drm: radeon: Fix a possible null-pointer dereference in radeon_connector_set_property()

2019-10-07T16:54:59+00:00

[ Upstream commit f3eb9b8f67bc28783eddc142ad805ebdc53d6339 ]

In radeon_connector_set_property(), there is an if statement on line 743
to check whether connector->encoder is NULL:
    if (connector->encoder)

When connector->encoder is NULL, it is used on line 755:
    if (connector->encoder->crtc)

Thus, a possible null-pointer dereference may occur.

To fix this bug, connector->encoder is checked before being used.

This bug is found by a static analysis tool STCheck written by us.

Signed-off-by: Jia-Ju Bai 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/radeon: Fix EEH during kexec

2019-10-07T16:54:58+00:00

[ Upstream commit 6f7fe9a93e6c09bf988c5059403f5f88e17e21e6 ]

During kexec some adapters hit an EEH since they are not properly
shut down in the radeon_pci_shutdown() function. Adding
radeon_suspend_kms() fixes this issue.

Signed-off-by: KyleMahlkuch 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/stm: attach gem fence to atomic state

2019-10-07T16:54:58+00:00

[ Upstream commit 8fabc9c3109a71b3577959a05408153ae69ccd8d ]

To properly synchronize with other devices the fence from the GEM
object backing the framebuffer needs to be attached to the atomic
state, so the commit work can wait on fence signaling.

Signed-off-by: Ahmad Fatoum 
Signed-off-by: Lucas Stach 
Acked-by: Philippe Cornu 
Tested-by: Philippe Cornu 
Signed-off-by: Benjamin Gaignard 
Link: https://patchwork.freedesktop.org/patch/msgid/20190712084228.8338-1-l.stach@pengutronix.de
Signed-off-by: Sasha Levin

drm/panel: simple: fix AUO g185han01 horizontal blanking

2019-10-07T16:54:57+00:00

[ Upstream commit f8c6bfc612b56f02e1b8fae699dff12738aaf889 ]

The horizontal blanking periods are too short, as the values are
specified for a single LVDS channel. Since this panel is dual LVDS
they need to be doubled. With this change the panel reaches its
nominal vrefresh rate of 60Fps, instead of the 64Fps with the
current wrong blanking.

Philipp Zabel added:
The datasheet specifies 960 active clocks + 40/128/160 clocks blanking
on each of the two LVDS channels (min/typical/max), so doubled this is
now correct.

Signed-off-by: Lucas Stach 
Reviewed-by: Philipp Zabel 
Reviewed-by: Sam Ravnborg 
Signed-off-by: Sam Ravnborg 
Link: https://patchwork.freedesktop.org/patch/msgid/1562764060.23869.12.camel@pengutronix.de
Signed-off-by: Sasha Levin

drm/bridge: tc358767: Increase AUX transfer length limit

2019-10-07T16:54:57+00:00

[ Upstream commit e0655feaec62d5139b6b13a7b1bbb1ab8f1c2d83 ]

According to the datasheet tc358767 can transfer up to 16 bytes via
its AUX channel, so the artificial limit of 8 appears to be too
low. However only up to 15-bytes seem to be actually supported and
trying to use 16-byte transfers results in transfers failing
sporadically (with bogus status in case of I2C transfers), so limit it
to 15.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Andrzej Hajda 
Reviewed-by: Tomi Valkeinen 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: Tomi Valkeinen 
Cc: Andrey Gusakov 
Cc: Philipp Zabel 
Cc: Cory Tusar 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrzej Hajda 
Link: https://patchwork.freedesktop.org/patch/msgid/20190619052716.16831-9-andrew.smirnov@gmail.com
Signed-off-by: Sasha Levin

drm/amd/powerplay/smu7: enforce minimal VBITimeout (v2)

2019-10-05T10:48:03+00:00

[ Upstream commit f659bb6dae58c113805f92822e4c16ddd3156b79 ]

This fixes screen corruption/flickering on 75 Hz displays.

v2: make print statement debug only (Alex)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102646
Reviewed-by: Evan Quan 
Signed-off-by: Ahzo 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin