In an if block for (running == 0) running cannot be non-zero.

v2: agd: remove unused variable
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

In an if block for (running == 0) running cannot be non-zero.

v2: agd: remove unused variable
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

With the previous change, it's safe to let page flips take effect
anytime during a vertical blank period.

This can avoid delaying a flip by a frame in some cases where we get to
radeon_flip_work_func -> adev->mode_info.funcs->page_flip during a
vertical blank period.
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Now we can program a flip during a vertical blank period, if it's the
one targeted by the flip (or a later one). This allows simplifying
radeon_flip_work_func considerably.
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The core will do this for us now.
Signed-off-by: NWolfram Sang <wsa-dev@sang-engineering.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

When this code was written, we didn't retry DP aux transactions on any
error, which required retrying important transactions like this in
individual drivers. Since that's no longer the case, retrying here is
not necessary. As well, we retry any aux transaction on any error 32
times. 7 * 32 = 224, which means this loop causes us to retry grabbing
the dpcd 224 times. This is definitely far more then we actually need to
do.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NLyude <cpaul@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Since it's normal for DRM to retry our aux transaction helpers multiple
times in a row, up to 32 times for each attempted transaction, we're
making a lot of noise that is no longer necessary now that DRM will just
print the return code we give it.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NLyude <cpaul@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Fixes hangs under memory pressure, e.g. running the piglit test
tex3d-maxsize concurrently with other tests.

Fixes: 17d33bc9 ("drm/ttm: drop waiting for idle in ttm_bo_evict.")
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

alloc_workqueue replaces deprecated create_singlethread_workqueue().

Each hardware CRTC has a single flip work queue.
When a radeon_flip_work_func item is queued, it needs to be executed
ASAP because even a slight delay may cause the flip to be delayed by
one refresh cycle.

Hence, a dedicated workqueue with WQ_HIGHPRI set, has been used here
since a delay can cause the outcome to miss the refresh cycle.

Since there are only a fixed number of work items, explicit concurrency
limit is unnecessary here.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Acked-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NBhaktipriya Shridhar <bhaktipriya96@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The drm_gem_object_unreference_unlocked() function tests whether
its argument is NULL and then returns immediately.
Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The message is harmless and confusing.  On PX systems,
there is one ATIF method, but potentially multiple GPUs
leading to an error on the GPU with no backlight control.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=115011Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Hans de Goede <jwrdegoede@fedoraproject.org>

 commit d967be9b ("drm/radeon/ci: disable needless sclk changes")
 introduces an unreachable if(C != C) conditional code section
 flagged by coccinelle script bad_conditional.cocci:

 Add a comment to make it clear that this is intentional.

 Fixes: d967be9b ("drm/radeon/ci: disable needless sclk changes")
Signed-off-by: NNicholas Mc Guire <hofrat@osadl.org>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

If we do it at enable time, it's too late for the feature
checks.

v2: drop .init setting as per Peter's comments

bug: https://bugzilla.kernel.org/show_bug.cgi?id=115321Reviewed-by: NPeter Wu <peter@lekensteyn.nl>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Peter Wu <peter@lekensteyn.nl>

Some of the checks didn't handle frev 2 tables properly.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Same interface as other UNIPHY blocks
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not
disconnections. Because of this, we end up losing hotplug polling for
analog connectors once they get connected.

Easy way to reproduce:
 - Grab a machine with a radeon GPU and a VGA port
 - Plug a monitor into the VGA port, wait for it to update the connector
   from disconnected to connected
 - Disconnect the monitor on VGA, a hotplug event is never sent for the
   removal of the connector.

Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a good
idea since doing VGA polling can sometimes result in having to mess with
the DAC voltages to figure out whether or not there's actually something
there since VGA doesn't have HPD. Doing this would have the potential of
showing visible artifacts on the screen every time we ran a poll while a
VGA display was connected. Luckily, radeon_vga_detect() only resorts to
this sort of polling if the poll is forced, and DRM's polling helper
doesn't force it's polls.

