the member of is_apu in smu_context need to initlialize by default.
set default value is false (dGPU)
for patch:
drm/amd/powerplay: bypass dpm_context null pointer check guard
for some smu series
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 1 +
1
The patch c670707 drm/amd: Pass drm_device to kfd introduced this issue and
fix the following compiler error.
CC [M] drivers/gpu/drm/amd/amdgpu//../powerplay/smumgr/fiji_smumgr.o
drivers/gpu/drm/amd/amdgpu//amdgpu_amdkfd.c:746:6: error: conflicting types for
‘kgd2kfd_device_init’
bool kgd2kfd
> -Original Message-
> From: Liu, Aaron
> Sent: Friday, September 27, 2019 11:23 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Huang, Ray ; Liu, Aaron
> Subject: [PATCH] Revert "drm/amdgpu: disable stutter mode for renoir"
>
> This reverts commit c512e6fdfd2da917b5b6792902e7224f58a77f94.
This reverts commit c512e6fdfd2da917b5b6792902e7224f58a77f94.
Since SBIOS WCD9925N, NMI printing disappeared. Hence enable stutter
mode.
Signed-off-by: Aaron Liu
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/displa
the smu driver need to split and optimize "smu->mutex" first,
because this lock is used on most scene.
after this lock clearly, we can define more fine-grained lock resource in smu
driver.
Best Regards,
Kevin
From: Quan, Evan
Sent: Friday, September 27, 2019 9:
There should be no issue with old powerplay routines.
As there is API lock(hwmgr->smu_lock) in amd_powerplay.c.
It's quite coarse-grained but working.
In fact, I'm considering whether we need to take the same way in swSMU routine.
Since for now it's hard to define what we are protecting for and th
On 2019-09-26 3:12 a.m., Koenig, Christian wrote:
> Am 25.09.19 um 16:54 schrieb Huang, Ray:
>>> -Original Message-
>>> From: Koenig, Christian
>>> Sent: Wednesday, September 25, 2019 10:47 PM
>>> To: Huang, Ray ; amd-gfx@lists.freedesktop.org; dri-
>>> de...@lists.freedesktop.org; Deucher
kfree() checks this automatically.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu
This commit is seperate from the previous one to make it easier to
revert in the future. Basically, there's multiple userspace applications
that interpret possible_crtcs very wrong:
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277
https://gitlab.gnome.org/GNOME/mutter/issues/759
Whi
Turns out that we don't actually check this anywhere, and additionally
actually forget to even mention this in our documentation.
Since we've had one driver making this mistake already, let's clarify
this by mentioning this limitation in the kernel docs. Additionally, for
drivers not using the leg
While this commit certainly will result in creating less fake MST
encoders, the main purpose of this is actually to fix amdgpu's incorrect
usage of the drm_encoder API in it's MST code. Currently we create one
encoder per-MST connector. However, MST connectors can and usually do
get created at basi
Noticed this while trying to respin my MST suspend/resume patch series.
It's not technically possible (at least until someone moves amdgpu
away from the deprecated drm_device->driver->{load,unload} hooks) for
amdgpu to properly register all of it's encoders before registering with
userspace. Howeve
We are supposed to be atomic after all. We'll need this in a moment for
the next commit.
Signed-off-by: Lyude Paul
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgp
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 5ec14efd4d8c..185bf0e2
On 2019-09-25 2:15 p.m., Zhao, Yong wrote:
> This was done on GFX9 previously, now do it for GFX10.
>
> Change-Id: I4442e60534c59bc9526a673559f018ba8058deac
> Signed-off-by: Yong Zhao
Reviewed-by: Felix Kuehling
> ---
> .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 23 +++
>
For GFXv9 you made an equivalent change for both GFXHub and MMHub
("drm/amdgpu: Expose *_setup_vm_pt_regs for kfd to use"). Your GFXv9
commit was also reviewed by Alex and Christian. You should get at least
one of them to Ack or Review this change.
For GFXv10 you're only changing the GFXHub. I
On 2019-09-26 6:16 p.m., Kuehling, Felix wrote:
> On 2019-09-26 5:59 p.m., Zhao, Yong wrote:
>> On 2019-09-26 5:36 p.m., Kuehling, Felix wrote:
>>> Minor nit-pick inline. Otherwise this patch is
>>>
>>> Reviewed-by: Felix Kuehling
>>>
>>> On 2019-09-26 5:27 p.m., Zhao, Yong wrote:
This makes
On 2019-09-26 5:59 p.m., Zhao, Yong wrote:
> On 2019-09-26 5:36 p.m., Kuehling, Felix wrote:
>> Minor nit-pick inline. Otherwise this patch is
>>
>> Reviewed-by: Felix Kuehling
>>
>> On 2019-09-26 5:27 p.m., Zhao, Yong wrote:
>>> This makes possible the vmid pasid mapping query through software.
Okay, I will delete that message.
Yong
On 2019-09-26 5:31 p.m., Kuehling, Felix wrote:
> On 2019-09-26 5:27 p.m., Zhao, Yong wrote:
>> Because we record the mapping under non HWS mode in the software,
>> we can query pasid through vmid using the stored mapping instead of
>> reading from ATC regis
On 2019-09-26 5:36 p.m., Kuehling, Felix wrote:
> Minor nit-pick inline. Otherwise this patch is
>
> Reviewed-by: Felix Kuehling
>
> On 2019-09-26 5:27 p.m., Zhao, Yong wrote:
>> This makes possible the vmid pasid mapping query through software.
>>
>> Change-Id: Ib539aae277a227cc39f6469ae23c46c4d
Minor nit-pick inline. Otherwise this patch is
Reviewed-by: Felix Kuehling
On 2019-09-26 5:27 p.m., Zhao, Yong wrote:
> This makes possible the vmid pasid mapping query through software.
>
> Change-Id: Ib539aae277a227cc39f6469ae23c46c4d289b87b
> Signed-off-by: Yong Zhao
> ---
> .../drm/amd/am
On 2019-09-26 5:27 p.m., Zhao, Yong wrote:
> Because we record the mapping under non HWS mode in the software,
> we can query pasid through vmid using the stored mapping instead of
> reading from ATC registers.
>
> This also prepares for the defeatured ATC block in future ASICs.
>
> Change-Id: I781
This makes possible the vmid pasid mapping query through software.
Change-Id: Ib539aae277a227cc39f6469ae23c46c4d289b87b
Signed-off-by: Yong Zhao
---
.../drm/amd/amdkfd/kfd_device_queue_manager.c | 33 ---
.../drm/amd/amdkfd/kfd_device_queue_manager.h | 3 +-
drivers/gpu/drm/amd/
Because we record the mapping under non HWS mode in the software,
we can query pasid through vmid using the stored mapping instead of
reading from ATC registers.
This also prepares for the defeatured ATC block in future ASICs.
Change-Id: I781cb9d30dc0cc93379908ff1cf8da798bb26f13
Signed-off-by: Yo
On 2019-09-26 5:02 p.m., Liu, Shaoyun wrote:
> I think this is only for none-hws case .
Yes. This is inside an if (!pasid && dev->dqm->sched_policy ==
KFD_SCHED_POLICY_NO_HWS).
Regards,
Felix
> HWS may dynamic change the
> mapping and driver will not get updated . If that's the case , ple
I think this is only for none-hws case . HWS may dynamic change the
mapping and driver will not get updated . If that's the case , please
specify this is for none hardware scheduler case in the header .
Regards
shaoyun.liu
On 2019-09-26 4:07 p.m., Kuehling, Felix wrote:
> On 2019-09-26 3:46
On 2019-09-26 3:46 p.m., Zhao, Yong wrote:
> Because we record the mapping in the software, we can query pasid
> through vmid using the stored mapping instead of reading from ATC
> registers.
>
> This also prepares for the defeatured ATC block in future ASICs.
>
> Change-Id: I781cb9d30dc0cc93379908
On 2019-09-26 3:46 p.m., Zhao, Yong wrote:
> This makes possible the vmid pasid mapping query through software.
>
> Change-Id: Ib539aae277a227cc39f6469ae23c46c4d289b87b
> Signed-off-by: Yong Zhao
> ---
> .../drm/amd/amdkfd/kfd_device_queue_manager.c | 33 ---
> .../drm/amd/amdkf
Because we record the mapping in the software, we can query pasid
through vmid using the stored mapping instead of reading from ATC
registers.
This also prepares for the defeatured ATC block in future ASICs.
Change-Id: I781cb9d30dc0cc93379908ff1cf8da798bb26f13
Signed-off-by: Yong Zhao
---
drive
This makes possible the vmid pasid mapping query through software.
Change-Id: Ib539aae277a227cc39f6469ae23c46c4d289b87b
Signed-off-by: Yong Zhao
---
.../drm/amd/amdkfd/kfd_device_queue_manager.c | 33 ---
.../drm/amd/amdkfd/kfd_device_queue_manager.h | 3 +-
drivers/gpu/drm/amd/
Patches 1-3 and patch 5 are
Reviewed-by: Felix Kuehling
See separate emails for patches 4 and 6.
On 2019-09-26 2:38 p.m., Zhao, Yong wrote:
> The GFX10 does not require the control stack to be right after mqd
> buffer any more, so move it back to usersapce allocated CSWR buffer.
>
> Change-Id:
On 2019-09-26 2:38 p.m., Zhao, Yong wrote:
> get_atc_vmid_pasid_mapping_valid() is very similar to
> get_atc_vmid_pasid_mapping_pasid(), so they can be merged into a new
> function get_atc_vmid_pasid_mapping_info() to reduce register access
> times.
Hmm, the most important part may actually not be
I agree.
Yong
On 2019-09-26 2:54 p.m., Kuehling, Felix wrote:
> On 2019-09-26 2:38 p.m., Zhao, Yong wrote:
>> This makes possible the vmid pasid mapping query through software.
>>
>> Change-Id: Ib539aae277a227cc39f6469ae23c46c4d289b87b
>> Signed-off-by: Yong Zhao
>> ---
>>.../drm/amd/amdkfd/
On 2019-09-26 2:38 p.m., Zhao, Yong wrote:
> This makes possible the vmid pasid mapping query through software.
>
> Change-Id: Ib539aae277a227cc39f6469ae23c46c4d289b87b
> Signed-off-by: Yong Zhao
> ---
> .../drm/amd/amdkfd/kfd_device_queue_manager.c | 34 +--
> .../drm/amd/amdkf
That was the same bug. What we need to do is to prevent VMID invalidation while
the SDMA is using it.
The first part was to disallow concurrent VMID flushes, the second part was
doing VMID0 flushes through the SDMA block itself.
Both workarounds where added to avoid corruption, that GFXOFF is h
Hi Felix,
I reworded this patch in the next series. Please review the first two patches
in this series.
Regards,
Yong
From: amd-gfx on behalf of Zhao, Yong
Sent: Wednesday, September 25, 2019 2:34 PM
To: Kuehling, Felix ; amd-gfx@lists.freedesktop.org
Subjec
Because we record the mapping in the software, we can query pasid
through vmid using the stored mapping instead of reading from ATC
registers.
This also prepares for the defeatured ATC block in future ASICs.
Change-Id: I781cb9d30dc0cc93379908ff1cf8da798bb26f13
Signed-off-by: Yong Zhao
---
.../g
They are not used anywhere.
Change-Id: Ieba4f57760f0c45f24e54629245cae419b8ff157
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
b/drivers/gpu/drm/amd/amdgpu/am
get_atc_vmid_pasid_mapping_valid() is very similar to
get_atc_vmid_pasid_mapping_pasid(), so they can be merged into a new
function get_atc_vmid_pasid_mapping_info() to reduce register access
times.
Change-Id: I255ebf2629012400b07fe6a69c3d075cfd46612e
Signed-off-by: Yong Zhao
---
.../drm/amd/amd
The GFX10 does not require the control stack to be right after mqd
buffer any more, so move it back to usersapce allocated CSWR buffer.
Change-Id: I446c9685549a09ac8846a42ee22d86cfb93fd98c
Signed-off-by: Yong Zhao
---
.../gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c | 37 ++-
1 file
Since KFD pasid starts from 0x8000 (32768 in decimal), it is better
perceived as a hex number. Meanwhile, change the pasid type from
unsigned int to uint16_t to be consistent throughout the code.
Change-Id: I565fe39f69e782749a697f18545775354c7a89f8
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/am
This makes possible the vmid pasid mapping query through software.
Change-Id: Ib539aae277a227cc39f6469ae23c46c4d289b87b
Signed-off-by: Yong Zhao
---
.../drm/amd/amdkfd/kfd_device_queue_manager.c | 34 +--
.../drm/amd/amdkfd/kfd_device_queue_manager.h | 3 +-
2 files changed, 26
Maybe I'm mixing up issues. The navi10/14 issue that was fixed on navi12 was
fixed in amdgpu_ids.c in
commit a2bd77bbde791202267c25478bbcbe71bb4ecdd5
Author: Christian König
Date: Thu Feb 7 12:10:29 2019 +0100
drm/amdgpu: disable concurrent flushes for Navi10 v2
Navi10 have a bug i
Well then you didn't figured out the root cause correctly.
This is to avoid data corruption with the SDMA on Navi 10/14 and should
definitely not applied to Navi 12.
The hardware team went through quite some work to avoid this.
Christian.
Am 26.09.2019 19:38 schrieb "Yuan, Xiaojie" :
Hi Alex
Hi Alex / Christian,
When gfxoff is enabled for Navi12, I observed sdma0 hang while launching
desktop. When this workaround is applied, the issue fades away.
That's why I included this workaround for Navi12 as well.
BR,
Xiaojie
From: Koenig, Christian
Sent: Thu
On Thu, Sep 26, 2019 at 3:59 AM Luya Tshimbalanga
wrote:
>
> Hello,
>
> What is the current status of the driver or module for AMD Sensor Fusion
> HUB for mobile Raven Ridge family? To this day, majority of mobile
> powered device equipped with that APU family lacks gyroscopic function
> for the s
Check navi10_ih_get_clock_gating for the reference.
Regards,
Hawking
-Original Message-
From: Zhang, Hawking
Sent: 2019年9月26日 23:09
To: 'Kenneth Feng' ; amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth
Subject: RE: [PATCH] drm/amd/amdgpu: add IH cg support on soc15 project
We should imp
We should implement get_clock_gating callback function for IH block as well.
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Kenneth Feng
Sent: 2019年9月26日 16:48
To: amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth
Subject: [PATCH] drm/amd/amdgpu: add IH cg support on soc15
Does the older powerplay code need a similar fix?
Alex
From: amd-gfx on behalf of Wang,
Kevin(Yang)
Sent: Thursday, September 26, 2019 9:06 AM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Huang, Ray ; Feng, Kenneth
Subject: Re: [PATCH 2/2] drm/amd/power
Am 26.09.2019 15:51 schrieb Alex Deucher :
On Thu, Sep 26, 2019 at 9:47 AM Koenig, Christian
wrote:
>
> Am 26.09.19 um 15:40 schrieb Alex Deucher:
> > On Thu, Sep 26, 2019 at 8:29 AM Christian König
> > wrote:
> >> Stop, wait a second guys!
> >>
> >> This will disable the workaround for Navi10
On Thu, Sep 26, 2019 at 9:47 AM Koenig, Christian
wrote:
>
> Am 26.09.19 um 15:40 schrieb Alex Deucher:
> > On Thu, Sep 26, 2019 at 8:29 AM Christian König
> > wrote:
> >> Stop, wait a second guys!
> >>
> >> This will disable the workaround for Navi10 and that is certainly not
> >> correct:
> >>
Am 26.09.19 um 15:40 schrieb Alex Deucher:
> On Thu, Sep 26, 2019 at 8:29 AM Christian König
> wrote:
>> Stop, wait a second guys!
>>
>> This will disable the workaround for Navi10 and that is certainly not
>> correct:
>>
>> !(adev->asic_type >= CHIP_NAVI10 && adev->asic_type <= CHIP_NAVI12)
>>
>
On Thu, Sep 26, 2019 at 8:29 AM Christian König
wrote:
>
> Stop, wait a second guys!
>
> This will disable the workaround for Navi10 and that is certainly not correct:
>
> !(adev->asic_type >= CHIP_NAVI10 && adev->asic_type <= CHIP_NAVI12)
>
Actually, I think it's correct. When I merged the baco
sure, you are right, the origin design should be add this lock into these
functions,
but only add these functions can't fix this issue.
eg:
"watch -n 0 /sys/kenel/debug/dri0/amdgpu_pm_info"
16 threads run this command will cause smu error.
so this is workaound fix about sensor interface.
in fact,
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Liu, Shaoyun
Sent: Thursday, September 26, 2019 8:03 AM
To: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdkfd: use navi12 specific family id for navi12 code
path
Ping.
__
Stop, wait a second guys!
This will disable the workaround for Navi10 and that is certainly not
correct:
!(adev->asic_type >= CHIP_NAVI10 && adev->asic_type <= CHIP_NAVI12)
Christian.
Am 26.09.19 um 14:26 schrieb Deucher, Alexander:
Please add a patch description. With that fixed:
Reviewe
Please add a patch description. With that fixed:
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Yuan,
Xiaojie
Sent: Thursday, September 26, 2019 4:09 AM
To: amd-gfx@lists.freedesktop.org
Cc: alexdeuc...@gmail.com
Subject: Re: [PATCH] drm/amdgpu/gmc10: a
This patch was already reviewed-by. I think you can land it on the branch
directly.
From: amd-gfx On Behalf Of Yuan, Xiaojie
Sent: Thursday, September 26, 2019 4:09 PM
To: amd-gfx@lists.freedesktop.org
Cc: alexdeuc...@gmail.com
Subject: Re: [PATCH] drm/amdgpu/gmc10: apply the 'invalidation from
Reviewed-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Kenneth Feng
Sent: Thursday, September 26, 2019 4:48 PM
To: amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth
Subject: [PATCH] drm/amd/amdgpu: add IH cg support on soc15 project
enable/disable IH clock gating on soc15 p
How about adding the mutex protection in smu_v11_0_send_msg_with_param and
smu_v11_0_send_msg?
That seems able to simplify the code.
-Original Message-
From: amd-gfx On Behalf Of Wang,
Kevin(Yang)
Sent: Thursday, September 26, 2019 4:56 PM
To: amd-gfx@lists.freedesktop.org
Cc: Huang, Ra
The series expect patch2 and pach6 are reviewed-by: Evan Quan
-Original Message-
From: Liang, Prike
Sent: Thursday, September 26, 2019 11:50 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan ; keneth.f...@amd.com; Huang, Ray
; Liang, Prike
Subject: [PATCH 8/8] drm/amd/powerplay: up
-Original Message-
From: Liang, Prike
Sent: Thursday, September 26, 2019 11:50 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan ; keneth.f...@amd.com; Huang, Ray
; Liang, Prike
Subject: [PATCH 2/8] drm/amd/powerplay: implement the interface for setting
soft freq range
The APU sof
Ping.
From: Liu, Shaoyun
Sent: September 25, 2019 5:14:08 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Shaoyun
Subject: [PATCH] drm/amdkfd: use navi12 specific family id for navi12 code path
Keep the same use of CHIP_IDs for navi12 in kfd
Change-Id: I5e52bbc05
With the following addressed, the patch is reviewed-by: Evan Quan
-Original Message-
From: Liang, Prike
Sent: Thursday, September 26, 2019 11:50 AM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan ; keneth.f...@amd.com; Huang, Ray
; Liang, Prike
Subject: [PATCH 6/8] drm/amd/powerplay
Here's the case: the user mode driver and the tester access the sysfs
simultaneously.
That causes the message/parameter mismatch.
Reviewed-by: Kenneth Feng
-Original Message-
From: Wang, Kevin(Yang)
Sent: Thursday, September 26, 2019 4:56 PM
To: amd-gfx@lists.freedesktop.org
Cc: Huang,
Note: 1ms works for navi10 but 100ms works for navi14.
Reviewed-by: Kenneth Feng
-Original Message-
From: Wang, Kevin(Yang)
Sent: Thursday, September 26, 2019 5:14 PM
To: amd-gfx@lists.freedesktop.org
Cc: Huang, Ray ; Feng, Kenneth ; Wang,
Kevin(Yang)
Subject: [PATCH v2] drm/amd/power
v2:
change period from 10ms to 100ms (typo error)
too high frequence to update mertrics table will cause smu firmware
error,so change mertrics table update period from 1ms to 100ms
(navi10, 12, 14)
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 2 +-
1 file changed,
too high frequence to update mertrics table will cause smu firmware
error,so change mertrics table update period from 1ms to 100ms
(navi10, 12, 14)
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
when multithreading access sysfs of amdgpu_pm_info at the sametime.
the swsmu driver cause smu firmware hang.
eg:
single thread access:
Message A + Param A ==> right
Message B + Param B ==> right
Message C + Param C ==> right
multithreading access:
Message A + Param B ==> error
Message B + Param A
Reviewed-by: Kevin Wang
Best Regards,
Kevin
From: amd-gfx on behalf of Kenneth Feng
Sent: Thursday, September 26, 2019 4:47 PM
To: amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth
Subject: [PATCH] drm/amd/amdgpu: add IH cg support on soc15 project
enable/disa
enable/disable IH clock gating on soc15 projects.
Signed-off-by: Kenneth Feng
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 3 +-
drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 39 ++
.../amd/include/asic_reg/oss/osssys_4_0_sh_mask.h | 4 +++
3 files chang
Sorry this is a previous patch. Sent it wrong.
Please ignore it.
Thanks.
-Original Message-
From: Kenneth Feng [mailto:kenneth.f...@amd.com]
Sent: Thursday, September 26, 2019 4:44 PM
To: amd-gfx@lists.freedesktop.org
Cc: Feng, Kenneth
Subject: [PATCH v2] drm/amd/amdgpu: disable MMHUB P
Yes, the peak profile model just set the max frequency for SCLK/UCLK.
If not implement the interface also will fine and will use the
smu_default_set_performance_level handle it.
Thanks,
Prike
From: Wang, Kevin(Yang)
Sent: Thursday, September 26, 2019 1:20 PM
To: Liang, Prike ; amd-gfx@lists.free
Disable MMHUB PG for navi10 according to the production requirement.
Signed-off-by: Kenneth Feng
---
drivers/gpu/drm/amd/amdgpu/nv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index d4a2012..46f402a 100644
--- a/drivers/gp
Hi Alex,
This patch is to add the asic_type check which is missing after drm-next branch
rebase.
BR,
Xiaojie
From: Yuan, Xiaojie
Sent: Thursday, September 26, 2019 4:08 PM
To: amd-gfx@lists.freedesktop.org
Cc: alexdeuc...@gmail.com ; Yuan, Xiaojie
Subject: [P
Fixes: 767acabdac81 ("drm/amd/powerplay: add baco smu reset function for smu11")
Signed-off-by: Xiaojie Yuan
---
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c
index cb3f61
Hello,
What is the current status of the driver or module for AMD Sensor Fusion
HUB for mobile Raven Ridge family? To this day, majority of mobile
powered device equipped with that APU family lacks gyroscopic function
for the screen.
Thanks in advance.
--
Luya Tshimbalanga
Fedora Design Tea
On Tuesday, 2019-09-24 15:58:56 +0300, Jani Nikula wrote:
> Hi all, v2 of [1], a little refactoring around drm_debug access to
> abstract it better. There shouldn't be any functional changes.
>
> I'd appreciate acks for merging the lot via drm-misc. If there are any
> objections to that, we'll nee
Am 25.09.19 um 18:01 schrieb Alex Deucher:
On Wed, Sep 25, 2019 at 9:59 AM Koenig, Christian
wrote:
Am 25.09.19 um 15:45 schrieb Huang, Ray:
From: Alex Deucher
If a buffer object is secure, i.e. created with
AMDGPU_GEM_CREATE_ENCRYPTED, then the TMZ bit of
the PTEs that belong the buffer obj
Am 25.09.19 um 16:54 schrieb Huang, Ray:
>> -Original Message-
>> From: Koenig, Christian
>> Sent: Wednesday, September 25, 2019 10:47 PM
>> To: Huang, Ray ; amd-gfx@lists.freedesktop.org; dri-
>> de...@lists.freedesktop.org; Deucher, Alexander
>>
>> Cc: Tuikov, Luben ; Liu, Aaron
>>
>>
80 matches
Mail list logo
