From: Monk Liu
Sent: Tuesday, July 18, 2017 1:56 PM
To: amd-gfx-boun...@lists.freedesktop.org
Cc: Liu, Monk; Yu, Xiangliang
Subject: [PATCH] drm/amdgpu:fix gfx fence allocate size
1, for sriov, we need 8dw for the gfx fence due to CP
behaviour
2, cleanup wrong
Hi Alex,
This patch series went into amd-kfd-staging. I'd like to also push it
into amd-staging-4.11 as I'm just working to minimize any unnecessary
differences between the branches before the big KFD history rework.
I rebased it, resolved some contlicts, and removed the declaration of
get_mec_nu
1, for sriov, we need 8dw for the gfx fence due to CP
behaviour
2, cleanup wrong logic in wptr/rptr wb alloc and free
Change-Id: Ifbfed17a4621dae57244942ffac7de1743de0294
Signed-off-by: Monk Liu
Signed-off-by: Xiangliang Yu
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 ++
drivers/gpu/drm
From: Dave Airlie
This is a port of radv to the new lowlevel cs submission APIs
for libdrm that I submitted earlier.
This moves a lot of the current non-shared semaphore handling
and chunk creation out of libdrm_amdgpu. It provides a much
simpler implementation without all the list handling, I'm
Allows gdb to access contents of user mode mapped VRAM BOs.
v2: return error for non-VRAM pools
Signed-off-by: Felix Kuehling
Reviewed-by: Michel Dänzer
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 62 +
1 file changed, 62 insertions(
Allows gdb to access contents of user mode mapped BOs. System memory
is handled by TTM using kmap. Other memory pools require a new driver
callback in ttm_bo_driver.
v2:
* kmap only one page at a time
* swap in BO if needed
* make driver callback more generic to handle private memory pools
* docum
From: Dave Airlie
This just sends chunks to the kernel API for a single command
stream.
This should provide a more future proof and extensible API
for command submission.
v2: use amdgpu_bo_list_handle, add two helper functions to
access bo and context internals.
Signed-off-by: Dave Airlie
---
> -Original Message-
> From: Junwei Zhang [mailto:jerry.zh...@amd.com]
> Sent: Monday, July 17, 2017 10:54 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander; Huang, Ray; gre...@linuxfoundation.org; Zhang,
> Jerry; sta...@vger.kernel.org
> Subject: [PATCH] drm/amdgpu: read reg
On 18 July 2017 at 03:02, Christian König wrote:
> Am 17.07.2017 um 05:36 schrieb Dave Airlie:
>>>
>>> I can take a look at it, I just won't have time until next week most
>>> likely.
>>
>> I've taken a look, and it's seemingly more complicated than I'm
>> expecting I'd want to land in Mesa before
From: "Zhang, Jerry"
v2: fixes the SOS loading failure for PSP v3.1
Signed-off-by: Junwei Zhang
Cc: sta...@vger.kernel.org
Acked-by: Alex Deucher (v1)
Acked-by: Huang Rui (v1)
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 3 +--
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 2 --
2 files changed
On 07/17/2017 07:45 PM, Huang Rui wrote:
On Mon, Jul 17, 2017 at 06:57:41PM +0800, Greg KH wrote:
On Mon, Jul 17, 2017 at 04:56:26PM +0800, Zhang, Jerry (Junwei) wrote:
> + sta...@vger.kernel.org
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please re
On 2017年07月18日 08:48, Dave Airlie wrote:
From: Dave Airlie
These are just wrappers using the amdgpu device handle.
Signed-off-by: Dave Airlie
Acked-by: Chunming Zhou
---
amdgpu/amdgpu.h| 55 +-
amdgpu/amdgpu_cs.c | 38 +++
On 2017年07月18日 01:35, Christian König wrote:
Am 17.07.2017 um 19:22 schrieb Marek Olšák:
On Sun, Jul 16, 2017 at 11:36 PM, Dave Airlie wrote:
I can take a look at it, I just won't have time until next week
most likely.
I've taken a look, and it's seemingly more complicated than I'm
expectin
Still holding on? I thought this patch was pushed in earlier with my RB.
Regards,
David Zhou
On 2017年07月18日 05:02, Christian König wrote:
From: Christian König
The hardware can use huge pages to map 2MB of address space with only one PDE.
v2: few cleanups and rebased
v3: skip PT updates if we
From: Dave Airlie
This just sends chunks to the kernel API for a single command
stream.
This should provide a more future proof and extensible API
for command submission.
Signed-off-by: Dave Airlie
---
amdgpu/amdgpu.h| 21 +
amdgpu/amdgpu_cs.c | 30
From: Dave Airlie
These are just wrappers using the amdgpu device handle.
Signed-off-by: Dave Airlie
---
amdgpu/amdgpu.h| 55 +-
amdgpu/amdgpu_cs.c | 38 +
2 files changed, 92 insertions(+), 1 deletion(
Am 17.07.2017 um 23:30 schrieb Felix Kuehling:
On 17-07-17 05:02 PM, Christian König wrote:
+ if (p->adev->asic_type < CHIP_VEGA10 ||
+ nptes != AMDGPU_VM_PTE_COUNT(p->adev) ||
+ p->func != amdgpu_vm_do_set_ptes ||
+ !(flags & AMDGPU_PTE_VALID)) {
Because of
On 17-07-17 05:02 PM, Christian König wrote:
> + if (p->adev->asic_type < CHIP_VEGA10 ||
> + nptes != AMDGPU_VM_PTE_COUNT(p->adev) ||
> + p->func != amdgpu_vm_do_set_ptes ||
> + !(flags & AMDGPU_PTE_VALID)) {
Because of this condition, I think this still won't work corr
The minimum BO size is 4K, so that can never happen.
Christian.
Am 17.07.2017 um 23:21 schrieb StDenis, Tom:
In amdgpu_vm_get_entry() if the bo size is less than 8 you'll get a divide by
zero. Are there mechanisms to prevent this? Maybe add a BUG() there?
Tom
___
In amdgpu_vm_get_entry() if the bo size is less than 8 you'll get a divide by
zero. Are there mechanisms to prevent this? Maybe add a BUG() there?
Tom
From: amd-gfx on behalf of Christian
König
Sent: Monday, July 17, 2017 17:02
To: amd-gfx@lists.freed
From: Christian König
The hardware can use huge pages to map 2MB of address space with only one PDE.
v2: few cleanups and rebased
v3: skip PT updates if we are using the PDE
v4: rebased, added support for CPU based updates
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_v
From: Christian König
The fragment bits work differently for Vega10 compared to previous generations.
Increase the fragment size to 2MB for now to better handle that.
v2: handle the hardware setup as well
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 5 +++--
Am 17.07.2017 um 19:22 schrieb Marek Olšák:
On Sun, Jul 16, 2017 at 11:36 PM, Dave Airlie wrote:
I can take a look at it, I just won't have time until next week most likely.
I've taken a look, and it's seemingly more complicated than I'm
expecting I'd want to land in Mesa before 17.2 ships, I'
On Sun, Jul 16, 2017 at 11:36 PM, Dave Airlie wrote:
>>
>> I can take a look at it, I just won't have time until next week most likely.
>
> I've taken a look, and it's seemingly more complicated than I'm
> expecting I'd want to land in Mesa before 17.2 ships, I'd really
> prefer to just push the n
Am 14.07.2017 um 21:44 schrieb Felix Kuehling:
On 17-07-14 06:08 AM, Christian König wrote:
Am 13.07.2017 um 23:08 schrieb Felix Kuehling:
[SNIP]
+result += bytes;
+buf = (uint8_t *)buf + bytes;
+pos += bytes;
+len -= bytes;
+if (pos >= (nodes->start + no
Am 17.07.2017 um 05:36 schrieb Dave Airlie:
I can take a look at it, I just won't have time until next week most likely.
I've taken a look, and it's seemingly more complicated than I'm
expecting I'd want to land in Mesa before 17.2 ships, I'd really
prefer to just push the new libdrm_amdgpu api
On Fri, Jul 14, 2017 at 4:21 AM, Jay Cornwall wrote:
> Dead code.
>
> Change-Id: Ic0bb1bcca87e96bc5e8fa9894727b0de152e8818
> Signed-off-by: Jay Cornwall
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 4
> drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 7 ---
>
On Fri, Jul 14, 2017 at 7:24 PM, Alex Deucher wrote:
> On Thu, Jul 13, 2017 at 9:21 PM, Jay Cornwall wrote:
>> The number of compute queues available to the KFD was erroneously
>> calculated as 64. Only the first MEC can execute compute queues and
>> it has 32 queue slots.
>>
>> This caused the o
On Mon, Jul 17, 2017 at 06:57:41PM +0800, Greg KH wrote:
> On Mon, Jul 17, 2017 at 04:56:26PM +0800, Zhang, Jerry (Junwei) wrote:
> > + sta...@vger.kernel.org
>
>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read:
> https://www.kernel.o
Signed-off-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
b/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
index 2718e86..23106e3 100644
--- a/drivers/gpu/drm/amd/amdgpu/psp_v3_1.c
+++ b/drivers/gpu/drm
From: "Zhang, Jerry"
Signed-off-by: Junwei Zhang
Acked-by: Alex Deucher
Acked-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
inde
On Fri, Jun 02, 2017 at 06:47:07PM +0200, Florian Echtler wrote:
> Regarding the SMC, there's actually only one key that consistently seems to
> have
> a different value whether the display is on or off:
>
> --- blank 2017-05-05 08:40:53.694565045 +0200
> +++ non_blank 2017-05-05 08:40:53.702
+ sta...@vger.kernel.org
On 07/17/2017 03:57 PM, Huang Rui wrote:
On Mon, Jul 17, 2017 at 03:52:10PM +0800, Huang Rui wrote:
On Fri, Jul 14, 2017 at 06:20:17PM +0800, Junwei Zhang wrote:
Signed-off-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 3 +--
1 file changed, 1 inse
On Mon, Jul 17, 2017 at 03:52:10PM +0800, Huang Rui wrote:
> On Fri, Jul 14, 2017 at 06:20:17PM +0800, Junwei Zhang wrote:
> > Signed-off-by: Junwei Zhang
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/
On Fri, Jul 14, 2017 at 06:20:17PM +0800, Junwei Zhang wrote:
> Signed-off-by: Junwei Zhang
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ps
35 matches
Mail list logo
