Fix compiling error when CONFIG_ACPI not enabled.
Change-Id: I20d3f55bbd2ad68e65363cde7452802b063643f0
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c | 2 ++
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drive
On Tue, Mar 6, 2018 at 12:46 AM, Rex Zhu wrote:
> replace smu_upper_32_bits/smu_lower_32_bits with
> the standard kernel macros
>
> Change-Id: I89dec914c716d6dd74f39f3eb63d875f750d460e
> Signed-off-by: Rex Zhu
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/powerplay/inc/smumgr.h
replace smu_upper_32_bits/smu_lower_32_bits with
the standard kernel macros
Change-Id: I89dec914c716d6dd74f39f3eb63d875f750d460e
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/inc/smumgr.h | 5 -
drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c | 24 +++--
to catch error that may schedule in atomic context early on
Change-Id: I49dec7c55470011729b7fa7d3e1ecfe1f38ed89f
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
b/drivers/gpu
this patch actually refactor mailbox implmentations, and
all below changes are needed together to fix all those mailbox
handshake issues exposured by heavey TDR test.
1)refactor all mailbox functions based on byte accessing for mb_control
reason is to avoid touching non-related bits when writing t
Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767
Signed-off-by: Monk Liu
---
drivers/dma-buf/reservation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 314eb10..29b7e45 100644
--- a/drivers/dma-buf/rese
mailbox register can be accessed with a byte boundry according
to BIF team, so this patch prepares register byte access
and will be used by following patches
Change-Id: I1e84f1c6e8e75dc42eb5be09c492fa5e7eb7502a
Signed-off-by: Monk Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 6 ++
d
Acked-by: Alex Deucher
From: amd-gfx on behalf of Emily Deng
Sent: Monday, March 5, 2018 9:14 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deng, Emily
Subject: [PATCH] drm/amdgpu: Disable sdma wptr polling memory for sriov
The sdma wptr polling memory will introdu
Acked-by: Alex Deucher
From: amd-gfx on behalf of Emily Deng
Sent: Thursday, March 1, 2018 10:31 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deng, Emily
Subject: [PATCH] Revert "drm/amdgpu: use polling mem to set SDMA3 wptr for VF"
This reverts commit 2ffe31deb27
The sdma wptr polling memory will introduce serious issue sdma hang for
sriov environment on sdma v3.
And the sdma wptr polling memory is only to fix the FLR cornner case, the
issue's probabity is very low.
Change-Id: I2c447533aac6b16d541f58644d141228dd75dfb3
Signed-off-by: Emily Deng
---
driver
Patch 1: Acked-by: Roger He
Patch 2~5: Reviewed-by: Roger He
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Monday, March 05, 2018 8:07 PM
To: dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org; Ben Ske
Ping
Hi all,
Please help review this, the regression introduced by the commit
2ffe31deb27579e2f2c9444e01f4d8abf385d145 is gating the sriov sanity test.
Best Wishes,
Emily Deng
> -Original Message-
> From: Emily Deng [mailto:emily.d...@amd.com]
> Sent: Friday, March 02, 2018 11:3
On 2018-03-05 12:50 PM, Christian König wrote:
>>> The easiest way to work around this to to add a separate IOCTL which
>>> waits for VM updates to complete. Should be trivial to use
>>> vm->last_update for this.
>> For the cost of an extra system call. That means every GPU mapping
>> operation no
On 2018-03-01 02:56 AM, S, Shirish wrote:
> From: Shirish S
>
> Add reverse iterator for_each_oldnew_plane_in_state_reverse to compliment the
> for_each_oldnew_plane_in_state way or reading plane states.
>
> The plane states are required to be read in reverse order for amd drivers,
> cause the
On Mon, Mar 5, 2018 at 12:44 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Since xf86CursorCloseScreen runs after RADEONCloseScreen_KMS,
> PointPriv->spriteFuncs doesn't point to the same struct in the latter as
> in RADEONCursorInit_KMS. So we were restoring info->Set/MoveCursor to
> the wr
On Mon, Mar 5, 2018 at 10:06 PM, Christian König
wrote:
> Ping?
On a quick look, it looks like both are used sometimes. I believe
this had something to do with the addition of Tegra support, but I'll
need some time to look into the details of why/how these things are
used again.
Ben.
>
>
> Am 2
Hi list,
I'd like to report a very odd screen artifacts while running both
4.16-rc3, as well as latest 4.16-rc4 with git linux-firmware.
I am using Ryzen 2400G with the integrate Vega.
I am aware that RAVEN support is yet to be finished, however I've read
that some people do run it already,
On Mon, Mar 5, 2018 at 12:14 PM, Christian König
wrote:
> Am 05.03.2018 um 17:58 schrieb Felix Kuehling:
>>
>> On 2018-03-05 07:17 AM, Christian König wrote:
>>>
>>> Am 04.03.2018 um 03:34 schrieb Felix Kuehling:
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/
On 2018-03-05 12:14 PM, Christian König wrote:
>> Also, we'd need to fix shadow page table handling with CPU updates, or
>> get rid of shadow page tables. I'm not sure why they're needed, TBH.
>
> The idea behind shadow page tables is that you have the current state
> of the pipeline if the GPU cr
Am 05.03.2018 um 19:30 schrieb Alex Deucher:
Always set the graphics values to the max for the
asic type. E.g., some 1 RB chips are actually 1 RB chips,
others are actually harvested 2 RB chips.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=99353
Signed-off-by: Alex Deucher
Cc: sta...@vg
Always set the graphics values to the max for the
asic type. E.g., some 1 RB chips are actually 1 RB chips,
others are actually harvested 2 RB chips.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=99353
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/amd/amdgpu/g
Always set the graphics values to the max for the
asic type. E.g., some 1 RB chips are actually 1 RB chips,
others are actually harvested 2 RB chips.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=99353
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/cik.c
On Sun, Mar 4, 2018 at 11:09 PM, Monk Liu wrote:
> Change-Id: Iec96c7762d791164c719ec64ec410e00a8cf5d90
> Signed-off-by: Monk Liu
Already fixed in amd-staging-drm-next.
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Mon, Mar 5, 2018 at 2:55 AM, Rex Zhu wrote:
> use SW method to update DPM settings by updating SRAM
> directly on CI.
>
> Change-Id: Ie9ed6c3a0e1c327cc9a9b06bec47b1cede87278d
> Signed-off-by: Rex Zhu
Series is:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/powerplay/smumgr/ci_smumg
On Mon, Mar 5, 2018 at 7:00 AM, Christian König
wrote:
> Disable the workaround on imported BOs as well.
>
> Signed-off-by: Christian König
Series is:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(
On Mon, Mar 5, 2018 at 5:43 AM, Rex Zhu wrote:
> use amdgpu_bo_create/free_kernel directly.
>
> Change-Id: I74f20353edd4e0df6328db66914cd9eabb60e1d7
> Signed-off-by: Rex Zhu
> ---
> drivers/gpu/drm/amd/powerplay/inc/smumgr.h | 7 -
> drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c |
On Mon, Mar 5, 2018 at 1:46 AM, Rex Zhu wrote:
> This reverts commit e429ea87b2939c4cce1b439baf6d76535a0767f2.
>
> Implement Workload Aware Dynamic power management instand of
> AutoWattman feature in linux.
>
> Change-Id: I619ba5695b14e1d165829c98d2776e5173f2737e
> Signed-off-by: Rex Zhu
Review
On Fri, Mar 2, 2018 at 5:49 AM, Rex Zhu wrote:
> Change-Id: I248982c5e0100b7a975d1a19781749baeadd71f4
> Signed-off-by: Rex Zhu
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gp
Am 05.03.2018 um 18:22 schrieb Felix Kuehling:
[SNIP]
I've been looking for documentation about the expected behaviour for
system calls interrupted by signals. All I can find is this statement in
Documentation/kernel-hacking/hacking.rst:
After you slept you should check if a signal occurred: th
From: Michel Dänzer
Since xf86CursorCloseScreen runs after RADEONCloseScreen_KMS,
PointPriv->spriteFuncs doesn't point to the same struct in the latter as
in RADEONCursorInit_KMS. So we were restoring info->Set/MoveCursor to
the wrong struct. Then in the next server generation,
info->Set/MoveCurs
On 2018-03-05 12:14 PM, Christian König wrote:
> Am 05.03.2018 um 17:58 schrieb Felix Kuehling:
>> On 2018-03-05 07:17 AM, Christian König wrote:
>>> Am 04.03.2018 um 03:34 schrieb Felix Kuehling:
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 82
Am 05.03.2018 um 17:58 schrieb Felix Kuehling:
On 2018-03-05 07:17 AM, Christian König wrote:
Am 04.03.2018 um 03:34 schrieb Felix Kuehling:
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 82
++
drivers/gpu/drm/amd/amdgpu/amdgpu_
On 2018-03-05 07:17 AM, Christian König wrote:
> Am 04.03.2018 um 03:34 schrieb Felix Kuehling:
>> Signed-off-by: Felix Kuehling
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 82
>> ++
>> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 1 +
>> 2 files changed, 83
Michel Dänzer writes:
> On 2018-03-03 05:49 AM, Keith Packard wrote:
>> Here are the patches to the modesetting driver amended for the amdgpu
>> driver.
>
> Thanks for the patches. Unfortunately, since this driver still has to
> compile and work with xserver >= 1.13, at least patches 1 & 3 cannot
There are three major options when SG capability is enabled,
1) Allocate everything when possible from GTT memory
2) Allocate everything when possible from VRAM
3) Allow both VRAM/GTT to be available
Each has its own pros/cons, and it has not been decided which direction is
going to be used for al
>> +if (amdgpu_display_framebuffer_domains(adev) ==
>> AMDGPU_GEM_DOMAIN_GTT)
>
> This check should probably be & instead of ==.
Thought about that as well. For mixed VRAM/GTT display case, since it has some
complications, I prefer to do it later.
Sam
On 2018-03-03 08:42 AM, Christi
will remove repeated assignment to mc_addr in verion 2.
Best Regards
Rex
From: amd-gfx on behalf of Rex Zhu
Sent: Monday, March 5, 2018 6:43 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: [PATCH 2/3] drm/amd/pp: Delete the wrap layer of
smu_allo
Am 04.03.2018 um 03:34 schrieb Felix Kuehling:
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 82 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 1 +
2 files changed, 83 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm
Ping?
Am 27.02.2018 um 13:07 schrieb Christian König:
Hi guys,
at least on amdgpu and radeon the page array allocated by
ttm_dma_tt_init is completely unused in the case of DMA-buf sharing.
So I'm trying to get rid of that by only allocating the DMA address
array.
Now the only other user o
Ping? Anybody who could give me an review on those changes?
The first one is just nice to have, the rest is a nice memory usage
reduction in some cases.
Christian.
Am 27.02.2018 um 12:49 schrieb Christian König:
Unpin the GEM object only after freeing the sg table.
Signed-off-by: Christian
Allow evicting all BOs from the GTT domain.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
Disable the workaround on imported BOs as well.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
ind
We can use ttm->bdev instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 614811061d3d..b19a4f7a8
Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767
Signed-off-by: Monk Liu
---
drivers/dma-buf/reservation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 375de41..9b875267 100644
--- a/drivers/dma-buf/res
Hi Monk,
then that was written differently. Maybe "might_sleep()" or something
like that?
It's just a checker which raises a nice warning when you try to sleep in
atomic context on debug kernels.
Christian.
Am 05.03.2018 um 12:27 schrieb Liu, Monk:
Hi Christian
I couln't find this "may_s
Hi Christian
I couln't find this "may_sleep()" in my 4.13kernel , did I miss something ??
Thanks
/Monk
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: 2018年3月5日 19:21
To: Liu, Monk ; Koenig, Christian ;
Kuehling, Felix ; amd-gfx@lists.freedeskt
Acked-by: Christian König for the series.
Am 05.03.2018 um 11:43 schrieb Rex Zhu:
Change-Id: I742e82315910ce57aeb4a391fe2ac1cdfccdb8ea
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 13 -
drivers/gpu/drm/amd/include/cgs_common.h | 6 --
drivers/gpu
Am 05.03.2018 um 09:08 schrieb Liu, Monk:
To better approach this issue I suggest to do the following:
1. Revert the original patch.
2. Stop waiting to long for writes. E.g. use a separate timeout (20ms
maybe?) to wait for the write. Then do a WARN_ON_ONCE when we timeout.
Cannot do that 20ms is
Change-Id: I9085b42b3ffac925aebd8000760d456a4f8ec03c
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 131 ---
drivers/gpu/drm/amd/include/cgs_common.h | 115 ---
2 files changed, 246 deletions(-)
diff --git a/drivers/gpu/d
use amdgpu_bo_create/free_kernel directly.
Change-Id: I74f20353edd4e0df6328db66914cd9eabb60e1d7
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/inc/smumgr.h | 7 -
drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c | 39 +++---
drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.h
Change-Id: I742e82315910ce57aeb4a391fe2ac1cdfccdb8ea
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 13 -
drivers/gpu/drm/amd/include/cgs_common.h | 6 --
drivers/gpu/drm/amd/powerplay/hwmgr/hardwaremanager.c | 4 +++-
3 files changed, 3 insertions(+), 2
You can tag my RB
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Deng,
Emily
Sent: 2018年3月5日 18:20
To: Deng, Emily ; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] Revert "drm/amdgpu: use polling mem to set SDMA3 wptr for
VF"
Ping
Hi
On 2018-03-03 12:27 AM, Samuel Li wrote:
> ---
> include/drm/amdgpu_drm.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
> index d9aa4a3..dc4d8bd 100644
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
> @@ -526,6 +526
Ping
Hi all,
Please help review this, the regression introduced by the commit
2ffe31deb27579e2f2c9444e01f4d8abf385d145 is gating the sriov sanity test.
Best Wishes,
Emily Deng
> -Original Message-
> From: Emily Deng [mailto:emily.d...@amd.com]
> Sent: Friday, March 02, 2018 11:3
On 2018-03-03 12:25 AM, Samuel Li wrote:
> It's enabled by default. -1 is auto, to allow both vram and gtt
> memory be available, for testing purpose only.
Do we really need a module parameter for this? There's already too many
of them. The driver should know which to use in which cases, and
devel
On 2018-03-03 05:49 AM, Keith Packard wrote:
> Here are the patches to the modesetting driver amended for the amdgpu
> driver.
Thanks for the patches. Unfortunately, since this driver still has to
compile and work with xserver >= 1.13, at least patches 1 & 3 cannot be
applied as is.
I was going t
On 2018-03-04 08:25 AM, Mario Kleiner wrote:
> Hi Michel,
>
> wrt. our conversation from ~ 1 month ago:
>
> On 01/22/2018 07:01 PM, Michel Dänzer wrote:
>> On 2018-01-22 03:14 AM, Mario Kleiner wrote:
>>
>>> When testing against current master in dual-x-screen mode,
>>> i found out that the curre
Reviewed-by: Evan Quan
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Rex
Zhu
Sent: Friday, March 02, 2018 8:44 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: [PATCH 4/4] drm/amd/pp: Add auto power profilng switch based on
workl
Reviewed-by: Evan Quan
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Rex
Zhu
Sent: Friday, March 02, 2018 8:44 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: [PATCH 3/4] drm/amd/pp: Revert gfx/compute profile switch sysfs
The g
Reviewed-by: Evan Quan
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Rex
Zhu
Sent: Friday, March 02, 2018 8:44 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: [PATCH 2/4] drm/amd/pp: Fix sclk in highest two levels in compute mode
use SW method to update DPM settings by updating SRAM
directly on CI.
Change-Id: Ie9ed6c3a0e1c327cc9a9b06bec47b1cede87278d
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c | 97
1 file changed, 97 insertions(+)
diff --git a/drivers/gpu/drm/amd
use SW method to update DPM settings by updating SRAM
directly on Tonga.
Change-Id: I21b1f5caee85587e30ff4d37b040d3ba36b843ee
Signed-off-by: Rex Zhu
---
.../gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c| 97 ++
1 file changed, 97 insertions(+)
diff --git a/drivers/gpu/drm/
use SW method to update DPM settings by updating SRAM
directly on Fiji.
Change-Id: Ic485e526332a0f1a169d395dfe810d71e5bdfea8
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c | 97 ++
1 file changed, 97 insertions(+)
diff --git a/drivers/gpu/drm/a
To better approach this issue I suggest to do the following:
1. Revert the original patch.
2. Stop waiting to long for writes. E.g. use a separate timeout (20ms
maybe?) to wait for the write. Then do a WARN_ON_ONCE when we timeout.
Cannot do that 20ms is not enough, sometimes you need 10 seconds s
Comment inline.
Regards
Evan
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Rex
Zhu
Sent: Friday, March 02, 2018 8:44 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Rex
Subject: [PATCH 1/4] drm/amd/pp: Implement get/set_power_profile_mode on
65 matches
Mail list logo