Am 29.10.21 um 17:09 schrieb Nirmoy Das:
We set WC memtype for aper_base but don't check return value
of arch_io_reserve_memtype_wc(). Be more defensive and return
early on error.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 7 ++-
1 file changed, 6 inser
Am 22.10.21 um 13:03 schrieb Nirmoy Das:
amdgpu_ttm_backend_bind() only needed for TTM_PL_TT
and AMDGPU_PL_PREEMPT.
Signed-off-by: Nirmoy Das
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/amd
On 10/29/2021 8:39 PM, Nirmoy Das wrote:
We set WC memtype for aper_base but don't check return value
of arch_io_reserve_memtype_wc(). Be more defensive and return
early on error.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 7 ++-
1 file changed, 6 inser
On 11/2/2021 2:58 AM, Mario Limonciello wrote:
This command corresponding to this attribute was deprecated in the PMFW
for YC so don't show a non-functional attribute.
Now it's a generic patch, not specific to YC. Maybe a generic one like
"for ASICs not supporting power profile mode, don't
For yellow carp, the desired CGPG hysteresis value is 0x4E20.
Signed-off-by: Aaron Liu
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 90a834d
Reviewed-by: Simon Ser
On Tue, Nov 02, 2021 at 04:51:18PM +0800, Liu, Aaron wrote:
> For yellow carp, the desired CGPG hysteresis value is 0x4E20.
>
> Signed-off-by: Aaron Liu
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/am
On 10/30/21 11:24, PGNet Dev wrote:
Is that kernel/modconfig config incorrect?
Not relevant to the problem?
Something else(where) needed?
fwiw,
AMD Global Customer Care's response to question about this 'purple' issue:
"...
Please be informed that Ryzen 5600G APU is supported only on Windows
From: Ye Guojin
Since the variables named is_end_of_payload and hpd_status are already
bool type, the ?: conditional operator is unnecessary any more.
Clean them up here.
Reported-by: Zeal Robot
Signed-off-by: Ye Guojin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
drivers/g
On 11/2/2021 9:00 AM, Lazar, Lijo wrote:
On 10/29/2021 8:39 PM, Nirmoy Das wrote:
We set WC memtype for aper_base but don't check return value
of arch_io_reserve_memtype_wc(). Be more defensive and return
early on error.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_obj
[Why]
For Vega10, disabling gart of gfxhub and mmhub could mess up KIQ and PSP under
sriov mode, and lead to DMAR on host side.
[How]
Do not call gmc_gart_disable under sriov but keep vram_unpin to avoid
pin_count leak.
Signed-off-by: YuBiao Wang
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 4 +
Am 02.11.21 um 11:11 schrieb Das, Nirmoy:
On 11/2/2021 9:00 AM, Lazar, Lijo wrote:
On 10/29/2021 8:39 PM, Nirmoy Das wrote:
We set WC memtype for aper_base but don't check return value
of arch_io_reserve_memtype_wc(). Be more defensive and return
early on error.
Signed-off-by: Nirmoy Das
-
Am 02.11.21 um 11:25 schrieb YuBiao Wang:
[Why]
For Vega10, disabling gart of gfxhub and mmhub could mess up KIQ and PSP under
sriov mode, and lead to DMAR on host side.
[How]
Do not call gmc_gart_disable under sriov but keep vram_unpin to avoid
pin_count leak.
NAK, if you want to do this you
On 11/2/2021 4:39 PM, Christian König wrote:
Am 02.11.21 um 11:11 schrieb Das, Nirmoy:
On 11/2/2021 9:00 AM, Lazar, Lijo wrote:
On 10/29/2021 8:39 PM, Nirmoy Das wrote:
We set WC memtype for aper_base but don't check return value
of arch_io_reserve_memtype_wc(). Be more defensive and ret
Am 02.11.21 um 12:18 schrieb Lazar, Lijo:
On 11/2/2021 4:39 PM, Christian König wrote:
Am 02.11.21 um 11:11 schrieb Das, Nirmoy:
On 11/2/2021 9:00 AM, Lazar, Lijo wrote:
On 10/29/2021 8:39 PM, Nirmoy Das wrote:
We set WC memtype for aper_base but don't check return value
of arch_io_reser
On 11/2/2021 12:33 PM, Christian König wrote:
Am 02.11.21 um 12:18 schrieb Lazar, Lijo:
On 11/2/2021 4:39 PM, Christian König wrote:
Am 02.11.21 um 11:11 schrieb Das, Nirmoy:
On 11/2/2021 9:00 AM, Lazar, Lijo wrote:
On 10/29/2021 8:39 PM, Nirmoy Das wrote:
We set WC memtype for aper_b
On Mon, Oct 25, 2021 at 12:17:37AM +0200, Claudio Suarez wrote:
[...]
No new comments about this, I suppose everything is fine.
I'm going to send the patch with this changes. Thanks to all and
special thanks to you, Ville. Hope this helps the kernel.
Don't hesitate to ask new changes if necessary
Commit a92d083d08b0 created the new flag is_hdmi in drm_display_info
which is set when sink compliant with CEA-861 (EDID) will be treated
as an HDMI sink.
>From that day, this value can be used in some cases instead of
calling drm_detect_hdmi_monitor() and a second parse is avoided
because drm_det
i'm running an AMD Ryzen 5600G -- with integrated graphics -- on linux
(Fedora34) kernel 5.14.14.
its color output is wrong.
i've reported it to AMD support; their response is that it's ONLY supported on "RHEL
& Ubuntu"; they suggest I switch to Ubuntu :-/
i've reported it here, on list; so f
On Tue, Nov 2, 2021 at 9:24 AM PGNet Dev wrote:
>
> i'm running an AMD Ryzen 5600G -- with integrated graphics -- on linux
> (Fedora34) kernel 5.14.14.
>
> its color output is wrong.
>
> i've reported it to AMD support; their response is that it's ONLY supported
> on "RHEL & Ubuntu"; they sugges
Yes, your device is supported.
gr8, thx!
If the issue is related to the whether
or not you can override the ycbcr vs rgb setting for your monitor,
i'm not clear if its a monitor issue, &/or or a (on-die) 'vid card' issue.
that said, most of the rumblings i've found so far _do_ refer to the
On Tue, Nov 2, 2021 at 9:48 AM PGNet Dev wrote:
>
> > Yes, your device is supported.
>
> gr8, thx!
>
> > If the issue is related to the whether
> > or not you can override the ycbcr vs rgb setting for your monitor,
>
> i'm not clear if its a monitor issue, &/or or a (on-die) 'vid card' issue.
>
W
On Wed, Oct 27, 2021 at 07:28:45AM +0900, Inki Dae wrote:
> Hi,
>
> 21. 10. 17. 오전 3:42에 Claudio Suarez 이(가) 쓴 글:
> > Once EDID is parsed, the monitor HDMI support information is available
> > through drm_display_info.is_hdmi. Retriving the same information with
> > drm_detect_hdmi_monitor() is le
Am 2021-11-01 um 10:40 p.m. schrieb Alex Sierra:
> [Why]:
> When we call hmm_range_fault to map memory after a migration, we don't
> expect memory to be migrated again as a result of hmm_range_fault. The
> driver ensures that all memory is in GPU-accessible locations so that
> no migration should b
On 2021-11-01 10:40 p.m., Alex Sierra
wrote:
[Why]:
When we call hmm_range_fault to map memory after a migration, we don't
expect memory to be migrated again as a result of hmm_range_fault. The
driver ensures that all memory is in GPU-accessible locations so
commit b1c61212d8dc ("drm/amd/display: Fully switch to dmub for all dcn21
asics") switched over to using dmub on Renoir to fix Gitlab 1735, but this
implied a new dependency on newer firmware which might not be met on older
kernel versions.
Since sw_init runs before hw_init, there is an opportunit
A lot of drivers open-code the HDMI 1.4 maximum pixel rate in their
driver to test whether the resolutions are supported or if the
scrambling needs to be enabled.
Let's create a common define for everyone to use it.
Cc: Alex Deucher
Cc: amd-gfx@lists.freedesktop.org
Cc: Andrzej Hajda
Cc: Benjam
On 11/2/2021 10:04 AM, philip yang wrote:
On 2021-11-01 10:40 p.m., Alex Sierra wrote:
[Why]:
When we call hmm_range_fault to map memory after a migration, we don't
expect memory to be migrated again as a result of hmm_range_fault. The
driver ensures that all memory is in GPU-accessible loca
On Tue, Nov 2, 2021 at 11:04 AM Mario Limonciello
wrote:
>
> commit b1c61212d8dc ("drm/amd/display: Fully switch to dmub for all dcn21
> asics") switched over to using dmub on Renoir to fix Gitlab 1735, but this
> implied a new dependency on newer firmware which might not be met on older
> kernel
[Public]
Reviewed-by: Roman Li
> -Original Message-
> From: Alex Deucher
> Sent: Tuesday, November 2, 2021 11:58 AM
> To: Limonciello, Mario
> Cc: amd-gfx list ; Li, Roman
>
> Subject: Re: [PATCH v3] drm/amd/display: Look at firmware version to
> determine using dmub on dcn21
>
> On T
On Tue, Nov 2, 2021 at 10:59 AM Maxime Ripard wrote:
>
> A lot of drivers open-code the HDMI 1.4 maximum pixel rate in their
> driver to test whether the resolutions are supported or if the
> scrambling needs to be enabled.
>
> Let's create a common define for everyone to use it.
>
> Cc: Alex Deuc
Applied. Thanks!
Alex
On Tue, Nov 2, 2021 at 4:58 AM Simon Ser wrote:
>
> Reviewed-by: Simon Ser
To revert wrong merge during rebase.
This reverts commit afd18180c07026f94a80ff024acef5f4159084a4.
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 7677ced16a27
From: Yifan Zhang
When IOMMU disabled in sbios and kfd in iommuv2 path, iommuv2
init will fail. But this failure should not block amdgpu driver init.
Reported-by: youling
Tested-by: youling
Signed-off-by: Yifan Zhang
Reviewed-by: James Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4
On Tue, Nov 2, 2021 at 3:23 PM James Zhu wrote:
>
> To revert wrong merge during rebase.
> This reverts commit afd18180c07026f94a80ff024acef5f4159084a4.
Missing your signed-off-by. Might be better to just merge these two
patches into one unless they are individually applicable to different
kerne
[AMD Official Use Only]
Hi Alex
Sure, Let me check it can be merged into one patch.
Thanks & Best Regards!
James Zhu
From: Alex Deucher
Sent: Tuesday, November 2, 2021 4:34 PM
To: Zhu, James
Cc: amd-gfx list ; Deucher, Alexander
; Zhang, Yifan ; Zhu, Jame
Remove duplicated kfd_resume_iommu which already runs
in mdgpu_amdkfd_device_init.
Signed-off-by: James Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device
On Tue, Nov 2, 2021 at 9:34 PM James Zhu wrote:
>
> Remove duplicated kfd_resume_iommu which already runs
> in mdgpu_amdkfd_device_init.
>
> Signed-off-by: James Zhu
Once you get confirmation, please add:
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214859
Bug: https://gitlab.freedesktop.org
[AMD Official Use Only]
Ray,
That ROCR issue is caused by CGCG(NOT CGPG).
With this patch applied, the rocr issue still exists.
--
Best Regards
Aaron Liu
> -Original Message-
> From: Huang, Ray
> Sent: Tuesday, November 2, 2021 5:19 PM
> To: Liu, Aaron
> Cc: amd-gfx@lists.freedesktop.
On 11/3/2021 12:53 AM, James Zhu wrote:
From: Yifan Zhang
When IOMMU disabled in sbios and kfd in iommuv2 path, iommuv2
init will fail. But this failure should not block amdgpu driver init.
Reported-by: youling
Tested-by: youling
Signed-off-by: Yifan Zhang
Reviewed-by: James Zhu
---
d
40 matches
Mail list logo
