Reviewed-by: Andrey Grodzovsky
Andrey
On 02/05/2018 04:14 PM, mikita.lip...@amd.com wrote:
From: Mikita Lipski
amdgpu_dm_display_resume is now called from dm_resume to
unify DAL resume call into a single function call
There is no more need to separately call 2 resume functions
for DM.
Init
On 2018-02-05 04:14 PM, mikita.lip...@amd.com wrote:
> From: Mikita Lipski
>
> amdgpu_dm_display_resume is now called from dm_resume to
> unify DAL resume call into a single function call
>
> There is no more need to separately call 2 resume functions
> for DM.
>
> Initially they were separated
From: Mikita Lipski
amdgpu_dm_display_resume is now called from dm_resume to
unify DAL resume call into a single function call
There is no more need to separately call 2 resume functions
for DM.
Initially they were separated to resume display state after
cursor is pinned. But because there is n
Signed-off-by: Tom St Denis
---
src/lib/ring_decode.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/lib/ring_decode.c b/src/lib/ring_decode.c
index f87d43e077a2..b18948d26b5f 100644
--- a/src/lib/ring_decode.c
+++ b/src/lib/ring_decode.c
@@ -1331,6 +1331,8 @@ static void print_decode_
Looks good to me on first glance.
You probably don't mind that I'm going to pull a good part of that into
amdgpu as next step?
Regards,
Christian.
Am 03.02.2018 um 03:29 schrieb Felix Kuehling:
The attached patch is my attempt to keep most of the IOMMU code in one
place (new kfd_iommu.c) to
-Original Message-
From: Alex Deucher [mailto:alexdeuc...@gmail.com]
Sent: Monday, February 05, 2018 12:53 PM
To: Bridgman, John
Cc: Koenig, Christian; Liu, Shaoyun; amd-gfx list
Subject: Re: [PATCH] drm/amdgpu: Basic emulation support
On Mon, Feb 5, 2018 at 12:34 PM, Bridgman, John wrot
On Mon, Feb 5, 2018 at 12:34 PM, Bridgman, John wrote:
>
>
>>-Original Message-
>>From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
>>Christian König
>>Sent: Monday, February 05, 2018 11:49 AM
>>To: Alex Deucher; Liu, Shaoyun
>>Cc: amd-gfx list
>>Subject: Re: [PATCH
>-Original Message-
>From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Christian König
>Sent: Monday, February 05, 2018 11:49 AM
>To: Alex Deucher; Liu, Shaoyun
>Cc: amd-gfx list
>Subject: Re: [PATCH] drm/amdgpu: Basic emulation support
>
>Am 05.02.2018 um 17:45 s
Am 05.02.2018 um 17:45 schrieb Alex Deucher:
On Thu, Feb 1, 2018 at 6:16 PM, Shaoyun Liu wrote:
Add amdgpu_emu_mode module parameter to control the emulation mode
Avoid vbios operation on emulation since there is no vbios post duirng
emulation,
use the common hw_init to simulate the post
Chan
On Thu, Feb 1, 2018 at 6:16 PM, Shaoyun Liu wrote:
> Add amdgpu_emu_mode module parameter to control the emulation mode
> Avoid vbios operation on emulation since there is no vbios post duirng
> emulation,
> use the common hw_init to simulate the post
>
> Change-Id: Iba32fa16e735490e7401e47121979
Reviewed-by: Felix Kuehling
On 2018-02-05 07:28 AM, Christian König wrote:
> Otherwise we might overwrite stuff which is still in use.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm
Attached is a patch for umr{master} which should in theory support both
iova and iomem.
I can add the write method if you want since ya it should be fairly
simple to copy/pasta that up.
Cheers,
Tom
On 05/02/18 07:07 AM, Christian König wrote:
Well adding write support is trivial.
What I'm
Hi everyone,
I have some updates. I left the system idle most of the time during
the weekend and from time to time I played a video on youtube and
turned off the screen. Yesterday night I did the same and today
morning I checked the system and it got hung up during the night. This
time it took a l
Otherwise we might overwrite stuff which is still in use.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 18ce47608bf1..0572d6
Am 05.02.2018 um 09:22 schrieb Chunming Zhou:
On 2018年01月31日 18:54, Christian König wrote:
So I think preventing validation on same place is a simpler way:
process B bo's place is fpfn~lpfn, it will only try to evict LRU BOs
in that range, while eviction, we just prevent those validation to
th
Well adding write support is trivial.
What I'm more concerned about is if setting page->mapping during
allocation of the page could have any negative effect?
I of hand don't see any since the page isn't reclaimable directly
anyway, but I'm not 100% sure of that.
Christian.
Am 05.02.2018 um
Another thing that occurred to me is this will break write access to GPU
bound memory. Previously we relied on iova to translate the address and
then /dev/mem or /dev/fmem to read/write it. But since this is
literally a read only method obviously there's no write support.
Tom
On 04/02/18 0
On 2018年01月31日 18:54, Christian König wrote:
So I think preventing validation on same place is a simpler way:
process B bo's place is fpfn~lpfn, it will only try to evict LRU BOs
in that range, while eviction, we just prevent those validation to
this range(fpfn~lpfn), if out of this range, th
18 matches
Mail list logo
