aldebaran supports up to 16 xgmi physical nodes.
Signed-off-by: Hawking Zhang
Reviewed-by: John Clements
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c
[Why]
for bailing job, this commit will delete it from pending list thus the
bailing job will never have a chance to be resubmitted even in advance
tdr mode.
[How]
after embeded hw_fence into amdgpu_job is done, the race condition that
this commit tries to work around is completely solved.So
Am 15.08.21 um 21:29 schrieb Nathan Chancellor:
Clang + -Wimplicit-fallthrough warns:
drivers/gpu/drm/radeon/radeon_fb.c:170:2: warning: unannotated
fall-through between switch labels [-Wimplicit-fallthrough]
default:
^
drivers/gpu/drm/radeon/radeon_fb.c:170:2: note: insert
On Fri, Aug 13, 2021 at 01:31:38AM -0500, Alex Sierra wrote:
> From: Ralph Campbell
>
> There are several places where ZONE_DEVICE struct pages assume a reference
> count == 1 means the page is idle and free. Instead of open coding this,
> add a helper function to hide this detail.
>
> v3:
>
On Fri, Aug 13, 2021 at 01:31:42AM -0500, Alex Sierra wrote:
> migrate.vma = vma;
> migrate.start = start;
> migrate.end = end;
> - migrate.flags = MIGRATE_VMA_SELECT_DEVICE_PRIVATE;
> migrate.pgmap_owner = SVM_ADEV_PGMAP_OWNER(adev);
>
> + if
On Fri, Aug 13, 2021 at 01:31:45AM -0500, Alex Sierra wrote:
> Add MEMORY_DEVICE_GENERIC case to free_zone_device_page callback.
> Device generic type memory case is now able to free its pages properly.
How is this going to work for the two existing MEMORY_DEVICE_GENERIC
that now change behavior?
On 8/13/21 9:59 AM, Tom Lendacky wrote:
In prep for other protected virtualization technologies, introduce a
generic helper function, prot_guest_has(), that can be used to check
for specific protection attributes, like memory encryption. This is
intended to eliminate having to add multiple
On Fri, Aug 13, 2021 at 11:59:20AM -0500, Tom Lendacky wrote:
> In prep for other uses of the prot_guest_has() function besides AMD's
> memory encryption support, selectively build the AMD memory encryption
> architecture override functions only when CONFIG_AMD_MEM_ENCRYPT=y. These
> functions
On Fri, Aug 13, 2021 at 11:59:22AM -0500, Tom Lendacky wrote:
> diff --git a/arch/x86/include/asm/protected_guest.h
> b/arch/x86/include/asm/protected_guest.h
> new file mode 100644
> index ..51e4eefd9542
> --- /dev/null
> +++ b/arch/x86/include/asm/protected_guest.h
> @@ -0,0 +1,29
On Fri, Aug 13, 2021 at 01:31:43AM -0500, Alex Sierra wrote:
> Two helpers added. One checks if zone device page is generic
> type. The other if page is either private or generic type.
>
> Signed-off-by: Alex Sierra
Looks good,
Reviewed-by: Christoph Hellwig
On Fri, Aug 13, 2021 at 11:59:21AM -0500, Tom Lendacky wrote:
> In prep for other protected virtualization technologies, introduce a
> generic helper function, prot_guest_has(), that can be used to check
> for specific protection attributes, like memory encryption. This is
> intended to eliminate
On Sun, Aug 15, 2021 at 08:53:31AM -0500, Tom Lendacky wrote:
> It's not a cross-vendor thing as opposed to a KVM or other hypervisor
> thing where the family doesn't have to be reported as AMD or HYGON.
What would be the use case? A HV starts a guest which is supposed to be
encrypted using the
On Fri, Aug 13, 2021 at 01:31:44AM -0500, Alex Sierra wrote:
> Device generic type case added for migrate_vma_pages and
> migrate_vma_check_page helpers.
> Both, generic and private device types have the same
> conditions to decide to migrate pages from/to device
> memory.
This reas a little
On 8/15/21 8:37 AM, Christoph Hellwig wrote:
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 8ae31622deef..d48a1f0889d1 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1218,7 +1218,7 @@ __maybe_unused struct page *try_grab_compound_head(struct
page *page, int refs,
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 8ae31622deef..d48a1f0889d1 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1218,7 +1218,7 @@ __maybe_unused struct page
> *try_grab_compound_head(struct page *page, int refs,
> static inline __must_check bool
> @@ -880,17 +881,22 @@ int svm_migrate_init(struct amdgpu_device *adev)
>* should remove reserved size
>*/
> size = ALIGN(adev->gmc.real_vram_size, 2ULL << 20);
> - res = devm_request_free_mem_region(adev->dev, _resource, size);
> + if (xgmi_connected_to_cpu)
> +
Am 12.08.21 um 10:11 schrieb Michel Dänzer:
On 2021-08-12 7:55 a.m., Koenig, Christian wrote:
Hi James,
Evan seems to have understood how this all works together.
See while any begin/end use critical section is active the work should not be
active.
When you handle only one ring you can just
Am 13.08.21 um 05:28 schrieb lwt105:
in line 1503, "dma_fence_put(fence);" drop the reference to fence and may
cause fence to be released. However, fence is used subsequently in line
1510 "fence->error". This may result in an use-after-free bug.
It can be fixed by recording fence->error in an
Am 13.08.21 um 12:29 schrieb Michel Dänzer:
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
after the first time GFXOFF was disabled and re-enabled, even if GFXOFF
was disabled and
Duncan posted on Mon, 16 Aug 2021 07:58:37 + as excerpted:
> Mikael Pettersson posted on Tue, 03 Aug 2021 08:54:18 +0200 as
> excerpted:
>> On Mon, Aug 2, 2021 at 8:29 PM Duncan wrote:
>>> Mikael Pettersson wrote...
>>> > Booting 5.14.0-rc4 on my box with Radeon graphics breaks with
>>> >
On 2021-08-16 7:10 a.m., Brian Starkey wrote:
> On Fri, Aug 13, 2021 at 10:42:12AM +0530, Sharma, Shashank wrote:
>> Hello Brian,
>> (+Uma in cc)
>>
>> Thanks for your comments, Let me try to fill-in for Harry to keep the design
>> discussion going. Please find my comments inline.
>>
Thanks,
On Mon, Aug 16, 2021 at 4:28 AM Christian König
wrote:
>
> Hi Wyatt,
>
> adding Leo as well.
>
> Question is what do you mean with "majority of VA-API hardware video decoders
> have disappeared" ?
>
> Do you have a dmesg? Or the output of vainfo?
Already fixed:
Am 13.08.21 um 17:03 schrieb Michel Dänzer:
On 2021-08-13 10:54 a.m., zhaoxiao wrote:
This patch fixes the following sparse errors:
drivers/gpu/drm/radeon/r600_dma.c:247:30: warning: incorrect type in assignment
(different base types)
drivers/gpu/drm/radeon/r600_dma.c:247:30:expected
[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
[AMD Official Use Only]
Yes, the information is from MMSCH firmware team.
They are saying the version info is not used in the old MMSCH firmware, so it
won't break the ASICs using old MMSCH firmware.
Ok, I will change the commit message to specify mmsch 1.0.
Thanks,
Zhigang
-Original
On 2021-08-13 3:21 p.m., Liu, Zhan wrote:
[AMD Official Use Only]
[AMD Official Use Only]
[why]
dcn301_calculate_wm_and_dl() causes flickering when external monitor is
connected.
This issue has been fixed before by commit 0e4c0ae59d7e
("drm/amdgpu/display: drop dcn301_calculate_wm_and_dl
On 8/16/2021 4:05 PM, Michel Dänzer wrote:
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
after the first time GFXOFF was disabled and re-enabled, even if GFXOFF
was disabled and
Am 16.08.21 um 13:33 schrieb Lazar, Lijo:
On 8/16/2021 4:05 PM, Michel Dänzer wrote:
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
after the first time GFXOFF was disabled and
On 2021-08-16 14:40, Harry Wentland wrote:
On 2021-08-16 7:10 a.m., Brian Starkey wrote:
On Fri, Aug 13, 2021 at 10:42:12AM +0530, Sharma, Shashank wrote:
Hello Brian,
(+Uma in cc)
Thanks for your comments, Let me try to fill-in for Harry to keep the
design
discussion going. Please find my
[AMD Official Use Only]
Is that information from MM team ?
Please make sure it won't break the ASICs that use the same code path. Also If
this is true for all mmsch_v1.0 , you need to specify this is mmSCH v1.0 ,
since other MMSCH version will still use this major and minor.
Shaoyun.liu
Hi Wyatt,
adding Leo as well.
Question is what do you mean with "majority of VA-API hardware video
decoders have disappeared" ?
Do you have a dmesg? Or the output of vainfo?
Thanks,
Christian.
Am 09.08.21 um 04:26 schrieb Wyatt Childers:
Hi,
I've encountered a bug
On 2021-08-16 6:13 a.m., Lazar, Lijo wrote:
> On 8/13/2021 9:30 PM, Michel Dänzer wrote:
>> On 2021-08-13 5:07 p.m., Lazar, Lijo wrote:
>>> On 8/13/2021 8:10 PM, Michel Dänzer wrote:
On 2021-08-13 4:14 p.m., Lazar, Lijo wrote:
> On 8/13/2021 7:04 PM, Michel Dänzer wrote:
>> On
On 2021-08-16 12:20 p.m., Quan, Evan wrote:
> [AMD Official Use Only]
>
> Hi Michel,
>
> The patch seems reasonable to me(especially the cancel_delayed_work_sync()
> part).
> However, can you explain more about the code below?
> What's the race issue here exactly?
>
> + /* mutex_lock could
We have a S3 issue on that SKU with BACO enabled. Will bring back this
when that root caused.
Change-Id: I56d4830e6275e20a415808896eecbadfe944070b
Signed-off-by: Evan Quan
Acked-by: Alex Deucher
Reviewed-by: Guchun Chen
--
v1->v2:
- limit the SKU further by subsystem IDs (Alex)
---
[AMD Official Use Only]
Hi Michel,
The patch seems reasonable to me(especially the cancel_delayed_work_sync()
part).
However, can you explain more about the code below?
What's the race issue here exactly?
+ /* mutex_lock could deadlock with cancel_delayed_work_sync in
From: Michel Dänzer
schedule_delayed_work does not push back the work if it was already
scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
after the first time GFXOFF was disabled and re-enabled, even if GFXOFF
was disabled and re-enabled again during those 100 ms.
This
On Fri, Aug 13, 2021 at 10:42:12AM +0530, Sharma, Shashank wrote:
> Hello Brian,
> (+Uma in cc)
>
> Thanks for your comments, Let me try to fill-in for Harry to keep the design
> discussion going. Please find my comments inline.
>
> On 8/2/2021 10:00 PM, Brian Starkey wrote:
> >
-- snip --
> >
On 2021-08-16 9:38 a.m., Christian König wrote:
> Am 13.08.21 um 12:29 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> schedule_delayed_work does not push back the work if it was already
>> scheduled before, so amdgpu_device_delay_enable_gfx_off ran ~100 ms
>> after the first time GFXOFF was
On 2021-08-16 2:06 p.m., Christian König wrote:
> Am 16.08.21 um 13:33 schrieb Lazar, Lijo:
>> On 8/16/2021 4:05 PM, Michel Dänzer wrote:
>>> From: Michel Dänzer
>>>
>>> schedule_delayed_work does not push back the work if it was already
>>> scheduled before, so amdgpu_device_delay_enable_gfx_off
MMSCH 1.0 doesn't have major/minor version, only verison.
Signed-off-by: Zhigang Luo
---
drivers/gpu/drm/amd/amdgpu/mmsch_v1_0.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/mmsch_v1_0.h
b/drivers/gpu/drm/amd/amdgpu/mmsch_v1_0.h
index
[AMD Official Use Only]
Looks ok to me .
Reviewed by Shaoyun.liu
-Original Message-
From: amd-gfx On Behalf Of Zhigang Luo
Sent: Monday, August 16, 2021 11:04 AM
To: amd-gfx@lists.freedesktop.org
Cc: Luo, Zhigang
Subject: [PATCH] drm/amdgpu: correct MMSCH 1.0 version
MMSCH 1.0
The TA has a limit to the amount of data that can be retrieved from
GET_TOPOLOGY. For setups that exceed this limit, the xGMI topology
needs to be re-initialized and data needs to be re-fetched from the
extended link records by setting a flag in the shared command buffer.
The number of hops and
Am 2021-08-15 um 5:10 a.m. schrieb Christoph Hellwig:
>> @@ -880,17 +881,22 @@ int svm_migrate_init(struct amdgpu_device *adev)
>> * should remove reserved size
>> */
>> size = ALIGN(adev->gmc.real_vram_size, 2ULL << 20);
>> -res = devm_request_free_mem_region(adev->dev,
Applied. Thanks!
Alex
On Mon, Aug 16, 2021 at 3:23 AM Christian König
wrote:
>
> Am 15.08.21 um 21:29 schrieb Nathan Chancellor:
> > Clang + -Wimplicit-fallthrough warns:
> >
> > drivers/gpu/drm/radeon/radeon_fb.c:170:2: warning: unannotated
> > fall-through between switch labels
Am 2021-08-15 um 4:40 p.m. schrieb John Hubbard:
> On 8/15/21 8:37 AM, Christoph Hellwig wrote:
>>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>>> index 8ae31622deef..d48a1f0889d1 100644
>>> --- a/include/linux/mm.h
>>> +++ b/include/linux/mm.h
>>> @@ -1218,7 +1218,7 @@ __maybe_unused
Am 2021-08-15 um 11:40 a.m. schrieb Christoph Hellwig:
> On Fri, Aug 13, 2021 at 01:31:45AM -0500, Alex Sierra wrote:
>> Add MEMORY_DEVICE_GENERIC case to free_zone_device_page callback.
>> Device generic type memory case is now able to free its pages properly.
> How is this going to work for
Applied. Thanks!
Alex
On Mon, Aug 16, 2021 at 11:07 AM Michel Dänzer wrote:
>
> On 2021-08-16 2:06 p.m., Christian König wrote:
> > Am 16.08.21 um 13:33 schrieb Lazar, Lijo:
> >> On 8/16/2021 4:05 PM, Michel Dänzer wrote:
> >>> From: Michel Dänzer
> >>>
> >>> schedule_delayed_work does not
On 8/15/2021 10:38 AM, Christoph Hellwig wrote:
On Fri, Aug 13, 2021 at 01:31:42AM -0500, Alex Sierra wrote:
migrate.vma = vma;
migrate.start = start;
migrate.end = end;
- migrate.flags = MIGRATE_VMA_SELECT_DEVICE_PRIVATE;
migrate.pgmap_owner =
On 2021-08-16 4:12 p.m., Alex Deucher wrote:
> These were converted to CONFIG_DRM_AMD_DC_DCN, fix this case up.
>
> Fixes: d7cecec64d07 ("drm/amd/display: Ensure DCN save after VM setup")
> Signed-off-by: Alex Deucher
Reviewed-by: Harry Wentland
Harry
> ---
>
On 2021-08-16 9:59 a.m., Leo Li wrote:
On 2021-08-13 3:21 p.m., Liu, Zhan wrote:
[AMD Official Use Only]
[AMD Official Use Only]
[why]
dcn301_calculate_wm_and_dl() causes flickering when external monitor is
connected.
This issue has been fixed before by commit 0e4c0ae59d7e
On Mon, Aug 16, 2021 at 4:25 PM Leo Li wrote:
>
>
>
> On 2021-08-16 9:59 a.m., Leo Li wrote:
> >
> >
> >
> > On 2021-08-13 3:21 p.m., Liu, Zhan wrote:
> >> [AMD Official Use Only]
> >>
> >> [AMD Official Use Only]
> >>
> >> [why]
> >> dcn301_calculate_wm_and_dl() causes flickering when external
HW Blocks:
++ +-+ +--+
| OPTC | | HDA | | HUBP |
++ +-+ +--+
| ||
| ||
HPO |==||
| | v|
| | +-+
HW Blocks:
++ +-+ +--+
| OPTC | | HDA | | HUBP |
++ +-+ +--+
| ||
| ||
HPO |==||
| | v|
| | +-+
1. Retrieve 128/132b link cap.
2. 128/132b link training and payload allocation.
3. UHBR10 link rate support.
Signed-off-by: Fangzhi Zuo
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c |6 +
drivers/gpu/drm/amd/display/dc/core/dc.c | 17 +
Parse DP2 encoder caps and hpo instance from bios
Signed-off-by: Fangzhi Zuo
---
drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c| 8
drivers/gpu/drm/amd/display/dc/bios/command_table2.c | 6 ++
.../gpu/drm/amd/display/dc/dcn30/dcn30_dio_link_encoder.c | 4
These were converted to CONFIG_DRM_AMD_DC_DCN, fix this case up.
Fixes: d7cecec64d07 ("drm/amd/display: Ensure DCN save after VM setup")
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/core/dc_vm_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
HW Blocks:
++ +-+ +--+
| OPTC | | HDA | | HUBP |
++ +-+ +--+
| ||
| ||
HPO |==||
| | v|
| | +-+
HW Blocks:
+-+
| HDA |
+-+
|
|
HPO ===|=
| v
| +-+
| | APG |
v +-+
The patch series adds SST UHBR10 support
Fangzhi Zuo (6):
drm/amd/display: Add DP 2.0 Audio Package Generator
drm/amd/display: Add DP 2.0 HPO Stream Encoder
drm/amd/display: Add DP 2.0 HPO Link Encoder
drm/amd/display: Add DP 2.0 DCCG
drm/amd/display: Add DP 2.0 BIOS and DMUB Support
On Mon, Aug 16, 2021 at 5:03 PM Fangzhi Zuo wrote:
>
> HW Blocks:
>
> ++ +-+ +--+
> | OPTC | | HDA | | HUBP |
> ++ +-+ +--+
> | ||
> | ||
> HPO
Regards,
Oak
On 2021-08-16, 3:53 PM, "amd-gfx on behalf of Sierra Guiza, Alejandro (Alex)"
wrote:
On 8/15/2021 10:38 AM, Christoph Hellwig wrote:
> On Fri, Aug 13, 2021 at 01:31:42AM -0500, Alex Sierra wrote:
>> migrate.vma = vma;
>> migrate.start =
Am 2021-08-16 um 6:06 p.m. schrieb Zeng, Oak:
> Regards,
> Oak
>
>
>
> On 2021-08-16, 3:53 PM, "amd-gfx on behalf of Sierra Guiza, Alejandro
> (Alex)" alex.sie...@amd.com> wrote:
>
>
> On 8/15/2021 10:38 AM, Christoph Hellwig wrote:
> > On Fri, Aug 13, 2021 at 01:31:42AM -0500, Alex
Am 2021-08-14 um 6:12 a.m. schrieb Yifan Zhang:
> [ RUN ] KFDSVMRangeTest.PartialUnmapSysMemTest
> /home/yifan/brahma/libhsakmt/tests/kfdtest/src/KFDTestUtil.cpp:245: Failure
> Value of: (hsaKmtAllocMemory(m_Node, m_Size, m_Flags, _pBuf))
> Actual: 1
> Expected: HSAKMT_STATUS_SUCCESS
>
63 matches
Mail list logo
