Dear Linux stable folks,
Am 28.10.21 um 16:21 schrieb Alex Deucher:
The DMA mask on SI parts is 40 bits not 44. Copy
paste typo.
Fixes: 244511f386ccb9 ("drm/amdgpu: simplify and cleanup setting the dma mask")
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1762
Acked-by: Christian König
limit the MPO rejection only for DCN1x as its not required on later
versions.
Fixes: d89f6048bdcb ("drm/amd/display: Reject non-zero src_y and src_x for
video planes")
Signed-off-by: Shirish S
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 20 ++-
1 file changed, 11 insert
update user with next level of info about which condition led to
atomic check failure.
Signed-off-by: Shirish S
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 70 ++-
1 file changed, 52 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu
Dear Evan,
Am 08.11.21 um 05:47 schrieb Evan Quan:
Just bail out if the target IP block is already in the desired
powergate/ungate state. This can avoid some duplicate settings
which sometime may cause unexpected issues.
sometime*s*
Please elaborate the kind of issues.
On what systems did y
Dear Shirish,
Am 08.11.21 um 09:15 schrieb Shirish S:
limit the MPO rejection only for DCN1x as its not required on later
it’s
versions.
Where is it documented, that it’s not required for later versions?
Shortly describing the implementation is also useful. Something like:
Require `fill
Dear Shrish,
Am 08.11.21 um 09:40 schrieb Shirish S:
update user with next level of info about which condition led to
atomic check failure.
Signed-off-by: Shirish S
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 70 ++-
1 file changed, 52 insertions(+), 18 deletions(-)
Mhm, good question. Looks like a refcount leak somewhere.
Is that reproducible? If yes could you bisect?
In general I suggest to try to reproduce it on the latest bleeding edge
code first.
Thanks for the notice,
Christian.
Am 05.11.21 um 04:13 schrieb Zzy Wysm:
Another use-after-free on the
Am 05.11.21 um 20:25 schrieb Alex Sierra:
The low 16MB of virtual address space are currently reserved for kernel
mode allocations mapped into user virtual address space. This causes
conflicts with HMM/SVM mappings at low virtual addresses. We tried to
move those kernel mode allocations to the up
Am 05.11.21 um 08:58 schrieb Quan, Evan:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Thursday, November 4, 2021 4:55 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH] drm/amdgpu: fix the Carrizo UVD hang on system
rebo
Hi Paul,
On 11/8/2021 2:25 PM, Paul Menzel wrote:
Dear Shirish,
Am 08.11.21 um 09:15 schrieb Shirish S:
limit the MPO rejection only for DCN1x as its not required on later
it’s
versions.
Where is it documented, that it’s not required for later versions?
This is a workaround to avoid s
Hi Paul,
On 11/8/2021 2:27 PM, Paul Menzel wrote:
Dear Shrish,
Am 08.11.21 um 09:40 schrieb Shirish S:
update user with next level of info about which condition led to
atomic check failure.
Signed-off-by: Shirish S
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 70 ++-
On 11/8/2021 10:17 AM, Evan Quan wrote:
Just bail out if the target IP block is already in the desired
powergate/ungate state. This can avoid some duplicate settings
which sometime may cause unexpected issues.
Change-Id: I66346c69f121df0f5ee20182451313ae4fda2d04
Signed-off-by: Evan Quan
Test
Am 08.11.21 um 12:13 schrieb S, Shirish:
Hi Paul,
On 11/8/2021 2:27 PM, Paul Menzel wrote:
Dear Shrish,
Am 08.11.21 um 09:40 schrieb Shirish S:
update user with next level of info about which condition led to
atomic check failure.
Signed-off-by: Shirish S
---
.../gpu/drm/amd/display/a
make action upon failure in "drm_atomic_add_affected_connectors()"
consistent with the rest of failures in amdgpu_dm_atomic_check().
Signed-off-by: Shirish S
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/
On Mon, Nov 08, 2021 at 09:51:03AM +0100, Paul Menzel wrote:
> Please elaborate the kind of issues.
It fails to reboot on Carrizo-based laptops.
Whoever commits this, pls add
Link: https://lore.kernel.org/r/yv81vidwqlwva...@zn.tnic
so that it is clear what the whole story way.
Thx.
--
Regard
Am 08.11.21 um 12:15 schrieb Borislav Petkov:
On Mon, Nov 08, 2021 at 09:51:03AM +0100, Paul Menzel wrote:
Please elaborate the kind of issues.
It fails to reboot on Carrizo-based laptops.
That doesn't necessary sounds like a good idea to me then.
What exactly is going wrong here? And what i
The check for whether to drain retry faults must be under the mmap write
lock to serialize with munmap notifier callbacks.
We were also missing checks on child ranges. To fix that, simplify the
logic by using a flag rather than checking on each prange. That also
allows draining less freqeuntly whe
[Which address should be used: sshan...@amd.com or shiris...@amd.com?]
Dear Shirish,
Am 08.11.21 um 12:11 schrieb S, Shirish:
On 11/8/2021 2:25 PM, Paul Menzel wrote:
Am 08.11.21 um 09:15 schrieb Shirish S:
limit the MPO rejection only for DCN1x as its not required on later
it’s
versi
Hi Paul,
On 11/8/2021 7:51 PM, Paul Menzel wrote:
[Which address should be used: sshan...@amd.com or shiris...@amd.com?]
"shiris...@amd.com"
Dear Shirish,
Am 08.11.21 um 12:11 schrieb S, Shirish:
On 11/8/2021 2:25 PM, Paul Menzel wrote:
Am 08.11.21 um 09:15 schrieb Shirish S:
limit th
Am 2021-11-08 um 5:22 a.m. schrieb Christian König:
> Am 05.11.21 um 20:25 schrieb Alex Sierra:
>> The low 16MB of virtual address space are currently reserved for kernel
>> mode allocations mapped into user virtual address space. This causes
>> conflicts with HMM/SVM mappings at low virtual addr
On 11/8/2021 7:44 PM, Christian König wrote:
Am 08.11.21 um 12:15 schrieb Borislav Petkov:
On Mon, Nov 08, 2021 at 09:51:03AM +0100, Paul Menzel wrote:
Please elaborate the kind of issues.
It fails to reboot on Carrizo-based laptops.
That doesn't necessary sounds like a good idea to me th
On 2021-11-08 03:15, Shirish S wrote:
> limit the MPO rejection only for DCN1x as its not required on later
> versions.
>
> Fixes: d89f6048bdcb ("drm/amd/display: Reject non-zero src_y and src_x for
> video planes")
>
> Signed-off-by: Shirish S
With Paul's suggestions addressed (mainly the
On 2021-11-08 08:56, Shirish S wrote:
> make action upon failure in "drm_atomic_add_affected_connectors()"
> consistent with the rest of failures in amdgpu_dm_atomic_check().
>
> Signed-off-by: Shirish S
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_d
On 2021-11-08 06:23, Christian König wrote:
>
>
> Am 08.11.21 um 12:13 schrieb S, Shirish:
>> Hi Paul,
>>
>> On 11/8/2021 2:27 PM, Paul Menzel wrote:
>>> Dear Shrish,
>>>
>>>
>>> Am 08.11.21 um 09:40 schrieb Shirish S:
update user with next level of info about which condition led to
On Thu, Nov 04, 2021 at 05:41:13PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 04, 2021 at 09:48:41AM +0100, Maxime Ripard wrote:
> > Hi Ville,
> >
> > On Wed, Nov 03, 2021 at 08:05:16PM +0200, Ville Syrjälä wrote:
> > > On Wed, Nov 03, 2021 at 01:02:11PM +0200, Ville Syrjälä wrote:
> > > > On Tue,
This patch removes the race condition where KFD and KMS both try to free
the pasid, depending on when the render node is closed.
KMS should not be freeing compute PASIDs during KMS' postclose.
Compute PASIDs are cleaned up during KFD cleanup in kfd_pasid.c , and
ida_free is not robust enough to gr
On 2021-11-08 9:15 a.m., Felix Kuehling
wrote:
The check for whether to drain retry faults must be under the mmap write
lock to serialize with munmap notifier callbacks.
We were also missing checks on child ranges. To fix that, simplify the
logic by using a
Am 08.11.21 um 15:35 schrieb Felix Kuehling:
Am 2021-11-08 um 5:22 a.m. schrieb Christian König:
Am 05.11.21 um 20:25 schrieb Alex Sierra:
The low 16MB of virtual address space are currently reserved for kernel
mode allocations mapped into user virtual address space. This causes
conflicts with
Hi Matthew,
Thanks for the review, Please find my comments
On 04/11/21 12:11 am, Matthew Auld wrote:
> On 25/10/2021 14:00, Arunpravin wrote:
>> - Make drm_buddy_alloc a single function to handle
>>range allocation and non-range allocation demands
>>
>> - Implemented a new function alloc_range
On 04/11/21 12:14 am, Matthew Auld wrote:
> On 25/10/2021 14:00, Arunpravin wrote:
>> 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 04/11/21 12:48 am, Matthew Auld wrote:
> On 25/10/2021 14:00, Arunpravin wrote:
>> 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(+)
On 04/11/21 2:24 pm, Christian König wrote:
> Am 04.11.21 um 09:49 schrieb Matthew Auld:
>> On 04/11/2021 07:34, Christian König wrote:
>>>
>>>
>>> Am 03.11.21 um 20:25 schrieb Matthew Auld:
On 25/10/2021 14:00, Arunpravin wrote:
> - Remove drm_mm references and replace with drm buddy f
Am 2021-11-05 um 3:58 p.m. schrieb Graham Sider:
> Switch to IP version checking instead of asic_type on various KFD
> version checks.
>
> Signed-off-by: Graham Sider
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 4 ++--
> drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
> driv
Am 2021-11-05 um 3:58 p.m. schrieb Graham Sider:
> Patches to change KFD to use IP versions rather than asic_type.
> Converting IP version checking in main switch statements.
>
> Signed-off-by: Graham Sider
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 124 +-
> .../dr
I stumbled across this thread when I ran into the same issue, while
working out how to move drm/msm to use scheduler's retire +
timeout/recovery (and get rid of our own mirror list of in-flight
jobs). We already have hw error detection enabled, and it can signal
quite fast, so assuming the first j
From: James Zhu
[ Upstream commit 9cec53c18a3170c7e5673c414da56aeecee94832 ]
Separate iommu_resume from kfd_resume, and move it before
other amdgpu ip init/resume.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=211277
Signed-off-by: James Zhu
Reviewed-by: Felix Kuehling
Signed-off-by: Alex
From: Andrey Grodzovsky
[ Upstream commit c03509cbc01559549700e14c4a6239f2572ab4ba ]
Add more guards to MMIO access post device
unbind/unplug
Bug:
https://bugs.archlinux.org/task/72092?project=1&order=dateopened&sort=desc&pagenum=1
Signed-off-by: Andrey Grodzovsky
Reviewed-by: James Zhu
Sign
From: Jimmy Kizito
[ Upstream commit 60f39edd897ea134a4ddb789a6795681691c3183 ]
[Why]
Links which are dynamically assigned link encoders have their link
encoder set to NULL.
[How]
Check that a pointer to a link_encoder object is non-NULL before using
it.
Reviewed-by: Aric Cyr
Reviewed-by: Mee
From: Andrey Grodzovsky
[ Upstream commit c03509cbc01559549700e14c4a6239f2572ab4ba ]
Add more guards to MMIO access post device
unbind/unplug
Bug:
https://bugs.archlinux.org/task/72092?project=1&order=dateopened&sort=desc&pagenum=1
Signed-off-by: Andrey Grodzovsky
Reviewed-by: James Zhu
Sign
From: Jimmy Kizito
[ Upstream commit 60f39edd897ea134a4ddb789a6795681691c3183 ]
[Why]
Links which are dynamically assigned link encoders have their link
encoder set to NULL.
[How]
Check that a pointer to a link_encoder object is non-NULL before using
it.
Reviewed-by: Aric Cyr
Reviewed-by: Mee
From: Andrey Grodzovsky
[ Upstream commit c03509cbc01559549700e14c4a6239f2572ab4ba ]
Add more guards to MMIO access post device
unbind/unplug
Bug:
https://bugs.archlinux.org/task/72092?project=1&order=dateopened&sort=desc&pagenum=1
Signed-off-by: Andrey Grodzovsky
Reviewed-by: James Zhu
Sign
MMIO/DOORBELL BOs encode control data and should be pinned in GTT
domain before enabling PCIe connected peer devices in accessing it
Signed-off-by: Ramesh Errabolu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 25 +
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 55 +++
[AMD Official Use Only]
> -Original Message-
> From: Paul Menzel
> Sent: Monday, November 8, 2021 4:51 PM
> To: Quan, Evan
> Cc: Deucher, Alexander ; Lazar, Lijo
> ; Borislav Petkov ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amd/pm: avoid duplicate powergate/ungate
[AMD Official Use Only]
> -Original Message-
> From: Borislav Petkov
> Sent: Monday, November 8, 2021 7:15 PM
> To: Paul Menzel
> Cc: Quan, Evan ; Deucher, Alexander
> ; Lazar, Lijo ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amd/pm: avoid duplicate powergate/ungate
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Monday, November 8, 2021 7:16 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Borislav Petkov
>
> Subject: Re: [PATCH] drm/amd/pm: avoid duplicate powergate/ungate
> setting
>
>
>
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Monday, November 8, 2021 10:41 PM
> To: Koenig, Christian ; Borislav Petkov
> ; Paul Menzel
> Cc: Deucher, Alexander ; Quan, Evan
> ; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amd/pm: avoid duplicat
On 11/9/2021 9:10 AM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Monday, November 8, 2021 7:16 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Borislav Petkov
Subject: Re: [PATCH] drm/amd/pm: avoid duplicate pow
Am 2021-11-08 um 8:37 p.m. schrieb Ramesh Errabolu:
> MMIO/DOORBELL BOs encode control data and should be pinned in GTT
> domain before enabling PCIe connected peer devices in accessing it
The PCIe connected peer device access isn't an issue on the upstream
branch (yet). But in general, it is a go
[Why]
Video plane gets rejected for non-zero src_y and src_x on DCN2.x.
[How]
Limit the rejection till DCN1.x and verified MPO, by dragging video
playback beyond display's left (0, 0) co-ordinates.
Fixes: d89f6048bdcb ("drm/amd/display: Reject non-zero src_y and src_x for
video planes")
Signed-o
[AMD Official Use Only]
Responses in line
Regards,
Ramesh
-Original Message-
From: Kuehling, Felix
Sent: Monday, November 8, 2021 10:51 PM
To: amd-gfx@lists.freedesktop.org; Errabolu, Ramesh
Subject: Re: [PATCH] drm/amdgpu: Pin MMIO/DOORBELL BO's in GTT domain
Am 2021-11-08 um 8:37 p
update developers with next level of info about unsupported
display configuration query that led to atomic check failure.
Signed-off-by: Shirish S
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 69 ++-
1 file changed, 51 insertions(+), 18 deletions(-)
diff --git a/drivers/g
On 11/8/2021 8:27 PM, Harry Wentland wrote:
On 2021-11-08 06:23, Christian König wrote:
Am 08.11.21 um 12:13 schrieb S, Shirish:
Hi Paul,
On 11/8/2021 2:27 PM, Paul Menzel wrote:
Dear Shrish,
Am 08.11.21 um 09:40 schrieb Shirish S:
update user with next level of info about which condit
On Mon, Nov 08, 2021 at 07:37:44PM -0600, Ramesh Errabolu wrote:
> MMIO/DOORBELL BOs encode control data and should be pinned in GTT
> domain before enabling PCIe connected peer devices in accessing it
>
> Signed-off-by: Ramesh Errabolu
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 25
MMIO/DOORBELL BOs encode control data and should be pinned in GTT
domain before enabling PCIe connected peer devices in accessing it
Signed-off-by: Ramesh Errabolu
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 76 +++
1 file changed, 76 insertions(+)
diff --git a/drivers/g
[AMD Official Use Only]
Responses in line
-Original Message-
From: Yu, Lang
Sent: Monday, November 8, 2021 11:27 PM
To: Errabolu, Ramesh
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: Pin MMIO/DOORBELL BO's in GTT domain
On Mon, Nov 08, 2021 at 07:37:44PM -0600, Ra
Accounting system to track amount of available memory (system, TTM
and VRAM of a device) relies on BO's domain. The change is to rely
instead on allocation flag indicating BO type - VRAM, GTT, USERPTR,
MMIO or DOORBELL
Signed-off-by: Ramesh Errabolu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
On Tue, Nov 09, 2021 at 02:12:00PM +0800, Errabolu, Ramesh wrote:
> [AMD Official Use Only]
>
> Responses in line
>
> -Original Message-
> From: Yu, Lang
> Sent: Monday, November 8, 2021 11:27 PM
> To: Errabolu, Ramesh
> Cc: amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdg
Am 08.11.21 um 15:41 schrieb Lazar, Lijo:
On 11/8/2021 7:44 PM, Christian König wrote:
Am 08.11.21 um 12:15 schrieb Borislav Petkov:
On Mon, Nov 08, 2021 at 09:51:03AM +0100, Paul Menzel wrote:
Please elaborate the kind of issues.
It fails to reboot on Carrizo-based laptops.
That doesn't
On 11/9/2021 12:46 PM, Christian König wrote:
Am 08.11.21 um 15:41 schrieb Lazar, Lijo:
On 11/8/2021 7:44 PM, Christian König wrote:
Am 08.11.21 um 12:15 schrieb Borislav Petkov:
On Mon, Nov 08, 2021 at 09:51:03AM +0100, Paul Menzel wrote:
Please elaborate the kind of issues.
It fails t
[AMD Official Use Only]
I will experiment to see if it is not needed. Will update patch based on the
results.
Regards,
Ramesh
From: Yu, Lang
Sent: Tuesday, November 9, 2021 12:44 AM
To: Errabolu, Ramesh
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] dr
Am 09.11.21 um 08:28 schrieb Lazar, Lijo:
[SNIP]
Ok guys I've double checked the git history and found that this here
is not as it is intended to be.
See the code in question was just added in August by the following
commit:
commit 859e4659273f1df3a23e3990826bcb41e85f68a5
Author: Evan Qua
61 matches
Mail list logo