On Tue, Apr 11, 2023 at 03:56:08PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +-
> 3 fi
[AMD Official Use Only - General]
Better to update the patch title with prefix as "drm/amdgpu:" instead of
"drm/amdgpu/gfx9:".
Either way, the patch is Reviewed-by: Evan Quan
Evan
From: Zhang, Jesse(Jie)
Sent: Wednesday, April 12, 2023 9:25 AM
To: amd-gfx@lists.freedesktop.org; Deucher, Alexan
[AMD Official Use Only - General]
Better to update the patch title with prefix as "drm/amdgpu:" instead of
"drm/amdgpu/gfx9:".
Either way, the patch is Reviewed-by: Evan Quan
Evan
From: Zhang, Jesse(Jie)
Sent: Wednesday, April 12, 2023 9:24 AM
To: amd-gfx@lists.freedesktop.org; Deucher, Alexan
Am 12.04.23 um 00:56 schrieb Rob Clark:
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well.
Am 12.04.23 um 02:00 schrieb Luben Tuikov:
On 2023-04-11 17:39, Alex Deucher wrote:
On Thu, Apr 6, 2023 at 4:01 PM Luben Tuikov wrote:
From: Vitaly Prosyak
During an IGT GPU reset test we see the following oops,
[ +0.03] [ cut here ]
[ +0.00] WARNING: CPU:
On 12/04/2023 10:34, Christian König wrote:
Am 12.04.23 um 00:56 schrieb Rob Clark:
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices wit
And ensure each ring supports that many submissions. This makes
sure that we don't get surprises after the submission has been
scheduled where the ring allocation actually gets rejected.
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2498
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/d
This info would be used by radv to figure out when we need to
split a submission into multiple submissions. radv currently has
a limit of 192 which seems to work for most gfx submissions, but
is way too high for e.g. compute or sdma.
Userspace is available at
https://gitlab.freedesktop.org/bnieuwe
Am 12.04.23 um 14:10 schrieb Tvrtko Ursulin:
On 12/04/2023 10:34, Christian König wrote:
Am 12.04.23 um 00:56 schrieb Rob Clark:
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is pr
Am 12.04.23 um 14:18 schrieb Bas Nieuwenhuizen:
And ensure each ring supports that many submissions. This makes
sure that we don't get surprises after the submission has been
scheduled where the ring allocation actually gets rejected.
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2498
Si
Am 12.04.23 um 14:18 schrieb Bas Nieuwenhuizen:
This info would be used by radv to figure out when we need to
split a submission into multiple submissions. radv currently has
a limit of 192 which seems to work for most gfx submissions, but
is way too high for e.g. compute or sdma.
Userspace is a
On Wed, Apr 12, 2023 at 2:46 PM Christian König
wrote:
>
> Am 12.04.23 um 14:18 schrieb Bas Nieuwenhuizen:
> > And ensure each ring supports that many submissions. This makes
> > sure that we don't get surprises after the submission has been
> > scheduled where the ring allocation actually gets re
Hamza Mahfooz writes:
> On 4/4/23 06:28, Michael Ellerman wrote:
>> The amdgpu driver builds some of its code with hard-float enabled,
>> whereas the rest of the kernel is built with soft-float.
>>
>> When building with 64-bit long double, if soft-float and hard-float
>> objects are linked togeth
On 4/11/23 14:11, Deucher, Alexander wrote:
> [Public]
>
>> -Original Message-
>> From: Nikita Zhandarovich
>> Sent: Monday, April 3, 2023 2:28 PM
>> To: Deucher, Alexander
>> Cc: Nikita Zhandarovich ; Koenig, Christian
>> ; Pan, Xinhui ; David
>> Airlie ; Daniel Vetter ; amd-
>> g...
Sorry if I read this completely wrong, but the other patch says "radv
currently has
a limit of 192 which seems to work for most gfx submissions, but
is way too high for e.g. compute or sdma.", while you return 192 for
AMDGPU_RING_TYPE_COMPUTE
here still?
Regards
//Ernst
Den ons 12 apr. 2023 kl 14
On Wed, Apr 12, 2023 at 3:01 PM Ernst Sjöstrand wrote:
>
> Sorry if I read this completely wrong, but the other patch says "radv
> currently has
> a limit of 192 which seems to work for most gfx submissions, but
> is way too high for e.g. compute or sdma.", while you return 192 for
> AMDGPU_RING
On 2023-04-04 09:45, Felix Kuehling wrote:
[+Philip]
Am 2023-04-04 um 08:47 schrieb Christian König:
Am 04.04.23 um 12:56 schrieb Xiao, Shane:
[AMD Official Use Only - General]
-Original Message-
From: Koenig, Christian
Sent: Tuesday, April 4, 2023 6:27 PM
To: Xiao, Shane ; amd-g
On Sat, 2023-04-08 at 07:46 -0400, Jeff Layton wrote:
> I've hit some repeated crashes in drm_dp_add_payload_part2. Here's one
> from this morning that occurred not long after booting the machine. I
> hadn't even logged in yet -- it was still at a gdm prompt:
>
> Apr 08 05:34:20 tleilax kernel: am
Was introduced as workaround. not needed anymore
Signed-off-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v3_0.c | 22 --
1 file changed, 22 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfxhub_v3_0.c
b/drivers/gpu/drm/amd/amdgpu/gfxhub_v3_0.c
index be0d0f4
[AMD Official Use Only - General]
Reviewed-by: Jack Gui
-Original Message-
From: Zhang, Hawking
Sent: Wednesday, April 12, 2023 10:02 PM
To: amd-gfx@lists.freedesktop.org; Gui, Jack ; Gao, Likun
Cc: Zhang, Hawking
Subject: [PATCH] drm/amdgpu: drop temp programming for pagefault hand
Am 12.04.23 um 14:50 schrieb Bas Nieuwenhuizen:
On Wed, Apr 12, 2023 at 2:46 PM Christian König
wrote:
Am 12.04.23 um 14:18 schrieb Bas Nieuwenhuizen:
And ensure each ring supports that many submissions. This makes
sure that we don't get surprises after the submission has been
scheduled where
Am 2023-04-12 um 09:35 schrieb Philip Yang:
On 2023-04-04 09:45, Felix Kuehling wrote:
[+Philip]
Am 2023-04-04 um 08:47 schrieb Christian König:
Am 04.04.23 um 12:56 schrieb Xiao, Shane:
[AMD Official Use Only - General]
-Original Message-
From: Koenig, Christian
Sent: Tuesday,
On Wed, Apr 12, 2023 at 8:39 AM Nikita Zhandarovich
wrote:
>
>
>
> On 4/11/23 14:11, Deucher, Alexander wrote:
> > [Public]
> >
> >> -Original Message-
> >> From: Nikita Zhandarovich
> >> Sent: Monday, April 3, 2023 2:28 PM
> >> To: Deucher, Alexander
> >> Cc: Nikita Zhandarovich ; Koeni
Multiple hdmi_*_infoframe_init() functions that initialize different
types of hdmi infoframes only return default 0 value (contrary to their
descriptions). Yet these functions are still checked against possible
errors in case of failure.
This patch removes redundant checks for errors in calls to f
Doorbells in AMDGPU drivers are currently managed by different clients
in a scattered way, across may places. The existing clients are:
- AMDGPU graphics driver for kernel level doorbell writes.
- AMDGPU MES module for kernel level doorbell write (MES ring test and
aggregated doorbells).
- AMDGPU
This patch:
- creates a new file for doorbell management.
- moves doorbell code from amdgpu_device.c to this file.
V2:
- remove doc from function declaration (Christian)
- remove 'device' from function names to make it consistent (Alex)
- add SPDX license identifier (Luben)
Cc: Alex Deucher
C
This patch removes the check and change in num_kernel_doorbells
for MES, which is not being used anywhere by MES code.
Cc: Alex Deucher
Cc: Christian Koenig
Reviewed-by: Christian Koenig
Acked-by: Alex Deucher
Signed-off-by: Shashank Sharma
---
.../gpu/drm/amd/amdgpu/amdgpu_doorbell_mgr.c |
From: Alex Deucher
This patch adds flags for a new gem domain AMDGPU_GEM_DOMAIN_DOORBELL
in the UAPI layer.
V2: Drop 'memory' from description (Christian)
Cc: Alex Deucher
Cc: Christian Koenig
Reviewed-by: Christian Koenig
Signed-off-by: Alex Deucher
Signed-off-by: Shashank Sharma
---
inc
This patch initialzes the ttm resource manager for doorbells.
V2: Do not round up doorbell size (Alex)
Cc: Alex Deucher
Cc: Christian Koenig
Reviewed-by: Christian Koenig
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +++
1 file changed, 7 insertions(+)
This patch:
- creates a doorbell page for graphics driver usages.
- adds a few new varlables in adev->doorbell structure to
keep track of kernel's doorbell-bo.
- removes the adev->doorbell.ptr variable, replaces it with
kernel-doorbell-bo's cpu address.
V2: - Create doorbell BO directly, no wr
This patch adds a helper function which converts a doorbell's
relative index in a BO to an absolute doorbell offset in the
doorbell BAR.
V2: No space between the variable name doc (Luben)
Cc: Alex Deucher
Cc: Christian Koenig
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/amd/amdgpu/amdgp
From: Alex Deucher
This patch adds changes:
- to accommodate the new GEM domain DOORBELL
- to accommodate the new TTM PL DOORBELL
in order to manage doorbell pages as GEM object.
V2: Addressed reviwe comments from Christian
- drop the doorbell changes for pinning/unpinning
- drop the do
This patch:
- adds a doorbell bo in kfd device structure.
- creates doorbell page for kfd kernel usages.
- updates the get_kernel_doorbell and free_kernel_doorbell functions
accordingly
V2: Do not use wrapper API, use direct amdgpu_create_kernel(Alex)
Cc: Alex Deucher
Cc: Christian Koenig
Cc:
This patch:
- adds a doorbell object in kfd pdd structure.
- allocates doorbells for a process while creating its pdd.
- frees the doorbells with pdd destroy.
- removes previous calls to allocate process doorbells as
its not required anymore.
PS: This patch ensures that we don't break the existi
This patch removes some variables and functions from KFD
doorbell handling code, which are no more required since
doorbell manager is handling doorbell calculations.
Cc: Alex Deucher
Cc: Christian Koenig
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 32
This patch:
- Removes the existing doorbell management code, and its variables
from the doorbell_init function, it will be done in doorbell
manager now.
- uses the doorbell page created for MES kernel level needs (doorbells
for MES self tests)
- current MES code was allocating MES doorbells i
MES allocates process level doorbells, but there is no userspace
client to consume it. It was only being used for the MES ring
tests (in kernel), and was written by kernel doorbell write.
The previous patch of this series has changed the MES ring test code to
use kernel level MES doorbells. This p
On Wed, Apr 5, 2023 at 6:06 PM Limonciello, Mario
wrote:
>
> On 4/5/2023 06:29, Liu, Aaron wrote:
> > GFX is in gfxoff mode during s0ix so we shouldn't need to
> > actually execute kfd_iommu_suspend/kfd_iommu_resume operation.
> >
> > Signed-off-by: Aaron Liu
> > ---
> Probably should add to this
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 7d8214bba44c1aa6a75921a09a691945d26a8d43 Add linux-next specific
files for 20230412
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202303161521.jbgbafjj-...@intel.com
https
Hi Nikita,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on tegra/for-next drm-intel/for-linux-next
drm-intel/for-linux-next-fixes linus/master v6.3-rc6 next-20230412]
[If your patch is applied to the wrong
It is to avoid redundant eviction for KFD's DMAbuf import
bo when dmaunmapping DMAbuf. The DMAbuf import bo has
been set as AMDGPU_PL_PREEMPT in KFD when mapping.
Signed-off-by: Eric Huang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff
Am 2023-04-12 um 14:49 schrieb Eric Huang:
It is to avoid redundant eviction for KFD's DMAbuf import
bo when dmaunmapping DMAbuf. The DMAbuf import bo has
been set as AMDGPU_PL_PREEMPT in KFD when mapping.
Signed-off-by: Eric Huang
The headline is a bit inaccurate. The shortest description I
Hi Dave, Daniel,
Fixes for 6.3.
The following changes since commit 09a9639e56c01c7a00d6c0ca63f4c7c41abe075d:
Linux 6.3-rc6 (2023-04-09 11:15:57 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.3-2023-04-12
for you to fetch
It is to avoid redundant eviction for KFD's DMAbuf import
bo when dmaunmapping DMAbuf. The DMAbuf import bo has
been set as AMDGPU_PL_PREEMPT in KFD when mapping.
Signed-off-by: Eric Huang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
di
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well. But this seems like a reasonable start.
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +-
3 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm
Am 2023-04-12 um 18:25 schrieb Eric Huang:
It is to avoid redundant eviction for KFD's DMAbuf import
bo when dmaunmapping DMAbuf. The DMAbuf import bo has
been set as AMDGPU_PL_PREEMPT in KFD when mapping.
Signed-off-by: Eric Huang
Reviewed-by: Felix Kuehling
I'd like to get an Acked-by fro
On 4/5/2023 06:29, Aaron Liu wrote:
GFX is in gfxoff mode during s0ix so we shouldn't need to
actually execute kfd_iommu_suspend/kfd_iommu_resume operation.
Signed-off-by: Aaron Liu
Acked-by: Alex Deucher
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++
[AMD Official Use Only - General]
Thanks for sorting out this, that is making sense since driver already skip kfd
device suspend and this will skip kfd_iommu_suspend() as well.
Reviewed-by: Prike Liang
Regards,
--Prike
> -Original Message-
> From: Limonciello, Mario
> Sent: Thursday,
Fixes: 0f486b64b8d4 ("drm/amd/amdgpu: introduce gc_*_mes_2.bin v2")
Reserve the MOUDLE_FIRMWARE declaration of gc_11_0_*_mes.bin
to avoid falling back to old mes bin failure via autoload.
Signed-off-by: Li Ma
---
drivers/gpu/drm/amd/amdgpu/mes_v11_0.c | 5 +
1 file changed, 5 insertions(+)
[AMD Official Use Only - General]
Fixes tag should be in a separate line, right above Signed off, with that
fixed, patch is
Reviewed-by: Yifan Zhang
-Original Message-
From: Ma, Li
Sent: Thursday, April 13, 2023 10:34 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Zha
On Wed, Apr 12, 2023 at 10:35 PM Li Ma wrote:
>
> Fixes: 0f486b64b8d4 ("drm/amd/amdgpu: introduce gc_*_mes_2.bin v2")
> Reserve the MOUDLE_FIRMWARE declaration of gc_11_0_*_mes.bin
> to avoid falling back to old mes bin failure via autoload.
typo. Should read:
to fix falling back to olad mes bin
Hi Nikita,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on tegra/for-next drm-intel/for-linux-next
drm-intel/for-linux-next-fixes linus/master v6.3-rc6 next-20230412]
[If your patch is applied to the wrong git
53 matches
Mail list logo
