On Wed, Jul 18, 2018 at 11:55 AM, Michel Dänzer wrote:
> On 2018-07-17 08:14 PM, Marek Olšák wrote:
>> Michel, I think you are wasting your time. This change can be misused
>> as easily as any other API. It's not more dangerous that any other
>> amdgpu libdrm function.
>
> That's trivially false.
Otherwise there may be potential SMU performance issues.
Change-Id: I05a09bb05407f7b3705d79a1d2c6628385c80461
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 5 -
drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 5 -
2 files changed, 8
The argument was set wrongly. Fast/slow switch was asked when there is
actually a slow/fast switch needed.
Change-Id: Ibcfdf741dea1700cc3796f84291606231e732f4b
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 2 +-
Slow switch for UCLK when there is multiple displays and they are
not in sync.
Change-Id: I8a296400d8b96443cc95518905307fc76c9f9e44
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Those two patches are Reviewed-by: Jim Qu
Thanks
JimQu
发件人: amd-gfx 代表 Alex Deucher
发送时间: 2018年7月19日 22:35:53
收件人: amd-gfx@lists.freedesktop.org
抄送: Deucher, Alexander
主题: [PATCH 2/2] drm/amdgpu/acpi: skip backlight events for DC
No change in
On 07/19/2018 04:17 PM, Andrey Grodzovsky wrote:
On 07/19/2018 03:37 PM, Harry Wentland wrote:
On 2018-07-19 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
On 07/19/2018 03:37 PM, Harry Wentland wrote:
On 2018-07-19 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 Thu, Jul 19, 2018 at 5:37 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> We were leaking it.
>
> Also, don't bother allocating new memory if it's already the expected
> size.
>
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
> ---
> src/drmmode_display.c | 7 ++-
> 1
On Thu, Jul 19, 2018 at 11:01 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> We always destroy the fbcon pixmap in drmmode_copy_fb anyway.
>
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
> ---
> src/amdgpu_drv.h | 1 -
> src/amdgpu_kms.c | 3 ---
>
On Thu, Jul 19, 2018 at 3:49 PM, Harry Wentland wrote:
> [Why]
> We were only setting this mask for DCN, but should really use it
> universally for all ASICs.
>
> [How]
> Move the assignment out of the Raven switch statement for all ASICs
> other than Stoney and Carrizo.
>
> v2: Keep stutter
[Why]
We were only setting this mask for DCN, but should really use it
universally for all ASICs.
[How]
Move the assignment out of the Raven switch statement for all ASICs
other than Stoney and Carrizo.
v2: Keep stutter always on for Carrizo and Stoney (Alex)
Cc: rex@amd.com
Cc:
On Thu, Jul 19, 2018 at 2:28 PM, Harry Wentland wrote:
> These are only ever called for non-DC code.
>
> Signed-off-by: Harry Wentland
Acked-by: Alex Deucher
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 ++
> 1 file changed, 2 insertions(+), 16 deletions(-)
>
>
Hi Dave,
More features for 4.19:
- Map processes to vmids for debugging GPUVM faults
- Raven gfxoff fixes
- Initial gfxoff support for vega12
- Use defines for interrupt sources rather than magic numbers
- DC aux fixes
- Finish DC logging TODO
- Add more DC debugfs interfaces for conformance
On 2018-07-19 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
On Wed, Jul 18, 2018 at 4:39 PM, wrote:
> From: Boyuan Zhang
>
> Enable system interrupt for jrbc during engine starting time.
>
> Signed-off-by: Boyuan Zhang
> ---
> drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git
Yes, agree! It's better to use that existing function. Will change it
accordingly.
Thanks,
Boyuan
From: Liu, Leo
Sent: July 19, 2018 2:13:50 PM
To: Zhang, Boyuan; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/5] drm/amdgpu: enable system interrupt for
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:
>
> On
These are only ever called for non-DC code.
Signed-off-by: Harry Wentland
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
On 07/18/2018 04:39 PM, boyuan.zh...@amd.com wrote:
From: Boyuan Zhang
Enable system interrupt for jrbc during engine starting time.
Signed-off-by: Boyuan Zhang
---
drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git
Hi Alex, Harry,
I wonder if this patch should have been tagged for stable.
Thanks
--
Gustavo
On 07/04/2018 08:22 AM, Gustavo A. R. Silva wrote:
> Add suffix ULL to constant 5 and cast variables target_pix_clk_khz and
> feedback_divider to uint64_t in order to avoid multiple potential integer
>
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:
On 07/19/2018 11:39 AM, Ville Syrjälä wrote:
On Thu, Jul 19, 2018 at 11:19:56AM -0400, Andrey
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:
>>> On 07/19/2018 11:39 AM, Ville Syrjälä wrote:
On Thu, Jul 19, 2018 at 11:19:56AM -0400, Andrey Grodzovsky wrote:
> Problem:
> FB
On Thu, Jul 19, 2018 at 11:14 AM, Zhu, Rex wrote:
> >We also need to power it back up in hw_fini and suspend and then power
> >it back down in resume.
>
> Yes, this logic will be added in acp block.
> In this patch, we only power down acp when it was not used and have no
> inpact wen s3.
>
But
On 07/19/2018 12:47 PM, Michel Dänzer wrote:
On 2018-07-19 06:33 PM, Andrey Grodzovsky wrote:
On 07/19/2018 11:39 AM, Ville Syrjälä wrote:
On Thu, Jul 19, 2018 at 11:19:56AM -0400, Andrey Grodzovsky wrote:
Problem:
FB is still not unpinned during the first run of amdgpu_bo_evict_vram
and so
On 2018-07-19 06:33 PM, Andrey Grodzovsky wrote:
> On 07/19/2018 11:39 AM, Ville Syrjälä wrote:
>> On Thu, Jul 19, 2018 at 11:19:56AM -0400, Andrey Grodzovsky wrote:
>>> Problem:
>>> FB is still not unpinned during the first run of amdgpu_bo_evict_vram
>>> and so it's left for the second run, but
On 07/19/2018 11:25 AM, Christian König wrote:
Am 19.07.2018 um 17:19 schrieb Andrey Grodzovsky:
Problem:
FB is still not unpinned during the first run of amdgpu_bo_evict_vram
and so it's left for the second run, but during second run the SDMA for
moving buffer around already disabled and you
On 07/19/2018 11:39 AM, Ville Syrjälä wrote:
On Thu, Jul 19, 2018 at 11:19:56AM -0400, Andrey Grodzovsky wrote:
Problem:
FB is still not unpinned during the first run of amdgpu_bo_evict_vram
and so it's left for the second run, but during second run the SDMA for
moving buffer around already
From: Michel Dänzer
The warning turned out to be not so useful, as BO destruction tends to
be deferred to a workqueue.
Also, we should be preventing any damage from this now, so not really
important anymore to fix code doing this.
Signed-off-by: Michel Dänzer
---
On Thu, Jul 19, 2018 at 11:19:56AM -0400, Andrey Grodzovsky wrote:
> Problem:
> FB is still not unpinned during the first run of amdgpu_bo_evict_vram
> and so it's left for the second run, but during second run the SDMA for
> moving buffer around already disabled and you have to do
> it with CPU,
On 2018-07-19 11:25 AM, Christian König wrote:
> Am 19.07.2018 um 17:19 schrieb Andrey Grodzovsky:
>> Problem:
>> FB is still not unpinned during the first run of amdgpu_bo_evict_vram
>> and so it's left for the second run, but during second run the SDMA for
>> moving buffer around already
Am 19.07.2018 um 17:19 schrieb Andrey Grodzovsky:
Problem:
FB is still not unpinned during the first run of amdgpu_bo_evict_vram
and so it's left for the second run, but during second run the SDMA for
moving buffer around already disabled and you have to do
it with CPU, but FB is not in visible
On 2018-07-19 11:17 AM, Harry Wentland wrote:
On 2018-07-19 10:36 AM, Christian König wrote:
Note that Harry and Leo Li are maintainers for that stuff.
Signed-off-by: Christian König
Reviewed-by: Harry Wentland
Reviewed-by: Leo Li
Harry
---
MAINTAINERS | 8
1 file
Problem:
FB is still not unpinned during the first run of amdgpu_bo_evict_vram
and so it's left for the second run, but during second run the SDMA for
moving buffer around already disabled and you have to do
it with CPU, but FB is not in visible VRAM and hence the eviction failure
leading later to
On 2018-07-19 10:36 AM, Christian König wrote:
> Note that Harry and Leo Li are maintainers for that stuff.
>
> Signed-off-by: Christian König
Reviewed-by: Harry Wentland
Harry
> ---
> MAINTAINERS | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
>
>We also need to power it back up in hw_fini and suspend and then power
>it back down in resume.
Yes, this logic will be added in acp block.
In this patch, we only power down acp when it was not used and have no inpact
wen s3.
Best Regards
Rex
From: Alex
From: Michel Dänzer
We always destroy the fbcon pixmap in drmmode_copy_fb anyway.
Signed-off-by: Michel Dänzer
---
src/amdgpu_drv.h | 1 -
src/amdgpu_kms.c | 3 ---
src/drmmode_display.c | 13 ++---
3 files changed, 2 insertions(+), 15 deletions(-)
diff --git
On 2018-07-19 04:36 PM, Christian König wrote:
> Note that Harry and Leo Li are maintainers for that stuff.
>
> Signed-off-by: Christian König
> ---
> MAINTAINERS | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e613df455ae0..2e9111e65d64
Note that Harry and Leo Li are maintainers for that stuff.
Signed-off-by: Christian König
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e613df455ae0..2e9111e65d64 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -728,6 +728,14 @@ S:
No change in behavior, just bail sooner.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index
Check the supported functions mask before calling the bios
requests method.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 53 +---
1 file changed, 28 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
On 2018-07-19 12:02 PM, Shirish S wrote:
> [Why]
> While the console_lock is held, console output will be buffered, till
> its unlocked it wont be emitted, hence its ideal to unlock sooner to enable
> debugging/detecting/fixing of any issue in the remaining sequence of events
> in resume path.
>
On Thu, Jul 19, 2018 at 4:44 AM, Rex Zhu wrote:
> This can fix the issue resume from S3, the user's OD setting
> were reverted to default.
>
> Signed-off-by: Rex Zhu
Series is:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 15 +++
> 1 file
On Thu, Jul 19, 2018 at 4:46 AM, Rex Zhu wrote:
> when ACP block not enabled, we power off
> acp block to save power.
>
> Signed-off-by: Rex Zhu
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/powerplay/amd_powerplay.c| 18 ++
>
On Thu, Jul 19, 2018 at 4:46 AM, Rex Zhu wrote:
> if board uses AZ rather than ACP, we power down acp
> through smu to save power.
>
We also need to power it back up in hw_fini and suspend and then power
it back down in resume.
Alex
> Signed-off-by: Rex Zhu
> ---
>
On Thu, Jul 19, 2018 at 5:17 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
Acked-by: Alex Deucher
David was also interested in helping out as a maintainer. I don't
remember
On 07/18/2018 02:44 PM, Christian König wrote:
The whole handle, filp and entity handling is superfluous here.
We should have reviewed that more thoughtfully. It looks like somebody
just made the code instance aware without knowing the background.
Yeah It's only required for UVD without VMID
On 07/18/2018 02:44 PM, Christian König wrote:
Not sure what that was every used for, but now it is completely unused.
UVD having it's own scheduler entity is inherited from UVD physical
mode, which need send session destroy ib when session is done to free
the handle in firmware.
Because we
From: Michel Dänzer
We don't need it.
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 39 +++
1 file changed, 11 insertions(+), 28 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index e947ca979..bf8b1a8b6 100644
---
[Why]
While the console_lock is held, console output will be buffered, till
its unlocked it wont be emitted, hence its ideal to unlock sooner to enable
debugging/detecting/fixing of any issue in the remaining sequence of events
in resume path.
The concern here is about consoles other than fbcon on
[Why]
While the console_lock is held, console output will be buffered, till
its unlocked it wont be emitted, hence its ideal to unlock sooner to enable
debugging/detecting/fixing of any issue in the remaining sequence of events
in resume path.
The concern here is about consoles other than fbcon on
On 2018-07-19 11:29 AM, Shirish S wrote:
> [Why]
> While the console_lock is held, console output will be buffered, till
> its unlocked it wont be emitted, hence its ideal to unlock sooner to enable
> debugging/detecting/fixing of any issue in the remaining sequence of events
> in resume path.
>
From: Michel Dänzer
We were leaking it.
Also, don't bother allocating new memory if it's already the expected
size.
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
[Why]
While the console_lock is held, console output will be buffered, till
its unlocked it wont be emitted, hence its ideal to unlock sooner to enable
debugging/detecting/fixing of any issue in the remaining sequence of events
in resume path.
The concern here is about consoles other than fbcon on
On 2018-07-18 12:24 PM, Shirish S wrote:
> [Why]
> While the console_lock is held, console output will be buffered, till
> its unlocked it wont be emitted, hence its ideal to unlock sooner to enable
> debugging/detecting/fixing of any issue in the remaining sequence of events
> in resume path.
Does anybody see any reasons why this should get into mmotm tree?
I do not want to rush this in but if general feeling is to push it for
the upcoming merge window then I will not object.
--
Michal Hocko
SUSE Labs
___
amd-gfx mailing list
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(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9d5eeff51b5f..e613df455ae0 100644
---
if board uses AZ rather than ACP, we power down acp
through smu to save power.
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
when ACP block not enabled, we power off
acp block to save power.
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/amd_powerplay.c| 18 ++
drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c | 21 -
drivers/gpu/drm/amd/powerplay/inc/hwmgr.h|
This can fix the issue resume from S3, the user's OD setting
were reverted to default.
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
Use the vddc limit before read them from vbios
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
On Thu, Jul 19, 2018 at 01:28:22PM +0800, Evan Quan wrote:
> The 'result' is not initialized correctly. It causes the API
> return an error code even on success.
>
> Change-Id: I14aea88b4022b490fb073bc1d4713f4edb96fb46
> Signed-off-by: Evan Quan
Acked-by: Huang Rui
> ---
>
On Wed, Jul 18, 2018 at 11:17:56AM +0200, Christian König wrote:
> Make struct amdgpu_bo a bit smaller.
>
> Signed-off-by: Christian König
Reviewed-by: Huang Rui
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 3 ++-
> 2 files
62 matches
Mail list logo
