In radeon_device_init, set the need_dma32 flag for Cedar chips
(e.g. FirePro 2270).  This fixes, or at least works around, a bug
on PowerPC exposed by last year's commits

8e3f1b1d (Russell Currey)

and

253fd51e (Alistair Popple)

which enabled the 64-bit DMA iommu bypass.

This caused the device to freeze, in some cases unrecoverably, and is
the subject of several bug reports internal to Red Hat.
Signed-off-by: NBen Crocker <bcrocker@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

swiotlb expands our card accessing range, but its path always is slower
than ttm pool allocation.
So add condition to use it.
v2: move a bit later
Signed-off-by: NChunming Zhou <david1.zhou@amd.com>
Reviewed-by: NMonk Liu <monk.liu@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180209024410.1469-3-david1.zhou@amd.com

This reverts commit ebff8453. Unused
since amdkfd is no longer supported with radeon.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel@daenzer.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This reverts commit 1c0a4625. Not needed
anymore, since amdkfd is no longer supported with radeon.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel@daenzer.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Fixes a hibernation regression on APUs.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=191571
Fixes: 274ad65c (drm/radeon: hard reset r600 and newer GPU when hibernating.)
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The PCI Power Management Spec, r1.2, sec 5.6.1, requires a 10 millisecond
delay when powering on a device, i.e., transitioning from state D3hot to
D0.

