On Tue, 30 Apr 2024 17:38:09 + Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's
> series to fix drivers/i2c/[1], fix the terminology for users of
> I2C_ALGOBIT
gpu_id needs to be unique for user space to identify GPUs via KFD
interface. In the current implementation there is a very small
probability of having non unique gpu_ids.
v2: Add check to confirm if gpu_id is unique. If not unique, find one
Changed commit header to reflect the above
On Fri, May 03, 2024 at 02:04:15PM -0700, Easwar Hariharan wrote:
> On 5/3/2024 12:34 PM, Rodrigo Vivi wrote:
> > On Fri, May 03, 2024 at 06:13:24PM +, Easwar Hariharan wrote:
> >> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced
> >> "master/slave"
> >> with more appropriate
On Fri, May 03, 2024 at 06:13:24PM +, Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's
> series to fix drivers/i2c/[1], fix the terminology for users of
> I2C_ALGOBIT
Em Fri, 29 Mar 2024 17:00:28 +
Easwar Hariharan escreveu:
> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's
> series to fix drivers/i2c/[1], fix the terminology for users of
> I2C_ALGOBIT
On Fri, May 3, 2024 at 1:06 PM Tvrtko Ursulin wrote:
>
>
> On 03/05/2024 16:58, Alex Deucher wrote:
> > On Fri, May 3, 2024 at 11:33 AM Daniel Vetter wrote:
> >>
> >> On Fri, May 03, 2024 at 01:58:38PM +0100, Tvrtko Ursulin wrote:
> >>>
> >>> [And I forgot dri-devel.. doing well!]
> >>>
> >>> On
On 5/3/2024 9:52 PM, Alex Deucher wrote:
On Fri, May 3, 2024 at 12:09 PM Khatri, Sunil wrote:
On 5/3/2024 9:18 PM, Khatri, Sunil wrote:
On 5/3/2024 8:52 PM, Alex Deucher wrote:
On Fri, May 3, 2024 at 4:45 AM Sunil Khatri
wrote:
add compute registers in set of registers to dump
during ip
Hi Alex,
yes, this is related to memory clearing changes. This is a known issue.
I am working on a fix.
Thanks,
Arun.
On 5/3/2024 6:46 PM, Alex Deucher wrote:
Possibly related to Arun's new memory clearing changes. @Arunpravin
can you take a look?
Alex
On Fri, May 3, 2024 at 9:10 AM Tvrtko
On Fri, May 3, 2024 at 12:09 PM Khatri, Sunil wrote:
>
>
> On 5/3/2024 9:18 PM, Khatri, Sunil wrote:
> >
> > On 5/3/2024 8:52 PM, Alex Deucher wrote:
> >> On Fri, May 3, 2024 at 4:45 AM Sunil Khatri
> >> wrote:
> >>> add compute registers in set of registers to dump
> >>> during ip dump for
On 5/3/2024 9:18 PM, Khatri, Sunil wrote:
On 5/3/2024 8:52 PM, Alex Deucher wrote:
On Fri, May 3, 2024 at 4:45 AM Sunil Khatri
wrote:
add compute registers in set of registers to dump
during ip dump for gfx10.
Signed-off-by: Sunil Khatri
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 42
On Fri, May 3, 2024 at 11:33 AM Daniel Vetter wrote:
>
> On Fri, May 03, 2024 at 01:58:38PM +0100, Tvrtko Ursulin wrote:
> >
> > [And I forgot dri-devel.. doing well!]
> >
> > On 03/05/2024 13:40, Tvrtko Ursulin wrote:
> > >
> > > [Correcting Christian's email]
> > >
> > > On 03/05/2024 13:36,
On 5/3/2024 8:52 PM, Alex Deucher wrote:
On Fri, May 3, 2024 at 4:45 AM Sunil Khatri wrote:
add compute registers in set of registers to dump
during ip dump for gfx10.
Signed-off-by: Sunil Khatri
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 42 +-
1 file changed,
On 5/3/2024 07:05, fililip wrote:
This patch allows setting a low power cap if |ignore_min_pcap| is set to 1.
Signed-off-by: fililip
Rather than an attachment you should send the patch inline. That would
mean that your commit message and SoB should be at the top of the patch
itself.
If
On Fri, May 3, 2024 at 9:27 AM fililip wrote:
>
> This patch allows setting a low power cap if ignore_min_pcap is set to 1.
>
> Signed-off-by: fililip
Please generate a proper signed off git patch and use git-send-email
to send it out. Also, I don't want to add more module parameters.
Alex
On Fri, May 03, 2024 at 01:58:38PM +0100, Tvrtko Ursulin wrote:
>
> [And I forgot dri-devel.. doing well!]
>
> On 03/05/2024 13:40, Tvrtko Ursulin wrote:
> >
> > [Correcting Christian's email]
> >
> > On 03/05/2024 13:36, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > Currently
On Fri, May 3, 2024 at 4:45 AM Sunil Khatri wrote:
>
> add compute registers in set of registers to dump
> during ip dump for gfx10.
>
> Signed-off-by: Sunil Khatri
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 42 +-
> 1 file changed, 41 insertions(+), 1 deletion(-)
On Fri, May 3, 2024 at 4:45 AM Sunil Khatri wrote:
>
> add registers in the ip dump for CP headers in gfx10
>
> Signed-off-by: Sunil Khatri
Patches 1, 2 are:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 9 -
> 1 file changed, 8 insertions(+), 1
On 2024-04-16 10:04, Tvrtko Ursulin wrote:
>
> On 01/04/2024 18:58, Felix Kuehling wrote:
>>
>> On 2024-04-01 12:56, Tvrtko Ursulin wrote:
>>>
>>> On 01/04/2024 17:37, Felix Kuehling wrote:
On 2024-04-01 11:09, Tvrtko Ursulin wrote:
>
> On 28/03/2024 20:42, Felix Kuehling wrote:
On Fri, May 3, 2024 at 10:01 AM Tvrtko Ursulin
wrote:
>
>
> On 03/05/2024 14:47, Alex Deucher wrote:
> > On Fri, May 3, 2024 at 3:50 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 02/05/2024 14:16, Christian König wrote:
> >>> Am 30.04.24 um 19:27 schrieb Tvrtko Ursulin:
> From: Tvrtko
On Fri, May 3, 2024 at 7:50 AM Tvrtko Ursulin wrote:
>
>
> On 02/05/2024 16:00, Alex Deucher wrote:
> > On Thu, May 2, 2024 at 10:43 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 02/05/2024 14:07, Christian König wrote:
> >>> Am 01.05.24 um 15:27 schrieb Tvrtko Ursulin:
>
> Hi Alex,
>
On Thu, May 2, 2024 at 3:22 PM Mario Limonciello
wrote:
>
> Limit the workaround introduced by commit 31729e8c21ec ("drm/amd/pm: fixes
> a random hang in S4 for SMU v13.0.4/11") to only run in the s4 path.
>
> Cc: Tim Huang
> Fixes: 31729e8c21ec ("drm/amd/pm: fixes a random hang in S4 for SMU
>
On Fri, May 3, 2024 at 3:50 AM Tvrtko Ursulin wrote:
>
>
> On 02/05/2024 14:16, Christian König wrote:
> > Am 30.04.24 um 19:27 schrieb Tvrtko Ursulin:
> >> From: Tvrtko Ursulin
> >>
> >> Do not emit the key-value pairs if the VRAM does not exist ie. VRAM
> >> placement is not valid and
On Fri, May 3, 2024 at 8:58 AM Tvrtko Ursulin wrote:
>
>
> [And I forgot dri-devel.. doing well!]
>
> On 03/05/2024 13:40, Tvrtko Ursulin wrote:
> >
> > [Correcting Christian's email]
> >
> > On 03/05/2024 13:36, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin
> >>
> >> Currently it is not well
Possibly related to Arun's new memory clearing changes. @Arunpravin
can you take a look?
Alex
On Fri, May 3, 2024 at 9:10 AM Tvrtko Ursulin wrote:
>
>
> Hi,
>
> I tried asking on #radeon yesterday but no takers. I was wondering if
> the below splat is already known or not.
>
> Appears to
[And I forgot dri-devel.. doing well!]
On 03/05/2024 13:40, Tvrtko Ursulin wrote:
[Correcting Christian's email]
On 03/05/2024 13:36, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Currently it is not well defined what is drm-memory- compared to other
categories.
In practice the only driver
test robot wrote:
|-- arc-randconfig-002-20240503
| `-- drivers-usb-dwc3-core.c:warning:variable-hw_mode-set-but-not-used
This warning (same for all arches), but can't seem to find it anywhere.
Any hints as to where it would be?
Hi Greg,
I think the hw_mode was not removed
On 03/05/2024 07:26, Christian König wrote:
Am 29.04.24 um 18:47 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Help code readability by replacing a bunch of:
bo->tbo.base.resv == vm->root.bo->tbo.base.resv
With:
amdgpu_vm_is_bo_always_valid(vm, bo)
No functional changes.
v2:
* Rename
Hi,
I tried asking on #radeon yesterday but no takers. I was wondering if
the below splat is already known or not.
Appears to happen due amdgpu_bo_release_notify genuniely running before
amdgpu_ttm_set_buffer_funcs_status set the buffer funcs to enabled
during device probe.
I couldn't
[Correcting Christian's email]
On 03/05/2024 13:36, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Currently it is not well defined what is drm-memory- compared to other
categories.
In practice the only driver which emits these keys is amdgpu and in them
exposes the total memory use (including
On 02/05/2024 16:00, Alex Deucher wrote:
On Thu, May 2, 2024 at 10:43 AM Tvrtko Ursulin
wrote:
On 02/05/2024 14:07, Christian König wrote:
Am 01.05.24 um 15:27 schrieb Tvrtko Ursulin:
Hi Alex,
On 30/04/2024 19:32, Alex Deucher wrote:
On Tue, Apr 30, 2024 at 1:27 PM Tvrtko Ursulin
On Fri, May 03, 2024 at 01:18:35PM +0300, Ilpo Järvinen wrote:
> On Thu, 15 Feb 2024, Ilpo Järvinen wrote:
>
> > Convert open coded RMW accesses for LNKCTL2 to use
> > pcie_capability_clear_and_set_word() which makes its easier to
> > understand what the code tries to do.
> >
> > LNKCTL2 is not
On Thu, 15 Feb 2024, Ilpo Järvinen wrote:
> Convert open coded RMW accesses for LNKCTL2 to use
> pcie_capability_clear_and_set_word() which makes its easier to
> understand what the code tries to do.
>
> LNKCTL2 is not really owned by any driver because it is a collection of
> control bits that
This patch allows setting a low power cap if ignore_min_pcap is set to 1.
Signed-off-by: fililip diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 50f57d4dfd8f..b83697b75221 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++
From: Tvrtko Ursulin
Currently it is not well defined what is drm-memory- compared to other
categories.
In practice the only driver which emits these keys is amdgpu and in them
exposes the total memory use (including shared).
Document that drm-memory- and drm-total-memory- are aliases to
From: Tvrtko Ursulin
Help code readability by replacing a bunch of:
bo->tbo.base.resv == vm->root.bo->tbo.base.resv
With:
amdgpu_vm_is_bo_always_valid(vm, bo)
No functional changes.
v2:
* Rename helper and move to amdgpu_vm. (Christian)
v3:
* Use Christian's kerneldoc.
Signed-off-by:
From: Tvrtko Ursulin
All apart from AMDGPU_GEM_DOMAIN_GTT memory domains map 1:1 to TTM
placements. And the former be either AMDGPU_PL_PREEMPT or TTM_PL_TT,
depending on AMDGPU_GEM_CREATE_PREEMPTIBLE.
Simplify a few places in the code which convert the TTM placement into
a domain by checking
From: Tvrtko Ursulin
Accurately show all placements when describing objects in debugfs, instead
of bunching them up under the 'CPU' placement.
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |
Add gfx queue registers in the list of registers to
be dumped in ip dump for gfx10
Signed-off-by: Sunil Khatri
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
add the registers of SE block of gfx for ip dump
for gfx10 IP.
Signed-off-by: Sunil Khatri
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index
add compute registers in set of registers to dump
during ip dump for gfx10.
Signed-off-by: Sunil Khatri
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 42 +-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
*** BLURB HERE ***
Sunil Khatri (4):
drm/amdgpu: add CP headers registers to gfx10 dump
drm/amdgpu: add se registers to ip dump for gfx10
drm/amdgpu: add compute registers in ip dump for gfx10
drm/amdgpu: add gfx queue registers for gfx10 ip dump
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c |
add registers in the ip dump for CP headers in gfx10
Signed-off-by: Sunil Khatri
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index
Am 03.05.24 um 10:23 schrieb Tvrtko Ursulin:
On 03/05/2024 07:26, Christian König wrote:
Am 29.04.24 um 18:47 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Help code readability by replacing a bunch of:
bo->tbo.base.resv == vm->root.bo->tbo.base.resv
With:
amdgpu_vm_is_bo_always_valid(vm,
Ok, I'm getting tired of seeing these for the USB portion of the tree,
so I went to look for:
On Fri, May 03, 2024 at 04:44:42AM +0800, kernel test robot wrote:
> |-- arc-randconfig-002-20240503
> | `-- drivers-usb-dwc3-core.c:warning:variable-hw_mode-set-but-not-used
This warning
AM +0800, kernel test robot wrote:
> > > |-- arc-randconfig-002-20240503
> > > | `-- drivers-usb-dwc3-core.c:warning:variable-hw_mode-set-but-not-used
> >
> > This warning (same for all arches), but can't seem to find it anywhere.
> >
> > Any hints as to wher
On 02/05/2024 14:16, Christian König wrote:
Am 30.04.24 um 19:27 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Do not emit the key-value pairs if the VRAM does not exist ie. VRAM
placement is not valid and accessible.
Yeah, that's unfortunately rather misleading.
Even APUs have VRAM or
On 02/05/2024 14:07, Christian König wrote:
Am 01.05.24 um 15:27 schrieb Tvrtko Ursulin:
Hi Alex,
On 30/04/2024 19:32, Alex Deucher wrote:
On Tue, Apr 30, 2024 at 1:27 PM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
I have noticed AMD GPUs can have more than one "engine" (ring?) of
the
On 5/2/2024 3:46 AM, Thomas Zimmermann wrote:
>
>
> Am 30.04.24 um 19:38 schrieb Easwar Hariharan:
>> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series to fix drivers/i2c/[1], fix the
On 5/3/2024 10:42 AM, Greg KH wrote:
Ok, I'm getting tired of seeing these for the USB portion of the tree,
so I went to look for:
On Fri, May 03, 2024 at 04:44:42AM +0800, kernel test robot wrote:
|-- arc-randconfig-002-20240503
| `-- drivers-usb-dwc3-core.c:warning:variable-hw_mode-set
Hi
Am 03.05.24 um 00:26 schrieb Easwar Hariharan:
On 5/2/2024 3:46 AM, Thomas Zimmermann wrote:
Am 30.04.24 um 19:38 schrieb Easwar Hariharan:
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
On Tue, 30 Apr 2024 17:38:02 +
Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced
> "master/slave" with more appropriate terms. Inspired by and following
> on to Wolfram's series to fix drivers/i2c/[1], fix the terminology
> for users of I2C_ALGOBIT
Am 02.05.24 um 18:31 schrieb Shashank Sharma:
This patch does necessary modifications to enable the SDMA-v6
usermode queues using the existing userqueue infrastructure.
V9: introduced this patch in the series
V10: use header file instead of extern (Alex)
Cc: Christian König
Cc: Alex Deucher
Am 02.05.24 um 18:31 schrieb Shashank Sharma:
This patch does the necessary changes required to
enable compute workload support using the existing
usermode queues infrastructure.
V9: Patch introduced
V10: Add custom IP specific mqd strcuture for compute (Alex)
Cc: Alex Deucher
Cc: Christian
Am 02.05.24 um 18:31 schrieb Shashank Sharma:
This patch:
- adds a kernel config option "CONFIG_DRM_AMD_USERQ_GFX"
- moves the usequeue initialization code for all IPs under
this flag
so that the userqueue works only when the config is enabled.
V9: Introduce this patch
V10: Call it
Am 29.04.24 um 18:47 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Instead of mixing them together with regular system memory objects mark
them explicitly as 'PREEMPTIBLE'.
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Felix Kuehling
---
No idea on the name to use.. :)
---
Am 29.04.24 um 18:47 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
All apart from AMDGPU_GEM_DOMAIN_GTT memory domains map 1:1 to TTM
placements. And the former be either AMDGPU_PL_PREEMPT or TTM_PL_TT,
depending on AMDGPU_GEM_CREATE_PREEMPTIBLE.
Simplify a few places in the code which convert
Am 29.04.24 um 18:47 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Help code readability by replacing a bunch of:
bo->tbo.base.resv == vm->root.bo->tbo.base.resv
With:
amdgpu_vm_is_bo_always_valid(vm, bo)
No functional changes.
v2:
* Rename helper and move to amdgpu_vm. (Christian)
57 matches
Mail list logo
