kernel/linux.git/drivers/gpu/drm/radeon, branch linux-4.20.y

drm/radeon: check if device is root before getting pci speed caps

2019-03-13T21:04:12+00:00

[ Upstream commit afeff4c16edaa6275b903f82b0561406259aa3a3 ] Check if the device is root rather before attempting to see what speeds the pcie port supports. Fixes a crash with pci passthrough in a VM. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109366 Reviewed-by: Evan Quan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

gpu: drm: radeon: Set DPM_FLAG_NEVER_SKIP when enabling PM-runtime

2019-02-27T09:09:55+00:00

commit 450d007d199e632a1a4c4b91302deacd7d56815f upstream. On HP ProBook 4540s, if PM-runtime is enabled in the radeon driver and the direct-complete optimization is used for the radeon device during system-wide suspend, the system doesn't resume. Preventing direct-complete from being used with the radeon device by setting the DPM_FLAG_NEVER_SKIP driver flag for it makes the problem go away, which indicates that direct-complete is not safe for the radeon driver in general and should not be used with it (at least for now). This fixes a regression introduced by commit c62ec4610c40 ("PM / core: Fix direct_complete handling for devices with no callbacks") which allowed direct-complete to be applied to devices without PM callbacks (again) which in turn unlocked direct-complete for radeon on HP ProBook 4540s. Fixes: c62ec4610c40 ("PM / core: Fix direct_complete handling for devices with no callbacks") Link: https://bugzilla.kernel.org/show_bug.cgi?id=201519 Reported-by: Ярослав Семченко Tested-by: Ярослав Семченко Signed-off-by: Rafael J. Wysocki Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/radeon: change SPDX identifier to MIT

2018-10-15T21:16:12+00:00

Commit b24413180f5600bcb3bb70fbed5cf186b60864bd added "SPDX-License-Identifier: GPL-2.0" to files which previously had no license, change this to MIT for radeon matching the license text of the other radeon files. Signed-off-by: Jonathan Gray Signed-off-by: Alex Deucher

drm/radeon: ratelimit bo warnings

2018-10-09T22:07:12+00:00

So a few days ago I started getting sprays of these warnings -- sorry, but because it was a few days ago I'm not sure what I was running at the time (but it was probably either Stellaris or Chromium). Sep 25 22:06:34 mutilate err: : [ 544.718905] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xc Sep 25 22:06:34 mutilate err: : [ 544.718909] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! Sep 25 22:06:34 mutilate err: : [ 544.719710] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xc Sep 25 22:06:34 mutilate err: : [ 544.719714] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! Sep 25 22:06:34 mutilate err: : [ 544.719862] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xc Sep 25 22:06:34 mutilate err: : [ 544.719865] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! Sep 25 22:06:34 mutilate err: : [ 544.720772] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xc Sep 25 22:06:34 mutilate err: : [ 544.720778] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! Sep 25 22:06:34 mutilate warning: : [ 544.721415] radeon 0000:01:00.0: vbo resource seems too big for the bo followed by a massive stream of "vbo resource seems too big for the bo". The most extreme flood ran from 23:01:58 to 23:02:47 and emitted 91,000 lines of log in that time. This... seems excessive, given that each log message after the first contains more or less no information. So ratelimit these messages. (We probably want to see at least *some* so that the underlying bug can be fixed -- always assuming the bug isn't in unfixable closed-source game code somewhere.) Signed-off-by: Nick Alcock Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher

Merge branch 'drm-next-4.20' of git://people.freedesktop.org/~agd5f/linux into drm-next

2018-09-20T23:52:53+00:00

