I will drop this one, because I found many other functions use 32 bits
as well and it seems to be convenient.
Regards,
Yong
On 2019-09-30 11:54 a.m., Kuehling, Felix wrote:
> If you want to make this interface consistent, you should make the vmid
> parameter uint8_t at the same time. That
The code use hex define, so should the printing.
Change-Id: Ia7cc7690553bb043915b3d8c0157216c64421a60
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
On Thu, Sep 19, 2019 at 3:03 AM Koenig, Christian
wrote:
>
> Am 18.09.19 um 21:05 schrieb Navid Emamdoost:
> > In acp_hw_init there are some allocations that needs to be released in
> > case of failure:
> >
> > 1- adev->acp.acp_genpd should be released if any allocation attemp for
> >
In acp_hw_init there are some allocations that needs to be released in
case of failure:
1- adev->acp.acp_genpd should be released if any allocation attemp for
adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails.
2- all of those allocations should be released if
mfd_add_hotplug_devices or
The 'debug_data' variable gets printed in debug statements without a
prior initialization in the function
hubbub1_verify_allow_pstate_change_high, as reported when building with
gcc 9.1.0:
warning: ‘debug_data’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
290 |
Not much relationship between them, except that this functional change is to
fix a IOCTL error printing.
Yong
From: Kuehling, Felix
Sent: Monday, September 30, 2019 11:57 AM
To: Zhao, Yong ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 5/6] drm/amdgpu:
Okay, I will change dev_err back to dev_dbg. The hex printing is still very
useful.
Yong
From: Kuehling, Felix
Sent: Monday, September 30, 2019 11:47 AM
To: Zhao, Yong ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 6/6] drm/amdkfd: Improve KFD IOCTL
Thanks. Will check that and fix the missing const.
Yong
From: Kuehling, Felix
Sent: Monday, September 30, 2019 11:42 AM
To: Zhao, Yong ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/6] drm/amdkfd: Use array to probe kfd2kgd_calls
On 2019-09-27 11:41
As far as I can tell, this is the only patch with functional changes in
the patch series. The rest are purely clean-up. Any relation I'm missing?
Anyway, patches 2,3,5 are
Reviewed-by: Felix Kuehling
On 2019-09-27 11:41 p.m., Zhao, Yong wrote:
> The HDP flush support code was missing in the
If you want to make this interface consistent, you should make the vmid
parameter uint8_t at the same time. That said, you don't really save any
resources, because 8-bit and 16-bit ints still consume 32-bits on the
call stack.
Regards,
Felix
On 2019-09-27 11:41 p.m., Zhao, Yong wrote:
>
On 2019-09-27 11:41 p.m., Zhao, Yong wrote:
> The code use hex define, so should the printing. Also, printf a message
> if there is a failure.
>
> Change-Id: Ia7cc7690553bb043915b3d8c0157216c64421a60
> Signed-off-by: Yong Zhao
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 5 +++--
> 1
On 2019-09-27 11:41 p.m., Zhao, Yong wrote:
> This is the same idea as the kfd device info probe and move all the
> probe control together for easy maintenance.
>
> Change-Id: I85c98bb08eb2a4a1a80c3b913c32691cc74602d1
> Signed-off-by: Yong Zhao
Nice clean-up. See one comment inline.
Also,
On Mon, Sep 30, 2019 at 09:51:35AM +, Brian Starkey wrote:
> Hi,
>
> On Tue, Sep 17, 2019 at 07:36:45PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 17, 2019 at 6:15 PM Neil Armstrong
> > wrote:
> > >
> > > Hi,
> > >
> > > On 17/09/2019 18:07, Liviu Dudau wrote:
> > > > On Tue, Sep 17, 2019
Am 30.09.19 um 11:06 schrieb Zhou1, Tao:
Hi Christian:
So the allocation information of a bo's vram page could be reserved after vram
lost?
Yes, exactly. VRAM lost just means that we are returning an error code
to userspace when they try to use a context created before VRAM was lost.
In
Hi Christian:
So the allocation information of a bo's vram page could be reserved after vram
lost?
In fact, this series could be dropped if the result of
amdgpu_bo_create_reserved is guaranteed to be failed after vram lost (protect
bad pages from reallocating).
Hi Andrey:
A bad page's
Am 30.09.19 um 05:19 schrieb Zhou1, Tao:
the info of retired page's bo may be lost if vram lost is encountered
in gpu reset (gpu page table in vram may be lost), force to recreate
all bos
v2: simplify NULL pointer check
add more comments
Repeating on the v2 of the patch set, this is
Am 29.09.19 um 09:40 schrieb Huang, Ray:
Mark a job as secure, if and only if the command
submission flag has the secure flag set.
v2: fix the null job pointer while in vmid 0
submission.
v3: Context --> Command submission.
v4: filling cs parser with cs->in.flags
v5: move the job secure flag
Am 29.09.19 um 08:35 schrieb Zhou1, Tao:
the info of retired page's bo may be lost if vram lost is encountered
in gpu reset (gpu page table in vram may be lost), force to recreate
all bos
NAK, that is complete nonsense.
When VRAM is lost the content of BOs in VRAM is lost, but the BOs itself
> -Original Message-
> From: Chen, Guchun
> Sent: 2019年9月30日 15:14
> To: Zhou1, Tao ; amd-gfx@lists.freedesktop.org;
> Zhang, Hawking
> Subject: RE: [PATCH] drm/amdgpu: avoid ras error injection for retired page
>
>
>
>
> Regards,
> Guchun
>
> -Original Message-
> From:
Regards,
Guchun
-Original Message-
From: Zhou1, Tao
Sent: Monday, September 30, 2019 2:58 PM
To: amd-gfx@lists.freedesktop.org; Chen, Guchun ; Zhang,
Hawking
Cc: Zhou1, Tao
Subject: [PATCH] drm/amdgpu: avoid ras error injection for retired page
check whether a page is bad page
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Saurav Girepunje
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
index
check whether a page is bad page before error injection
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 38 +
1 file changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index
22 matches
Mail list logo
