Avoids confusion and duplication.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

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=156964Signed-off-by: NAdis Hamzić <adis@hamzadis.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

radeon currently uses a drm function to get the speed capabilities for
the bus, drm_pcie_get_speed_cap_mask. However, this is a non-standard
method of performing this detection and this patch changes it to use
the max_bus_speed attribute.

From: Lucas Kannebley Tavares <lucaskt@linux.vnet.ibm.com>
Signed-off-by: NKleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Hainan has no display hardware:
- no DCE (crtc, uniphy, dac, etc.)
- no VGA

v2: fix bios fetch
v3: fix interrupts
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

Add ULL prefix to avoid overflow.
Signed-off-by: NNiels Ole Salscheider <niels_ole@salscheider-online.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Instead of duplicating the code over and over again, just use a single
function to handle the clock calculations.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Just power down the PLL when we get a VCLK or DCLK of zero.
Enabling the bypass mode early should also allow us to
switch UVD clocks on the fly.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Just disabling the mem requests should be enough, but
that doesn't seem to work correctly on efi systems.

May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=57567
https://bugs.freedesktop.org/show_bug.cgi?id=43655
https://bugzilla.kernel.org/show_bug.cgi?id=56441

v2: blank displays first, then disable.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Need to wait for the new addresses to take affect before
re-enabling the MC.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Properly wait for the next vblank region.  The previous
code didn't always wait long enough depending on the timing.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Avoids potential interrupt storms when the display is disabled.

May fix:
https://bugzilla.kernel.org/show_bug.cgi?id=56041Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

If the disabled rb mask register is not properly initialized
program a sane default based on the number of RBs for the
asic.  This avoids a potential divide by 0 when calculating
the backend mask.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Avoid confusion with the *REG32_P mask macro.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

v2: set UVD tiling config for rv730
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>

v2: remove unneeded register definitions
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

v2: write clk registers only once!
v3: update cg scratch register properly
v4: add TN support
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Just everything needed to decode videos using UVD.

v6: just all the bugfixes and support for R7xx-SI merged in one patch
v7: UVD_CGC_GATE is a write only register, lockup detection fix
v8: split out VRAM fallback changes, remove support for RV770,
    add support for HEMLOCK, add buffer sizes checks
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The MC is mostly likely busy (e.g., display requests), not hung
so no need to reset it.  Doing an MC reset is tricky and not
particularly reliable.  Fixes hangs in certain cases.
Reported-by: NJosh Boyer <jwboyer@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

vddci needs to track mclk for multi-head.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The MC isn't part of the GPU per se.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

fetch the reset mask and check if the relevant ring flags
are set to determine whether the ring is hung or not.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It's better to halt the engines before we disable the MC.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

When we attempt the reset the GPU, look at the status registers
to determine what blocks need to be reset.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

When we attempt the reset the GPU, look at the status registers
to determine what blocks need to be reset.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Update the code to better match the recommended
programming sequence for soft reset.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Update the code to better match the recommended
programming sequence for soft reset.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Used by all asic families from r600+.
Flag for the vbios and later instances of the driver
that the GPU is hung.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This simplify and cleanup the async dma checking.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Some chips seem to need a little delay after blacking out
the MC before the requests actually stop.

May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56139
https://bugs.freedesktop.org/show_bug.cgi?id=57567Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Need to adjust the backend map depending on which
RB is enabled.

Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=892233Reported-by: NMikko Tiihonen <mikko.tiihonen@iki.fi>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Force the crtc mem requests on/off immediately rather
than waiting for the double buffered updates to kick in.
Seems we miss the update in certain conditions.  Also
handle the DCE6 case.
Signed-off-by: NChristopher Staite <chris@yourdreamnet.co.uk>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Fixes a hard lock in the gpu reset code after the
rework for DMA support (0ecebb9e
"drm/radeon: switch to a finer grained reset for evergreen")
due to not bailing before the MC shutdown if the relevant engines
are idle.

Discussion:
http://lists.freedesktop.org/archives/dri-devel/2013-January/032985.htmlReported-by: NEldad Zack <eldad@fogrefinery.com>
Tested-by: NEldad Zack <eldad@fogrefinery.com>
Acked-by: NPaul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

No change in functionality as we currently set all the reset
flags.
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

SRBM write packet takes DW aligned registers.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This try to reset the dma engine when performing gpu reset. Hopefully
bringing back the gpu dma engine in sane state.

v2: agd5f: fix dma reset on cayman/TN, add support for SI
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

To help debug dma related lockup.

v2: agd5f: update SI as well
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Set the proper number of tile pipe that should be a multiple of
pipe depending on the number of se engine.

Fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56405
https://bugs.freedesktop.org/show_bug.cgi?id=56720

v2: Don't change sumo2
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Cc: stable@vger.kernel.org
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>

There are 2 async DMA engines on cayman, one at 0xd000 and
one at 0xd800.  The programming interface is the same as
evergreen however there are some changes to the commands
for using vmids.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>