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

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: 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

drm/radeon: Only flush HDP cache for indirect buffers from userspace

2014-08-18T21:09:44Z

It isn't necessary for command streams generated by the kernel (at least not while we aren't storing ring or indirect buffers in VRAM). Signed-off-by: Michel Dänzer Signed-off-by: Alex Deucher

drm/radeon: Prevent too early kms-pageflips triggered by vblank.

2014-07-17T13:01:31Z

Since 3.16-rc1 we have this new failure: When the userspace XOrg ddx schedules vblank events to trigger deferred kms-pageflips, e.g., via the OML_sync_control extension call glXSwapBuffersMscOML(), or if a glXSwapBuffers() is called immediately after completion of a previous swapbuffers call, e.g., in a tight rendering loop with minimal rendering, it happens frequently that the pageflip ioctl() is executed within the same vblank in which a previous kms-pageflip completed, or - for deferred swaps - always one vblank earlier than requested by the client app. This causes premature pageflips and detection of failure by the ddx, e.g., XOrg log warnings like... "(WW) RADEON(1): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 201025 < target_msc 201026" ... and error/invalid return values of glXWaitForSbcOML() and Intel_swap_events extension. Reason is the new way in which kms-pageflips are programmed since 3.16. This commit changes the time window in which the hw can execute pending programmed pageflips. Before, a pending flip would get executed anywhere within the vblank interval. Now a pending flip only gets executed at the leading edge of vblank (start of front porch), making sure that a invocation of the pageflip ioctl() within a given vblank interval will only lead to pageflip completion in the following vblank. Tested to death on a DCE-4 card. Signed-off-by: Mario Kleiner Signed-off-by: Alex Deucher

drm/radeon: resume old pm late

2014-03-06T21:46:56Z

Moving the pm resume up in the init order to fix dpm seems to have regressed somes cases with the old pm code. Move it back to late resume. Signed-off-by: Alex Deucher

drm/radeon/pm: move pm handling into the asic specific code

2013-12-24T22:57:06Z

We need more control over the ordering of dpm init with respect to the rest of the asic. Specifically, the SMC has to be initialized before the rlc and cg/pg. The pm code currently initializes late in the driver, but we need it to happen much earlier so move pm handling into the asic specific callbacks. This makes dpm more reliable and makes clockgating work properly on CIK parts and should help on SI parts as well. Signed-off-by: Alex Deucher

drm/radeon: fix-up some float to fixed conversion thinkos

2013-11-08T17:33:38Z

Spotted by Brad Smith when porting to OpenBSD. Noticed-by: Brad Smith Signed-off-by: Alex Deucher

drm/radeon: add spinlocks for indirect register accesss

2013-09-11T15:44:29Z

This adds spinlocks to protect access to other indirect register apertures. These indirect spaces are used pretty infrequently and we haven't had an reported problems, but better safe than sorry. Signed-off-by: Alex Deucher

drm/radeon/kms: fix up 6xx/7xx display watermark calc for dpm

2013-06-27T14:49:22Z

Calculate the low and high watermarks based on the low and high clocks for the current power state. The dynamic pm hw will select the appropriate watermark based on the internal dpm state. Signed-off-by: Alex Deucher

radeon: Fix system hang issue when using KMS with older cards

2013-06-03T14:17:54Z

The current radeon driver initialization routines, when using KMS, are written so that the IRQ installation routine is called before initializing the WB buffer and the CP rings. With some ASICs, though, the IRQ routine tries to access the GFX_INDEX ring causing a call to RREG32 with the value of -1 in radeon_fence_read. This, in turn causes the system to completely hang with some cards, requiring a hard reset. A call stack that can cause such a hang looks like this (using rv515 ASIC for the example here): * rv515_init (rv515.c) * radeon_irq_kms_init (radeon_irq_kms.c) * drm_irq_install (drm_irq.c) * radeon_driver_irq_preinstall_kms (radeon_irq_kms.c) * rs600_irq_process (rs600.c) * radeon_fence_process - due to SW interrupt (radeon_fence.c) * radeon_fence_read (radeon_fence.c) * hang due to RREG32(-1) The patch moves the IRQ installation to the card startup routine, after the ring has been initialized, but before the IRQ has been set. This fixes the issue, but requires a check to see if the IRQ is already installed, as is the case in the system resume codepath. I have tested the patch on three machines using the rv515, the rv770 and the evergreen ASIC. They worked without issues. This seems to be a known issue and has been reported on several bug tracking sites by various distributions (see links below). Most of reports recommend booting the system with KMS disabled and then enabling KMS by reloading the radeon module. For some reason, this was indeed a usable workaround, however, UMS is now deprecated and disabled by default. Bug reports: https://bugzilla.redhat.com/show_bug.cgi?id=845745 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561789 https://bbs.archlinux.org/viewtopic.php?id=156964 Signed-off-by: Adis Hamzić Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org