On Wed, Feb 26, 2020 at 3:34 PM Nirmoy Das wrote:
>
> init_priority will set second compute queue(gfx8 and gfx9) of a pipe to high
> priority
> and 1st queue to normal priority.
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 +
>
Hi Dave, Daniel,
New stuff for 5.7.
The following changes since commit 58fe03d6dec908a1bec07eea7e94907af5c07eec:
drm/amd/dm/mst: Ignore payload update failures (2020-02-04 23:30:39 -0500)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux
Hi Dave, Daniel,
Fixes for 5.6.
The following changes since commit 97d9a4e9619a822c5baf6a63e6f5b80fee4d4213:
Merge tag 'drm-intel-fixes-2020-02-20' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2020-02-21 12:46:54
+1000)
are available in the Git repository at:
On Wed, Feb 26, 2020 at 8:48 PM Emily Deng wrote:
>
> For vega10 sriov, the register is blocked, use
> copy data command to fix the issue.
>
> v2: Rename amdgpu_kiq_read_clock to gfx_v9_0_kiq_read_clock.
>
> Signed-off-by: Emily Deng
Reviewed-by: Alex Deucher
> ---
>
[AMD Official Use Only - Internal Distribution Only]
Thanks Alex and Christian. Already renamed it according your request. Please
help review.
Best wishes
Emily Deng
>-Original Message-
>From: Alex Deucher
>Sent: Wednesday, February 26, 2020 10:30 PM
>To: Deng, Emily
>Cc: amd-gfx
For vega10 sriov, the register is blocked, use
copy data command to fix the issue.
v2: Rename amdgpu_kiq_read_clock to gfx_v9_0_kiq_read_clock.
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 68 +--
1 file changed, 58 insertions(+), 10
Move the responsibility for reading argument registers into the
smu_send_smc_msg* implementations, so that adding a message-sending lock
to protect the SMU registers will result in the lock still being held
when the argument is read.
v2: transition smu_v12_0, it's asics, and vega20
Sorry for the extra email, but the mutex_init got lost when I was rebasing.
Oops.
This patchset adds a message lock to lock access to the SMU message
communication registers to prevent concurrent access.
v2: Separate navi10 change out into a separate patch, and remove mutex
definition from
The new interface reads the argument in the call to send the message, so
this is no longer needed, and shouldn't be used for concurrency safety
reasons.
Signed-off-by: Matt Coffin
---
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 1 -
drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 1 -
This adds a message lock to the smu_send_smc_msg* implementations to
protect against concurrent access to the mmu registers used to
communicate with the SMU
v2: Implement for smu_v12_0 as well
v3: Add mutex_init for message_lock
Signed-off-by: Matt Coffin
---
This patchset adds a message lock to lock access to the SMU message
communication registers to prevent concurrent access.
v2: Separate navi10 change out into a separate patch, and remove mutex
definition from first patch
For Alex's concerns, I omitted one of them, though I can re-submit if
it's
The new interface reads the argument in the call to send the message, so
this is no longer needed, and shouldn't be used for concurrency safety
reasons.
Signed-off-by: Matt Coffin
---
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 1 -
drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 1 -
This adds a message lock to the smu_send_smc_msg* implementations to
protect against concurrent access to the mmu registers used to
communicate with the SMU
v2: Implement for smu_v12_0 as well
Signed-off-by: Matt Coffin
---
drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h | 1 +
Move the responsibility for reading argument registers into the
smu_send_smc_msg* implementations, so that adding a message-sending lock
to protect the SMU registers will result in the lock still being held
when the argument is read.
v2: transition smu_v12_0, it's asics, and vega20
I was thinking like something like this, Ray.
It optimizes the body of the loop, and pulls
out invariant conditionals out of the loop,
and a few other optimizations.
Luben Tuikov (1):
drm/amdgpu: Fix per-IB secure flag GFX hang
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 87
Since commit "Move to a per-IB secure flag (TMZ)",
we've been seeing hangs in GFX. Ray H. pointed out
by sending a patch that we need to send FRAME
CONTROL stop/start back-to-back, every time we
flip the TMZ flag as per each IB we submit. That
is, when we transition from TMZ to non-TMZ we have
to
Removes codestyle issues on detect_dp function as suggested by
checkpatch.pl.
CHECK: Lines should not end with a '('
WARNING: Missing a blank line after declarations
WARNING: line over 80 characters
CHECK: Alignment should match open parenthesis
Signed-off-by: Melissa Wen
---
Coding style clean up on enable_link_dp function as suggested by
checkpatch.pl:
CHECK: Lines should not end with a '('
WARNING: line over 80 characters
WARNING: suspect code indent for conditional statements (8, 24)
CHECK: braces {} should be used on all arms of this statement
ERROR: else should
This patchset solves some coding style issues on dc_link for readability
and cleaning up warnings. Change suggested by checkpatch.pl.
Melissa Wen (2):
drm/amd/display: dc_link: code clean up on enable_link_dp function
drm/amd/display: dc_link: code clean up on detect_dp function
Because too many things are involved in this workaround, we need more
comments to avoid pitfalls.
Change-Id: I5d7917296dd5f5edb45921118cf8e7d778d40de1
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 5 -
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c | 17
Because two many things are involved in this workaround, we need more
comments to avoid pitfalls.
Change-Id: I5d7917296dd5f5edb45921118cf8e7d778d40de1
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 5 -
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c | 16
On 2020-02-26 14:37, Eric Huang wrote:
SDMA MQD memory type is NC that causes MQD data overwritten
accidentally by an old stable cache line. Changing it to UC
default for GART will fix the issue.
Maybe add a statement here, that the mqd_gfx9 parameter is meant for
control stacks that are
This is my initial idea which sets half compute queues to normal priority and
other half to high priority. I am reusing existing set_priority codes
here.
My understanding of gfx_v*_0_pipe_reserve_resources is very low so I am
probably doing some mistake at init_priority()
Nirmoy Das (3):
Remove unused amdgpu_ring_priority_put() and amdgpu_ring_priority_get()
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 70
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 4 --
2 files changed, 74 deletions(-)
diff --git
[AMD Official Use Only - Internal Distribution Only]
It looks good to me. I was thinking maybe we should go one step further, adding
more explanation comments around the MQD control stack workaround, so that
people have a clearer idea of what's that MQD control stack workaround is
about. We
init_priority will set second compute queue(gfx8 and gfx9) of a pipe to high
priority
and 1st queue to normal priority.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 +
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 14 ++
We were changing compute ring priority while rings were being used
before every job submission which is not recommended. This patch
recreates entity with higher/normal priority sched list when user
changes ctx's priority.
high/normal priority sched list are generated from set of high/normal
SDMA MQD memory type is NC that causes MQD data overwritten
accidentally by an old stable cache line. Changing it to UC
default for GART will fix the issue.
Change-Id: If609f47c78cb97e2c8dc930df2ab5c10c29dfe56
Signed-off-by: Eric Huang
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c |
The CAP fw is for enabling driver compatibility. Currently, it only
enabled for vega10 VF.
Signed-off-by: Zhigang Luo
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 9 +++-
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.h | 3 ++-
The drm resource being limited here is the GEM buffer objects. User
applications allocate and free these buffers. In addition, a process
can allocate a buffer and share it with another process. The consumer
of a shared buffer can also outlive the allocator of the buffer.
For the purpose of
gpu.buffer.count.stats
A read-only flat-keyed file which exists on all cgroups. Each
entry is keyed by the drm device's major:minor.
Total number of GEM buffer allocated.
Change-Id: Iad29bdf44390dbcee07b1e72ea0ff811aa3b9dcd
Signed-off-by: Kenny Ho
---
gpu.buffer.peak.stats
A read-only flat-keyed file which exists on all cgroups. Each
entry is keyed by the drm device's major:minor.
Largest (high water mark) GEM buffer allocated in bytes.
Change-Id: I40fe4c13c1cea8613b3e04b802f3e1f19eaab4fc
Signed-off-by: Kenny Ho
---
gpu.buffer.peak.default
A read-only flat-keyed file which exists on the root cgroup.
Each entry is keyed by the drm device's major:minor.
Default limits on the largest GEM buffer allocation in bytes.
gpu.buffer.peak.max
A read-write flat-keyed file which exists on
The number of compute unit (CU) for a device is used for the gpu cgroup
compute capacity. The gpu cgroup compute allocation limit only applies
to compute workload for the moment (enforced via kfd queue creation.)
Any cu_mask update is validated against the availability of the compute
unit as
drmcg initialization involves allocating a per cgroup, per device data
structure and setting the defaults. There are two entry points for
drmcg init:
1) When struct drmcg is created via css_alloc, initialization is done
for each device
2) When DRM devices are created after drmcgs are created
gpu.compute.weight
A read-write flat-keyed file which exists on all cgroups. The
default weight is 100. Each entry is keyed by the DRM device's
major:minor (the primary minor). The weights are in the range [1,
1] and specifies the relative amount of physical
Before this commit, drmcg limits are updated but enforcement is delayed
until the next time the driver check against the new limit. While this
is sufficient for certain resources, a more proactive enforcement may be
needed for other resources.
Introducing an optional drmcg_limit_updated callback
With the increased importance of machine learning, data science and
other cloud-based applications, GPUs are already in production use in
data centers today. Existing GPU resource management is very coarse
grain, however, as sysadmins are only able to distribute workload on a
per-GPU basis. An
This is a submission for the introduction of a new cgroup controller for the
drm subsystem follow a series of RFCs [v1, v2, v3, v4]
Changes from PR v1
* changed cgroup controller name from drm to gpu
* removed lgpu
* added compute.weight resources, clarified resources being distributed as
The drm resource being measured here is the GEM buffer objects. User
applications allocate and free these buffers. In addition, a process
can allocate a buffer and share it with another process. The consumer
of a shared buffer can also outlive the allocator of the buffer.
For the purpose of
Since the drm subsystem can be compiled as a module and drm devices can
be added and removed during run time, add several functions to bind the
drm subsystem as well as drm devices with drmcg.
Two pairs of functions:
drmcg_bind/drmcg_unbind - used to bind/unbind the drm subsystem to the
cgroup
[AMD Official Use Only - Internal Distribution Only]
Series is:
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Yong Zhao
Sent: Wednesday, February 26, 2020 12:58 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhao, Yong
Subject: [PATCH 2/2] drm/amdkfd: Make
I'll push it out today. Thanks!
Alex
From: Kuehling, Felix
Sent: Wednesday, February 26, 2020 12:49 PM
To: Pan, Xinhui ; Deucher, Alexander
Cc: amd-gfx@lists.freedesktop.org
Subject: RE: linux-next: Tree for Feb 26 (gpu/drm/amd/amdgpu/)
[AMD Official Use
Given we can query all the asic specific information from amdgpu_gfx_config,
we can make get_tile_config() generic.
Change-Id: I1080fec4d50c51bc84bb49b0145f8fec50081fce
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 3 ++
The two members will be used by KFD later.
Change-Id: I36a605e359b242f2fe546fb67f8e402c48a62342
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 2 ++
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 5 +
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 5 +
3 files changed, 12
[AMD Official Use Only - Internal Distribution Only]
I pushed the fix to amd-staging-drm-next. How do we get this into linux-next?
-Original Message-
From: Kuehling, Felix
Sent: Wednesday, February 26, 2020 11:11
To: Pan, Xinhui ; Deucher, Alexander
(alexander.deuc...@amd.com)
Cc:
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Yong Zhao
From: amd-gfx on behalf of Felix
Kuehling
Sent: Wednesday, February 26, 2020 12:12 PM
To: amd-gfx@lists.freedesktop.org ; Deucher,
Alexander
Cc: Pan, Xinhui
Subject: [PATCH 1/1]
Add a dummy implementation of amdgpu_amdkfd_remove_fence_on_pt_pd_bos
for kernel configs without KFD.
Fixes: be8e48e08499 ("drm/amdgpu: Remove kfd eviction fence before release bo")
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 5 +
1 file changed, 5
[AMD Official Use Only - Internal Distribution Only]
[Dropping most, +Alex, +Xinhui]
Looks like this was introduced by Xinhui's change:
commit be8e48e0849943fb53457e2fd83905eaf19cb1f7
Author: xinhui pan
Date: Tue Feb 11 11:28:34 2020 +0800
drm/amdgpu: Remove kfd eviction fence before
[AMD Public Use]
That's fine we can take care of testing other platforms.
Thanks,
Alex
From: amd-gfx on behalf of Matt Coffin
Sent: Tuesday, February 25, 2020 7:03 PM
To: Alex Deucher
Cc: Das, Nirmoy ; amd-gfx list
Subject: Re: [PATCH 1/2]
On 2020-02-25 18:40, Luben Tuikov wrote:
> On 2020-02-25 8:57 a.m., Huang Rui wrote:
>> Since 6643ba1 frame control packets are only issued in presence of secure
>> IB(s).
>> This causes hangs on some hardware (eg: Raven1). This patch restores the
>> unconditionnal frame control packets issuing,
On 2/25/20 8:34 PM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20200225:
>
on i386:
ld: drivers/gpu/drm/amd/amdgpu/amdgpu_object.o: in function
`amdgpu_bo_release_notify':
amdgpu_object.c:(.text+0xe07): undefined reference to
`amdgpu_amdkfd_remove_fence_on_pt_pd_bos'
Full
Am 26.02.20 um 15:29 schrieb Alex Deucher:
On Tue, Feb 25, 2020 at 11:34 PM Emily Deng wrote:
For vega10 sriov, the register is blocked, use
copy data command to fix the issue.
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 68 +--
1
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Jerry (Fangzhi) Zuo
-Original Message-
From: Alex Deucher
Sent: February 26, 2020 10:40 AM
To: Zuo, Jerry
Cc: Liu, Zhan ; Wentland, Harry ;
amd-gfx list ; Maling list - DRI developers
; Deucher, Alexander
;
On Wed, Feb 26, 2020 at 10:36 AM Zuo, Jerry wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> Hi Alex:
>
> The patch set works. Please let me know when you push the change to
> drm-next.
Can someone give me and R-b or A-b on the patches?
Thanks,
Alex
>
> Thanks a
[AMD Official Use Only - Internal Distribution Only]
Hi Alex:
The patch set works. Please let me know when you push the change to
drm-next.
Thanks a lot.
Regards,
Jerry
-Original Message-
From: Alex Deucher
Sent: February 25, 2020 1:42 PM
To: Zuo, Jerry
Cc: Liu, Zhan ;
On Tue, Feb 25, 2020 at 11:34 PM Emily Deng wrote:
>
> For vega10 sriov, the register is blocked, use
> copy data command to fix the issue.
>
> Signed-off-by: Emily Deng
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 68
> +--
> 1 file changed, 58
On Wed, Feb 26, 2020 at 8:30 AM Christian König
wrote:
>
> Am 25.02.20 um 20:12 schrieb Christian König:
> > Am 25.02.20 um 20:11 schrieb Alex Deucher:
> >> On Tue, Feb 25, 2020 at 2:09 PM Christian König
> >> wrote:
> >>> Am 25.02.20 um 19:56 schrieb Alex Deucher:
> From: Ahzo
>
>
On Tue, Feb 25, 2020 at 9:46 PM Rohit Khaire wrote:
>
> This change programs CP_ME_CNTL and RLC_CSIB_* through RLC
>
> Signed-off-by: Rohit Khaire
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff
On Wed, Feb 26, 2020 at 2:30 PM Christian König
wrote:
>
> Am 25.02.20 um 20:12 schrieb Christian König:
> > Am 25.02.20 um 20:11 schrieb Alex Deucher:
> >> On Tue, Feb 25, 2020 at 2:09 PM Christian König
> >> wrote:
> >>> Am 25.02.20 um 19:56 schrieb Alex Deucher:
> From: Ahzo
>
>
Am 25.02.20 um 20:12 schrieb Christian König:
Am 25.02.20 um 20:11 schrieb Alex Deucher:
On Tue, Feb 25, 2020 at 2:09 PM Christian König
wrote:
Am 25.02.20 um 19:56 schrieb Alex Deucher:
From: Ahzo
Set the drm_device to NULL, so that the newly created buffer object
doesn't appear to use
Reviewed-by: Monk Liu
_
Monk Liu|GPU Virtualization Team |AMD
-Original Message-
From: amd-gfx On Behalf Of Emily Deng
Sent: Wednesday, February 26, 2020 12:34 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deng, Emily
Subject: [PATCH] drm/amdgpu/sriov:
62 matches
Mail list logo
