From: Dmytro Laktyushkin
This change adds EMP packet programming for enabling dsc with
hdmi. The packets are structured according to VESA HDMI 2.1x
r2 spec, section 10.10.2.2.
Signed-off-by: Dmytro Laktyushkin
Reviewed-by: Charlene Liu
Acked-by: Leo Li
---
From: David Galiffi
[WHY]
TRAINING_AUX_RD_INTERVAL (DPCD 000Eh) modifies the read interval
for the EQ training sequence. CR read interval should remain 100 us.
Currently, the CR interval is also being modified.
[HOW]
lt_settings->cr_pattern_time should always be 100 us.
Signed-off-by: David
From: Dmytro Laktyushkin
A regression caused dsc to never get disabled in certain situations.
Signed-off-by: Dmytro Laktyushkin
Reviewed-by: Nikola Cornij
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff
From: David Galiffi
[WHY]
To add support for OS requirement to set preferred link training
parameters.
[HOW]
Create new structure of dp link training overrides. During link training
processes, these values should be used instead of the default training
parameters.
Signed-off-by: David Galiffi
From: Aric Cyr
Signed-off-by: Aric Cyr
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index e513028faefa..2a7f25d372e1 100644
---
Be less pessimistic about estimated page table use for KFD. Most
allocations use 2MB pages and therefore need less VRAM for page
tables. This allows more VRAM to be used for applications especially
on large systems with many GPUs and hundreds of GB of system memory.
Example: 8 GPUs with 32GB VRAM
Am 15.07.19 um 18:12 schrieb Alex Deucher:
On Sat, Jul 13, 2019 at 2:43 AM Kuehling, Felix wrote:
When starting a new mm_node, the page_offset becomes 0.
Signed-off-by: Felix Kuehling
Reviewed-by: Alex Deucher
Reviewed-by: Christian König
---
On Mon, Jul 15, 2019 at 06:01:29PM +0200, Andrey Konovalov wrote:
> On Mon, Jun 24, 2019 at 7:40 PM Catalin Marinas
> wrote:
> >
> > On Mon, Jun 24, 2019 at 04:32:56PM +0200, Andrey Konovalov wrote:
> > > This patch is a part of a series that extends kernel ABI to allow to pass
> > > tagged user
On Mon, Jul 15, 2019 at 06:51:06PM +0200, Michel Dänzer wrote:
>
> With a KASAN enabled kernel built from amd-staging-drm-next, the
> attached use-after-free is pretty reliably detected during a piglit gpu run.
Does this branch you are testing have the hmm.git merged? I think from
the name it
With a KASAN enabled kernel built from amd-staging-drm-next, the
attached use-after-free is pretty reliably detected during a piglit gpu run.
Any ideas?
P.S. With my standard kernels without KASAN (currently 5.2.y + drm-next
changes for 5.3), I'm having trouble lately completing a piglit run,
On Mon, Jul 15, 2019 at 10:57 AM wrote:
>
> From: Wang Xiayang
>
> The simple_strtol() function is deprecated. kstrto[l,u32]() is
> the correct replacement as it can properly handle overflows.
>
> This patch replaces the deprecated simple_strtol() use introduced recently.
> As clk is of type
On Mon, Jul 15, 2019 at 3:57 AM Fuqian Huang wrote:
>
> kzalloc has already zeroed the memory during the allocation.
> So memset is unneeded.
>
> Signed-off-by: Fuqian Huang
Applied. thanks!
Alex
> ---
> Changes in v3:
> - Fix subject prefix: gpu/drm -> drm/amdgpu
>
>
On Sat, Jul 13, 2019 at 2:43 AM Kuehling, Felix wrote:
>
> When starting a new mm_node, the page_offset becomes 0.
>
> Signed-off-by: Felix Kuehling
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
On Fri, Jul 12, 2019 at 5:41 AM Arnd Bergmann wrote:
>
> It is annoying to have #warnings that trigger in randconfig
> builds like
>
> drivers/gpu/drm/amd/amdgpu/soc15.c:653:3: error: "Enable CONFIG_DRM_AMD_DC
> for display support on SOC15."
> drivers/gpu/drm/amd/amdgpu/nv.c:400:3: error:
On Mon, Jun 24, 2019 at 7:40 PM Catalin Marinas wrote:
>
> On Mon, Jun 24, 2019 at 04:32:56PM +0200, 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
On Mon, Jun 24, 2019 at 7:51 PM Catalin Marinas wrote:
>
> On Mon, Jun 24, 2019 at 04:32:53PM +0200, 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
On Mon, Jun 24, 2019 at 7:50 PM Catalin Marinas wrote:
>
> On Mon, Jun 24, 2019 at 04:32:52PM +0200, 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
On Mon, Jul 15, 2019 at 11:25:29AM +0200, Arnd Bergmann wrote:
> On Thu, Jul 4, 2019 at 7:52 AM Nathan Chancellor
> wrote:
> >
> > clang warns:
> >
> > drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:995:39: warning:
> > implicit conversion from enumeration type 'PPCLK_e' to different
> >
From: Wang Xiayang
The simple_strtol() function is deprecated. kstrto[l,u32]() is
the correct replacement as it can properly handle overflows.
This patch replaces the deprecated simple_strtol() use introduced recently.
As clk is of type uint32_t, we are safe to use kstrtou32().
It is also safe
Acked-by: Alex Deucher
From: amd-gfx on behalf of Russell,
Kent
Sent: Monday, July 15, 2019 8:54 AM
To: amd-gfx@lists.freedesktop.org
Cc: Russell, Kent
Subject: [PATCH] drm/amdgpu: Fix Vega20 Perf counter for pcie_bw
The perf counter for Vega20 is 108, instead
> kzalloc has already zeroed the memory.
> So the memset is unneeded.
See also a previous patch:
drm/amd/powerplay: Delete a redundant memory setting in
vega20_set_default_od8_setttings()
https://lore.kernel.org/lkml/de3f6a5e-8ac4-bc8e-0d0c-3a4a5db28...@web.de/
Dear Nicholas,
On 7/15/19 2:57 PM, Kazlauskas, Nicholas wrote:
> On 7/15/19 6:34 AM, Paul Menzel wrote:
>> From 09c1952466752033722b02d9c7e5532e1982f6d9 Mon Sep 17 00:00:00 2001
>> From: Paul Menzel
>> Date: Sat, 13 Jul 2019 20:33:49 +0200
>>
>> This basically reverts commit 00893681a0ff4
On 7/15/19 6:34 AM, Paul Menzel wrote:
> From 09c1952466752033722b02d9c7e5532e1982f6d9 Mon Sep 17 00:00:00 2001
> From: Paul Menzel
> Date: Sat, 13 Jul 2019 20:33:49 +0200
>
> This basically reverts commit 00893681a0ff4 (drm/amd/display: Reject
> PPLib clock values if they are invalid).
>
> 0
The perf counter for Vega20 is 108, instead of 104 which it was on all
previous GPUs, so add a check to use the appropriate value.
Change-Id: Id5b5026a03b09d8b9d52dda85e17ed5acd818912
Signed-off-by: Kent Russell
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 10 --
1 file changed, 8
Am 02.07.19 um 19:15 schrieb Emil Velikov:
On Fri, 14 Jun 2019 at 19:02, Koenig, Christian
wrote:
Am 14.06.19 um 19:33 schrieb Emil Velikov:
From: Emil Velikov
Currently the AMDGPU_CTX_PRIORITY_* defines are used in both
drm_amdgpu_ctx_in::priority and drm_amdgpu_sched_in::priority.
Extend
kzalloc has already zeroed the memory.
So the memset is unneeded.
Signed-off-by: Fuqian Huang
---
drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
b/drivers/gpu/drm/amd/powerplay/vega20_ppt.c
index
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
Signed-off-by: Oleg Vasilev
Cc: amd-gfx@lists.freedesktop.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 12
Hi Emily,
no, we can only cleanup the current one because we don't have a
reference to the other ones.
At least that's how I understand you question,
Christian.
Am 15.07.19 um 12:47 schrieb Deng, Emily:
> Hi Christian,
> Do you think we could free all those bos those are in current
Hi Christian,
Do you think we could free all those bos those are in current destroy list
when the current resv is signal in ttm_bo_cleanup_refs?
Best wishes
Emily Deng
>-Original Message-
>From: Koenig, Christian
>Sent: Monday, July 15, 2019 5:41 PM
>To: Deng, Emily ; Zhou,
On 2019/07/15, Fuqian Huang wrote:
> kzalloc has already zeroed the memory during the allocation.
> So memset is unneeded.
>
> Signed-off-by: Fuqian Huang
> ---
> Changes in v3:
> - Fix subject prefix: gpu/drm -> drm/amdgpu
>
Reviewed-by: Emil Velikov
-Emil
From 09c1952466752033722b02d9c7e5532e1982f6d9 Mon Sep 17 00:00:00 2001
From: Paul Menzel
Date: Sat, 13 Jul 2019 20:33:49 +0200
This basically reverts commit 00893681a0ff4 (drm/amd/display: Reject
PPLib clock values if they are invalid).
0 kHz values are a thing on at least the boards below.
> Do you think we don't need to fix it?
No, when the application is exhausting memory then we can't expect
anything else here.
See memory freeing is always delayed until it isn't used any more or
when the process is killed after access is prevented (by clearing page
tables for example).
What
Hi Christian,
As has this behavior, when test vulkan cts allocation test, it will
exhausting the memory, and cause out of memory. Do you think we don't need to
fix it?
Best wishes
Emily Deng
>-Original Message-
>From: Koenig, Christian
>Sent: Monday, July 15, 2019 5:31 PM
>To:
Hi guys,
> Do you have any suggestion about this? For per vm bo, it seems always delay
> to free the ttm bo.
Yeah, and that is correct behavior.
Since we don't know who is using a per-vm BO we need to wait for all
command submissions in flight when it is freed.
For this we copy the current
On Thu, Jul 4, 2019 at 7:52 AM Nathan Chancellor
wrote:
>
> clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:995:39: warning:
> implicit conversion from enumeration type 'PPCLK_e' to different
> enumeration type 'enum smu_clk_type' [-Wenum-conversion]
> ret =
On Mon, Jul 8, 2019 at 6:05 PM Arnd Bergmann wrote:
> On Mon, Jul 8, 2019 at 4:54 PM Nathan Chancellor
> wrote:
> > On Mon, Jul 08, 2019 at 03:57:06PM +0200, Arnd Bergmann wrote:
> > > A couple of calls to smu_get_current_clk_freq() and smu_force_clk_levels()
> > > pass constants of the wrong
Hi David,
You are right, it will copy per-vm resv.
But currently, it still has the delay free issue which non per vm bo
doesn't has. Maybe it already has new fences append to this resv object before
copy.
Hi Christian,
Do you have any suggestion about this? For per vm bo, it seems
Am 13.07.19 um 22:24 schrieb Felix Kuehling:
Am 2019-04-30 um 1:03 p.m. schrieb Koenig, Christian:
The only real solution I can see is to be able to reliable kill shaders
in an OOM situation.
Well, we can in fact preempt our compute shaders with low latency.
Killing a KFD process will do
201 - 238 of 238 matches
Mail list logo
