Per FW requirement, replace mode2 with mode1.
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
b/drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c
ind
+amd-gfx
On Thu, Jun 13, 2024 at 1:59 AM Marek Olšák wrote:
>
> Hi Thomas,
>
> Commit 9eac534db0013aff9b9124985dab114600df9081 as per the title
> breaks (crashes?) lightdm (login screen) such that all I get is the
> terminal. It's also reproducible with tag v6.9 where the commit is
> present.
>
>
If the lid on a laptop is closed when eDP connectors are populated
then it remains enabled when the initial framebuffer configuration
is built.
When creating the initial framebuffer configuration detect the
lid status and if it's closed disable any eDP connectors.
Also set up a workqueue to monit
If gpu is recovering, clear all message reset flags
in fifo and wait for gpu to complete recovery.
Signed-off-by: YiPeng Chai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/a
If the number of messages to be processed in the fifo exceeds
the threshold, it will not continue to wait for the DE data
to be ready.
Signed-off-by: YiPeng Chai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 13 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 4 +++-
2 files changed, 16
Add completion to wait for gpu to complete reset.
Signed-off-by: YiPeng Chai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 12
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/a
To avoid resetting the gpu repeatedly, clear all
message reset flags in the fifo before the first
gpu reset.
Signed-off-by: YiPeng Chai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 59 -
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/am
1. Cannot add messages to fifo in gpu reset mode.
2. Only when the message is successfully saved to the
fifo, the thread can be awakened.
Signed-off-by: YiPeng Chai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 16 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_umc.c | 18 +++---
[AMD Official Use Only - AMD Internal Distribution Only]
Reviewed-by: Kenneth Feng
-Original Message-
From: amd-gfx On Behalf Of Aurabindo
Pillai
Sent: Wednesday, June 12, 2024 3:23 AM
To: amd-gfx@lists.freedesktop.org
Cc: Siqueira, Rodrigo ; Wentland, Harry
; Deucher, Alexander ;
P
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call drm_atomic
Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown(), or in this case the
non-atomic equivalent drm_helper_force_disable_all(), at system
shutdown time and at driver remove time. This is important because
drm_helper_force_disable_all()
This patch series is the leftovers of a patch series sent in September
2023 [1] in an attempt to get some of the patches landed finally.
This patch series originally came about after a _long_ discussion
between me and Maxime Ripard in response to a different patch I sent
out [2]. As part of that
On Wed, Jun 12, 2024 at 04:37:12PM -0300, André Almeida wrote:
> Different planes may have different capabilities of doing async flips,
> so create a field to let drivers allow async flip per plane type.
>
> Signed-off-by: André Almeida
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
> drive
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 03d44168cbd7fc57d5de56a3730427db758fc7f6 Add linux-next specific
files for 20240612
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202406130139.tv8i316r-...@intel.com
Error
From: Xiaogang Chen
Current kfd/svm driver acquires mm's mmap write lock before update
mm->notifier_subscriptions->itree. This tree is already protected
by mm->notifier_subscriptions->lock at mmu notifier. Each process mm interval
tree update from different components in kernel go to mmu interval
On Wed, Jun 12, 2024 at 04:37:12PM -0300, André Almeida wrote:
> Different planes may have different capabilities of doing async flips,
> so create a field to let drivers allow async flip per plane type.
>
> Signed-off-by: André Almeida
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
> drive
amdgpu can handle async flips on overlay planes, so mark it as true
during the plane initialization.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.
Hi,
AMD hardware can do async flips with overlay planes, so this patchset does a
small redesign to allow drivers to choose per plane type if they can or cannot
do async flips.
It also allows async commits with IN_FENCE_ID in any driver.
Changes from v4:
- Rebased on top current drm-misc/drm-misc
Different planes may have different capabilities of doing async flips,
so create a field to let drivers allow async flip per plane type.
Signed-off-by: André Almeida
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
drivers/gpu/drm/drm_plane.c | 3 +++
include/drm/drm_plane.h | 5 +
Allow userspace to use explicit synchronization with atomic async flips.
That means that the flip will wait for some hardware fence, and then
will flip as soon as possible (async) in regard of the vblank.
Signed-off-by: André Almeida
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++-
1 file changed
Hello:
This patch was applied to jaegeuk/f2fs.git (dev)
by Steven Rostedt (Google) :
On Thu, 16 May 2024 13:34:54 -0400 you wrote:
> From: "Steven Rostedt (Google)"
>
> [
>This is a treewide change. I will likely re-create this patch again in
>the second week of the merge window of v6.1
On 6/12/2024 3:06 PM, Yiqing Yao wrote:
> When flushing gpu tlb using kiq for gfxhub, kiq ring is always
> local by selecting kiq instance. Test shows mmreg write data packet's
> higher bits then 16 have no effect when flush using kiq on gfxhub.
>
> Also some variant have policy blocking higher
Well there is still no explanation why this patch is needed in the first
place?
When the higher bits are ignored by the KIQ then it should already work.
Regards,
Christian.
Am 12.06.24 um 11:57 schrieb Ma, Qing (Mark):
[AMD Official Use Only - AMD Internal Distribution Only]
@Deucher, Alexan
When flushing gpu tlb using kiq for gfxhub, kiq ring is always
local by selecting kiq instance. Test shows mmreg write data packet's
higher bits then 16 have no effect when flush using kiq on gfxhub.
Also some variant have policy blocking higher offset when req/ack is set
with extra bits and can c
Hi Greg KH, Sasha,
Please pick up this patch for 5.15 stable tree. I have built a test kernel and
can confirm that it fixes affected users.
Downstream bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2068738
Thanks,
Matthew
25 matches
Mail list logo
