Hello Christian K??nig,
The patch 9cc2e0e9f133: "drm/radeon: never unpin UVD bo v3" from Jul
12, 2013, leads to the following static checker warning:
drivers/gpu/drm/radeon/radeon_uvd.c:225 radeon_uvd_init()
warn: inconsistent returns '*rdev->uvd.vcpu_bo->tbo.base.resv'.
Acked-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Tuesday, November 26, 2019 12:13 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: [PATCH] drm/amdgpu: flag vram lost on baco reset for VI/CIK
>
> VI/CIK BACO was
Thanks Alex
_
Monk Liu|GPU Virtualization Team |AMD
[sig-cloud-gpu]
From: Alex Deucher
Sent: Tuesday, November 26, 2019 4:34 AM
To: Liu, Monk
Cc: Koenig, Christian ; amd-gfx@lists.freedesktop.org
Subject: Re: why we unreserve MQD of KIQ ?
On Mon, Nov 25,
Really cool patch!
Reviewed-by: xinhui pan
-Original Message-
From: Kuehling, Felix
Sent: 2019年11月26日 3:35
To: amd-gfx@lists.freedesktop.org; Pan, Xinhui
Subject: [PATCH 1/1] drm/amdgpu: Optimize KFD page table reservation
Be less pessimistic about estimated page table use for KFD.
Christian asked to submit it to drm-misc instead of our drm-next to avoid later
conflicts with Steven's patch which he mentioned in this thread which is not in
drm-next yet.
Christian, Alex, once this merged to drm-misc I guess we need to pull all
latest changes from there to drm-next so the
Ran amdgpu_test(drm) successfully multiple times to test this. But I am
pretty sure I am missing some corner case here.
Regards,
Nirmoy
On 11/26/19 12:17 AM, Nirmoy Das wrote:
Currently we pre-allocate entities for all the HW IPs on
context creation and some of which are might never be
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Yong Zhao
From: amd-gfx on behalf of Felix
Kuehling
Sent: Monday, November 25, 2019 4:28 PM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH 1/1] drm/amdgpu: Raise KFD unpinned system memory
- Original Message -
> From: "Felix Kuehling"
> To: "Timothy Pearson"
> Cc: "amd-gfx"
> Sent: Monday, November 25, 2019 3:34:20 PM
> Subject: Re: [PATCH 1/1] amdgpu: Enable KFD on POWER systems
> On 2019-11-25 4:06 p.m., Timothy Pearson wrote:
>>
>> - Original Message -
>>>
[AMD Official Use Only - Internal Distribution Only]
Hi Andrey,
Seems you didn't submit this patch?
Best wishes
Emily Deng
>-Original Message-
>From: Andrey Grodzovsky
>Sent: Monday, November 25, 2019 12:51 PM
>Cc: dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org;
Please kindly give a review on my latest revision. Thanks a lot.
Regards,
Jerry
-Original Message-
From: Jerry (Fangzhi) Zuo
Sent: November 5, 2019 11:38 AM
To: dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org
Cc: ly...@redhat.com; manasi.d.nav...@intel.com; Wentland,
On 2019-11-25 4:06 p.m., Timothy Pearson wrote:
- Original Message -
From: "Felix Kuehling"
To: "Timothy Pearson" , "amd-gfx"
Sent: Monday, November 25, 2019 11:07:31 AM
Subject: Re: [PATCH 1/1] amdgpu: Enable KFD on POWER systems
Hi Timothy,
Thank you for the patch and for
Allow KFD applications to use more unpinned system memory through
HMM.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
- Original Message -
> From: "Felix Kuehling"
> To: "Timothy Pearson" , "amd-gfx"
>
> Sent: Monday, November 25, 2019 11:07:31 AM
> Subject: Re: [PATCH 1/1] amdgpu: Enable KFD on POWER systems
> Hi Timothy,
>
> Thank you for the patch and for confirming that it works. We did some
>
Problem:
Due to a race between drm_sched_cleanup_jobs in sched thread and
drm_sched_job_timedout in timeout work there is a possiblity that
bad job was already freed while still being accessed from the
timeout thread.
Fix:
Instead of just peeking at the bad job in the mirror list
remove it from
Hi Linus,
Here is this batch of hmm updates, I think we are nearing the end of this
project for now, although I suspect there will be some more patches related to
hmm_range_fault() in the next cycle.
You will probably be most interested in the patch "mm/mmu_notifier: add an
interval tree
On Mon, Nov 25, 2019 at 4:05 AM Liu, Monk wrote:
> commit a9a8a788e5e946a9835a1365256fc4ce9e96ba2c
>
> Author: Rex Zhu
>
> Date: Wed Aug 22 18:54:45 2018 +0800
>
>
>
> drm/amdgpu: Change kiq ring initialize sequence on gfx9
>
>
>
> 1. initialize kiq before initialize gfx ring.
>
>
Hi Xinhui,
I sent this patch in July and then forgot about it. Please review it.
You could use this as the basis for your heap-size improvement. Just
move the ESTIMATE_PT_SIZE macro into an appropriate header file so you
can use it in the KFD code.
Regards,
Felix
On 2019-11-25 2:35 p.m.,
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
Hi Timothy,
Thank you for the patch and for confirming that it works. We did some
experimental work on Power8 a few years ago. I see that Talos II is Power9.
At the time we were working on Power8 we had to add some #ifdef
CONFIG_ACPI guards around some ACPI-specific code in KFD. Do you know
On 25/11/2019 14:10, Andrey Grodzovsky wrote:
> Problem:
> Due to a race between drm_sched_cleanup_jobs in sched thread and
> drm_sched_job_timedout in timeout work there is a possiblity that
> bad job was already freed while still being accessed from the
> timeout thread.
>
> Fix:
> Instead of
On 25/11/2019 14:10, Andrey Grodzovsky wrote:
> When the sched thread is parked we assume ring_mirror_list is
> not accessed from here.
FWIW I don't think this is necessary. kthread_park() will wait until the
thread is parked, at which point the thread is stuck in kthread_parkme()
until unparked.
25 Kas 2019 Pzt 17:44 tarihinde Alex Deucher şunu
yazdı:
> On Mon, Nov 25, 2019 at 8:55 AM Yusuf Altıparmak
> wrote:
> >
> > Hello,
> >
> > I am trying to use AMD E9171 with T1042D4RDB-64B(
>
VI/CIK BACO was inflight when this fix landed for SOC15/NV.
Add the fix to VI/CIK as well.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/cik.c | 7 +--
drivers/gpu/drm/amd/amdgpu/vi.c | 7 +--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Zhan Liu
From: amd-gfx on behalf of Bhawanpreet
Lakha
Sent: Monday, November 25, 2019 10:40:24 AM
To: amd-gfx@lists.freedesktop.org
Cc: Lakha, Bhawanpreet
Subject: [PATCH] drm/amd/display:
On 2019-11-25 10:40 a.m., Bhawanpreet Lakha wrote:
[Why]
previously event_property_validate was only called after we enabled the display.
But after "Refactor HDCP to handle multiple displays per link" this function
can be called at any time. In certain cases we don't have a aconnector
[How]
[Why]
previously event_property_validate was only called after we enabled the display.
But after "Refactor HDCP to handle multiple displays per link" this function
can be called at any time. In certain cases we don't have a aconnector
[How]
Null check aconnector and exit early. This is ok because
On Mon, Nov 25, 2019 at 10:00 AM YueHaibing wrote:
>
> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:
> In function vegam_populate_clock_stretcher_data_table:
> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:1489:29:
> warning: variable stretch_amount2 set but not
On Mon, Nov 25, 2019 at 10:00 AM YueHaibing wrote:
>
> drivers/gpu/drm/amd/amdgpu/../display/modules/hdcp/hdcp_psp.c: In function
> mod_hdcp_hdcp2_enable_encryption:
> drivers/gpu/drm/amd/amdgpu/../display/modules/hdcp/hdcp_psp.c:633:77:
> warning: variable msg_out set but not used
drivers/gpu/drm/amd/amdgpu/../display/modules/hdcp/hdcp_psp.c: In function
mod_hdcp_hdcp2_enable_encryption:
drivers/gpu/drm/amd/amdgpu/../display/modules/hdcp/hdcp_psp.c:633:77: warning:
variable msg_out set but not used [-Wunused-but-set-variable]
On Sun, Nov 24, 2019 at 2:15 PM Timothy Pearson
wrote:
>
> KFD has been verified to function on POWER systems (Talos II / Vega 64).
> It should be available as a kernel configuration option on these systems.
>
> Signed-off-by: Timothy Pearson
Applied. Thanks!
Alex
> ---
>
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:
In function vegam_populate_clock_stretcher_data_table:
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:1489:29:
warning: variable stretch_amount2 set but not used [-Wunused-but-set-variable]
It is never used, so can be
On Fri, Nov 22, 2019 at 6:15 PM Colin King wrote:
>
> From: Colin Ian King
>
> The variable ret is being initialized with a value that is never
> read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
>
On Mon, Nov 25, 2019 at 3:07 AM Nathan Chancellor
wrote:
>
> Commit b0f3cd3191cd ("drm/amdgpu: remove unnecessary JPEG2.0 code from
> VCN2.0") introduced a new clang warning in the vcn_v2_0_stop function:
>
> ../drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c:1082:2: warning: variable 'r'
> is used
On Mon, Nov 25, 2019 at 8:55 AM Yusuf Altıparmak
wrote:
>
> Hello,
>
> I am trying to use AMD E9171 with
>
On Sat, Nov 23, 2019 at 3:57 AM Takashi Iwai wrote:
>
> On Fri, 22 Nov 2019 22:43:49 +0100,
> Alex Deucher wrote:
> >
> > These patches were originally part of a larger set of patches
> > to enabled runtime pm support on the GPU side[1]. However, the
> > patches are useful on their own there are
On Fri, Nov 22, 2019 at 6:04 PM Colin King wrote:
>
> From: Colin Ian King
>
> The variables HiSidd and LoSidd are being initialized with values that
> are never read and are being updated a little later with a new value.
> The initialization is redundant and can be removed.
>
>
On Sun, Nov 24, 2019 at 9:56 PM Ernst Sjöstrand wrote:
>
> The same bug is listed twice. Did you mean a third bug?
No just a typo. Already fixed up locally.
Alex
>
>
> Den tors 21 nov. 2019 kl 00:25 skrev Alex Deucher :
> >
> > Ping?
> >
> > On Fri, Nov 15, 2019 at 11:01 AM Alex Deucher
On 2019-11-23 2:36 p.m., Nathan Chancellor wrote:
> Clang warns:
>
> ../drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:1965:26: warning:
> expression which evaluates to zero treated as a null pointer constant of
> type 'struct dc_dsc_config *' [-Wnon-literal-null-conversion]
>
On 2019-11-25 4:49 a.m., Louis Li wrote:
> On Fri, Nov 22, 2019 at 10:31:19AM -0500, Harry Wentland wrote:
>>
>>
>> On 2019-11-22 1:33 a.m., Louis Li wrote:
>>> On Thu, Nov 21, 2019 at 08:47:50AM -0500, Kazlauskas, Nicholas wrote:
On 2019-11-21 8:40 a.m., Kazlauskas, Nicholas wrote:
>
When the sched thread is parked we assume ring_mirror_list is
not accessed from here.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git
Problem:
Due to a race between drm_sched_cleanup_jobs in sched thread and
drm_sched_job_timedout in timeout work there is a possiblity that
bad job was already freed while still being accessed from the
timeout thread.
Fix:
Instead of just peeking at the bad job in the mirror list
remove it from
Applied. Thanks!
Alex
On Thu, Nov 21, 2019 at 11:13 AM Deucher, Alexander
wrote:
>
> Reviewed-by: Alex Deucher
>
> From: Krzysztof Kozlowski
> Sent: Thursday, November 21, 2019 8:29 AM
> To: linux-ker...@vger.kernel.org
> Cc: Krzysztof Kozlowski ; Deucher,
Hello,
I am trying to use AMD E9171 with T1042D4RDB-64B(
https://www.nxp.com/products/processors-and-microcontrollers/power-architecture/qoriq-communication-processors/t-series/qoriq-t1042-and-t1022-multicore-communications-processors:T1042).
Software documentation is here (
On Fri, Nov 22, 2019 at 10:31:19AM -0500, Harry Wentland wrote:
>
>
> On 2019-11-22 1:33 a.m., Louis Li wrote:
> > On Thu, Nov 21, 2019 at 08:47:50AM -0500, Kazlauskas, Nicholas wrote:
> >> On 2019-11-21 8:40 a.m., Kazlauskas, Nicholas wrote:
> >>> On 2019-11-21 3:31 a.m., Li, Ching-shih (Louis)
commit a9a8a788e5e946a9835a1365256fc4ce9e96ba2c
Author: Rex Zhu
Date: Wed Aug 22 18:54:45 2018 +0800
drm/amdgpu: Change kiq ring initialize sequence on gfx9
1. initialize kiq before initialize gfx ring.
2. set kiq ring ready immediately when kiq initialize
successfully.
On Fri, Nov 22, 2019 at 04:54:08PM -0800, Ralph Campbell wrote:
> Actually, I think you can remove the "need_wake" variable since it is
> unconditionally set to "true".
Oh, yes, thank you. An earlier revision had a different control flow
> Also, the comment in__mmu_interval_notifier_insert()
Commit b0f3cd3191cd ("drm/amdgpu: remove unnecessary JPEG2.0 code from
VCN2.0") introduced a new clang warning in the vcn_v2_0_stop function:
../drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c:1082:2: warning: variable 'r'
is used uninitialized whenever 'while' loop exits because its condition
is false
Clang warns:
../drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:1965:26: warning:
expression which evaluates to zero treated as a null pointer constant of
type 'struct dc_dsc_config *' [-Wnon-literal-null-conversion]
update->dsc_config = false;
48 matches
Mail list logo
