Ultimately once they are reviewed they end up here:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next
and then from their they go upstream.
Alex
On Fri, Jul 20, 2018 at 4:20 PM, Eric Merth wrote:
> Sorry, new to this development process.
>
>
> Are these patches posted to a GI
Sorry, new to this development process.
Are these patches posted to a GIT repo? If so what is the URL for the repo?
Thanks for helping!
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Nayan Deshmukh writes:
> The scheduler of the entity is decided by the run queue on which
> it is queued. This patch avoids us the effort required to maintain
> a sync between rq and sched field when we start shifting entites
> among different rqs.
Reviewed-by: Eric Anholt
signature.asc
Descr
Nayan Deshmukh writes:
> entity has a scheduler field and we don't need the sched argument
> in any of the functions where entity is provided.
>
> Signed-off-by: Nayan Deshmukh
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 13 +-
Am 20.07.2018 um 18:31 schrieb Andrey Grodzovsky:
Shouldn't you send this to dri-devel as well ?
Well, I've did Just as two separate mails because of hitting enter to
fast :)
Christian.
Andrey
On 07/19/2018 05:10 AM, Christian König wrote:
Roger unfortunately doesn't work for AMD any l
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Michel Dänzer
> Sent: Friday, July 20, 2018 12:33 PM
> To: amd-gfx@lists.freedesktop.org
> Subject: [PATCH] drm/amdgpu: Fix RLC safe mode test in
> gfx_v9_0_enter_rlc_safe_mode
>
> From: Mich
From: Michel Dänzer
We were testing the register offset, instead of the value stored in the
register, therefore always timing out the loop.
This reduces suspend time of the system in the bug report below by ~600
ms.
Bugzilla: https://bugs.freedesktop.org/107277
Tested-by: Paul Menzel
Signed-of
Shouldn't you send this to dri-devel as well ?
Andrey
On 07/19/2018 05:10 AM, Christian König wrote:
Roger unfortunately doesn't work for AMD any longer. So add Rui and
Jerry as co-maintainer as well.
Signed-off-by: Christian König
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+),
Am 20.07.2018 um 17:47 schrieb Andrey Grodzovsky:
Problem:
amdgpu_ttm_set_buffer_funcs_status destroys adev->mman.entity on suspend
without releasing adev->mman.bdev.man[TTM_PL_VRAM].move fence
so on resume the new drm_sched_entity.fence_context causes
the warning against the old fence context wh
Problem:
amdgpu_ttm_set_buffer_funcs_status destroys adev->mman.entity on suspend
without releasing adev->mman.bdev.man[TTM_PL_VRAM].move fence
so on resume the new drm_sched_entity.fence_context causes
the warning against the old fence context which is different.
Fix:
When destroying sched_entity
On 2018-07-20 08:30 AM, Shirish S wrote:
> This patch removes the usage of console_(un)lock
> by replacing drm_fb_helper_set_suspend() to
> drm_fb_helper_set_suspend_unlocked() which locks and
> unlocks the console instead of locking ourselves.
>
> Signed-off-by: Shirish S
Reviewed-by: Harry Wen
On 2018-07-20 10:17 AM, Nicholas Kazlauskas wrote:
> [Why]
>
> New GCC warnings for stringop-truncation and stringop-overflow help
> catch common misuse of strncpy. This patch suppresses these warnings
> by fixing bugs identified by them.
>
> [How]
>
> Since the parameter passed for name in amdp
We just check that as a way see whether we are using AZ audio (and gpu driver
should control ACP power) or i2s audio (and acp driver controls power). In the
former case, there is no structure allocated.
Alex
From: amd-gfx on behalf of Zhu, Rex
Sent: Friday,
Am 20.07.2018 um 14:21 schrieb Nayan Deshmukh:
entity has a scheduler field and we don't need the sched argument
in any of the functions where entity is provided.
Signed-off-by: Nayan Deshmukh
Reviewed-by: Christian König for the series.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 2
[Why]
New GCC warnings for stringop-truncation and stringop-overflow help
catch common misuse of strncpy. This patch suppresses these warnings
by fixing bugs identified by them.
[How]
Since the parameter passed for name in amdpgu_dm_create_common_mode has
no fixed length, if the string is >= DRM
On Fri, Jul 20, 2018 at 6:25 AM, Rex Zhu wrote:
> Only delete the dead temp variables in Polaris.
>
> Signed-off-by: Rex Zhu
Reviewed-by: Alex Deucher
> ---
> .../drm/amd/powerplay/smumgr/polaris10_smumgr.c| 22
> ++
> 1 file changed, 6 insertions(+), 16 deletions(-)
On Fri, Jul 20, 2018 at 4:36 AM, Rex Zhu wrote:
> DIDTConfig_Polaris12[] table missed a big chunk of data.
>
> Pointed by aidan.fabius
>
> Signed-off-by: Rex Zhu
Reviewed-by: Alex Deucher
> ---
> .../gpu/drm/amd/powerplay/hwmgr/smu7_powertune.c | 43
> ++
> 1 file chan
On 2018-07-20 02:30 PM, Shirish S wrote:
> This patch removes the usage of console_(un)lock
> by replacing drm_fb_helper_set_suspend() to
> drm_fb_helper_set_suspend_unlocked() which locks and
> unlocks the console instead of locking ourselves.
>
> Signed-off-by: Shirish S
> ---
> drivers/gpu/dr
On 07/19/2018 02:30 PM, Alex Deucher wrote:
On Thu, Jul 19, 2018 at 1:07 PM, Andrey Grodzovsky
wrote:
On 07/19/2018 12:59 PM, Michel Dänzer wrote:
On 2018-07-19 06:53 PM, Andrey Grodzovsky wrote:
On 07/19/2018 12:47 PM, Michel Dänzer wrote:
On 2018-07-19 06:33 PM, Andrey Grodzovsky wrote
This patch removes the usage of console_(un)lock
by replacing drm_fb_helper_set_suspend() to
drm_fb_helper_set_suspend_unlocked() which locks and
unlocks the console instead of locking ourselves.
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++--
drivers/gpu/dr
The scheduler of the entity is decided by the run queue on which
it is queued. This patch avoids us the effort required to maintain
a sync between rq and sched field when we start shifting entites
among different rqs.
Signed-off-by: Nayan Deshmukh
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c|
entity has a scheduler field and we don't need the sched argument
in any of the functions where entity is provided.
Signed-off-by: Nayan Deshmukh
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 13 +
drivers/gpu/drm/amd/amdgpu/amdgpu
Hi Alex,
I am Ok with the patch in v2.
just one question,
+if (!adev->acp.acp_cell)
+amdgpu_dpm_set_powergating_by_smu(adev, AMD_IP_BLOCK_TYPE_ACP, true);
Do we need to check adev->acp.acp_cell before poweron/off ACP?
Best Regards
Rex
From:
Only delete the dead temp variables in Polaris.
Signed-off-by: Rex Zhu
---
.../drm/amd/powerplay/smumgr/polaris10_smumgr.c| 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c
b/drivers/gpu/drm/amd
Hi Evan，
Changing the title to "Only allow slow switch if NB pstate switch is enabled"
can make patch more
understandable.
Best Regards
Rex
From: amd-gfx on behalf of Zhu, Rex
Sent: Friday, July 20, 2018 4:43 PM
To: Quan, Evan; amd-gfx@lists.freedeskt
Reviewed-by: Rex Zhumailto:re...@amd.com>>
Regards
Rex
From: amd-gfx on behalf of Evan Quan
Sent: Friday, July 20, 2018 10:35 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan; Zhu, Rex
Subject: [PATCH 1/3] drm/amd/powerplay: slow UCLK switch when multiple d
+ bool uclk_switching_disabled =
+(bool)hwmgr->display_config->nb_pstate_switch_disable;
Don't need type convert.
Best Regards
Rex
From: amd-gfx on behalf of Evan Quan
Sent: Friday, July 20, 2018 10:35 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, E
DIDTConfig_Polaris12[] table missed a big chunk of data.
Pointed by aidan.fabius
Signed-off-by: Rex Zhu
---
.../gpu/drm/amd/powerplay/hwmgr/smu7_powertune.c | 43 ++
1 file changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_powertune.c
b/dri
On 2018-07-20 09:58 AM, S, Shirish wrote:
> Sure Michel, but not immediately.
> Is that fine?
Sure, thanks.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
__
Sure Michel, but not immediately.
Is that fine?
Regards,
Shirish S
-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net]
Sent: Friday, July 20, 2018 1:04 PM
To: S, Shirish
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: lock and unlock console only for
am
On 2018-07-19 11:20 AM, Michel Dänzer wrote:
>
> Possible follow-up work:
>
> * Move the console_(un)lock calls into amdgpu_fbdev_set_suspend, or
> maybe use drm_fb_helper_set_suspend_unlocked instead of locking ourselves
>
> * Move the amdgpu_fbdev_set_suspend call in amdgpu_device_suspend
> fu
31 matches
Mail list logo
