This patch adds the notion of a drm_bridge. A bridge is a chained
device which hangs off an encoder. The drm driver using the bridge
should provide the association between encoder and bridge. Once a
bridge is associated with an encoder, it will participate in mode
set, and dpms (via the enable/disable hooks).
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Noticed by kbuild test robot.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Check to make sure the dc limits are valid before using them.
Some systems may not have a dc limits table.  In that case just
use the ac limits.  This fixes hangs on systems when the power
state is changed when on battery (dc) due to invalid performance
state parameters.

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

Check to make sure the dc limits are valid before using them.
Some systems may not have a dc limits table.  In that case just
use the ac limits.  This fixes hangs on systems when the power
state is changed when on battery (dc) due to invalid performance
state parameters.

Should fix:
https://bugs.freedesktop.org/show_bug.cgi?id=68708

v2: fix up limits in dpm_init()
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

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>

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

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>

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

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>

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

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>

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

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>

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

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>

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

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>

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

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>

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

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>

Newer versions of gcc seem to wander off into the
weeds when dealing with variable sizes arrays in
structs.  Rather than indexing the arrays, use
pointer arithmetic.

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>

The same as on evergreen.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reported-by: NFrankR Huang <FrankR.Huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The vram scratch buffer needs to be initialized
before the mc is programmed otherwise we program
0 as the GPU address of the default GPU fault
page.  In most cases we put vram at zero anyway and
reserve a page for the legacy vga buffer so in practice
this shouldn't cause any problems, but better to make
it correct.

Was changed in:
6fab3febReported-by: NFrankR Huang <FrankR.Huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Avoid needless uvd reprogramming if uvd powergating is disabled.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

No need to try the ring tests if starting the UVD block failed.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

For powergating, we just need to re-init the registers, there
is no need to restore the uvd BOs.  This just adds needless
work when powergating uvd for playback while the system is
on.  We only need to restore the uvd BOs on an actual resume
from suspend or when the driver loads.

This fixes multi-stream UVD playback on KB systems.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>

Commit a01c34f7 (radeon kms: do not
flush uninitialized hotplug work) moved work initialisation phase to
the last step of radeon_irq_kms_init(). Meelis Roos reported that this
causes problems on his machine because drm_irq_install() uses hotplug
work on r100.

hotplug work flushed in radeon_irq_kms_fini(), with two possible cases:
-- radeon_irq_kms_fini() call after successful radeon_irq_kms_init()
-- radeon_irq_kms_fini() call after unsuccessful (or not called at all)
   radeon_irq_kms_init()

