Hi Christian
Many thanks for your review.
The background is that this bo is to let psp load sos and sysdrv but under
sriov, sos and sysdrv is loaded by VBIOS or hypervisor driver.
The reason why not let guest driver to load it under SRIOV is that it is not
safe.
Best Regards
Yintian Ta
Hi Yintian,
please add this as a code comment to the patch.
Christian.
Am 17.05.19 um 09:17 schrieb Tao, Yintian:
Hi Christian
Many thanks for your review.
The background is that this bo is to let psp load sos and sysdrv but
under sriov, sos and sysdrv is loaded by VBIOS or hypervisor d
Hi Chrisitian
Yes, of course. Thanks for your reminder.
Best Regards
Yintian Tao
发件人: Christian König
发送时间: 2019年5月17日 15:20:54
收件人: Tao, Yintian; Koenig, Christian
抄送: amd-gfx@lists.freedesktop.org; Liu, Monk
主题: Re: 答复: [PATCH] drm/amdgpu: skip fw pri bo
On Thu, May 09, 2019 at 10:31:05AM +, Pan, Xinhui wrote:
> add badpages node.
> it will output badpages list in format
> gpu pfn : gpu page size : flags
>
> example
> 0x : 0x1000 : R
> 0x0001 : 0x1000 : R
> 0x0002 : 0x1000 : R
> 0x0003 : 0x1000 : R
> 0x0
Hi Christian，
With the series patch set , amdgpu_vm_validate_pt_bos occasionally evicted
amdgpu BOs failed and can’t
find the valid first busy bo . Another problem is that during the first BOs
get lock period will run into deadlock .
/* check if other user occupy memory too long time */
Instead if guest load “sos” and “sysdrv” there are two kinds of result:
1. For elder version PSP boot loader guest would hit failure.
2. For new version PSP boot loader those ucode won’t work at all so loading
the is redundant
/Monk
From: Tao, Yintian
Sent: Friday, May 17, 2019 3:17 PM
To
Use struct_size() helper to keep code simple.
Signed-off-by: xiaolinkui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 22bd21e..4717a64 1006
On 2019-04-30 3:56 p.m., Mario Kleiner wrote:
> [CAUTION: External Email]
>
> On Tue, Apr 30, 2019 at 2:22 PM Kazlauskas, Nicholas
> wrote:
>>
>> On 4/30/19 3:44 AM, Michel Dänzer wrote:
>>> [CAUTION: External Email]
>>>
>>> On 2019-04-30 9:37 a.m., Mario Kleiner wrote:
Allow to detect any
Add a file that provides a Unique ID for the GPU.
This will persist across machines and is guaranteed to be unique.
This is only available for GFX9 and newer, so older ASICs will not
have this file in the sysfs pool
Change-Id: I3c673f78efcc5bf93ca58d65edbe39fc3a86b42a
Signed-off-by: Kent Russell
> -Original Message-
> From: Christian König
> Sent: Tuesday, May 14, 2019 8:31 PM
> To: Olsak, Marek ; Zhou, David(ChunMing)
> ; Liang, Prike ; dri-
> de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org
> Subject: [PATCH 01/11] drm/ttm: Make LRU removal optional.
>
> [CAUTION: E
Not necessary on soc15 and breaks driver reload on server cards.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index 3
How about combining these two patches into one? This seems cleaner.
Alex
On Thu, May 16, 2019 at 10:39 PM Tao, Yintian wrote:
>
> Ping...
>
> Hi Christian and Alex
>
>
> Can you help review this? Thanks in advance.
>
>
> Best Regards
> Yintian Tao
>
> -Original Message-
> From: Yintian
On 2019-05-17 10:26 a.m., Alex Deucher wrote:
> [CAUTION: External Email]
>
> Not necessary on soc15 and breaks driver reload on server cards.
>
> Signed-off-by: Alex Deucher
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/amd/amdgpu/soc15.c | 5 +
> 1 file changed, 5 insertions(+)
>
Hi Andrey,
On Mon, May 06, 2019 at 06:30:46PM +0200, Andrey Konovalov wrote:
> One of the alternative approaches to untagging that was considered is to
> completely strip the pointer tag as the pointer enters the kernel with
> some kind of a syscall wrapper, but that won't work with the countless
Hi Alex
Many thanks for your review. I will merge these two patches into one and submit
again.
Best Regards
Yintian Tao
发件人: Alex Deucher
发送时间: 2019年5月17日 22:34:30
收件人: Tao, Yintian
抄送: amd-gfx@lists.freedesktop.org; Koenig, Christian; Deucher, Alexander;
On Thu, May 16, 2019 at 1:39 PM Alex Deucher wrote:
>
> On Thu, May 16, 2019 at 4:07 PM Micah Morton wrote:
> >
> > On Wed, May 15, 2019 at 7:19 PM Alex Deucher wrote:
> > >
> > > On Wed, May 15, 2019 at 2:26 PM Micah Morton wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > I'm interested in run
amdkfd (part of amdgpu) driver supports the AMD GPU compute stack.
amdkfd exposes only a single device /dev/kfd even if multiple AMD GPU
(compute) devices exist in a system. However, amdgpu drvier exposes a
separate render device file /dev/dri/renderDN for each device. To participate
in device cgro
This is required to check against cgroup permissions.
Signed-off-by: Harish Kasiviswanathan
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 10 ++
drivers/gpu/drm/amd/amdkfd/kfd_topology.h | 3 +++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/
kfd needs drm_device to call into drm_cgroup functions
Signed-off-by: Harish Kasiviswanathan
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 +
drivers/gpu/drm/amd/amdkfd/kfd_device.c| 2 ++
drivers/gpu/drm/am
For AMD compute (amdkfd) driver.
All AMD compute devices are exported via single device node /dev/kfd. As
a result devices cannot be controlled individually using device cgroup.
AMD compute devices will rely on its graphics counterpart that exposes
/dev/dri/renderN node for each device. For each
Participate in device cgroup. All kfd devices are exposed via /dev/kfd.
So use /dev/dri/renderN node.
Before exposing the device to a task check if it has permission to
access it. If the task (based on its cgroup) can access /dev/dri/renderN
then expose the device via kfd node.
If the task cannot
better to use div64_ul(x, y) for compatiblity.
From: Abramov, Slava
Sent: Friday, May 17, 2019 5:19:54 AM
To: amd-gfx@lists.freedesktop.org
Cc: Pan, Xinhui; Deucher, Alexander
Subject: [PATCH] drm/amdgpu: cast to unsigned int for 32-bit portability
Without casting
I am going to put more members which are also array after this struct, not only
obj[]. Looks like this struct_size did not help on multiple array case. Thanks
anyway.
From: xiaolinkui
Sent: Friday, May 17, 2019 4:46:00 PM
To: Deucher, Alexander; Koenig, Christia
On Fri, May 17, 2019 at 04:14:52PM +, Kasiviswanathan, Harish wrote:
> amdkfd (part of amdgpu) driver supports the AMD GPU compute stack.
> amdkfd exposes only a single device /dev/kfd even if multiple AMD GPU
> (compute) devices exist in a system. However, amdgpu drvier exposes a
> separate re
On Fri, May 17, 2019 at 11:36 AM Micah Morton wrote:
>
> On Thu, May 16, 2019 at 1:39 PM Alex Deucher wrote:
> >
> > On Thu, May 16, 2019 at 4:07 PM Micah Morton wrote:
> > >
> > > On Wed, May 15, 2019 at 7:19 PM Alex Deucher
> > > wrote:
> > > >
> > > > On Wed, May 15, 2019 at 2:26 PM Micah M
On Fri, May 17, 2019 at 10:47 AM Lin, Amber wrote:
>
>
>
> On 2019-05-17 10:26 a.m., Alex Deucher wrote:
> > [CAUTION: External Email]
> >
> > Not necessary on soc15 and breaks driver reload on server cards.
> >
> > Signed-off-by: Alex Deucher
> > Cc: sta...@vger.kernel.org
> > ---
> > drivers/
Did you see the patch I attached?
Alex
From: Tao, Yintian
Sent: Friday, May 17, 2019 10:51 AM
To: Alex Deucher
Cc: amd-gfx@lists.freedesktop.org; Koenig, Christian; Deucher, Alexander;
Huang, Trigger
Subject: 答复: [PATCH] drm/amdgpu: set correct vram_width for vega
On Fri, May 17, 2019 at 04:15:06PM +, Kasiviswanathan, Harish wrote:
> For AMD compute (amdkfd) driver.
>
> All AMD compute devices are exported via single device node /dev/kfd. As
> a result devices cannot be controlled individually using device cgroup.
>
> AMD compute devices will rely on i
For SR-IOV, vram_width can't be read from ATOM as
RAVEN, and DF related registers is not readable, so hardcord
is the only way to set the correct vram_width.
Signed-off-by: Trigger Huang
Signed-off-by: Yintian Tao
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 10 +
Hello!
Registration & Call for Proposals are now open for XDC 2019, which will
take place at the Concordia University Conference Centre in Montréal,
Canada on October 2-4, 2019.
Thanks to LWN.net, this year we have a brand new website using the
Indico platform, a fully open source event managemen
On Fri, May 17, 2019 at 9:45 AM Russell, Kent wrote:
>
> Add a file that provides a Unique ID for the GPU.
> This will persist across machines and is guaranteed to be unique.
> This is only available for GFX9 and newer, so older ASICs will not
> have this file in the sysfs pool
>
> Change-Id: I3c6
Add a file that provides a Unique ID for the GPU.
This will persist across machines and is guaranteed to be unique.
This is only available for GFX9 and newer, so older ASICs will not
have this file in the sysfs pool
v2: Store it in adev for ASICs that don't have a hwmgr
Change-Id: I3c673f78efcc5b
v1: replace casting to unsigned long with div64_ul
Change-Id: Ia48671ed0756bb73c7b4760a800bcb6f600cbef2
Signed-off-by: Slava Abramov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
b/driv
On Fri, May 17, 2019 at 2:31 PM Russell, Kent wrote:
>
> Add a file that provides a Unique ID for the GPU.
> This will persist across machines and is guaranteed to be unique.
> This is only available for GFX9 and newer, so older ASICs will not
> have this file in the sysfs pool
>
> v2: Store it in
Acked-by: Amber Lin
On 2019-05-17 1:02 p.m., Alex Deucher wrote:
> [CAUTION: External Email]
>
> On Fri, May 17, 2019 at 10:47 AM Lin, Amber wrote:
>>
>>
>> On 2019-05-17 10:26 a.m., Alex Deucher wrote:
>>> [CAUTION: External Email]
>>>
>>> Not necessary on soc15 and breaks driver reload on serv
On Fri, May 17, 2019 at 2:34 PM Abramov, Slava wrote:
>
> v1: replace casting to unsigned long with div64_ul
>
> Change-Id: Ia48671ed0756bb73c7b4760a800bcb6f600cbef2
> Signed-off-by: Slava Abramov
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 4 ++--
> 1 file change
Hi Tejun,
Thanks for comments. I can definitely add more documentation but just need a
bit of clarification on this.
1). Documentation for user on how to use device cgroup for amdkfd device. I
have some more information on this in patch 4.
or
2) The reason devcgroup_check_permission() needs to
Patches 1,2,4 will be submitted through amd-staging-drm-next. Patch 3
goes through the cgroup tree. Patch 4 depends on patch 3. So submitting
patch 4 will need to wait until we rebase amd-staging-drm-next on a new
enough kernel release that includes patch 3.
Patch 1 and 2 could be submitted now
On 5/17/19 3:35 PM, Erico Nunes wrote:
> [CAUTION: External Email]
>
> Hello,
>
> I have recently observed a memory leak issue with lima using
> drm-misc-next, which I initially reported here:
> https://gitlab.freedesktop.org/lima/linux/issues/24
> It is an easily reproduceable memory leak which I
Hello,
I have recently observed a memory leak issue with lima using
drm-misc-next, which I initially reported here:
https://gitlab.freedesktop.org/lima/linux/issues/24
It is an easily reproduceable memory leak which I was able to bisect to commit:
5918045c4ed4 drm/scheduler: rework job destructio
On Fri, May 17, 2019 at 10:43 PM Grodzovsky, Andrey
wrote:
> On 5/17/19 3:35 PM, Erico Nunes wrote:
> > Lima currently defaults to an "infinite" timeout. Setting a 500ms
> > default timeout like most other drm_sched users do fixed the leak for
> > me.
>
> I am not very clear about the problem - so
Don't have the code in front of me now but as far as I remember it will only
prematurely terminate in drm_sched_cleanup_jobs if there is timeout work in
progress which would not be the case if nothing hangs.
Andrey
From: Erico Nunes
Sent: 17 May 2019 17
42 matches
Mail list logo
