- 09 Apr, 2021 27 commits
-
-
Evan Quan authored
The RLC was put into a wrong state on runtime suspend. Thus the RLC autoload will fail on the succeeding runtime resume. By adding an intermediate PPSMC_MSG_PrepareMp1ForUnload(some GC hard reset involved, designed for PnP), we can bring RLC back into the desired state. V2: integrate INTERRUPTS_ENABLED flag clearing into current mp1 state set routines Signed-off-by:Evan Quan <evan.quan@amd.com> Reviewed-by:
Lijo Lazar <lijo.lazar@amd.com> Reviewed-by:
Guchun Chen <guchun.chen@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Lijo Lazar authored
Enable clockgating for VCN and JPEG blocks on aldebaran Signed-off-by:
Hawking Zhang <Hawking.Zhang@amd.com> Acked-by:
-
Bhaskar Chowdhury authored
s/proces/process/ Signed-off-by:
Bhaskar Chowdhury <unixbhaskar@gmail.com> Signed-off-by:
-
Bhaskar Chowdhury authored
s/traing/training/ ...Plus the entire sentence construction for better readability. Signed-off-by:
-
Daniel Gomez authored
If userptr pages have been pinned but not bounded, they remain uncleared. Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Daniel Gomez <daniel@qtec.com> Signed-off-by:
-
Daniel Gomez authored
If userptr pages have been pinned but not bounded, they remain uncleared. Reviewed-by:
-
Alex Deucher authored
GFX is in gfxoff mode during s0ix so we shouldn't need to actually tear anything down and restore it. Acked-by:
-
Alex Deucher authored
We handle it properly within the CG/PG functions directly now. Acked-by:
-
Pratik Vishwakarma authored
Not needed as the device is in gfxoff state so the CG/PG state is handled just like it would be for gfxoff during runtime gfxoff. This should also prevent delays on resume. Reworked from Pratik's original patch (Alex) Acked-by:
Pratik Vishwakarma <Pratik.Vishwakarma@amd.com>
-
Alex Deucher authored
Provide and explanation as to why we skip GFX and PSP for S0ix. GFX goes into gfxoff, same as runtime, so no need to tear down and re-init. PSP is part of the always on state, so no need to touch it. Acked-by:
-
Alex Deucher authored
The SMU expects CGPG to be enabled when entering S0ix. with this we can re-enable SMU suspend. Acked-by:
-
Alex Deucher authored
This really needs to be done to properly tear down the device. SMC, PSP, and GFX are still problematic, need to dig deeper into what aspect of them that is problematic. Acked-by:
-
Alex Deucher authored
No functional change. v2: use correct dev v3: rework Reviewed-by:
-
Alex Deucher authored
Move the non-DC specific code into the DCE IP blocks similar to how we handle DC. This cleans up the common suspend and resume pathes. Reviewed-by:
-
Alex Deucher authored
Vram is system memory, so no need to evict. v2: use PM_EVENT messages v3: use correct dev v4: use driver flags Reviewed-by:
-
Alex Deucher authored
Set flags at the top level pmops callbacks to track state. This cleans up the current set of flags and properly handles S4 on S0ix capable systems. Reviewed-by:
-
Prike Liang authored
During system hibernation suspend still need un-gate gfx CG/PG firstly to handle HW status check before HW resource destory. Signed-off-by:
Prike Liang <Prike.Liang@amd.com> Acked-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Alex Deucher authored
There's no need to keep vgaswitcheroo around for HG systems. They don't use muxes and their power control is handled via ACPI. Reviewed-by:
-
Alex Deucher authored
Once the device has runtime suspended, we don't need to power it back up again for system suspend. Likewise for resume, we don't to power up the device again on resume only to power it back off again via runtime pm because it's still idle. v2: add DPM_FLAG_SMART_PREPARE as well Reviewed-by:
-
Alex Deucher authored
as per: https://www.kernel.org/doc/html/latest/driver-api/pm/devices.html The prepare callback is required to support the DPM_FLAG_SMART_SUSPEND driver flag. This allows runtime pm to auto complete when the system goes into suspend avoiding a wake up on suspend and on resume. Apply this for hybrid gfx and BOCO systems where d3cold is provided by the ACPI platform. v2: check if device is runtime suspended in prepare. Reviewed-by:
-
Alex Deucher authored
Add new DID. Reviewed-by:
-
Alex Deucher authored
Added a new parameter and forgot to update the documentation. Fixes: b6f91fc1 ("drm/amdgpu/display: buffer INTERRUPT_LOW_IRQ_CONTEXT interrupt work") Reviewed-by:
Xiaogang Chen <xiaogang.chen@amd.com> Signed-off-by:
-
Nirmoy Das authored
KIQ ring is being operated by kfd as well as amdgpu. KFD is using kiq lock, we should the same from amdgpu side as well. Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Acked-by:
-
Xiaojian Du authored
This reverts commit 33cf440d. And it will enable mode-2 gpu reset for vangogh, it asks PSP firmware version is 00.1A.00.0F or newer. Signed-off-by:
Xiaojian Du <Xiaojian.Du@amd.com> Reviewed-by:
-
Dennis Li authored
When recovery thread has begun GPU reset, there should be not other threads to access hardware, otherwise system randomly hang. v2 (chk): rewritten from scratch, use trylock and lockdep instead of hand wiring the logic. v3: add in_irq check v4: change to check in_task Signed-off-by:
Dennis Li <Dennis.Li@amd.com> Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 5.13: UAPI Changes: Cross-subsystem Changes: Core Changes: - bridge: Fix Kconfig dependency - cmdline: Refuse zero width/height mode - ttm: Ignore signaled move fences, ioremap buffer according to mem caching settins Driver Changes: - Conversions to sysfs_emit - tegra: Don't register DP AUX channels before connectors - zynqmp: Fix for an out-of-bound (but within struct padding) memset Signed-off-by:Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210409090020.jroa2d4p4qansrpa@gilmour
-
Tian Tao authored
Fix the following coccicheck warning: drivers/gpu/drm/panel//panel-tpo-td043mtea1.c:217:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/panel//panel-tpo-td043mtea1.c:189:8-16: WARNING: use scnprintf or sprintf Signed-off-by:
Tian Tao <tiantao6@hisilicon.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1617069288-8317-1-git-send-email-tiantao6@hisilicon.com
-
- 08 Apr, 2021 13 commits
-
-
Lyude Paul authored
Checkpatch was complaining about this - there's no need for us to print errors when kzalloc() fails, as kzalloc() will already WARN for us. So, let's fix that before converting things to make checkpatch happy. Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: Robert Foss <robert.foss@linaro.org> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210326203807.105754-20-lyude@redhat.com
-
Lyude Paul authored
Since we're about to move drm_dp_helper.c over to drm_dbg_*(), we'll want to make sure that we can also add ratelimited versions of these macros in order to retain some of the previous debugging output behavior we had. However, as I was preparing to do this I noticed that the current rate limited macros we have are kind of bogus. It looks like when I wrote these, I didn't notice that we'd always be calling __ratelimit() even if the debugging message we'd be printing would normally be filtered out due to the relevant DRM debugging category being disabled. So, let's fix this by making sure to check drm_debug_enabled() in our ratelimited macros before calling __ratelimit(), and start using drm_dev_printk() in order to print debugging messages since that will save us from doing a redundant drm_debug_enabled() check. And while we're at it, let's move the code for this into another macro that we can reuse for defining new ratelimited DRM debug macros more easily. v2: * Make sure to use tabs where possible in __DRM_DEFINE_DBG_RATELIMITED() Signed-off-by:
-
Lyude Paul authored
As pointed out by the documentation for drm_dp_aux_register(), drm_dp_aux_init() should be used in situations where the AUX channel for a display driver can potentially be registered before it's respective DRM driver. This is the case with Tegra, since the DP aux channel exists as a platform device instead of being a grandchild of the DRM device. Since we're about to add a backpointer to a DP AUX channel's respective DRM device, let's fix this so that we don't potentially allow userspace to use the AUX channel before we've associated it with it's DRM connector. Signed-off-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210326203807.105754-3-lyude@redhat.com
-
Lyude Paul authored
* Make sure that struct members are referred to using @, otherwise they won't be formatted as such * Make sure to refer to other struct types using & so they link back to each struct's definition * Make sure to precede constant values with % so they're formatted correctly Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210326203807.105754-2-lyude@redhat.com
-
Christian König authored
Just fix a warning. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Fixes: f2f12eb9 ("drm/scheduler: provide scheduler score externally") Reviewed-by:
-
Guobin Huang authored
spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than explicitly calling spin_lock_init(). Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Guobin Huang <huangguobin4@huawei.com> Signed-off-by:
-
Wan Jiabing authored
struct drm_gem_object is declared twice. One is declared at 40th line. The blew one is not needed. Remove the duplicate. Signed-off-by:
Wan Jiabing <wanjiabing@vivo.com> Signed-off-by:
-
Dan Carpenter authored
The dp->train_set[] for this driver is only two characters, not four so this memsets too much. Fortunately, this ends up corrupting a struct hole and not anything important. Fixes: d76271d2 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Dafna Hirschfeld authored
fix 's/controller/controllers/' in the sentence: Most display controller handle display connectors... Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by:
-
Oak Zeng authored
If tbo.mem.bus.caching is cached, buffer is intended to be mapped as cached from CPU. Map it with ioremap_cache. This wasn't necessary before as device memory was never mapped as cached from CPU side. It becomes necessary for aldebaran as device memory is mapped cached from CPU. Signed-off-by:
Oak Zeng <Oak.Zeng@amd.com> Reviewed-by:
-
Felix Kuehling authored
Move fences that have already signaled should not prevent memory allocations with no_wait_gpu. Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
-
David Stevens authored
Allocate a new private stub fence in drm_syncobj_assign_null_handle, instead of using a static stub fence. When userspace creates a fence with DRM_SYNCOBJ_CREATE_SIGNALED or when userspace signals a fence via DRM_IOCTL_SYNCOBJ_SIGNAL, the timestamp obtained when the fence is exported and queried with SYNC_IOC_FILE_INFO should match when the fence's status was changed from the perspective of userspace, which is during the respective ioctl. When a static stub fence started being used in by these ioctls, this behavior changed. Instead, the timestamp returned by SYNC_IOC_FILE_INFO became the first time anything used the static stub fence, which has no meaning to userspace. Signed-off-by:
David Stevens <stevensd@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210408095428.3983055-1-stevensd@google.comReviewed-by:
-
Zhang Jianhua authored
If CONFIG_DRM_LONTIUM_LT8912B=m, the following errors will be seen while compiling lontium-lt8912b.c drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_hard_power_on’: drivers/gpu/drm/bridge/lontium-lt8912b.c:252:2: error: implicit declaration of function ‘gpiod_set_value_cansleep’; did you mean ‘gpio_set_value_cansleep’? [-Werror=implicit-function-declaration] gpiod_set_value_cansleep(lt->gp_reset, 0); ^~~~~~~~~~~~~~~~~~~~~~~~ gpio_set_value_cansleep drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_parse_dt’: drivers/gpu/drm/bridge/lontium-lt8912b.c:628:13: error: implicit declaration of function ‘devm_gpiod_get_optional’; did you mean ‘devm_gpio_request_one’? [-Werror=implicit-function-declaration] gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); ^~~~~~~~~~~~~~~~~~~~~~~ devm_gpio_request_one drivers/gpu/drm/bridge/lontium-lt8912b.c:628:51: error: ‘GPIOD_OUT_HIGH’ undeclared (first use in this function); did you mean ‘GPIOF_INIT_HIGH’? gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); ^~~~~~~~~~~~~~ GPIOF_INIT_HIGH Signed-off-by:Zhang Jianhua <zhangjianhua18@huawei.com> Reviewed-by:
-
