kernel/drivers/gpu/drm/radeon/r600.c, branch linux-4.17.y

drm/radeon: Unbreak HPD handling for r600+

2017-05-24T20:46:43Z

We end up reading the interrupt register for HPD5, and then writing it to HPD6 which on systems without anything using HPD5 results in permanently disabling hotplug on one of the display outputs after the first time we acknowledge a hotplug interrupt from the GPU. This code is really bad. But for now, let's just fix this. I will hopefully have a large patch series to refactor all of this soon. Reviewed-by: Christian König Signed-off-by: Lyude Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher

gpu: drm: amd/radeon: Convert printk(KERN_ to pr_

2017-03-30T03:53:24Z

Use a more common logging style. Miscellanea: o Coalesce formats and realign arguments o Neaten a few macros now using pr_ Signed-off-by: Joe Perches Signed-off-by: Alex Deucher

drm/radeon: squash lines for simple wrapper functions

2016-09-15T14:39:37Z

Remove unneeded variables and assignments. Reviewed-by: Gustavo Padovan Signed-off-by: Masahiro Yamada Signed-off-by: Sean Paul Link: http://patchwork.freedesktop.org/patch/msgid/1473863952-7658-3-git-send-email-yamada.masahiro@socionext.com

drm/radeon: switch UVD code to use UVD_NO_OP for padding

2016-08-24T20:25:05Z

Replace packet2's with packet0 writes to UVD_NO_OP. The value written to UVD_NO_OP does not matter. Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/radeon: don't include RADEON_HPD_NONE in HPD IRQ enable bitsets

2016-05-02T19:25:40Z

The values of all but the RADEON_HPD_NONE members of the radeon_hpd_id enum transform 1:1 into bit positions within the 'enabled' bitset as assembled by evergreen_hpd_init(): enabled |= 1 << radeon_connector->hpd.hpd; However, if ->hpd.hpd happens to equal RADEON_HPD_NONE == 0xff, UBSAN reports UBSAN: Undefined behaviour in drivers/gpu/drm/radeon/evergreen.c:1867:16 shift exponent 255 is too large for 32-bit type 'int' [...] Call Trace: [] dump_stack+0xbc/0x117 [] ? _atomic_dec_and_lock+0x169/0x169 [] ubsan_epilogue+0xd/0x4e [] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254 [] ? atom_execute_table+0x3e/0x50 [radeon] [] ? __ubsan_handle_load_invalid_value+0x158/0x158 [] ? radeon_get_pll_use_mask+0x130/0x130 [radeon] [] ? wake_up_klogd_work_func+0x60/0x60 [] ? vprintk_default+0x3e/0x60 [] evergreen_hpd_init+0x274/0x2d0 [radeon] [] ? evergreen_hpd_init+0x274/0x2d0 [radeon] [] radeon_modeset_init+0x8ce/0x18d0 [radeon] [] radeon_driver_load_kms+0x186/0x350 [radeon] [] drm_dev_register+0xc6/0x100 [drm] [] drm_get_pci_dev+0xe4/0x490 [drm] [] ? kfree+0x220/0x370 [] radeon_pci_probe+0x112/0x140 [radeon] [...] ===================================================================== radeon 0000:01:00.0: No connectors reported connected with modes At least on x86, there should be no user-visible impact as there 1 << 0xff == 1 << (0xff & 31) == 1 << 31 holds and 31 > RADEON_MAX_HPD_PINS. Thus, this patch is a cosmetic one. All of the above applies analogously to evergreen_hpd_fini(), r100_hpd_init(), r100_hpd_fini(), r600_hpd_init(), r600_hpd_fini(), rs600_hpd_init() and rs600_hpd_fini() Silence UBSAN by checking ->hpd.hpd for RADEON_HPD_NONE before oring it into the 'enabled' bitset in the *_init()- or the 'disabled' bitset in the *_fini()-functions respectively. Signed-off-by: Nicolai Stange Signed-off-by: Alex Deucher

drm/radeon: allow to force hard GPU reset.

2016-05-02T17:08:54Z

In some cases, like when freezing for hibernation, we need to be able to force hard reset even if no engine are stuck. This patch add a bool option to current asic reset callback to allow to force hard reset on asic that supports it. Reviewed-by: Christian König Signed-off-by: Jérôme Glisse Cc: Alex Deucher Cc: Christian König Signed-off-by: Alex Deucher

drm/radeon: consolidate r600 uvd initialization and startup code.

2016-05-02T17:08:47Z

This match the exact same control flow as existing code. It just use goto instead of multiple levels of if/else. It also clarify early initialization failures by clearing rdev->has_uvd doing so does not change end result from hardware point of view, it only avoids printing more error messages down the line and thus only the original error is reported. Acked-by: Christian König Signed-off-by: Jérôme Glisse Cc: Alex Deucher Cc: Christian König Signed-off-by: Alex Deucher

drm/radeon: fix indentation.

2016-03-16T22:08:06Z

I hate doing this but it hurts my eyes to go over code that does not comply with indentation rules. Only thing that is not only space change is in atom.c all other files are space indentation issues. Acked-by: Christian König Signed-off-by: Jérôme Glisse Cc: Alex Deucher Signed-off-by: Alex Deucher

drm/radeon: Avoid double gpu reset by adding a timeout on IB ring tests.

2016-02-10T19:17:15Z

When the radeon driver resets a gpu, it attempts to test whether all the rings can successfully handle an IB. If these rings fail to respond, the process will wait forever. Another gpu reset can't happen at this point, as the current reset holds a lock required to do so. Instead, make all the IB tests run with a timeout, so the system can attempt to recover in this case. While this doesn't fix the underlying issue with card resets failing, it gives the system a higher chance of recovering. These timeouts have been confirmed to help both a Tathi and Hawaii card recover after a gpu reset. This also adds a new function, radeon_fence_wait_timeout, that behaves like fence_wait_timeout. It is used instead of fence_wait_timeout as it continues to work during a reset. radeon_fence_wait is changed to be implemented using this function. V2: - Changed the timeout to 1s, as the default 10s from radeon_wait_timeout was too long. A timeout of 100ms was tested and found to be too short. - Changed radeon_fence_wait_timeout to behave more like fence_wait_timeout. Reviewed-by: Christian König Signed-off-by: Matthew Dawson Signed-off-by: Alex Deucher

drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt

2015-12-04T18:09:12Z

HPD signals on DVI ports can be fired off before the pins required for DDC probing actually make contact, due to the pins for HPD making contact first. This results in a HPD signal being asserted but DDC probing failing, resulting in hotplugging occasionally failing. This is somewhat rare on most cards (depending on what angle you plug the DVI connector in), but on some cards it happens constantly. The Radeon R5 on the machine used for testing this patch for instance, runs into this issue just about every time I try to hotplug a DVI monitor and as a result hotplugging almost never works. Rescheduling the hotplug work for a second when we run into an HPD signal with a failing DDC probe usually gives enough time for the rest of the connector's pins to make contact, and fixes this issue. Reviewed-by: Christian König Signed-off-by: Lyude Signed-off-by: Alex Deucher