Hi Emil and Alex,
Sorry for miss your emails. I will update a new patch as Emil's suggestion.
Best wishes
Emily Deng
>-Original Message-
>From: Emil Velikov
>Sent: Thursday, April 18, 2019 2:26 AM
>To: Deucher, Alexander
>Cc: Alex Deucher ; Deng, Emily
>; Maling list - DRI develop
>> -drm_sched_stop(&ring->sched, &job->base);
>> -
>> /* after all hw jobs are reset, hw fence is meaningless, so
>> force_completion */
>> amdgpu_fence_driver_force_completion(ring);
>> }
HW fence are already forced completion, then we can just disab
One more nit-pick inline.
On 2019-04-23 4:59 p.m., Zeng, Oak wrote:
> Remap HDP_MEM_COHERENCY_FLUSH_CNTL and HDP_REG_COHERENCY_FLUSH_CNTL
> to an empty page in mmio space. We will later map this page to process
> space so application can flush hdp. This can't be done properly at
> those registers'
It seems to me that amdgpu_hive_info is a driver-internal structure, but
the psp_xpmi_topology structures are an interface with the PSP that may
change in future ASIC generations. So on second thought, adding the
psp_xgmi_topology structures to the psp_xgmi_context (or
amdgpu_hive_info) like th
Introduce a new memory type (KFD_IOC_ALLOC_MEM_FLAGS_MMIO_REMAP) and
expose mmio page of HDP registers to user space through this new
memory type.
v2: moved remapped hdp regs to adev struct
v3: rename the new memory type to ALLOC_MEM_FLAGS_MMIO_REMAP
v4: use more generic function name
v5: Fail rem
Remap HDP_MEM_COHERENCY_FLUSH_CNTL and HDP_REG_COHERENCY_FLUSH_CNTL
to an empty page in mmio space. We will later map this page to process
space so application can flush hdp. This can't be done properly at
those registers' original location because it will expose more than
desired registers to proc
Upper level runtime need the xgmi hops info to determine the data path
Change-Id: I969b419eab125157e223e9b03980ca229c1e6af4
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 7 +--
drivers/gpu/drm/amd/amdkfd/kfd_crat.h | 3 ++-
2 files changed, 7 insertions(+), 3 deletions(
KFD need to provide the info for upper level to determine the data path
Change-Id: Idc809e8f3381b9222dd7be96539522d440f3ee7d
Signed-off-by: shaoyunl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 15 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 +
drivers/gpu/drm/amd/amdgpu/
See inline.
On 2019-04-23 3:23 p.m., Zeng, Oak wrote:
> Remap HDP_MEM_COHERENCY_FLUSH_CNTL and HDP_REG_COHERENCY_FLUSH_CNTL
> to an empty page in mmio space. We will later map this page to process
> space so application can flush hdp. This can't be done properly at
> those registers' original loca
Introduce a new memory type (KFD_IOC_ALLOC_MEM_FLAGS_MMIO_REMAP) and
expose mmio page of HDP registers to user space through this new
memory type.
v2: moved remapped hdp regs to adev struct
v3: rename the new memory type to ALLOC_MEM_FLAGS_MMIO_REMAP
v4: use more generic function name
v5: Fail rem
Remap HDP_MEM_COHERENCY_FLUSH_CNTL and HDP_REG_COHERENCY_FLUSH_CNTL
to an empty page in mmio space. We will later map this page to process
space so application can flush hdp. This can't be done properly at
those registers' original location because it will expose more than
desired registers to proc
comments inline.
On 2019-04-23 2:09 p.m., Kuehling, Felix wrote:
> See inline.
>
> On 2019-04-17 2:58 p.m., Liu, Shaoyun wrote:
>> KFD need to provide the info for upper level to determine the data path
>>
>> Change-Id: Idc809e8f3381b9222dd7be96539522d440f3ee7d
>> Signed-off-by: shaoyunl
>> ---
>
On 2019-04-17 2:59 p.m., Liu, Shaoyun wrote:
> Upper level runtime need the xgmi hops info to determine the data path
>
> Change-Id: I969b419eab125157e223e9b03980ca229c1e6af4
> Signed-off-by: shaoyunl
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 8 ++--
> drivers/gpu/drm/amd/amdkfd/kfd_c
See inline.
On 2019-04-17 2:58 p.m., Liu, Shaoyun wrote:
> KFD need to provide the info for upper level to determine the data path
>
> Change-Id: Idc809e8f3381b9222dd7be96539522d440f3ee7d
> Signed-off-by: shaoyunl
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 15 +++
> drive
Introduce a new memory type (KFD_IOC_ALLOC_MEM_FLAGS_MMIO_REMAP) and
expose mmio page of HDP registers to user space through this new
memory type.
v2: moved remapped hdp regs to adev struct
v3: rename the new memory type to ALLOC_MEM_FLAGS_MMIO_REMAP
v4: use more generic function name
Change-Id:
Remap HDP_MEM_COHERENCY_FLUSH_CNTL and HDP_REG_COHERENCY_FLUSH_CNTL
to an empty page in mmio space. We will later map this page to process
space so application can flush hdp. This can't be done properly at
those registers' original location because it will expose more than
desired registers to proc
No, i mean the actual HW fence which signals when the job finished execution on
the HW.
Andrey
On 4/23/19 11:19 AM, Zhou, David(ChunMing) wrote:
do you mean fence timer? why not stop it as well when stopping sched for the
reason of hw reset?
Original Message
Subject: Re: [PAT
On Tue, Apr 23, 2019 at 02:16:53PM +, Kazlauskas, Nicholas wrote:
> On 4/23/19 10:10 AM, Dan Carpenter wrote:
> > Hello David Francis,
> >
> > This is a semi-automatic email about new static checker warnings.
> >
> > The patch c238bfe0be9e: "drm/amd/display: If one stream full updates,
> > fu
do you mean fence timer? why not stop it as well when stopping sched for the
reason of hw reset?
Original Message
Subject: Re: [PATCH v5 6/6] drm/amdgpu: Avoid HW reset if guilty job already
signaled.
From: "Grodzovsky, Andrey"
To: "Zhou, David(ChunMing)"
,dri-de...@lists.free
On 4/22/19 8:59 AM, Zhou, David(ChunMing) wrote:
> +Monk to response this patch.
>
>
> 在 2019/4/18 23:00, Andrey Grodzovsky 写道:
>> For later driver's reference to see if the fence is signaled.
>>
>> v2: Move parent fence put to resubmit jobs.
>>
>> Signed-off-by: Andrey Grodzovsky
>> Reviewed-by:
On 4/23/19 10:44 AM, Zhou, David(ChunMing) wrote:
This patch is to fix deadlock between fence->lock and sched->job_list_lock,
right?
So I suggest to just move list_del_init(&s_job->node) from
drm_sched_process_job to work thread. That will avoid deadlock described in the
link.
Do you mean res
On Mon, Apr 22, 2019 at 07:56:26PM -0400, sunpeng...@amd.com wrote:
> From: Leo Li
>
> In preparation for adding aux devices for DP MST, make the IDR
> non-cyclic. That way, hotplug cycling MST devices won't needlessly
> increment the minor version index.
>
> Signed-off-by: Leo Li
I don't reca
On Mon, Apr 22, 2019 at 07:56:27PM -0400, sunpeng...@amd.com wrote:
> From: Leo Li
>
> To give identifiable attributes to MST DP aux devices, we can use the
> MST relative address. Expose this function for later use.
>
> Signed-off-by: Leo Li
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 4 +
On 4/22/19 9:09 AM, Zhou, David(ChunMing) wrote:
> +Monk.
>
> GPU reset is used widely in SRIOV, so need virtulizatino guy take a look.
>
> But out of curious, why guilty job can signal more if the job is already
> set to guilty? set it wrongly?
>
>
> -David
It's possible that the job does compl
Am 23.04.19 um 16:12 schrieb Grodzovsky, Andrey:
On 4/23/19 8:32 AM, Koenig, Christian wrote:
Well you at least have to give me time till after the holidays to get
going again :)
Not sure exactly jet why we need patch number 5.
Probably you missed the mail where I pointed out a bug I found du
Acked-by: Alex Deucher
From: amd-gfx on behalf of Nicholas
Kazlauskas
Sent: Tuesday, April 23, 2019 10:40 AM
To: amd-gfx@lists.freedesktop.org
Cc: Li, Sun peng (Leo); Wentland, Harry; Kazlauskas, Nicholas
Subject: [PATCH] drm/amd/display: Expose DRM_FORMAT_RGB56
This patch is to fix deadlock between fence->lock and sched->job_list_lock,
right?
So I suggest to just move list_del_init(&s_job->node) from
drm_sched_process_job to work thread. That will avoid deadlock described in the
link.
Original Message
Subject: Re: [PATCH v5 3/6] drm
RGB565 support isn't restricted to just the primary plane in DC, so
also expose support for it on overlays.
Cc: Harry Wentland
Cc: Leo Li
Signed-off-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm
On 4/22/19 8:48 AM, Chunming Zhou wrote:
> Hi Andrey,
>
> static void drm_sched_process_job(struct dma_fence *f, struct
> dma_fence_cb *cb)
> {
> ...
> spin_lock_irqsave(&sched->job_list_lock, flags);
> /* remove job from ring_mirror_list */
> list_del_init(&s_job->no
On 4/23/19 10:10 AM, Dan Carpenter wrote:
> Hello David Francis,
>
> This is a semi-automatic email about new static checker warnings.
>
> The patch c238bfe0be9e: "drm/amd/display: If one stream full updates,
> full update all planes" from Mar 29, 2019, leads to the following
> Smatch complaint:
On 4/23/19 8:32 AM, Koenig, Christian wrote:
> Well you at least have to give me time till after the holidays to get
> going again :)
>
> Not sure exactly jet why we need patch number 5.
Probably you missed the mail where I pointed out a bug I found during
testing - I am reattaching the mail an
Hello David Francis,
This is a semi-automatic email about new static checker warnings.
The patch c238bfe0be9e: "drm/amd/display: If one stream full updates,
full update all planes" from Mar 29, 2019, leads to the following
Smatch complaint:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:
OK, i will merge them into amd-staging drm-next.
Andrey
On 4/23/19 9:14 AM, Kazlauskas, Nicholas wrote:
> Feel free to merge 1+2 since they don't really depend on any other work
> in the series and they were previously reviewed.
>
> Nicholas Kazlauskas
>
> On 4/23/19 8:32 AM, Koenig, Christian wr
This series is on top of drm-misc because of panfrost and lima drovers
which are missing form amd-staging-drm-next. Once i land it in drm-misc
I will merge and p[ush it into drm-next.
Andrey
On 4/22/19 10:35 PM, Dieter Nützel wrote:
> Hello Andrey,
>
> this series can't apply (brake on #3) on t
Series is:
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Evan Quan
Sent: Tuesday, April 23, 2019 4:37 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander; Quan, Evan
Subject: [PATCH 5/5] drm/amd/powerplay: support hwmon temperature channel
labels
Feel free to merge 1+2 since they don't really depend on any other work
in the series and they were previously reviewed.
Nicholas Kazlauskas
On 4/23/19 8:32 AM, Koenig, Christian wrote:
> Well you at least have to give me time till after the holidays to get
> going again :)
>
> Not sure exactly
Am 19.04.19 um 19:13 schrieb Alex Deucher:
On Thu, Apr 18, 2019 at 8:09 AM Christian König
wrote:
A lot of root complexes can still do P2P even when PCI devices
don't share a common upstream bridge.
Start adding a whitelist and allow P2P if both participants are
attached to known good root com
Well you at least have to give me time till after the holidays to get
going again :)
Not sure exactly jet why we need patch number 5.
And we should probably commit patch #1 and #2.
Christian.
Am 22.04.19 um 13:54 schrieb Grodzovsky, Andrey:
> Ping for patches 3, new patch 5 and patch 6.
>
> An
These new interfaces(temp1_emergency, temp2_emergency,
temp3_emergency) are supported on SOC15 dGPUs only.
Change-Id: I2552df63f9c8c50294b3940bb2a402217673c2bc
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h | 6 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c| 40
Two new hwmon interfaces(temp2_input and temp3_input) are added.
They are supported on SOC15 dGPUs only.
- V2: correct thermal sensor output
Change-Id: I935c512bd38e080fb8b6e3164c5e5294baff4e91
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c| 45 +++
Expose temp[1-3]_label hwmon interfaces. While temp2_label
and temp3_label are visible for SOC15 dGPUs only.
- V2: correct temp1_label as "edge"
Change-Id: I7f1e10c52ec21d272027554cdf6da97103e0be58
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c| 35 +
That should provide some necessary sensor information.
Change-Id: I898371cef06795c5369a14c4dd3fe8717959d81a
Signed-off-by: Evan Quan
---
.../drm/amd/powerplay/hwmgr/vega12_hwmgr.c| 21 +++
.../drm/amd/powerplay/hwmgr/vega12_hwmgr.h| 3 +++
.../drm/amd/powerplay/smumgr/ve
These new interfaces(temp2_crit, temp2_crit_hyst, temp3_crit,
temp3_crit_hyst) are supported on SOC15 dGPUs only.
Change-Id: Ia87e3f6ad816b51d6680eb74c8f755d6c2b0a6ae
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h | 8 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
On Tue, Apr 23, 2019 at 10:16:50AM +0200, Daniel Vetter wrote:
> On Thu, Apr 18, 2019 at 02:09:25PM +0200, Christian König wrote:
> > Add a peer2peer flag noting that the importer can deal with device
> > resources which are not backed by pages.
> >
> > Signed-off-by: Christian König
>
> Should
On Thu, Apr 18, 2019 at 02:09:25PM +0200, Christian König wrote:
> Add a peer2peer flag noting that the importer can deal with device
> resources which are not backed by pages.
>
> Signed-off-by: Christian König
Should we add something like "Such importers should also support dynamic
dma_buf att
45 matches
Mail list logo
