From: tiancyin
update the smu11_driver_if_navi10.h since navi10 smu fw
update to 42.28
Signed-off-by: tiancyin
---
drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_navi10.h | 6 +++---
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 2 +-
2 files changed, 4 insertions(+), 4 delet
On Wed, Jun 26, 2019 at 06:52:50PM -0400, Kenny Ho wrote:
> Ok. I am not too familiar with shrinker but I will dig into it. Just
> so that I am looking into the right things, you are referring to
> things like struct shrinker and struct shrink_control?
Yeah. Reason I'm asking for this is this is
On Thu, Jun 27, 2019 at 12:34:05AM -0400, Kenny Ho wrote:
> On Wed, Jun 26, 2019 at 12:25 PM Daniel Vetter wrote:
> >
> > On Wed, Jun 26, 2019 at 11:05:20AM -0400, Kenny Ho wrote:
> > > The bandwidth is measured by keeping track of the amount of bytes moved
> > > by ttm within a time period. We d
On Thu, Jun 27, 2019 at 12:06:13AM -0400, Kenny Ho wrote:
> On Wed, Jun 26, 2019 at 12:12 PM Daniel Vetter wrote:
> >
> > On Wed, Jun 26, 2019 at 11:05:18AM -0400, Kenny Ho wrote:
> > > drm.memory.stats
> > > A read-only nested-keyed file which exists on all cgroups.
> > > Each ent
On Wed, Jun 26, 2019 at 06:41:32PM -0400, Kenny Ho wrote:
> On Wed, Jun 26, 2019 at 5:41 PM Daniel Vetter wrote:
> > On Wed, Jun 26, 2019 at 05:27:48PM -0400, Kenny Ho wrote:
> > > On Wed, Jun 26, 2019 at 12:05 PM Daniel Vetter wrote:
> > > > So what happens when you start a lot of threads all at
On Wed, Jun 26, 2019 at 12:25 PM Daniel Vetter wrote:
>
> On Wed, Jun 26, 2019 at 11:05:20AM -0400, Kenny Ho wrote:
> > The bandwidth is measured by keeping track of the amount of bytes moved
> > by ttm within a time period. We defined two type of bandwidth: burst
> > and average. Average bandwi
On Wed, Jun 26, 2019 at 12:12 PM Daniel Vetter wrote:
>
> On Wed, Jun 26, 2019 at 11:05:18AM -0400, Kenny Ho wrote:
> > drm.memory.stats
> > A read-only nested-keyed file which exists on all cgroups.
> > Each entry is keyed by the drm device's major:minor. The
> > followin
On Thu, 27 Jun 2019 at 13:07, Dave Airlie wrote:
>
> Thanks,
>
> I've pulled this, but it introduced one warning
>
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c: In
> function ‘vcn_v2_0_start_dpg_mode’:
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/amd/amdgpu/v
I do not think this is a good idea.
As there is still some cases that version mismatch will cause unexpected
issues. And they will be hard to debug.
If this is for debug purpose only, I would suggest to keep this in your custom
branch only.
Regards,
Evan
> -Original Message-
> From: amd
Ok. I am not too familiar with shrinker but I will dig into it. Just
so that I am looking into the right things, you are referring to
things like struct shrinker and struct shrink_control?
Regards,
Kenny
On Wed, Jun 26, 2019 at 12:44 PM Daniel Vetter wrote:
>
> On Wed, Jun 26, 2019 at 11:05:22
On Wed, Jun 26, 2019 at 5:41 PM Daniel Vetter wrote:
> On Wed, Jun 26, 2019 at 05:27:48PM -0400, Kenny Ho wrote:
> > On Wed, Jun 26, 2019 at 12:05 PM Daniel Vetter wrote:
> > > So what happens when you start a lot of threads all at the same time,
> > > allocating gem bo? Also would be nice if we
From: Marek Olšák
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 6baaa65a1daa..5b807a19bbbf 100644
--- a/drivers/g
From: Marek Olšák
v2: update emit_ib_size
(though it's still wrong because it was wrong before)
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gds.h | 3 ++-
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 14 +++---
2 files changed, 13 insertions(+), 4 deletions(-)
diff
On 2019-06-26 11:22 a.m., Zeng, Oak wrote:
> Set default value of this kernel parameter to 9000
>
> Change-Id: If91db4d2c2ac08e25d7728d49629cbaec0d6c773
> Signed-off-by: Oak Zeng
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
> 1 file changed, 1 insertion(+
On Wed, Jun 26, 2019 at 5:04 PM Daniel Vetter wrote:
> On Wed, Jun 26, 2019 at 10:37 PM Kenny Ho wrote:
> > (sending again, I keep missing the reply-all in gmail.)
> You can make it the default somewhere in the gmail options.
Um... interesting, my option was actually not set (neither reply or rep
On Wed, Jun 26, 2019 at 05:27:48PM -0400, Kenny Ho wrote:
> On Wed, Jun 26, 2019 at 12:05 PM Daniel Vetter wrote:
> >
> > > drm.buffer.default
> > > A read-only flat-keyed file which exists on the root cgroup.
> > > Each entry is keyed by the drm device's major:minor.
> > >
> > >
On Wed, Jun 26, 2019 at 12:05 PM Daniel Vetter wrote:
>
> > drm.buffer.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 total GEM buffer allocation in bytes.
>
> D
On Wed, Jun 26, 2019 at 10:37 PM Kenny Ho wrote:
> (sending again, I keep missing the reply-all in gmail.)
You can make it the default somewhere in the gmail options.
(also resending, I missed that you didn't group-replied).
On Wed, Jun 26, 2019 at 10:25 PM Kenny Ho wrote:
>
> On Wed, Jun 26,
(sending again, I keep missing the reply-all in gmail.)
On Wed, Jun 26, 2019 at 11:56 AM Daniel Vetter wrote:
>
> Why the separate, explicit registration step? I think a simpler design for
> drivers would be that we set up cgroups if there's anything to be
> controlled, and then for GEM drivers t
On Wed, Jun 26, 2019 at 9:35 PM Kenny Ho wrote:
>
> On Wed, Jun 26, 2019 at 11:49 AM Daniel Vetter wrote:
> >
> > Bunch of naming bikesheds
>
> I appreciate the suggestions, naming is hard :).
>
> > > +#include
> > > +
> > > +struct drmcgrp {
> >
> > drm_cgroup for more consistency how we usuall
On Wed, Jun 26, 2019 at 11:49 AM Daniel Vetter wrote:
>
> Bunch of naming bikesheds
I appreciate the suggestions, naming is hard :).
> > +#include
> > +
> > +struct drmcgrp {
>
> drm_cgroup for more consistency how we usually call these things.
I was hoping to keep the symbol short if possible
On 6/24/19 8:32 AM, Andrey Konovalov wrote:
> This patch is a part of a series that extends kernel ABI to allow to pass
> tagged user pointers (with the top byte set to something else other than
> 0x00) as syscall arguments.
>
> In radeon_gem_userptr_ioctl() an MMU notifier is set up with a (tagge
Reviewed-by: Andrey Grodzovsky
Andrey
On 6/26/19 1:50 PM, Liu, Shaoyun wrote:
> In XGMI configuration, more than one asic can be reset at same time,
> kfd is able to handle this and no need to trigger the warning
>
> Change-Id: If339503860e86ee1dbeed294ba1c103fcce70b7b
> Signed-off-by: shaoyunl
In XGMI configuration, more than one asic can be reset at same time,
kfd is able to handle this and no need to trigger the warning
Change-Id: If339503860e86ee1dbeed294ba1c103fcce70b7b
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 -
1 file changed, 1 deletion(-)
diff -
Hi Andrew,
On Mon, Jun 24, 2019 at 04:32:45PM +0200, Andrey Konovalov wrote:
> Andrey Konovalov (14):
> arm64: untag user pointers in access_ok and __uaccess_mask_ptr
> lib: untag user pointers in strn*_user
> mm: untag user pointers passed to memory syscalls
> mm: untag user pointers in m
On Wed, Jun 26, 2019 at 11:05:22AM -0400, Kenny Ho wrote:
> Allow DRM TTM memory manager to register a work_struct, such that, when
> a drmcgrp is under memory pressure, memory reclaiming can be triggered
> immediately.
>
> Change-Id: I25ac04e2db9c19ff12652b88ebff18b44b2706d8
> Signed-off-by: Kenn
On Wed, Jun 26, 2019 at 11:05:20AM -0400, Kenny Ho wrote:
> The bandwidth is measured by keeping track of the amount of bytes moved
> by ttm within a time period. We defined two type of bandwidth: burst
> and average. Average bandwidth is calculated by dividing the total
> amount of bytes moved w
On Wed, Jun 26, 2019 at 11:05:19AM -0400, Kenny Ho wrote:
> drm.memory.peak.stats
> A read-only nested-keyed file which exists on all cgroups.
> Each entry is keyed by the drm device's major:minor. The
> following nested keys are defined.
>
> == =
On Wed, Jun 26, 2019 at 11:05:18AM -0400, Kenny Ho wrote:
> The drm resource being measured is the TTM (Translation Table Manager)
> buffers. TTM manages different types of memory that a GPU might access.
> These memory types include dedicated Video RAM (VRAM) and host/system
> memory accessible t
On Wed, Jun 26, 2019 at 11:05:15AM -0400, Kenny Ho wrote:
> The drm resource being measured and 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 share
On Wed, Jun 26, 2019 at 11:05:13AM -0400, Kenny Ho wrote:
> Change-Id: I908ee6975ea0585e4c30eafde4599f87094d8c65
> Signed-off-by: Kenny Ho
Why the separate, explicit registration step? I think a simpler design for
drivers would be that we set up cgroups if there's anything to be
controlled, and t
On Wed, Jun 26, 2019 at 11:05:12AM -0400, Kenny Ho wrote:
Needs a bit more commit message here I htink.
> Change-Id: I6830d3990f63f0c13abeba29b1d330cf28882831
> Signed-off-by: Kenny Ho
Bunch of naming bikesheds
> ---
> include/linux/cgroup_drm.h| 76 +++
> in
Acked-by: Alex Deucher
From: Zeng, Oak
Sent: Wednesday, June 26, 2019 11:22 AM
To: amd-gfx@lists.freedesktop.org
Cc: Kuehling, Felix; Deucher, Alexander; Li, Candice; Zeng, Oak
Subject: [PATCH] drm/amdgpu: Set queue_preemption_timeout_ms default value
Set default
Set default value of this kernel parameter to 9000
Change-Id: If91db4d2c2ac08e25d7728d49629cbaec0d6c773
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/d
drm.memory.peak.stats
A read-only nested-keyed file which exists on all cgroups.
Each entry is keyed by the drm device's major:minor. The
following nested keys are defined.
== ==
system Pea
The drm resource being measured is the TTM (Translation Table Manager)
buffers. TTM manages different types of memory that a GPU might access.
These memory types include dedicated Video RAM (VRAM) and host/system
memory accessible through IOMMU (GART/GTT). TTM is currently used by
multiple drm dr
The drm resource being limited is the TTM (Translation Table Manager)
buffers. TTM manages different types of memory that a GPU might access.
These memory types include dedicated Video RAM (VRAM) and host/system
memory accessible through IOMMU (GART/GTT). TTM is currently used by
multiple drm dri
Allow DRM TTM memory manager to register a work_struct, such that, when
a drmcgrp is under memory pressure, memory reclaiming can be triggered
immediately.
Change-Id: I25ac04e2db9c19ff12652b88ebff18b44b2706d8
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/ttm/ttm_bo.c| 47 ++
The bandwidth is measured by keeping track of the amount of bytes moved
by ttm within a time period. We defined two type of bandwidth: burst
and average. Average bandwidth is calculated by dividing the total
amount of bytes moved within a cgroup by the lifetime of the cgroup.
Burst bandwidth is s
Change-Id: I3750fc657b956b52750a36cb303c54fa6a265b44
Signed-off-by: Kenny Ho
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index da7b4fe8ade3..2568fd730161 1006
drm.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: Id3e1809d5fee8562e47a7d2b961688956d844ec6
Signed-off-by: Kenny Ho
---
include/linux/cgro
This is a follow up to the RFC I made previously to introduce a cgroup
controller for the GPU/DRM subsystem [v1,v2]. The goal is to be able to
provide resource management to GPU resources using things like container.
The cover letter from v1 is copied below for reference.
[v1]: https://lists.free
drm.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 GEM buffer allocated in bytes.
drm.buffer.peak.default
A read-only flat-keyed file which exists on the root cgroup.
The drm resource being measured and 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 pu
Change-Id: I6830d3990f63f0c13abeba29b1d330cf28882831
Signed-off-by: Kenny Ho
---
include/linux/cgroup_drm.h| 76 +++
include/linux/cgroup_subsys.h | 4 ++
init/Kconfig | 5 +++
kernel/cgroup/Makefile| 1 +
kernel/cgroup/drm.c
Change-Id: I908ee6975ea0585e4c30eafde4599f87094d8c65
Signed-off-by: Kenny Ho
---
include/drm/drm_cgroup.h | 24
include/linux/cgroup_drm.h | 10
kernel/cgroup/drm.c| 116 +
3 files changed, 150 insertions(+)
create mode 100644 include
Should prevent flicker if PP_OVERDRIVE_MASK is set.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=102646
bug: https://bugs.freedesktop.org/show_bug.cgi?id=108941
Signed-off-by: Sergei Lopatin
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 5 -
1 file changed, 4 insertions(+), 1
On 26/06/2019 14:25, Daniel Stone wrote:
> Hi Colin,
>
> On Wed, 26 Jun 2019 at 14:24, Colin King wrote:
>> There are a couple of spelling mistakes in dm_error messages and
>> a comment. Fix these.
>
> Whilst there, you might fix the '[next[' typo in the commit message.
Ugh, fickle fingers. May
Hi Colin,
On Wed, 26 Jun 2019 at 14:24, Colin King wrote:
> There are a couple of spelling mistakes in dm_error messages and
> a comment. Fix these.
Whilst there, you might fix the '[next[' typo in the commit message.
Cheers,
Daniel
From: Colin Ian King
There are a couple of spelling mistakes in dm_error messages and
a comment. Fix these.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c | 2 +-
drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c | 8
2 files changed, 5 insertions(+)
On Wed, Jun 26, 2019 at 02:23:05PM +0200, Christian König wrote:
> On the exporter side we add optional explicit pinning callbacks. If those
> callbacks are implemented the framework no longer caches sg tables and the
> map/unmap callbacks are always called with the lock of the reservation object
>
Instead of relying on the DRM functions just implement our own import
functions. This prepares support for taking care of unpinned DMA-buf.
v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
v3: change to new dma_buf attach
This way we can even pipeline imported BO evictions.
v2: Limit this to only cases when the parent object uses a separate
reservation object as well. This fixes another OOM problem.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 20 +++-
1 file changed
Pipeline removal of the BOs backing store when no placement is given
during validation.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c7de667d482a
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called with the lock of the reservation object
held.
On the importer side we add an optional invalidate callback. This
Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/
The caching of SGT's is actually quite harmful and should probably removed
altogether when all drivers are audited.
Start by providing a separate DMA-buf export implementation in amdgpu.
This is also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugging lefto
On Wed, Jun 26, 2019 at 1:53 PM Christian König
wrote:
>
> [SNIP]
> > I'm confused here: Atm ->moving isn't in resv_obj, there's only one
> >>> exclusive fence. And yes you need to set that every time you do a move
> >>> (because a move needs to be pretty exclusive access). But I'm not seeing
[SNIP]
I'm confused here: Atm ->moving isn't in resv_obj, there's only one
exclusive fence. And yes you need to set that every time you do a move
(because a move needs to be pretty exclusive access). But I'm not seeing a
separate not_quite_exclusive fence slot for moves.
Yeah, but shouldn't tha
Reviewed-by: Kevin Wang
On 6/25/19 3:43 PM, Prike Liang wrote:
> The mutex for procting SMU during hw_init was removed as system
> will be deadlock when smu_populate_umd_state_clk try get SMU mutex.
> Therefore need remove the residual mutex from failed path.
>
> Change-Id: Id8019c01b9496c067efd
Reviewed-by: Kevin Wang
Best Regards,
Kevin
On 6/25/19 9:58 PM, Alex Deucher wrote:
> ULL is needed for 32 bit arches.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 2 +-
> drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 2 +-
> 2 files changed, 2 inserti
On 2019/6/25 1:42, Kim, Jonathan wrote:
> Immediate return should be ok since perf registration isn't dependent on gpu
> hw.
>
> Reviewed-by: Jonathan Kim
thanks for review.
>
> -Original Message-
> From: Mao Wenan
> Sent: Monday, June 24, 2019 7:23 AM
> To: airl...@linux.ie; dan
On Wed, Jun 26, 2019 at 11:28 AM Koenig, Christian
wrote:
>
> Am 26.06.19 um 10:17 schrieb Daniel Vetter:
> > On Wed, Jun 26, 2019 at 09:49:03AM +0200, Christian König wrote:
> >> Am 25.06.19 um 18:05 schrieb Daniel Vetter:
> >>> On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
> >
On 2019-06-26 9:04 a.m., Kuehling, Felix wrote:
> On 2019-06-26 2:54 a.m., Koenig, Christian wrote:
>> Am 26.06.19 um 08:40 schrieb Kuehling, Felix:
>>> Returning -EAGAIN prevents ttm_bo_mem_space from trying alternate
>>> placements and can lead to live-locks in amdgpu_cs, retrying
>>> indefinitel
Am 26.06.19 um 10:17 schrieb Daniel Vetter:
> On Wed, Jun 26, 2019 at 09:49:03AM +0200, Christian König wrote:
>> Am 25.06.19 um 18:05 schrieb Daniel Vetter:
>>> On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
On the exporter side we add optional explicit pinning callbacks. If
On Wed, Jun 26, 2019 at 07:10:21AM +, Koenig, Christian wrote:
> Those patches would become superfluous when merging Gerd's work.
Not entirely, they still remove the gem_prime_res_obj. Setting up
gem_bo.resv is only one half of what these do here. And yeah I think that
single addition can be r
On Wed, Jun 26, 2019 at 09:49:03AM +0200, Christian König wrote:
> Am 25.06.19 um 18:05 schrieb Daniel Vetter:
> > On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
> > > On the exporter side we add optional explicit pinning callbacks. If those
> > > callbacks are implemented the fra
Am 25.06.19 um 18:05 schrieb Daniel Vetter:
On Tue, Jun 25, 2019 at 02:46:49PM +0200, Christian König wrote:
On the exporter side we add optional explicit pinning callbacks. If those
callbacks are implemented the framework no longer caches sg tables and the
map/unmap callbacks are always called
Those patches would become superfluous when merging Gerd's work.
But I'm not sure if that is going to fly soon or not.
Christian.
Am 25.06.19 um 22:42 schrieb Daniel Vetter:
> That way we can ditch our gem_prime_res_obj implementation. Since ttm
> absolutely needs the right reservation object al
On 2019-06-26 2:54 a.m., Koenig, Christian wrote:
> Am 26.06.19 um 08:40 schrieb Kuehling, Felix:
>> Returning -EAGAIN prevents ttm_bo_mem_space from trying alternate
>> placements and can lead to live-locks in amdgpu_cs, retrying
>> indefinitely and never succeeding.
>>
>> Fixes: cfcc52e477e4 ("dr
70 matches
Mail list logo
