On 2021/10/25 下午11:18, Andrey Grodzovsky wrote:
>
> On 2021-10-24 10:56 p.m., JingWen Chen wrote:
>> On 2021/10/23 上午4:41, Andrey Grodzovsky wrote:
>>> What do you mean by underflow in this case ? You mean use after free
>>> because of extra dma_fence_put() ?
>> yes
>
>
> Then maybe update the d
On 2021-10-25 3:56 p.m., Christian König wrote:
In general I'm all there to get this fixed, but there is one major
problem: Drivers don't expect the lock to be dropped.
I am probably missing something but in my approach we only modify the
code for those clients that call dma_fence_signal,
no
On Wed, Oct 13, 2021 at 02:12:20PM -0400, Mark Yacoub wrote:
> From: Mark Yacoub
>
> [Why]
> 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
> or Degamma props in the new CRTC state, allowing any invalid size to
> be passed on.
> 2. Each driver has its own LUT size, whi
On 10/24/21 21:16, Alistair Popple wrote:
MIGRATE_PFN_LOCKED is used to indicate to migrate_vma_prepare() that a
source page was already locked during migrate_vma_collect(). If it
wasn't then the a second attempt is made to lock the page. However if
the first attempt failed it's unlikely a seco
Am 2021-10-25 um 5:58 a.m. schrieb Lang Yu:
> Actually, cu_mask has been copied to mqd memory and
> does't have to persist in queue_properties. Remove it
> from queue_properties.
>
> And use struct mqd_update_info to store such properties,
> then pass it to update queue operation.
>
> v2:
> * Renam
(Sorry for the noise, had to resend because I typo'd amd's mailing list
email address by accident)
Just resubmitting this patch series from AMD with _very_ minor changes
(just a typo and fixing a debug message) so that this can be pushed
upstream with a proper patchwork link. Will be pushing this
From: Bhawanpreet Lakha
[Why]
Add DP2 MST and debugfs support
[How]
Update the slot info based on the link encoding format
Reviewed-by: "Lin, Wayne"
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Fangzhi Zuo
Signed-off-by: Lyude Paul
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29
From: Fangzhi Zuo
[Why]
configure/call DC interface for DP2 mst support. This is needed to make DP2
mst work.
[How]
- add encoding type, logging, mst update/reduce payload functions
Use the link encoding to determine the DP type (1.4 or 2.0) and add a
flag to dc_stream_update to determine wheth
From: Bhawanpreet Lakha
8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.
In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP.
From: Bhawanpreet Lakha
This code path is used during commit, and we dont expect things to fail
during the commit stage, so remove this.
Signed-off-by: Bhawanpreet Lakha
Reviewed-by: Lyude Paul
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
1 file changed, 1
From: Bhawanpreet Lakha
[Why]
Add DP2 MST and debugfs support
[How]
Update the slot info based on the link encoding format
Reviewed-by: "Lin, Wayne"
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Fangzhi Zuo
Signed-off-by: Lyude Paul
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29
From: Fangzhi Zuo
[Why]
configure/call DC interface for DP2 mst support. This is needed to make DP2
mst work.
[How]
- add encoding type, logging, mst update/reduce payload functions
Use the link encoding to determine the DP type (1.4 or 2.0) and add a
flag to dc_stream_update to determine wheth
From: Bhawanpreet Lakha
8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.
In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP.
In general I'm all there to get this fixed, but there is one major
problem: Drivers don't expect the lock to be dropped.
What we could do is to change all drivers so they call always call the
dma_fence_signal functions and drop the _locked variants. This way we
could move calling the callback
On 2021-10-25 14:52, Alex Deucher wrote:
> Stutter mode is a power saving feature on GPUs, however at
> least one early raven system exhibits stability issues with
> it. Add a quirk to disable it for that system.
>
> Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214417
> Signed-off-by: Alex De
Adding back Daniel (somehow he got off the addresses list) and Chris who
worked a lot in this area.
On 2021-10-21 2:34 a.m., Christian König wrote:
Am 20.10.21 um 21:32 schrieb Andrey Grodzovsky:
On 2021-10-04 4:14 a.m., Christian König wrote:
The problem is a bit different.
The callback
Stutter mode is a power saving feature on GPUs, however at
least one early raven system exhibits stability issues with
it. Add a quirk to disable it for that system.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214417
Signed-off-by: Alex Deucher
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_
[AMD Official Use Only]
> -Original Message-
> From: Kuehling, Felix
> Sent: Monday, October 25, 2021 1:30 PM
> To: Tuikov, Luben ; amd-gfx@lists.freedesktop.org
> Cc: Russell, Kent ; Deucher, Alexander
>
> Subject: Re: [PATCH] drm/amdgpu: Restore information reporting in RAS
>
> Am 2
From: Jude Shih
[Why]
DMUB binary is common for both A0 and B0. Hence, driver should
notify FW about the support for DPIA in B0.
[How]
Added dpia_supported bit in dmub_fw_boot_options and will be set
only for B0.
Assign dpia_supported to true before dm_dmub_hw_init
in B0 case.
Signed-off-by: J
From: Jude Shih
[Why]
Notify data from outbox corrupt, the notify type should be 2 (HPD) instead of 0
(No data). We copied the address instead of the value. The memory might be
freed in the end of outbox IRQ
[How]
We should allocate the memory of notify and copy the whole content from outbox
to
From: Michael Strauss
[WHY]
On certain configs, SMU clock table voltages don't match which cause parser
to behave incorrectly by leaving dcfclk and socclk table entries unpopulated.
[HOW]
Currently the function that finds the corresponding clock for a given voltage
only checks for exact voltage
From: Meenakshikumar Somasundaram
[Why]
- DPIA MST slot registers are not programmed during payload
allocation and hence MST does not work with DPIA.
- HPD RX interrupts are not handled for DPIA.
[How]
- Added inbox command to program the MST slots whenever
payload allocation happens for DPIA
[Why]
A deadlock in the kernel occurs when we fallback from the V3 to V2
add_topology_to_display or remove_topology_to_display because they
both try to acquire the dtm_mutex but recursive locking isn't
supported on mutex_lock().
[How]
Make the mutex_lock/unlock more fine grained and move them up s
This patchset is a mini-promotion to fix USBC lightup
on DCN31B for both SST and MST displays.
There are five issues at play here:
1. Invalid clock table causing mode validation to fail
2. HDCP downgrade to v2 causes deadlock
3. MST payload allocation not being propagated
4. PHY mux selection not
sbios settings
any of these raise a suspicion?
screenshot from the ASRockRack X470D4U's BIOS setup:
https://imgur.com/a/rdhGQNy
Am 2021-10-25 um 12:02 p.m. schrieb Luben Tuikov:
> A recent patch took away the reporting of number of RAS records and
> the threshold due to the way it was edited/spliced on top of the code.
> This patch restores this reporting.
>
> Cc: Kent Russell
> Cc: Alex Deucher
> Fixes: 07df2fb092d09e ("
Hi Robin,
Am 25.10.21 um 18:01 schrieb Robin Murphy:
On 2021-10-25 12:23, Christian König wrote:
Hi Paul,
not sure how the IOMMU gives out addresses, but the printed ones look
suspicious to me. Something like we are using an invalid address like
-1 or similar.
FWIW those look like believab
hi
The driver is not able to find the vbios image which is required for
the driver to properly enumerate the hardware. I would guess it's a
platform issue. Is there a newer sbios image available for your
platform?
...
I would start with an sbios update is possible.
not that i'm aware.
thi
[Public]
Does the message need a mention about the newly added option to ignore
threshold?
Thanks,
Lijo
From: amd-gfx on behalf of Luben Tuikov
Sent: Monday, October 25, 2021 9:32:20 PM
To: amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Russell, Kent ;
De
On Mon, Oct 25, 2021 at 12:02 PM Luben Tuikov wrote:
>
> A recent patch took away the reporting of number of RAS records and
> the threshold due to the way it was edited/spliced on top of the code.
> This patch restores this reporting.
>
> Cc: Kent Russell
> Cc: Alex Deucher
> Fixes: 07df2fb092d
[AMD Official Use Only]
Thanks Luben
Reviewed-by: Kent Russell
Kent
> -Original Message-
> From: Tuikov, Luben
> Sent: Monday, October 25, 2021 12:02 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Tuikov, Luben ; Russell, Kent
> ;
> Deucher, Alexander
> Subject: [PATCH] drm/amdgpu: R
A recent patch took away the reporting of number of RAS records and
the threshold due to the way it was edited/spliced on top of the code.
This patch restores this reporting.
Cc: Kent Russell
Cc: Alex Deucher
Fixes: 07df2fb092d09e ("drm/amdgpu: Add kernel parameter support for ignoring
bad page
On 2021-10-25 12:23, Christian König wrote:
Hi Paul,
not sure how the IOMMU gives out addresses, but the printed ones look
suspicious to me. Something like we are using an invalid address like -1
or similar.
FWIW those look like believable DMA addresses to me, assuming that the
DMA mapping
On 2021-10-25 11:12, Paul Menzel wrote:
> Dear Nicholas, dear Harry,
>
>
> On 25.10.21 16:42, Kazlauskas, Nicholas wrote:
>> On 2021-10-25 9:58 a.m., Harry Wentland wrote:
>
>>> On 2021-10-25 07:25, Paul Menzel wrote:
>
On 24.10.21 15:31, Rodrigo Siqueira wrote:
> From: Wenjing Liu
On 2021-10-24 10:56 p.m., JingWen Chen wrote:
On 2021/10/23 上午4:41, Andrey Grodzovsky wrote:
What do you mean by underflow in this case ? You mean use after free because of
extra dma_fence_put() ?
yes
Then maybe update the description because 'underflow' is very confusing
On 2021-10-2
On 10/25/2021 7:45 PM, Alex Deucher wrote:
On Mon, Oct 25, 2021 at 9:48 AM PGNet Dev wrote:
( cc'ing this here, OP -> dri-devel@ )
i've a dual gpu system
inxi -GS
System:Host: ws05 Kernel: 5.14.13-200.fc34.x86_64 x86_64
bits: 64 Console: tty pts/0
Dear Nicholas, dear Harry,
On 25.10.21 16:42, Kazlauskas, Nicholas wrote:
On 2021-10-25 9:58 a.m., Harry Wentland wrote:
On 2021-10-25 07:25, Paul Menzel wrote:
On 24.10.21 15:31, Rodrigo Siqueira wrote:
From: Wenjing Liu
[why]
We have a regression that cause maximize lane settings to
Hi Paul,
First of all, thanks for your feedback.
Before I address your comments, I just want to give you some background
about this type of patchset.
All patches in this series are from a week ago and came from all display
teams in AMD. Keep in mind that we share our display core with other
On 2021-10-25 9:58 a.m., Harry Wentland wrote:
On 2021-10-25 07:25, Paul Menzel wrote:
Dear Wenjing, dear Rodrigo,
On 24.10.21 15:31, Rodrigo Siqueira wrote:
From: Wenjing Liu
[why]
We have a regression that cause maximize lane settings to use
uninitialized data from unused lanes.
Which
On Mon, Oct 25, 2021 at 9:48 AM PGNet Dev wrote:
>
> ( cc'ing this here, OP -> dri-devel@ )
>
> i've a dual gpu system
>
> inxi -GS
> System:Host: ws05 Kernel: 5.14.13-200.fc34.x86_64 x86_64
> bits: 64 Console: tty pts/0
>Distro: Fedora rele
On 2021-10-25 07:25, Paul Menzel wrote:
> Dear Wenjing, dear Rodrigo,
>
>
> On 24.10.21 15:31, Rodrigo Siqueira wrote:
>> From: Wenjing Liu
>>
>> [why]
>> We have a regression that cause maximize lane settings to use
>> uninitialized data from unused lanes.
>
> Which commit caused the regres
adding a trace,
...
[5.201715] [drm] amdgpu kernel modesetting enabled.
[5.201902] amdgpu: Virtual CRAT table created for CPU
[5.201909] amdgpu: Topology: Add CPU node
[5.201968] checking generic (e100 1d5000) vs hw (c000 1000)
[5.201969] checking generic (e100
( cc'ing this here, OP -> dri-devel@ )
i've a dual gpu system
inxi -GS
System:Host: ws05 Kernel: 5.14.13-200.fc34.x86_64 x86_64
bits: 64 Console: tty pts/0
Distro: Fedora release 34 (Thirty Four)
(1) Graphics: Device-1: NVIDIA
[Public]
Hi all,
This week this patchset was tested on the following systems:
HP Envy 360, with Ryzen 5 4500U, with the following display types: eDP 1080p
60hz, 4k 60hz (via USB-C to DP/HDMI), 1440p 144hz (via USB-C to DP/HDMI),
1680*1050 60hz (via USB-C to DP and then DP to DVI/VGA)
AMD
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation and memory alignment logic from
i915 drive
Move the base i915 buddy allocator code into drm
- Move i915_buddy.h to include/drm
- Move i915_buddy.c to drm root folder
- Rename "i915" string with "drm" string wherever applicable
- Rename "I915" string with "DRM" string wherever applicable
- Fix header file dependencies
- Fix alignment issues
- Remove drm_mm references and replace with drm buddy functionalities
- Add res cursor support for drm buddy
Signed-off-by: Arunpravin
---
.../gpu/drm/amd/amdgpu/amdgpu_res_cursor.h| 97 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_m
Move shared vram inline functions and structs
into a header file
Signed-off-by: Arunpravin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h | 51
1 file changed, 51 insertions(+)
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h
diff --git a/drivers/gpu/drm/a
add drm_buddy_free_unused_pages() support on
contiguous allocation
Signed-off-by: Arunpravin
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.
On contiguous allocation, we round up the size
to the *next* power of 2, implement a function
to free the unused pages after the newly allocate block.
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 103
include/drm/drm_buddy.h | 4 ++
2 fil
add top down allocation support to i915 driver
Signed-off-by: Arunpravin
---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index 75197ba6e40d..963
Implemented a function which walk through the order list,
compares the offset and returns the maximum offset block,
this method is unpredictable in obtaining the high range
address blocks which depends on allocation and deallocation.
for instance, if driver requests address at a low specific
range,
Dear Christian,
Thank you for your reply.
On 25.10.21 13:23, Christian König wrote:
not sure how the IOMMU gives out addresses, but the printed ones look
suspicious to me. Something like we are using an invalid address like -1
or similar.
Can you try that on an up to date kernel as well?
Dear Wenjing, dear Rodrigo,
On 24.10.21 15:31, Rodrigo Siqueira wrote:
From: Wenjing Liu
[why]
We have a regression that cause maximize lane settings to use
uninitialized data from unused lanes.
Which commit caused the regression? Please amend the commit message.
This will cause link trai
Hi Paul,
not sure how the IOMMU gives out addresses, but the printed ones look
suspicious to me. Something like we are using an invalid address like -1
or similar.
Can you try that on an up to date kernel as well? E.g. ideally bleeding
edge amd-staging-drm-next from Alex repository.
Regard
Dear Linux folks,
On a Dell OptiPlex 5055, Linux 5.10.24 logged the IOMMU messages below.
(GPU hang in amdgpu issue #1762 [1] might be related.)
$ lspci -nn -s 05:00.0
05:00.0 VGA compatible controller [0300]: Advanced Micro Devices,
Inc. [AMD/ATI] Oland [Radeon HD 8570 / R7 240/340
[AMD Official Use Only]
Thanks, will and comment as you suggested.
Regards,
Tao
From: Zhang, Hawking
Sent: Monday, October 25, 2021 5:29 PM
To: Zhou1, Tao ; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: skip GPRs init for some CU settings on
A
Actually, cu_mask has been copied to mqd memory and
does't have to persist in queue_properties. Remove it
from queue_properties.
And use struct mqd_update_info to store such properties,
then pass it to update queue operation.
v2:
* Rename pqm_update_queue to pqm_update_queue_properties.
* Rename
Currently, queue is updated with data in queue_properties.
And all allocated resource in queue_properties will not
be freed until the queue is destroyed.
But some properties(e.g., cu mask) bring some memory
management headaches(e.g., memory leak) and make code
complex. Actually they have been copi
[AMD Official Use Only]
Please add inline comment to remind us remove this workaround later. Other than
the patch is
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Zhou1, Tao
Sent: Monday, October 25, 2021 16:56
To: amd-gfx@lists.freedesktop.org; Zhang, Hawking
[AMD Official Use Only]
>-Original Message-
>From: Kuehling, Felix
>Sent: Friday, October 22, 2021 1:11 AM
>To: Yu, Lang ; amd-gfx@lists.freedesktop.org
>Cc: Deucher, Alexander ; Huang, Ray
>
>Subject: Re: [PATCH 2/2] drm/amdkfd: Remove cu mask from struct
>queue_properties
>
>Am 2021-1
Skip GPRs init in specific condition since current GPRs init algorithm only
works for some CU settings.
Signed-off-by: Tao Zhou
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c
b/drivers/gpu/drm/amd/amdg
[AMD Official Use Only]
>-Original Message-
>From: Kuehling, Felix
>Sent: Friday, October 22, 2021 12:46 AM
>To: Yu, Lang ; amd-gfx@lists.freedesktop.org
>Cc: Deucher, Alexander ; Huang, Ray
>
>Subject: Re: [PATCH 1/2] drm/amdkfd: Add an optional argument into update
>queue operation
>
63 matches
Mail list logo
