For r6xx+ asics.  This mirrors the behavior of pre-r6xx
asics.  We need to program the MC even if something
else in startup() fails.  Failure to do so results in
an unusable GPU.

Based on a fix from: Mark Kettenis <kettenis@openbsd.org>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Need to set the wallclock ratio and adjust the phase
and module registers appropriately.  May fix problems
with audio timing at certain display timings.

v2: properly handle clocks below 24mhz
v3: rebase r600 changes
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Enabling spread spectrum on the engine clock
leads to hangs on some asics.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=66963Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Removing the clock/power or resetting the VCPU can cause
hangs if that happens in the middle of a register write.

Stall the memory and register bus before putting the VCPU
into reset. Keep it in reset when unloading the module or
suspending.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

There are some hardware issue with reclocking on SI when
UVD is active, so use a stable power state when UVD is
active.  Fixes possible hangs and performance issues when
using UVD on SI.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Need to check for engine and memory clock ss separately
and only enable dynamic ss if either of them are found.

This should fix systems which have a ss table, but do
not have entries for engine or memory.  On those systems
we may enable dynamic spread spectrum without enabling
it on the engine or memory clocks which can lead to a
hang in some cases.

fixes some systems reported here:
https://bugs.freedesktop.org/show_bug.cgi?id=66963

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

On rv770 and newer, clock gating is not required
for thermal protection.  The only requirement is that
the design utilizes a thermal sensor.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

There are two audio dtos on radeon asics that you can
select between.  Normally, dto0 is used for hdmi and
dto1 for DP, but it seems that the dto is somehow
tied to the encoders on DCE3 asics.

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

When we reset the GPU, we need to properly tear
down power management before reseting the GPU and then
set it back up again after reset.  Add the missing
radeon_pm_[suspend|resume] calls to the gpu reset
function.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Forgot to use the appropriate math64 function.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@gmail.com>

Now that the fixed point functions are fixed we
can re-enable cac support.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Need to make some slight adjustments for the fixed point math to
work properly.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The ProcessAuxChannel table on some rv635 boards assumes
the divmul members are initialized to 0 otherwise we get
an invalid fb offset since it has a bad mask set when
setting the fb base.  While here initialize all the
atom interpretor elements to 0.

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

The SMC interface changed compared to Cayman and
previous asics.  Set the enabled levels properly
and enable reclocking by default when dpm is enabled.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Disable cac setup on SI for now since it causes
strange performance level restrictions on certain
cards.  I suspect there may be issues with some of
the 64 bit fixed point double emulation that is used
to set up those parameters.  I need to double check
the math before this can be re-enabled.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Coarse grain clockgating causes problems with reclocking on
some cards and powergating (verde only) causes problems with
ring initialization.  The proper fix (restructuring the init
sequences) is too invasive for 3.11 so just disable them for
now.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Need to program EnabledLevels to 1 to force the low state.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

For correctness.  The fb divider isn't actually used
in any of the relevant dpm code.  It's calculated
from the other parameters.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Don't try and enable clockgating if the asic doesn't have
UVD.  Use rdev->has_uvd rather than using local checks.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

0x6835 should be treated as a cape verde pro.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Update alogorithm as per internal advice.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Need to set the DISP*_GAP fields as well as the
DISP*_GAP_MCHG fields.  Same as on previous asics.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We need to set the dto source before setting the
dividers otherwise we may get stability problems
with the dto leading to audio playback problems.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org

Actually program the correct register to enable
engine clock scaling control.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Allows you to limit the selected power levels via sysfs.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Need to use the driver state rather than the register
state since the displays may not be enabled when the
power state is programmed.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Need to set high for the last two entries.  Looks
like a copy and paste typo.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Noticed that my old Radeon 7500 hung after printing

   drm: GPU not posted. posting now...

when it wasn't selected as the primary card the BIOS.  Some digging
revealed that it was hanging in combios_parse_mmio_table() while
parsing the ASIC INIT 3 table.  Looking at the BIOS ROM for the card,
it becomes obvious that there is no ASIC INIT 3 table in the BIOS.
The code is just processing random garbage.  No surprise it hangs!

