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
b/drivers/gpu/drm/amd/powerplay/hwmgr/v
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
b/drivers/
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|
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
b/drivers/gpu/drm/amd/amdgpu/amdg
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
--- a/MAINTAI
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
amd-gfx@lists.fr
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.
May
[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
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
in
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.
> Th
[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
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
--- a/src/d
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 c
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 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 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
> ---
> drivers/gpu/drm/amd/amdgpu/
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 ++
> drivers/gpu/drm/amd/powerplay/hwmgr/sm
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 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.
> Th
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 455617813ec4..353993
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
b/
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: Supp
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 100644
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 a/src/amdgpu_
>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 Deucher
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
> i
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 chan
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
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 V
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 disabled
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, b
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
---
drivers/gpu/drm/amd/amdgpu/am
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 di
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 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 d
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 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 I
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 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 Grodzovs
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
> o
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 a/drivers/gp
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
b/drivers/gpu/drm/amd/display/am
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 07/
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 jrb
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 a/drivers/g
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 2018-0
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 testi
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(-)
>
>
[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: feifei...@am
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 alway
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 ---
> src/drmmode_disp
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 file
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 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 wro
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 behavi
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 a/drivers/gpu/dr
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 +-
drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr
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 insertions(+),
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.
60 matches
Mail list logo