Apparently some devices require more time, and d1f9809e ("drm/radeon:
add quirk for d3 delay during switcheroo poweron for apple macbooks") added
an additional delay for the Radeon device in a MacBook Pro.  4807c5a8
("drm/radeon: add a PX quirk list") made the affected device more explicit.

Add a generic PCI quirk to increase the d3_delay.  This means we will use
the additional delay for *all* wakeups from D3, not just those initiated by
radeon_switcheroo_set_state().
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAndreas Boll <andreas.boll.dev@gmail.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
CC: Maarten Lankhorst <maarten.lankhorst@canonical.com>

Disable PX on these systems.

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

An external Thunderbolt GPU can neither drive the laptop's panel nor be
powered off by the platform, so there's no point in registering it with
vga_switcheroo.  In fact, when the external GPU is runtime suspended,
vga_switcheroo will cut power to the internal discrete GPU, resulting in
a lockup.  Moreover AMD's Windows driver special-cases Thunderbolt as
well.
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Link: http://patchwork.freedesktop.org/patch/msgid/72d8a9645aece3eff44e116303f0fec8be061c88.1489145162.git.lukas@wunner.de

There is no need to repeat information that printed by PCI core at boot time.

Besides that printing was potentially wrong since resource_size_t might be
bigger than 32 bits and there is a dedicated specifier for such type, i.e.
%pap. Someone can fix it and use even better approach, i.e. %pR.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Use a more common logging style.

Miscellanea:

o Coalesce formats and realign arguments
o Neaten a few macros now using pr_<level>
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so it's not necessary to call drm_debugfs_remove_files().

Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-13-noralf@tronnes.org

Since commit 8a357d10 ("drm: Nerf DRM_CONTROL nodes"), a
struct drm_device's ->control member is always NULL.

In the case of CONFIG_DEBUG_FS=y, radeon_debugfs_add_files() accesses
->control->debugfs_root though. This results in the following Oops:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
  IP: radeon_debugfs_add_files+0x90/0x100 [radeon]
  PGD 0
  Oops: 0000 [#1] SMP
  [...]
  Call Trace:
   ? work_on_cpu+0xb0/0xb0
   radeon_fence_driver_init+0x120/0x150 [radeon]
   si_init+0x122/0xd50 [radeon]
   ? _raw_spin_unlock_irq+0x2c/0x40
   ? device_pm_check_callbacks+0xb3/0xc0
   radeon_device_init+0x958/0xda0 [radeon]
   radeon_driver_load_kms+0x9a/0x210 [radeon]
   drm_dev_register+0xa9/0xd0 [drm]
   drm_get_pci_dev+0x9c/0x1e0 [drm]
   radeon_pci_probe+0xb8/0xe0 [radeon]
  [...]

Fix this by omitting the drm_debugfs_create_files() call for the
control minor debugfs directory which is now non-existent anyway.

Fixes: 8a357d10 ("drm: Nerf DRM_CONTROL nodes")
Signed-off-by: NNicolai Stange <nicstange@gmail.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161203144700.2307-1-nicstange@gmail.com

If the platform does not support hybrid graphics or ATPX dGPU
power control.

bug: https://bugzilla.kernel.org/show_bug.cgi?id=51381Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Update the comment to explain why we do this.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

I plan to usurp the short name of struct fence for a core kernel struct,
and so I need to rename the specialised fence/timeline for DMA
operations to make room.

A consensus was reached in
https://lists.freedesktop.org/archives/dri-devel/2016-July/113083.html
that making clear this fence applies to DMA operations was a good thing.
Since then the patch has grown a bit as usage increases, so hopefully it
remains a good thing!

(v2...: rebase, rerun spatch)
v3: Compile on msm, spotted a manual fixup that I broke.
v4: Try again for msm, sorry Daniel

coccinelle script:
@@

@@
- struct fence
+ struct dma_fence
@@

@@
- struct fence_ops
+ struct dma_fence_ops
@@

@@
- struct fence_cb
+ struct dma_fence_cb
@@

@@
- struct fence_array
+ struct dma_fence_array
@@

@@
- enum fence_flag_bits
+ enum dma_fence_flag_bits
@@

@@
(
- fence_init
+ dma_fence_init
|
- fence_release
+ dma_fence_release
|
- fence_free
+ dma_fence_free
|
- fence_get
+ dma_fence_get
|
- fence_get_rcu
+ dma_fence_get_rcu
|
- fence_put
+ dma_fence_put
|
- fence_signal
+ dma_fence_signal
|
- fence_signal_locked
+ dma_fence_signal_locked
|
- fence_default_wait
+ dma_fence_default_wait
|
- fence_add_callback
+ dma_fence_add_callback
|
- fence_remove_callback
+ dma_fence_remove_callback
|
- fence_enable_sw_signaling
+ dma_fence_enable_sw_signaling
|
- fence_is_signaled_locked
+ dma_fence_is_signaled_locked
|
- fence_is_signaled
+ dma_fence_is_signaled
|
- fence_is_later
+ dma_fence_is_later
|
- fence_later
+ dma_fence_later
|
- fence_wait_timeout
+ dma_fence_wait_timeout
|
- fence_wait_any_timeout
+ dma_fence_wait_any_timeout
|
- fence_wait
+ dma_fence_wait
|
- fence_context_alloc
+ dma_fence_context_alloc
|
- fence_array_create
+ dma_fence_array_create
|
- to_fence_array
+ to_dma_fence_array
|
- fence_is_array
+ dma_fence_is_array
|
- trace_fence_emit
+ trace_dma_fence_emit
|
- FENCE_TRACE
+ DMA_FENCE_TRACE
|
- FENCE_WARN
+ DMA_FENCE_WARN
|
- FENCE_ERR
+ DMA_FENCE_ERR
)
 (
 ...
 )
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Acked-by: NSumit Semwal <sumit.semwal@linaro.org>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161025120045.28839-1-chris@chris-wilson.co.uk

Only needed on CIK+ due to the way pci reset is handled
by the GPU.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

This is not necessary as pointed out by Lukas Wunner.

This reverts commit 5e0b1617.

We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/radeon/radeon_device.c:1961:5: warning: no previous prototype for 'radeon_debugfs_init' [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_device.c:1966:6: warning: no previous prototype for 'radeon_debugfs_cleanup' [-Wmissing-prototypes]

In fact, these functions are dummy, but can be removed,
so this patch removes them.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Normally on shutdown or reboot we don't care about necessarily
making sure the hw is in a good state because the system is about
to be powered down or reset.  However, after a shutdown or reboot
in a VM, it's best to tear down the hw properly otherwise there
can be problems with the next VM use.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NEdward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Missed this case previously. No need to do anything if the
device is already off.  runtime pm will handle it.
Acked-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

radeon_device_init() returns an error if either of the two calls to
radeon_init() fail. One level up in the call stack,
radeon_driver_load_kms() will then skip runtime pm initialization and
call radeon_driver_unload_kms(), which acquires a runtime pm ref that
is leaked.

Balance by releasing a runtime pm ref in the error path of
radeon_device_init().

Fixes: 10ebc0bc ("drm/radeon: add runtime PM support (v2)")
Cc: Dave Airlie <airlied@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/fa5bb977c1fe00474acedae5b03232dbf0b49410.1465392124.git.lukas@wunner.de

When executing in a PCI passthrough based virtuzliation environment, the
hypervisor will usually attempt to send a PCIe bus reset signal to the
ASIC when the VM reboots. In this scenario, the card is not correctly
initialized, but we still consider it to be posted. Therefore, in a
passthrough based environemnt we should always post the card to guarantee
it is in a good state for driver initialization.

Ported from amdgpu commit:
amdgpu: fix asic initialization for virtualized environments

Cc: Andres Rodriguez <andres.rodriguez@amd.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Seems r600/r700 does not like hard reset while freezing for hibernation
(regression due to 274ad65c which itself
is a fix for hibernation on some GPU families). Until i can debug further
issue with r600, let just disable this for r600/r700 as they are very
similar family and bug affecting one likely affect the other.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NJérôme Glisse <jglisse@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Some GPU block like UVD and VCE require hard reset to be properly
resume if there is no real powerdown of the asic like during various
hibernation step. This patch perform such hard reset.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NJérôme Glisse <jglisse@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This reverts commit e64c952e.

ATPX is the ACPI method for controlling AMD PowerXpress laptops.
There are flags to indicate which methods are supported.  If
the dGPU power down flag is not supported, the driver needs to
implement the dGPU power down manually.  We had previously
always forced the driver to assume the ATPX dGPU power down
was present, but this causes problems on boards where it is
not, leading to GPU hangs when attempting to power down the
dGPU.  Manual dGPU power down is not currently supported in
the Linux driver.  Some laptops indicate that the ATPX
dGPU power down method is not present, but it actually
apparently is.  I'm not sure if this is a bios bug and it should
be set or if there is a reason it was unset and the method should
not be used.  This is not an issue on other OSes since both the
ATPX and the manual driver power down methods are supported.

This is apparently fairly widespread, so just revert for now.

bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=115321
https://bugzilla.kernel.org/show_bug.cgi?id=116581
https://bugzilla.kernel.org/show_bug.cgi?id=116251

Cc: stable@vger.kernel.org

The pci revision id is useful in debugging certain things as
it's part of how SKUs are defined on newer asics.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

I hate doing this but it hurts my eyes to go over code that does not
comply with indentation rules. Only thing that is not only space change
is in atom.c all other files are space indentation issues.
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NJérôme Glisse <jglisse@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Some PX laptops don't provide an ACPI method to control dGPU power.  On
those systems, the driver is responsible for handling the dGPU power
state.  Disable runtime PM on them until support for this is implemented.
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

This reverts commit dbb17a21.

It turns out that commit can cause problems for systems with multiple
GPUs, and causes X to hang on at least a HP Pavilion dv7 with hybrid
graphics.

This got noticed originally in 4.4.4, where this patch had already
gotten back-ported, but 4.5-rc7 was verified to have the same problem.

Alexander Deucher says:
 "It looks like you have a muxed system so I suspect what's happening is
  that one of the display is being reported as connected for both the
  IGP and the dGPU and then the desktop environment gets confused or
  there some sort problem in the detect functions since the mux is not
  switched to the dGPU.  I don't see an easy fix unless Dave has any
  ideas.  I'd say just revert for now"
Reported-by: NJörg-Volker Peetz <jvpeetz@web.de>
Acked-by: NAlexander Deucher <Alexander.Deucher@amd.com>
Cc: Dave Airlie <airlied@gmail.com>
Cc: stable@kernel.org  # wherever dbb17a21 got back-ported
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlexandre Demers <alexandre.f.demers@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Need to call this on resume if displays changes during
suspend in order to properly be notified of changes.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Currently everyone and their dog has their own favourite spelling
for vga_switcheroo. This makes it hard to grep dmesg for log entries
relating to vga_switcheroo. It also makes it hard to find related
source files in the tree.

vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

In

commit 7a3f3d66
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jul 9 23:44:28 2015 +0200

    drm: Check locking in drm_for_each_connector

I added locking checks to drm_for_each_connector but failed that
through drm_helper_connector_dpms -> drm_helper_choose_encoder_dpms
it's used in a few more places in the radeon resume/suspend code.

Fix them up.

Note that we could use the connector iterator macros in there too, but
that's for the future.
Reported-and-tested-by: NBorislav Petkov <bp@alien8.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Everything is evicted from VRAM before suspend, so we need to make
sure all BOs are unpinned and re-pinned after resume. Fixes broken
mouse cursor after resume introduced by commit b9729b17.

[Michel Dänzer: Add pinning BOs on resume]

v2:
[Alex Deucher: merge cursor unpin into fb unpin loop]

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100541
Cc: stable@vger.kernel.org
Reviewed-by: Christian König <christian.koenig@amd.com> (v1)
Signed-off-by: NGrigori Goronzy <greg@chown.ath.cx>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Newer ASICs have more VRAM on average and allocating more GART as
well can have advantages. Also see commit edcd26e8.

Ideally, we should scale GART size based on actual VRAM size, but
that requires significant restructuring of initialization.

v2: extract small helper, apply to error paths
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NGrigori Goronzy <greg@chown.ath.cx>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Laptop with Turks/Thames GPU will freeze if dpm is enabled. It seems
the SMC engine is relying on some state inside the CP engine. CP needs
to chew at least one packet for it to get in good state for dynamic
power management.

This patch simply disabled and re-enable DPM after the ring test which
is enough to avoid the freeze.
Signed-off-by: NJérôme Glisse <jglisse@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Userspace will be able to tell whether a GPU reset occured by comparing
an old referece value of the counter with a new value.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMarek Olšák <marek.olsak@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This adds initial DP 1.2 MST support to radeon, on CAYMAN
and up in theory.

This is off by default.

v2: agd5f:
- add UNIPHY3 offsets
- move atom cmd table code into atombios_encoders.c
- whitespace cleanup
- replace some magic numbers with proper defines
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

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: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

While developing MST support I noticed I often got the wrong data
back from a transaction, in a racy fashion. I noticed the scratch
space wasn't locked against concurrent users.

Based on a patch by Alex, but I've made it a bit more obvious when
things are locked.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org