This is a new pull for drm-next on top of last weeks with the following changes: - Fixed 64 bit divide - Fixed vram type on vega20 - Misc vega20 fixes - Misc DC fixes - Fix GDS/GWS/OA domain handling Previous changes from last week: amdgpu/kfd: - Picasso (new APU) support - Raven2 (new APU) support - Vega20 enablement - ACP powergating improvements - Add ABGR/XBGR display support - VCN JPEG engine support - Initial xGMI support - Use load balancing for engine scheduling - Lots of new documentation - Rework and clean up i2c and aux handling in DC - Add DP YCbCr 4:2:0 support in DC - Add DMCU firmware loading for Raven (used for ABM and PSR) - New debugfs features in DC - LVDS support in DC - Implement wave kill for gfx/compute (light weight reset for shaders) - Use AGP aperture to avoid gart mappings when possible - GPUVM performance improvements - Bulk moves for more efficient GPUVM LRU handling - Merge amdgpu and amdkfd into one module - Enable gfxoff and stutter mode on Raven - Misc cleanups Scheduler: - Load balancing support - Bug fixes ttm: - Bulk move functionality - Bug fixes radeon: - Misc cleanups Signed-off-by: Dave Airlie From: Alex Deucher Link: https://patchwork.freedesktop.org/patch/msgid/20180920150438.12693-1-alexander.deucher@amd.com

drm/radeon: change function signature to pass full range

2018-09-19T17:37:25+00:00

In function ‘radeon_process_i2c_ch’ a comparison of a u8 value against 255 is done. Since it is always false, change the signature of this function to use an `int` instead, which match the type used in caller: `radeon_atom_hw_i2c_xfer`. Fix the following warning triggered with W=1: CC [M] drivers/gpu/drm/radeon/atombios_i2c.o drivers/gpu/drm/radeon/atombios_i2c.c: In function ‘radeon_process_i2c_ch’: drivers/gpu/drm/radeon/atombios_i2c.c:71:11: warning: comparison is always false due to limited range of data type [-Wtype-limits] if (num > ATOM_MAX_HW_I2C_READ) { ^ Reviewed-by: Huang Rui Signed-off-by: Mathieu Malaterre Signed-off-by: Alex Deucher

drm/radeon: use simpler remove_conflicting_pci_framebuffers()

2018-09-03T16:17:20+00:00

Signed-off-by: Michał Mirosław Acked-by: Alex Deucher Acked-by: Daniel Vetter Acked-by: Bartlomiej Zolnierkiewicz Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/b61a2e458b6a2964039693d724cc75b4fcfb3ddb.1535810304.git.mirq-linux@rere.qmqm.pl

drm/radeon: Do not evict VRAM on APUs with disabled HIBERNATE

2018-08-27T16:11:04+00:00

Improve commit d796d844 (drm/radeon/kms: make hibernate work on IGPs) to only migrate VRAM objects if the Linux kernel is actually built with support for hibernation (suspend to disk). Link: https://bugs.freedesktop.org/show_bug.cgi?id=100941 Signed-off-by: Paul Menzel Signed-off-by: Alex Deucher

drm/radeon: enable ABGR and XBGR formats (v2)

2018-08-27T16:10:19+00:00

Add support for DRM_FORMAT_{A,X}BGR8888 in atombios_crtc Swapping of red and blue channels is implemented for radeon chipsets: DCE2/R6xx and later - crossbar registers defined where needed and used DCE1/R5xx - AVIVO_D1GRPH_SWAP_RB bit is used (v2) Set AVIVO_D1GRPH_SWAP_RB bit in fb_format, using bitwise OR for DCE1 path Use bitwise OR where required for big endian settings in fb_swap Use existing code style CHIP_R600 condition, fix typo in R600 blue crossbar Signed-off-by: Mauro Rossi Signed-off-by: Alex Deucher

gpu: drm: radeon: radeon_test: Replace mdelay() with msleep()

2018-08-27T16:10:02+00:00

radeon_test_ring_sync() and radeon_test_ring_sync2() are never called in atomic context. They call mdelay() to busily wait, which is not necessary. mdelay() can be replaced with msleep(). This is found by a static analysis tool named DCNS written by myself. Signed-off-by: Jia-Ju Bai Signed-off-by: Alex Deucher