On 12/11/2024 4:22 AM, Alex Deucher wrote:
> Have a separate work handler for each VCN instance. This
> paves the way for per instance VCN power gating at runtime.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 84 +
> drivers/gpu/drm
On 12/11/2024 4:22 AM, Alex Deucher wrote:
> Store it per instance so we can track it per instance.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 2 +-
> drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 6 +--
> drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 11
[Public]
> From: Koenig, Christian
> Sent: Wednesday, December 11, 2024 3:16
> Am 10.12.24 um 18:59 schrieb Yunxiang Li:
> > Tracking the state of a GEM object for shared stats is quite difficult
> > since the handle_count is managed behind driver's back. So instead
> > considers GEM object share
Uprev IGT to the latest version and update expectation files.
Signed-off-by: Vignesh Raman
---
v1:
- Pipeline link -
https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1327810
Will update the flake bug report link after v1 is reviewed.
---
drivers/gpu/drm/ci/gitlab-ci.yml
Am 11.12.24 um 15:02 schrieb Li, Yunxiang (Teddy):
[Public]
From: Koenig, Christian
Sent: Wednesday, December 11, 2024 3:16
Am 10.12.24 um 18:59 schrieb Yunxiang Li:
Tracking the state of a GEM object for shared stats is quite difficult
since the handle_count is managed behind driver's back.
Currently, DRM atomic uAPI allows only primary planes to be flipped
asynchronously. However, each driver might be able to perform async
flips in other different plane types. To enable drivers to set their own
restrictions on which type of plane they can or cannot flip, use the
existing atomic_async
Hi,
The goal of this work is to find a nice way to allow amdgpu to perform
async page flips in the overlay plane as well, not only on the primary
one. Currently, when using the atomic uAPI, this is the only type of
plane allowed to do async flips, and every driver accepts it.
This patchset re-use
From: Nikita Zhandarovich
[ Upstream commit 2a3cfb9a24a28da9cc13d2c525a76548865e182c ]
Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULL
before the call to dc_enable_dmub_notifications(), check
beforehand to ensure there will not be a possible NULL-ptr-deref
there.
Also, since c
amdgpu can handle async flips on overlay planes, so allow it for atomic
async checks.
Signed-off-by: André Almeida
---
Changes from v8:
- Use new parameter 'flip'
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff -
From: Nikita Zhandarovich
[ Upstream commit 2a3cfb9a24a28da9cc13d2c525a76548865e182c ]
Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULL
before the call to dc_enable_dmub_notifications(), check
beforehand to ensure there will not be a possible NULL-ptr-deref
there.
Also, since c
From: Sohaib Nadeem
[ Upstream commit 0484e05d048b66d01d1f3c1d2306010bb57d8738 ]
[why]:
issues fixed:
- comparison with wider integer type in loop condition which can cause
infinite loops
- pointer dereference before null check
Cc: Mario Limonciello
Cc: Alex Deucher
Cc: sta...@vger.kernel.org
From: Wayne Lin
[ Upstream commit fcf6a49d79923a234844b8efe830a61f3f0584e4 ]
[Why]
When unplug one of monitors connected after mst hub, encounter null pointer
dereference.
It's due to dc_sink get released immediately in early_unregister() or
detect_ctx(). When
commit new state which directly
Hi,
On Wed, Feb 28, 2024 at 11:39:16AM -0700, Alex Hung wrote:
> From: Nicholas Kazlauskas
>
> [WHY]
> To log commit states and when we transition in/out of allow and idle
> states and the caller.
>
> [HOW]
> Add a new logging helper and wrap idle optimization calls to receive
> the caller.
>
From: Wayne Lin
[ Upstream commit fcf6a49d79923a234844b8efe830a61f3f0584e4 ]
[Why]
When unplug one of monitors connected after mst hub, encounter null pointer
dereference.
It's due to dc_sink get released immediately in early_unregister() or
detect_ctx(). When
commit new state which directly
On Tue, Dec 10, 2024 at 9:45 PM Mario Limonciello
wrote:
>
> This helps to avoid a spurious PME event on hotplug to Azalia.
>
> Cc: Vijendar Mukunda
> Reported-by: ionut_n2...@yahoo.com
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=215884
> Tested-by: Gabriel Marcano
> Signed-off-by: Mar
From: Mario Limonciello
If the kernel hasn't been compiled with PCIe hotplug support this
can lead to problems with dGPUs that use BOCO because they effectively
drop off the bus.
To prevent issues, disable BOCO support when compiled without PCIe hotplug.
Reported-by: Gabriel Marcano
Closes: ht
[Public]
> From: Koenig, Christian
> Sent: Wednesday, December 11, 2024 10:03
> Am 11.12.24 um 15:02 schrieb Li, Yunxiang (Teddy):
> > [Public]
> >
> >> From: Koenig, Christian
> >> Sent: Wednesday, December 11, 2024 3:16 Am 10.12.24 um 18:59 schrieb
> >> Yunxiang Li:
> >>> Tracking the state of
[AMD Official Use Only - AMD Internal Distribution Only]
Hi Guenter,
Thanks for the updates.
This may be a real issue. Please file a bug at
https://gitlab.freedesktop.org/drm/amd/-/issues and share your setup. This
helps us investigate further.
From: Guenter
[AMD Official Use Only - AMD Internal Distribution Only]
The series is:
Reviewed-by: Ruijing Dong
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Tuesday, December 10, 2024 4:47 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 2/2] drm/amdgp
Since 2320c9e6a768 ("drm/sched: memset() 'job' in drm_sched_job_init()")
accessing job->base.sched can produce unexpected results as the initialisation
of (*job)->base.sched done in amdgpu_job_alloc is overwritten by the
memset.
This commit fixes an issue when a CS would fail validation and would
It's unused.
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 6 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 3 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 3 +--
drivers/gpu/drm/amd/amd
This init is useless because base.sched will be cleared to 0 in
drm_sched_job_init
because of 2320c9e6a768 ("drm/sched: memset() 'job' in drm_sched_job_init()").
Signed-off-by: Pierre-Eric Pelloux-Prayer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 5 -
1 file changed, 5 deletions(-)
diff
On Wed, Dec 11, 2024 at 2:10 AM Lazar, Lijo wrote:
>
>
>
> On 12/11/2024 4:23 AM, Alex Deucher wrote:
> > Add a helper to get the number of instances of an IP type.
> >
> > Signed-off-by: Alex Deucher
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 ++
> > drivers/gpu/drm/amd/amdgpu/
On Wed, Dec 11, 2024 at 12:13 PM Pierre-Eric Pelloux-Prayer
wrote:
>
> Since 2320c9e6a768 ("drm/sched: memset() 'job' in drm_sched_job_init()")
> accessing job->base.sched can produce unexpected results as the initialisation
> of (*job)->base.sched done in amdgpu_job_alloc is overwritten by the
>
On Wed, Dec 11, 2024 at 07:58:05PM +0530, Vignesh Raman wrote:
> Uprev IGT to the latest version and update expectation files.
>
> Signed-off-by: Vignesh Raman
> ---
>
> v1:
> - Pipeline link -
> https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1327810
> Will update the flake
On Wed, Dec 11, 2024 at 3:19 PM Mario Limonciello wrote:
>
> On 12/11/2024 14:08, Alex Deucher wrote:
> > On Wed, Dec 11, 2024 at 10:56 AM Mario Limonciello
> > wrote:
> >>
> >> From: Mario Limonciello
> >>
> >> If the kernel hasn't been compiled with PCIe hotplug support this
> >> can lead to
On 12/11/2024 15:41, Alex Deucher wrote:
On Wed, Dec 11, 2024 at 3:19 PM Mario Limonciello wrote:
On 12/11/2024 14:08, Alex Deucher wrote:
On Wed, Dec 11, 2024 at 10:56 AM Mario Limonciello wrote:
From: Mario Limonciello
If the kernel hasn't been compiled with PCIe hotplug support this
c
- The previous patch only considered the case for baremetal
and not applicable for SRIOV code path. We also need to
init fw_share for SRIOV VF
Signed-off-by: Bokun Zhang
Change-Id: If26a377a2fe8f2aa09bfa21fc54bf26e80fd564c
---
drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c | 2 ++
1 file changed, 2
Hi Dave, Simona,
Fixes for 6.13.
The following changes since commit 73dae652dcac776296890da215ee7dec357a1032:
drm/amdgpu: rework resume handling for display (v2) (2024-12-03 18:19:23
-0500)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-dr
On 12/11/2024 15:43, Mario Limonciello wrote:
On 12/11/2024 15:41, Alex Deucher wrote:
On Wed, Dec 11, 2024 at 3:19 PM Mario Limonciello
wrote:
On 12/11/2024 14:08, Alex Deucher wrote:
On Wed, Dec 11, 2024 at 10:56 AM Mario Limonciello
wrote:
From: Mario Limonciello
If the kernel hasn't
On Wed, Dec 11, 2024 at 12:25:07AM -0300, André Almeida wrote:
> Hi,
>
> The goal of this work is to find a nice way to allow amdgpu to perform
> async page flips in the overlay plane as well, not only on the primary
> one. Currently, when using the atomic uAPI, this is the only type of
> plane al
On Wed, Dec 11, 2024 at 10:56 AM Mario Limonciello wrote:
>
> From: Mario Limonciello
>
> If the kernel hasn't been compiled with PCIe hotplug support this
> can lead to problems with dGPUs that use BOCO because they effectively
> drop off the bus.
>
> To prevent issues, disable BOCO support when
On 12/11/2024 14:08, Alex Deucher wrote:
On Wed, Dec 11, 2024 at 10:56 AM Mario Limonciello wrote:
From: Mario Limonciello
If the kernel hasn't been compiled with PCIe hotplug support this
can lead to problems with dGPUs that use BOCO because they effectively
drop off the bus.
To prevent is
On Wed, Dec 04, 2024 at 01:17:17PM +0200, Raag Jadav wrote:
> + misc maintainers
>
> On Tue, Dec 03, 2024 at 11:18:00AM +0100, Christian König wrote:
> > Am 03.12.24 um 06:00 schrieb Raag Jadav:
> > > On Mon, Dec 02, 2024 at 10:07:59AM +0200, Raag Jadav wrote:
> > > > On Fri, Nov 29, 2024 at 10:40
On 12/11/2024 16:16, Gabriel Marcano wrote:
>On 12/11/2024 15:41, Alex Deucher wrote:
On Wed, Dec 11, 2024 at 3:19 PM Mario Limonciello wrote:
On 12/11/2024 14:08, Alex Deucher wrote:
On Wed, Dec 11, 2024 at 10:56 AM Mario Limonciello wrote:
From: Mario Limonciello
If the kernel h
Am 10.12.24 um 18:59 schrieb Yunxiang Li:
Tracking the state of a GEM object for shared stats is quite difficult
since the handle_count is managed behind driver's back. So instead
considers GEM object shared the moment it is exported with flink ioctl.
This makes it work the same to the dma_buf ca
[Public]
Reviewed-by: Harish Kasiviswanathan
-Original Message-
From: amd-gfx On Behalf Of Andrew Martin
Sent: Tuesday, December 10, 2024 1:19 PM
To: amd-gfx@lists.freedesktop.org
Cc: Kuehling, Felix ; Tudor, Alexandru
; Martin, Andrew ; Martin,
Andrew
Subject: [PATCH 1/2] drm/amdgpu
[Public]
The comment needs to be fixed. This patch is checking if the variable is not
null. With that fixed.
Reviewed-by: Harish Kasiviswanathan
-Original Message-
From: amd-gfx On Behalf Of Andrew Martin
Sent: Tuesday, December 10, 2024 1:19 PM
To: amd-gfx@lists.freedesktop.org
Cc:
kfd_process_wq_release() signals eviction fence by
dma_fence_signal() which wanrs if dma_fence
is NULL.
kfd_process->ef is initialized by kfd_process_device_init_vm()
through ioctl. That means the fence is NULL for a new
created kfd_process, and close a kfd_process right
after open it will trigger
Hi Dmitry,
On 12/12/24 03:09, Dmitry Baryshkov wrote:
On Wed, Dec 11, 2024 at 07:58:05PM +0530, Vignesh Raman wrote:
Uprev IGT to the latest version and update expectation files.
Signed-off-by: Vignesh Raman
---
v1:
- Pipeline link -
https://gitlab.freedesktop.org/vigneshraman/linux/-/pi
Hi Helen,
On 11/12/24 21:57, Helen Mae Koike Fornazier wrote:
Hi Vignesh,
thanks for the patch.
On Wed, 11 Dec 2024 11:28:05 -0300 Vignesh Raman wrote ---
> Uprev IGT to the latest version and update expectation files.
>
> Signed-off-by: Vignesh Raman vignesh.ra...@collabora.com
On 12/12/2024 12:19 PM, Felix Kuehling wrote:
>
> On 2024-12-11 22:06, Zhu Lingshan wrote:
>> kfd_process_wq_release() signals eviction fence by
>> dma_fence_signal() which wanrs if dma_fence
>> is NULL.
> That's news to me. Looking at the dma_fence_signal implementation on
> amd-staging-drm-next,
On 2024-12-11 22:06, Zhu Lingshan wrote:
> kfd_process_wq_release() signals eviction fence by
> dma_fence_signal() which wanrs if dma_fence
> is NULL.
That's news to me. Looking at the dma_fence_signal implementation on
amd-staging-drm-next, it just silently returns -EINVAL if the fence pointe
Driver has different ways to fetch VBIOS. If one of the methods doesn't
find an authentic one, it will show misleading info messages eventhough
a subsequent method finds a valid VBIOS. Keep the message level at debug
and add device context.
Signed-off-by: Lijo Lazar
---
drivers/gpu/drm/amd/amdgp
44 matches
Mail list logo
