count indicats the total number of key in handle table
max_key becomes the max value of key
Signed-off-by: Junwei Zhang
---
amdgpu/handle_table.c | 18 +++---
amdgpu/handle_table.h | 1 +
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/amdgpu/handle_table.c b/amdgpu/
Userspace needs to know if the user memory is from BO or malloc.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu.h| 23 +++
amdgpu/amdgpu_bo.c | 34 ++
2 files changed, 57 insertions(+)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index be
Add a test for API to query bo by CPU mapping
Signed-off-by: Junwei Zhang
Reviewed-by: Christian König
---
tests/amdgpu/bo_tests.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/tests/amdgpu/bo_tests.c b/tests/amdgpu/bo_tests.c
index 9d4da4a..dc2de9b 1006
When create bo from user memory, add it to handle table
for future query.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu_bo.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index 422c7c9..b24e698 100644
--- a/amdgpu/amdgpu_b
On 2018年08月07日 15:26, Junwei Zhang wrote:
When create bo from user memory, add it to handle table
for future query.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu_bo.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
ind
On 2018年08月07日 15:26, Junwei Zhang wrote:
Userspace needs to know if the user memory is from BO or malloc.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu.h| 23 +++
amdgpu/amdgpu_bo.c | 34 ++
2 files changed, 57 insertions(+)
diff -
Well NAK, that wasn't the intention of putting all BOs into the handle
table.
You should still use the kernel implementation.
Christian.
Am 07.08.2018 um 09:26 schrieb Junwei Zhang:
Userspace needs to know if the user memory is from BO or malloc.
Signed-off-by: Junwei Zhang
---
amdgpu/amd
On 08/07/2018 04:20 PM, Christian König wrote:
Well NAK, that wasn't the intention of putting all BOs into the handle table.
You should still use the kernel implementation.
I thought we have discussed that in below mail thread. any gap?
[PATCH 1/2] drm/amdgpu: return bo itself if userptr is c
This patch is to fix the warning to remove unused variable.
/home/ray/linux/drivers/gpu/drm//amd/amdgpu/amdgpu_ctx.c:
In function ‘amdgpu_ctx_priority_override’:
/home/ray/linux/drivers/gpu/drm//amd/amdgpu/amdgpu_ctx.c:397:23:
warning: unused variable ‘rq’ [-Wunused-variable]
struct drm_sched_rq
Am 07.08.2018 um 10:47 schrieb Huang Rui:
This patch is to fix the warning to remove unused variable.
/home/ray/linux/drivers/gpu/drm//amd/amdgpu/amdgpu_ctx.c:
In function ‘amdgpu_ctx_priority_override’:
/home/ray/linux/drivers/gpu/drm//amd/amdgpu/amdgpu_ctx.c:397:23:
warning: unused variable ‘r
Am 07.08.2018 um 09:55 schrieb zhoucm1:
On 2018年08月07日 15:26, Junwei Zhang wrote:
Userspace needs to know if the user memory is from BO or malloc.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu.h | 23 +++
amdgpu/amdgpu_bo.c | 34 ++
Am 07.08.2018 um 10:28 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 04:20 PM, Christian König wrote:
Well NAK, that wasn't the intention of putting all BOs into the
handle table.
You should still use the kernel implementation.
I thought we have discussed that in below mail thread. any gap?
On 08/07/2018 05:33 PM, Christian König wrote:
Am 07.08.2018 um 10:28 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 04:20 PM, Christian König wrote:
Well NAK, that wasn't the intention of putting all BOs into the handle table.
You should still use the kernel implementation.
I thought we have
On 08/07/2018 03:51 PM, zhoucm1 wrote:
On 2018年08月07日 15:26, Junwei Zhang wrote:
When create bo from user memory, add it to handle table
for future query.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu_bo.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/amd
Am 07.08.2018 um 11:52 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 05:33 PM, Christian König wrote:
Am 07.08.2018 um 10:28 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 04:20 PM, Christian König wrote:
Well NAK, that wasn't the intention of putting all BOs into the
handle table.
You should s
Am 07.08.2018 um 11:54 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 03:51 PM, zhoucm1 wrote:
On 2018年08月07日 15:26, Junwei Zhang wrote:
When create bo from user memory, add it to handle table
for future query.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu_bo.c | 11 ++-
1 file cha
On 2018年08月07日 17:30, Christian König wrote:
Am 07.08.2018 um 09:55 schrieb zhoucm1:
On 2018年08月07日 15:26, Junwei Zhang wrote:
Userspace needs to know if the user memory is from BO or malloc.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu.h | 23 +++
amdgpu/amdgpu
Under runtime, the wait fence time could be quite long when
other VFs are in exclusive mode.
SWDEV-161490
Change-Id: Ifc32d56ca7fde01b1f4fe2b0db6959b51909008a
Signed-off-by: Monk Liu
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
1 file changed, 1 insertion(+)
On 08/07/2018 05:59 PM, Christian König wrote:
Am 07.08.2018 um 11:52 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 05:33 PM, Christian König wrote:
Am 07.08.2018 um 10:28 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 04:20 PM, Christian König wrote:
Well NAK, that wasn't the intention of putti
Thanks for that!
Reviewed-by: Kent Russell
-Original Message-
From: amd-gfx On Behalf Of Huang Rui
Sent: Tuesday, August 07, 2018 1:28 AM
To: Gustavo A. R. Silva ; Kuehling, Felix
Cc: Oded Gabbay ; Zhou, David(ChunMing)
; David Airlie ;
linux-ker...@vger.kernel.org; amd-gfx@lists.fre
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As s
On Tue, Aug 07, 2018 at 11:45:00AM +0100, Chris Wilson wrote:
> amdgpu only uses shared-fences internally, but dmabuf importers rely on
> implicit write hazard tracking via the reservation_object.fence_excl.
> For example, the importer use the write hazard for timing a page flip to
> only occur aft
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As s
Quoting Huang Rui (2018-08-07 11:56:24)
> On Tue, Aug 07, 2018 at 11:45:00AM +0100, Chris Wilson wrote:
> > amdgpu only uses shared-fences internally, but dmabuf importers rely on
> > implicit write hazard tracking via the reservation_object.fence_excl.
> > For example, the importer use the write h
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As s
Am 07.08.2018 um 13:05 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
Well I would rather suggest a solution where we stop doing this.
The problem here is that i915 assumes that
Am 07.08.2018 um 12:23 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 05:59 PM, Christian König wrote:
Am 07.08.2018 um 11:52 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 05:33 PM, Christian König wrote:
Am 07.08.2018 um 10:28 schrieb Zhang, Jerry (Junwei):
On 08/07/2018 04:20 PM, Christian Kön
Am 07.08.2018 um 09:26 schrieb Junwei Zhang:
Userspace needs to know if the user memory is from BO or malloc.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu.h| 23 +++
amdgpu/amdgpu_bo.c | 34 ++
2 files changed, 57 insertions(+)
diff
On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
> Am 07.08.2018 um 13:05 schrieb Chris Wilson:
> > amdgpu only uses shared-fences internally, but dmabuf importers rely on
> > implicit write hazard tracking via the reservation_object.fence_excl.
>
> Well I would rather suggest a so
On Tue, Aug 07, 2018 at 02:43:22PM +0200, Daniel Vetter wrote:
> On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
> > Am 07.08.2018 um 13:05 schrieb Chris Wilson:
> > > amdgpu only uses shared-fences internally, but dmabuf importers rely on
> > > implicit write hazard tracking via t
Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
Am 07.08.2018 um 13:05 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_exc
On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:
> Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
> > On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
> > > Am 07.08.2018 um 13:05 schrieb Chris Wilson:
> > > > amdgpu only uses shared-fences internally, but dmabuf impo
Am 07.08.2018 um 14:59 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:
Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
Am 07.08.2018 um 13:05 schrieb Chris Wilson:
amdgpu only uses shared-fe
On Tue, Aug 07, 2018 at 03:17:06PM +0200, Christian König wrote:
> Am 07.08.2018 um 14:59 schrieb Daniel Vetter:
> > On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:
> > > Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
> > > > On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König
Am 07.08.2018 um 15:37 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 03:17:06PM +0200, Christian König wrote:
Am 07.08.2018 um 14:59 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:
Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 0
On Tue, Aug 7, 2018 at 3:54 PM, Christian König
wrote:
> Am 07.08.2018 um 15:37 schrieb Daniel Vetter:
>>
>> On Tue, Aug 07, 2018 at 03:17:06PM +0200, Christian König wrote:
>>>
>>> Am 07.08.2018 um 14:59 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wr
On Sun, Jul 29, 2018 at 4:39 PM, Christian König
wrote:
>> Do you need further informations?
>
> No, that is a known issue.
>
Hi,
is there any progress on this?
Thanks.
Regards,
- Sedat -
> Regards,
> Christian.
>
>
> Am 29.07.2018 um 15:52 schrieb Sedat Dilek:
>>
>> Hi,
>>
>> when compiling
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As s
On Tue, Aug 7, 2018 at 6:22 AM, Emily Deng wrote:
> Under runtime, the wait fence time could be quite long when
> other VFs are in exclusive mode.
>
> SWDEV-161490
>
> Change-Id: Ifc32d56ca7fde01b1f4fe2b0db6959b51909008a
> Signed-off-by: Monk Liu
> Signed-off-by: Emily Deng
Seems pretty long.
Since commit 09ea0dfbf972 ("dma-buf: make map_atomic and map function
pointers optional"), we no longer need to provide stub no-op functions
as the core now provides them directly.
References: 09ea0dfbf972 ("dma-buf: make map_atomic and map function pointers
optional")
Signed-off-by: Chris Wilson
Am 07.08.2018 um 19:47 schrieb Chris Wilson:
Since commit 09ea0dfbf972 ("dma-buf: make map_atomic and map function
pointers optional"), we no longer need to provide stub no-op functions
as the core now provides them directly.
References: 09ea0dfbf972 ("dma-buf: make map_atomic and map function p
On Tue, Aug 07, 2018 at 06:47:48PM +0100, Chris Wilson wrote:
> Since commit 09ea0dfbf972 ("dma-buf: make map_atomic and map function
> pointers optional"), we no longer need to provide stub no-op functions
> as the core now provides them directly.
>
> References: 09ea0dfbf972 ("dma-buf: make map_
Am 07.08.2018 um 18:08 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has fin
Quoting Christian König (2018-08-07 18:57:16)
> Am 07.08.2018 um 18:08 schrieb Chris Wilson:
> > amdgpu only uses shared-fences internally, but dmabuf importers rely on
> > implicit write hazard tracking via the reservation_object.fence_excl.
> > For example, the importer use the write hazard for t
Am 07.08.2018 um 20:14 schrieb Chris Wilson:
Quoting Christian König (2018-08-07 18:57:16)
Am 07.08.2018 um 18:08 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the
Quoting Christian König (2018-08-07 19:18:55)
> Am 07.08.2018 um 20:14 schrieb Chris Wilson:
> > Quoting Christian König (2018-08-07 18:57:16)
> >> Am 07.08.2018 um 18:08 schrieb Chris Wilson:
> >>> amdgpu only uses shared-fences internally, but dmabuf importers rely on
> >>> implicit write hazard
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As s
Am 07.08.2018 um 20:32 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has fin
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As s
Properly swap when reading from the vbios.
Signed-off-by: Alex Deucher
---
.../amd/powerplay/hwmgr/process_pptables_v1_0.c| 194 ++---
1 file changed, 97 insertions(+), 97 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
b/drivers/gpu/dr
Properly swap when reading from the vbios.
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/powerplay/hwmgr/processpptables.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/processpptables.c
b/drivers/gpu/drm/amd/
Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Wednesday, August 08, 2018 5:32 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: [PATCH 2/2] drm/amdgpu/pp: endian fixes for processpptables.c
>
> Properly swap whe
Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Wednesday, August 08, 2018 5:32 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: [PATCH 1/2] drm/amdgpu/pp: endian fixes for
> process_pptables_v1_0.c
>
> Properly
Series is:
Reviewed-by: Rex Zhu
Regards
Rex
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Wednesday, August 8, 2018 5:32 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 2/2] drm/amdgpu/pp: endian fixes for processpptables.c
Properly swap
Hi Alex,
Thanks for your review.
The host gim driver gives every VF fullaccess_timeout is 3000, so for 4
vf, the worst case is 3*3000(9000), if the vf number is more than 4,
then the time will be longer, so 8000 is not the worst time.
But with using 8000, it will pass all the TDR t
Modify the commit message
Extend the timeout for recovering vram bos from shadows on sr-iov
to cover the worst case scenario for timeslices and VFs
Under runtime, the wait fence time could be quite long when
other VFs are in exclusive mode. For example, for 4 VF, every
VF's exclusive timeout time
When create bo from user memory, add it to handle table
for future query.
Signed-off-by: Junwei Zhang
Reviewed-by: Christian König
---
amdgpu/amdgpu_bo.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index 422c7c9..b24e69
Userspace needs to know if the user memory is from BO or malloc.
v2: update mutex range and rebase
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu.h| 23 +++
amdgpu/amdgpu_bo.c | 34 ++
2 files changed, 57 insertions(+)
diff --git a/amdgpu/
Add a test for API to query bo by CPU mapping
Signed-off-by: Junwei Zhang
Reviewed-by: Christian König
---
tests/amdgpu/bo_tests.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/tests/amdgpu/bo_tests.c b/tests/amdgpu/bo_tests.c
index 9d4da4a..dc2de9b 1006
a helper function to create and initialize amdgpu bo
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu_bo.c | 81 ++
1 file changed, 33 insertions(+), 48 deletions(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index a7f0662..59cba69 1006
On 2018年08月08日 12:08, Junwei Zhang wrote:
Userspace needs to know if the user memory is from BO or malloc.
v2: update mutex range and rebase
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu.h| 23 +++
amdgpu/amdgpu_bo.c | 34 ++
2 file
Am 06.08.2018 02:13, schrieb Dieter Nützel:
Am 04.08.2018 06:18, schrieb Dieter Nützel:
Am 04.08.2018 06:12, schrieb Dieter Nützel:
Am 04.08.2018 05:27, schrieb Dieter Nützel:
Am 03.08.2018 13:09, schrieb Christian König:
Am 03.08.2018 um 03:08 schrieb Dieter Nützel:
Hello Christian, AMD guy
Am 08.08.2018 um 06:23 schrieb zhoucm1:
On 2018年08月08日 12:08, Junwei Zhang wrote:
Userspace needs to know if the user memory is from BO or malloc.
v2: update mutex range and rebase
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu.h | 23 +++
amdgpu/amdgpu_bo.c | 34 ++
Am 08.08.2018 um 06:08 schrieb Junwei Zhang:
a helper function to create and initialize amdgpu bo
Can the new function be also used to initialize a BO structure during
import?
Apart from that it look like a nice cleanup to me,
Christian.
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu_bo
64 matches
Mail list logo