The latter one causes flush work on uninitialised hotplug work. Move
work initialisation before drm_irq_install(), but keep existing agreement
to flush hotplug work in radeon_irq_kms_fini() only for `irq.installed'
(successful radeon_irq_kms_init()) case.

WARNING: CPU: 0 PID: 243 at kernel/workqueue.c:1378 __queue_work+0x132/0x16d()
Call Trace:
[<c12319b3>] ? dump_stack+0xa/0x13
[<c1022600>] ? warn_slowpath_common+0x75/0x8a
[<c1031010>] ? __queue_work+0x132/0x16d
[<c1031010>] ? __queue_work+0x132/0x16d
[<c102269e>] ? warn_slowpath_null+0x1b/0x1f
[<c1031010>] ? __queue_work+0x132/0x16d
[<c103107b>] ? queue_work_on+0x30/0x40
[<f8aed3f3>] ? r100_irq_process+0x16d/0x1e6 [radeon]
[<f8ae77cf>] ? radeon_driver_irq_preinstall_kms+0xc2/0xc5 [radeon]
[<f8974d77>] ? drm_irq_install+0xb2/0x1ac [drm]
[<f897604d>] ? drm_vblank_init+0x196/0x1d2 [drm]
[<f8ae78d3>] ? radeon_irq_kms_init+0x33/0xc6 [radeon]
[<f8aef35a>] ? r100_startup+0x1a3/0x1d6 [radeon]
[<f8ad77c8>] ? radeon_ttm_init+0x26e/0x287 [radeon]
[<f8aef752>] ? r100_init+0x2b3/0x309 [radeon]
[<c118082e>] ? vga_client_register+0x39/0x40
[<f8ac535f>] ? radeon_device_init+0x54b/0x61b [radeon]
[<f8ac40fd>] ? cail_mc_write+0x13/0x13 [radeon]
[<f8ac6864>] ? radeon_driver_load_kms+0x82/0xda [radeon]
[<f8978bbd>] ? drm_get_pci_dev+0x136/0x22d [drm]
[<f8ac409b>] ? radeon_pci_probe+0x6c/0x86 [radeon]
[<c112acf6>] ? pci_device_probe+0x4c/0x83
[<c11846c7>] ? driver_probe_device+0x80/0x184
[<c112a848>] ? pci_match_id+0x18/0x36
[<c1184837>] ? __driver_attach+0x44/0x5f
[<c11833f4>] ? bus_for_each_dev+0x50/0x5a
[<c118433e>] ? driver_attach+0x14/0x16
[<c11847f3>] ? __device_attach+0x28/0x28
[<c1184045>] ? bus_add_driver+0xd6/0x1bf
[<c1184c22>] ? driver_register+0x78/0xcf
[<f8ba8000>] ? 0xf8ba7fff
[<c10003bf>] ? do_one_initcall+0x8b/0x121
[<c101e668>] ? change_page_attr_clear+0x2e/0x33
[<f8ba8000>] ? 0xf8ba7fff
[<c101e689>] ? set_memory_ro+0x1c/0x20
[<c104de94>] ? set_page_attributes+0x11/0x12
[<c104f6e1>] ? load_module+0x12fa/0x17e8
[<c107483b>] ? map_vm_area+0x22/0x31
[<c104fc36>] ? SyS_init_module+0x67/0x7d
[<c1234245>] ? sysenter_do_call+0x12/0x26
Reported-by: NMeelis Roos <mroos@linux.ee>
Tested-by: NMeelis Roos <mroos@linux.ee>
Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

This sets up the short audio descriptors properly on
DCE3.2 asics for hdmi audio.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The table has the following format:

typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT         //usSrcDstTableOffset pointing to this structure
{
  UCHAR               ucNumberOfSrc;
  USHORT              usSrcObjectID[1];
  UCHAR               ucNumberOfDst;
  USHORT              usDstObjectID[1];
}ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;

usSrcObjectID[] and usDstObjectID[] are variably sized, so we
can't access them directly.  Use pointers and update the offset
appropriately when accessing the Dst members.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Setting MC_MISC_CNTL.GART_INDEX_REG_EN causes hangs on
some boards on resume.  The systems seem to work fine
without touching this bit so leave it as is.

v2: read-modify-write the GART_INDEX_REG_EN bit.
I suspect the problem is that we are losing the other
settings in the register.

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=52952Reported-by: NOndrej Zary <linux@rainbow-software.org>
Tested-by: NDaniel Tobias <dan.g.tob@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

This fills in the GPU specific details for berlin
GPU cores so that the driver will work with them.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

These blocks need to be ungated for the other parts of
the driver properly initialize them (e.g., after a gpu
reset, etc.).
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Track the current uvd gated state on CI to avoid unnecessary
state changes when uvd is active.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

UVD dpm dynamically adjusts the uvd clocks on
demand.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Since we aren't using it when the crtc is disabled, turn it off
to save power.  The GRPH block is the part of the display
controller that controls the primary graphics plane (size,
address, etc.).
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

These fixes make writes work properly.  Previously
only reads worked.  Note that this feature is off
by default.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

If the LCD table contains an EDID record, properly account
for the edid size when walking through the records.

This should fix error messages about unknown LCD records.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Check the overrides in the firmware info table before
enabling spread spectrum on the engine or memory clocks.

Some boards may have valid spread spectrum tables, but
shouldn't necessarily have it enabled.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We need to allocate line buffer to each display when
setting up the watermarks.  Failure to do so can lead
to a blank screen.  This fixes blank screen problems
on dce8 asics.

Based on an initial fix from:
Jay Cornwall <jay.cornwall@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

We need to allocate line buffer to each display when
setting up the watermarks.  Failure to do so can lead
to a blank screen.  This fixes blank screen problems
on dce6 asics.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=64850

Based on an initial fix from:
Jay Cornwall <jay.cornwall@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

We need to allocate line buffer to each display when
setting up the watermarks.  Failure to do so can lead
to a blank screen.  This fixes blank screen problems
on dce4.1/5 asics.

Based on an initial fix from:
Jay Cornwall <jay.cornwall@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Also add a new RADEON_INFO query to check that CP DMA packets are
supported on the compute ring.

CP DMA has been supported since the 3.8 kernel, but due to an oversight
we forgot to teach the CS checker that the CP DMA packet was legal for
the compute ring on Southern Islands GPUs.

This patch fixes a bug where the radeon driver will incorrectly reject a legal
CP DMA packet from user space.  I would like to have the patch
backported to stable so that we don't have to require Mesa users to use a
bleeding edge kernel in order to take advantage of this feature which
is already present in the stable kernels (3.8 and newer).

v2:
  - Don't bump kms version, so this patch can be backported to stable
    kernels.

Cc: stable@vger.kernel.org
Signed-off-by: NTom Stellard <thomas.stellard@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Now that the CP is no longer reset and cg is properly
disabled in when appropriate in the dpm code we can
now enable mgcg (medium grained clockgating).
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Clockgating needs to be disabled around certain parts
of dpm setup otherwise the smc gets into a bad state
and dpm doesn't work properly.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Clockgating needs to be disabled around certain parts
of dpm setup otherwise the smc gets into a bad state
and dpm doesn't work properly.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The format of the clearstate buffer used for pg (powergating)
changed between NI and SI.  This formats it properly for what
the hardware expects on SI+.

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

Clockgating requires signalling between the CP and the
RLC to work properly.  Resetting the CP block in the
CP resume code messed up the internal coordination
between the blocks.  Removing the reset allows gfx
clockgating to work properly.  However, when gfx clock
gating is enabled, there is a strange interaction with
dpm which causes the chip to stay in the high performance
level all the time, so leave gfx clockgating disabled
for now.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>