+Monk.
Moving push_job out of reservation lock indeed not a good idea.
Hi Monk,
How about Christian's revert?
Regards,
David Zhou
On 2017年09月05日 21:14, Christian König wrote:
From: Christian König
This reverts commit 10e709cb296c98424c03408d23e3addeddcd4088.
The patch doesn't work at all:
Yes.
Best Regards
Rex
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Tom
St Denis
Sent: Wednesday, September 06, 2017 12:23 AM
To: amd-gfx@lists.freedesktop.org
Subject: Re: unclear code in vega10 pp
After seeing this style a few other place
Thanks Tom.
Patch is Reviewed-By: Rex Zhu
Best Regards
Rex
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Tom
St Denis
Sent: Tuesday, September 05, 2017 8:03 PM
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: [PATCH] drm/amd/pow
On 2017-09-01 05:40 PM, Daniel Vetter wrote:
> On Fri, Sep 1, 2017 at 8:50 PM, Harry Wentland wrote:
>> This is no longer needed in 4.13
>>
>> Signed-off-by: Harry Wentland
>> ---
>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 12
>> +---
>> 1 file changed, 1 insertion
I believe this can lead to lock warnings when multiple MMU notifier
pairs are happening at the same time. They're probably harmless, because
read locks are not exclusive. Below is an example I got during process
termination of an HSA process.
Is there some kind of lock annotation that can prevent
I found another problem as I was looking at adapting KFD's userptr code.
On 2017-09-05 11:37 AM, Christian König wrote:
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -622,6 +622,8 @@ int amdgpu_ttm_tt_get_user_pages(struct ttm_tt *ttm,
> str
Reviewed-by: Felix Kuehling
On 2017-09-02 07:22 AM, Christian König wrote:
> From: Christian König
>
> Move calling put_page into the unpopulate callback. Otherwise we mess up the
> pages
> reference count when it is unbound multiple times.
>
> Signed-off-by: Christian König
> ---
> drivers/
I made one comment on patch 5. Other than that, this series is
Reviewed-by: Felix Kuehling
This is the second week I'll get very little productive work done,
because I'm busy debugging memory manager changes and patching KFD to
keep it working. This series will require some changes to userptr
han
On 2017-09-05 11:37 AM, Christian König wrote:
> +struct amdgpu_mn *amdgpu_mn_get(struct amdgpu_device *adev) { return NULL; }
> static inline int amdgpu_mn_register(struct amdgpu_bo *bo, unsigned long
> addr)
> {
> return -ENODEV;
> }
> static inline void amdgpu_mn_unregister(struct amd
On Tue, Sep 5, 2017 at 6:48 PM, Felix Kuehling wrote:
> Acked-by: Felix Kuehling
>
> But isn't that a bug in the SPARC kernel headers? Shouldn't they handle
> that dependency rather than putting the responsibility on unsuspecting
> users of mmu_context.h? I sent a question about this to Pavel Tat
Looks like Oded is fixing it by adding #include before
including mmu_context.h. But I still think this is a bug in the SPARC
headers. The header file that depends on percpu.h should include it.
Regards,
Felix
On 2017-09-02 08:13 PM, kbuild test robot wrote:
> Hi Felix,
>
> FYI, the error/warn
After seeing this style a few other places in the same file are they
just padding out the rest of the array with the highest setting?
Tom
On 05/09/17 12:18 PM, Tom St Denis wrote:
In vega10_populate_smc_link_levels(): there's this bit
j = i - 1;
while (i < NUM_LINK_LEVELS) {
In vega10_populate_smc_link_levels(): there's this bit
j = i - 1;
while (i < NUM_LINK_LEVELS) {
pp_table->PcieGenSpeed[i] = pcie_table->pcie_gen[j];
pp_table->PcieLaneCount[i] = pcie_table->pcie_lane[j];
result = vega10_populate_sin
Acked-by: Felix Kuehling
But isn't that a bug in the SPARC kernel headers? Shouldn't they handle
that dependency rather than putting the responsibility on unsuspecting
users of mmu_context.h? I sent a question about this to Pavel Tatashin
on Aug 22, but haven't heard back from him.
Regards,
Fe
On 2017-09-03 07:54 AM, Oded Gabbay wrote:
> Don't you need to allocate PASID on all possible devices ?
> If so, does it need to be the same on all devices ?
The PASID allocator is global (not per-device), so the PASID is intended
to be the same for all devices. I only need to find a device for th
From: Christian König
This is quite controversial because it adds another lock which is held during
page table updates, but I don't see much other option.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 19 +++
1 file changed, 19 insertions(+)
diff
From: Christian König
Instead use a counter to figure out if we need to set new pages or not.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 11 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 ++
From: Christian König
This didn't helped as intended, just simplify the code.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 12 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4
3 files changed, 5 i
From: Christian König
Instead of moving them in the MMU notifier move them during CS.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 5 -
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/g
From: Christian König
Instead take the callback lock during the final parts of CS.
This should solve the last remaining locking order problems with BO
reservations.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 8
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
From: Christian König
Allow at least some parallel processing.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
b/drivers/gpu/drm/am
On 2017-09-02 03:52 AM, Christian König wrote:
> Ah, crap yeah that won't work.
>
> Yeah, we should block userptr BOs in amdgpu_ttm_bind() for now.
>
>> There is something else still broken in our IPC test for system memory
>> also, but I'll have to rewrite that anyway to work for large BOs with a
From: Christian König
This reverts commit 10e709cb296c98424c03408d23e3addeddcd4088.
The patch doesn't work at all:
1. The CS can still be blocked because of amdgpu_ctx_add_fence().
2. The order of submission isn't correct any more.
3. We could end up using freed up memory because we now drop the
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Rex Zhu
> Sent: Monday, September 04, 2017 9:29 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex
> Subject: [PATCH 4/4] drm/amd/powerplay: delete dead code in powerplay
>
> delete functi
Am 05.09.2017 um 13:32 schrieb Tom St Denis:
Fixed kbuild errors when IOMMU/SWIOTLB are disabled.
Signed-off-by: Tom St Denis
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
We now pass a pointer to a pointer which seems to be
what they meant in the first place. The previous version
was modifying a pointer passed by value.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c | 4 ++--
drivers/gpu/drm/amd/powerplay/hwmgr/pp_psm.c | 8
Fixed kbuild errors when IOMMU/SWIOTLB are disabled.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 6a660d196d87..052e1f102113 100644
---
On Tue, Sep 05, 2017 at 09:29:26AM +0800, Rex Zhu wrote:
> 1. add function points instand of creat function tables
> 2. implement stop dpm tasks for CZ/ST
better to split to 2 patches.
>
> Change-Id: Ibe6fc92b989ba125da34857ce8b056e8b699b41b
> Signed-off-by: Rex Zhu
> ---
> .../drm/amd/powerpla
28 matches
Mail list logo
