On Wed, Apr 11, 2018 at 01:03:59PM +0100, Robin Murphy wrote:
> On 10/04/18 21:59, Sinan Kaya wrote:
>> Code is expecing to observe the same number of buffers returned from
>> dma_map_sg() function compared to sg_alloc_table_from_pages(). This
>> doesn't hold true universally especially for systems
On 2018-04-12 06:25 AM, Andrey Grodzovsky wrote:
> On 04/12/2018 12:16 AM, Alex Deucher wrote:
>> On Thu, Apr 12, 2018 at 12:08 AM, Andrey Grodzovsky
>> wrote:
>>> From: Alex Deucher
>>>
>>> Steal 9 MB for vga emulation and fb if vga is enabled, otherwise,
>>> steal enough to cover the current di
On 2018-04-12 01:30 AM, Cyr, Aric wrote:
>> From: Michel Dänzer [mailto:mic...@daenzer.net]
>> Sent: Wednesday, April 11, 2018 05:50
>> On 2018-04-11 08:57 AM, Nicolai Hähnle wrote:
>>> On 10.04.2018 23:45, Cyr, Aric wrote:
How does it work fine today given that all kernel seems to know is
>>>
On Thu, Apr 12, 2018 at 12:25:08PM +0800, Grodzovsky, Andrey wrote:
>
>
> On 04/12/2018 12:16 AM, Alex Deucher wrote:
> > On Thu, Apr 12, 2018 at 12:08 AM, Andrey Grodzovsky
> > wrote:
> >> From: Alex Deucher
> >>
> >> Steal 9 MB for vga emulation and fb if vga is enabled, otherwise,
> >> steal
Am Mittwoch, den 11.04.2018, 20:26 +0200 schrieb Christian König:
> Am 11.04.2018 um 19:11 schrieb Robin Murphy:
> > For dma_map_sg(), DMA API implementations are free to merge consecutive
> > segments into a single DMA mapping if conditions are suitable, thus the
> > resulting DMA addresses may be
Am 12.04.2018 um 11:11 schrieb Lucas Stach:
Am Mittwoch, den 11.04.2018, 20:26 +0200 schrieb Christian König:
Am 11.04.2018 um 19:11 schrieb Robin Murphy:
For dma_map_sg(), DMA API implementations are free to merge consecutive
segments into a single DMA mapping if conditions are suitable, thus
Am 12.04.2018 um 08:26 schrieb Christoph Hellwig:
On Wed, Apr 11, 2018 at 01:03:59PM +0100, Robin Murphy wrote:
On 10/04/18 21:59, Sinan Kaya wrote:
Code is expecing to observe the same number of buffers returned from
dma_map_sg() function compared to sg_alloc_table_from_pages(). This
doesn't h
Am Donnerstag, den 12.04.2018, 11:35 +0200 schrieb Christian König:
> Am 12.04.2018 um 11:11 schrieb Lucas Stach:
> > Am Mittwoch, den 11.04.2018, 20:26 +0200 schrieb Christian König:
> > > Am 11.04.2018 um 19:11 schrieb Robin Murphy:
> > > > For dma_map_sg(), DMA API implementations are free to me
Change-Id: I34924a40392653e72f143c30ab312cbbf9fa
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/ttm/ttm_bo.c| 23 +++
include/drm/ttm/ttm_bo_api.h| 1 +
include/drm/ttm/ttm_bo_driver.h | 10 ++
3 files changed, 34 insertions(+)
diff --git a/drivers/gpu/
Since per-process-bo feature is introduced, old lru isn't working for it.
old lru order is depending on BO list order, which will be updated by bo
list after every command submission.
But for per-process-bo, which aren't in bo list, so it have no chance to
refresh its order in lru. Which also will
Change-Id: I2cf802e641d8b2cdb2bf8bdf1957f3f4f27afaba
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/a
Change-Id: Ie43f3c73cc65526a449208f3ce927b1dfad5cf6b
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amd
Change-Id: I4de8146567b858ae07a8a27cadf71d13d490e8ac
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 7 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +++-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
Change-Id: Id2333f69119222a7e9bdb0357bbed97cf08636da
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/ttm/ttm_bo.c| 59 ++---
include/drm/ttm/ttm_bo_driver.h | 3 ++-
2 files changed, 52 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_
Change-Id: I0f533c6512f3b72fcf2fbf11d738f38d9e087f26
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/ttm/ttm_bo.c| 39 +++
include/drm/ttm/ttm_bo_api.h| 3 ++-
include/drm/ttm/ttm_bo_driver.h | 2 +-
3 files changed, 34 insertions(+), 10 deletions(-)
Change-Id: Ifb0dc95db6a358cf7f76e2a99f94c58637ad6ee6
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 17 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 170 ++
Change-Id: I4abf5cf0aaf946162dabd08fc1fd0406c2abf418
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/ttm/ttm_bo.c| 1 +
include/drm/ttm/ttm_bo_driver.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 73343d1108d2..d56312
Change-Id: I877b2d5c54b3e47b66f2d58454dcf1e5f5a68972
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 7bb6ee777067..d54ab
Change-Id: Ib68bff91fd127162cf8c72516101546e1fe014df
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 1 -
drivers/gpu/drm/ttm/ttm_bo.c | 39 --
2 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm
Change-Id: I5b6afbdd715e28e5266b5099ca9a34399d1fc3a1
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/ttm/ttm_bo.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index dc9545eeb5d6..d6e7c835f4c1 100644
--- a
issue:
there are VMC page fault occurred if force APP kill during
3dmark test, the cause is in entity_fini we manually signal
all those jobs in entity's queue which confuse the sync/dep
mechanism:
1)page fault occurred in sdma's clear job which operate on
shadow buffer, and shadow buffer's Gart ta
On 2018-04-11 11:26 PM, Leo Li wrote:
> On 2018-04-11 04:39 AM, Michel Dänzer wrote:
>>
>> Hmm. So either legacy or non-legacy clients won't work at all, or
>> they'll step on each other's toes, clobbering the HW gamma LUT from
>> each other.
>>
>> I'm afraid neither of those alternatives sound
Am 12.04.2018 um 11:49 schrieb Lucas Stach:
Am Donnerstag, den 12.04.2018, 11:35 +0200 schrieb Christian König:
Am 12.04.2018 um 11:11 schrieb Lucas Stach:
Am Mittwoch, den 11.04.2018, 20:26 +0200 schrieb Christian König:
Am 11.04.2018 um 19:11 schrieb Robin Murphy:
For dma_map_sg(), DMA API
On 04/12/2018 12:32 AM, Alex Deucher wrote:
On Thu, Apr 12, 2018 at 12:08 AM, Andrey Grodzovsky
wrote:
Reserved VRAM is used to avoid overriding pre OS FB.
Once our display stack takes over we don't need the reserved
VRAM anymore.
v2:
Remove comment, we know actually why we need to reserve t
On 12.04.2018 01:30, Cyr, Aric wrote:
At least with VDPAU, video players are already explicitly specifying the
target presentation time, so no changes should be required at that
level. Don't know about other video APIs.
The X11 Present extension protocol is also prepared for specifying the
targe
On 2018-04-12 06:33, Christian König wrote:
Am 12.04.2018 um 11:49 schrieb Lucas Stach:
Am Donnerstag, den 12.04.2018, 11:35 +0200 schrieb Christian König:
Am 12.04.2018 um 11:11 schrieb Lucas Stach:
Am Mittwoch, den 11.04.2018, 20:26 +0200 schrieb Christian König:
Am 11.04.2018 um 19:11 schr
On Thu, Apr 12, 2018 at 7:17 AM, Andrey Grodzovsky
wrote:
>
>
> On 04/12/2018 12:32 AM, Alex Deucher wrote:
>>
>> On Thu, Apr 12, 2018 at 12:08 AM, Andrey Grodzovsky
>> wrote:
>>>
>>> Reserved VRAM is used to avoid overriding pre OS FB.
>>> Once our display stack takes over we don't need the rese
On 12/04/18 10:42, Christian König wrote:
Am 12.04.2018 um 08:26 schrieb Christoph Hellwig:
On Wed, Apr 11, 2018 at 01:03:59PM +0100, Robin Murphy wrote:
On 10/04/18 21:59, Sinan Kaya wrote:
Code is expecing to observe the same number of buffers returned from
dma_map_sg() function compared to
On 12/04/18 11:33, Christian König wrote:
Am 12.04.2018 um 11:49 schrieb Lucas Stach:
Am Donnerstag, den 12.04.2018, 11:35 +0200 schrieb Christian König:
Am 12.04.2018 um 11:11 schrieb Lucas Stach:
Am Mittwoch, den 11.04.2018, 20:26 +0200 schrieb Christian König:
Am 11.04.2018 um 19:11 schrie
On 2018-04-12 03:33 PM, Alex Deucher wrote:
> On Thu, Apr 12, 2018 at 7:17 AM, Andrey Grodzovsky
> wrote:
>> On 04/12/2018 12:32 AM, Alex Deucher wrote:
>>>
>>> On Thu, Apr 12, 2018 at 12:08 AM, Andrey Grodzovsky
>>> wrote:
Reserved VRAM is used to avoid overriding pre OS FB.
Once
This reverts commit cd2d6c92a8e39d7e50a5af9fcc67d07e6a89e91d.
Cc: Shirish S
Cc: Alex Deucher
Cc: sta...@vger.kernel.org
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_d
This seems to cause flickering and lock-ups for a wide range of users.
Revert until we've found a proper fix for the flickering and lock-ups.
This reverts commit 36cc549d59864b7161f0e23d710c1c4d1b9cf022.
Cc: Shirish S
Cc: Alex Deucher
Cc: sta...@vger.kernel.org
Signed-off-by: Harry Wentland
--
On 2018-04-12 01:39 PM, Nicolai Hähnle wrote:
> On 12.04.2018 01:30, Cyr, Aric wrote:
>>> At least with VDPAU, video players are already explicitly specifying the
>>> target presentation time, so no changes should be required at that
>>> level. Don't know about other video APIs.
>>>
>>> The X11 Pre
On 04/12/2018 10:33 AM, Michel Dänzer wrote:
On 2018-04-12 03:33 PM, Alex Deucher wrote:
On Thu, Apr 12, 2018 at 7:17 AM, Andrey Grodzovsky
wrote:
On 04/12/2018 12:32 AM, Alex Deucher wrote:
On Thu, Apr 12, 2018 at 12:08 AM, Andrey Grodzovsky
wrote:
Reserved VRAM is used to avoid overridi
On 2018-04-12 04:51 PM, Harry Wentland wrote:
> This seems to cause flickering and lock-ups for a wide range of users.
> Revert until we've found a proper fix for the flickering and lock-ups.
>
> This reverts commit 36cc549d59864b7161f0e23d710c1c4d1b9cf022.
>
> Cc: Shirish S
> Cc: Alex Deucher
On 2018-04-12 04:58 PM, Andrey Grodzovsky wrote:
> On 04/12/2018 10:33 AM, Michel Dänzer wrote:
>> On 2018-04-12 03:33 PM, Alex Deucher wrote:
>>> On Thu, Apr 12, 2018 at 7:17 AM, Andrey Grodzovsky
>>> wrote:
On 04/12/2018 12:32 AM, Alex Deucher wrote:
> On Thu, Apr 12, 2018 at 12:08 AM,
Can you be more specific, Christian? Mesa has this, I don't think it needs
anything else:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=7d2079908d9ef05ec3f35b7078833e57846cab5b
Marek
On Wed, Mar 28, 2018 at 3:46 AM, Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Am 28.03.2018 u
On 2018-04-12 06:30 AM, Michel Dänzer wrote:
On 2018-04-11 11:26 PM, Leo Li wrote:
On 2018-04-11 04:39 AM, Michel Dänzer wrote:
Hmm. So either legacy or non-legacy clients won't work at all, or
they'll step on each other's toes, clobbering the HW gamma LUT from
each other.
I'm afraid neithe
Can you be more specific, Christian? Mesa has this, I don't think it
needs anything else:
Completely agree, that's what I suggested to implement.
The point is this kernel change now needs to be reworked and adapted to
what Mesa is doing.
Regards,
Christian.
Am 12.04.2018 um 18:40 schrieb Mar
> The point is this kernel change now needs to be reworked and adapted to what
> Mesa is doing.
Three options have been brought up for kernel,
1) Turn off immediate mode when flipping between VRAM/GTT.
2) Check the domain of the current fb and then adjust the new one before
pinning it.
3) Use onl
On 2018-04-12 07:39 AM, Nicolai Hähnle wrote:
> On 12.04.2018 01:30, Cyr, Aric wrote:
>>> At least with VDPAU, video players are already explicitly specifying the
>>> target presentation time, so no changes should be required at that
>>> level. Don't know about other video APIs.
>>>
>>> The X11 Pre
On 11/04/18 19:28, Christian König wrote:
Am 11.04.2018 um 19:11 schrieb Robin Murphy:
Now that drm_prime_sg_to_page_addr_arrays() understands the case where
dma_map_sg() has coalesced segments and returns 0 < count < nents, we
can relax the check to only consider genuine failure.
That pattern
1) Turn off immediate mode when flipping between VRAM/GTT.
That must be implemented independently.
See working around the hardware bug should be a different patch than
implementing a placement policy.
As per discussion, the 3rd one, which is the current patch, seems the best so
far.
And I c
Please clarify, Christian. How would you like it to be implemented?
Sam
On 2018-04-12 02:00 PM, Christian König wrote:
>> 1) Turn off immediate mode when flipping between VRAM/GTT.
> That must be implemented independently.
>
> See working around the hardware bug should be a different patch than
Patch #1: Avoid the hardware bug!
E.g. even when we avoid different placements it would be good to have a
patch which turns off immediate flipping when switching from VRAM to GTT.
That is as safety net and to document that we need to avoid this
condition on the hardware.
Patch #2: Go into a
Am 12.04.2018 um 19:53 schrieb Robin Murphy:
On 11/04/18 19:28, Christian König wrote:
Am 11.04.2018 um 19:11 schrieb Robin Murphy:
Now that drm_prime_sg_to_page_addr_arrays() understands the case where
dma_map_sg() has coalesced segments and returns 0 < count < nents, we
can relax the check to
In function ‘radeon_process_i2c_ch’ a comparison of a u8 value against
255 is done. Since it is always false, change the signature of this
function to use an `int` instead, which match the type used in caller:
`radeon_atom_hw_i2c_xfer`.
Fix the following warning triggered with W=1:
CC [M] driv
On 04/12/2018 11:10 AM, Michel Dänzer wrote:
On 2018-04-12 04:58 PM, Andrey Grodzovsky wrote:
On 04/12/2018 10:33 AM, Michel Dänzer wrote:
On 2018-04-12 03:33 PM, Alex Deucher wrote:
On Thu, Apr 12, 2018 at 7:17 AM, Andrey Grodzovsky
wrote:
On 04/12/2018 12:32 AM, Alex Deucher wrote:
On T
The 4th proposal :)
> In other words add something like the following:
>
> if (domain & AMDGPU_GEM_DOMAIN_GTT && bo->preferred_domains &
> AMDGPU_GEM_DOMAIN_GTT)
> domain = AMDGPU_GEM_DOMAIN_GTT;
>
> That should be everything we need here.
This is basically against the idea of Marek's chan
Am 12.04.2018 um 22:01 schrieb Samuel Li:
The 4th proposal :)
In other words add something like the following:
if (domain & AMDGPU_GEM_DOMAIN_GTT && bo->preferred_domains &
AMDGPU_GEM_DOMAIN_GTT)
domain = AMDGPU_GEM_DOMAIN_GTT;
That should be everything we need here.
This is basically
Hi Dave,
More fixes for 4.17 and stable:
- Add a PX quirk for radeon
- Fix flickering and stability issues with DC on some platforms
- Fix HDMI audio regression
- Few other misc DC and base driver fixes
The following changes since commit 871e899db19da3dbd17a5d263b555dc5b7d8fed5:
Merge branch '
Hi Christian,
If you have any good proposal, please describe here.
Otherwise kindly avoid saying anything based on your emotion.
Regards,
Sam
On 2018-04-12 04:13 PM, Christian König wrote:
> Am 12.04.2018 um 22:01 schrieb Samuel Li:
>> The 4th proposal :)
>>
>>> In other words add something li
On Tue, Apr 10, 2018 at 12:37 AM, Michel Dänzer wrote:
> On 2018-04-10 08:45 AM, Christian König wrote:
>> Am 09.04.2018 um 23:45 schrieb Manasi Navare:
>>> Thanks for initiating the discussion. Find my comments below:
>>> On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
On 201
Hi Sam,
yeah sorry for that. It's already rather late here and I got a bit taken
away.
But I still insist that you at least try as I advised, I'm pretty sure
that this approach will work and cover all use cases discussed so far.
Regards,
Christian.
Am 12.04.2018 um 22:42 schrieb Samuel Li:
Ping
Best Wishes,
Emily Deng
> -Original Message-
> From: Emily Deng [mailto:emily.d...@amd.com]
> Sent: Thursday, April 12, 2018 6:22 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deng, Emily ; Liu, Monk
> Subject: [PATCH] drm/gpu-sched: fix force APP kill hang(v3)
>
> issue:
> t
Hi Harry, Alex,
The solution given while reviewing my patch was that "DC should support
enabling a CRTC without a framebuffer."
Since the revert is a temporary workaround to address issue at hand and
considering the bigger regression it will cause on ChromeOS(explained below),
I would strongly
amdgpu_ib_ring_tests() runs test IB's on rings at boot
contributes to ~500 ms of amdgpu driver's boot time.
This patch defers it and adds a check to report
in amdgpu_info_ioctl() if it was scheduled or not.
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 ++
drivers
Hi Christian & Emily
This v3 version looks pretty good to me, but still some parts need to
improve:
e.g.
1)entity->finished doesn't presenting what it really means, better
rename it to entity->last_scheduled.
2)drm_sched_entity_fini_job_cb() better renamed to
drm_sched_entity_kill_jobs_cb
Den tis 10 apr. 2018 23:11Harry Wentland skrev:
> From: Anthony Koo
>
> Signed-off-by: Anthony Koo
> Reviewed-by: Aric Cyr
> Acked-by: Harry Wentland
> ---
> drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff
Hi Monk,
Thanks your review, I will refine the code as your suggestion 1),2),3),
4),5).
About 6): I think it is no relation to put the amdgpu_ctx_mgr_fini before
or after amdgpu_vm_fini.
Hi Christian,
Do you have any thoughts about 6)?
Best Wishes,
Emily Deng
> -Original Me
Hi Monk,
Another consideration, it will be better to put amdgpu_ctx_mgr_fini()
beneath amdgpu_vm_fini, in
this case, it will first set all ctx and vm entity rq to null, then set all the
not scheduled job's fence to signal.
Best Wishes,
Emily Deng
> -Original Message-
> From: amd-gf
Am 13.04.2018 um 06:07 schrieb Shirish S:
amdgpu_ib_ring_tests() runs test IB's on rings at boot
contributes to ~500 ms of amdgpu driver's boot time.
This patch defers it and adds a check to report
in amdgpu_info_ioctl() if it was scheduled or not.
That is rather suboptimal, but see below.
Hi Monk/Emily,
give me the weekend to take a closer look since I'm very busy this morning.
In general the order of ctx_fini and vm fini is very important cause we
otherwise dereference invalid pointers here.
Regards,
Christian.
Am 13.04.2018 um 08:18 schrieb Deng, Emily:
Hi Monk,
Anoth
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c | 56 ++
drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.h | 21
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 43 +
3 files changed, 78 insertions(+), 42 deletions(-
On 4/13/2018 11:53 AM, Christian König wrote:
Am 13.04.2018 um 06:07 schrieb Shirish S:
amdgpu_ib_ring_tests() runs test IB's on rings at boot
contributes to ~500 ms of amdgpu driver's boot time.
This patch defers it and adds a check to report
in amdgpu_info_ioctl() if it was scheduled or not
65 matches
Mail list logo