Why do I say that there is no ASIC INIT 3 table is the BIOS?  This
table is found through the MISC INFO table.  The MISC INFO table can
be found at offset 0x5e in the COMBIOS header.  But the header is
smaller than that.  The COMBIOS header starts at offset 0x126.  The
standard PCI Data Structure (the bit that starts with 'PCIR') lives at
offset 0x180.  That means that the COMBIOS header can not be larger
than 0x5a bytes and therefore cannot contain a MISC INFO table.

I looked at a dozen or so BIOS images, some my own, some downloaded from:

    <http://www.techpowerup.com/vgabios/index.php?manufacturer=ATI&page=1>

It is fairly obvious that the size of the COMBIOS header can be found
at offset 0x6 of the header.  Not sure if it is a 16-bit number or
just an 8-bit number, but that doesn't really matter since the tables
seems to be always smaller than 256 bytes.

So I think combios_get_table_offset() should check if the requested
table is present.  This can be done by checking the offset against the
size of the header.  See the diff below.  The diff is against the WIP
OpenBSD codebase that roughly corresponds to Linux 3.8.13 at this
point.  But I don't think this bit of the code changed much since
then.

For what it is worth:
Signed-off-by: NMark Kettenis <kettenis@openbsd.org>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Hopefully avoid more quirks in the future due to bogus
vbios dac data.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Hello,
got another card with "too bright" problem:
Sapphire Radeon VE 7000 DDR (VGA+S-Video)

lspci -vnn:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] [1002:5159] (prog-if 00 [VGA controller])
        Subsystem: PC Partner Limited Sapphire Radeon VE 7000 DDR [174b:7c28]

The patch below fixes the problem for this card.
But I don't like the blacklist, couldn't some heuristic be used instead?
The interesting thing is that the manufacturer is the same as the other card
needing the same quirk. I wonder how many different types are broken this way.

The "wrong" ps2_pdac_adj value that comes from BIOS on this card is 0x300.

====================
drm/radeon: Add primary dac adj quirk for Sapphire Radeon VE 7000 DDR

Values from BIOS are wrong, causing too bright colors.
Use default values instead.
Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The atom interpreter expects data in LE format, so
swap the message buffer as apprioriate.

v2: properly handle non-dw aligned byte counts.
v3: properly handle remainder
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Dong He <hedonghust@gmail.com>
Cc: stable@vger.kernel.org

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

Make sure the 3D engine is idle before using CP DMA for
bo copies.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Marek Olšák <maraeo@gmail.com>

This allows you to look at the current DPM state via
debugfs.

Due to the way the hardware works on these asics, there's
no way to look up exactly what power state we are in, so
we make the best guess we can based on the current sclk.

v2: Anthoine's version
v3: fix ref div
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

See bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
https://bugs.freedesktop.org/show_bug.cgi?id=66972
https://bugs.freedesktop.org/show_bug.cgi?id=66945Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It seems gcc 4.8.1 generates bogus code for the old logic causing
part of the function to get skipped.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
https://bugs.freedesktop.org/show_bug.cgi?id=66972
https://bugs.freedesktop.org/show_bug.cgi?id=66945Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Parsing the table in incorrectly led to problems with
certain asics with mclk switching.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

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

Can cause hangs when enabled in certain motherboards.
Set radeon.aspm=0 to disable aspm.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Fix a warning from lockdep caused by calling flush_work() for
uninitialized hotplug work. Initialize hotplug_work, audio_work
and reset_work upon successful radeon_irq_kms_init() completion
and thus perform hotplug flush_work only when rdev->irq.installed
is true.

[    4.790019] [drm] Loading CEDAR Microcode
[    4.790943] r600_cp: Failed to load firmware "radeon/CEDAR_smc.bin"
[    4.791152] [drm:evergreen_startup] *ERROR* Failed to load firmware!
[    4.791330] radeon 0000:01:00.0: disabling GPU acceleration

[    4.792633] INFO: trying to register non-static key.
[    4.792792] the code is fine but needs lockdep annotation.
[    4.792953] turning off the locking correctness validator.