Additionally, this removes some assignments to connector->polled that
weren't actually doing anything.

Cc: stable@vger.kernel.org
Signed-off-by: NLyude <cpaul@redhat.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It isn't used and not waiting for the GPU after scheduling a move is
actually quite dangerous.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

When we want to pipeline accelerated moves we need to wait in the fallback path.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Wait for idle before moving the BO in all drivers implementing
an accelerated move function.

This should keep the current behavior when removing the pre move wait.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Align to the jump table offset. May fix hangs on some
asics with GFX PG enabled.
Reviewed-by: NNicolai Hähnle <nicolai.haehnle@amd.com>
Acked-by: NTom St Denis <tom.stdenis@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Until Dave's patch to support the new hybrid gfx ACPI method goes
upstream, we can fallback to the old ATPX method which seems to
still work.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The ATPX power control method does this for you.
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The platform d3 cold is used to power down the dGPU.
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

hybrid graphics in this case refers to systems which use the new
platform d3 cold ACPI methods as opposed to ATPX for dGPU power
control.
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Now that we handle this correctly, there is no need to force
it.
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

On PX systems without dGPU power control, use PCI_D3hot.
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The runtime pm sequence is different depending on whether or
not the platform supports ATPX dGPU power control.
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

ATPX dGPU power control requires a 200ms delay between
power off and on.  This should fix dGPU failures on
resume from power off.
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

The presence of the power control method should be determined
via the presence of the method in function 0.  However, some
sbioses only set the appropriate bits in function 1 so use
then to override a missing power control function.
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Windows 10 (and some 8.1) systems use standardized
ACPI calls for hybrid laptops to control dGPU power.
Detect those cases and disable the AMD specific ATPX
power control.
Reviewed-by: NHawking Zhang <Hawking.Zhang@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NEdmondo Tommasina <edmondo.tommasina@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The size needs to handle the CP JT and GDS.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The power tables on some variants require different firmware.
This may fix stability issues on some newer CI parts.

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

The power tables on some variants require different firmware.
This may fix stability issues on some newer SI parts.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

radeon leaks a runtime pm ref if at least one CRTC is enabled on unload.
The ref is taken by radeon_crtc_set_config() and held as long as a CRTC
is in use. Fix by turning off all CRTCs on unload.

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/f706b9db319e2bdaf153966a2b95a5d80f67e09b.1465392124.git.lukas@wunner.de

The PCI core calls pm_runtime_forbid() on device probe in pci_pm_init(),
making this the default state when radeon is loaded.
radeon_driver_load_kms() therefore calls pm_runtime_allow(), but there's
no pm_runtime_forbid() in radeon_driver_unload_kms() to balance it. Add
it so that we leave the device in the same state that we found it.

This isn't a bug, it's just good housekeeping. When radeon is first
loaded with runpm=1, then unloaded and loaded again with runpm=0,
pm_runtime_forbid() will be called from radeon_pmops_runtime_idle() or
radeon_pmops_runtime_suspend(), so the behaviour is correct. If there
ever is a third party driver for AMD cards, this commit avoids that it
has to clean up behind radeon.

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/25a3e20b786fd66b10f40fa24c61dd36c33270da.1465392124.git.lukas@wunner.de

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

radeon_driver_load_kms() calls pm_runtime_put_autosuspend() if
radeon_is_px(dev), but radeon_driver_unload_kms() calls
pm_runtime_get_sync() unconditionally. We therefore leak a runtime pm
ref whenever radeon is unloaded on a non-PX machine or if runpm=0. The
GPU will subsequently never runtime suspend after loading radeon again.

Fix by taking the runtime pm ref under the same condition that it was
released on driver load.

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/aaf71106c042126817aeca8b8e54ed468ab61ef7.1465392124.git.lukas@wunner.de