Am 16.06.20 um 08:30 schrieb Chen Tao:
Fix memory leak in amdgpu_debugfs_gpr_read not freeing data when
pm_runtime_get_sync failed.
Fixes: a9ffe2a983383 ("drm/amdgpu/debugfs: properly handle runtime pm")
Signed-off-by: Chen Tao
Probably better to remove the duplication of result and r here an
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Aditya Pakki
Sent: Sunday, June 14, 2020 10:21 AM
To: pakki...@umn.edu
Cc: wu000...@umn.edu; David Airlie ; k...@umn.edu;
linux-ker...@vger.kernel.org; amd-gfx@lists.f
[AMD Official Use Only - Internal Distribution Only]
Acked-by: Evan Quan
From: amd-gfx On Behalf Of Guo Lei
Sent: Monday, June 15, 2020 3:14 PM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH] drm/amdgpu: Fix incorrect firmware size calculation
>From 014162f69b909a59c241e7f73c3630d1da34696c
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Tuesday, June 16, 2020 4:26 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu/pm: update comment to clarify
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Tuesday, June 16, 2020 4:40 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu: fix documentation around bus
Yes, I agree.
On Tue, Jun 16, 2020 at 3:08 AM Alex Deucher wrote:
>
> On Mon, Jun 15, 2020 at 5:30 AM Aaron Chou wrote:
> >
> > About one month ago, I have asked a question about HDMI hotplug, the link
> > is:
> >
> > https://gitlab.freedesktop.org/drm/amd/-/issues/1135#note_492460
> >
> > And
On 2020-06-13 15:32, wu000...@umn.edu wrote:
From: Qiushi Wu
kobject_init_and_add() takes reference even when it fails.
If this function returns an error, kobject_put() must be called to
properly clean up the memory associated with the object.
Signed-off-by: Qiushi Wu
Thank you. The patch i
On Mon, Jun 15, 2020 at 3:27 AM Aditya Pakki wrote:
>
> On calling pm_runtime_get_sync() the reference count of the device
> is incremented. In case of failure, decrement the
> reference count before returning the error.
Is this required if pm_runtime_get_sync() fails?
Alex
>
> Signed-off-by: A
> Are we planning to keep PASID live once a task has used it once or are we
> going to swap it lazily? If the latter, a percpu variable might be better.
Current plan is "touch it once and the task owns it until exit(2)"
Maybe someday in the future when we have data on how applications
actually
> So what’s the RDMSR for? Surely you
> have some state somewhere that says “this task has a PASID.”
> Can’t you just make sure that stays in sync with the MSR? Then, on #GP, if
> the task already has a PASID, you know the MSR is set.
We have state that says the process ("mm") has been allocate
> On Jun 15, 2020, at 1:17 PM, Fenghua Yu wrote:
>
> Hi, Peter,
>
>> On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote:
>>> On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
>>>
>>> Or do you suggest to add a random new flag in struct thread_info instead
>>> of a TIF fl
> On Jun 15, 2020, at 1:56 PM, Luck, Tony wrote:
>
>
>>
>> Are we planning to keep PASID live once a task has used it once or are we
>> going to swap it lazily? If the latter, a percpu variable might be better.
>
> Current plan is "touch it once and the task owns it until exit(2)"
>
> Ma
Hi, Peter,
On Mon, Jun 15, 2020 at 09:09:28PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
>
> > Or do you suggest to add a random new flag in struct thread_info instead
> > of a TIF flag?
>
> Why thread_info? What's wrong with something simple like
Reviewed-by: Nirmoy Das
On 6/15/20 10:40 PM, Alex Deucher wrote:
Add rename the gpu busy percentage for consistency and
add the mem busy percentage documentation.
Signed-off-by: Alex Deucher
---
Documentation/gpu/amdgpu.rst | 9 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c |
Add rename the gpu busy percentage for consistency and
add the mem busy percentage documentation.
Signed-off-by: Alex Deucher
---
Documentation/gpu/amdgpu.rst | 9 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 2 +-
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/Do
Acked-by: Nirmoy Das
On 6/15/20 10:25 PM, Alex Deucher wrote:
Vega10 and previous asics use one interface, vega20 and newer
use another.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
Vega10 and previous asics use one interface, vega20 and newer
use another.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
i
[AMD Official Use Only - Internal Distribution Only]
Series is
Reviewed-by: Bhawanpreet.Lakha
From: amd-gfx on behalf of Jerry
(Fangzhi) Zuo
Sent: June 15, 2020 3:01 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Zuo, Jerry
; Wentland, Harry ;
On Mon, Jun 15, 2020 at 11:55:29AM -0700, Fenghua Yu wrote:
> Or do you suggest to add a random new flag in struct thread_info instead
> of a TIF flag?
Why thread_info? What's wrong with something simple like the below. It
takes a bit from the 'strictly current' flags word.
diff --git a/include
On Mon, Jun 15, 2020 at 5:30 AM Aaron Chou wrote:
>
> About one month ago, I have asked a question about HDMI hotplug, the link is:
>
> https://gitlab.freedesktop.org/drm/amd/-/issues/1135#note_492460
>
> And I have put one patch to fix this, as follows:
>
> 39 diff --git a/drivers/gpu/drm/amd/am
From: Alvin Lee
[Why]
We need to update each p-state in the bounding box
[How]
Update states when assigning values to clocks
Signed-off-by: Alvin Lee
Signed-off-by: Jerry (Fangzhi) Zuo
Reviewed-by: Hersen Wu
---
.../drm/amd/display/dc/dcn30/dcn30_resource.c | 65 +++
1 file
From: Alvin Lee
[Why]
We want to update the bounding box to have more granular control of the
DCFCLK.
[How]
Setup DCFCLK to use STA values and also optimal values based on
UCLK.
Signed-off-by: Alvin Lee
Signed-off-by: Jerry (Fangzhi) Zuo
Reviewed-by: Hersen Wu
---
.../drm/amd/display/dc/dcn
Hi, Peter,
On Mon, Jun 15, 2020 at 08:31:16PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 15, 2020 at 11:12:59AM -0700, Fenghua Yu wrote:
> > > I don't get why you need a rdmsr here, or why not having one would
> > > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed?
> >
> > My
On Mon, Jun 15, 2020 at 11:19:21AM -0700, Raj, Ashok wrote:
> On Mon, Jun 15, 2020 at 06:03:57PM +0200, Peter Zijlstra wrote:
> >
> > I don't get why you need a rdmsr here, or why not having one would
> > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed?
> >
> > > > > + *
On Mon, Jun 15, 2020 at 11:12:59AM -0700, Fenghua Yu wrote:
> > I don't get why you need a rdmsr here, or why not having one would
> > require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed?
>
> My concern is TIF flags are precious (only 3 slots available). Defining
> a new TIF flag
On Mon, Jun 15, 2020 at 06:03:57PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 15, 2020 at 08:48:54AM -0700, Fenghua Yu wrote:
> > Hi, Peter,
> > On Mon, Jun 15, 2020 at 09:56:49AM +0200, Peter Zijlstra wrote:
> > > On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote:
> > > > +/*
> > > > + *
On Mon, Jun 15, 2020 at 06:03:57PM +0200, Peter Zijlstra wrote:
>
> I don't get why you need a rdmsr here, or why not having one would
> require a TIF flag. Is that because this MSR is XSAVE/XRSTOR managed?
>
> > > > +*/
> > > > + rdmsrl(MSR_IA32_PASID, pasid_msr);
> > > > + i
>> The heuristic always initializes the MSR with the per mm PASID IIF the
>> mm has a valid PASID but the MSR doesn't have one. This heuristic usually
>> happens only once on the first #GP in a thread.
>
> But it doesn't guarantee the PASID is the right one. Suppose both the mm
> has a PASID and th
On Mon, Jun 15, 2020 at 12:18 PM Tom St Denis wrote:
>
> Forgot to subtract the SOC15 IP offsetand add the BASE_IDX values.
>
> Signed-off-by: Tom St Denis
Reviewed-by: Alex Deucher
> ---
> .../gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_offset.h | 6 --
> .../gpu/drm/amd/include/asic_reg
On Mon, Jun 15, 2020 at 08:48:54AM -0700, Fenghua Yu wrote:
> Hi, Peter,
> On Mon, Jun 15, 2020 at 09:56:49AM +0200, Peter Zijlstra wrote:
> > On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote:
> > > +/*
> > > + * Apply some heuristics to see if the #GP fault was caused by a thread
> > > +
Forgot to subtract the SOC15 IP offsetand add the BASE_IDX values.
Signed-off-by: Tom St Denis
---
.../gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_offset.h | 6 --
.../gpu/drm/amd/include/asic_reg/gc/gc_10_3_0_offset.h | 6 --
drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_0_offset.h |
Hi, Peter,
On Mon, Jun 15, 2020 at 09:56:49AM +0200, Peter Zijlstra wrote:
> On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote:
> > +/*
> > + * Apply some heuristics to see if the #GP fault was caused by a thread
> > + * that hasn't had the IA32_PASID MSR initialized. If it looks like tha
Hi, Peter,
On Mon, Jun 15, 2020 at 09:52:02AM +0200, Peter Zijlstra wrote:
> On Fri, Jun 12, 2020 at 05:41:21PM -0700, Fenghua Yu wrote:
>
> > This series only provides simple and basic support for ENQCMD and the MSR:
> > 1. Clean up type definitions (patch 1-3). These patches can be in a
> >s
On Fri, Jun 12, 2020 at 05:41:21PM -0700, Fenghua Yu wrote:
> This series only provides simple and basic support for ENQCMD and the MSR:
> 1. Clean up type definitions (patch 1-3). These patches can be in a
>separate series.
>- Define "pasid" as "unsigned int" consistently (patch 1 and 2).
On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote:
> +/*
> + * Apply some heuristics to see if the #GP fault was caused by a thread
> + * that hasn't had the IA32_PASID MSR initialized. If it looks like that
> + * is the problem, try initializing the IA32_PASID MSR. If the heuristic
> + *
On Fri, Jun 12, 2020 at 05:41:33PM -0700, Fenghua Yu wrote:
> @@ -447,6 +458,18 @@ dotraplinkage void do_general_protection(struct pt_regs
> *regs, long error_code)
> int ret;
>
> RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
> +
> + /*
> + * Perform th
[AMD Official Use Only - Internal Distribution Only]
please add these smu messages into patch commit,
after fixed,
Reviewed-by: Kevin Wang
Best Regards,
Kevin
From: Sheng, Wenhui
Sent: Sunday, June 14, 2020 3:38 PM
To: Wang, Kevin(Yang) ; amd-gfx@lists.freedeskt
About one month ago, I have asked a question about HDMI hotplug, the link is:
https://gitlab.freedesktop.org/drm/amd/-/issues/1135#note_492460
And I have put one patch to fix this, as follows:
39 diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_con
From: Qiushi Wu
kobject_init_and_add() takes reference even when it fails.
If this function returns an error, kobject_put() must be called to
properly clean up the memory associated with the object.
Signed-off-by: Qiushi Wu
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 20 +++
On calling pm_runtime_get_sync() the reference count of the device
is incremented. In case of failure, decrement the
reference count before returning the error.
Signed-off-by: Aditya Pakki
---
drivers/gpu/drm/radeon/radeon_display.c | 4 +++-
drivers/gpu/drm/radeon/radeon_drv.c | 4 +++-
dri
The call to pm_runtime_get_sync increments the counter even in case of
failure, leading to incorrect ref count.
In case of failure, decrement the ref count before returning.
Signed-off-by: Navid Emamdoost
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 16
1 file changed, 1
From 014162f69b909a59c241e7f73c3630d1da34696c Mon Sep 17 00:00:00 2001
From: Lei Guo
Date: Mon, 15 Jun 2020 13:54:26 +0800
Subject: [PATCH] drm/amdgpu: Fix incorrect firmware size calculation
[WHY]
The memcpy() function copies n bytes from memory area src to memory area
dest. So specify t
On calling pm_runtime_get_sync() the reference count of the device
is incremented. In case of failure, decrement the
reference count before returning the error.
Signed-off-by: Aditya Pakki
---
drivers/gpu/drm/radeon/radeon_connectors.c | 20 +++-
1 file changed, 15 insertions(+),
in amdgpu_drm_ioctl the call to pm_runtime_get_sync increments the
counter even in case of failure, leading to incorrect
ref count. In case of failure, decrement the ref count before returning.
Signed-off-by: Navid Emamdoost
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
1 file changed, 2
> in amdgpu_display_crtc_set_config, …
* Can the term “reference count” become relevant also for this commit message
besides other possible adjustments?
* Can it be nicer to combine proposed updates for this software module
as a patch series (with a cover letter)?
* Would you like to add the
in amdgpu_display_crtc_set_config, the call to pm_runtime_get_sync
increments the counter even in case of failure, leading to incorrect
ref count. In case of failure, decrement the ref count before returning.
Signed-off-by: Navid Emamdoost
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 5 +++-
in amdgpu_driver_open_kms the call to pm_runtime_get_sync increments the
counter even in case of failure, leading to incorrect
ref count. In case of failure, decrement the ref count before returning.
Signed-off-by: Navid Emamdoost
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 ++-
1 file chang
Hi Fenghua,
On 6/13/20 8:41 AM, Fenghua Yu wrote:
A PASID is allocated for an "mm" the first time any thread attaches
to an SVM capable device. Later device attachments (whether to the same
device or another SVM device) will re-use the same PASID.
The PASID is freed when the process exits (so n
48 matches
Mail list logo
