To fit the latest SMU firmware.
Change-Id: Ib197e6186127121b4ae276639fa66677094a7d01
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/inc/smu11_driver_if_arcturus.h | 2 +-
drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h| 2 +-
2 files changed, 2 insertions(+), 2 deletion
Am 05.11.19 um 07:32 schrieb Zhu, Changfeng:
> From: changzhu
>
> The GRBM register interface is now capable of bursting 1 cycle per
> register wr->wr, wr->rd much faster than previous muticycle per
> transaction done interface. This has caused a problem where
> status registers requiring HW to u
Enable pcie_replay_count interface support on Navi.
Change-Id: Idc770663416ecf45aab8caa19de9cc99b619d2c3
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/nv.c | 14 ++
.../amd/include/asic_reg/nbio/nbio_2_3_smn.h | 28 +++
2 files changed, 42 inserti
Reviewed-by: Le Ma
-Original Message-
From: amd-gfx On Behalf Of Quan, Evan
Sent: Tuesday, November 5, 2019 4:23 PM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan
Subject: [PATCH] drm/amd/powerplay: update Arcturus driver-smu interface header
To fit the latest SMU firmware.
Change-I
Reviewed-by: Kenneth Feng
-Original Message-
From: amd-gfx On Behalf Of Quan, Evan
Sent: Tuesday, November 5, 2019 4:23 PM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan
Subject: [PATCH] drm/amd/powerplay: update Arcturus driver-smu interface header
[CAUTION: External Email]
To fit
Otherwise, the feature enablement will be skipped due to wrong count.
Caused by "drm/amdgpu: fix a race in GPU reset with IB test (v2)".
Change-Id: Id576090d7ce7645a5c98ac160e0af730a51526b0
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 7 +++
drivers/gpu/drm/amd/a
Hi Chris,
Maybe it's better to use amdgpu_ring_emit_reg_wait(ring, reg0, 0, 0); to replace
amdgpu_ring_emit_reg_wait(ring, reg1, 0, 0); ?
http://ontrack-internal.amd.com/browse/SWDEV-192660
Jira ticket recommends to read VM_INVALIDATE_ENG*_REQ.
BR,
Changfeng.
-Original Message-
From: Ko
fix workload bit (WORKLOAD_PPLIB_COMPUTE_BIT) map error
on vega20 and navi asic.
fix commit:
drm/amd/powerplay: add function get_workload_type_map for swsmu
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 2 +-
drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 2 +-
2 file
P-state switch should be performed after all devices from the hive
get initialized.
Change-Id: Ifc7cac9ef0cf250447d2a412da35d601e2ac79ec
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 47 --
1 file changed, 35 insertions(+), 12 deletions(-)
diff --
Added lock protection so that the p-state switch will
be guarded to be sequential. Also update the hive
pstate only all device from the hive are in the same
state.
Change-Id: I165a6f44e8aec1e6da56eefa0fc49d36670e56fe
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +++
the asic callback function of get_pcie_replay_count is not implement on navi
asic,
it will cause null pinter error when read this interface.
Signed-off-by: Kevin Wang
---
drivers/gpu/drm/amd/amdgpu/nv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/
Am 05.11.19 um 11:21 schrieb Zhu, Changfeng:
> Hi Chris,
>
> Maybe it's better to use amdgpu_ring_emit_reg_wait(ring, reg0, 0, 0); to
> replace
> amdgpu_ring_emit_reg_wait(ring, reg1, 0, 0); ?
Good point. I've mixed up request and acknowledge register.
Important is that you need 0 as mask and va
Series is Reviewed-by: Feifei Xu
-Original Message-
From: amd-gfx On Behalf Of Quan, Evan
Sent: 2019年11月5日 18:24
To: amd-gfx@lists.freedesktop.org
Cc: Strawbridge, Michael ; Kim, Jonathan
; Quan, Evan
Subject: [PATCH 1/2] drm/amdgpu: fix possible pstate switch race condition
Added l
From: changzhu
The GRBM register interface is now capable of bursting 1 cycle per
register wr->wr, wr->rd much faster than previous muticycle per
transaction done interface. This has caused a problem where
status registers requiring HW to update have a 1 cycle delay, due
to the register update h
From: changzhu
It needs to add warning to update firmware in gfx9
in case that firmware is too old to have function to
realize dummy read in cp firmware.
Change-Id: I6aef94f0823138f244f1eedb62fde833dd697023
Signed-off-by: changzhu
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 7 +++
1 file c
Am 05.11.19 um 12:42 schrieb Zhu, Changfeng:
> From: changzhu
>
> It needs to add warning to update firmware in gfx9
> in case that firmware is too old to have function to
> realize dummy read in cp firmware.
>
> Change-Id: I6aef94f0823138f244f1eedb62fde833dd697023
> Signed-off-by: changzhu
Revi
Am 05.11.19 um 12:42 schrieb Zhu, Changfeng:
> From: changzhu
>
> The GRBM register interface is now capable of bursting 1 cycle per
> register wr->wr, wr->rd much faster than previous muticycle per
> transaction done interface. This has caused a problem where
> status registers requiring HW to u
On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
> @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct *vma)
> struct gntdev_priv *priv = file->private_data;
>
> pr_debug("gntdev_vma_close %p\n", vma);
> - if (use_ptemod) {
> - /* It is possible that an
Reviewed-by: Marek Olšák
Marek
From: Zhu, Changfeng
Sent: November 4, 2019 02:07
To: Cui, Flora ; brahma_sw_dev ;
amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Liu, Aaron
; Zhang, Hawking ; Huang, Ray
; Huang, Shimmer ; Deucher, Alexander
; Olsak, M
From: Rafael J. Wysocki
Notice that radeon_set_suspend(), which is the only caller of
__pci_complete_power_transition() outside of pci.c, really only
cares about the pci_platform_power_transition() invoked by it,
so export the latter instead of it, update the radeon driver to
call pci_platform_po
On Mon, Nov 04, 2019 at 05:03:31PM -0500, Boris Ostrovsky wrote:
> On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
> > @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct
> > *vma)
> > struct gntdev_priv *priv = file->private_data;
> >
> > pr_debug("gntdev_vma_close %p\n"
On Tue, Oct 15, 2019 at 03:12:32PM -0300, Jason Gunthorpe wrote:
> @@ -250,26 +85,15 @@ static inline int ib_init_umem_odp(struct ib_umem_odp
> *umem_odp)
> ret = -ENOMEM;
> goto out_page_list;
> }
> - }
>
> - mn = mmu_notifier_ge
On Fri, Nov 01, 2019 at 01:54:45PM -0700, Ralph Campbell wrote:
> You can add my Tested-by for the mm and nouveau changes.
> IOW, patches 1-4, 10-11, and 15.
>
> Tested-by: Ralph Campbell
Got it, thanks
Jason
___
amd-gfx mailing list
amd-gfx@lists.fre
On Mon, Nov 4, 2019 at 12:24 PM Daniel Vetter wrote:
>
> On Mon, Nov 04, 2019 at 12:05:40PM -0500, Alex Deucher wrote:
> > On Mon, Nov 4, 2019 at 11:55 AM Daniel Vetter wrote:
> > >
> > > On Mon, Nov 04, 2019 at 03:23:09PM +, Harry Wentland wrote:
> > > > On 2019-11-04 5:53 a.m., Daniel Vette
On Mon, Nov 4, 2019 at 6:04 PM Dieter Nützel wrote:
>
> Hello Alex,
>
> like AMD...;-)
>
> [Why]
> 5.3-rcX (-rc3)
> - has broken (regressed) block layer (CD/DVD, games...) - fixed in 5.3
> final
> - ACPI (power management) regression - fixed in 5.3 final
> - USB 3.1/3.2 regression (5.000 vs 10.000
On Tue, Nov 5, 2019 at 1:52 PM Alex Deucher wrote:
>
> On Mon, Nov 4, 2019 at 12:24 PM Daniel Vetter wrote:
> >
> > On Mon, Nov 04, 2019 at 12:05:40PM -0500, Alex Deucher wrote:
> > > On Mon, Nov 4, 2019 at 11:55 AM Daniel Vetter wrote:
> > > >
> > > > On Mon, Nov 04, 2019 at 03:23:09PM +, H
On 2019-11-05 8:14 a.m., Daniel Vetter wrote:
> On Tue, Nov 5, 2019 at 1:52 PM Alex Deucher wrote:
>>
>> On Mon, Nov 4, 2019 at 12:24 PM Daniel Vetter wrote:
>>>
>>> On Mon, Nov 04, 2019 at 12:05:40PM -0500, Alex Deucher wrote:
On Mon, Nov 4, 2019 at 11:55 AM Daniel Vetter wrote:
>
>>
On Tue, Nov 5, 2019 at 3:17 PM Harry Wentland wrote:
>
>
>
> On 2019-11-05 8:14 a.m., Daniel Vetter wrote:
> > On Tue, Nov 5, 2019 at 1:52 PM Alex Deucher wrote:
> >>
> >> On Mon, Nov 4, 2019 at 12:24 PM Daniel Vetter wrote:
> >>>
> >>> On Mon, Nov 04, 2019 at 12:05:40PM -0500, Alex Deucher wrot
Reviewed-by: Kent Russell
I'll try to get on the actual implementation soon.
Kent
-Original Message-
From: amd-gfx On Behalf Of Wang,
Kevin(Yang)
Sent: Tuesday, November 5, 2019 6:02 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Yuan, Xiaojie
; Li, Candice ; Wang, Ke
Reviewed-by: Kenneth Feng mailto:kenneth.f...@amd.com>>
在 2019年11月5日，下午6:23，Wang, Kevin(Yang)
mailto:kevin1.w...@amd.com>> 写道：
fix workload bit (WORKLOAD_PPLIB_COMPUTE_BIT) map error
on vega20 and navi asic.
fix commit:
drm/amd/powerplay: add function get_workload_type_map for swsmu
Signed-of
On 2019-11-05 9:23 a.m., Daniel Vetter wrote:
> On Tue, Nov 5, 2019 at 3:17 PM Harry Wentland wrote:
>>
>>
>>
>> On 2019-11-05 8:14 a.m., Daniel Vetter wrote:
>>> On Tue, Nov 5, 2019 at 1:52 PM Alex Deucher wrote:
On Mon, Nov 4, 2019 at 12:24 PM Daniel Vetter wrote:
>
> On Mo
On Tue, Nov 5, 2019 at 3:39 PM Harry Wentland wrote:
>
>
>
> On 2019-11-05 9:23 a.m., Daniel Vetter wrote:
> > On Tue, Nov 5, 2019 at 3:17 PM Harry Wentland wrote:
> >>
> >>
> >>
> >> On 2019-11-05 8:14 a.m., Daniel Vetter wrote:
> >>> On Tue, Nov 5, 2019 at 1:52 PM Alex Deucher wrote:
>
>
From: Leo Li
[Why]
For DCN hardware, the crtc_high_irq handler is assigned to the vstartup
interrupt. This is different from DCE, which has it assigned to vblank
start.
We'd like to send vblank and user events at vstartup because:
* It happens close enough to vupdate - the point of no return f
From: Leo Li
[Why]
On DCN hardware, the crtc_high_irq handler makes vupdate_high_irq
handler redundant.
All the vupdate handler does is handle vblank events, and update vrr
for DCE hw (excluding VEGA, more on that later). As far as usermode is
concerned. vstartup happens close enough to vupdate
From: Leo Li
[Why]
On DCN hardware, the crtc_high_irq handler makes vupdate_high_irq
handler redundant.
All the vupdate handler does is handle vblank events, and update vrr
for DCE hw (excluding VEGA, more on that later). As far as usermode is
concerned. vstartup happens close enough to vupdate
On 2019-11-05 10:34 a.m., sunpeng...@amd.com wrote:
> From: Leo Li
>
> [Why]
>
> For DCN hardware, the crtc_high_irq handler is assigned to the vstartup
> interrupt. This is different from DCE, which has it assigned to vblank
> start.
>
> We'd like to send vblank and user events at vstartup bec
On 2019-11-05 10:58 a.m., sunpeng...@amd.com wrote:
> From: Leo Li
>
> [Why]
>
> On DCN hardware, the crtc_high_irq handler makes vupdate_high_irq
> handler redundant.
>
> All the vupdate handler does is handle vblank events, and update vrr
> for DCE hw (excluding VEGA, more on that later). As
Hi Christian,
I found the reason why page tables are not freed when unmapping. All the
pts are reserved, then they are not freed until vm fini. So the
consequences are old pts and new pts for the same VAs will exist till vm
fini. In KFD big buffer strees test, multiple times of mapping and
unm
Please see inline.
Jon
-Original Message-
From: Quan, Evan
Sent: Tuesday, November 5, 2019 5:24 AM
To: amd-gfx@lists.freedesktop.org
Cc: Kim, Jonathan ; Strawbridge, Michael
; Quan, Evan
Subject: [PATCH 2/2] drm/amdgpu: perform p-state switch after the whole hive
initialized
P-state
DP 1.4 edid corruption test requires source DUT to write calculated
CRC, not the corrupted CRC from reference sink.
Return the calculated CRC back, and initiate the required sequence.
-v2: Have separate routine for returning real CRC
-v3: Rewrite checksum computation routine to avoid duplicated
Hi Jon,
Does that mean we can simply use this instead?
+ if (mgpu_info.num_dgpu == adev->gmc.xgmi.num_physical_nodes -
1) {
Thanks,
Michael
From: Kim, Jonathan
Sent: 05 November 2019 11:32 AM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: St
Yes that's correct. This should fix the issue.
Jon
From: Strawbridge, Michael
Sent: Tuesday, November 5, 2019 11:40 AM
To: Kim, Jonathan ; Quan, Evan ;
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/amdgpu: perform p-state switch after the whole
hive initialized
Hi Jon,
Does tha
+ for (i = 0; i < mgpu_info.num_gpu; i++) {
Also while num_physical_nodes should be used here instead. It doesn't make
sense to have a pre-condition check i.e. (if (mgpu_info.num_dgpu ==
adev->gmc.xgmi.num_physical_nodes - 1) ) against the total number of nodes
while the l
On 2019-11-05 11:15 a.m., Kazlauskas, Nicholas wrote:
> On 2019-11-05 10:34 a.m., sunpeng...@amd.com wrote:
>> From: Leo Li
>>
>> [Why]
>>
>> For DCN hardware, the crtc_high_irq handler is assigned to the vstartup
>> interrupt. This is different from DCE, which has it assigned to vblank
>> start
Hi Eric,
Ah! Yeah that is a well known issue.
Basic problem is that for releasing the BOs we need to reserve them to
check if they are idle or not.
I've got a branch with a TTM change to avoid that, but essentially that
is a huge problem which needs a rather big change in memory management
to
On 2019-11-05 11:16 a.m., Kazlauskas, Nicholas wrote:
> On 2019-11-05 10:58 a.m., sunpeng...@amd.com wrote:
>> From: Leo Li
>>
>> [Why]
>>
>> On DCN hardware, the crtc_high_irq handler makes vupdate_high_irq
>> handler redundant.
>>
>> All the vupdate handler does is handle vblank events, and up
From: Leo Li
[Why]
On DCN hardware, the crtc_high_irq handler makes vupdate_high_irq
handler redundant.
All the vupdate handler does is handle vblank events, and update vrr
for DCE hw (excluding VEGA, more on that later). As far as usermode is
concerned. vstartup happens close enough to vupdate
On 2019-11-05 2:01 p.m., sunpeng...@amd.com wrote:
> From: Leo Li
>
> [Why]
>
> On DCN hardware, the crtc_high_irq handler makes vupdate_high_irq
> handler redundant.
>
> All the vupdate handler does is handle vblank events, and update vrr
> for DCE hw (excluding VEGA, more on that later). As
From: Leo Li
[Why]
On DCN hardware, the crtc_high_irq handler makes vupdate_high_irq
handler redundant.
All the vupdate handler does is handle vblank events, and update vrr
for DCE hw (excluding VEGA, more on that later). As far as usermode is
concerned. vstartup happens close enough to vupdate
On 01.11.19 19:26, Jason Gunthorpe wrote:
On Mon, Oct 28, 2019 at 05:10:25PM -0300, Jason Gunthorpe wrote:
From: Jason Gunthorpe
DMA_SHARED_BUFFER can not be enabled by the user (it represents a library
set in the kernel). The kconfig convention is to use select for such
symbols so they are tu
On 11/4/19 9:31 PM, Jason Gunthorpe wrote:
> On Mon, Nov 04, 2019 at 05:03:31PM -0500, Boris Ostrovsky wrote:
>> On 10/28/19 4:10 PM, Jason Gunthorpe wrote:
>>> @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct
>>> *vma)
>>> struct gntdev_priv *priv = file->private_data;
On 2019-11-05 2:07 p.m., sunpeng...@amd.com wrote:
> From: Leo Li
>
> [Why]
>
> On DCN hardware, the crtc_high_irq handler makes vupdate_high_irq
> handler redundant.
>
> All the vupdate handler does is handle vblank events, and update vrr
> for DCE hw (excluding VEGA, more on that later). As f
On 2019-11-05 1:32 p.m., Li, Sun peng (Leo) wrote:
>
>
> On 2019-11-05 11:15 a.m., Kazlauskas, Nicholas wrote:
>> On 2019-11-05 10:34 a.m., sunpeng...@amd.com wrote:
>>> From: Leo Li
>>>
>>> [Why]
>>>
>>> For DCN hardware, the crtc_high_irq handler is assigned to the vstartup
>>> interrupt. This
On 10/28/19 1:10 PM, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> Now that we have KERNEL_HEADER_TEST all headers are generally compile
> tested, so relying on makefile tricks to avoid compiling code that depends
> on CONFIG_MMU_NOTIFIER is more annoying.
>
> Instead follow the usual patte
Using unified VBIOS has performance drop in sriov environment.
The fix is switching to another register instead.
Signed-off-by: Eric Huang
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/
On 2019-11-05 5:03 p.m., Huang, JinHuiEric wrote:
> Using unified VBIOS has performance drop in sriov environment.
> The fix is switching to another register instead.
>
> Signed-off-by: Eric Huang
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 18 +++---
> 1 file changed, 15 inser
Using unified VBIOS has performance drop in sriov environment.
The fix is switching to another register instead.
Signed-off-by: Eric Huang
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu
Reviewed-by: Alex Deucher
From: Quan, Evan
Sent: Tuesday, November 5, 2019 5:18 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject: [PATCH] drm/amdgpu: register gpu instance before fan boost feature
enablment
Otherwise, the featu
On 2019-11-01 7:03 p.m., Zhao, Yong wrote:
>
> > + /* only leave the offset segment */
> > + vma->vm_pgoff &= (1ULL << (KFD_MMAP_GPU_ID_SHIFT - PAGE_SHIFT)) -
> 1;
>
> You're now open-coding what used to be done by the
> KFD_MMAP_OFFSET_VALUE_GET macro. I don't see how this
On 2019-11-05 5:26 p.m., Huang, JinHuiEric wrote:
> Using unified VBIOS has performance drop in sriov environment.
> The fix is switching to another register instead.
>
> Signed-off-by: Eric Huang
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 19
On Tue, Nov 5, 2019 at 5:26 PM Huang, JinHuiEric
wrote:
>
> Using unified VBIOS has performance drop in sriov environment.
> The fix is switching to another register instead.
>
> Signed-off-by: Eric Huang
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 19 ---
> 1 file changed, 1
Okay. I will delete that line.
Regards,
Yong
From: Kuehling, Felix
Sent: Tuesday, November 5, 2019 5:34 PM
To: Zhao, Yong ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdkfd: Simplify the mmap offset related bit operations
On 2019-11-01 7:03 p.m., Z
drivers/gpu/drm/amd/powerplay/renoir_ppt.c:186:2: error: missing braces
around initializer [-Werror=missing-braces]
SmuMetrics_t metrics = {0};
^
Fixes: 8b8031703bd7 ("drm/amd/powerplay: implement sysfs for getting dpm clock")
Signed-off-by: Raul E Rangel
---
drivers/gpu/drm/amd/powerpla
The new code uses straightforward bit shifts and thus has better readability.
Change-Id: I0c1f7cca7e24ddb7b4ffe1cb0fa71943828ae373
Signed-off-by: Yong Zhao
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 10 --
drivers/gpu/drm/amd/amdkfd/kfd_events.c | 1 -
drivers/gpu/drm/amd/amdkfd/kf
On 2019-11-05 6:06 p.m., Alex Deucher wrote:
> On Tue, Nov 5, 2019 at 5:26 PM Huang, JinHuiEric
> wrote:
>> Using unified VBIOS has performance drop in sriov environment.
>> The fix is switching to another register instead.
>>
>> Signed-off-by: Eric Huang
>> ---
>> drivers/gpu/drm/amd/amdgpu/g
Hi Alex,
Under the SRIOV mode, the L1 policy prevent the write to
mmRLC_CAPTURE_GPU_CLOCK_COUNT on VF, so the RLC_GPU_CLOCK_COUNT_LSB/MSB doesn't
get updated for each read under SRIOV VF.
On the other hand, the read from RLC_REFCLOCK_TIMESTAMP_LSB/MSB doesn't rely on
any write, so it is availa
Taking a look at this again, it's not an indexing issue, it's a placement
problem. I don't think this solution will work if we expect to pstate switch
all gpus.
>From amdgpu_kms.c, amdgpu_register_gpu_instance comes after
>amdgpu_device_init. This means we'll never reach mgpu_info.num_gpu ==
Thanks Jon.
Per discussed in another mail thread, this should be applied after the patch
below
https://lists.freedesktop.org/archives/amd-gfx/2019-November/042160.html
Sorry for missing this important information.
Regards,
Evan
From: Kim, Jonathan
Sent: Wednesday, November 6, 2019 10:18 AM
To: S
No problem. With the incoming patch referenced below, this patch should be ok
since it doesn't break the build.
Reviewed-by: Jonathan Kim
From: Quan, Evan
Sent: Tuesday, November 5, 2019 10:11 PM
To: Kim, Jonathan ; Strawbridge, Michael
; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH 2/
Hi, gentle ping ? Thx in advance.
On Tue, Oct 8, 2019 at 11:15 AM Julien Isorce
wrote:
> Hi Harry,
>
> I can reproduce on LG, Samsung and NEC monitors.
>
> "Have you checked whether the driver picks RGB or YCBCR420 without your
> patch?" -> it was selecting RGB .
>
> For example on https://commo
For driver reload test, it will report "can't enable
MSI (MSI-X already enabled)".
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
inde
For driver reload test, it will report "can't enable
MSI (MSI-X already enabled)".
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
b/drivers/gpu/drm/amd/amdgpu/amdgp
Sorry, please ignore this, will send another patch later.
Best wishes
Emily Deng
>-Original Message-
>From: Emily Deng
>Sent: Wednesday, November 6, 2019 2:18 PM
>To: amd-gfx@lists.freedesktop.org
>Cc: Deng, Emily
>Subject: [PATCH] drm/amdgpu: Need to disable msix when unloading drive
Hi all,
Please help to review this. This is to fix driver reload issue.
Best wishes
Emily Deng
>-Original Message-
>From: Emily Deng
>Sent: Wednesday, November 6, 2019 2:24 PM
>To: amd-gfx@lists.freedesktop.org
>Cc: Deng, Emily
>Subject: [PATCH] drm/amdgpu: Need to disable msix whe
Guest driver can be unloaded while engines still using some backend resources
which whould lead to guest driver unload failure.
Need to add mutex lock to protect backend resources from concurrent operations
Before entering powergating mode, VCE and UVD need to check if backend
resources are still
Unloading driver has call trace when unloading happens
2s after loading driver.
Since ring test are delayed after initializing driver,
it is possible that driver has been unloaded before or
while doing ring test.
Add mutex to prevent ring test and driver finalization
occurs at the same time and c
smu_enable_umd_pstate() will try to get the smu->mutex which was already
hold by its parent API smu_force_performance_level() on the call path.
Thus deadlock happens.
Change-Id: Ic4d3c7d06eb47eab2ea42b98f399cd95ab320f0c
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 19
Reviewed-by: Feifei Xu
-Original Message-
From: amd-gfx On Behalf Of Quan, Evan
Sent: Wednesday, November 6, 2019 2:57 PM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan
Subject: [PATCH] drm/amd/powerplay: fix deadlock on setting
power_dpm_force_performance_level
smu_enable_umd_pst
78 matches
Mail list logo
