[AMD Official Use Only - Internal Distribution Only]
Hi Fenghua,
I am okay with the idea.
Regards,
Yong
From: Fenghua Yu
Sent: Friday, May 22, 2020 5:21 PM
To: Kuehling, Felix
Cc: Zhao, Yong ; amd-gfx@lists.freedesktop.org
Subject: Re: drm/amdkfd: Change pasi
Track SDMA usage on a per process basis and report it through sysfs.
The value in the sysfs file indicates the amount of time SDMA has
been in-use by this process since the creation of the process.
This value is in microsecond granularity.
v2:
- Remove unnecessary checks for pdd is kfd_procfs_show
so yea, looks like the compositing wasnt happening on the amdgpu, so
thats why when i would see 300fps for glxgears etc.
also, the whole thing about "monitor updating once every 3 seconds"
when i close the lid is because mutter will go down to 1fps when it
detects that the lid is closed.
i setup t
Explicitly set the smallk size to 0 (4k). This is the hw
default, but set it anyway just in case something else
changed it.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v2_0.c | 4
drivers/gpu/drm/amd/amdgpu/mmhub_v2_0.c | 4
2 files changed, 8 insertions(+)
dif
Hi, Felix,
On Fri, May 22, 2020 at 03:40:06PM -0400, Felix Kuehling wrote:
> Hi Fenghua,
>
> The PASID width in KFD is currently limited to 16 bits. I believe this
> reflects what our hardware can handle. KFD will never allocate a PASID
> bigger than 16 bits. That said, I'm OK with changing this
Hi, Yong,
In commit: 6027b1bf6071fc61a5aa11b9922a2e0e91bff1ea
drm/amdkfd: Use hex print format for pasid
pasid's type was change to "uint16_t" from "unsigned int" in
struct kfd_process.
But, pasid is a 20-bit value according to PCIe spec and other places
in amdkfd (plus other iommu code) def
On Fri, May 22, 2020 at 3:39 PM Gavin Wan wrote:
>
> For SRIOV, since the CP_INT_CNTL_RING0 is programed on host side.
> The Guest should not program CP_INT_CNTL_RING0 again.
>
> Change-Id: Ic336fab3b23b8371c9e9e192182a3ba14a8db8e1
> Signed-off-by: Gavin Wan
Acked-by: Alex Deucher
> ---
> dri
On Fri, 22 May 2020 at 20:43, Emil Velikov wrote:
>
> On Fri, 22 May 2020 at 20:38, Simon Ser wrote:
> >
> > drm_gem_object_put_unlocked has been renamed to drm_gem_object_put.
> >
> > Signed-off-by: Simon Ser
> > Fixes: e07ddb0ce7cd ("drm/amd: remove _unlocked suffix in
> > drm_gem_object_put_
On Fri, 22 May 2020 at 20:38, Simon Ser wrote:
>
> drm_gem_object_put_unlocked has been renamed to drm_gem_object_put.
>
> Signed-off-by: Simon Ser
> Fixes: e07ddb0ce7cd ("drm/amd: remove _unlocked suffix in
> drm_gem_object_put_unlocked")
Wrong tag it seems. At that commit, the amdgpu code uses
Am 2020-05-22 um 3:38 p.m. schrieb Simon Ser:
> drm_gem_object_put_unlocked has been renamed to drm_gem_object_put.
Alex, I guess you'll need to apply this patch when you include
e07ddb0ce7cd in a pull request to Dave Airlie. I don't think it makes
sense to apply this on amd-kfd-staging until the
HI Alex,
I fixed it as your suggestion.
Thanks,
Gavin
-Original Message-
From: Alex Deucher
Sent: Friday, May 22, 2020 3:11 PM
To: Wan, Gavin
Cc: amd-gfx list
Subject: Re: [PATCH] drm/amd/amdgpu: Fix the CGCG setting is overwritten for
SRIOV.
On Fri, May 22, 2020 at 2:20 PM Gavin W
Hi Fenghua,
The PASID width in KFD is currently limited to 16 bits. I believe this
reflects what our hardware can handle. KFD will never allocate a PASID
bigger than 16 bits. That said, I'm OK with changing this field in the
kfd_process structure to unsigned int. Generally, I find uint16_t in
stru
For SRIOV, since the CP_INT_CNTL_RING0 is programed on host side.
The Guest should not program CP_INT_CNTL_RING0 again.
Change-Id: Ic336fab3b23b8371c9e9e192182a3ba14a8db8e1
Signed-off-by: Gavin Wan
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletio
drm_gem_object_put_unlocked has been renamed to drm_gem_object_put.
Signed-off-by: Simon Ser
Fixes: e07ddb0ce7cd ("drm/amd: remove _unlocked suffix in
drm_gem_object_put_unlocked")
Cc: Alex Deucher
Cc: Christian König
Cc: David (ChunMing) Zhou
Cc: Emil Velikov
---
drivers/gpu/drm/amd/amdgpu
On Fri, May 22, 2020 at 2:20 PM Gavin Wan wrote:
>
> For SRIOV, since the CP_INT_CNTL_RING0 is programed on host side.
> The Guest should not program CP_INT_CNTL_RING0 again.
>
> Change-Id: Ic336fab3b23b8371c9e9e192182a3ba14a8db8e1
> Signed-off-by: Gavin Wan
> ---
> drivers/gpu/drm/amd/amdgpu/gf
Fixed it as Monk and Hawking suggestion. Now it only has one checking in
function gfx_v10_0_enable_gui_idle_interrupt.
BTW, I update the commit, but it send out an another email.
Thanks,
Gavin
-Original Message-
From: Zhang, Hawking
Sent: Friday, May 22, 2020 2:17 AM
To: Liu, Monk ; C
On 2020-05-22 2:03 p.m., Nicholas Kazlauskas wrote:
> [Why]
> Warnings in the kernel are generally treated as errors.
>
> The BREAK_TO_DEBUGGER macro is not a critical error or warning, but
> rather intended for developer use to help investigate behavior and
> sequences for other issues.
>
> We d
For SRIOV, since the CP_INT_CNTL_RING0 is programed on host side.
The Guest should not program CP_INT_CNTL_RING0 again.
Change-Id: Ic336fab3b23b8371c9e9e192182a3ba14a8db8e1
Signed-off-by: Gavin Wan
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/
On Fri, May 22, 2020 at 1:39 PM Gustavo A. R. Silva
wrote:
>
> The current codebase makes use of one-element arrays in the following
> form:
>
> struct something {
> int length;
> u8 data[1];
> };
>
> struct something *instance;
>
> instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
On Fri, May 22, 2020 at 1:29 PM Gustavo A. R. Silva
wrote:
>
> The current codebase makes use of one-element arrays in the following
> form:
>
> struct something {
> int length;
> u8 data[1];
> };
>
> struct something *instance;
>
> instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
[Why]
Warnings in the kernel are generally treated as errors.
The BREAK_TO_DEBUGGER macro is not a critical error or warning, but
rather intended for developer use to help investigate behavior and
sequences for other issues.
We do still make use of DC_ERROR/ASSERT(0) in various places in the
code
On Fri, May 22, 2020 at 1:46 PM Gustavo A. R. Silva
wrote:
>
> On Wed, May 20, 2020 at 09:42:27AM +0200, Christian König wrote:
> > >
> > > Signed-off-by: Gustavo A. R. Silva
> >
> > Acked-by: Christian König
> >
> > May I suggest that we add a section how to correctly do this to
> > Documentati
On Wed, May 20, 2020 at 09:42:27AM +0200, Christian König wrote:
> >
> > Signed-off-by: Gustavo A. R. Silva
>
> Acked-by: Christian König
>
> May I suggest that we add a section how to correctly do this to
> Documentation/process/coding-style.rst or similar document?
>
That's already on my l
The current codebase makes use of one-element arrays in the following
form:
struct something {
int length;
u8 data[1];
};
struct something *instance;
instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
instance->length = size;
memcpy(instance->data, source, size);
but the preferre
The current codebase makes use of one-element arrays in the following
form:
struct something {
int length;
u8 data[1];
};
struct something *instance;
instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
instance->length = size;
memcpy(instance->data, source, size);
but the preferre
On Fri, May 22, 2020 at 09:00:09AM +0200, Christian König wrote:
> > +++ b/drivers/gpu/drm/radeon/ni_dpm.c
> > @@ -2685,11 +2685,12 @@ static int ni_upload_sw_state(struct radeon_device
> > *rdev,
> > struct rv7xx_power_info *pi = rv770_get_pi(rdev);
> > u16 address = pi->state_table_start
On Fri, May 22, 2020 at 11:41 AM Kevin Wang wrote:
>
> the origin design will use varible of "attr->states" to save node
> supported states on current gpu device, but for multi gpu device, when
> probe second gpu device, the driver will check attribute node states
> from previous gpu device wtheth
[AMD Official Use Only - Internal Distribution Only]
From: Alex Deucher
Sent: Friday, May 22, 2020 11:16 PM
To: Wang, Kevin(Yang)
Cc: amd-gfx list ; Deucher, Alexander
; Zhang, Hawking
Subject: Re: [PATCH] drm/amdgpu: fix device attribute node create failed w
the origin design will use varible of "attr->states" to save node
supported states on current gpu device, but for multi gpu device, when
probe second gpu device, the driver will check attribute node states
from previous gpu device wthether to create attribute node.
it will cause other gpu device cr
On Fri, May 22, 2020 at 10:57 AM Kevin Wang wrote:
>
> the origin design will use varible of "attr->states" to save node
> supported states on current gpu device, but for multi gpu device, when
> probe second gpu device, the driver will check attribute node states
> from previous gpu device wtheth
On 2020-05-22 10:45 a.m., Alex Deucher wrote:
On Thu, May 21, 2020 at 5:39 PM Bhawanpreet Lakha
wrote:
[Why]
Previously we used the s3 codepath for gpu reset. This can lead to issues in
certain case where we end of waiting for fences which will never come (because
parts of the hw are off due t
the origin design will use varible of "attr->states" to save node
supported states on current gpu device, but for multi gpu device, when
probe second gpu device, the driver will check attribute node states
from previous gpu device wthether to create attribute node.
it will cause other gpu device cr
On Fri, May 22, 2020 at 6:41 AM Christian König
wrote:
>
> Am 20.05.20 um 18:18 schrieb Alex Deucher:
> > On Wed, May 20, 2020 at 10:43 AM Christian König
> > wrote:
> >> Am 13.05.20 um 13:03 schrieb Christian König:
> >>> Unfortunately AGP is still to widely used as we could just drop support
>
On Thu, May 21, 2020 at 5:39 PM Bhawanpreet Lakha
wrote:
>
> [Why]
> Previously we used the s3 codepath for gpu reset. This can lead to issues in
> certain case where we end of waiting for fences which will never come (because
> parts of the hw are off due to gpu reset) and we end up waiting forev
On Fri, May 22, 2020 at 6:25 AM Christian König
wrote:
>
> Well what exactly is going wrong here?
>
> At least this one looks correct to me, and if it blocks the revert we
> should probably squash it in there as well.
I can squash them together. These were just dependences. The issue
is the thi
On 2020-05-22 12:40 p.m., Christian König wrote:
> Am 20.05.20 um 18:25 schrieb Michel Dänzer:
>> On 2020-05-20 4:43 p.m., Christian König wrote:
>>> Am 13.05.20 um 13:03 schrieb Christian König:
Unfortunately AGP is still to widely used as we could just drop
support for using its GART.
>
Am 20.05.20 um 18:18 schrieb Alex Deucher:
On Wed, May 20, 2020 at 10:43 AM Christian König
wrote:
Am 13.05.20 um 13:03 schrieb Christian König:
Unfortunately AGP is still to widely used as we could just drop support for
using its GART.
Not using the AGP GART also doesn't mean a loss in func
Am 20.05.20 um 18:25 schrieb Michel Dänzer:
On 2020-05-20 4:43 p.m., Christian König wrote:
Am 13.05.20 um 13:03 schrieb Christian König:
Unfortunately AGP is still to widely used as we could just drop
support for using its GART.
Not using the AGP GART also doesn't mean a loss in functionality
Am 21.05.20 um 23:32 schrieb Alex Deucher:
On Thu, May 21, 2020 at 4:45 PM Alan Swanson wrote:
Even with the "Above 4G decoding" (or similar) BIOS option enabled,
many BIOS do not assign the PCI root bus a 64-bit address space.
If available, "MMIOH Base" and "MMIO High Size" (or similar) BIOS
Well what exactly is going wrong here?
At least this one looks correct to me, and if it blocks the revert we
should probably squash it in there as well.
Christian.
Am 21.05.20 um 22:23 schrieb Alex Deucher:
This reverts commit b41d9df2b680b96913cc3ccf929252e2dce71b24.
Signed-off-by: Alex De
LGTM
Acked-by: Nirmoy Das
On 5/22/20 12:00 PM, Guchun Chen wrote:
This will assist debug in error injection case.
Signed-off-by: Guchun Chen
Reviewed-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgp
This will assist debug in error injection case.
Signed-off-by: Guchun Chen
Reviewed-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 50fe08bf2f
Am 21.05.20 um 19:06 schrieb Felix Kuehling:
Am 2020-05-21 um 9:50 a.m. schrieb Christian König:
Am 21.05.20 um 00:51 schrieb Felix Kuehling:
This fixes an intermittent bug where a root PD clear operation still in
progress could overwrite a PDE update done by the CPU, resulting in a
VM fault.
[AMD Public Use]
Thanks Tao. I will address that when pushing.
Regards,
Guchun
-Original Message-
From: Zhou1, Tao
Sent: Friday, May 22, 2020 4:51 PM
To: Chen, Guchun ; amd-gfx@lists.freedesktop.org; Zhang,
Hawking ; Clements, John ; Li,
Dennis
Subject: RE: [PATCH] drm/amdgpu: print
[AMD Public Use]
OK, but I still suggest adding "RAS" in the print to indicate its module, with
this addressed the patch is:
Reviewed-by: Tao Zhou
> -Original Message-
> From: Chen, Guchun
> Sent: 2020年5月22日 16:31
> To: Zhou1, Tao ; amd-gfx@lists.freedesktop.org;
> Zhang, Hawking ; Cl
[AMD Public Use]
Hi Tao,
Please see my response inline.
Regards,
Guchun
-Original Message-
From: Zhou1, Tao
Sent: Friday, May 22, 2020 4:11 PM
To: Chen, Guchun ; amd-gfx@lists.freedesktop.org; Zhang,
Hawking ; Clements, John ; Li,
Dennis
Subject: RE: [PATCH] drm/amdgpu: print warni
[AMD Official Use Only - Internal Distribution Only]
> -Original Message-
> From: Chen, Guchun
> Sent: 2020年5月22日 15:53
> To: amd-gfx@lists.freedesktop.org; Zhang, Hawking
> ; Zhou1, Tao ;
> Clements, John ; Li, Dennis
>
> Cc: Chen, Guchun
> Subject: [PATCH] drm/amdgpu: print warning
This will assist debug.
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 6e911ca97038..5c73f444eaef 100644
--- a/drivers/gpu/drm/am
Acked-by: Christian König
Am 22.05.20 um 08:06 schrieb Quan, Evan:
[AMD Official Use Only - Internal Distribution Only]
Patch1, 2 are reviewed-by: Evan Quan
Patch3 is acked-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Thursday, May 21, 2020 10:16 P
Am 22.05.20 um 03:25 schrieb Gustavo A. R. Silva:
The current codebase makes use of one-element arrays in the following
form:
struct something {
int length;
u8 data[1];
};
struct something *instance;
instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
instance->length = size;
m
50 matches
Mail list logo
