this patch, i think the smu driver should be unify the driver code format,
it is very useful for optimize and maintain smu driver code in the furture.
you can reference the navi10_ppt.c and arcuturs_ppt.c
funciton: arcturus_get_workload_type
Best Regards,
Kevin
this patch is not needed for apu.
by default, the smu will use max value as peak value.
refs:smu_default_set_performance_level
Best Regards,
Kevin
From: amd-gfx on behalf of Liang, Prike
Sent: Thursday, September 26, 2019 11:50 AM
To:
comment inline.
From: amd-gfx on behalf of Liang, Prike
Sent: Thursday, September 26, 2019 11:50 AM
To: amd-gfx@lists.freedesktop.org
Cc: Liang, Prike ; Quan, Evan ; Huang,
Ray ; keneth.f...@amd.com
Subject: [PATCH 1/8] drm/amd/powerplay: bypass dpm_context
That's base function for forcing and unforcing dpm limit value.
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 62 ++
1 file changed, 62 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
Update get_dpm_uclk_limited to get more clock type full scale dpm frequency.
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 7 ---
drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 16 ++-
drivers/gpu/drm/amd/powerplay/smu_v12_0.c | 28
The APU soft freq range set by different way from DGPU, thus need implement
the function respectively base on each common SMU part.
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 25 +---
drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 3 ++
Add set_power_profile_mode() for none manual dpm level case setting power
profile mode.
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
implement get_profiling_clk_mask and force_clk_levels for forcing dpm clk to
limit value.
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 91 ++
1 file changed, 91 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
Add the interface for setting sclk and uclk peak frequency.
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 40 ++
1 file changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c
For now APU has no smu_dpm_context structure for containing default/current
related dpm tables,
thus will needn't initialize smu_dpm_context to aviod APU null pointer issue.
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 7 ---
The workload type was got from the input of power profile mode.
Signed-off-by: Prike Liang
Reviewed-by: Kevin Wang
Reviewed-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 29 +
1 file changed, 29 insertions(+)
diff --git
Reviewed-by: Yong Zhao
From: amd-gfx on behalf of Cornwall,
Jay
Sent: Wednesday, September 25, 2019 6:06 PM
To: amd-gfx@lists.freedesktop.org
Cc: Cornwall, Jay
Subject: [PATCH] drm/amdkfd: Fix race in gfx10 context restore handler
Missing synchronization
AFAIK the functionality at the I2C driver leave should be identical so
something like registers instance offset given on init should be enough.
Obviously this also requires modified registers accessor wich includes the
offset.
Andrey
From: Russell,
Missing synchronization with VGPR restore leads to intermittent
VGPR trashing in the user shader.
Signed-off-by: Jay Cornwall
---
drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler.h | 139 +++--
.../gpu/drm/amd/amdkfd/cwsr_trap_handler_gfx10.asm | 1 +
2 files changed, 71
Since we're going to be reprobing the entire topology state on resume
now using sideband transactions, we need to ensure that we actually have
short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume().
So, do that.
Changes since v4:
* Fix typo in comments
Cc: Juston Li
Cc: Imre
Hi Dave, Daniel,
More fixes for 5.4. Nothing major.
The following changes since commit e16a7cbced7110866dcde84e504909ea85099bbd:
drm/amdgpu: flag navi12 and 14 as experimental for 5.4 (2019-09-18 08:29:30
-0500)
are available in the Git repository at:
Since KFD pasid starts from 0x8000 (32768 in decimal), it is better
perceived as a hex number.
Change-Id: I565fe39f69e782749a697f18545775354c7a89f8
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 12 +--
drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c | 4
That's the fun part Working on adding checks for which chip is requested for
shared functionality, or separate functions for separated functionality.
Kent
-Original Message-
From: Grodzovsky, Andrey
Sent: Wednesday, September 25, 2019 2:11 PM
To: Russell, Kent ;
Keep the same use of CHIP_IDs for navi12 in kfd
Change-Id: I5e52bbc058be51e79553147732a571a604537b7c
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 1 +
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 2 +-
Reviewed-by: Andrey Grodzovsky
How are you planning to use them given the hard coded use of CSKVII2C
(instance zero I2C engine) in I2C controller code ?
Andrey
On 9/25/19 5:03 PM, Russell, Kent wrote:
> These are the offsets for CKSVII2C1, and match up with the values
> already added for
I think TCCs are global, because all memory traffic from gfx
engines+cp+sdma has to go through TCCs, e.g. memory requests from different
SEs accessing the same memory address go to the same TCC.
Marek
On Tue, Sep 24, 2019 at 10:58 PM Alex Deucher wrote:
> On Tue, Sep 24, 2019 at 6:29 PM Marek
These are the offsets for CKSVII2C1, and match up with the values
already added for CKSVII2C
v2: Don't remove some of the CSKVII2C values
Change-Id: I5ed88bb31253ccaf4ed4ae6f4959040c0da2f6d0
Signed-off-by: Kent Russell
---
.../asic_reg/smuio/smuio_11_0_0_offset.h | 92 +
On Wed, 2019-09-25 at 16:00 -0400, Sean Paul wrote:
> On Tue, Sep 03, 2019 at 04:45:58PM -0400, Lyude Paul wrote:
> > Yes-you read that right. Currently there is literally no locking in
> > place for any of the drm_dp_mst_port struct members that can be modified
> > in response to a link address
These are the offsets for CKSVII2C1, and match up with the values
already added for CKSVII2C
Change-Id: I5ed88bb31253ccaf4ed4ae6f4959040c0da2f6d0
Signed-off-by: Kent Russell
---
.../asic_reg/smuio/smuio_11_0_0_offset.h | 92 +
.../asic_reg/smuio/smuio_11_0_0_sh_mask.h | 192
On Wed, 2019-09-25 at 15:27 -0400, Sean Paul wrote:
> On Tue, Sep 03, 2019 at 04:45:54PM -0400, Lyude Paul wrote:
> > Since we're going to be implementing suspend/resume reprobing very soon,
> > we need to make sure we are extra careful to ensure that our locking
> > actually protects the topology
Agreed. KFD is part of amdgpu. We shouldn't use the CHIP_ IDs
differently in KFD. The code duplication is minimal and we've done it
for all chips so far. E.g. Fiji and all the Polaris versions are treated
the same in KFD. Similarly Vega10, Vega20 and Arcturus are the same for
most purposes.
From: Marek Olšák
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index ca01643fa0c8..73cd254449b3 100644
---
I think it would be cleaner to add navi12 to all of the relevant
cases. We should double check what we did for navi14 as well.
Alex
On Wed, Sep 25, 2019 at 4:09 PM Liu, Shaoyun wrote:
>
> I sent out another change that set the asic_family as CHIP_NAVI10 since from
> KFD side there is no
I sent out another change that set the asic_family as CHIP_NAVI10 since from
KFD side there is no difference for navi10 and navi12.
Regards
Shaoyun.liu
-Original Message-
From: Kuehling, Felix
Sent: Wednesday, September 25, 2019 11:23 AM
To: Liu, Shaoyun ;
On Tue, Sep 03, 2019 at 04:46:02PM -0400, Lyude Paul wrote:
> Since we're going to be reprobing the entire topology state on resume
> now using sideband transactions, we need to ensure that we actually have
> short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume().
> So, do that.
>
On Wed, 2019-09-25 at 14:16 -0400, Sean Paul wrote:
> On Tue, Sep 03, 2019 at 04:45:41PM -0400, Lyude Paul wrote:
> > When reprobing an MST topology during resume, we have to account for the
> > fact that while we were suspended it's possible that mstbs may have been
> > removed from any ports in
On Tue, Sep 03, 2019 at 04:46:00PM -0400, Lyude Paul wrote:
> In order for suspend/resume reprobing to work, we need to be able to
> perform sideband communications during suspend/resume, along with
> runtime PM suspend/resume. In order to do so, we also need to make sure
> that nouveau doesn't
On Tue, Sep 03, 2019 at 04:45:59PM -0400, Lyude Paul wrote:
> This probably hasn't caused any problems up until now since it's
> probably nearly impossible to encounter this in the wild, however if we
> were to receive a connection status notification from the MST hub after
> resume while we're in
On Tue, Sep 03, 2019 at 04:45:56PM -0400, Lyude Paul wrote:
> These are most certainly accessed from far more than the mgr work. In
> fact, up_req_recv is -only- ever accessed from outside the mgr work.
>
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Daniel
On Tue, Sep 03, 2019 at 04:45:55PM -0400, Lyude Paul wrote:
> The names for these functions are rather confusing. drm_dp_add_port()
> sounds like a function that would simply create a port and add it to a
> topology, and do nothing more. Similarly, drm_dp_update_port() would be
> assumed to be the
On Tue, Sep 03, 2019 at 04:45:54PM -0400, Lyude Paul wrote:
> Since we're going to be implementing suspend/resume reprobing very soon,
> we need to make sure we are extra careful to ensure that our locking
> actually protects the topology state where we expect it to. Turns out
> this isn't the
On Tue, Sep 03, 2019 at 04:45:52PM -0400, Lyude Paul wrote:
> Turns out we've been forgetting for a while now to actually destroy any
> of the mutexes that we create in drm_dp_mst_topology_mgr. So, let's do
> that.
>
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
>
On Tue, Sep 03, 2019 at 04:45:46PM -0400, Lyude Paul wrote:
> This will allow us to add some locking for port->* members, in
> particular the PDT and ->connector, which can't be done from
> drm_dp_destroy_port() since we don't know what locks the caller might be
> holding.
Might be nice to
Yes. I confirmed with CP guys and they said the behavior on GFX10 is the
same as GFX8 now. I remember that the workaround on GFX9 was to help
with a HW bug, but not too sure.
Regards,
Yong
On 2019-09-25 2:25 p.m., Kuehling, Felix wrote:
> On 2019-09-25 2:15 p.m., Zhao, Yong wrote:
>> The
On 2019-09-25 2:15 p.m., Zhao, Yong wrote:
> The GFX10 does not have this hardware bug any more, so remove it.
I wouldn't call this a bug and a workaround. More like a change in the
HW or FW behaviour and a corresponding driver change. I.e. in GFXv8 the
control stack was in the user mode CWSR
On Tue, Sep 03, 2019 at 04:45:42PM -0400, Lyude Paul wrote:
> Yes, apparently we've been testing this for every single driver load for
> quite a long time now. At least that means our PBN calculation is solid!
>
> Anyway, introduce self tests for MST and move this into there.
>
> Cc: Juston Li
On Tue, Sep 03, 2019 at 04:45:41PM -0400, Lyude Paul wrote:
> When reprobing an MST topology during resume, we have to account for the
> fact that while we were suspended it's possible that mstbs may have been
> removed from any ports in the topology. Since iterating downwards in the
> topology
The GFX10 does not have this hardware bug any more, so remove it.
Change-Id: I446c9685549a09ac8846a42ee22d86cfb93fd98c
Signed-off-by: Yong Zhao
---
.../gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c | 37 ++-
1 file changed, 4 insertions(+), 33 deletions(-)
diff --git
This was done on GFX9 previously, now do it for GFX10.
Change-Id: I4442e60534c59bc9526a673559f018ba8058deac
Signed-off-by: Yong Zhao
---
.../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git
The KFD code will call this function later.
Change-Id: I88a53368cdee719b2c75393e5cdbd8290584548e
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v2_0.c | 20
drivers/gpu/drm/amd/amdgpu/gfxhub_v2_0.h | 2 ++
2 files changed, 14 insertions(+), 8 deletions(-)
On Tue, Sep 03, 2019 at 04:45:40PM -0400, Lyude Paul wrote:
> This seems to be some leftover detritus from before the port/mstb kref
> cleanup and doesn't do anything anymore, so get rid of it.
>
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Reviewed-by: Daniel
On Tue, Sep 03, 2019 at 04:45:39PM -0400, Lyude Paul wrote:
> Makes things easier to read.
>
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Reviewed-by: Daniel Vetter
> Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
> ---
>
On 2019-09-25 10:54, Huang, Ray wrote:
>> -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
>>
>>
> -Original Message-
> From: amd-gfx On Behalf Of Liu,
> Shaoyun
> Sent: Wednesday, September 25, 2019 6:14 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Liu, Shaoyun
> Subject: [PATCH] drm/amdgpu: Add NAVI12 support from kfd side
>
> Add device info for both navi12 PF and VF
>
>
On Wed, Sep 25, 2019 at 9:54 AM Harry Wentland wrote:
>
>
>
> On 2019-09-25 12:23 a.m., Navid Emamdoost wrote:
> > In dcn*_create_resource_pool the allocated memory should be released if
> > construct pool fails.
> >
> > Signed-off-by: Navid Emamdoost
>
> Reviewed-by: Harry Wentland
>
Applied.
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 object should be
> > set.
You'll also need to add "case CHIP_NAVI12:" in a bunch of places. Grep
for "CHIP_NAVI10" and you'll find them all pretty quickly.
Regards,
Felix
On 2019-09-24 6:13 p.m., Liu, Shaoyun wrote:
> Add device info for both navi12 PF and VF
>
> Change-Id: Ifb4035e65c12d153fc30e593fe109f9c7e0541f4
>
On 2019-09-23 10:29 a.m., Chen, Guchun wrote:
> Hi Michel,
>
> Can you help illustrate more about using MRs to proceed libdrm changes? We
> can use gitlab to merge the change from our local forked repository to drm
> master repository?
Yes. Anybody who has write access to master can merge an
> -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
>
> Subject: Re: [PATCH v3 10/11] drm/amdgpu: job is
Am 25.09.19 um 16:38 schrieb Huang, Ray:
> Mark a job as secure, if and only if the command
> submission flag has the secure flag set.
>
> v2: fix the null job pointer while in vmid 0
> submission.
> v3: Context --> Command submission.
> v4: filling cs parser with cs->in.flags
>
> Signed-off-by:
> -Original Message-
> From: amd-gfx On Behalf Of
> Christian K?nig
> Sent: Thursday, September 19, 2019 1:43 AM
> To: amd-gfx@lists.freedesktop.org
> Subject: [PATCH] drm/amdgpu: fix error handling in amdgpu_bo_list_create
>
> We need to drop normal and userptr BOs separately.
>
>
Mark a job as secure, if and only if the command
submission flag has the secure flag set.
v2: fix the null job pointer while in vmid 0
submission.
v3: Context --> Command submission.
v4: filling cs parser with cs->in.flags
Signed-off-by: Huang Rui
Co-developed-by: Luben Tuikov
Signed-off-by:
Hi Monk,
this patch doesn't prevents PD/PT eviction.
The intention of the code here was that per VM BOs can evict other per
VM BOs during allocation.
The problem my patch fixes is that this unfortunately also meant that
allocation PDs/PTs could evict other PDs/PTs from the same process.
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 object should be
> set.
>
> v1: design and draft the skeletion of TMZ bits setting on PTEs (Alex)
Am 25.09.19 um 15:45 schrieb Huang, Ray:
> Mark a job as secure, if and only if the command
> submission flag has the secure flag set.
>
> v2: fix the null job pointer while in vmid 0
> submission.
> v3: Context --> Command submission.
>
> Signed-off-by: Huang Rui
> Co-developed-by: Luben Tuikov
On 2019-09-25 12:23 a.m., Navid Emamdoost wrote:
> In dcn*_create_resource_pool the allocated memory should be released if
> construct pool fails.
>
> Signed-off-by: Navid Emamdoost
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c | 1 +
>
Hi Christian
Theoretically the vm pt/pd should be allowed to be evicted like other BOs ..
If you encountered page fault and could be avoided by this patch, that means
there is bug in the VM/ttm system , and your patch simply
w/a the root cause.
_
Monk
This patch expands the context control function to support trusted flag while we
want to set command buffer in trusted mode.
Signed-off-by: Huang Rui
Reviewed-by: Alex Deucher
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 2 +-
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 object should be
set.
v1: design and draft the skeletion of TMZ bits setting on PTEs (Alex)
v2: return failure once create secure BO on non-TMZ
Mark a job as secure, if and only if the command
submission flag has the secure flag set.
v2: fix the null job pointer while in vmid 0
submission.
v3: Context --> Command submission.
Signed-off-by: Huang Rui
Co-developed-by: Luben Tuikov
Signed-off-by: Luben Tuikov
Reviewed-by: Alex Deucher
This patch adds tmz bit in frame control pm4 packet, and it will used in future.
Signed-off-by: Huang Rui
Reviewed-by: Alex Deucher
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/nvd.h| 1 +
drivers/gpu/drm/amd/amdgpu/soc15d.h | 1 +
2 files changed, 2 insertions(+)
diff
This patch expands the emit_tmz function to support trusted flag while we want
to set command buffer in trusted mode.
Signed-off-by: Huang Rui
Reviewed-by: Alex Deucher
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h |
Add a function to check tmz capability with kernel parameter and ASIC type.
v2: use a per device tmz variable instead of global amdgpu_tmz.
v3: refine the comments for the function. (Luben)
v4: add amdgpu_tmz.c/h for future use.
Signed-off-by: Huang Rui
Reviewed-by: Alex Deucher
---
This patch adds tmz parameter to enable/disable the feature in the amdgpu kernel
module. Nomally, by default, it should be auto (rely on the hardware
capability).
But right now, it need to set "off" to avoid breaking other developers'
work because it's not totally completed.
Will set "auto" till
From: Alex Deucher
Add a flag to the GEM_CREATE ioctl to create encrypted buffers.
Buffers with this flag set will be created with the TMZ bit set
in the PTEs or engines accessing them. This is required in order
to properly access the data from the engines.
Signed-off-by: Alex Deucher
This patch to add amdgpu_tmz structure which stores all tmz related fields.
Signed-off-by: Huang Rui
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_tmz.h | 36 +
2 files changed, 41
From: Alex Deucher
Define the TMZ (encryption) bit in the page table entry (PTE) for
Raven and newer asics.
Signed-off-by: Alex Deucher
Reviewed-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 3 +++
1 file changed, 3 insertions(+)
diff --git
From: Luben Tuikov
Add a flag to the command submission IOCTL
structure which when present indicates that this
command submission should be treated as
secure. The kernel driver uses this flag to
determine whether the engine should be
transitioned to secure or unsecure, or the work
can be
Hi all,
These series of patches introduce a feature to support secure buffer object.
The Trusted Memory Zone (TMZ) is a method to protect the contents being written
to and read from memory. We use TMZ hardware memory protection scheme to
implement the secure buffer object support.
TMZ is the
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Liu, Shaoyun
Sent: Tuesday, September 24, 2019 6:13 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Shaoyun
Subject: [PATCH] drm/amdgpu: Add NAVI12 support from kfd side
Add device info for both navi12 PF
Ping? Can I get at least and acked-by for this?
Thanks,
Christian.
Am 18.09.19 um 19:43 schrieb Christian König:
We need to drop normal and userptr BOs separately.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 7 ++-
1 file changed, 6 insertions(+),
Reviewed-by: Le Ma
-Original Message-
From: amd-gfx On Behalf Of Quan, Evan
Sent: Tuesday, September 24, 2019 12:50 PM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan
Subject: [PATCH] drm/amd/powerplay: update arcturus smu-driver interaction
header
To pair the latest SMU firmware.
Yes, I have already tested it.
Best wishes
Emily Deng
>-Original Message-
>From: Christian König
>Sent: Wednesday, September 25, 2019 5:36 PM
>To: Deng, Emily ; amd-gfx@lists.freedesktop.org
>Subject: Re: [PATCH] drm7amdgpu: once more fix
>amdgpu_bo_create_kernel_at
>
>Hi Emily,
>
Hi Emily,
have you also tested this? I don't have the hardware to test it so that
would be rather nice to have.
Thanks,
Christian.
Am 25.09.19 um 11:31 schrieb Deng, Emily:
Reviewed-by: Emily Deng
-Original Message-
From: Christian König
Sent: Tuesday, September 24, 2019 7:56 PM
Reviewed-by: Emily Deng
>-Original Message-
>From: Christian König
>Sent: Tuesday, September 24, 2019 7:56 PM
>To: Deng, Emily ; amd-gfx@lists.freedesktop.org
>Subject: [PATCH] drm7amdgpu: once more fix amdgpu_bo_create_kernel_at
>
>When CPU access is needed we should tell that to
Reviewed-by: Emily Deng
>-Original Message-
>From: Christian König
>Sent: Thursday, September 19, 2019 9:17 PM
>To: amd-gfx@lists.freedesktop.org
>Cc: Deng, Emily ; Zhang, Jack (Jian)
>
>Subject: [PATCH] drm/amdgpu: restrict hotplug error message
>
>We should print the error only when
Am 25.09.19 um 10:07 schrieb Dave Airlie:
> On Sat, 31 Mar 2018 at 06:45, Takashi Iwai wrote:
>> amdgpu driver lacks of modeset module option other drm drivers provide
>> for enforcing or disabling the driver load. Interestingly, the
>> amdgpu_mode variable declaration is already found in the
On Sat, 31 Mar 2018 at 06:45, Takashi Iwai wrote:
>
> amdgpu driver lacks of modeset module option other drm drivers provide
> for enforcing or disabling the driver load. Interestingly, the
> amdgpu_mode variable declaration is already found in the header file,
> but the actual implementation
83 matches
Mail list logo
