[AMD Official Use Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Tom St Denis
Sent: Friday, January 7, 2022 20:08
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: [PATCH] drm/amd/amdgpu: Add pcie indirect support to
Hi Zhenneng,
+ some display folks
First of all, thanks a lot for your patch.
We had a similar patch in the past, but we had to revert it because we
cannot simply enable DCN for ARM-based systems. You can refer to this
commit message to get a better context:
On 2022-01-07 4:40 p.m., Mario Limonciello wrote:
Otherwise future commands may fail as well leading to downstream
problems that look like they stemmed from a timeout the first time
but really didn't.
Signed-off-by: Mario Limonciello
I guess we used to do this but after we started adding the
Otherwise future commands may fail as well leading to downstream
problems that look like they stemmed from a timeout the first time
but really didn't.
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn31/dcn31_smu.c | 6 ++
1 file changed, 6 insertions(+)
diff
The calcs folder has FPU code on it, which should be isolated inside the
DML folder as per https://patchwork.freedesktop.org/series/93042/.
This commit aims single-handedly to correct the location of such FPU
code and does not refactor any functions.
Changes since v2:
- Corrected problems to
On Thu, Jan 6, 2022 at 4:57 AM Greg Kroah-Hartman
wrote:
>
> There are currently 2 ways to create a set of sysfs files for a
> kobj_type, through the default_attrs field, and the default_groups
> field. Move the amdkfd sysfs code to use default_groups field which has
> been the preferred way
On Thu, Jan 6, 2022 at 4:56 AM Greg Kroah-Hartman
wrote:
>
> There are currently 2 ways to create a set of sysfs files for a
> kobj_type, through the default_attrs field, and the default_groups
> field. Move the amdgpu sysfs code to use default_groups field which has
> been the preferred way
On Thu, Jan 06, 2022 at 01:24:52PM +0100, Wolfram Sang wrote:
> This largely reverts commit 5a7b95fb993ec399c8a685552aa6a8fc995c40bd. It
> breaks suspend with AMD GPUs, and we couldn't incrementally fix it. So,
> let's remove the code and go back to the drawing board. We keep the
> header
> Tested-by: Konstantin Kharlamov
Thanks!
> By the way, shouldn't the patch include a field
>
> Cc: # 5.14+
Yes, but I add such lines only when applying to my tree. If I add it
when sending out patches, the mail gets CCed to stable although the
patch is not upstream yet.
Applied. Thanks!
Alex
On Thu, Dec 30, 2021 at 11:32 AM Christian König
wrote:
>
> Am 30.12.21 um 06:00 schrieb Jonathan Gray:
> > Follow the amdgpu change made in
> > 7611750784664db46d0db95631e322aeb263dde7
> > and replace local radeon function with is_power_of_2().
> >
> > Signed-off-by:
Hi Isabelle,
Using the dml makefile for everything sounds better to me.
Could you send the v3 version using your way to me?
Regards,
Jasdeep
From: Isabella Basso
Sent: January 3, 2022 2:52 PM
To: Dhillon, Jasdeep
Cc: Deucher, Alexander ; Koenig, Christian
;
I think this is still used on the DKMS branch. But it's fine upstream.
Thanks for catching this.
Reviewed-by: Felix Kuehling
Regards,
Felix
Am 2022-01-07 um 5:18 a.m. schrieb Nirmoy:
> Found the commit that removed usages of this function.
>
>
> Fixes: dfcbe6d5f ("drm/amdgpu: Remove unused
[AMD Official Use Only]
> I think the revert is fine once we figure out where we're missing calls to:
>
> .optimize_pwr_state = dcn21_optimize_pwr_state,
> .exit_optimized_pwr_state = dcn21_exit_optimized_pwr_state,
>
> These are already part of dc_link_detect, so I suspect
Hi, this is your Linux kernel regression tracker speaking.
On 05.01.22 18:06, Mario Limonciello wrote:
> The WA from commit 5965280abd30 ("drm/amd/display: Apply w/a for
> hard hang on HPD") causes a regression in s0ix where the system will
> fail to resume properly. This may be because an HPD
Thank you! I tested it (had to resolve a small conflict), works for me. So, in
case you need it, the patch is
Tested-by: Konstantin Kharlamov
By the way, shouldn't the patch include a field
Cc: # 5.14+
?
P.S.: sorry, for all mangled up CC fields. For some reason I didn't
There are currently 2 ways to create a set of sysfs files for a
kobj_type, through the default_attrs field, and the default_groups
field. Move the amdgpu sysfs code to use default_groups field which has
been the preferred way since aa30f47cf666 ("kobject: Add support for
default attribute groups
For adapting radeon rx6600 xt on arm64 platform,
there report some compile errors.
Zhenneng Li (2):
drm/amdgpu: fix compile error for dcn on arm64
drm/amdgpu: enable dcn support on arm64
drivers/gpu/drm/amd/display/Kconfig | 2 +-
drivers/gpu/drm/amd/display/dc/calcs/Makefile |
For adapting radeon rx6600 xt on arm64,
I enabled dcn on arm64 platform, compiler
report not compatible with -mgeneral-regs-only
and -mhard-float when compiling some source file.
Signed-off-by: Zhenneng Li
---
drivers/gpu/drm/amd/display/dc/calcs/Makefile | 6 +
There are currently 2 ways to create a set of sysfs files for a
kobj_type, through the default_attrs field, and the default_groups
field. Move the amdkfd sysfs code to use default_groups field which has
been the preferred way since aa30f47cf666 ("kobject: Add support for
default attribute groups
Signed-off-by: Zhenneng Li
---
drivers/gpu/drm/amd/display/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/Kconfig
b/drivers/gpu/drm/amd/display/Kconfig
index 127667e549c1..1c6c4cb1fd0a 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++
Am 2022-01-07 um 3:56 a.m. schrieb Christian König:
> Am 06.01.22 um 17:51 schrieb Felix Kuehling:
>> Am 2022-01-06 um 11:48 a.m. schrieb Christian König:
>>> Am 06.01.22 um 17:45 schrieb Felix Kuehling:
Am 2022-01-06 um 4:05 a.m. schrieb Christian König:
[SNIP]
Also, why does your
[AMD Official Use Only]
> -Original Message-
> From: Limonciello, Mario
> Sent: January 7, 2022 11:50 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Limonciello, Mario ; Kazlauskas, Nicholas
> ; Zhuo, Qingqing (Lillian)
> ; Scott Bruce ; Chris
> Hixon ; spassw...@web.de
> Subject: [PATCH
The WA from commit 2a50edbf10c8 ("drm/amd/display: Apply w/a for hard hang
on HPD") and commit 1bd3bc745e7f ("drm/amd/display: Extend w/a for hard
hang on HPD to dcn20") causes a regression in s0ix where the system will
fail to resume properly on many laptops. Pull the workarounds out to
avoid
For some reason this file isn't using the appropriate register
headers for DCN headers, which means that on DCN2 we're getting
the VIEWPORT_DIMENSION offset wrong.
This means that we're not correctly carving out the framebuffer
memory correctly for a framebuffer allocated by EFI and
therefore see
[AMD Official Use Only]
Acked-by: Alex Deucher
From: amd-gfx on behalf of Tom St Denis
Sent: Friday, January 7, 2022 7:07 AM
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: [PATCH] drm/amd/amdgpu: Add pcie indirect support to
On 2022-01-07 12:46 a.m., JingWen Chen wrote:
On 2022/1/7 上午11:57, JingWen Chen wrote:
On 2022/1/7 上午3:13, Andrey Grodzovsky wrote:
On 2022-01-06 12:18 a.m., JingWen Chen wrote:
On 2022/1/6 下午12:59, JingWen Chen wrote:
On 2022/1/6 上午2:24, Andrey Grodzovsky wrote:
On 2022-01-05 2:59 a.m.,
Am 07.01.22 um 16:49 schrieb Matthew Auld:
On 26/12/2021 22:24, Arunpravin wrote:
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
On 26/12/2021 22:24, Arunpravin wrote:
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
I've just pushed the whole set to amd-staging-drm-next.
Thanks,
Christian.
Am 07.01.22 um 09:51 schrieb Nirmoy Das:
Do not allow exported amdgpu_gtt_mgr_*() to accept
any ttm_resource_manager pointer. Also there is no need
to force other module to call a ttm function just to
eventually call
The function amdgpu_mm_wreg_mmio_rlc() is used by debugfs to write to
MMIO registers. It didn't support registers beyond the BAR mapped MMIO
space. This adds pcie indirect write support.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +++-
1 file changed, 3
Found the commit that removed usages of this function.
Fixes: dfcbe6d5f ("drm/amdgpu: Remove unused function pointers")
On 1/7/22 09:51, Nirmoy Das wrote:
Remove unused amdgpu_amdkfd_get_vram_usage()
CC: felix.kuehl...@amd.com
Signed-off-by: Nirmoy Das
---
Am 06.01.22 um 17:51 schrieb Felix Kuehling:
Am 2022-01-06 um 11:48 a.m. schrieb Christian König:
Am 06.01.22 um 17:45 schrieb Felix Kuehling:
Am 2022-01-06 um 4:05 a.m. schrieb Christian König:
[SNIP]
Also, why does your ACK or NAK depend on this at all. If it's the right
thing to do, it's
Get rid off pin/unpin of gart BO at resume/suspend and
instead pin only once and try to recover gart content
at resume time. This is much more stable in case there
is OOM situation at 2nd call to amdgpu_device_evict_resources()
while evicting GART table.
v3: remove gart recovery from other places
Remove unused amdgpu_amdkfd_get_vram_usage()
CC: felix.kuehl...@amd.com
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 7 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 1 -
2 files changed, 8 deletions(-)
diff --git
Do not allow exported amdgpu_vram_mgr_*() to accept
any ttm_resource_manager pointer. Also there is no need
to force other module to call a ttm function just to
eventually call vram_mgr functions.
v2: pass adev's vram_mgr instead of adev
Reviewed-by: Christian König
Signed-off-by: Nirmoy Das
Do not allow exported amdgpu_gtt_mgr_*() to accept
any ttm_resource_manager pointer. Also there is no need
to force other module to call a ttm function just to
eventually call gtt_mgr functions.
v4: remove unused adev.
v3: upcast mgr from ttm resopurce manager instead of
getting it from adev.
v2:
36 matches
Mail list logo
