Patch https://patchwork.freedesktop.org/series/106024/ should fix this.
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Mikhail
Gavrilov
Sent: Tuesday, July 19, 2022 7:50 AM
To: amd-gfx list ; Linux List Kernel Mailing
; Christian König
Subject: Command "clinfo" causes
From: "Jiadong.Zhu"
Set register to enable mcbp according to amdgpu_mcbp.
Add sdma preempt_ib function used for debugfs test.
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 53 ++
1 file changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
b/drive
From: "Jiadong.Zhu"
1. Use unmap_queue package to trigger preemption on gfx9
Add trailing fence to track the preemption done.
2. Modify emit_ce_meta emit_de_meta functions
for the resumed ibs.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 +
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c|
ping.
On 07/14/ , Lang Yu wrote:
> The driver can only support AMDGPU_MAX_GFX_RINGS gfx queues
> at the moment. Once enabled gfx queues exceed the limit,
> we will run into problems when setting up gfx rings in
> gfx_xxx_sw_init().
>
> Signed-off-by: Lang Yu
> ---
> drivers/gpu/drm/amd/amdgpu/a
On Wed, Jul 13, 2022 at 5:38 PM Mikhail Gavrilov
wrote:
> # first bad commit: [9cbbd694a58bdf24def2462276514c90cab7cf80] Merge
> drm/drm-next into drm-misc-next
>
Don't know who to thank but the issue disappeared in 5.19 rc7.
--
Best Regards,
Mike Gavrilov.
Hi guys I continue testing 5.19 rc7 and found the bug.
Command "clinfo" causes BUG: kernel NULL pointer dereference, address:
0008 on driver amdgpu.
Here is trace:
[ 1320.203332] BUG: kernel NULL pointer dereference, address: 0008
[ 1320.203338] #PF: supervisor read access
This simplifies existing coherence handling for Arcturus and Aldabaran
to account for !coherent && uncached scenarios.
Cc: Joseph Greathouse
Cc: Alex Deucher
Signed-off-by: Rajneesh Bhardwaj
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 53 +--
1 file changed, 26 insertio
On Thu, 14 Jul 2022 08:00:32 -0700, Christian König wrote:
>
> Am 14.07.22 um 15:33 schrieb Alex Deucher:
> > On Thu, Jul 14, 2022 at 9:09 AM Christian König
> > wrote:
> >> Hi Mauro,
> >>
> >> well the last time I checked drm-tip was clean.
> >>
> >> The revert is necessary because we had some pr
On Mon, 18 Jul 2022 12:56:29 +0200 David Hildenbrand wrote:
> > /*
> > * Try to move out any movable page before pinning the range.
> > */
> > @@ -1919,7 +1948,8 @@ static long check_and_migrate_movable_pages(unsigned
> > long nr_pages,
> >
Am 18.07.22 um 21:32 schrieb Gavin Wan:
The scratch register should be accessed through MMIO instead of RLCG
in SRIOV, since it being used in RLCG register access function.
Fixes: 0e1314781b9c("drm/amdgpu: nuke dynamic gfx scratch reg allocation")
Signed-off-by: Gavin Wan
Change-Id: I888cb3b96
The scratch register should be accessed through MMIO instead of RLCG
in SRIOV, since it being used in RLCG register access function.
Fixes: 0e1314781b9c("drm/amdgpu: nuke dynamic gfx scratch reg allocation")
Signed-off-by: Gavin Wan
Change-Id: I888cb3b96856583e764b35a098bcf8bff01ad90c
---
drive
Applied the series with some minor tweaks to the documentation.
Thanks!
Alex
On Thu, Jul 14, 2022 at 3:18 PM André Almeida wrote:
>
> Add a GFXOFF section at "GPU Power Controls" file, explaining what it is
> and how userspace can interact with it.
>
> Signed-off-by: André Almeida
> ---
> Chan
Applied with a trivial fix for dcn314_resource.c.
Thanks!
Alex
On Sat, Jul 16, 2022 at 3:52 PM Melissa Wen wrote:
>
> Although dcn31_update_soc_for_wm_a() is only called in dml/dcn31/dcn31_fpu by
> dc->res_pool->funcs->update_soc_for_wm_a(dc, context), it's declared in
> dcn31_resource that is
Applied. Thanks!
On Thu, Jul 14, 2022 at 12:45 PM Maíra Canal wrote:
>
> On the dce_v6_0 and dce_v8_0 hpd tear down callback, the tmp variable
> should be written into the control register instead of 0.
>
> Fixes: b00861b9 ("drm/amd/amdgpu: port of DCE v6 to new headers (v3)")
> Fixes: 2285b91c
On Thu, Jul 14, 2022 at 12:46 PM Maíra Canal wrote:
>
> The parameters WritebackPixelFormat and WritebackVRatio are removed as
> they are not used on the function dml30_CalculateWriteBackDISPCLK.
Maybe this is done for consistency with other dml code for other DCN blocks?
Alex
>
> Signed-off-by
Applied. Thanks!
Alex
On Thu, Jul 14, 2022 at 12:46 PM Maíra Canal wrote:
>
> Remove the variable MaxUsedBW from the function
> DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation.
> As a side-effect, the variables MaxPerPlaneVActiveWRBandwidth and
> WRBandwidth ar
Applied. Thanks!
Alex
On Thu, Jul 14, 2022 at 12:46 PM Maíra Canal wrote:
>
> The variable regval from the function enc1_update_generic_info_packet
> and the variables dynamic_range_rgb and dynamic_range_ycbcr from the
> function enc1_stream_encoder_dp_set_stream_attribute are not currently
> u
On Thu, Jul 14, 2022 at 12:46 PM Maíra Canal wrote:
>
> Remove the variable value0 from the function
> dcn10_link_encoder_update_mst_stream_allocation_table.
>
> This was pointed by clang with the following warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_link_encoder.c:1223:11:
>
Applied. Thanks!
Alex
On Thu, Jul 14, 2022 at 12:46 PM Maíra Canal wrote:
>
> Remove the variables dispclk_delay_subtotal and dppclk_delay_subtotal from
> the function dml_rq_dlg_get_dlg_params.
>
> This was pointed by clang with the following warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/
Applied. Thanks!
Alex
On Thu, Jul 14, 2022 at 12:46 PM Maíra Canal wrote:
>
> Remove the unused unsigned int NumberOfStates from the file, which was
> declared but never hooked up.
>
> This was pointed by clang with the following warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/d
Applied. Thanks!
Alex
On Thu, Jul 14, 2022 at 12:45 PM Maíra Canal wrote:
>
> Remove dml32_CalculatedoublePipeDPPCLKAndSCLThroughput function, which is not
> used in
> the codebase.
>
> This was pointed by clang with the following warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32
Applied. Thanks!
Alex
On Thu, Jul 14, 2022 at 12:45 PM Maíra Canal wrote:
>
> Remove the variable clk_src from the function dcn3_get_pix_clk_dividers.
>
> This was pointed by clang with the following warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_clock_source.c:1279:25:
> warnin
Applied. Thanks!
Alex
On Thu, Jul 14, 2022 at 12:45 PM Maíra Canal wrote:
>
> Turn previously global function into a static function as it is not used
> outside the file.
>
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/amd/display/dc/dml/display_mode_vba.c | 2 +-
> drivers/gpu/drm/amd
On 18.07.22 19:52, Felix Kuehling wrote:
> On 2022-07-18 06:50, David Hildenbrand wrote:
>> On 15.07.22 17:05, Alex Sierra wrote:
>>> [WHY]
>>> It makes more sense to have these helpers in zone specific header
>>> file, rather than the generic mm.h
>>>
>>> Signed-off-by: Alex Sierra
>> Acked-by: D
On 2022-07-15 19:54, Alex Sierra wrote:
[WHY]
Unified memory with xnack off should be tracked, as userptr mappings
and legacy allocations do. To avoid oversuscribe system memory when
xnack off.
[How]
Exposing functions reserve_mem_limit and unreserve_mem_limit to SVM
API and call them on every pr
On 2022-07-18 06:50, David Hildenbrand wrote:
On 15.07.22 17:05, Alex Sierra wrote:
[WHY]
It makes more sense to have these helpers in zone specific header
file, rather than the generic mm.h
Signed-off-by: Alex Sierra
Acked-by: David Hildenbrand
Thank you! I don't think I have the authorit
[Public]
Will do.
Alex
From: Kuehling, Felix
Sent: Monday, July 18, 2022 11:29 AM
To: Mike Lothian ; Christian König
Cc: Pan, Xinhui ; amd-gfx@lists.freedesktop.org
; Deucher, Alexander
; Koenig, Christian
Subject: Re: [PATCH] drm/amdgpu: Fix a NULL pointer
Xinhui submitted this patch instead, which should address the same
issue: "drm/amdgpu: Remove one duplicated ef removal"
Alex, can you pick up that patch for drm-fixes for 5.19, if it's not too
late?
Thanks,
Felix
On 2022-07-18 10:58, Mike Lothian wrote:
Is this likely to land before 5.1
Is this likely to land before 5.19 final? It's been nearly 2 weeks
since I said if fixed an issue I was seeing
https://gitlab.freedesktop.org/drm/amd/-/issues/2074
On Fri, 8 Jul 2022 at 10:05, Christian König
wrote:
>
> Hi guys,
>
> well the practice to remove all fences by adding a NULL exclusiv
Am 18.07.22 um 16:55 schrieb Ruijing Dong:
From VCN4, AMDGPU_HW_IP_VCN_ENC is re-used to support
both encoding and decoding jobs.
link: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/245/commits
Reviewed-by: Leo Liu
Signed-off-by: Ruijing Dong
Reviewed-by: Christian König
---
>From VCN4, AMDGPU_HW_IP_VCN_ENC is re-used to support
both encoding and decoding jobs.
link: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/245/commits
Reviewed-by: Leo Liu
Signed-off-by: Ruijing Dong
---
include/uapi/drm/amdgpu_drm.h | 4
1 file changed, 4 insertions(+)
diff
Am 15.07.22 um 07:20 schrieb Jason Wang:
The double `have' is duplicated in line 696, remove one.
The subject line is rather confusing since this isn't related to DMA-buf
at all.
Please change that to "drm/radeon:", apart from that the patch looks
good to me.
Christian.
Signed-off-by:
[AMD Official Use Only - General]
No, we don't plan to clone another one. I will modify the comment only and
remove the bias.
Thanks
Ruijing
-Original Message-
From: Koenig, Christian
Sent: Monday, July 18, 2022 10:37 AM
To: Dong, Ruijing ; Liu, Leo ;
amd-gfx@lists.freedesktop.org
Cc
Am 18.07.22 um 16:14 schrieb Dong, Ruijing:
[AMD Official Use Only - General]
What happened is that the encode ring was extended with decode functionality.
In other words we still use the same format for encoding, we just added another
one for decoding as well.
Just to clarify the format dif
[AMD Official Use Only - General]
>> What happened is that the encode ring was extended with decode
>> functionality. In other words we still use the same format for encoding, we
>> just added another one for decoding as well.
Just to clarify the format difference between legacy encoding and un
Am 18.07.22 um 15:48 schrieb Leo Liu:
On 2022-07-18 02:57, Christian König wrote:
Am 15.07.22 um 22:04 schrieb Ruijing Dong:
From VCN4, AMDGPU_HW_IP_VCN_UNIFIED is used to support
both encoding and decoding jobs, it re-uses the same
queue number of AMDGPU_HW_IP_VCN_ENC.
link:
https://gitlab
On 2022-07-18 02:57, Christian König wrote:
Am 15.07.22 um 22:04 schrieb Ruijing Dong:
From VCN4, AMDGPU_HW_IP_VCN_UNIFIED is used to support
both encoding and decoding jobs, it re-uses the same
queue number of AMDGPU_HW_IP_VCN_ENC.
link:
https://gitlab.freedesktop.org/mesa/drm/-/merge_requ
The double `have' is duplicated in line 696, remove one.
Signed-off-by: Jason Wang
---
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 84843b3b3aef..261fcbae88
[Public]
Hi all,
This week this patchset was tested on the following systems:
HP Envy 360, with Ryzen 5 4500U
Lenovo Thinkpad T14s Gen2, with AMD Ryzen 5 5650U
Sapphire Pulse RX5700XT
Reference AMD RX6800
Engineering board with Ryzen 9 5900H
These systems were tested on the following displ
On 15.07.22 17:05, Alex Sierra wrote:
> From: Alistair Popple
>
> Currently any attempts to pin a device coherent page will fail. This is
> because device coherent pages need to be managed by a device driver, and
> pinning them would prevent a driver from migrating them off the device.
>
> Howev
On 15.07.22 17:05, Alex Sierra wrote:
> With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
> device-managed anonymous pages that are not LRU pages. Although they
> behave like normal pages for purposes of mapping in CPU page, and for
> COW. They do not support LRU lists, NUMA migration
On 15.07.22 17:05, Alex Sierra wrote:
> [WHY]
> It makes more sense to have these helpers in zone specific header
> file, rather than the generic mm.h
>
> Signed-off-by: Alex Sierra
Acked-by: David Hildenbrand
--
Thanks,
David / dhildenb
Am 18.07.22 um 14:08 schrieb yehonsun:
The comments say that the product number is a 16-digit HEX string so the
buffer needs to be at least 17 characters to hold the NUL terminator.
The comments say that the product number is a 16-digit HEX string so the
buffer needs to be at least 17 characters
The comments say that the product number is a 16-digit HEX string so the
buffer needs to be at least 17 characters to hold the NUL terminator.
The comments say that the product number is a 16-digit HEX string so the
buffer needs to be at least 17 characters to hold the NUL terminator.
Signed-off-
On Fri, Jul 15, 2022 at 01:48:56PM +0530, Somalapuram, Amaranath wrote:
>
> On 7/14/2022 9:13 PM, André Almeida wrote:
> > Às 12:06 de 14/07/22, Sebin Sebastian escreveu:
> > > On Tue, Jul 12, 2022 at 12:14:27PM -0300, André Almeida wrote:
> > > > Hi Sebin,
> > > >
> > > > Às 10:29 de 10/07/22, S
45 matches
Mail list logo
