Otherwise there may be potential SMU performance issues.
v2: fix commit description and coding style
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Rex Zhu <rex.zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The argument was set wrongly. Fast/slow switch was asked when there is
actually a slow/fast switch needed.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Rex Zhu <rex.zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Remove local variable 'priv' to fix GCC warning:
drivers/gpu/drm/exynos/exynos_mixer.c: In function 'mixer_initialize':
drivers/gpu/drm/exynos/exynos_mixer.c:840:29: warning: variable 'priv' set but not used [-Wunused-but-set-variable]
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Add calls to pm_runtime_force_{suspend,resume} as SYSTEM_SLEEP_PM_OPS for
all drivers for the real Exynos DRM hardware modules. This ensures that
the resources will be released for the system PM suspend/resume cycle.
Exynos DRM core already takes care of suspending the whole display pipeline
before PM callbacks of the real devices are called.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
In the current code, exynos_drm_suspend() function is called after all
real devices (CRTCs, Encoders, etc) are suspended, because Exynos DRM
virtual platform device is created as last device in the system (as
a part of DRM registration). None of the devices for real hardware
modules has its own system suspend/resume callbacks, so it doesn't
change any order of the executed code, but it has a side-effect:
runtime PM callbacks for real devices are not executed, because those
devices are considered by PM core as already suspended. This might
cause issues on boards with complex pipelines, where something
depends on the runtime PM state of the given device.
To ensure that exynos_drm_suspend() is called before any suspend
callback from the real devices, assign it to .prepare callback. Same
for exynos_drm_resume(), using .complete callback ensures that all
real devices have been resumed when calling it.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The virtual Exynos DRM device has no runtime PM enabled, so checking
for its runtime suspended state is useless.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Replace all calls to exynos_drm_gem_get_{dma_addr,size}, by a simpler
function exynos_drm_gem_get(). This lets the caller to get access to
exynos_drm_gem object and extract any information about GEM object
without searching object tree for getting each parameter.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Exynos G2D driver is the last client of the custom Exynos 'sub-driver'
framework. In the current state it doesn't really resolve any of the
issues it has been designed for, as Exynos DRM is already built only
as a single kernel module. Remove the custom 'sub-driver' framework and
simply use generic component framework also in G2D driver.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Fixups
- Fix several problems to IPPv2 merged to mainline recentely.
. An align problem of width size that IPP driver incorrectly
calculated the real buffer size.
. Horizontal and vertical flip problem.
. Per-plane global alpha for XRGB modes.
. Incorrect variant of the YUV modes.
- Fix plane overlapping problem.
. The stange order of overlapping planes on XRGB modes
by setting global alpha value to maximum value.
Cleanup
- Rename a enum type, drm_ipp_size_id, to one specific to Exynos,
drm_exynos_ipp_limit_type.
- Replace {un/reference} with {put,get} functions.
. it replaces several reference/unreference functions with Linux
kernel nameing standard.
Set possible_clones field to report that the writeback connector and
the one driving the display could be enabled at the same time.
Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Older version of this patch series reported writeback as disconnected
to avoid confusing userspace not aware of writeback connectors.
However, the version that got merged uses a special cap
(DRM_CLIENT_CAP_WRITEBACK_CONNECTORS) for this purpose.
This helps us avoid some special handling of writeback connector
in drm_helper_probe_single_connector_modes, see [1].
https://lists.freedesktop.org/archives/dri-devel/2018-July/183144.html
Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Pull vfs fixes from Al Viro:
"Fix several places that screw up cleanups after failures halfway
through opening a file (one open-coding filp_clone_open() and getting
it wrong, two misusing alloc_file()). That part is -stable fodder from
the 'work.open' branch.
And Christoph's regression fix for uapi breakage in aio series;
include/uapi/linux/aio_abi.h shouldn't be pulling in the kernel
definition of sigset_t, the reason for doing so in the first place had
been bogus - there's no need to expose struct __aio_sigset in
aio_abi.h at all"
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
aio: don't expose __aio_sigset in uapi
ocxlflash_getfile(): fix double-iput() on alloc_file() failures
cxl_getfile(): fix double-iput() on alloc_file() failures
drm_mode_create_lease_ioctl(): fix open-coded filp_clone_open()
Use the newly split ip suspend functions to do suspend displays
first (to deal with atomic so that FBs can be unpinned before
attempting to evict vram), then evict vram, then suspend the
other IPs. Also move the non-DC pinning code to only be
called in the non-DC cases since atomic should take care of
DC.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107065
Fixes: e00fb85 drm: Stop updating plane->crtc/fb/old_fb on atomic drivers
Acked-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-and-tested-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We need to do some IPs earlier to deal with ordering issues
similar to how resume is split into two phases. Do DCE first
to deal with atomic, then do the rest.
Acked-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-and-tested-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Check the supported functions mask before calling the bios
requests method.
Reviewed-by: Jim Qu <Jim.Qu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Problem:
amdgpu_ttm_set_buffer_funcs_status destroys adev->mman.entity on suspend
without releasing adev->mman.bdev.man[TTM_PL_VRAM].move fence
so on resume the new drm_sched_entity.fence_context causes
the warning against the old fence context which is different.
Fix:
When destroying sched_entity in amdgpu_ttm_set_buffer_funcs_status
release man->move and set the pointer to NULL.
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This patch removes the usage of console_(un)lock
by replacing drm_fb_helper_set_suspend() to
drm_fb_helper_set_suspend_unlocked() which locks and
unlocks the console instead of locking ourselves.
Signed-off-by: Shirish S <shirish.s@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Except special naming as *_in_khz, The default clock unit in powerplay
is in 10KHz. so need to * 10 as expecting clock frequency in display
is in kHz.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
While the console_lock is held, console output will be buffered, till
its unlocked it wont be emitted, hence its ideal to unlock sooner to enable
debugging/detecting/fixing of any issue in the remaining sequence of events
in resume path.
The concern here is about consoles other than fbcon on the device,
e.g. a serial console
[How]
This patch restructures the console_lock, console_unlock around
amdgpu_fbdev_set_suspend() and moves this new block appropriately.
V2: Kept amdgpu_fbdev_set_suspend after pci_set_power_state
V3: Updated the commit message to clarify the real concern that this patch
addresses.
V4: code clean-up.
V5: fixed return value
Signed-off-by: Shirish S <shirish.s@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
More features for 4.19:
- Map processes to vmids for debugging GPUVM faults
- Raven gfxoff fixes
- Initial gfxoff support for vega12
- Use defines for interrupt sources rather than magic numbers
- DC aux fixes
- Finish DC logging TODO
- Add more DC debugfs interfaces for conformance testing
- Add CRC support for DCN
- Scheduler rework in preparation for load balancing
- Unify common smu9 code
- Clean up UVD instancing support
- ttm cleanups
- Misc fixes and cleanups
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180719194001.3488-1-alexander.deucher@amd.com
On GEM side:
- GuC related fixes (Chris, Michal)
- GTT read-only pages support (Jon, Chris)
- More selftests fixes (Chris)
- More GPU reset improvements (Chris)
- Flush caches after GGTT writes (Chris)
- Handle recursive shrinker for vma->last_active allocation (Chris)
- Other execlists fixes (Chris)
On Display side:
- GLK HDMI fix (Clint)
- Rework and cleanup around HPD pin (Ville)
- Preparation work for Display Stream Compression support coming on ICL (Anusha)
- Nuke LVDS lid notification (Ville)
- Assume eDP is always connected (Ville)
- Kill intel panel detection (Ville)
Signed-off-by: Dave Airlie <airlied@redhat.com>
# gpg: Signature made Fri 20 Jul 2018 01:51:45 AM AEST
# gpg: using RSA key FA625F640EEB13CA
# gpg: Good signature from "Rodrigo Vivi <rodrigo.vivi@intel.com>"
# gpg: aka "Rodrigo Vivi <rodrigo.vivi@gmail.com>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6D20 7068 EEDD 6509 1C2C E2A3 FA62 5F64 0EEB 13CA
# Conflicts:
# drivers/gpu/drm/i915/intel_lrc.c
Link: https://patchwork.freedesktop.org/patch/msgid/20180719171257.GA12199@intel.com
drm-misc-next for 4.19:
Core Changes:
- add support for DisplayPort CEC-Tunneling-over-AUX (Hans Verkuil)
- more doc updates (Daniel Vetter)
- fourcc: Add is_yuv field to drm_format_info (Ayan Kumar Halder)
- dma-buf: correctly place BUG_ON (Michel Dänzer)
Driver Changes:
- more vkms support(Rodrigo Siqueira)
- many fixes and small improments to all drivers
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180718200826.GA20165@juma
The whole handle, filp and entity handling is superfluous here.
We should have reviewed that more thoughtfully. It looks like somebody
just made the code instance aware without knowing the background.
v2: fix one more missed case in amdgpu_uvd_suspend
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Allowing CONFIG_DRM_AMD_DC_DCN1_0 to be disabled on X86 was an
opportunity for display with Raven Ridge accidentally not working.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use the newly added irq source defines rather than magic numbers
for smu7 thermal interrupts.
Rewiewed-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Rex Zhu <rezhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
There's a race between idling the engine and finishing off the last
tasklet (as we may kick the tasklets after declaring an individual
engine idle). However, since we do not need to access the device until
we try to submit to the ELSP register (processing the CSB just requires
normal CPU access to the HWSP, and when idle we should not need to
submit!) we can defer the assertion unto that point. The assertion is
still useful as it does verify that we do hold the longterm GT wakeref
taken from request allocation until request completion.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107274
Fixes: 9512f985c3 ("drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180719075029.28643-1-chris@chris-wilson.co.uk
We make a decision at module load whether to use the GuC backend or not,
but lose that setup across set-wedge. Currently, the guc doesn't
override the engine->set_default_submission hook letting execlists sneak
back in temporarily on unwedging leading to an unbalanced park/unpark.
v2: Remove comment about switching back temporarily to execlists on
guc_submission_disable(). We currently only call disable on shutdown,
and plan to also call disable before suspend and reset, in which case we
will either restore guc submission or mark the driver as wedged, making
the reset back to execlists pointless.
v3: Move reset.prepare across
Fixes: 63572937ce ("drm/i915/execlists: Flush pending preemption events during reset")
Testcase: igt/drv_module_reload/basic-reload-inject
Testcase: igt/gem_eio
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180717202932.1423-1-chris@chris-wilson.co.uk
Workaround for issues seen on systems with large amounts of RAM, caused
by display not supporting the same physical address limits as the other
parts of the GPU.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This was causing problems on a system with a large amount of RAM, where
display push buffers were being fetched incorrectly when placed in high
system memory addresses.
While this commit will resolve the issue on that particular system, the
issue will be avoided completely with another patch to more fully solve
problems with display and large amounts of system memory on Pascal.
It's still probably a good idea to disable this to prevent weird issues
in the future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