[    4.793114] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc0-dbg-10676-gfe56456-dirty #1816
[    4.793314] Hardware name: Acer             Aspire 5741G    /Aspire 5741G    , BIOS V1.20 02/08/2011
[    4.793507]  ffffffff821fd810 ffff8801530b9a18 ffffffff8160434e 0000000000000002
[    4.794155]  ffff8801530b9ad8 ffffffff810b8404 ffff8801530b0798 ffff8801530b0000
[    4.794789]  ffff8801530b9b00 0000000000000046 00000000000004c0 ffffffff00000000
[    4.795418] Call Trace:
[    4.795573]  [<ffffffff8160434e>] dump_stack+0x4e/0x82
[    4.795731]  [<ffffffff810b8404>] __lock_acquire+0x1a64/0x1d30
[    4.795893]  [<ffffffff814a87f0>] ? dev_vprintk_emit+0x50/0x60
[    4.796034]  [<ffffffff810b8fb4>] lock_acquire+0xa4/0x200
[    4.796216]  [<ffffffff8106cd75>] ? flush_work+0x5/0x280
[    4.796375]  [<ffffffff8106cdad>] flush_work+0x3d/0x280
[    4.796520]  [<ffffffff8106cd75>] ? flush_work+0x5/0x280
[    4.796682]  [<ffffffff810b659d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[    4.796862]  [<ffffffff8131d775>] ? delay_tsc+0x95/0xf0
[    4.797024]  [<ffffffff8141bb8b>] radeon_irq_kms_fini+0x2b/0x70
[    4.797186]  [<ffffffff814557c9>] evergreen_init+0x2a9/0x2e0
[    4.797347]  [<ffffffff813ebb1f>] radeon_device_init+0x5ef/0x700
[    4.797511]  [<ffffffff81335bc7>] ? pci_find_capability+0x47/0x50
[    4.797672]  [<ffffffff813edaed>] radeon_driver_load_kms+0x8d/0x150
[    4.797843]  [<ffffffff813ce426>] drm_get_pci_dev+0x166/0x280
[    4.798007]  [<ffffffff8116cff5>] ? kfree+0xf5/0x2e0
[    4.798168]  [<ffffffff813ea298>] ? radeon_pci_probe+0x98/0xd0
[    4.798329]  [<ffffffff813ea2aa>] radeon_pci_probe+0xaa/0xd0
[    4.798489]  [<ffffffff81339404>] pci_device_probe+0x84/0xe0
[    4.798644]  [<ffffffff814ac7d6>] driver_probe_device+0x76/0x240
[    4.798805]  [<ffffffff814aca73>] __driver_attach+0x93/0xa0
[    4.798948]  [<ffffffff814ac9e0>] ? __device_attach+0x40/0x40
[    4.799126]  [<ffffffff814aa82b>] bus_for_each_dev+0x6b/0xb0
[    4.799272]  [<ffffffff814ac2be>] driver_attach+0x1e/0x20
[    4.799434]  [<ffffffff814abec0>] bus_add_driver+0x1f0/0x280
[    4.799596]  [<ffffffff814ad0e4>] driver_register+0x74/0x150
[    4.799758]  [<ffffffff8133923d>] __pci_register_driver+0x5d/0x60
[    4.799936]  [<ffffffff81d16efc>] ? ttm_init+0x67/0x67
[    4.800081]  [<ffffffff813ce655>] drm_pci_init+0x115/0x130
[    4.800243]  [<ffffffff81d16efc>] ? ttm_init+0x67/0x67
[    4.800405]  [<ffffffff81d16f98>] radeon_init+0x9c/0xba
[    4.800586]  [<ffffffff810002ca>] do_one_initcall+0xfa/0x150
[    4.800746]  [<ffffffff81073f60>] ? parse_args+0x120/0x330
[    4.800909]  [<ffffffff81cdafae>] kernel_init_freeable+0x111/0x191
[    4.801052]  [<ffffffff81cda87a>] ? do_early_param+0x88/0x88
[    4.801233]  [<ffffffff815fb670>] ? rest_init+0x140/0x140
[    4.801393]  [<ffffffff815fb67e>] kernel_init+0xe/0x180
[    4.801556]  [<ffffffff8160dcac>] ret_from_fork+0x7c/0xb0
[    4.801718]  [<ffffffff815fb670>] ? rest_init+0x140/0x140
Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org