On Wed, 19 Apr 2017 10:01:47 +0900
Michel Dänzer wrote:
> On 18/04/17 07:14 PM, Gerd Hoffmann wrote:
> > Hi,
> >
> >>> Quite true that this proves nothing. However one should note that
> >>> fbcon -> fbdev works,
> >>
> >> BTW, this supports Gerd's patch, since the KMS fbdev emulation code
Am 19.04.2017 um 03:53 schrieb Junwei Zhang:
v2: unify PRT bit for all ASICs
Signed-off-by: Junwei Zhang
Acked-by: David Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 3 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a
On 04/19/2017 03:28 PM, Christian König wrote:
Am 19.04.2017 um 03:53 schrieb Junwei Zhang:
v2: unify PRT bit for all ASICs
Signed-off-by: Junwei Zhang
Acked-by: David Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 3 ++-
2 files chang
On 2017年04月19日 14:59, Christian König wrote:
Am 19.04.2017 um 08:52 schrieb zhoucm1:
On 2017年04月19日 14:38, Christian König wrote:
Am 19.04.2017 um 05:50 schrieb Chunming Zhou:
gtt_mgr_alloc is called by many places in local driver, while
gtt_mgr_new is called by get_node in ttm.
NAK, tha
Am 19.04.2017 um 11:15 schrieb zhoucm1:
On 2017年04月19日 14:59, Christian König wrote:
Am 19.04.2017 um 08:52 schrieb zhoucm1:
On 2017年04月19日 14:38, Christian König wrote:
Am 19.04.2017 um 05:50 schrieb Chunming Zhou:
gtt_mgr_alloc is called by many places in local driver, while
gtt_mgr_new
Am 14.04.2017 um 00:04 schrieb Andres Rodriguez:
Use an LRU policy to map usermode rings to HW compute queues.
Most compute clients use one queue, and usually the first queue
available. This results in poor pipe/queue work distribution when
multiple compute apps are running. In most cases pipe 0
Am 17.04.2017 um 14:05 schrieb Rex Zhu:
Change-Id: I27aca4ad0f06f01390c92ed7a520e9c89e99b13d
Signed-off-by: Rex Zhu
Reviewed-by: Christian König for the whole
series.
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/dri
Hi,
Would you please help to review this patch?
Thanks & Best Wishes,
Trigger Huang
-Original Message-
From: Trigger Huang [mailto:trigger.hu...@amd.com]
Sent: Tuesday, April 18, 2017 3:05 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Monk ; Yu, Xiangliang ;
Huang, Ray ; Huang, Trigger
Hi Christian,
Without correctly kunmap, page table is corrupted. Page entries point to wrong
memory locations. You might call it completely harmless. But I think this is a
severe bug. Leaking memory is better than a corrupted page table. Think
security.
Would you provide any document and ref
Am 19.04.2017 um 10:10 schrieb Zhang, Jerry (Junwei):
On 04/19/2017 03:28 PM, Christian König wrote:
Am 19.04.2017 um 03:53 schrieb Junwei Zhang:
v2: unify PRT bit for all ASICs
Signed-off-by: Junwei Zhang
Acked-by: David Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 +
drivers
Without correctly kunmap, page table is corrupted. Page entries point
to wrong memory locations. You might call it completely harmless. But
I think this is a severe bug. Leaking memory is better than a
corrupted page table. Think security.
We are talking about the page tables for the vmalloc are
Am 13.04.2017 um 03:41 schrieb Dave Airlie:
From: Dave Airlie
This just splits out a common base object to be shared
between sync_file and sem_files.
I don't think I like that approach.
A good argument of using sync_file instead of self coding it was to be
able to be able to use the resulti
Am 13.04.2017 um 03:41 schrieb Dave Airlie:
Okay I've taken Chris's suggestions to heart and reworked things
around a sem_file to see how they might look.
This means the drm_syncobj are currently only useful for semaphores,
the flags field could be used in future to use it for other things,
and
Am 10.04.2017 um 09:11 schrieb Zhang, Jerry (Junwei):
On 04/10/2017 03:02 PM, Christian König wrote:
Mhm, did you run into an actual issue or was that just from reading
the code?
Just reading the code. (maybe adding the prefix [RFC] is better)
Yeah, that is usually a good idea, but I'm forge
Hi,
> > >> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses
> > >> e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses
> > >> native endian packed colour values.
> > >
> > > Same is true for DRM_IOCTL_MODE_ADDFB, with depth/bpp 24/32 you'll get
> > > D
umr expects the ring name to be a complete word. This also
makes it consistent with GFXv7/8.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amd
umr expects the ring name to be a complete word. This also
makes it consistent with GFXv7/8.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
b/drivers/gpu/drm/amd/amd
Am 19.04.2017 um 15:10 schrieb Tom St Denis:
umr expects the ring name to be a complete word. This also
makes it consistent with GFXv7/8.
Signed-off-by: Tom St Denis
Reviewed-by: Christian König for both.
---
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 2 +-
1 file changed, 1 insertion(+),
From: Christian König
Use amdgpu_vm_bo_update_mapping() instead of amdgpu_vm_bo_split_mapping() here.
We don't want any flags set in the cleared areas and splitting
should be unnecessary.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 +++--
1 file changed, 3 in
So it's more obvious which rings are using which INV engines.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index a71521
Am 19.04.2017 um 17:03 schrieb Tom St Denis:
So it's more obvious which rings are using which INV engines.
Signed-off-by: Tom St Denis
I wonder if we shouldn't stop printing the ring numbers completely in
the ring and IB tests as well and always use the ring name.
But anyway for now the pa
On 19/04/17 11:07 AM, Christian König wrote:
Am 19.04.2017 um 17:03 schrieb Tom St Denis:
So it's more obvious which rings are using which INV engines.
Signed-off-by: Tom St Denis
I wonder if we shouldn't stop printing the ring numbers completely in
the ring and IB tests as well and always
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Tom St Denis
> Sent: Wednesday, April 19, 2017 9:11 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: StDenis, Tom
> Subject: [PATCH 2/2] drm/amd/amdgpu: Change comp GFXv9 ring name to
> remove spa
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Christian König
> Sent: Wednesday, April 19, 2017 10:07 AM
> To: amd-gfx@lists.freedesktop.org
> Subject: [PATCH] drm/amdgpu: fix amdgpu_vm_clear_freed
>
> From: Christian König
>
> Use amd
On 04/19/2017 05:07 AM, Christian König wrote:
Am 13.04.2017 um 03:41 schrieb Dave Airlie:
Okay I've taken Chris's suggestions to heart and reworked things
around a sem_file to see how they might look.
This means the drm_syncobj are currently only useful for semaphores,
the flags field could be
On 19 April 2017 at 22:07, Christian König wrote:
> Am 13.04.2017 um 03:41 schrieb Dave Airlie:
>>
>> Okay I've taken Chris's suggestions to heart and reworked things
>> around a sem_file to see how they might look.
>>
>> This means the drm_syncobj are currently only useful for semaphores,
>> the
On 17-04-11 10:23 PM, Michel Dänzer wrote:
> One possibility would be making each driver also parse the other
> driver's module parameter on the kernel command line. I.e. radeon would
> parse
>
> amdgpu.enable_cik=0
I looked for a way to do this. I think I figured out the parsing part.
But I can't
On 20 April 2017 at 04:42, Dave Airlie wrote:
> On 19 April 2017 at 22:07, Christian König wrote:
>> Am 13.04.2017 um 03:41 schrieb Dave Airlie:
>>>
>>> Okay I've taken Chris's suggestions to heart and reworked things
>>> around a sem_file to see how they might look.
>>>
>>> This means the drm_sy
On Tue, Apr 18, 2017 at 3:04 AM, Trigger Huang wrote:
> Fix issue that PSP initialization will fail if reload amdgpu module.
> That's because the PSP ring must be destroyed to be ready for the
> next time PSP initialization.
>
> Changes in v2:
> - Move psp_ring_destroy before all BOs free
Hi Christian,
Missing kunmap mapping in vmalloc will make kernel master page table incorrect.
I would not call such issue as completely harmless. Please note that AMD
graphic driver can run in 32 bit system. In 32 bit system, vmalloc address
space is much smaller than size of most GPU VRAM.
On Tue, Apr 18, 2017 at 03:04:45PM +0800, Trigger Huang wrote:
> Fix issue that PSP initialization will fail if reload amdgpu module.
> That's because the PSP ring must be destroyed to be ready for the
> next time PSP initialization.
>
> Changes in v2:
> - Move psp_ring_destroy before all
On Thu, Apr 20, 2017 at 08:53:54AM +0800, Huang Rui wrote:
> On Tue, Apr 18, 2017 at 03:04:45PM +0800, Trigger Huang wrote:
> > +int psp_v3_1_ring_destroy(struct psp_context *psp, enum psp_ring_type
> > ring_type)
> > +{
> > + int ret = 0;
> > + struct psp_ring *ring;
> > + unsign
Signed-off-by: Evan Quan
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/inc/smu9_driver_if.h | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu9_driver_if.h
b/drivers/gpu/drm/amd/powerplay/inc/smu9_driver_
On Wed, Apr 19, 2017 at 9:52 PM, Evan Quan wrote:
> Signed-off-by: Evan Quan
> Signed-off-by: Alex Deucher
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/powerplay/inc/smu9_driver_if.h | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers
On 2017年04月19日 17:40, Christian König wrote:
Am 19.04.2017 um 11:15 schrieb zhoucm1:
On 2017年04月19日 14:59, Christian König wrote:
Am 19.04.2017 um 08:52 schrieb zhoucm1:
On 2017年04月19日 14:38, Christian König wrote:
Am 19.04.2017 um 05:50 schrieb Chunming Zhou:
gtt_mgr_alloc is called b
Change-Id: If0474e24e14d237d2d55731871c5ceb11e5a3601
Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 9 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git
Change-Id: Icdf2486a2d1116e71dc8958cda679a4a83838489
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index d74a406..8f201
Fix issue that PSP initialization will fail if reload amdgpu module.
That's because the PSP ring must be destroyed to be ready for the
next time PSP initialization.
Changes in v2:
- Move psp_ring_destroy before all BOs free (suggested by
Ray Huang).
Changes in v3:
- Check
Hi Ray,
Thanks for your suggestions. As discussed, free adev->firmware.rbuf is still
needed.
I have made a patch V3 according to your suggestions.
Thanks & Best Wishes,
Trigger Huang
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Huang
Rui
Hi Alex,
Thanks for your help.
Thanks & Best Wishes,
Trigger Huang
-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Thursday, April 20, 2017 3:18 AM
To: Huang, Trigger
Cc: amd-gfx list ; Huang, Ray
; Yu, Xiangliang ; Liu, Monk
Subject: Re: [PATCH V2] drm/
On 04/19/2017 10:07 PM, Christian König wrote:
From: Christian König
Use amdgpu_vm_bo_update_mapping() instead of amdgpu_vm_bo_split_mapping() here.
We don't want any flags set in the cleared areas and splitting
should be unnecessary.
Yeah, the mappings in the freed list are split already, I
On 04/20/2017 01:49 PM, Zhang, Jerry (Junwei) wrote:
On 04/19/2017 10:07 PM, Christian König wrote:
From: Christian König
Use amdgpu_vm_bo_update_mapping() instead of amdgpu_vm_bo_split_mapping() here.
We don't want any flags set in the cleared areas and splitting
should be unnecessary.
Yea
On Thu, Apr 20, 2017 at 12:15:52PM +0800, Trigger Huang wrote:
> Fix issue that PSP initialization will fail if reload amdgpu module.
> That's because the PSP ring must be destroyed to be ready for the
> next time PSP initialization.
>
> Changes in v2:
> - Move psp_ring_destroy before all
43 matches
Mail list logo
