[AMD Official Use Only - General]
> Presumably other gfx versions require something similar?
From firmware guys, that is always the case. firmware would checks
gds_backup_addr zero or not to restore gds partition in the resumed sequence.
Currently, only gfx9 has the scenario that os sending
Reviewed-by: Sui Jingfeng
On 2023/5/24 17:21, Thomas Zimmermann wrote:
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the callbacks. Fbdev-generic was the
only caller of the DRM helpers, so remove
Hi Melissa,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.4-rc3 next-20230524]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
Hi,
I have just tested this patch on my i3-8100@3.6Ghz cpu + h110
motherboard with fbtest:
Benchmarking... 10x10 squares: 26.44 Mpixels/s
Benchmarking... 20x20 squares: 52.54 Mpixels/s
Benchmarking... 50x50 squares: 128.13 Mpixels/s
Benchmarking... 100x100 squares: 252.21 Mpixels/s
[AMD Official Use Only - General]
Tested-by: Ying Li for the patch
-Original Message-
From: Zhu, James
Sent: Wednesday, May 24, 2023 4:35 PM
To: amd-gfx@lists.freedesktop.org; Li, Ying
Cc: Wu, Jason ; Deng, Bonnie ; Liang,
Richard qi
Subject: [PATCH] drm/jpeg: add init value for
[AMD Official Use Only - General]
Reviewed-by: Richard Liang for the patch.
-Original Message-
From: Zhu, James
Sent: Wednesday, May 24, 2023 4:35 PM
To: amd-gfx@lists.freedesktop.org; Li, Ying
Cc: Wu, Jason ; Deng, Bonnie ; Liang,
Richard qi
Subject: [PATCH] drm/jpeg: add init
Hi Dave, Daniel,
Fixes for 6.4.
The following changes since commit 79ef1c9d14c65a5c3f7eec47389d8c2a33be8e8d:
Merge tag 'amd-drm-fixes-6.4-2023-05-18' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2023-05-19 11:26:21
+1000)
are available in the Git repository at:
Hi,
we love your patch:
On 2023/5/24 17:21, Thomas Zimmermann wrote:
For framebuffers in I/O and system memory, add macros that set
struct fb_ops to the respective callback functions.
For deferred I/O, add macros that generate callback functions with
damage handling. Add initializer macros
Reviewed-by: Sui Jingfeng
On 2023/5/24 17:21, Thomas Zimmermann wrote:
Many fbdev drivers use the same set of fb_ops helpers. Add Kconfig
options to select them at once. This will help with making DRM's
fbdev emulation code more modular, but can also be used to simplify
fbdev's driver
Acked-by: Alex Deucher
On Wed, May 24, 2023 at 4:35 PM James Zhu wrote:
>
> Need init new num_jpeg_rings to 1 on jpeg.
>
> Signed-off-by: James Zhu
> ---
> drivers/gpu/drm/amd/amdgpu/jpeg_v1_0.c | 1 +
> drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c | 1 +
> drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c |
Need init new num_jpeg_rings to 1 on jpeg.
Signed-off-by: James Zhu
---
drivers/gpu/drm/amd/amdgpu/jpeg_v1_0.c | 1 +
drivers/gpu/drm/amd/amdgpu/jpeg_v2_0.c | 1 +
drivers/gpu/drm/amd/amdgpu/jpeg_v2_5.c | 1 +
drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c | 1 +
drivers/gpu/drm/amd/amdgpu/jpeg_v4_0.c
+ Kees
On 5/24/23 15:50, Alex Deucher wrote:
On Wed, May 24, 2023 at 3:46 PM Felix Kuehling wrote:
Sure, I think we tried enabling warnings as errors before and had to
revert it because of weird compiler quirks or the variety of compiler
versions that need to be supported.
Alex, are you
Tested-by: Sui Jingfeng
This version works fine, I have tested it On LoongArch with
drm/loongson(v14) as it is most handy for me.
Also because it using fbdev-generic. fbdev of IGT report no error. Then
I run fbtest from geert[1],
Before apply your patch:
Benchmarking... 10x10 squares:
On 5/24/23 15:54, Harry Wentland wrote:
On 5/24/23 15:27, Hamza Mahfooz wrote:
On 5/24/23 15:22, Alex Deucher wrote:
On Wed, May 24, 2023 at 3:20 PM Hamza Mahfooz wrote:
Currently, there are quite a number of issues that are quite easy for
the CI to catch, that slip through the cracks.
[AMD Official Use Only - General]
I ran some experiment yesterday to turn on CONFIG_WERROR and here are some
results (summary: gcc 12 seems ok but gcc 13 gives a lot more error, but not
necessarily in our module.)
Build with gcc13 using Fedora 38:
On 5/24/23 15:27, Hamza Mahfooz wrote:
> On 5/24/23 15:22, Alex Deucher wrote:
>> On Wed, May 24, 2023 at 3:20 PM Hamza Mahfooz wrote:
>>>
>>> Currently, there are quite a number of issues that are quite easy for
>>> the CI to catch, that slip through the cracks. Among them, there are
>>>
On 3/17/23 09:53, Joshua Ashton wrote:
>
>
> On 3/17/23 13:35, Pekka Paalanen wrote:
>> On Fri, 17 Mar 2023 14:50:40 +0200
>> Ville Syrjälä wrote:
>>
>>> On Fri, Mar 17, 2023 at 10:53:35AM +0200, Pekka Paalanen wrote:
On Fri, 17 Mar 2023 01:01:38 +0200
Ville Syrjälä wrote:
On Wed, May 24, 2023 at 3:46 PM Felix Kuehling wrote:
>
> Sure, I think we tried enabling warnings as errors before and had to
> revert it because of weird compiler quirks or the variety of compiler
> versions that need to be supported.
>
> Alex, are you planning to upstream this, or is this only
Sure, I think we tried enabling warnings as errors before and had to
revert it because of weird compiler quirks or the variety of compiler
versions that need to be supported.
Alex, are you planning to upstream this, or is this only to enforce more
internal discipline about not ignoring
[AMD Official Use Only - General]
(Adding Felix in CC)
I’m a fan of adding it to KFD as well. Felix, can you foresee any issues here?
Kent
From: amd-gfx On Behalf Of Ho, Kenny
Sent: Wednesday, May 24, 2023 3:23 PM
To: Alex Deucher ; Mahfooz, Hamza
Cc: Li, Sun peng (Leo) ; Wentland, Harry
;
On 5/24/23 15:22, Alex Deucher wrote:
On Wed, May 24, 2023 at 3:20 PM Hamza Mahfooz wrote:
Currently, there are quite a number of issues that are quite easy for
the CI to catch, that slip through the cracks. Among them, there are
unused variable and indentation issues. Also, we should
[AMD Official Use Only - General]
(+ Felix)
Should we do the same for other modules under amd (amdkfd)? I was going to
enable full kernel werror in the kconfig used by my CI but this is probably
better.
Kenny
From: Alex Deucher
Sent: Wednesday, May 24, 2023
On Wed, May 24, 2023 at 3:20 PM Hamza Mahfooz wrote:
>
> Currently, there are quite a number of issues that are quite easy for
> the CI to catch, that slip through the cracks. Among them, there are
> unused variable and indentation issues. Also, we should consider all
> warnings to be compile
Currently, there are quite a number of issues that are quite easy for
the CI to catch, that slip through the cracks. Among them, there are
unused variable and indentation issues. Also, we should consider all
warnings to be compile errors, since the community will eventually end
up complaining
Currently, there are quite a number of issues that are quite easy for
the CI to catch, that slip through the cracks. Among them, there unused
variable and indentation issues. Also, we should consider all warnings
to be compile errors, since the community will eventually end up
complaining about
PF0_PARTITION_COMPUTE_STATUS, tmp);
> }
>
> -static enum amdgpu_memory_partition
> -nbio_v7_9_get_memory_partition_mode(struct amdgpu_device *adev, u32
> *supp_modes)
> +static u32 nbio_v7_9_get_memory_partition_mode(struct amdgpu_device *adev,
> +
Am 24.05.23 um 00:53 schrieb Chia-I Wu:
Validate drm_amdgpu_gem_va addrs in amdgpu_gem_va_ioctl.
amdgpu_vm_bo_replace_map no longer needs to validate (and its
validations were insufficient either). amdgpu_vm_bo_map has internal
users and its validations are kept.
No, please keep all
On 3/8/23 04:24, Pekka Paalanen wrote:
> On Tue, 7 Mar 2023 10:10:59 -0500
> Harry Wentland wrote:
>
>> We want compositors to be able to set the output
>> colorspace on DP and HDMI outputs, based on the
>> caps reported from the receiver via EDID.
>>
>> Signed-off-by: Harry Wentland
>> Cc:
On 5/24/23 13:58, Mario Limonciello wrote:
> There is already access to the DPCD from userspace through
> `CONFIG_DRM_DP_AUX_CHARDEV`, so it's unnecessary to reinvent the wheel
> with a set of extra debugfs nodes specific to amdgpu.
>
> The character device interface behaves more like you
On 5/24/23 13:58, Mario Limonciello wrote:
There is already access to the DPCD from userspace through
`CONFIG_DRM_DP_AUX_CHARDEV`, so it's unnecessary to reinvent the wheel
with a set of extra debugfs nodes specific to amdgpu.
The character device interface behaves more like you would expect in
There is already access to the DPCD from userspace through
`CONFIG_DRM_DP_AUX_CHARDEV`, so it's unnecessary to reinvent the wheel
with a set of extra debugfs nodes specific to amdgpu.
The character device interface behaves more like you would expect in that
you can seek/read/write all from the
[AMD Official Use Only - General]
Acked-by: Alex Deucher
From: amd-gfx on behalf of
jiadong@amd.com
Sent: Wednesday, May 24, 2023 12:35 AM
To: amd-gfx@lists.freedesktop.org
Cc: Zhu, Jiadong
Subject: [PATCH] drm/amdgpu: Reset CP_VMID_PREEMPT after
On 3/8/23 04:09, Pekka Paalanen wrote:
> On Tue, 7 Mar 2023 10:10:53 -0500
> Harry Wentland wrote:
>
>> From: Joshua Ashton
>>
>> Userspace has no way of controlling or knowing the pixel encoding
>> currently, so there is no way for it to ever get the right values here.
>>
>> When we do add
On 3/8/23 03:59, Pekka Paalanen wrote:
> On Tue, 7 Mar 2023 10:10:52 -0500
> Harry Wentland wrote:
>
>> From: Joshua Ashton
>>
>> To match the other enums, and add more information about these values.
>>
>> v2:
>> - Specify where an enum entry comes from
>> - Clarify DEFAULT and NO_DATA
;
---
base-commit: fd8f7bb391fa9c1979232cb5ab5bedb08abc855d
change-id:
20230524-nbio_v7_9-wincompatible-function-pointer-types-strict-c894636ce146
Best regards,
--
Nathan Chancellor
On 5/24/23 12:19, Srinivasan Shanmugam wrote:
gcc with W=1
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn321/dcn321_resource.c:1346:43:
warning: ‘res_create_maximus_funcs’ defined but not used
[-Wunused-const-variable=]
1346 | static const struct resource_create_funcs res_create_maximus_funcs
gcc with W=1
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn321/dcn321_resource.c:1346:43:
warning: ‘res_create_maximus_funcs’ defined but not used
[-Wunused-const-variable=]
1346 | static const struct resource_create_funcs res_create_maximus_funcs = {
|
On 24/05/2023 18:10, Neil Armstrong wrote:
Hi,
On Mon, 15 May 2023 07:30:07 -0700, Rob Clark wrote:
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with
Hi,
On Wed, 24 May 2023 08:59:30 -0700, Rob Clark wrote:
> From: Rob Clark
>
> Similar motivation to other similar recent attempt[1]. But with an
> attempt to have some shared code for this. As well as documentation.
>
> It is probably a bit UMA-centric, I guess devices with VRAM might want
Hi,
On Mon, 15 May 2023 07:30:07 -0700, Rob Clark wrote:
> Similar motivation to other similar recent attempt[1]. But with an
> attempt to have some shared code for this. As well as documentation.
>
> It is probably a bit UMA-centric, I guess devices with VRAM might want
> some placement stats
In setup_vmid_config functions of all mmhubs, the CONTEXT1_CNTL reg is
enabled before related CONTEXT1_PAGE_TABLE_START_ADDR and
CONTEXT1_PAGE_TABLE_END_ADDR regs are written, which may cause
undefined behavior.
This patch enable CONTEXT1_CNTL after page table addresses are set,
so that it can
From: Rob Clark
v2: Rebase on drm-misc-next
Signed-off-by: Rob Clark
Reviewed-by: Christian König
Acked-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 32 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices with VRAM might want
some placement stats as well. But this seems like a reasonable start.
On 5/24/23 04:57, Jiapeng Chong wrote:
No functional modification involved.
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/dcn314_fpu.c:269
dcn314_update_bw_bounding_box_fpu() warn: inconsistent indenting.
Reported-by: Abaci Robot
Closes:
On 5/23/23 23:59, Yang Li wrote:
Eliminate the following warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_resource.c:889:43:
warning: unused variable 'res_create_maximus_funcs'
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5296
Fixes:
On Wed, May 24, 2023 at 11:25 AM ghostfly233 wrote:
>
> In gfxhub_v2_1_setup_vmid_config(), the GCVM_CONTEXT1_CNTL reg is
> enabled before related GCVM_CONTEXT1_PAGE_TABLE_START_ADDR and
> GCVM_CONTEXT1_PAGE_TABLE_END_ADDR regs are written, which may
> cause undefined behavior.
>
> This patch
In gfxhub_v2_1_setup_vmid_config(), the GCVM_CONTEXT1_CNTL reg is
enabled before related GCVM_CONTEXT1_PAGE_TABLE_START_ADDR and
GCVM_CONTEXT1_PAGE_TABLE_END_ADDR regs are written, which may
cause undefined behavior.
This patch enable GCVM_CONNTEXT1_CNTL after page table addresses are set,
so
On Wed, May 24, 2023 at 11:22 AM Srinivasan Shanmugam
wrote:
>
> gcc with W=1
> In file included from drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:33:
> drivers/gpu/drm/amd/amdgpu/clearstate_gfx9.h:939:36: warning: ‘gfx9_cs_data’
> defined but not used [-Wunused-const-variable=]
> 939 | static
gcc with W=1
In file included from drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:33:
drivers/gpu/drm/amd/amdgpu/clearstate_gfx9.h:939:36: warning: ‘gfx9_cs_data’
defined but not used [-Wunused-const-variable=]
939 | static const struct cs_section_def gfx9_cs_data[] = {
|
gfx9_cs_data is not
Since bios reading does not work currently so just bypass all operations
related to bios
v2: hardcode the vram info for APP_APU case (hawking)
v3: correct the vram_width with channel number * channel size (lijo)
Signed-off-by: Shiwu Zhang
Reviewed-by: Yang Wang
Reviewed-by: Hawking Zhang
---
On Wed, May 24, 2023 at 5:00 AM wrote:
>
> From: Jiadong Zhu
>
> It is firmware requirement to set gds_backup_addrlo and gds_backup_addrhi
> of DE meta both zero if no gds partition is allocated for the frame.
Presumably other gfx versions require something similar?
Reviewed-by: Alex Deucher
No functional modification involved.
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn321/dcn321_fpu.c:556
dcn321_update_bw_bounding_box_fpu() warn: inconsistent indenting.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5304
Signed-off-by: Jiapeng Chong
---
On Tue, 23 May 2023 21:14:50 -0100
Melissa Wen wrote:
> Hook up driver-specific atomic operations for managing AMD color
> properties and create AMD driver-specific color management properties
> and attach them according to HW capabilities defined by `struct
> dc_color_caps`. Add enumerated
No functional modification involved.
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/dcn314_fpu.c:269
dcn314_update_bw_bounding_box_fpu() warn: inconsistent indenting.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5305
Signed-off-by: Jiapeng Chong
---
Eliminate the following warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn302/dcn302_resource.c:957:43:
warning: unused variable 'res_create_maximus_funcs'
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn302/dcn302_resource.c:101:38:
warning: unused variable 'debug_defaults_diags'
Reported-by:
Eliminate the following warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn314/dcn314_resource.c:1390:43:
warning: unused variable 'res_create_maximus_funcs'
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5296
Fixes: 00df97e1df57 ("drm/amd/display: Clean FPGA
Eliminate the following warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_resource.c:889:43:
warning: unused variable 'res_create_maximus_funcs'
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5296
Fixes: 00df97e1df57 ("drm/amd/display: Clean FPGA
During reboot test on arm64 platform, it may failure
on boot.
The error message are as follows:
[1.706570][ 3] [ T273] [drm:si_thermal_enable_alert [amdgpu]] *ERROR*
Could not enable thermal interrupts.
[1.716547][ 3] [ T273] [drm:amdgpu_device_ip_late_init [amdgpu]] *ERROR*
late_init
During reboot test on arm64 platform, it may failure
on boot.
The error message are as follows:
[1.706570][ 3] [ T273] [drm:si_thermal_enable_alert [amdgpu]] *ERROR*
Could not enable thermal interrupts.
[1.716547][ 3] [ T273] [drm:amdgpu_device_ip_late_init [amdgpu]] *ERROR*
late_init
Eliminate the following warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn301/dcn301_resource.c:1050:43:
warning: unused variable 'res_create_maximus_funcs'
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn301/dcn301_resource.c:705:38:
warning: unused variable 'debug_defaults_diags'
Reported-by:
Eliminate the following warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.c:1355:43:
warning: unused variable 'res_create_maximus_funcs'
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.c:899:38:
warning: unused variable 'debug_defaults_diags'
Reported-by:
Eliminate the following warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.c:1357:43:
warning: unused variable 'res_create_maximus_funcs'
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.c:893:38:
warning: unused variable 'debug_defaults_diags'
Reported-by:
Eliminate the following warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_resource.c:1360:43:
warning: unused variable 'res_create_maximus_funcs'
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_resource.c:737:38:
warning: unused variable 'debug_defaults_diags'
Reported-by:
Eliminate the following warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn321/dcn321_resource.c:1346:43:
warning: unused variable 'res_create_maximus_funcs'
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn321/dcn321_resource.c:735:38:
warning: unused variable 'debug_defaults_diags'
Reported-by:
Eliminate the following warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:1222:43:
warning: unused variable 'res_create_maximus_funcs'
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:658:38:
warning: unused variable 'debug_defaults_diags'
Reported-by:
Eliminate the following warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:1079:43:
warning: unused variable 'res_create_maximus_funcs'
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:731:38:
warning: unused variable 'debug_defaults_diags'
Reported-by:
During reboot test on arm64 platform, it may failure
on boot.
The error message are as follows:
[1.706570][ 3] [ T273] [drm:si_thermal_enable_alert [amdgpu]] *ERROR*
Could not enable thermal interrupts.
[1.716547][ 3] [ T273] [drm:amdgpu_device_ip_late_init [amdgpu]] *ERROR*
late_init
This patch is part of the Linux Kernel Bug Fixing Summer screening
tasks. By removing the extra description, several documentation
compilation warnings such as the following have been fixed:
> ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:758: warning: Excess function
> parameter 'pcie_index'
Eliminate the following warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn303/dcn303_resource.c:884:43:
warning: unused variable 'res_create_maximus_funcs'
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn303/dcn303_resource.c:84:38:
warning: unused variable 'debug_defaults_diags'
Reported-by:
Hello Qingqing Zhuo,
The patch 00df97e1df57: "drm/amd/display: Clean FPGA code in dc" from
Mar 16, 2023, leads to the following Smatch static checker warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn21/rn_clk_mgr.c:775
rn_clk_mgr_construct()
warn: variable dereferenced before check
Eliminate the following warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.c:1356:43:
warning: unused variable 'res_create_maximus_funcs'
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.c:894:38:
warning: unused variable 'debug_defaults_diags'
Reported-by:
During reboot test on arm64 platform, it may failure
on boot.
The error message are as follows:
[1.706570][ 3] [ T273] [drm:si_thermal_enable_alert [amdgpu]] *ERROR*
Could not enable thermal interrupts.
[1.716547][ 3] [ T273] [drm:amdgpu_device_ip_late_init [amdgpu]] *ERROR*
late_init
Eliminate the following warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn201/dcn201_resource.c:899:43:
warning: unused variable 'res_create_maximus_funcs'
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5296
Fixes: 00df97e1df57 ("drm/amd/display: Clean FPGA
Recent code stores xcp_id to amdgpu bo for accounting memory
usage or find correct KFD node, and this xcp_id is from file
private data after opening device. However, not all VMs are
attached to this fpriv structure like the case in amdgpu_mes_self_test.
So add a flag to differentiate the cases.
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the callbacks. Fbdev-generic was the
only caller of the DRM helpers, so remove them from the helper
module.
v4:
* generate deferred-I/O helpers
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Tegra does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Fbdev-dma does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
For framebuffers in I/O and system memory, add macros that set
struct fb_ops to the respective callback functions.
For deferred I/O, add macros that generate callback functions with
damage handling. Add initializer macros that set struct fb_ops to
the generated callbacks.
These macros can remove
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Radeon does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Omapdrm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Export drm_fb_helper_damage() and drm_fb_helper_damage_range(), which
handle damage areas for fbdev emulation. This is a temporary export
that allows to move the DRM I/O helpers for fbdev into drivers. Only
fbdev-generic and i915 need them. Both will be updated to implement
damage handling by
DRM provides a number of wrappers around fbdev cfb_() sys_(), fb_io_()
and fb_sys_() helpers. The DRM functions don't provide any additional
functionality for most DRM drivers. So remove them and call the fbdev
I/O helpers directly.
The DRM fbdev I/O wrappers were originally added because
does
Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Use an fbdev generator macro for
deferred I/O to create the fbdev callbacks. i915 was the only
caller of the DRM helpers, so remove them from the helper module.
i915's fbdev emulation is still incomplete as it
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Armada does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Msm does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Gma500 does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Exynos does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.
By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions
Many fbdev drivers use the same set of fb_ops helpers. Add Kconfig
options to select them at once. This will help with making DRM's
fbdev emulation code more modular, but can also be used to simplify
fbdev's driver configs.
v3:
* fix select statement (Jingfeng)
Signed-off-by: Thomas
[Public]
Thanks for your prompt patch for this.
Reviewed-by: Guchun Chen
Regards,
Guchun
> -Original Message-
> From: Zhang, Yifan
> Sent: Wednesday, May 24, 2023 5:01 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Chen, Guchun
> ; lizhenn...@kylinos.cn; Zhang,
Fix compiling warnings:
CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.o
CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.o
drivers/gpu/drm/amd/amdgpu/../pm/legacy-dpm/si_dpm.c:6928:12: warning:
‘si_set_temperature_range’ defined but not used
From: Jiadong Zhu
It is firmware requirement to set gds_backup_addrlo and gds_backup_addrhi
of DE meta both zero if no gds partition is allocated for the frame.
Signed-off-by: Jiadong Zhu
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 13 -
1 file changed, 8 insertions(+), 5
[AMD Official Use Only - General]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Shiwu Zhang
Sent: Thursday, May 18, 2023 20:21
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH v2 4/6] drm/amdgpu: Use single copy per SDMA instance type (v2)
[AMD Official Use Only - General]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Shiwu Zhang
Sent: Thursday, May 18, 2023 20:21
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH v2 6/6] drm/amdgpu: complement the 4, 6 and 8 XCC cases
[Public]
Applied by modifying the subject a bit to " drm/amd/pm: resolve reboot
exception for si oland". Thanks.
Regards,
Guchun
> -Original Message-
> From: Zhenneng Li
> Sent: Wednesday, May 24, 2023 2:00 PM
> To: Chen, Guchun
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Pan,
94 matches
Mail list logo
