The check on ret is duplicated in two places, it is redundant code.
Remove it.
Addresses-Coverity: ("Logically dead code") Fixes: b94afb61cdae ("drm/amd/powerplay: honor hw limit on fetching metrics data for navi10") Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The SOC15_REG_OFFSET() macro wasn't used, making the soft recovery fail.
v2: use WREG32_SOC15 instead of WREG32 + SOC15_REG_OFFSET
Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Le Ma [Thu, 8 Aug 2019 06:54:12 +0000 (14:54 +0800)]
drm/amdgpu: split athub clock gating from mmhub
Untie the bind of get/set athub CG state from mmhub, for cosmetic fix and Asic
not using mmhub 1.0. Besides, also fix wrong athub CG state in amdgpu_pm_info.
Signed-off-by: Le Ma <le.ma@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Michel Dänzer [Wed, 24 Jul 2019 15:56:28 +0000 (17:56 +0200)]
drm/amdgpu: Update pitch on page flips without DC as well
DC already handles this correctly since amdgpu minor version 31. Bump
the minor version again so that xf86-video-amdgpu can take advantage of
this working without DC as well now.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
David Francis [Wed, 7 Aug 2019 14:25:48 +0000 (10:25 -0400)]
drm/amd/display: Remove drm_dsc_dc.c
This file was accidentally added to the driver during
Navi promotion
Nothing includes it. No makefile attempts to compile it, and
it would fail compilation if they tried
Remove it
Signed-off-by: David Francis <David.Francis@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com>w Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dave Airlie [Mon, 12 Aug 2019 04:20:21 +0000 (14:20 +1000)]
Merge tag 'drm-next-5.4-2019-08-09' of git://people.freedesktop.org/~agd5f/linux into drm-next
drm-next-5.4-2019-08-09:
Same as drm-next-5.4-2019-08-06, but with the
readq/writeq stuff fixed and 5.3-rc3 backmerged.
amdgpu:
- Add navi14 support
- Add navi12 support
- Add Arcturus support
- Enable mclk DPM for Navi
- Misc DC display fixes
- Add perfmon support for DF
- Add scatter/gather display support for Raven
- Improve SMU handling for GPU reset
- RAS support for GFX
- Drop last of drmP.h
- Add support for wiping memory on buffer release
- Allow cursor async updates for fb swaps
- Misc fixes and cleanups
amdkfd:
- Add navi14 support
- Add navi12 support
- Add Arcturus support
- CWSR trap handlers updates for gfx9, 10
- Drop last of drmP.h
- Update MAINTAINERS
radeon:
- Misc fixes and cleanups
- Make kexec more reliable by tearing down the GPU
ttm:
- Add release_notify callback
uapi:
- Add wipe memory on release flag for buffer creation
Tao Zhou [Fri, 9 Aug 2019 07:57:51 +0000 (15:57 +0800)]
drm/amdgpu: remove RREG64/WREG64
atomic 64 bits REG operations are useless currently
Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Tao Zhou [Fri, 9 Aug 2019 07:57:50 +0000 (15:57 +0800)]
drm/amdgpu: implement UMC 64 bits REG operations
implement 64 bits operations via 32 bits interface
v2: make use of lower_32_bits() and upper_32_bits() macros
Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Tao Zhou [Wed, 7 Aug 2019 02:28:54 +0000 (10:28 +0800)]
drm/amdgpu: replace readq/writeq with atomic64 operations
what we really want is a read or write that is guaranteed to be 64 bits
at a time, atomic64 operations are supported on all architectures
Signed-off-by: Tao Zhou <tao.zhou1@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dave Airlie [Fri, 9 Aug 2019 06:04:15 +0000 (16:04 +1000)]
Merge tag 'drm-misc-next-2019-08-08' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 5.4:
UAPI Changes:
- HDCP: Add a Content protection type property
Cross-subsystem Changes:
Core Changes:
- Continue to rework the include dependencies
- fb: Remove the unused drm_gem_fbdev_fb_create function
- drm-dp-helper: Make the link rate calculation more tolerant to
non-explicitly defined, yet supported, rates
- fb-helper: Map DRM client buffer only when required, and instanciate a
shadow buffer when the device has a dirty function or says so
- connector: Add a helper to link the DDC adapter used by that connector to
the userspace
- vblank: Switch from DRM_WAIT_ON to wait_event_interruptible_timeout
- dma-buf: Fix a stack corruption
- ttm: Embed a drm_gem_object struct to make ttm_buffer_object a
superclass of GEM, and convert drivers to use it.
- hdcp: Improvements to report the content protection type to the
userspace
Driver Changes:
- Remove drm_gem_prime_import/export from being defined in the drivers
- Drop DRM_AUTH usage from drivers
- Continue to drop drmP.h
- Convert drivers to the connector ddc helper
- ingenic: Add support for more panel-related cases
- komeda: Support for dual-link
- lima: Reduce logging
- mpag200: Fix the cursor support
- panfrost: Export GPU features register to userspace through an ioctl
- pl111: Remove the CLD pads wiring support from the DT
- rockchip: Rework to use DRM PSR helpers, fix a bug in the VOP_WIN_GET
macro
- sun4i: Improve support for color encoding and range
- tinydrm: Rework SPI support, improve MIPI-DBI support, move to drm/tiny
- vkms: Rework of the CRC tracking
- bridges:
- sii902x: Add support for audio graph card
- tc358767: Rework AUX data handling code
- ti-sn65dsi86: Add Debugfs and proper DSI mode flags support
- panels
- Support for GiantPlus GPM940B0, Sharp LQ070Y3DG3B, Ortustech
COM37H3M, Novatek NT39016, Sharp LS020B1DD01D, Raydium RM67191,
Boe Himax8279d, Sharp LD-D5116Z01B
- Conversion of the device tree bindings to the YAML description
- jh057n00900: Rework the enable / disable path
- fbdev:
- ssd1307fb: Support more devices based on that controller
John Keeping [Wed, 3 Jul 2019 09:51:11 +0000 (10:51 +0100)]
drm/rockchip: fix VOP_WIN_GET macro
Commit 9a61c54b9bff ("drm/rockchip: vop: group vop registers") seems to
have unintentionally changed the defintion of this macro. Since it is
unused, this was not spotted but any attempt to use it results in
compilation errors.
Emil Velikov [Mon, 27 May 2019 08:17:35 +0000 (09:17 +0100)]
drm/msm: drop DRM_AUTH usage from the driver
The authentication can be circumvented, by design, by using the render
node.
From the driver POV there is no distinction between primary and render
nodes, thus we can drop the token.
Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: freedreno@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190527081741.14235-7-emil.l.velikov@gmail.com
Clang warns (only Navi warning shown but Arcturus warns as well):
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1534:4: warning:
variable 'asic_default_power_limit' is used uninitialized whenever '?:'
condition is false [-Wsometimes-uninitialized]
smu_read_smc_arg(smu, &asic_default_power_limit);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:588:3: note:
expanded from macro 'smu_read_smc_arg'
((smu)->funcs->read_smc_arg? (smu)->funcs->read_smc_arg((smu), (arg)) : 0)
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1550:30: note:
uninitialized use occurs here
smu->default_power_limit = asic_default_power_limit;
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1534:4: note:
remove the '?:' if its condition is always true
smu_read_smc_arg(smu, &asic_default_power_limit);
^
drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:588:3: note:
expanded from macro 'smu_read_smc_arg'
((smu)->funcs->read_smc_arg? (smu)->funcs->read_smc_arg((smu), (arg)) : 0)
^
drivers/gpu/drm/amd/amdgpu/../powerplay/navi10_ppt.c:1517:35: note:
initialize the variable 'asic_default_power_limit' to silence this
warning
uint32_t asic_default_power_limit;
^
= 0
1 warning generated.
As the code is currently written, if read_smc_arg were ever NULL, arg
would fail to be initialized but the code would continue executing as
normal because the return value would just be zero.
There are a few different possible solutions to resolve this class
of warnings which have appeared in these drivers before:
1. Assume the function pointer will never be NULL and eliminate the
wrapper macros.
2. Have the wrapper macros initialize arg when the function pointer is
NULL.
3. Have the wrapper macros return an error code instead of 0 when the
function pointer is NULL so that the callsites can properly bail out
before arg can be used.
4. Initialize arg at the top of its function.
Number four is the path of least resistance right now as every other
change will be driver wide so do that here. I only make the comment
now as food for thought.
Fixes: b4af964e75c4 ("drm/amd/powerplay: make power limit retrieval as asic specific") Link: https://github.com/ClangBuiltLinux/linux/issues/627 Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
amdgpu_ip_block.status.hw for GMC wasn't set to
false on suspend during GPU reset and so on resume gmc_v9_0_resume
wasn't called.
Caused by 'drm/amdgpu: fix double ucode load by PSP(v3)'
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Likun Gao [Fri, 2 Aug 2019 07:18:57 +0000 (15:18 +0800)]
drm/amdgpu: pin the csb buffer on hw init for gfx v8
Without this pin, the csb buffer will be filled with inconsistent
data after S3 resume. And that will causes gfx hang on gfxoff
exit since this csb will be executed then.
Signed-off-by: Likun Gao <Likun.Gao@amd.com> Tested-by: Paul Gover <pmw.gover@yahoo.co.uk> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Reviewed-by: Xiaojie Yuan <xiaojie.yuan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Block immediate flips for non-fast updates
[Why]
Underflow can occur in the case where we change buffer pitch, DCC state,
rotation or mirroring for a plane while also performing an immediate
flip. It can also generate a p-state warning stack trace on DCN1 which
is typically observed during the cursor handler pipe locking because of
how frequent cursor updates can occur.
[How]
Store the update type on each CRTC - every plane will have access to
the CRTC state if it's flipping. If the update type is not
UPDATE_TYPE_FAST then the immediate flip should be disallowed.
No changes to the target vblank sequencing need to be done, we just
need to ensure that the surface registers do a double buffered update.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <david.francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
drm/amd/display: Validate dc_plane_info and dc_plane_size in atomic check
[Why]
Pitch, DCC, rotation and mirroring can result in updates that are not
UPDATE_TYPE_FAST but UPDATE_TYPE_MED instead. DC needs dc_plane_info
and dc_plane_size to make this determination and we aren't currently
passing this into DC during atomic check.
Underflow (visible or non-visible) can occur if we don't validate this
correctly. This also will generally trigger p-state warnings, typically
via the cursor handler when locking.
[How]
Get the framebuffer tiling flags and generate the required structures
for DC in dm_determine_update_type_for_commit.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: David Francis <david.francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Brian Starkey [Tue, 6 Aug 2019 12:46:22 +0000 (13:46 +0100)]
drm/crc-debugfs: Add notes about CRC<->commit interactions
CRC generation can be impacted by commits coming from userspace, and
enabling CRC generation may itself trigger a commit. Add notes about
this to the kerneldoc.
Changes since v1:
- Clarified that anything that would disable CRCs counts as a full
modeset, and so userspace needs to reconfigure after full modesets
Changes since v2:
- Add these notes
- Rebase onto drm-misc-next (trivial conflict in comment)
Signed-off-by: Brian Starkey <brian.starkey@arm.com> Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link:- https://patchwork.freedesktop.org/patch/321974/
Ramalingam C [Thu, 1 Aug 2019 11:41:18 +0000 (17:11 +0530)]
drm/i915: update the hdcp state with uevent
drm function to update the content protection property state and to
generate a uevent is invoked from the intel hdcp property work.
Hence whenever kernel changes the property state, userspace will be
updated with a uevent.
v2:
state update is moved into drm function [daniel]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320965/?series=57232&rev=14
Ramalingam C [Thu, 1 Aug 2019 11:41:17 +0000 (17:11 +0530)]
drm/hdcp: update content protection property with uevent
drm function is defined and exported to update a connector's
content protection property state and to generate a uevent along
with it.
Pekka have completed the Weston DRM-backend review in
https://gitlab.freedesktop.org/wayland/weston/merge_requests/48
and the UAPI for HDCP 2.2 looks good.
The userspace is accepted in Weston.
v2:
Update only when state is different from old one.
v3:
KDoc is added [Daniel]
v4:
KDoc is extended bit more [pekka]
v5:
Uevent usage is documented at kdoc of "Content Protection" also
[pekka]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320963/?series=57232&rev=14
Ramalingam C [Thu, 1 Aug 2019 11:41:16 +0000 (17:11 +0530)]
drm: uevent for connector status change
DRM API for generating uevent for a status changes of connector's
property.
This uevent will have following details related to the status change:
HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
Pekka have completed the Weston DRM-backend review in
https://gitlab.freedesktop.org/wayland/weston/merge_requests/48
and the UAPI for HDCP 2.2 looks good.
The userspace is accepted in Weston.
v2:
Minor fixes at KDoc comments [Daniel]
v3:
Check the property is really attached with connector [Daniel]
v4:
Typos and string length suggestions are addressed [Sean]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Sean Paul <sean@poorly.run> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320961/?series=57232&rev=14
Ramalingam C [Thu, 1 Aug 2019 11:41:15 +0000 (17:11 +0530)]
drm/i915: Attach content type property
Attaches the content type property for HDCP2.2 capable connectors.
Implements the update of content type from property and apply the
restriction on HDCP version selection.
Need ACK for content type property from userspace consumer.
v2:
s/cp_content_type/content_protection_type [daniel]
disable at hdcp_atomic_check to avoid check at atomic_set_property
[Maarten]
v3:
s/content_protection_type/hdcp_content_type [Pekka]
v4:
hdcp disable incase of type change is moved into commit [daniel].
v5:
Simplified the Type change procedure. [Daniel]
v6:
Type change with UNDESIRED state is ignored.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320959/?series=57232&rev=14
Ramalingam C [Thu, 1 Aug 2019 11:41:14 +0000 (17:11 +0530)]
drm: Add Content protection type property
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected display wires.
But Type 1 content can be rendered only on HDCP2.2 protected paths.
So when a userspace sets this property to Type 1 and starts the HDCP
enable, kernel will honour it only if HDCP2.2 authentication is through
for type 1. Else HDCP enable will be failed.
Pekka have completed the Weston DRM-backend review in
https://gitlab.freedesktop.org/wayland/weston/merge_requests/48
and the UAPI for HDCP 2.2 looks good.
The userspace is accepted in Weston.
v2:
cp_content_type is replaced with content_protection_type [daniel]
check at atomic_set_property is removed [Maarten]
v3:
%s/content_protection_type/hdcp_content_type [Pekka]
v4:
property is created for the first requested connector and then reused.
[Danvet]
v5:
kernel doc nits addressed [Daniel]
Rebased as part of patch reordering.
v6:
Kernel docs are modified [pekka]
v7:
More details in Kernel docs. [pekka]
v8:
Few more clarification into kernel doc of content type [pekka]
v9:
Small fixes in coding style.
v10:
Moving DRM_MODE_HDCP_CONTENT_TYPEx definition to drm_hdcp.h [pekka]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320957/?series=57232&rev=14