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

drm/radeon: Support DRM_MODE_PAGE_FLIP_ASYNC

2016-05-05T00:19:03Z

When this flag is set, we program the hardware to execute the flip during horizontal blank (i.e. for the next scanline) instead of during vertical blank (i.e. for the next frame). Currently this is only supported on ASICs which have a page flip completion interrupt (>= R600), and only if the use_pflipirq parameter has value 2 (the default). Reviewed-by: Christian König Signed-off-by: Michel Dänzer 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: 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

drm/radeon: do a posting read in rs600_set_irq

2015-03-03T22:28:27Z

To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next

2015-01-29T01:45:31Z

This backmerges drm-fixes into drm-next mainly for the amdkfd stuff, I'm not 100% confident, but it builds and the amdkfd folks can fix anything up. Signed-off-by: Dave Airlie Conflicts: drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h

drm/radeon: Split off gart_get_page_entry ASIC hook from set_page_entry

2015-01-22T16:46:17Z

get_page_entry calculates the GART page table entry, which is just written to the GART page table by set_page_entry. This is a prerequisite for the following fix. Reviewed-by: Christian König Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher

radeon/audio: consolidate audio_fini() functions

2015-01-22T15:42:09Z

Reviewed-by: Christian König Signed-off-by: Slava Grigorev Signed-off-by: Alex Deucher

radeon/audio: consolidate audio_init() functions

2015-01-22T15:38:59Z

Reviewed-by: Christian König Signed-off-by: Slava Grigorev Signed-off-by: Alex Deucher

drm/radeon: make sure mode init is complete in bandwidth_update

2014-11-06T20:42:44Z

The power management code calls into the display code for certain things. If certain power management sysfs attributes are called before the driver has finished initializing all of the hardware we can run into problems with uninitialized modesetting state. Add a check to make sure modesetting init has completed to the bandwidth update callbacks to fix this. Can be triggered by the tlp and laptop start up scripts depending on the timing. bugs: https://bugzilla.kernel.org/show_bug.cgi?id=83611 https://bugs.freedesktop.org/show_bug.cgi?id=85771 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org