Re: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers

[kernel test robot]

Hi Mario,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip 
linus/master v6.8-rc4 next-20240216]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/drm-Stop-using-select-ACPI_VIDEO-in-all-drivers/20240215-055936
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240214215756.6530-2-mario.limonciello%40amd.com
patch subject: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers
config: alpha-kismet-CONFIG_FB_BACKLIGHT-CONFIG_FB_TFT-0-0 
(https://download.01.org/0day-ci/archive/20240217/202402171302.hkl1cpkb-...@intel.com/config)
reproduce: 
(https://download.01.org/0day-ci/archive/20240217/202402171302.hkl1cpkb-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202402171302.hkl1cpkb-...@intel.com/

kismet warnings: (new ones prefixed by >>)
>> kismet: WARNING: unmet direct dependencies detected for FB_BACKLIGHT when 
>> selected by FB_TFT
   .config:262:warning: symbol value 'n' invalid for SATA_MOBILE_LPM_POLICY
   .config:360:warning: symbol value 'n' invalid for PSTORE_BLK_MAX_REASON
   .config:445:warning: symbol value 'n' invalid for KFENCE_SAMPLE_INTERVAL
   .config:599:warning: symbol value 'n' invalid for AIC79XX_DEBUG_MASK
   .config:634:warning: symbol value 'n' invalid for AIC79XX_RESET_DELAY_MS
   .config:638:warning: symbol value 'n' invalid for DRM_XE_JOB_TIMEOUT_MIN
   .config:680:warning: symbol value 'n' invalid for CRYPTO_DEV_QCE_SW_MAX_LEN
   .config:780:warning: symbol value 'n' invalid for PANEL_LCD_CHARSET
   .config:820:warning: symbol value 'n' invalid for SND_AC97_POWER_SAVE_DEFAULT
   .config:881:warning: symbol value 'n' invalid for MAGIC_SYSRQ_DEFAULT_ENABLE
   .config:894:warning: symbol value 'n' invalid for 
DRM_I915_MAX_REQUEST_BUSYWAIT
   .config:928:warning: symbol value 'n' invalid for DRM_XE_PREEMPT_TIMEOUT_MIN
   .config:939:warning: symbol value 'n' invalid for SND_AT73C213_TARGET_BITRATE
   .config:940:warning: symbol value 'n' invalid for NET_EMATCH_STACK
   .config:942:warning: symbol value 'n' invalid for VMCP_CMA_SIZE
   .config:1112:warning: symbol value 'n' invalid for AIC79XX_CMDS_PER_DEVICE
   .config:1181:warning: symbol value 'n' invalid for PANEL_LCD_PIN_SDA
   .config:1208:warning: symbol value 'n' invalid for MTDRAM_ERASE_SIZE
   .config:1238:warning: symbol value 'n' invalid for 
MTD_REDBOOT_DIRECTORY_BLOCK
   .config:1330:warning: symbol value 'n' invalid for SERIAL_UARTLITE_NR_UARTS
   .config:1516:warning: symbol value 'n' invalid for LEGACY_PTY_COUNT
   .config:1666:warning: symbol value 'n' invalid for AIC7XXX_RESET_DELAY_MS
   .config:1808:warning: symbol value 'n' invalid for IBM_EMAC_POLL_WEIGHT
   .config:1972:warning: symbol value 'n' invalid for DRM_I915_STOP_TIMEOUT
   .config:2387:warning: symbol value 'n' invalid for PANEL_LCD_BWIDTH
   .config:2412:warning: symbol value 'n' invalid for DRM_XE_TIMESLICE_MAX
   .config:2427:warning: symbol value 'n' invalid for 
FTRACE_RECORD_RECURSION_SIZE
   .config:2607:warning: symbol value 'n' invalid for KCOV_IRQ_AREA_SIZE
   .config:2633:warning: symbol value 'n' invalid for PANEL_PARPORT
   .config:2722:warning: symbol value 'n' invalid for NOUVEAU_DEBUG_DEFAULT
   .config:2919:warning: symbol value 'n' invalid for KCSAN_REPORT_ONCE_IN_MS
   .config:3017:warning: symbol value 'n' invalid for KCSAN_UDELAY_INTERRUPT
   .config:3041:warning: symbol value 'n' invalid for PANEL_LCD_PIN_BL
   .config:3066:warning: symbol value 'n' invalid for INITRAMFS_ROOT_GID
   .config:3113:warning: symbol value 'n' invalid for 
SND_SOC_SOF_DEBUG_IPC_FLOOD_TEST_NUM
   .config:3132:warning: symbol value 'n' invalid for SCSI_MESH_RESET_DELAY_MS
   .config:3173:warning: symbol value 'n' invalid for ATM_FORE200E_TX_RETRY
   .config:3216:warning: symbol value 'n' invalid for 
FB_OMAP2_DSS_MIN_FCK_PER_PCK
   .config:3306:warning: symbol value 'n' invalid for IP_VS_MH_TAB_INDEX
   .config:3454:warning: symbol value 'n' invalid for PSTORE_BLK_CONSOLE_SIZE
   .config:3554:warning: symbol value 'n' invalid for KCSAN_UDELAY_TASK
   .config:3564:warning: symbol value 'n' invalid for MMC_BLOCK_MINORS
   .config:3567:warning: symbol value 'n' invalid for INET_TABLE_PERTURB_ORDER
   .config:3612:warning: symbol value 'n' invalid for SCSI_NCR53C8XX_SYNC
   .config:3638:warning: symbol value 'n' invalid for BOOKE_WDT_DEFAULT_TIMEOUT
   .config:3730:warning: symbol value 'n' invalid for UCLAMP_BUCKETS_COU

[linux-next:master] BUILD REGRESSION d37e1e4c52bc60578969f391fb81f947c3e83118

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: d37e1e4c52bc60578969f391fb81f947c3e83118  Add linux-next specific 
files for 20240216

Error/Warning reports:

https://lore.kernel.org/oe-kbuild-all/202402161359.furktcoz-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202402161410.ig9i4odj-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202402162252.fpea3zuy-...@intel.com

Error/Warning: (recently discovered and may have been fixed)

aarch64-linux-ld: ktd2801-backlight.c:(.text+0x118): undefined reference to 
`expresswire_power_off'
aarch64-linux-ld: ktd2801-backlight.c:(.text+0x16c): undefined reference to 
`expresswire_enable'
drivers/gpu/drm/tests/drm_buddy_test.c:(.text.drm_test_buddy_alloc_contiguous+0xb0):
 undefined reference to `__umoddi3'
drivers/gpu/drm/tests/drm_buddy_test.c:48:(.text+0xfc): undefined reference to 
`__umoddi3'
ktd2801-backlight.c:(.text+0x118): relocation truncated to fit: 
R_AARCH64_CALL26 against undefined symbol `expresswire_power_off'
ktd2801-backlight.c:(.text+0x16c): relocation truncated to fit: 
R_AARCH64_CALL26 against undefined symbol `expresswire_enable'
ktd2801-backlight.c:(.text+0xe4): relocation truncated to fit: R_AARCH64_CALL26 
against undefined symbol `expresswire_write_u8'
ktd2801-backlight.c:(.text+0xe4): undefined reference to `expresswire_write_u8'
xtensa-linux-ld: arch/xtensa/boot/lib/inftrees.c:220:(.text+0x4d3): undefined 
reference to `__ubsan_handle_shift_out_of_bounds'
xtensa-linux-ld: arch/xtensa/boot/lib/inftrees.c:96:(.text+0x152): undefined 
reference to `__ubsan_handle_out_of_bounds'

Unverified Error/Warning (likely false positive, please contact us if 
interested):

fs/btrfs/space-info.c:2012:13: warning: 'ret' may be used uninitialized 
[-Wmaybe-uninitialized]
include/linux/netfilter/x_tables.h:372: undefined reference to `xt_recseq'
include/linux/seqlock.h:72: undefined reference to `xt_recseq'
ld: include/linux/netfilter/x_tables.h:379: undefined reference to `xt_recseq'
ld: include/linux/seqlock.h:73: undefined reference to `xt_recseq'
ld: net/ipv4/netfilter/arp_tables.c:1014: undefined reference to 
`xt_find_table_lock'
ld: net/ipv4/netfilter/arp_tables.c:1469: undefined reference to 
`xt_find_revision'
ld: net/ipv4/netfilter/arp_tables.c:1497: undefined reference to 
`xt_free_table_info'
ld: net/ipv4/netfilter/arp_tables.c:1526: undefined reference to 
`xt_register_table'
ld: net/ipv4/netfilter/arp_tables.c:1648: undefined reference to 
`xt_unregister_targets'
ld: net/ipv4/netfilter/arp_tables.c:417: undefined reference to 
`xt_request_find_target'
ld: net/ipv4/netfilter/arp_tables.c:432: undefined reference to 
`xt_percpu_counter_free'
ld: net/ipv4/netfilter/arp_tables.c:900: undefined reference to 
`xt_request_find_table_lock'
ld: net/ipv4/netfilter/arp_tables.c:912: undefined reference to 
`xt_replace_table'
ld: net/ipv4/netfilter/arp_tables.c:944: undefined reference to 
`xt_table_unlock'
ld: net/ipv4/netfilter/arptable_filter.c:67: undefined reference to 
`xt_hook_ops_alloc'
ld: net/ipv4/netfilter/arptable_filter.c:75: undefined reference to 
`xt_unregister_template'
net/ipv4/netfilter/arp_tables.c:1010: undefined reference to `xt_copy_counters'
net/ipv4/netfilter/arp_tables.c:1040: undefined reference to `xt_table_unlock'
net/ipv4/netfilter/arp_tables.c:1469: undefined reference to `xt_find_revision'
net/ipv4/netfilter/arp_tables.c:1489: undefined reference to 
`xt_unregister_table'
net/ipv4/netfilter/arp_tables.c:1513: undefined reference to 
`xt_alloc_table_info'
net/ipv4/netfilter/arp_tables.c:1575: undefined reference to `xt_find_table'
net/ipv4/netfilter/arp_tables.c:1614: undefined reference to `xt_proto_init'
net/ipv4/netfilter/arp_tables.c:1619: undefined reference to `xt_proto_fini'
net/ipv4/netfilter/arp_tables.c:1636: undefined reference to 
`xt_register_targets'
net/ipv4/netfilter/arp_tables.c:1658: undefined reference to 
`xt_unregister_targets'
net/ipv4/netfilter/arp_tables.c:369: undefined reference to 
`xt_find_jump_offset'
net/ipv4/netfilter/arp_tables.c:401: undefined reference to `xt_check_target'
net/ipv4/netfilter/arp_tables.c:413: undefined reference to 
`xt_percpu_counter_alloc'
net/ipv4/netfilter/arp_tables.c:475: undefined reference to 
`xt_check_entry_offsets'
net/ipv4/netfilter/arp_tables.c:513: undefined reference to 
`xt_percpu_counter_free'
net/ipv4/netfilter/arp_tables.c:539: undefined reference to 
`xt_alloc_entry_offsets'
net/ipv4/netfilter/arp_tables.c:565: undefined reference to 
`xt_check_table_hooks'
net/ipv4/netfilter/arp_tables.c:611: undefined reference to `xt_recseq'
net/ipv4/netfilter/arp_tables.c:706: undefined reference to `xt_target_to_user'
net/ipv4/netfilter/arp_tables.c:808: undefined reference to 
`xt_request_find_table_lock'
net/ipv4/netfilter/arp_tables.c:862: undefined reference to `xt_find_table_lock'
net/ipv4/netfilter/arp_tables.c:894: undefined reference to `xt_counters_alloc'
net/ipv4/netfilter/arptable_filter.c:61

Re: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers

[kernel test robot]

Hi Mario,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip 
linus/master v6.8-rc4 next-20240216]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/drm-Stop-using-select-ACPI_VIDEO-in-all-drivers/20240215-055936
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240214215756.6530-2-mario.limonciello%40amd.com
patch subject: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers
config: alpha-kismet-CONFIG_FB_BACKLIGHT-CONFIG_FB_SSD1307-0-0 
(https://download.01.org/0day-ci/archive/20240217/202402170903.pslaho5f-...@intel.com/config)
reproduce: 
(https://download.01.org/0day-ci/archive/20240217/202402170903.pslaho5f-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202402170903.pslaho5f-...@intel.com/

kismet warnings: (new ones prefixed by >>)
>> kismet: WARNING: unmet direct dependencies detected for FB_BACKLIGHT when 
>> selected by FB_SSD1307
   .config:254:warning: symbol value 'n' invalid for SATA_MOBILE_LPM_POLICY
   .config:268:warning: symbol value 'n' invalid for INPUT_MOUSEDEV_SCREEN_Y
   .config:441:warning: symbol value 'n' invalid for KFENCE_SAMPLE_INTERVAL
   .config:460:warning: symbol value 'n' invalid for AIC79XX_DEBUG_MASK
   .config:610:warning: symbol value 'n' invalid for 
USB_GADGET_STORAGE_NUM_BUFFERS
   .config:619:warning: symbol value 'n' invalid for DRM_XE_JOB_TIMEOUT_MIN
   .config:645:warning: symbol value 'n' invalid for CRYPTO_DEV_QCE_SW_MAX_LEN
   .config:757:warning: symbol value 'n' invalid for PANEL_LCD_CHARSET
   .config:758:warning: symbol value 'n' invalid for SERIAL_ALTERA_UART_BAUDRATE
   .config:800:warning: symbol value 'n' invalid for SND_AC97_POWER_SAVE_DEFAULT
   .config:834:warning: symbol value 'n' invalid for DUMMY_CONSOLE_ROWS
   .config:844:warning: symbol value 'n' invalid for MAGIC_SYSRQ_DEFAULT_ENABLE
   .config:858:warning: symbol value 'n' invalid for 
DRM_I915_MAX_REQUEST_BUSYWAIT
   .config:882:warning: symbol value 'n' invalid for AIC79XX_CMDS_PER_DEVICE
   .config:894:warning: symbol value 'n' invalid for SND_AT73C213_TARGET_BITRATE
   .config:903:warning: symbol value 'n' invalid for DRM_XE_PREEMPT_TIMEOUT_MIN
   .config:915:warning: symbol value 'n' invalid for NET_EMATCH_STACK
   .config:917:warning: symbol value 'n' invalid for VMCP_CMA_SIZE
   .config:942:warning: symbol value 'n' invalid for PANEL_LCD_PIN_SDA
   .config:1062:warning: symbol value 'n' invalid for PANEL_LCD_PIN_E
   .config:1143:warning: symbol value 'n' invalid for RCU_CPU_STALL_TIMEOUT
   .config:1173:warning: symbol value 'n' invalid for MTDRAM_ERASE_SIZE
   .config:1281:warning: symbol value 'n' invalid for SERIAL_UARTLITE_NR_UARTS
   .config:1324:warning: symbol value 'n' invalid for VERBOSE_MCHECK_ON
   .config:1453:warning: symbol value 'n' invalid for LEGACY_PTY_COUNT
   .config:1605:warning: symbol value 'n' invalid for AIC7XXX_RESET_DELAY_MS
   .config:1659:warning: symbol value 'n' invalid for XEN_MEMORY_HOTPLUG_LIMIT
   .config:1755:warning: symbol value 'n' invalid for IBM_EMAC_POLL_WEIGHT
   .config:1881:warning: symbol value 'n' invalid for DRM_I915_STOP_TIMEOUT
   .config:2135:warning: symbol value 'n' invalid for AIC79XX_RESET_DELAY_MS
   .config:2155:warning: symbol value 'n' invalid for KCOV_IRQ_AREA_SIZE
   .config:2172:warning: symbol value 'n' invalid for RCU_FANOUT_LEAF
   .config:2315:warning: symbol value 'n' invalid for DRM_XE_TIMESLICE_MAX
   .config:2317:warning: symbol value 'n' invalid for PANEL_LCD_BWIDTH
   .config:2557:warning: symbol value 'n' invalid for PANEL_PARPORT
   .config:2643:warning: symbol value 'n' invalid for NOUVEAU_DEBUG_DEFAULT
   .config:2791:warning: symbol value 'n' invalid for 
SND_SOC_SOF_DEBUG_IPC_FLOOD_TEST_NUM
   .config:2831:warning: symbol value 'n' invalid for KCSAN_REPORT_ONCE_IN_MS
   .config:2932:warning: symbol value 'n' invalid for KCSAN_UDELAY_INTERRUPT
   .config:2954:warning: symbol value 'n' invalid for PANEL_LCD_PIN_BL
   .config:2972:warning: symbol value 'n' invalid for 
DEBUG_OBJECTS_ENABLE_DEFAULT
   .config:2978:warning: symbol value 'n' invalid for INITRAMFS_ROOT_GID
   .config:3082:warning: symbol value 'n' invalid for ATM_FORE200E_TX_RETRY
   .config:3119:warning: symbol value 'n' invalid for 
FB_OMAP2_DSS_MIN_FCK_PER_PCK
   .config:3212:warning: symbol value 'n' invalid for PSTORE_BLK_CONSOLE_SIZE
   .config:3341:warning: symbol value 'n' invalid for BOOKE_W

Re: [PATCH] drm/amd: Drop abm_level property

[Harry Wentland]

On 2024-02-16 10:33, Mario Limonciello wrote:
> This vendor specific property has never been used by userspace
> software and conflicts with the panel_power_savings sysfs file.
> That is a compositor and user could fight over the same data.
> 
> Fixes: f97e4303da16 ("drm/amd/display: add panel_power_savings sysfs entry to 
> eDP connectors")
> Suggested-by: Harry Wentland 
> Signed-off-by: Mario Limonciello 
> --
> Cc: Hamza Mahfooz 
> Cc: Sun peng (Leo) Li 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  8 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  2 --
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 --
>  3 files changed, 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index b8fbe97efe1d..3ecc7ef95172 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -1350,14 +1350,6 @@ int amdgpu_display_modeset_create_props(struct 
> amdgpu_device *adev)
>"dither",
>amdgpu_dither_enum_list, sz);
>  
> - if (adev->dc_enabled) {
> - adev->mode_info.abm_level_property =
> - drm_property_create_range(adev_to_drm(adev), 0,
> -   "abm level", 0, 4);
> - if (!adev->mode_info.abm_level_property)
> - return -ENOMEM;
> - }
> -
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index 2e4911050cc5..1fe21a70ddd0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -324,8 +324,6 @@ struct amdgpu_mode_info {
>   struct drm_property *audio_property;
>   /* FMT dithering */
>   struct drm_property *dither_property;
> - /* Adaptive Backlight Modulation (power feature) */
> - struct drm_property *abm_level_property;
>   /* hardcoded DFP edid from BIOS */
>   struct edid *bios_hardcoded_edid;
>   int bios_hardcoded_edid_size;
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index b9ac3d2f8029..e3b32ffba85a 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6388,9 +6388,6 @@ int amdgpu_dm_connector_atomic_set_property(struct 
> drm_connector *connector,
>   } else if (property == adev->mode_info.underscan_property) {
>   dm_new_state->underscan_enable = val;
>   ret = 0;
> - } else if (property == adev->mode_info.abm_level_property) {
> - dm_new_state->abm_level = val ?: ABM_LEVEL_IMMEDIATE_DISABLE;
> - ret = 0;
>   }
>  
>   return ret;
> @@ -6433,10 +6430,6 @@ int amdgpu_dm_connector_atomic_get_property(struct 
> drm_connector *connector,
>   } else if (property == adev->mode_info.underscan_property) {
>   *val = dm_state->underscan_enable;
>   ret = 0;
> - } else if (property == adev->mode_info.abm_level_property) {
> - *val = (dm_state->abm_level != ABM_LEVEL_IMMEDIATE_DISABLE) ?
> - dm_state->abm_level : 0;
> - ret = 0;
>   }
>  
>   return ret;
> @@ -7652,13 +7645,6 @@ void amdgpu_dm_connector_init_helper(struct 
> amdgpu_display_manager *dm,
>   aconnector->base.state->max_bpc = 16;
>   aconnector->base.state->max_requested_bpc = 
> aconnector->base.state->max_bpc;
>  
> - if (connector_type == DRM_MODE_CONNECTOR_eDP &&
> - (dc_is_dmcu_initialized(adev->dm.dc) ||
> -  adev->dm.dc->ctx->dmub_srv) && amdgpu_dm_abm_level < 0) {
> - drm_object_attach_property(>base.base,
> - adev->mode_info.abm_level_property, 0);
> - }
> -
>   if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
>   /* Content Type is currently only implemented for HDMI. */
>   drm_connector_attach_content_type_property(>base);

Re: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers

[kernel test robot]

Hi Mario,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip 
linus/master v6.8-rc4 next-20240216]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/drm-Stop-using-select-ACPI_VIDEO-in-all-drivers/20240215-055936
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240214215756.6530-2-mario.limonciello%40amd.com
patch subject: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers
config: alpha-kismet-CONFIG_FB_BACKLIGHT-CONFIG_FB_SH_MOBILE_LCDC-0-0 
(https://download.01.org/0day-ci/archive/20240217/202402170543.qd0jrj6h-...@intel.com/config)
reproduce: 
(https://download.01.org/0day-ci/archive/20240217/202402170543.qd0jrj6h-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202402170543.qd0jrj6h-...@intel.com/

kismet warnings: (new ones prefixed by >>)
>> kismet: WARNING: unmet direct dependencies detected for FB_BACKLIGHT when 
>> selected by FB_SH_MOBILE_LCDC
   .config:92:warning: symbol value 'n' invalid for AIC7XXX_DEBUG_MASK
   .config:218:warning: symbol value 'n' invalid for RAPIDIO_DISC_TIMEOUT
   .config:242:warning: symbol value 'n' invalid for SATA_MOBILE_LPM_POLICY
   .config:259:warning: symbol value 'n' invalid for FAT_DEFAULT_CODEPAGE
   .config:339:warning: symbol value 'n' invalid for PSTORE_BLK_MAX_REASON
   .config:341:warning: symbol value 'n' invalid for PANEL_PROFILE
   .config:352:warning: symbol value 'n' invalid for AIC79XX_DEBUG_MASK
   .config:432:warning: symbol value 'n' invalid for KFENCE_SAMPLE_INTERVAL
   .config:610:warning: symbol value 'n' invalid for DRM_XE_JOB_TIMEOUT_MIN
   .config:616:warning: symbol value 'n' invalid for CRYPTO_DEV_QCE_SW_MAX_LEN
   .config:717:warning: symbol value 'n' invalid for PANEL_LCD_CHARSET
   .config:755:warning: symbol value 'n' invalid for AIC79XX_CMDS_PER_DEVICE
   .config:784:warning: symbol value 'n' invalid for SND_AC97_POWER_SAVE_DEFAULT
   .config:805:warning: symbol value 'n' invalid for PANEL_LCD_PIN_SDA
   .config:807:warning: symbol value 'n' invalid for MAGIC_SYSRQ_DEFAULT_ENABLE
   .config:825:warning: symbol value 'n' invalid for 
DRM_I915_MAX_REQUEST_BUSYWAIT
   .config:864:warning: symbol value 'n' invalid for SND_AT73C213_TARGET_BITRATE
   .config:886:warning: symbol value 'n' invalid for DRM_XE_PREEMPT_TIMEOUT_MIN
   .config:894:warning: symbol value 'n' invalid for NET_EMATCH_STACK
   .config:896:warning: symbol value 'n' invalid for VMCP_CMA_SIZE
   .config:988:warning: symbol value 'n' invalid for INPUT_MOUSEDEV_SCREEN_Y
   .config:1124:warning: symbol value 'n' invalid for RCU_CPU_STALL_TIMEOUT
   .config:1150:warning: symbol value 'n' invalid for MTDRAM_ERASE_SIZE
   .config:1237:warning: symbol value 'n' invalid for SERIAL_UARTLITE_NR_UARTS
   .config:1303:warning: symbol value 'n' invalid for 
USB_GADGET_STORAGE_NUM_BUFFERS
   .config:1396:warning: symbol value 'n' invalid for LEGACY_PTY_COUNT
   .config:1533:warning: symbol value 'n' invalid for AIC7XXX_RESET_DELAY_MS
   .config:1723:warning: symbol value 'n' invalid for IBM_EMAC_POLL_WEIGHT
   .config:1759:warning: symbol value 'n' invalid for PANEL_LCD_PIN_E
   .config:1805:warning: symbol value 'n' invalid for DRM_I915_STOP_TIMEOUT
   .config:1981:warning: symbol value 'n' invalid for KCOV_IRQ_AREA_SIZE
   .config:2132:warning: symbol value 'n' invalid for RCU_FANOUT_LEAF
   .config:2232:warning: symbol value 'n' invalid for DRM_XE_TIMESLICE_MAX
   .config:2278:warning: symbol value 'n' invalid for PANEL_LCD_BWIDTH
   .config:2512:warning: symbol value 'n' invalid for PANEL_PARPORT
   .config:2520:warning: symbol value 'n' invalid for 
SND_SOC_SOF_DEBUG_IPC_FLOOD_TEST_NUM
   .config:2599:warning: symbol value 'n' invalid for NOUVEAU_DEBUG_DEFAULT
   .config:2785:warning: symbol value 'n' invalid for KCSAN_REPORT_ONCE_IN_MS
   .config:2883:warning: symbol value 'n' invalid for PSTORE_BLK_CONSOLE_SIZE
   .config:2884:warning: symbol value 'n' invalid for KCSAN_UDELAY_INTERRUPT
   .config:2894:warning: symbol value 'n' invalid for AIC79XX_RESET_DELAY_MS
   .config:2908:warning: symbol value 'n' invalid for PANEL_LCD_PIN_BL
   .config:2924:warning: symbol value 'n' invalid for 
DEBUG_OBJECTS_ENABLE_DEFAULT
   .config:2931:warning: symbol value 'n' invalid for INITRAMFS_ROOT_GID
   .config:3032:warning: symbol value 'n' invalid for ATM_FORE200E_TX_RETRY
   .config:3059:warning: symbol value 'n' invalid for BOOKE_WDT_DEFAULT_TIMEO

RE: [PATCH 3/4] drm/amdgpu: Use correct SRIOV macro for gmc_v9_0_vm_fault_interrupt_state

[Luo, Zhigang]

[AMD Official Use Only - General]

Reviewed By Zhigang Luo 

From: Lu, Victor Cheng Chi (Victor) 
Sent: Friday, February 16, 2024 1:50 PM
To: Luo, Zhigang 
Subject: Fw: [PATCH 3/4] drm/amdgpu: Use correct SRIOV macro for 
gmc_v9_0_vm_fault_interrupt_state


[AMD Official Use Only - General]



From: Lu, Victor Cheng Chi (Victor) 
mailto:victorchengchi...@amd.com>>
Sent: Tuesday, January 2, 2024 12:30 PM
To: amd-gfx@lists.freedesktop.org 
mailto:amd-gfx@lists.freedesktop.org>>
Cc: Chander, Vignesh mailto:vignesh.chan...@amd.com>>; 
Lu, Victor Cheng Chi (Victor) 
mailto:victorchengchi...@amd.com>>
Subject: [PATCH 3/4] drm/amdgpu: Use correct SRIOV macro for 
gmc_v9_0_vm_fault_interrupt_state

Under SRIOV, programming to VM_CONTEXT*_CNTL regs failed because the
current macro does not pass through the correct xcc instance.
Use the *REG32_XCC macro in this case.

The behaviour without SRIOV is the same.

Signed-off-by: Victor Lu 
mailto:victorchengchi...@amd.com>>
---
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 473a774294ce..e2e14d40109c 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
@@ -496,14 +496,14 @@ static int gmc_v9_0_vm_fault_interrupt_state(struct 
amdgpu_device *adev,
 if (j >= AMDGPU_MMHUB0(0))
 tmp = RREG32_SOC15_IP(MMHUB, reg);
 else
-   tmp = RREG32_SOC15_IP(GC, reg);
+   tmp = RREG32_XCC(reg, j);

 tmp &= ~bits;

 if (j >= AMDGPU_MMHUB0(0))
 WREG32_SOC15_IP(MMHUB, reg, tmp);
 else
-   WREG32_SOC15_IP(GC, reg, tmp);
+   WREG32_XCC(reg, tmp, j);
 }
 }
 break;
@@ -524,14 +524,14 @@ static int gmc_v9_0_vm_fault_interrupt_state(struct 
amdgpu_device *adev,
 if (j >= AMDGPU_MMHUB0(0))
 tmp = RREG32_SOC15_IP(MMHUB, reg);
 else
-   tmp = RREG32_SOC15_IP(GC, reg);
+   tmp = RREG32_XCC(reg, j);

 tmp |= bits;

 if (j >= AMDGPU_MMHUB0(0))
 WREG32_SOC15_IP(MMHUB, reg, tmp);
 else
-   WREG32_SOC15_IP(GC, reg, tmp);
+   WREG32_XCC(reg, tmp, j);
 }
 }
 break;
--
2.34.1

Re: [PATCH 1/2] drm/amdkfd: Document and define SVM event tracing macro

[Felix Kuehling]

On 2024-02-15 10:18, Philip Yang wrote:

Document how to use SMI system management interface to receive SVM
events.

Define SVM events message string format macro that could use by user
mode for sscanf to parse the event. Add it to uAPI header file to make
it obvious that is changing uAPI in future.

No functional changes.

Signed-off-by: Philip Yang 
---
  drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 51 +++---
  include/uapi/linux/kfd_ioctl.h  | 77 -
  2 files changed, 102 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
index d9953c2b2661..85465eb303a9 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
@@ -225,15 +225,16 @@ void kfd_smi_event_update_gpu_reset(struct kfd_node *dev, 
bool post_reset)
event = KFD_SMI_EVENT_GPU_PRE_RESET;
++(dev->reset_seq_num);
}
-   kfd_smi_event_add(0, dev, event, "%x\n", dev->reset_seq_num);
+   kfd_smi_event_add(0, dev, event,
+ KFD_EVENT_FMT_UPDATE_GPU_RESET(dev->reset_seq_num));
  }
  
  void kfd_smi_event_update_thermal_throttling(struct kfd_node *dev,

 uint64_t throttle_bitmask)
  {
-   kfd_smi_event_add(0, dev, KFD_SMI_EVENT_THERMAL_THROTTLE, "%llx:%llx\n",
- throttle_bitmask,
- amdgpu_dpm_get_thermal_throttling_counter(dev->adev));
+   kfd_smi_event_add(0, dev, KFD_SMI_EVENT_THERMAL_THROTTLE,
+ 
KFD_EVENT_FMT_UPDATE_THERMAL_THROTTLING(throttle_bitmask,
+ 
amdgpu_dpm_get_thermal_throttling_counter(dev->adev)));
  }
  
  void kfd_smi_event_update_vmfault(struct kfd_node *dev, uint16_t pasid)

@@ -246,8 +247,8 @@ void kfd_smi_event_update_vmfault(struct kfd_node *dev, 
uint16_t pasid)
if (!task_info.pid)
return;
  
-	kfd_smi_event_add(0, dev, KFD_SMI_EVENT_VMFAULT, "%x:%s\n",

- task_info.pid, task_info.task_name);
+   kfd_smi_event_add(0, dev, KFD_SMI_EVENT_VMFAULT,
+ KFD_EVENT_FMT_VMFAULT(task_info.pid, 
task_info.task_name));
  }
  
  void kfd_smi_event_page_fault_start(struct kfd_node *node, pid_t pid,

@@ -255,16 +256,16 @@ void kfd_smi_event_page_fault_start(struct kfd_node 
*node, pid_t pid,
ktime_t ts)
  {
kfd_smi_event_add(pid, node, KFD_SMI_EVENT_PAGE_FAULT_START,
- "%lld -%d @%lx(%x) %c\n", ktime_to_ns(ts), pid,
- address, node->id, write_fault ? 'W' : 'R');
+ KFD_EVENT_FMT_PAGEFAULT_START(ktime_to_ns(ts), pid,
+ address, node->id, write_fault ? 'W' : 'R'));
  }
  
  void kfd_smi_event_page_fault_end(struct kfd_node *node, pid_t pid,

  unsigned long address, bool migration)
  {
kfd_smi_event_add(pid, node, KFD_SMI_EVENT_PAGE_FAULT_END,
- "%lld -%d @%lx(%x) %c\n", ktime_get_boottime_ns(),
- pid, address, node->id, migration ? 'M' : 'U');
+ KFD_EVENT_FMT_PAGEFAULT_END(ktime_get_boottime_ns(),
+ pid, address, node->id, migration ? 'M' : 'U'));
  }
  
  void kfd_smi_event_migration_start(struct kfd_node *node, pid_t pid,

@@ -274,9 +275,9 @@ void kfd_smi_event_migration_start(struct kfd_node *node, 
pid_t pid,
   uint32_t trigger)
  {
kfd_smi_event_add(pid, node, KFD_SMI_EVENT_MIGRATE_START,
- "%lld -%d @%lx(%lx) %x->%x %x:%x %d\n",
- ktime_get_boottime_ns(), pid, start, end - start,
- from, to, prefetch_loc, preferred_loc, trigger);
+ KFD_EVENT_FMT_MIGRATE_START(ktime_get_boottime_ns(),
+ pid, start, end - start, from, to, prefetch_loc,
+ preferred_loc, trigger));
  }
  
  void kfd_smi_event_migration_end(struct kfd_node *node, pid_t pid,

@@ -284,24 +285,23 @@ void kfd_smi_event_migration_end(struct kfd_node *node, 
pid_t pid,
 uint32_t from, uint32_t to, uint32_t trigger)
  {
kfd_smi_event_add(pid, node, KFD_SMI_EVENT_MIGRATE_END,
- "%lld -%d @%lx(%lx) %x->%x %d\n",
- ktime_get_boottime_ns(), pid, start, end - start,
- from, to, trigger);
+ KFD_EVENT_FMT_MIGRATE_END(ktime_get_boottime_ns(), 
pid,
+ start, end - start, from, to, trigger));
  }
  
  void kfd_smi_event_queue_eviction(struct kfd_node *node, pid_t pid,

  uint32_t trigger)
  {
kfd_smi_event_add(pid, node, KFD_SMI_EVENT_QUEUE_EVICTION,
- "%lld -%d 

Re: [PATCH] drm/amd: Only allow one entity to control ABM

[Alex Deucher]

On Fri, Feb 16, 2024 at 10:42 AM Christian König
 wrote:
>
> Am 16.02.24 um 16:12 schrieb Mario Limonciello:
> > On 2/16/2024 09:05, Harry Wentland wrote:
> >>
> >>
> >> On 2024-02-16 09:47, Christian König wrote:
> >>> Am 16.02.24 um 15:42 schrieb Mario Limonciello:
>  On 2/16/2024 08:38, Christian König wrote:
> > Am 16.02.24 um 15:07 schrieb Mario Limonciello:
> >> By exporting ABM to sysfs it's possible that DRM master and software
> >> controlling the sysfs file fight over the value programmed for ABM.
> >>
> >> Adjust the module parameter behavior to control who control ABM:
> >> -2: DRM
> >> -1: sysfs (IE via software like power-profiles-daemon)
> >
> > Well that sounds extremely awkward. Why should a
> > power-profiles-deamon has control over the panel power saving
> > features?
> >
> > I mean we are talking about things like reducing backlight level
> > when the is inactivity, don't we?
> 
>  We're talking about activating the ABM algorithm when the system is
>  in power saving mode; not from inactivity.  This allows the user to
>  squeeze out some extra power "just" in that situation.
> 
>  But given the comments on the other patch, I tend to agree with
>  Harry's proposal instead that we just drop the DRM property
>  entirely as there are no consumers of it.
> >>>
> >>> Yeah, but even then the design to let this be controlled by an
> >>> userspace deamon is questionable. Stuff like that is handled inside
> >>> the kernel and not exposed to userspace usually.
> >>>
> >
> > Regarding the "how" and "why" of PPD; besides this panel power savings
> > sysfs file there are two other things that are nominally changed.
> >
> > ACPI platform profile:
> > https://www.kernel.org/doc/html/latest/userspace-api/sysfs-platform_profile.html
> >
> > AMD-Pstate EPP value:
> > https://www.kernel.org/doc/html//latest/admin-guide/pm/amd-pstate.html
> >
> > When a user goes into "power saving" mode both of those are tweaked.
> > Before we introduced the EPP tweaking in PPD we did discuss a callback
> > within the kernel so that userspace could change "just" the ACPI
> > platform profile and everything else would react.  There was pushback
> > on this, and so instead knobs are offered for things that should be
> > tweaked and the userspace daemon can set up policy for what to do when
> > a a user uses a userspace client (such as GNOME or KDE) to change the
> > desired system profile.
>
> Ok, well who came up with the idea of the userspace deamon? Cause I
> think there will be even more push back on this approach.
>
> Basically when we go from AC to battery (or whatever) the drivers
> usually handle that all inside the kernel today. Involving userspace is
> only done when there is a need for that, e.g. inactivity detection or
> similar.

Well, we don't want policy in the kernel unless it's a platform or
hardware requirement.  Kernel should provide the knobs and then
userspace can set them however they want depending on user preference.

Alex


>
> >>
> >> I think we'll need a bit in our kernel docs describing ABM.
> >> Assumptions around what it is and does seem to lead to confusion.
> >>
> >> The thing is that ABM has a visual impact that not all users like. It
> >> would make sense for users to be able to change the ABM level as
> >> desired, and/or configure their power profiles to select a certain
> >> ABM level.
> >>
> >> ABM will reduce the backlight and compensate by adjusting brightness
> >> and contrast of the image. It has 5 levels: 0, 1, 2, 3, 4. 0 means
> >> off. 4 means maximum backlight reduction. IMO, 1 and 2 look okay. 3
> >> and 4 can be quite impactful, both to power and visual fidelity.
> >>
> >
> > Aside from this patch Hamza did make some improvements to the kdoc in
> > the recent patches, can you read through again and see if you think it
> > still needs improvements?
>
> Well what exactly is the requirement? That we have different ABM
> settings for AC and battery? If yes providing different DRM properties
> would sound like the right approach to me.
>
> Regards,
> Christian.
>
> >
> >> Harry
> >>
> >>> Regards,
> >>> Christian.
> >>>
> 
> >
> > Regards,
> > Christian.
> >
> >> 0-4: User via command line
> >>
> >> Also introduce a Kconfig option that allows distributions to choose
> >> the default policy that is appropriate for them.
> >>
> >> Fixes: f97e4303da16 ("drm/amd/display: add panel_power_savings
> >> sysfs entry to eDP connectors")
> >> Signed-off-by: Mario Limonciello 
> >> ---
> >> Cc: Hamza Mahfooz 
> >> Cc: Harry Wentland 
> >> Cc: Sun peng (Leo) Li 
> >>drivers/gpu/drm/amd/amdgpu/Kconfig| 72
> >> +++
> >>drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 23 +++---
> >>.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  6 +-
> >>3 files changed, 90 insertions(+), 11 

Re: [PATCH v2] drm/amd/display: fix null-pointer dereference on edid reading

[Alex Deucher]

Applied.  Thanks!

Alex

On Fri, Feb 16, 2024 at 7:24 AM Melissa Wen  wrote:
>
> Use i2c adapter when there isn't aux_mode in dc_link to fix a
> null-pointer derefence that happens when running
> igt@kms_force_connector_basic in a system with DCN2.1 and HDMI connector
> detected as below:
>
> [  +0.178146] BUG: kernel NULL pointer dereference, address: 04c0
> [  +0.10] #PF: supervisor read access in kernel mode
> [  +0.05] #PF: error_code(0x) - not-present page
> [  +0.04] PGD 0 P4D 0
> [  +0.06] Oops:  [#1] PREEMPT SMP NOPTI
> [  +0.06] CPU: 15 PID: 2368 Comm: kms_force_conne Not tainted 6.5.0-asdn+ 
> #152
> [  +0.05] Hardware name: HP HP ENVY x360 Convertible 13-ay1xxx/8929, BIOS 
> F.01 07/14/2021
> [  +0.04] RIP: 0010:i2c_transfer+0xd/0x100
> [  +0.11] Code: ea fc ff ff 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 
> 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 55 53 <48> 8b 
> 47 10 48 89 fb 48 83 38 00 0f 84 b3 00 00 00 83 3d 2f 80 16
> [  +0.04] RSP: 0018:9c4f89c0fad0 EFLAGS: 00010246
> [  +0.05] RAX:  RBX: 0005 RCX: 
> 0080
> [  +0.03] RDX: 0002 RSI: 9c4f89c0fb20 RDI: 
> 04b0
> [  +0.03] RBP: 9c4f89c0fb80 R08: 0080 R09: 
> 8d8e0b15b980
> [  +0.03] R10: 000380e0 R11:  R12: 
> 0080
> [  +0.02] R13: 0002 R14: 9c4f89c0fb0e R15: 
> 9c4f89c0fb0f
> [  +0.04] FS:  7f9ad2176c40() GS:8d90fe9c() 
> knlGS:
> [  +0.03] CS:  0010 DS:  ES:  CR0: 80050033
> [  +0.04] CR2: 04c0 CR3: 000121bc4000 CR4: 
> 00750ee0
> [  +0.03] PKRU: 5554
> [  +0.03] Call Trace:
> [  +0.06]  
> [  +0.06]  ? __die+0x23/0x70
> [  +0.11]  ? page_fault_oops+0x17d/0x4c0
> [  +0.08]  ? preempt_count_add+0x6e/0xa0
> [  +0.08]  ? srso_alias_return_thunk+0x5/0x7f
> [  +0.11]  ? exc_page_fault+0x7f/0x180
> [  +0.09]  ? asm_exc_page_fault+0x26/0x30
> [  +0.13]  ? i2c_transfer+0xd/0x100
> [  +0.10]  drm_do_probe_ddc_edid+0xc2/0x140 [drm]
> [  +0.67]  ? srso_alias_return_thunk+0x5/0x7f
> [  +0.06]  ? _drm_do_get_edid+0x97/0x3c0 [drm]
> [  +0.43]  ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]
> [  +0.42]  edid_block_read+0x3b/0xd0 [drm]
> [  +0.43]  _drm_do_get_edid+0xb6/0x3c0 [drm]
> [  +0.41]  ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]
> [  +0.43]  drm_edid_read_custom+0x37/0xd0 [drm]
> [  +0.44]  amdgpu_dm_connector_mode_valid+0x129/0x1d0 [amdgpu]
> [  +0.000153]  drm_connector_mode_valid+0x3b/0x60 [drm_kms_helper]
> [  +0.00]  __drm_helper_update_and_validate+0xfe/0x3c0 [drm_kms_helper]
> [  +0.00]  ? amdgpu_dm_connector_get_modes+0xb6/0x520 [amdgpu]
> [  +0.00]  ? srso_alias_return_thunk+0x5/0x7f
> [  +0.00]  drm_helper_probe_single_connector_modes+0x2ab/0x540 
> [drm_kms_helper]
> [  +0.00]  status_store+0xb2/0x1f0 [drm]
> [  +0.00]  kernfs_fop_write_iter+0x136/0x1d0
> [  +0.00]  vfs_write+0x24d/0x440
> [  +0.00]  ksys_write+0x6f/0xf0
> [  +0.00]  do_syscall_64+0x60/0xc0
> [  +0.00]  ? srso_alias_return_thunk+0x5/0x7f
> [  +0.00]  ? syscall_exit_to_user_mode+0x2b/0x40
> [  +0.00]  ? srso_alias_return_thunk+0x5/0x7f
> [  +0.00]  ? do_syscall_64+0x6c/0xc0
> [  +0.00]  ? do_syscall_64+0x6c/0xc0
> [  +0.00]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
> [  +0.00] RIP: 0033:0x7f9ad46b4b00
> [  +0.00] Code: 40 00 48 8b 15 19 b3 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff 
> ff ff eb b7 0f 1f 00 80 3d e1 3a 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 
> 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89
> [  +0.00] RSP: 002b:7ffcbd3bd6d8 EFLAGS: 0202 ORIG_RAX: 
> 0001
> [  +0.00] RAX: ffda RBX:  RCX: 
> 7f9ad46b4b00
> [  +0.00] RDX: 0002 RSI: 7f9ad48a7417 RDI: 
> 0009
> [  +0.00] RBP: 0002 R08: 0064 R09: 
> 
> [  +0.00] R10:  R11: 0202 R12: 
> 7f9ad48a7417
> [  +0.00] R13: 0009 R14: 7ffcbd3bd760 R15: 
> 0001
> [  +0.00]  
> [  +0.00] Modules linked in: ctr ccm rfcomm snd_seq_dummy snd_hrtimer 
> snd_seq snd_seq_device cmac algif_hash algif_skcipher af_alg bnep btusb btrtl 
> btbcm btintel btmtk bluetooth uvcvideo videobuf2_vmalloc sha3_generic 
> videobuf2_memops uvc jitterentropy_rng videobuf2_v4l2 videodev drbg 
> videobuf2_common ansi_cprng mc ecdh_generic ecc qrtr binfmt_misc 
> hid_sensor_accel_3d hid_sensor_magn_3d hid_sensor_gyro_3d hid_sensor_trigger 
> industrialio_triggered_buffer kfifo_buf industrialio snd_ctl_led joydev 
> hid_sensor_iio_common rtw89_8852ae rtw89_8852a rtw89_pci 
> snd_hda_codec_realtek rtw89_core snd_hda_codec_generic intel_rapl_msr 
> 

Re: [PATCH v2 1/6] tracing, dma-buf: add a trace_dma_fence_sync_to event

[Daniel Vetter]

On Fri, Feb 16, 2024 at 05:51:59PM +0100, Christian König wrote:
> Am 16.02.24 um 17:32 schrieb Daniel Vetter:
> > On Tue, Feb 13, 2024 at 04:50:26PM +0100, Pierre-Eric Pelloux-Prayer wrote:
> > > This new event can be used to trace where a given dma_fence is added
> > > as a dependency of some other work.
> > How?
> > 
> > What I'd expected here is that you add a dependency chain from one fence
> > to another, but this only has one fence.
> 
> That's what I though initially as well, but at the point we add the
> dependency fences to the scheduler job we don't have the scheduler fence
> initialized yet.
> 
> We could change this so that we only trace all the fences after we have
> initialized the scheduler fence, but then we loose the information where the
> dependency comes from.

Hm right, I thought we'd dump the hashed pointe value into the fence
events too, then you could make the connection. But we don't, so this is a
bit annoying ...

And walking the entire scheduler dependency chain at trace_dma_fence_emit
time (or something similar) maybe?
-Sima

> > How do you figure out what's the
> > next dma_fence that will stall on this dependency?
> 
> I'm not fully sure on that either. Pierre?
> 
> Christian.
> 
> 
> >   Like in the gpu
> > scheduler we do know what will be the fence that userspace gets back, so
> > we can make that connection. And same for the atomic code (although you
> > don't wire that up at all).
> > 
> > I'm very confused on how this works and rather worried it's a brittle
> > amdgpu-only solution ...
> > -Sima
> > 
> > > I plan to use it in amdgpu.
> > > 
> > > Signed-off-by: Pierre-Eric Pelloux-Prayer 
> > > 
> > > ---
> > >   drivers/dma-buf/dma-fence.c  |  1 +
> > >   include/trace/events/dma_fence.h | 34 
> > >   2 files changed, 35 insertions(+)
> > > 
> > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > > index e0fd99e61a2d..671a499a5ccd 100644
> > > --- a/drivers/dma-buf/dma-fence.c
> > > +++ b/drivers/dma-buf/dma-fence.c
> > > @@ -23,6 +23,7 @@
> > >   EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
> > >   EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
> > >   EXPORT_TRACEPOINT_SYMBOL(dma_fence_signaled);
> > > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_sync_to);
> > >   static DEFINE_SPINLOCK(dma_fence_stub_lock);
> > >   static struct dma_fence dma_fence_stub;
> > > diff --git a/include/trace/events/dma_fence.h 
> > > b/include/trace/events/dma_fence.h
> > > index 3963e79ca7b4..9b3875f7aa79 100644
> > > --- a/include/trace/events/dma_fence.h
> > > +++ b/include/trace/events/dma_fence.h
> > > @@ -83,6 +83,40 @@ DEFINE_EVENT(dma_fence, dma_fence_wait_end,
> > >   TP_ARGS(fence)
> > >   );
> > > +DECLARE_EVENT_CLASS(dma_fence_from,
> > > +
> > > + TP_PROTO(struct dma_fence *fence, const char *reason),
> > > +
> > > + TP_ARGS(fence, reason),
> > > +
> > > + TP_STRUCT__entry(
> > > + __string(driver, fence->ops->get_driver_name(fence))
> > > + __string(timeline, fence->ops->get_timeline_name(fence))
> > > + __field(unsigned int, context)
> > > + __field(unsigned int, seqno)
> > > + __string(reason, reason)
> > > + ),
> > > +
> > > + TP_fast_assign(
> > > + __assign_str(driver, fence->ops->get_driver_name(fence));
> > > + __assign_str(timeline, fence->ops->get_timeline_name(fence));
> > > + __entry->context = fence->context;
> > > + __entry->seqno = fence->seqno;
> > > + __assign_str(reason, reason);
> > > + ),
> > > +
> > > + TP_printk("driver=%s timeline=%s context=%u seqno=%u reason=%s",
> > > +   __get_str(driver), __get_str(timeline), __entry->context,
> > > +   __entry->seqno, __get_str(reason))
> > > +);
> > > +
> > > +DEFINE_EVENT(dma_fence_from, dma_fence_sync_to,
> > > +
> > > + TP_PROTO(struct dma_fence *fence, const char *reason),
> > > +
> > > + TP_ARGS(fence, reason)
> > > +);
> > > +
> > >   #endif /*  _TRACE_DMA_FENCE_H */
> > >   /* This part must be outside protection */
> > > -- 
> > > 2.40.1
> > > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers

[kernel test robot]

Hi Mario,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip 
linus/master v6.8-rc4 next-20240216]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/drm-Stop-using-select-ACPI_VIDEO-in-all-drivers/20240215-055936
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240214215756.6530-2-mario.limonciello%40amd.com
patch subject: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers
config: alpha-kismet-CONFIG_FB_BACKLIGHT-CONFIG_FB_RIVA-0-0 
(https://download.01.org/0day-ci/archive/20240217/202402170047.mijmtqic-...@intel.com/config)
reproduce: 
(https://download.01.org/0day-ci/archive/20240217/202402170047.mijmtqic-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202402170047.mijmtqic-...@intel.com/

kismet warnings: (new ones prefixed by >>)
>> kismet: WARNING: unmet direct dependencies detected for FB_BACKLIGHT when 
>> selected by FB_RIVA
   .config:69:warning: symbol value 'n' invalid for FAT_DEFAULT_CODEPAGE
   .config:240:warning: symbol value 'n' invalid for SATA_MOBILE_LPM_POLICY
   .config:307:warning: symbol value 'n' invalid for XEN_MEMORY_HOTPLUG_LIMIT
   .config:328:warning: symbol value 'n' invalid for PSTORE_BLK_MAX_REASON
   .config:359:warning: symbol value 'n' invalid for AIC79XX_DEBUG_MASK
   .config:429:warning: symbol value 'n' invalid for KFENCE_SAMPLE_INTERVAL
   .config:612:warning: symbol value 'n' invalid for CRYPTO_DEV_QCE_SW_MAX_LEN
   .config:613:warning: symbol value 'n' invalid for DRM_XE_JOB_TIMEOUT_MIN
   .config:702:warning: symbol value 'n' invalid for VGA_ARB_MAX_GPUS
   .config:715:warning: symbol value 'n' invalid for PANEL_LCD_CHARSET
   .config:789:warning: symbol value 'n' invalid for SND_AC97_POWER_SAVE_DEFAULT
   .config:793:warning: symbol value 'n' invalid for INPUT_MOUSEDEV_SCREEN_Y
   .config:811:warning: symbol value 'n' invalid for AIC79XX_CMDS_PER_DEVICE
   .config:830:warning: symbol value 'n' invalid for 
DRM_I915_MAX_REQUEST_BUSYWAIT
   .config:855:warning: symbol value 'n' invalid for SND_AT73C213_TARGET_BITRATE
   .config:877:warning: symbol value 'n' invalid for PANEL_LCD_PIN_SDA
   .config:893:warning: symbol value 'n' invalid for DRM_XE_PREEMPT_TIMEOUT_MIN
   .config:901:warning: symbol value 'n' invalid for NET_EMATCH_STACK
   .config:903:warning: symbol value 'n' invalid for VMCP_CMA_SIZE
   .config:1095:warning: symbol value 'n' invalid for 
USB_GADGET_STORAGE_NUM_BUFFERS
   .config:1130:warning: symbol value 'n' invalid for RCU_CPU_STALL_TIMEOUT
   .config:1159:warning: symbol value 'n' invalid for MTDRAM_ERASE_SIZE
   .config:1238:warning: symbol value 'n' invalid for SERIAL_UARTLITE_NR_UARTS
   .config:1397:warning: symbol value 'n' invalid for LEGACY_PTY_COUNT
   .config:1524:warning: symbol value 'n' invalid for PANEL_LCD_PIN_E
   .config:1528:warning: symbol value 'n' invalid for AIC7XXX_RESET_DELAY_MS
   .config:1726:warning: symbol value 'n' invalid for IBM_EMAC_POLL_WEIGHT
   .config:1763:warning: symbol value 'n' invalid for SCSI_MESH_RESET_DELAY_MS
   .config:1817:warning: symbol value 'n' invalid for DRM_I915_STOP_TIMEOUT
   .config:2048:warning: symbol value 'n' invalid for KCOV_IRQ_AREA_SIZE
   .config:2143:warning: symbol value 'n' invalid for RCU_FANOUT_LEAF
   .config:2237:warning: symbol value 'n' invalid for DRM_XE_TIMESLICE_MAX
   .config:2290:warning: symbol value 'n' invalid for PANEL_LCD_BWIDTH
   .config:2523:warning: symbol value 'n' invalid for PANEL_PARPORT
   .config:2568:warning: symbol value 'n' invalid for 
SND_SOC_SOF_DEBUG_IPC_FLOOD_TEST_NUM
   .config:2606:warning: symbol value 'n' invalid for NOUVEAU_DEBUG_DEFAULT
   .config:2707:warning: symbol value 'n' invalid for AIC79XX_RESET_DELAY_MS
   .config:2779:warning: symbol value 'n' invalid for 
SERIAL_ALTERA_UART_BAUDRATE
   .config:2791:warning: symbol value 'n' invalid for KCSAN_REPORT_ONCE_IN_MS
   .config:2888:warning: symbol value 'n' invalid for KCSAN_UDELAY_INTERRUPT
   .config:2910:warning: symbol value 'n' invalid for PANEL_LCD_PIN_BL
   .config:2934:warning: symbol value 'n' invalid for INITRAMFS_ROOT_GID
   .config:2968:warning: symbol value 'n' invalid for DUMMY_CONSOLE_ROWS
   .config:3008:warning: symbol value 'n' invalid for PSTORE_BLK_CONSOLE_SIZE
   .config:3038:warning: symbol value 'n' invalid for ATM_FORE200E_TX_RETRY
   .config:3078:warning: symbol value 'n' invalid for 
FB_OMAP2_DSS_MIN_FCK_PER_PCK
   .c

Re: [PATCH 1/3] drm/radeon: Use RMW accessors for changing LNKCTL2

[Alex Deucher]

Applied.  Thanks.

Alex

On Fri, Feb 16, 2024 at 5:38 AM Ilpo Järvinen
 wrote:
>
> On Thu, 15 Feb 2024, Deucher, Alexander wrote:
>
> > [Public]
> >
> > > -Original Message-
> > > From: Ilpo Järvinen 
> > > Sent: Thursday, February 15, 2024 8:32 AM
> > > To: Deucher, Alexander ; amd-
> > > g...@lists.freedesktop.org; Daniel Vetter ; David Airlie
> > > ; Dennis Dalessandro
> > > ; dri-
> > > de...@lists.freedesktop.org; Jason Gunthorpe ; Leon
> > > Romanovsky ; linux-ker...@vger.kernel.org; linux-
> > > r...@vger.kernel.org; Pan, Xinhui ; Koenig, Christian
> > > 
> > > Cc: Ilpo Järvinen ; Lukas Wunner
> > > 
> > > Subject: [PATCH 1/3] drm/radeon: Use RMW accessors for changing LNKCTL2
> > >
> > > Convert open coded RMW accesses for LNKCTL2 to use
> > > pcie_capability_clear_and_set_word() which makes its easier to understand
> > > what the code tries to do.
> > >
> > > LNKCTL2 is not really owned by any driver because it is a collection of 
> > > control
> > > bits that PCI core might need to touch. RMW accessors already have support
> > > for proper locking for a selected set of registers
> > > (LNKCTL2 is not yet among them but likely will be in the future) to avoid 
> > > losing
> > > concurrent updates.
> > >
> > > Suggested-by: Lukas Wunner 
> > > Signed-off-by: Ilpo Järvinen 
> >
> > The radeon and amdgpu patches are:
> > Acked-by: Alex Deucher 
> >
> > Are you looking for me to pick them up or do you want to land them as
> > part of some larger change?  Either way is fine with me.
>
> Hi,
>
> You please take them, I intentionally took them apart from the BW
> controller series so they can go through the usual trees, not along with
> the BW controller. (I don't expect the BW controller to be accepted during
> this cycle).
>
> --
>  i.

Re: [PATCH v2 1/6] tracing, dma-buf: add a trace_dma_fence_sync_to event

[Christian König]

Am 16.02.24 um 17:32 schrieb Daniel Vetter:

On Tue, Feb 13, 2024 at 04:50:26PM +0100, Pierre-Eric Pelloux-Prayer wrote:

This new event can be used to trace where a given dma_fence is added
as a dependency of some other work.

How?

What I'd expected here is that you add a dependency chain from one fence
to another, but this only has one fence.


That's what I though initially as well, but at the point we add the 
dependency fences to the scheduler job we don't have the scheduler fence 
initialized yet.


We could change this so that we only trace all the fences after we have 
initialized the scheduler fence, but then we loose the information where 
the dependency comes from.



How do you figure out what's the
next dma_fence that will stall on this dependency?


I'm not fully sure on that either. Pierre?

Christian.



  Like in the gpu
scheduler we do know what will be the fence that userspace gets back, so
we can make that connection. And same for the atomic code (although you
don't wire that up at all).

I'm very confused on how this works and rather worried it's a brittle
amdgpu-only solution ...
-Sima


I plan to use it in amdgpu.

Signed-off-by: Pierre-Eric Pelloux-Prayer 
---
  drivers/dma-buf/dma-fence.c  |  1 +
  include/trace/events/dma_fence.h | 34 
  2 files changed, 35 insertions(+)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index e0fd99e61a2d..671a499a5ccd 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -23,6 +23,7 @@
  EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
  EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
  EXPORT_TRACEPOINT_SYMBOL(dma_fence_signaled);
+EXPORT_TRACEPOINT_SYMBOL(dma_fence_sync_to);
  
  static DEFINE_SPINLOCK(dma_fence_stub_lock);

  static struct dma_fence dma_fence_stub;
diff --git a/include/trace/events/dma_fence.h b/include/trace/events/dma_fence.h
index 3963e79ca7b4..9b3875f7aa79 100644
--- a/include/trace/events/dma_fence.h
+++ b/include/trace/events/dma_fence.h
@@ -83,6 +83,40 @@ DEFINE_EVENT(dma_fence, dma_fence_wait_end,
TP_ARGS(fence)
  );
  
+DECLARE_EVENT_CLASS(dma_fence_from,

+
+   TP_PROTO(struct dma_fence *fence, const char *reason),
+
+   TP_ARGS(fence, reason),
+
+   TP_STRUCT__entry(
+   __string(driver, fence->ops->get_driver_name(fence))
+   __string(timeline, fence->ops->get_timeline_name(fence))
+   __field(unsigned int, context)
+   __field(unsigned int, seqno)
+   __string(reason, reason)
+   ),
+
+   TP_fast_assign(
+   __assign_str(driver, fence->ops->get_driver_name(fence));
+   __assign_str(timeline, fence->ops->get_timeline_name(fence));
+   __entry->context = fence->context;
+   __entry->seqno = fence->seqno;
+   __assign_str(reason, reason);
+   ),
+
+   TP_printk("driver=%s timeline=%s context=%u seqno=%u reason=%s",
+ __get_str(driver), __get_str(timeline), __entry->context,
+ __entry->seqno, __get_str(reason))
+);
+
+DEFINE_EVENT(dma_fence_from, dma_fence_sync_to,
+
+   TP_PROTO(struct dma_fence *fence, const char *reason),
+
+   TP_ARGS(fence, reason)
+);
+
  #endif /*  _TRACE_DMA_FENCE_H */
  
  /* This part must be outside protection */

--
2.40.1

Re: [PATCH v4 1/3] drm: Add drm_get_acpi_edid() helper

[Daniel Vetter]

On Mon, Feb 12, 2024 at 01:27:57PM +0200, Jani Nikula wrote:
> On Sat, 10 Feb 2024, Mario Limonciello  wrote:
> > On 2/9/2024 12:57, Daniel Vetter wrote:
> >> On Fri, Feb 09, 2024 at 09:34:13AM -0600, Mario Limonciello wrote:
> >>> On 2/9/2024 05:07, Daniel Vetter wrote:
>  On Thu, Feb 08, 2024 at 11:57:11AM +0200, Jani Nikula wrote:
> > On Wed, 07 Feb 2024, Mario Limonciello  
> > wrote:
> >> Some manufacturers have intentionally put an EDID that differs from
> >> the EDID on the internal panel on laptops.  Drivers can call this
> >> helper to attempt to fetch the EDID from the BIOS's ACPI _DDC method.
> >>
> >> Signed-off-by: Mario Limonciello 
> >> ---
> >>drivers/gpu/drm/Kconfig|  5 +++
> >>drivers/gpu/drm/drm_edid.c | 77 
> >> ++
> >>include/drm/drm_edid.h |  1 +
> >>3 files changed, 83 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> >> index 6ec33d36f3a4..ec2bb71e8b36 100644
> >> --- a/drivers/gpu/drm/Kconfig
> >> +++ b/drivers/gpu/drm/Kconfig
> >> @@ -21,6 +21,11 @@ menuconfig DRM
> >>select KCMP
> >>select VIDEO_CMDLINE
> >>select VIDEO_NOMODESET
> >> +  select ACPI_VIDEO if ACPI
> >> +  select BACKLIGHT_CLASS_DEVICE if ACPI
> >> +  select INPUT if ACPI
> >> +  select X86_PLATFORM_DEVICES if ACPI && X86
> >> +  select ACPI_WMI if ACPI && X86
> >
> > I think I'll defer to drm maintainers on whether this is okay or
> > something to be avoided.
> 
>  Uh yeah this is a bit much, and select just messes with everything. Just
>  #ifdef this in the code with a dummy alternative, if users configure 
>  their
>  kernel without acpi but need it, they get to keep all the pieces.
> 
>  Alternatively make a DRM_ACPI_HELPERS symbol, but imo a Kconfig for every
>  function is also not great. And just using #ifdef in the code also works
>  for CONFIG_OF, which is exactly the same thing for platforms using dt to
>  describe hw.
> 
>  Also I'd expect ACPI code to already provide dummy functions if ACPI is
>  provided, so you probably dont even need all that much #ifdef in the 
>  code.
> 
>  What we defo cant do is select platform/hw stuff just because you enable
>  CONFIG_DRM.
>  -Sima
> >>>
> >>> The problem was with linking.  I'll experiment with #ifdef for the next
> >>> version.
> >> 
> >> Ah yes, if e.g. acpi is a module but drm is built-in then it will compile,
> >> but not link.
> >> 
> >> You need
> >> 
> >>depends on (ACPI || ACPI=n)
> >> 
> >> for this. Looks a bit funny but works for all combinations.
> >
> > Nope; this fails at link time with this combination:
> >
> > CONFIG_ACPI=y
> > CONFIG_ACPI_VIDEO=m
> > CONFIG_DRM=y
> >
> > ld: drivers/gpu/drm/drm_edid.o: in function `drm_do_probe_acpi_edid':
> > drm_edid.c:(.text+0xd34): undefined reference to `acpi_video_get_edid'
> > make[5]: *** [scripts/Makefile.vmlinux:37: vmlinux] Error 1
> >
> > So the logical solution is to try
> > depends on (ACPI_VIDEO || ACPI_VIDEO=n)
> >
> > But that leads me back to the rabbit hole of why I had the selects moved 
> > to drm instead of drivers in the first place:
> >
> > drivers/gpu/drm/Kconfig:8:error: recursive dependency detected!
> > drivers/gpu/drm/Kconfig:8:  symbol DRM depends on ACPI_VIDEO
> > drivers/acpi/Kconfig:213:   symbol ACPI_VIDEO depends on 
> > BACKLIGHT_CLASS_DEVICE
> > drivers/video/backlight/Kconfig:136:symbol BACKLIGHT_CLASS_DEVICE is 
> > selected by DRM_RADEON
> > drivers/gpu/drm/radeon/Kconfig:3:   symbol DRM_RADEON depends on DRM
> 
> Generally speaking the root cause is using "select" instead of "depends
> on" in the first place. The excessive selects are just band-aid over
> that root cause. And if you try to convert some but not all the selects
> to depends ons, you'll get recursive dependencies.
> 
> Quoting Documentation/kbuild/kconfig-language.rst:
> 
>   Note:
>   select should be used with care. select will force
>   a symbol to a value without visiting the dependencies.
>   By abusing select you are able to select a symbol FOO even
>   if FOO depends on BAR that is not set.
>   In general use select only for non-visible symbols
>   (no prompts anywhere) and for symbols with no dependencies.
>   That will limit the usefulness but on the other hand avoid
>   the illegal configurations all over.
> 
> Yeah, we ignore that, and get to keep all the pieces.

Yeah we need radically fewer select and replace them with depends. The
idea is that people just magically get the correct kernel config because
even menuconfig sucks at showing you why you cannot enable a driver.

But it's really not a good solution to that issue, and we need to stop
suffering. Reality is that enabling a correct config for complex 

Re: [PATCH v2 6/6] drm: add drm_mode_atomic_commit event

[Steven Rostedt]

On Fri, 16 Feb 2024 17:37:23 +0100
Daniel Vetter  wrote:

> > > @@ -1503,6 +1504,24 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > >   drm_mode_object_put(obj);
> > >   }
> > >  
> > > + if (trace_drm_mode_atomic_commit_enabled()) {
> > > + struct drm_crtc_state *crtc_state;
> > > + struct drm_crtc *crtc;
> > > + int *crtcs;
> > > + int i, num_crtcs;
> > > +
> > > + crtcs = kcalloc(dev->mode_config.num_crtc, sizeof(int),
> > > + GFP_KERNEL);  
> > 
> > If the above allocation fails, this will cause a NULL kernel dereference.  
> 
> Yeah can't we somehow iterate directly into the trace subsystem? If
> nothing else works I guess just a per-crtc event should do.

You mean like this?

  https://lore.kernel.org/all/20240216105934.7b81e...@gandalf.local.home/

;-)

-- Steve

Re: [PATCH] drm/amd/display: Fix memory leak in dm_sw_fini()

[Alex Deucher]

Applied.  Thanks!

On Mon, Feb 12, 2024 at 8:08 PM Armin Wolf  wrote:
>
> After destroying dmub_srv, the memory associated with it is
> not freed, causing a memory leak:
>
> unreferenced object 0x896302b45800 (size 1024):
>   comm "(udev-worker)", pid 222, jiffies 4294894636
>   hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>   backtrace (crc 6265fd77):
> [] kmalloc_trace+0x29d/0x340
> [] dm_dmub_sw_init+0xb4/0x450 [amdgpu]
> [] dm_sw_init+0x15/0x2b0 [amdgpu]
> [] amdgpu_device_init+0x1417/0x24e0 [amdgpu]
> [] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]
> [] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]
> [] local_pci_probe+0x3e/0x90
> [] pci_device_probe+0xc3/0x230
> [] really_probe+0xe2/0x480
> [] __driver_probe_device+0x78/0x160
> [] driver_probe_device+0x1f/0x90
> [] __driver_attach+0xce/0x1c0
> [] bus_for_each_dev+0x70/0xc0
> [] bus_add_driver+0x112/0x210
> [] driver_register+0x55/0x100
> [] do_one_initcall+0x41/0x300
>
> Fix this by freeing dmub_srv after destroying it.
>
> Fixes: 743b9786b14a ("drm/amd/display: Hook up the DMUB service in DM")
> Signed-off-by: Armin Wolf 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 59d2eee72a32..9cbfc8d39dee 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2287,6 +2287,7 @@ static int dm_sw_fini(void *handle)
>
> if (adev->dm.dmub_srv) {
> dmub_srv_destroy(adev->dm.dmub_srv);
> +   kfree(adev->dm.dmub_srv);
> adev->dm.dmub_srv = NULL;
> }
>
> --
> 2.39.2
>

Re: [PATCH v2 6/6] drm: add drm_mode_atomic_commit event

[Daniel Vetter]

On Tue, Feb 13, 2024 at 11:20:17AM -0500, Steven Rostedt wrote:
> On Tue, 13 Feb 2024 16:50:31 +0100
> Pierre-Eric Pelloux-Prayer  wrote:
> 
> > @@ -1503,6 +1504,24 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> > drm_mode_object_put(obj);
> > }
> >  
> > +   if (trace_drm_mode_atomic_commit_enabled()) {
> > +   struct drm_crtc_state *crtc_state;
> > +   struct drm_crtc *crtc;
> > +   int *crtcs;
> > +   int i, num_crtcs;
> > +
> > +   crtcs = kcalloc(dev->mode_config.num_crtc, sizeof(int),
> > +   GFP_KERNEL);
> 
> If the above allocation fails, this will cause a NULL kernel dereference.

Yeah can't we somehow iterate directly into the trace subsystem? If
nothing else works I guess just a per-crtc event should do.

The more fundamental issue: I don't get how this works. For atomic we
have:
- explicitly handed in in-fences as dependencies with the IN_FENCE
  property
- dependencies that drivers fish out of the dma_resv object of the
  underlying gem buffer objects for each framebuffer. That has become
  pretty much entirely generic code since everyone uses the same, and so
  imo the dependency tracking should be fully generic too

- atomic has an out-fence too, so we could even do the full fence->fence
  dependency tracking. It's just not created as a userspace object if all
  userspace asks for is a drm vblank event, but it is very much there. And
  I think if you want fence tracking, we really should have fence tracking
  :-) Also the out-fence should be 100% generic (or it's a driver bug)
  because the driver functions hide the differences between generating a
  vblank event and signalling a dma_fence.

Cheers, Sima


> 
> -- Steve
> 
> > +
> > +   num_crtcs = 0;
> > +   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > +   crtcs[num_crtcs++] = drm_crtc_index(crtc);
> > +
> > +   trace_drm_mode_atomic_commit(file_priv, crtcs, num_crtcs, 
> > arg->flags);
> > +
> > +   kfree(crtcs);
> > +   }
> > +
> > ret = prepare_signaling(dev, state, arg, file_priv, _state,
> > _fences);
> > if (ret)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 1/6] tracing, dma-buf: add a trace_dma_fence_sync_to event

[Daniel Vetter]

On Tue, Feb 13, 2024 at 04:50:26PM +0100, Pierre-Eric Pelloux-Prayer wrote:
> This new event can be used to trace where a given dma_fence is added
> as a dependency of some other work.

How?

What I'd expected here is that you add a dependency chain from one fence
to another, but this only has one fence. How do you figure out what's the
next dma_fence that will stall on this dependency? Like in the gpu
scheduler we do know what will be the fence that userspace gets back, so
we can make that connection. And same for the atomic code (although you
don't wire that up at all).

I'm very confused on how this works and rather worried it's a brittle
amdgpu-only solution ...
-Sima

> I plan to use it in amdgpu.
> 
> Signed-off-by: Pierre-Eric Pelloux-Prayer 
> ---
>  drivers/dma-buf/dma-fence.c  |  1 +
>  include/trace/events/dma_fence.h | 34 
>  2 files changed, 35 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index e0fd99e61a2d..671a499a5ccd 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -23,6 +23,7 @@
>  EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
>  EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
>  EXPORT_TRACEPOINT_SYMBOL(dma_fence_signaled);
> +EXPORT_TRACEPOINT_SYMBOL(dma_fence_sync_to);
>  
>  static DEFINE_SPINLOCK(dma_fence_stub_lock);
>  static struct dma_fence dma_fence_stub;
> diff --git a/include/trace/events/dma_fence.h 
> b/include/trace/events/dma_fence.h
> index 3963e79ca7b4..9b3875f7aa79 100644
> --- a/include/trace/events/dma_fence.h
> +++ b/include/trace/events/dma_fence.h
> @@ -83,6 +83,40 @@ DEFINE_EVENT(dma_fence, dma_fence_wait_end,
>   TP_ARGS(fence)
>  );
>  
> +DECLARE_EVENT_CLASS(dma_fence_from,
> +
> + TP_PROTO(struct dma_fence *fence, const char *reason),
> +
> + TP_ARGS(fence, reason),
> +
> + TP_STRUCT__entry(
> + __string(driver, fence->ops->get_driver_name(fence))
> + __string(timeline, fence->ops->get_timeline_name(fence))
> + __field(unsigned int, context)
> + __field(unsigned int, seqno)
> + __string(reason, reason)
> + ),
> +
> + TP_fast_assign(
> + __assign_str(driver, fence->ops->get_driver_name(fence));
> + __assign_str(timeline, fence->ops->get_timeline_name(fence));
> + __entry->context = fence->context;
> + __entry->seqno = fence->seqno;
> + __assign_str(reason, reason);
> + ),
> +
> + TP_printk("driver=%s timeline=%s context=%u seqno=%u reason=%s",
> +   __get_str(driver), __get_str(timeline), __entry->context,
> +   __entry->seqno, __get_str(reason))
> +);
> +
> +DEFINE_EVENT(dma_fence_from, dma_fence_sync_to,
> +
> + TP_PROTO(struct dma_fence *fence, const char *reason),
> +
> + TP_ARGS(fence, reason)
> +);
> +
>  #endif /*  _TRACE_DMA_FENCE_H */
>  
>  /* This part must be outside protection */
> -- 
> 2.40.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors

[Mario Limonciello]

On 2/16/2024 10:13, Harry Wentland wrote:



On 2024-02-16 11:11, Harry Wentland wrote:



On 2024-02-16 10:42, Pekka Paalanen wrote:

On Fri, 16 Feb 2024 09:33:47 -0500
Harry Wentland  wrote:


On 2024-02-16 03:19, Pekka Paalanen wrote:

On Fri, 2 Feb 2024 10:28:35 -0500
Hamza Mahfooz  wrote:
   

We want programs besides the compositor to be able to enable or disable
panel power saving features.


Could you also explain why, in the commit message, please?

It is unexpected for arbitrary programs to be able to override the KMS
client, and certainly new ways to do so should not be added without an
excellent justification.

Maybe debugfs would be more appropriate if the purpose is only testing
rather than production environments?
   

However, since they are currently only
configurable through DRM properties, that isn't possible. So, to remedy
that issue introduce a new "panel_power_savings" sysfs attribute.


When the DRM property was added, what was used as the userspace to
prove its workings?
   


I don't think there ever was a userspace implementation and doubt any
exists today. Part of that is on me. In hindsight, the KMS prop should
have never gone upstream.

I suggest we drop the KMS prop entirely.


Sounds good. What about the sysfs thing? Should it be a debugfs thing
instead, assuming the below question will be resolved?




It's intended to be used by the power profiles daemon (PPD). I don't think
debugfs is the right choice. See
https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/commit/41ed5d33a82b0ceb7b6d473551eb2aa62cade6bc


As for the color accuracy topic, I think it is important that compositors
can have full control over that if needed, while it's also important
for HW vendors to optimize for power when absolute color accuracy is not
needed. An average end-user writing code or working on their slides
would rather have a longer battery life than a perfectly color-accurate
display. We should probably think of a solution that can support both
use-cases.


I agree. Maybe this pondering should start from "how would it work from
end user perspective"?

"Automatically" is probably be most desirable answer. Some kind of


I agree


desktop settings with options like "save power at the expense of image
quality":
- always
- not if watching movies/gaming
- on battery
- on battery, unless I'm watching movies/gaming
- never



It's interesting that you split out movies/gaming, specifically. AMD's
ABM algorithm seems to have considered movies in particular when
evaluating the power/fidelity trade-off.

I wouldn't think consumer media is very particular about a specific
color fidelity (despite what HDR specs try to make you believe). Where
color fidelity would matter to me is when I'd want to edit pictures or
video.

The "abm_level" property that we expose is really just that, a setting
for the strength of the power-savings effect, with 0 being off and 4 being
maximum strength and power saving, at the expense of fidelity.

Mario's work is to let the PPD control it and set the ABM levels based on
the selected power profile:
0 - Performance
1 - Balance
3 - Power

And I believe we've looked at disabling ABM (setting it to 0) automatically
if we know we're on AC power.


Or maybe there already is something like that, and it only needs to be
plumbed through?

Which would point towards KMS clients needing to control it, which
means a generic KMS prop rather than vendor specific?

Or should the desktop compositor be talking to some daemon instead of
KMS for this? Maybe they already are?



I think the intention is for the PPD to be that daemon. Mario can elaborate.



Some more details and screenshots on how the PPD is expected to work and look:
https://linuxconfig.org/how-to-manage-power-profiles-over-d-bus-with-power-profiles-daemon-on-linux


Right, thanks!

The most important point is that the user indicates intent from the GUI.
The daemon orchestrates the various knobs to get that intent.

It's intentionally very coarse - 3 power states.  The policy of what to 
do for those states is managed by the daemon.


In the case of ABM it will only apply the policy if the daemon detects 
the system is on battery.

Re: [PATCH v2 0/6] dma-fence, drm, amdgpu new trace events

[Daniel Vetter]

On Tue, Feb 13, 2024 at 04:50:25PM +0100, Pierre-Eric Pelloux-Prayer wrote:
> This series adds new events to make it easier for tools
> like gpuvis or umr to graph the GPUs, kernel and applications
> activity.
> 
> UMR patches using these events can be found here:
> https://gitlab.freedesktop.org/tomstdenis/umr/-/merge_requests/37
> 
> V1:
> https://patchwork.kernel.org/project/linux-media/patch/20240117184329.479554-1-pierre-eric.pelloux-pra...@amd.com/
> 
> Changes from V1:
> * uses trace_dma_fence_sync_to from dma-fence-chain.c
> * new amdgpu events
> * new drm plane commit event

I think a patch to add this to the drm/sched dependency tracking would be
really neat. With the addition of drm_sched_job_add_dependency() and
friends that would wire up some basic dependency tracking for a _lot_ of
drivers.

It should also be done before the amdgpu specific additions, because
amdgpu is also using that and we don't want to duplicate fence dependency
tracking in drivers that should be in common code.

Cheer, Sima
> 
> Pierre-Eric Pelloux-Prayer (6):
>   tracing, dma-buf: add a trace_dma_fence_sync_to event
>   dma-buf/fence-chain: use trace_dma_fence_sync_to
>   amdgpu: use trace_dma_fence_sync_to in amdgpu_fence_sync
>   drm/amdgpu: add BO clear event
>   drm/amdgpu: add a amdgpu_cs_ioctl2 event
>   drm: add drm_mode_atomic_commit event
> 
>  drivers/dma-buf/dma-fence-chain.c |  4 +++
>  drivers/dma-buf/dma-fence.c   |  1 +
>  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  |  8 ++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 16 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c   |  8 ++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c   |  4 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c|  2 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c  | 11 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h  |  3 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 28 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_umsch_mm.c  |  4 +--
>  drivers/gpu/drm/drm_atomic_uapi.c | 19 +++
>  drivers/gpu/drm/drm_trace.h   | 28 +--
>  include/trace/events/dma_fence.h  | 34 +++
>  14 files changed, 144 insertions(+), 26 deletions(-)
> 
> -- 
> 2.40.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v3 6/8] drm: add drm_mode_atomic_commit event

[Ville Syrjälä]

On Fri, Feb 16, 2024 at 04:09:55PM +0100, Pierre-Eric Pelloux-Prayer wrote:
> With this and the dma_fence_used_as_dependency event, a tool can draw the
> relationship between the compositing draw, the atomic commit, and vblank.
> 
> An example on a 2 monitors system look like this:
> 
> gnome-shell-1638[018] .  2571.905124: drm_mode_atomic_commit: 
> file=245c3f0c, pid=1165, flags=0201, crtcs={0x1}
> gnome-shell-1638[018] .  2571.905147: dma_fence_used_as_dependency: 
> driver=drm_sched timeline=gfx_0.0.0 context=270 seqno=73240 
> reason=dma_fence_chain_init
> gnome-shell-1638[018] .  2571.913226: drm_mode_atomic_commit: 
> file=245c3f0c, pid=1165, flags=0201, crtcs={0x0}
> gnome-shell-1638[018] .  2571.913250: dma_fence_used_as_dependency: 
> driver=drm_sched timeline=gfx_0.0.0 context=270 seqno=73241 
> reason=dma_fence_chain_init
> -0   [018] d.h3.  2571.915687: drm_vblank_event: crtc=1, 
> seq=155747, time=2571916093743, high-prec=true
> -0   [018] d.h3.  2571.915968: drm_vblank_event: crtc=0, 
> seq=153862, time=2571916377180, high-prec=true
> 
> v2: fix unchecked memory allocation
> 
> Signed-off-by: Pierre-Eric Pelloux-Prayer 
> ---
>  drivers/gpu/drm/drm_atomic_uapi.c | 21 +
>  drivers/gpu/drm/drm_trace.h   | 23 +++
>  2 files changed, 44 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 29d4940188d4..f31b5c6f870b 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -41,6 +41,7 @@
>  #include 
>  
>  #include "drm_crtc_internal.h"
> +#include "drm_trace.h"
>  
>  /**
>   * DOC: overview
> @@ -1503,6 +1504,26 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   drm_mode_object_put(obj);
>   }
>  
> + if (trace_drm_mode_atomic_commit_enabled()) {
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + int *crtcs;
> + int i, num_crtcs;
> +
> + crtcs = kcalloc(dev->mode_config.num_crtc, sizeof(int),
> + GFP_KERNEL);
> +
> + if (crtcs) {
> + num_crtcs = 0;
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> + crtcs[num_crtcs++] = drm_crtc_index(crtc);
> +
> + trace_drm_mode_atomic_commit(file_priv, crtcs, 
> num_crtcs, arg->flags);
> +
> + kfree(crtcs);
> + }
> + }

I think the current drm trace events are sort of semi-useless.
The problems are:
- no device id in the events so good luck with multi gpu systems
- vblank trace events are only emitted from some vblank
  codepaths but not others

I'm also not sure putting an event straight into the atomic ioctl is
particularly useful.

First of all it means that any commit not initiated by the atomic
ioctl will not be traced.

It would also seem more useful to me if the driver can emit the
trace just before it commits the frame to the hardware, so that
we can also observe the latency between userspace submitting
the frame vs. when the hardware will actually see it.

Also if we want tools to use these I think we're going to have to
make some kind of abi promises about the events, so we should make
sure they are as future proof as we can make them (eg. regarding
mutli-gpu systems/etc.).

> +
>   ret = prepare_signaling(dev, state, arg, file_priv, _state,
>   _fences);
>   if (ret)
> diff --git a/drivers/gpu/drm/drm_trace.h b/drivers/gpu/drm/drm_trace.h
> index 11c6dd577e8e..63489923c289 100644
> --- a/drivers/gpu/drm/drm_trace.h
> +++ b/drivers/gpu/drm/drm_trace.h
> @@ -66,6 +66,29 @@ TRACE_EVENT(drm_vblank_event_delivered,
> __entry->seq)
>  );
>  
> +TRACE_EVENT(drm_mode_atomic_commit,
> + TP_PROTO(struct drm_file *file, int *crtcs, int ncrtcs, uint32_t 
> flags),
> + TP_ARGS(file, crtcs, ncrtcs, flags),
> + TP_STRUCT__entry(
> + __field(struct drm_file *, file)
> + __dynamic_array(u32, crtcs, ncrtcs)
> + __field(uint32_t, ncrtcs)
> + __field(uint32_t, flags)
> + ),
> + TP_fast_assign(
> + unsigned int i;
> +
> + __entry->file = file;
> + for (i = 0; i < ncrtcs; i++)
> + ((u32 *)__get_dynamic_array(crtcs))[i] = crtcs[i];
> + __entry->ncrtcs = ncrtcs;
> + __entry->flags = flags;
> + ),
> + TP_printk("file=%p, pid=%8d, flags=%08x, crtcs=%s", __entry->file,
> +   pid_nr(__entry->file->pid), __entry->flags,
> +   __print_array(__get_dynamic_array(crtcs), 
> __entry->ncrtcs, 4))
> +);
> +
>  #endif /* _DRM_TRACE_H_ */
>  
>  /* This part must be 

Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors

[Harry Wentland]

On 2024-02-16 11:11, Harry Wentland wrote:
> 
> 
> On 2024-02-16 10:42, Pekka Paalanen wrote:
>> On Fri, 16 Feb 2024 09:33:47 -0500
>> Harry Wentland  wrote:
>>
>>> On 2024-02-16 03:19, Pekka Paalanen wrote:
 On Fri, 2 Feb 2024 10:28:35 -0500
 Hamza Mahfooz  wrote:
   
> We want programs besides the compositor to be able to enable or disable
> panel power saving features.  

 Could you also explain why, in the commit message, please?

 It is unexpected for arbitrary programs to be able to override the KMS
 client, and certainly new ways to do so should not be added without an
 excellent justification.

 Maybe debugfs would be more appropriate if the purpose is only testing
 rather than production environments?
   
> However, since they are currently only
> configurable through DRM properties, that isn't possible. So, to remedy
> that issue introduce a new "panel_power_savings" sysfs attribute.  

 When the DRM property was added, what was used as the userspace to
 prove its workings?
   
>>>
>>> I don't think there ever was a userspace implementation and doubt any
>>> exists today. Part of that is on me. In hindsight, the KMS prop should
>>> have never gone upstream.
>>>
>>> I suggest we drop the KMS prop entirely.
>>
>> Sounds good. What about the sysfs thing? Should it be a debugfs thing
>> instead, assuming the below question will be resolved?
>>
> 
> 
> It's intended to be used by the power profiles daemon (PPD). I don't think
> debugfs is the right choice. See
> https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/commit/41ed5d33a82b0ceb7b6d473551eb2aa62cade6bc
> 
>>> As for the color accuracy topic, I think it is important that compositors
>>> can have full control over that if needed, while it's also important
>>> for HW vendors to optimize for power when absolute color accuracy is not
>>> needed. An average end-user writing code or working on their slides
>>> would rather have a longer battery life than a perfectly color-accurate
>>> display. We should probably think of a solution that can support both
>>> use-cases.
>>
>> I agree. Maybe this pondering should start from "how would it work from
>> end user perspective"?
>>
>> "Automatically" is probably be most desirable answer. Some kind of
> 
> I agree
> 
>> desktop settings with options like "save power at the expense of image
>> quality":
>> - always
>> - not if watching movies/gaming
>> - on battery
>> - on battery, unless I'm watching movies/gaming
>> - never
>>
> 
> It's interesting that you split out movies/gaming, specifically. AMD's
> ABM algorithm seems to have considered movies in particular when
> evaluating the power/fidelity trade-off.
> 
> I wouldn't think consumer media is very particular about a specific
> color fidelity (despite what HDR specs try to make you believe). Where
> color fidelity would matter to me is when I'd want to edit pictures or
> video.
> 
> The "abm_level" property that we expose is really just that, a setting
> for the strength of the power-savings effect, with 0 being off and 4 being
> maximum strength and power saving, at the expense of fidelity.
> 
> Mario's work is to let the PPD control it and set the ABM levels based on
> the selected power profile:
> 0 - Performance
> 1 - Balance
> 3 - Power
> 
> And I believe we've looked at disabling ABM (setting it to 0) automatically
> if we know we're on AC power.
> 
>> Or maybe there already is something like that, and it only needs to be
>> plumbed through?
>>
>> Which would point towards KMS clients needing to control it, which
>> means a generic KMS prop rather than vendor specific?
>>
>> Or should the desktop compositor be talking to some daemon instead of
>> KMS for this? Maybe they already are?
>>
> 
> I think the intention is for the PPD to be that daemon. Mario can elaborate.
> 

Some more details and screenshots on how the PPD is expected to work and look:
https://linuxconfig.org/how-to-manage-power-profiles-over-d-bus-with-power-profiles-daemon-on-linux

Harry

> Harry
> 
>>
>> Thanks,
>> pq
> 

Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors

[Harry Wentland]

On 2024-02-16 10:42, Pekka Paalanen wrote:
> On Fri, 16 Feb 2024 09:33:47 -0500
> Harry Wentland  wrote:
> 
>> On 2024-02-16 03:19, Pekka Paalanen wrote:
>>> On Fri, 2 Feb 2024 10:28:35 -0500
>>> Hamza Mahfooz  wrote:
>>>   
 We want programs besides the compositor to be able to enable or disable
 panel power saving features.  
>>>
>>> Could you also explain why, in the commit message, please?
>>>
>>> It is unexpected for arbitrary programs to be able to override the KMS
>>> client, and certainly new ways to do so should not be added without an
>>> excellent justification.
>>>
>>> Maybe debugfs would be more appropriate if the purpose is only testing
>>> rather than production environments?
>>>   
 However, since they are currently only
 configurable through DRM properties, that isn't possible. So, to remedy
 that issue introduce a new "panel_power_savings" sysfs attribute.  
>>>
>>> When the DRM property was added, what was used as the userspace to
>>> prove its workings?
>>>   
>>
>> I don't think there ever was a userspace implementation and doubt any
>> exists today. Part of that is on me. In hindsight, the KMS prop should
>> have never gone upstream.
>>
>> I suggest we drop the KMS prop entirely.
> 
> Sounds good. What about the sysfs thing? Should it be a debugfs thing
> instead, assuming the below question will be resolved?
> 


It's intended to be used by the power profiles daemon (PPD). I don't think
debugfs is the right choice. See
https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/commit/41ed5d33a82b0ceb7b6d473551eb2aa62cade6bc

>> As for the color accuracy topic, I think it is important that compositors
>> can have full control over that if needed, while it's also important
>> for HW vendors to optimize for power when absolute color accuracy is not
>> needed. An average end-user writing code or working on their slides
>> would rather have a longer battery life than a perfectly color-accurate
>> display. We should probably think of a solution that can support both
>> use-cases.
> 
> I agree. Maybe this pondering should start from "how would it work from
> end user perspective"?
> 
> "Automatically" is probably be most desirable answer. Some kind of

I agree

> desktop settings with options like "save power at the expense of image
> quality":
> - always
> - not if watching movies/gaming
> - on battery
> - on battery, unless I'm watching movies/gaming
> - never
> 

It's interesting that you split out movies/gaming, specifically. AMD's
ABM algorithm seems to have considered movies in particular when
evaluating the power/fidelity trade-off.

I wouldn't think consumer media is very particular about a specific
color fidelity (despite what HDR specs try to make you believe). Where
color fidelity would matter to me is when I'd want to edit pictures or
video.

The "abm_level" property that we expose is really just that, a setting
for the strength of the power-savings effect, with 0 being off and 4 being
maximum strength and power saving, at the expense of fidelity.

Mario's work is to let the PPD control it and set the ABM levels based on
the selected power profile:
0 - Performance
1 - Balance
3 - Power

And I believe we've looked at disabling ABM (setting it to 0) automatically
if we know we're on AC power.

> Or maybe there already is something like that, and it only needs to be
> plumbed through?
> 
> Which would point towards KMS clients needing to control it, which
> means a generic KMS prop rather than vendor specific?
> 
> Or should the desktop compositor be talking to some daemon instead of
> KMS for this? Maybe they already are?
> 

I think the intention is for the PPD to be that daemon. Mario can elaborate.

Harry

> 
> Thanks,
> pq

Re: [PATCH v3 6/8] drm: add drm_mode_atomic_commit event

[Steven Rostedt]

On Fri, 16 Feb 2024 16:09:55 +0100
Pierre-Eric Pelloux-Prayer  wrote:
> 
> Signed-off-by: Pierre-Eric Pelloux-Prayer 
> ---
>  drivers/gpu/drm/drm_atomic_uapi.c | 21 +
>  drivers/gpu/drm/drm_trace.h   | 23 +++
>  2 files changed, 44 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 29d4940188d4..f31b5c6f870b 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -41,6 +41,7 @@
>  #include 
>  
>  #include "drm_crtc_internal.h"
> +#include "drm_trace.h"
>  
>  /**
>   * DOC: overview
> @@ -1503,6 +1504,26 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   drm_mode_object_put(obj);
>   }
>  
> + if (trace_drm_mode_atomic_commit_enabled()) {
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + int *crtcs;
> + int i, num_crtcs;
> +
> + crtcs = kcalloc(dev->mode_config.num_crtc, sizeof(int),
> + GFP_KERNEL);
> +
> + if (crtcs) {
> + num_crtcs = 0;
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> + crtcs[num_crtcs++] = drm_crtc_index(crtc);

Hmm, looking deeper into this, could you just do the loop the trace event?

That is how different is the config.num_crtc compared to the final num_crtcs?
That way, we don't need to do this allocation if it's not too different.
That is, pass in the dev->mode_config.num_crtc to the tracepoint instead of
num_crtcs.

> +
> + trace_drm_mode_atomic_commit(file_priv, crtcs, 
> num_crtcs, arg->flags);
> +
> + kfree(crtcs);
> + }
> + }
> +
>   ret = prepare_signaling(dev, state, arg, file_priv, _state,
>   _fences);
>   if (ret)
> diff --git a/drivers/gpu/drm/drm_trace.h b/drivers/gpu/drm/drm_trace.h
> index 11c6dd577e8e..63489923c289 100644
> --- a/drivers/gpu/drm/drm_trace.h
> +++ b/drivers/gpu/drm/drm_trace.h
> @@ -66,6 +66,29 @@ TRACE_EVENT(drm_vblank_event_delivered,
> __entry->seq)
>  );
>  
> +TRACE_EVENT(drm_mode_atomic_commit,
> + TP_PROTO(struct drm_file *file, int *crtcs, int ncrtcs, uint32_t 
> flags),
> + TP_ARGS(file, crtcs, ncrtcs, flags),
> + TP_STRUCT__entry(
> + __field(struct drm_file *, file)
> + __dynamic_array(u32, crtcs, ncrtcs)

Here the ncrtcs is what is passed in. It will always be allocated to that
size though.

> + __field(uint32_t, ncrtcs)
> + __field(uint32_t, flags)
> + ),
> + TP_fast_assign(
> + unsigned int i;
> +
> + __entry->file = file;
> + for (i = 0; i < ncrtcs; i++)
> + ((u32 *)__get_dynamic_array(crtcs))[i] = crtcs[i];

Here we have:

int n = 0;

for_each_new_crtc_in_state(state, crtc, crtc_state, i)
((u32 *)__get_dynamic_array(crtcs))[n++] = 
drm_crtc_index(crtc);

__entry->ncrtcs = n;

But this is only viable if the ncrtcs is close to the same size as 
dev->mode_config.num_crtc,
otherwise it's not worth it.

-- Steve



> + __entry->ncrtcs = ncrtcs;
> + __entry->flags = flags;
> + ),
> + TP_printk("file=%p, pid=%8d, flags=%08x, crtcs=%s", __entry->file,
> +   pid_nr(__entry->file->pid), __entry->flags,
> +   __print_array(__get_dynamic_array(crtcs), 
> __entry->ncrtcs, 4))
> +);
> +
>  #endif /* _DRM_TRACE_H_ */
>  
>  /* This part must be outside protection */

Re: [PATCH v3 3/8] amdgpu: use trace_dma_fence_sync_to in amdgpu_fence_sync

[Christian König]

Am 16.02.24 um 16:09 schrieb Pierre-Eric Pelloux-Prayer:

This makes it possible to understand the dependencies between jobs.
Possible usage of this trace:
* stuttering issues like Mesa !9189
* incorrect synchronization: I don't have a link for this one, but having
   these events was very useful to debug a virtio-gpu / native-context /
   radeonsi sync issue

I have prototype code using this in UMR, as can be see here:
https://gitlab.freedesktop.org/tomstdenis/umr/-/merge_requests/37

v2: add a macro since every caller passes __func__ as the reason parameter

Signed-off-by: Pierre-Eric Pelloux-Prayer 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 9 +++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h | 4 +++-
  2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
index 1b013a44ca99..9a3fdc4be51e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
@@ -30,6 +30,7 @@
   */
  
  #include 

+#include 
  
  #include "amdgpu.h"

  #include "amdgpu_trace.h"
@@ -145,14 +146,16 @@ static bool amdgpu_sync_add_later(struct amdgpu_sync 
*sync, struct dma_fence *f)
  }
  
  /**

- * amdgpu_sync_fence - remember to sync to this fence
+ * amdgpu_sync_fence_with_reason - remember to sync to this fence
   *
   * @sync: sync object to add fence to
   * @f: fence to sync to
+ * @reason: why do we sync to this fence
   *
   * Add the fence to the sync object.
   */
-int amdgpu_sync_fence(struct amdgpu_sync *sync, struct dma_fence *f)
+int amdgpu_sync_fence_with_reason(struct amdgpu_sync *sync, struct dma_fence 
*f,
+ const char *reason)
  {
struct amdgpu_sync_entry *e;
  
@@ -166,6 +169,8 @@ int amdgpu_sync_fence(struct amdgpu_sync *sync, struct dma_fence *f)

if (!e)
return -ENOMEM;
  
+	trace_dma_fence_used_as_dependency(f, reason);

+
hash_add(sync->fences, >node, f->context);
e->fence = dma_fence_get(f);
return 0;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h
index cf1e9e858efd..52e7306801de 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h
@@ -47,7 +47,9 @@ struct amdgpu_sync {
  };
  
  void amdgpu_sync_create(struct amdgpu_sync *sync);

-int amdgpu_sync_fence(struct amdgpu_sync *sync, struct dma_fence *f);
+int amdgpu_sync_fence_with_reason(struct amdgpu_sync *sync, struct dma_fence 
*f,
+ const char *reason);
+#define amdgpu_sync_fence(s, f) amdgpu_sync_fence_with_reason(s, f, __func__)
  int amdgpu_sync_resv(struct amdgpu_device *adev, struct amdgpu_sync *sync,
 struct dma_resv *resv, enum amdgpu_sync_mode mode,
 void *owner);

[PATCH] drm/amd: Drop abm_level property

[Mario Limonciello]

This vendor specific property has never been used by userspace
software and conflicts with the panel_power_savings sysfs file.
That is a compositor and user could fight over the same data.

Fixes: f97e4303da16 ("drm/amd/display: add panel_power_savings sysfs entry to 
eDP connectors")
Suggested-by: Harry Wentland 
Signed-off-by: Mario Limonciello 
--
Cc: Hamza Mahfooz 
Cc: Sun peng (Leo) Li 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  8 
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  2 --
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 --
 3 files changed, 24 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index b8fbe97efe1d..3ecc7ef95172 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -1350,14 +1350,6 @@ int amdgpu_display_modeset_create_props(struct 
amdgpu_device *adev)
 "dither",
 amdgpu_dither_enum_list, sz);
 
-   if (adev->dc_enabled) {
-   adev->mode_info.abm_level_property =
-   drm_property_create_range(adev_to_drm(adev), 0,
- "abm level", 0, 4);
-   if (!adev->mode_info.abm_level_property)
-   return -ENOMEM;
-   }
-
return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index 2e4911050cc5..1fe21a70ddd0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -324,8 +324,6 @@ struct amdgpu_mode_info {
struct drm_property *audio_property;
/* FMT dithering */
struct drm_property *dither_property;
-   /* Adaptive Backlight Modulation (power feature) */
-   struct drm_property *abm_level_property;
/* hardcoded DFP edid from BIOS */
struct edid *bios_hardcoded_edid;
int bios_hardcoded_edid_size;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index b9ac3d2f8029..e3b32ffba85a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6388,9 +6388,6 @@ int amdgpu_dm_connector_atomic_set_property(struct 
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
dm_new_state->underscan_enable = val;
ret = 0;
-   } else if (property == adev->mode_info.abm_level_property) {
-   dm_new_state->abm_level = val ?: ABM_LEVEL_IMMEDIATE_DISABLE;
-   ret = 0;
}
 
return ret;
@@ -6433,10 +6430,6 @@ int amdgpu_dm_connector_atomic_get_property(struct 
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
*val = dm_state->underscan_enable;
ret = 0;
-   } else if (property == adev->mode_info.abm_level_property) {
-   *val = (dm_state->abm_level != ABM_LEVEL_IMMEDIATE_DISABLE) ?
-   dm_state->abm_level : 0;
-   ret = 0;
}
 
return ret;
@@ -7652,13 +7645,6 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
aconnector->base.state->max_bpc = 16;
aconnector->base.state->max_requested_bpc = 
aconnector->base.state->max_bpc;
 
-   if (connector_type == DRM_MODE_CONNECTOR_eDP &&
-   (dc_is_dmcu_initialized(adev->dm.dc) ||
-adev->dm.dc->ctx->dmub_srv) && amdgpu_dm_abm_level < 0) {
-   drm_object_attach_property(>base.base,
-   adev->mode_info.abm_level_property, 0);
-   }
-
if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
/* Content Type is currently only implemented for HDMI. */
drm_connector_attach_content_type_property(>base);
-- 
2.34.1

Re: [PATCH] drm/amd: Only allow one entity to control ABM

[Mario Limonciello]

On 2/16/2024 09:41, Christian König wrote:

Am 16.02.24 um 16:12 schrieb Mario Limonciello:

On 2/16/2024 09:05, Harry Wentland wrote:



On 2024-02-16 09:47, Christian König wrote:

Am 16.02.24 um 15:42 schrieb Mario Limonciello:

On 2/16/2024 08:38, Christian König wrote:

Am 16.02.24 um 15:07 schrieb Mario Limonciello:

By exporting ABM to sysfs it's possible that DRM master and software
controlling the sysfs file fight over the value programmed for ABM.

Adjust the module parameter behavior to control who control ABM:
-2: DRM
-1: sysfs (IE via software like power-profiles-daemon)


Well that sounds extremely awkward. Why should a 
power-profiles-deamon has control over the panel power saving 
features?


I mean we are talking about things like reducing backlight level 
when the is inactivity, don't we?


We're talking about activating the ABM algorithm when the system is 
in power saving mode; not from inactivity.  This allows the user to 
squeeze out some extra power "just" in that situation.


But given the comments on the other patch, I tend to agree with 
Harry's proposal instead that we just drop the DRM property 
entirely as there are no consumers of it.


Yeah, but even then the design to let this be controlled by an 
userspace deamon is questionable. Stuff like that is handled inside 
the kernel and not exposed to userspace usually.




Regarding the "how" and "why" of PPD; besides this panel power savings 
sysfs file there are two other things that are nominally changed.


ACPI platform profile: 
https://www.kernel.org/doc/html/latest/userspace-api/sysfs-platform_profile.html


AMD-Pstate EPP value: 
https://www.kernel.org/doc/html//latest/admin-guide/pm/amd-pstate.html


When a user goes into "power saving" mode both of those are tweaked. 
Before we introduced the EPP tweaking in PPD we did discuss a callback 
within the kernel so that userspace could change "just" the ACPI 
platform profile and everything else would react.  There was pushback 
on this, and so instead knobs are offered for things that should be 
tweaked and the userspace daemon can set up policy for what to do when 
a a user uses a userspace client (such as GNOME or KDE) to change the 
desired system profile.


Ok, well who came up with the idea of the userspace deamon? Cause I 
think there will be even more push back on this approach.


Basically when we go from AC to battery (or whatever) the drivers 
usually handle that all inside the kernel today. Involving userspace is 
only done when there is a need for that, e.g. inactivity detection or 
similar.




It's more than AC vs battery.  It's user preference of how they want to 
use the system.


Here's some screenshots of how it all works:

https://linuxconfig.org/how-to-manage-power-profiles-over-d-bus-with-power-profiles-daemon-on-linux



I think we'll need a bit in our kernel docs describing ABM. 
Assumptions around what it is and does seem to lead to confusion.


The thing is that ABM has a visual impact that not all users like. It 
would make sense for users to be able to change the ABM level as 
desired, and/or configure their power profiles to select a certain 
ABM level.


ABM will reduce the backlight and compensate by adjusting brightness 
and contrast of the image. It has 5 levels: 0, 1, 2, 3, 4. 0 means 
off. 4 means maximum backlight reduction. IMO, 1 and 2 look okay. 3 
and 4 can be quite impactful, both to power and visual fidelity.




Aside from this patch Hamza did make some improvements to the kdoc in 
the recent patches, can you read through again and see if you think it 
still needs improvements?


Well what exactly is the requirement? That we have different ABM 
settings for AC and battery? If yes providing different DRM properties 
would sound like the right approach to me.




It's user wants system in "power-saving" state or they want it in 
"balanced" state or they want it in "performance" state.


User picks that state in a client and there is a designated ABM policy 
value that goes with it.  Daemon programs the ABM value.

Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors

[Pekka Paalanen]

On Fri, 16 Feb 2024 09:33:47 -0500
Harry Wentland  wrote:

> On 2024-02-16 03:19, Pekka Paalanen wrote:
> > On Fri, 2 Feb 2024 10:28:35 -0500
> > Hamza Mahfooz  wrote:
> >   
> >> We want programs besides the compositor to be able to enable or disable
> >> panel power saving features.  
> > 
> > Could you also explain why, in the commit message, please?
> > 
> > It is unexpected for arbitrary programs to be able to override the KMS
> > client, and certainly new ways to do so should not be added without an
> > excellent justification.
> > 
> > Maybe debugfs would be more appropriate if the purpose is only testing
> > rather than production environments?
> >   
> >> However, since they are currently only
> >> configurable through DRM properties, that isn't possible. So, to remedy
> >> that issue introduce a new "panel_power_savings" sysfs attribute.  
> > 
> > When the DRM property was added, what was used as the userspace to
> > prove its workings?
> >   
> 
> I don't think there ever was a userspace implementation and doubt any
> exists today. Part of that is on me. In hindsight, the KMS prop should
> have never gone upstream.
> 
> I suggest we drop the KMS prop entirely.

Sounds good. What about the sysfs thing? Should it be a debugfs thing
instead, assuming the below question will be resolved?

> As for the color accuracy topic, I think it is important that compositors
> can have full control over that if needed, while it's also important
> for HW vendors to optimize for power when absolute color accuracy is not
> needed. An average end-user writing code or working on their slides
> would rather have a longer battery life than a perfectly color-accurate
> display. We should probably think of a solution that can support both
> use-cases.

I agree. Maybe this pondering should start from "how would it work from
end user perspective"?

"Automatically" is probably be most desirable answer. Some kind of
desktop settings with options like "save power at the expense of image
quality":
- always
- not if watching movies/gaming
- on battery
- on battery, unless I'm watching movies/gaming
- never

Or maybe there already is something like that, and it only needs to be
plumbed through?

Which would point towards KMS clients needing to control it, which
means a generic KMS prop rather than vendor specific?

Or should the desktop compositor be talking to some daemon instead of
KMS for this? Maybe they already are?


Thanks,
pq


pgpwS7aUkNiWZ.pgp
Description: OpenPGP digital signature

Re: [PATCH] drm/amd: Only allow one entity to control ABM

[Christian König]

Am 16.02.24 um 16:12 schrieb Mario Limonciello:

On 2/16/2024 09:05, Harry Wentland wrote:



On 2024-02-16 09:47, Christian König wrote:

Am 16.02.24 um 15:42 schrieb Mario Limonciello:

On 2/16/2024 08:38, Christian König wrote:

Am 16.02.24 um 15:07 schrieb Mario Limonciello:

By exporting ABM to sysfs it's possible that DRM master and software
controlling the sysfs file fight over the value programmed for ABM.

Adjust the module parameter behavior to control who control ABM:
-2: DRM
-1: sysfs (IE via software like power-profiles-daemon)


Well that sounds extremely awkward. Why should a 
power-profiles-deamon has control over the panel power saving 
features?


I mean we are talking about things like reducing backlight level 
when the is inactivity, don't we?


We're talking about activating the ABM algorithm when the system is 
in power saving mode; not from inactivity.  This allows the user to 
squeeze out some extra power "just" in that situation.


But given the comments on the other patch, I tend to agree with 
Harry's proposal instead that we just drop the DRM property 
entirely as there are no consumers of it.


Yeah, but even then the design to let this be controlled by an 
userspace deamon is questionable. Stuff like that is handled inside 
the kernel and not exposed to userspace usually.




Regarding the "how" and "why" of PPD; besides this panel power savings 
sysfs file there are two other things that are nominally changed.


ACPI platform profile: 
https://www.kernel.org/doc/html/latest/userspace-api/sysfs-platform_profile.html


AMD-Pstate EPP value: 
https://www.kernel.org/doc/html//latest/admin-guide/pm/amd-pstate.html


When a user goes into "power saving" mode both of those are tweaked. 
Before we introduced the EPP tweaking in PPD we did discuss a callback 
within the kernel so that userspace could change "just" the ACPI 
platform profile and everything else would react.  There was pushback 
on this, and so instead knobs are offered for things that should be 
tweaked and the userspace daemon can set up policy for what to do when 
a a user uses a userspace client (such as GNOME or KDE) to change the 
desired system profile.


Ok, well who came up with the idea of the userspace deamon? Cause I 
think there will be even more push back on this approach.


Basically when we go from AC to battery (or whatever) the drivers 
usually handle that all inside the kernel today. Involving userspace is 
only done when there is a need for that, e.g. inactivity detection or 
similar.




I think we'll need a bit in our kernel docs describing ABM. 
Assumptions around what it is and does seem to lead to confusion.


The thing is that ABM has a visual impact that not all users like. It 
would make sense for users to be able to change the ABM level as 
desired, and/or configure their power profiles to select a certain 
ABM level.


ABM will reduce the backlight and compensate by adjusting brightness 
and contrast of the image. It has 5 levels: 0, 1, 2, 3, 4. 0 means 
off. 4 means maximum backlight reduction. IMO, 1 and 2 look okay. 3 
and 4 can be quite impactful, both to power and visual fidelity.




Aside from this patch Hamza did make some improvements to the kdoc in 
the recent patches, can you read through again and see if you think it 
still needs improvements?


Well what exactly is the requirement? That we have different ABM 
settings for AC and battery? If yes providing different DRM properties 
would sound like the right approach to me.


Regards,
Christian.




Harry


Regards,
Christian.





Regards,
Christian.


0-4: User via command line

Also introduce a Kconfig option that allows distributions to choose
the default policy that is appropriate for them.

Fixes: f97e4303da16 ("drm/amd/display: add panel_power_savings 
sysfs entry to eDP connectors")

Signed-off-by: Mario Limonciello 
---
Cc: Hamza Mahfooz 
Cc: Harry Wentland 
Cc: Sun peng (Leo) Li 
   drivers/gpu/drm/amd/amdgpu/Kconfig    | 72 
+++

   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 23 +++---
   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  6 +-
   3 files changed, 90 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig 
b/drivers/gpu/drm/amd/amdgpu/Kconfig

index 22d88f8ef527..2ab57ccf6f21 100644
--- a/drivers/gpu/drm/amd/amdgpu/Kconfig
+++ b/drivers/gpu/drm/amd/amdgpu/Kconfig
@@ -80,6 +80,78 @@ config DRM_AMDGPU_WERROR
 Add -Werror to the build flags for amdgpu.ko.
 Only enable this if you are warning code for amdgpu.ko.
+choice
+    prompt "Amdgpu panel power Savings"
+    default AMDGPU_SYSFS_ABM
+    help
+    Control the default behavior for adaptive panel power 
savings.

+
+    Panel power savings features will sacrifice color accuracy
+    in exchange for power savings.
+
+    This can be configured for:
+    - dynamic control by the DRM master
+    - dynamic control by sysfs nodes
+    - statically by the user at 

RE: [PATCH 9/9] drm/amdgpu: enable MES discovery for GC 11.5.1

[Liu, Shaoyun]

[AMD Official Use Only - General]

Reviewed by shaoyun.liu 

-Original Message-
From: amd-gfx  On Behalf Of Alex Deucher
Sent: Thursday, February 15, 2024 3:40 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Yifan ; Deucher, Alexander 

Subject: [PATCH 9/9] drm/amdgpu: enable MES discovery for GC 11.5.1

From: Yifan Zhang 

This patch to enable MES for GC 11.5.1

Signed-off-by: Yifan Zhang 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index 70aeb56bfd53..704b7820c47c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -2185,6 +2185,7 @@ static int amdgpu_discovery_set_mes_ip_blocks(struct 
amdgpu_device *adev)
case IP_VERSION(11, 0, 3):
case IP_VERSION(11, 0, 4):
case IP_VERSION(11, 5, 0):
+   case IP_VERSION(11, 5, 1):
amdgpu_device_ip_block_add(adev, _v11_0_ip_block);
adev->enable_mes = true;
adev->enable_mes_kiq = true;
--
2.42.0

Re: [PATCH v3 2/8] dma-buf/fence-chain: use trace_dma_fence_sync_to

[Christian König]

Am 16.02.24 um 16:09 schrieb Pierre-Eric Pelloux-Prayer:

To inform tools about the relationship between the fences.

Signed-off-by: Pierre-Eric Pelloux-Prayer 


Reviewed-by: Christian König 


---
  drivers/dma-buf/dma-fence-chain.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/dma-buf/dma-fence-chain.c 
b/drivers/dma-buf/dma-fence-chain.c
index 9663ba1bb6ac..3435078c45b7 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -9,6 +9,8 @@
  
  #include 
  
+#include "trace/events/dma_fence.h"

+
  static bool dma_fence_chain_enable_signaling(struct dma_fence *fence);
  
  /**

@@ -251,6 +253,8 @@ void dma_fence_chain_init(struct dma_fence_chain *chain,
chain->fence = fence;
chain->prev_seqno = 0;
  
+	trace_dma_fence_used_as_dependency(fence, __func__);

+
/* Try to reuse the context of the previous chain node. */
if (prev_chain && __dma_fence_is_later(seqno, prev->seqno, prev->ops)) {
context = prev->context;

Re: [PATCH] drm/amdgpu: Do not program IH_CHICKEN in vega20_ih.c under SRIOV

[Alex Deucher]

On Tue, Feb 13, 2024 at 5:43 PM Victor Lu  wrote:
>
> IH_CHICKEN is blocked for VF writes; this access should be skipped.
>
> Signed-off-by: Victor Lu 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/vega20_ih.c | 38 ++
>  1 file changed, 20 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/vega20_ih.c 
> b/drivers/gpu/drm/amd/amdgpu/vega20_ih.c
> index db66e6cccaf2..b9e785846637 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vega20_ih.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vega20_ih.c
> @@ -291,27 +291,29 @@ static int vega20_ih_irq_init(struct amdgpu_device 
> *adev)
>
> adev->nbio.funcs->ih_control(adev);
>
> -   if ((amdgpu_ip_version(adev, OSSSYS_HWIP, 0) == IP_VERSION(4, 2, 1)) 
> &&
> -   adev->firmware.load_type == AMDGPU_FW_LOAD_DIRECT) {
> -   ih_chicken = RREG32_SOC15(OSSSYS, 0, mmIH_CHICKEN);
> -   if (adev->irq.ih.use_bus_addr) {
> -   ih_chicken = REG_SET_FIELD(ih_chicken, IH_CHICKEN,
> -  MC_SPACE_GPA_ENABLE, 1);
> +   if (!amdgpu_sriov_vf(adev)) {
> +   if ((amdgpu_ip_version(adev, OSSSYS_HWIP, 0) == IP_VERSION(4, 
> 2, 1)) &&
> +   adev->firmware.load_type == AMDGPU_FW_LOAD_DIRECT) {
> +   ih_chicken = RREG32_SOC15(OSSSYS, 0, mmIH_CHICKEN);
> +   if (adev->irq.ih.use_bus_addr) {
> +   ih_chicken = REG_SET_FIELD(ih_chicken, 
> IH_CHICKEN,
> +  
> MC_SPACE_GPA_ENABLE, 1);
> +   }
> +   WREG32_SOC15(OSSSYS, 0, mmIH_CHICKEN, ih_chicken);
> }
> -   WREG32_SOC15(OSSSYS, 0, mmIH_CHICKEN, ih_chicken);
> -   }
>
> -   /* psp firmware won't program IH_CHICKEN for aldebaran
> -* driver needs to program it properly according to
> -* MC_SPACE type in IH_RB_CNTL */
> -   if ((amdgpu_ip_version(adev, OSSSYS_HWIP, 0) == IP_VERSION(4, 4, 0)) 
> ||
> -   (amdgpu_ip_version(adev, OSSSYS_HWIP, 0) == IP_VERSION(4, 4, 2))) 
> {
> -   ih_chicken = RREG32_SOC15(OSSSYS, 0, mmIH_CHICKEN_ALDEBARAN);
> -   if (adev->irq.ih.use_bus_addr) {
> -   ih_chicken = REG_SET_FIELD(ih_chicken, IH_CHICKEN,
> -  MC_SPACE_GPA_ENABLE, 1);
> +   /* psp firmware won't program IH_CHICKEN for aldebaran
> +* driver needs to program it properly according to
> +* MC_SPACE type in IH_RB_CNTL */
> +   if ((amdgpu_ip_version(adev, OSSSYS_HWIP, 0) == IP_VERSION(4, 
> 4, 0)) ||
> +   (amdgpu_ip_version(adev, OSSSYS_HWIP, 0) == IP_VERSION(4, 
> 4, 2))) {
> +   ih_chicken = RREG32_SOC15(OSSSYS, 0, 
> mmIH_CHICKEN_ALDEBARAN);
> +   if (adev->irq.ih.use_bus_addr) {
> +   ih_chicken = REG_SET_FIELD(ih_chicken, 
> IH_CHICKEN,
> +  
> MC_SPACE_GPA_ENABLE, 1);
> +   }
> +   WREG32_SOC15(OSSSYS, 0, mmIH_CHICKEN_ALDEBARAN, 
> ih_chicken);
> }
> -   WREG32_SOC15(OSSSYS, 0, mmIH_CHICKEN_ALDEBARAN, ih_chicken);
> }
>
> for (i = 0; i < ARRAY_SIZE(ih); i++) {
> --
> 2.34.1
>

Re: [PATCH v3 1/8] tracing, dma-buf: add a trace_dma_fence_sync_to event

[Christian König]

Am 16.02.24 um 16:09 schrieb Pierre-Eric Pelloux-Prayer:

This new event can be used to trace where a given dma_fence is added
as a dependency of some other work.

I plan to use it in amdgpu.

Signed-off-by: Pierre-Eric Pelloux-Prayer 
---
  drivers/dma-buf/dma-fence.c  |  1 +
  include/trace/events/dma_fence.h | 27 +++
  2 files changed, 28 insertions(+)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 0393a9bba3a8..e7276c043984 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -23,6 +23,7 @@
  EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
  EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
  EXPORT_TRACEPOINT_SYMBOL(dma_fence_signaled);
+EXPORT_TRACEPOINT_SYMBOL(dma_fence_used_as_dependency);
  
  static DEFINE_SPINLOCK(dma_fence_stub_lock);

  static struct dma_fence dma_fence_stub;
diff --git a/include/trace/events/dma_fence.h b/include/trace/events/dma_fence.h
index 3963e79ca7b4..5a5d272031ce 100644
--- a/include/trace/events/dma_fence.h
+++ b/include/trace/events/dma_fence.h
@@ -83,6 +83,33 @@ DEFINE_EVENT(dma_fence, dma_fence_wait_end,
TP_ARGS(fence)
  );
  
+TRACE_EVENT(dma_fence_used_as_dependency,

+
+   TP_PROTO(struct dma_fence *fence, const char *reason),
+
+   TP_ARGS(fence, reason),
+
+   TP_STRUCT__entry(
+   __string(driver, fence->ops->get_driver_name(fence))
+   __string(timeline, fence->ops->get_timeline_name(fence))
+   __field(unsigned int, context)
+   __field(unsigned int, seqno)


I noted it before that this needs to be an u64 and not unsigned int. 
Otherwise we will lose the higher 32bits.


The existing trace points have that bug as well, so you might also want 
to provide a patch to fix this.


Christian.


+   __string(reason, reason)
+   ),
+
+   TP_fast_assign(
+   __assign_str(driver, fence->ops->get_driver_name(fence));
+   __assign_str(timeline, fence->ops->get_timeline_name(fence));
+   __entry->context = fence->context;
+   __entry->seqno = fence->seqno;
+   __assign_str(reason, reason);
+   ),
+
+   TP_printk("driver=%s timeline=%s context=%u seqno=%u reason=%s",
+ __get_str(driver), __get_str(timeline), __entry->context,
+ __entry->seqno, __get_str(reason))
+);
+
  #endif /*  _TRACE_DMA_FENCE_H */
  
  /* This part must be outside protection */

Re: [PATCH] drm/amdgpu: Improve error checking in amdgpu_virt_rlcg_reg_rw (v2)

[Alex Deucher]

On Tue, Feb 13, 2024 at 2:03 PM Victor Lu  wrote:
>
> The current error detection only looks for a timeout.
> This should be changed to also check scratch_reg1 for any errors
> returned from RLCG.
>
> v2: remove new error value
>
> Signed-off-by: Victor Lu 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 5 +++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h | 1 +
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> index 6ff7d3fb2008..7a4eae36778a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> @@ -979,7 +979,7 @@ u32 amdgpu_virt_rlcg_reg_rw(struct amdgpu_device *adev, 
> u32 offset, u32 v, u32 f
>  * SCRATCH_REG0 = read/write value
>  * SCRATCH_REG1[30:28]  = command
>  * SCRATCH_REG1[19:0]   = address in dword
> -* SCRATCH_REG1[26:24]  = Error reporting
> +* SCRATCH_REG1[27:24]  = Error reporting
>  */
> writel(v, scratch_reg0);
> writel((offset | flag), scratch_reg1);
> @@ -993,7 +993,8 @@ u32 amdgpu_virt_rlcg_reg_rw(struct amdgpu_device *adev, 
> u32 offset, u32 v, u32 f
> udelay(10);
> }
>
> -   if (i >= timeout) {
> +   tmp = readl(scratch_reg1);
> +   if (i >= timeout || (tmp & AMDGPU_RLCG_SCRATCH1_ERROR_MASK) 
> != 0) {
> if (amdgpu_sriov_rlcg_error_report_enabled(adev)) {
> if (tmp & AMDGPU_RLCG_VFGATE_DISABLED) {
> dev_err(adev->dev,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> index fa7be5f277b9..3f59b7b5523f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> @@ -45,6 +45,7 @@
>  #define AMDGPU_RLCG_REG_NOT_IN_RANGE   0x100
>
>  #define AMDGPU_RLCG_SCRATCH1_ADDRESS_MASK  0xF
> +#define AMDGPU_RLCG_SCRATCH1_ERROR_MASK0xF00
>
>  /* all asic after AI use this offset */
>  #define mmRCC_IOV_FUNC_IDENTIFIER 0xDE5
> --
> 2.34.1
>

Re: [PATCH v3 0/8] dma-fence, drm, amdgpu new trace events

[Christian König]

Am 16.02.24 um 16:09 schrieb Pierre-Eric Pelloux-Prayer:

This series adds new events to make it easier for tools
like gpuvis or umr to graph the GPUs, kernel and applications
activity.

UMR patches using these events can be found here:
https://gitlab.freedesktop.org/tomstdenis/umr/-/merge_requests/37

V1:
https://patchwork.kernel.org/project/linux-media/patch/20240117184329.479554-1-pierre-eric.pelloux-pra...@amd.com/


I need to separate this patch set a bit. The DMA-buf stuff usually goes 
upstream through drm-misc-next while the amdgpu only patches go upstream 
through our internal branch.


I will keep you looped in which patch I pick from this set to which branch.

Oh, that's going to be fun.

Christian.



Changes from V1:
* uses trace_dma_fence_sync_to from dma-fence-chain.c
* new amdgpu events
* new drm plane commit event

Changes from V2:
* uses trace_dma_fence_used_as_dependency from drm_sched_job_add_dependency
* add devname attribute to the trace_amdgpu_sched_run_job event
* addressed review comments

Pierre-Eric Pelloux-Prayer (8):
   tracing, dma-buf: add a trace_dma_fence_sync_to event
   dma-buf/fence-chain: use trace_dma_fence_sync_to
   amdgpu: use trace_dma_fence_sync_to in amdgpu_fence_sync
   drm/amdgpu: add a amdgpu_bo_fill trace event
   drm/amdgpu: add a amdgpu_cs_start trace event
   drm: add drm_mode_atomic_commit event
   drm/sched: use trace_dma_fence_used_as_dependency
   drm/amdgpu: add devname to trace_amdgpu_sched_run_job

  drivers/dma-buf/dma-fence-chain.c |  4 +++
  drivers/dma-buf/dma-fence.c   |  1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c|  2 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c   |  2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c  |  9 +++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h  |  4 ++-
  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 42 ---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |  2 ++
  drivers/gpu/drm/drm_atomic_uapi.c | 21 
  drivers/gpu/drm/drm_trace.h   | 23 +
  drivers/gpu/drm/scheduler/sched_main.c|  4 +++
  include/trace/events/dma_fence.h  | 27 +++
  12 files changed, 133 insertions(+), 8 deletions(-)

Reporting a null-ptr-deref in amdgpu

[Joonkyo Jung]

Hello,

We would like to report a null-ptr-deref bug in the AMDGPU DRM driver in
the linux kernel v6.8-rc4 that we found with our customized Syzkaller.
The bug can be triggered by sending two ioctls to the AMDGPU DRM driver in
succession.

The first ioctl amdgpu_ctx_ioctl will create a ctx, and return ctx_id = 1
to the userspace.
Second ioctl, actually any ioctl that will eventually call
amdgpu_ctx_get_entity, carries this ctx_id and passes the context check.
Here, for example, drm_amdgpu_wait_cs.
Validations in amdgpu_ctx_get_entity can also be passed by the
user-provided values from the ioctl arguments.
This eventually leads to drm_sched_entity_init, where the null-ptr-deref
will trigger on RCU_INIT_POINTER(entity->last_scheduled, NULL);

Steps to reproduce are as below.
union drm_amdgpu_ctx *arg1;
union drm_amdgpu_wait_cs *arg2;

arg1 = malloc(sizeof(union drm_amdgpu_ctx));
arg2 = malloc(sizeof(union drm_amdgpu_wait_cs));

arg1->in.op = 0x1;
ioctl(AMDGPU_renderD128_DEVICE_FILE, 0x140106442, arg1);

arg2->in.handle = 0x0;
arg2->in.timeout = 0x2;
arg2->in.ip_type = 0x9;
arg2->in.ip_instance = 0x0;
arg2->in.ring = 0x0;
arg2->in.ctx_id = 0x1;
ioctl(AMDGPU_renderD128_DEVICE_FILE, 0xc0206449, arg2);

The KASAN report is as follows:
general protection fault, probably for non-canonical address
0xdc05:  [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0028-0x002f]
Call Trace:
 
 ? drm_sched_entity_init+0x16e/0x650
 ? drm_sched_entity_init+0x208/0x650
 amdgpu_ctx_get_entity+0x944/0xc30
 amdgpu_cs_wait_ioctl+0x13d/0x3f0
 drm_ioctl_kernel+0x300/0x410
 drm_ioctl+0x648/0xb30
 amdgpu_drm_ioctl+0xc8/0x160
 

Should you need any more information, please do not hesitate to contact us.

Best regards,
Joonkyo Jung

Reporting a slab-use-after-free in amdgpu

[Joonkyo Jung]

Hello,

We would like to report a slab-use-after-free bug in the AMDGPU DRM driver
in the linux kernel v6.8-rc4 that we found with our customized Syzkaller.
The bug can be triggered by sending two ioctls to the AMDGPU DRM driver in
succession.

In amdgpu_bo_move, struct ttm_resource *old_mem = bo->resource is assigned.
As you can see on the alloc & free stack calls, on the same function
amdgpu_bo_move,
amdgpu_move_blit in the end frees bo->resource at ttm_bo_move_accel_cleanup
with ttm_bo_wait_free_node(bo, man->use_tt).
But amdgpu_bo_move continues after that, reaching trace_amdgpu_bo_move(abo,
new_mem->mem_type, old_mem->mem_type) at the end, causing the
use-after-free bug.

Steps to reproduce are as below.
union drm_amdgpu_gem_create *arg1;

arg1 = malloc(sizeof(union drm_amdgpu_gem_create));
arg1->in.bo_size = 0x8;
arg1->in.alignment = 0x0;
arg1->in.domains = 0x4;
arg1->in.domain_flags = 0x9;
ioctl(fd, 0xc0206440, arg1);

arg1->in.bo_size = 0x7fff;
arg1->in.alignment = 0x0;
arg1->in.domains = 0x4;
arg1->in.domain_flags = 0x9;
ioctl(fd, 0xc0206440, arg1);

The KASAN report is as follows:
==
BUG: KASAN: slab-use-after-free in amdgpu_bo_move+0x1479/0x1550
Read of size 4 at addr 88800f5bee80 by task syz-executor/219
Call Trace:
 
 amdgpu_bo_move+0x1479/0x1550
 ttm_bo_handle_move_mem+0x4d0/0x700
 ttm_mem_evict_first+0x945/0x1230
 ttm_bo_mem_space+0x6c7/0x940
 ttm_bo_validate+0x286/0x650
 ttm_bo_init_reserved+0x34c/0x490
 amdgpu_bo_create+0x94b/0x1610
 amdgpu_bo_create_user+0xa3/0x130
 amdgpu_gem_create_ioctl+0x4bc/0xc10
 drm_ioctl_kernel+0x300/0x410
 drm_ioctl+0x648/0xb30
 amdgpu_drm_ioctl+0xc8/0x160
 

Allocated by task 219:
 kmalloc_trace+0x211/0x390
 amdgpu_vram_mgr_new+0x1d6/0xbe0
 ttm_resource_alloc+0xfd/0x1e0
 ttm_bo_mem_space+0x255/0x940
 ttm_bo_validate+0x286/0x650
 ttm_bo_init_reserved+0x34c/0x490
 amdgpu_bo_create+0x94b/0x1610
 amdgpu_bo_create_user+0xa3/0x130
 amdgpu_gem_create_ioctl+0x4bc/0xc10
 drm_ioctl_kernel+0x300/0x410
 drm_ioctl+0x648/0xb30
 amdgpu_drm_ioctl+0xc8/0x160

Freed by task 219:
 kfree+0x111/0x2d0
 ttm_resource_free+0x17e/0x1e0
 ttm_bo_move_accel_cleanup+0x77e/0x9b0
 amdgpu_move_blit+0x3db/0x670
 amdgpu_bo_move+0xfa2/0x1550
 ttm_bo_handle_move_mem+0x4d0/0x700
 ttm_mem_evict_first+0x945/0x1230
 ttm_bo_mem_space+0x6c7/0x940
 ttm_bo_validate+0x286/0x650
 ttm_bo_init_reserved+0x34c/0x490
 amdgpu_bo_create+0x94b/0x1610
 amdgpu_bo_create_user+0xa3/0x130
 amdgpu_gem_create_ioctl+0x4bc/0xc10
 drm_ioctl_kernel+0x300/0x410
 drm_ioctl+0x648/0xb30
 amdgpu_drm_ioctl+0xc8/0x160

The buggy address belongs to the object at 88800f5bee70
 which belongs to the cache kmalloc-96 of size 96
The buggy address is located 16 bytes inside of
 freed 96-byte region [88800f5bee70, 88800f5beed0)

Should you need any more information, please do not hesitate to contact us.

Best regards,
Joonkyo Jung

RE: [PATCH 1/3] drm/radeon: Use RMW accessors for changing LNKCTL2

[Ilpo Järvinen]

On Thu, 15 Feb 2024, Deucher, Alexander wrote:

> [Public]
> 
> > -Original Message-
> > From: Ilpo Järvinen 
> > Sent: Thursday, February 15, 2024 8:32 AM
> > To: Deucher, Alexander ; amd-
> > g...@lists.freedesktop.org; Daniel Vetter ; David Airlie
> > ; Dennis Dalessandro
> > ; dri-
> > de...@lists.freedesktop.org; Jason Gunthorpe ; Leon
> > Romanovsky ; linux-ker...@vger.kernel.org; linux-
> > r...@vger.kernel.org; Pan, Xinhui ; Koenig, Christian
> > 
> > Cc: Ilpo Järvinen ; Lukas Wunner
> > 
> > Subject: [PATCH 1/3] drm/radeon: Use RMW accessors for changing LNKCTL2
> >
> > Convert open coded RMW accesses for LNKCTL2 to use
> > pcie_capability_clear_and_set_word() which makes its easier to understand
> > what the code tries to do.
> >
> > LNKCTL2 is not really owned by any driver because it is a collection of 
> > control
> > bits that PCI core might need to touch. RMW accessors already have support
> > for proper locking for a selected set of registers
> > (LNKCTL2 is not yet among them but likely will be in the future) to avoid 
> > losing
> > concurrent updates.
> >
> > Suggested-by: Lukas Wunner 
> > Signed-off-by: Ilpo Järvinen 
> 
> The radeon and amdgpu patches are:
> Acked-by: Alex Deucher 
> 
> Are you looking for me to pick them up or do you want to land them as 
> part of some larger change?  Either way is fine with me. 

Hi,

You please take them, I intentionally took them apart from the BW 
controller series so they can go through the usual trees, not along with 
the BW controller. (I don't expect the BW controller to be accepted during 
this cycle).

-- 
 i.

[PATCH 2/2] drm/amdgpu: use new reset-affected accessors for userspace interfaces

[Alex Deucher]

Use the new reset critical section accessors for debugfs, sysfs,
and the INFO IOCTL to provide proper mutual exclusivity
to hardware with respect the GPU resets.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c |  20 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  10 +
 drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 215 
 drivers/gpu/drm/amd/pm/amdgpu_pm.c  |  91 -
 4 files changed, 235 insertions(+), 101 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 72eceb7d6667..d0e4a8729703 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1670,7 +1670,7 @@ static int amdgpu_debugfs_test_ib_show(struct seq_file 
*m, void *unused)
}
 
/* Avoid accidently unparking the sched thread during GPU reset */
-   r = down_write_killable(>reset_domain->sem);
+   r = amdgpu_reset_domain_access_write_start(adev);
if (r)
return r;
 
@@ -1699,7 +1699,7 @@ static int amdgpu_debugfs_test_ib_show(struct seq_file 
*m, void *unused)
kthread_unpark(ring->sched.thread);
}
 
-   up_write(>reset_domain->sem);
+   amdgpu_reset_domain_access_write_end(adev);
 
pm_runtime_mark_last_busy(dev->dev);
pm_runtime_put_autosuspend(dev->dev);
@@ -1929,7 +1929,7 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 val)
return -ENOMEM;
 
/* Avoid accidently unparking the sched thread during GPU reset */
-   r = down_read_killable(>reset_domain->sem);
+   r = amdgpu_reset_domain_access_read_start(adev);
if (r)
goto pro_end;
 
@@ -1970,7 +1970,7 @@ static int amdgpu_debugfs_ib_preempt(void *data, u64 val)
/* restart the scheduler */
kthread_unpark(ring->sched.thread);
 
-   up_read(>reset_domain->sem);
+   amdgpu_reset_domain_access_read_end(adev);
 
 pro_end:
kfree(fences);
@@ -2031,23 +2031,23 @@ static ssize_t 
amdgpu_reset_dump_register_list_read(struct file *f,
return 0;
 
memset(reg_offset, 0, 12);
-   ret = down_read_killable(>reset_domain->sem);
+   ret = amdgpu_reset_domain_access_read_start(adev);
if (ret)
return ret;
 
for (i = 0; i < adev->reset_info.num_regs; i++) {
sprintf(reg_offset, "0x%x\n", 
adev->reset_info.reset_dump_reg_list[i]);
-   up_read(>reset_domain->sem);
+   amdgpu_reset_domain_access_read_end(adev);
if (copy_to_user(buf + len, reg_offset, strlen(reg_offset)))
return -EFAULT;
 
len += strlen(reg_offset);
-   ret = down_read_killable(>reset_domain->sem);
+   ret = amdgpu_reset_domain_access_read_start(adev);
if (ret)
return ret;
}
 
-   up_read(>reset_domain->sem);
+   amdgpu_reset_domain_access_read_end(adev);
*pos += len;
 
return len;
@@ -2089,14 +2089,14 @@ static ssize_t 
amdgpu_reset_dump_register_list_write(struct file *f,
ret = -ENOMEM;
goto error_free;
}
-   ret = down_write_killable(>reset_domain->sem);
+   ret = amdgpu_reset_domain_access_write_start(adev);
if (ret)
goto error_free;
 
swap(adev->reset_info.reset_dump_reg_list, tmp);
swap(adev->reset_info.reset_dump_reg_value, new);
adev->reset_info.num_regs = i;
-   up_write(>reset_domain->sem);
+   amdgpu_reset_domain_access_write_end(adev);
ret = size;
 
 error_free:
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index a2df3025a754..4efb44a964ef 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -43,6 +43,7 @@
 #include "amdgpu_gem.h"
 #include "amdgpu_display.h"
 #include "amdgpu_ras.h"
+#include "amdgpu_reset.h"
 #include "amd_pcie.h"
 
 void amdgpu_unregister_gpu_instance(struct amdgpu_device *adev)
@@ -704,7 +705,11 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
return copy_to_user(out, , min(size, 4u)) ? -EFAULT : 0;
}
case AMDGPU_INFO_TIMESTAMP:
+   ret = amdgpu_reset_domain_access_read_start(adev);
+   if (ret)
+   return -EFAULT;
ui64 = amdgpu_gfx_get_gpu_clock_counter(adev);
+   amdgpu_reset_domain_access_read_end(adev);
return copy_to_user(out, , min(size, 8u)) ? -EFAULT : 0;
case AMDGPU_INFO_FW_VERSION: {
struct drm_amdgpu_info_firmware fw_info;
@@ -831,6 +836,9 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
return -ENOMEM;
alloc_size = 

[PATCH 1/2] drm/amdgpu: add new accessors for GPU reset-affected critcal sections

[Alex Deucher]

Provide helper functions for code which needs to be mutually
exclusive with GPU resets.  While we are here, move
amdgpu_in_reset in amdgpu_reset.c since that is the more
logical location for it and add documentation.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  2 -
 .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c|  1 +
 .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c |  1 +
 .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c |  1 +
 .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|  5 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c   |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c   |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 86 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h |  6 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c  |  1 +
 drivers/gpu/drm/amd/amdgpu/aqua_vanjaram.c|  1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c|  1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c|  1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c |  1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c |  1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_4_2.c   |  1 +
 drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c   |  1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c|  1 +
 drivers/gpu/drm/amd/amdgpu/mes_v10_1.c|  1 +
 drivers/gpu/drm/amd/amdgpu/mes_v11_0.c|  1 +
 drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c  |  1 +
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  1 +
 .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c|  1 +
 drivers/gpu/drm/amd/pm/amdgpu_pm.c|  1 +
 .../drm/amd/pm/powerplay/inc/amd_powerplay.h  |  1 +
 drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c |  1 +
 .../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c |  1 +
 .../drm/amd/pm/swsmu/smu13/aldebaran_ppt.c|  1 +
 .../drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c  |  1 +
 33 files changed, 121 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 9246bca0a008..0e365cadcc3f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1602,8 +1602,6 @@ static inline bool amdgpu_is_tmz(struct amdgpu_device 
*adev)
return adev->gmc.tmz_enabled;
 }
 
-int amdgpu_in_reset(struct amdgpu_device *adev);
-
 extern const struct attribute_group amdgpu_vram_mgr_attr_group;
 extern const struct attribute_group amdgpu_gtt_mgr_attr_group;
 extern const struct attribute_group amdgpu_flash_attr_group;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
index 69810b3f1c63..78bec0b6c502 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
@@ -22,6 +22,7 @@
 #include "amdgpu.h"
 #include "amdgpu_amdkfd.h"
 #include "amdgpu_amdkfd_gfx_v10.h"
+#include "amdgpu_reset.h"
 #include "gc/gc_10_1_0_offset.h"
 #include "gc/gc_10_1_0_sh_mask.h"
 #include "athub/athub_2_0_0_offset.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
index ca4a6b82817f..717a6d10b01c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
@@ -22,6 +22,7 @@
 
 #include "amdgpu.h"
 #include "amdgpu_amdkfd.h"
+#include "amdgpu_reset.h"
 #include "cikd.h"
 #include "cik_sdma.h"
 #include "gfx_v7_0.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
index 0f3e2944edd7..d08e9c308835 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
@@ -22,6 +22,7 @@
 
 #include "amdgpu.h"
 #include "amdgpu_amdkfd.h"
+#include "amdgpu_reset.h"
 #include "gfx_v8_0.h"
 #include "gca/gfx_8_0_sh_mask.h"
 #include "gca/gfx_8_0_d.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
index 5a35a8ca8922..b0ff1065491e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c
@@ -21,6 +21,7 @@
  */
 #include "amdgpu.h"
 #include "amdgpu_amdkfd.h"
+#include "amdgpu_reset.h"
 #include "gc/gc_9_0_offset.h"
 #include "gc/gc_9_0_sh_mask.h"
 #include "vega10_enum.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index e2ae9ba147ba..0eed6bb213b8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -27,6 +27,7 @@
 #include "amdgpu.h"
 #include "amdgpu_sched.h"
 #include "amdgpu_ras.h"
+#include "amdgpu_reset.h"
 #include 
 
 #define to_amdgpu_ctx_entity(e)\
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 

[PATCH v3 8/8] drm/amdgpu: add devname to trace_amdgpu_sched_run_job

[Pierre-Eric Pelloux-Prayer]

With the move to work queues for the drm scheduler it becomes
impossible for a tool to match the events to the GPU.

Before this move, the event source was fixed (eg: gfx_0.0.0-598),
so even if the system had multiple GPUs with identical queue names
it was possible to map the events using the PID.

With work queues, the source is now something like: "kworker/u64:0-15248"
(and the PID isn't stable), so the "timeline=gfx_0.0.0" attribute
isn't enough in multi-GPU setups.

This commit adds a dev=devname attribute to resolve this issue.

Signed-off-by: Pierre-Eric Pelloux-Prayer 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 12 
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index 71a5cf37b472..657866a498f1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -292,7 +292,7 @@ static struct dma_fence *amdgpu_job_run(struct 
drm_sched_job *sched_job)
job = to_amdgpu_job(sched_job);
finished = >base.s_fence->finished;
 
-   trace_amdgpu_sched_run_job(job);
+   trace_amdgpu_sched_run_job(job, adev);
 
/* Skip job if VRAM is lost and never resubmit gangs */
if (job->generation != amdgpu_vm_generation(adev, job->vm) ||
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index 3f18f570e5ac..1aea1b78747d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -202,8 +202,8 @@ TRACE_EVENT(amdgpu_cs_start,
 );
 
 TRACE_EVENT(amdgpu_sched_run_job,
-   TP_PROTO(struct amdgpu_job *job),
-   TP_ARGS(job),
+   TP_PROTO(struct amdgpu_job *job, struct amdgpu_device *adev),
+   TP_ARGS(job, adev),
TP_STRUCT__entry(
 __field(uint64_t, sched_job_id)
 __string(timeline, 
AMDGPU_JOB_GET_TIMELINE_NAME(job))
@@ -211,6 +211,7 @@ TRACE_EVENT(amdgpu_sched_run_job,
 __field(unsigned int, seqno)
 __string(ring, 
to_amdgpu_ring(job->base.sched)->name)
 __field(u32, num_ibs)
+__string(dname, dev_name(adev->dev))
 ),
 
TP_fast_assign(
@@ -220,10 +221,13 @@ TRACE_EVENT(amdgpu_sched_run_job,
   __entry->seqno = job->base.s_fence->finished.seqno;
   __assign_str(ring, 
to_amdgpu_ring(job->base.sched)->name);
   __entry->num_ibs = job->num_ibs;
+  __assign_str(dname, dev_name(adev->dev));
   ),
-   TP_printk("sched_job=%llu, timeline=%s, context=%u, seqno=%u, 
ring_name=%s, num_ibs=%u",
+   TP_printk("sched_job=%llu, timeline=%s, context=%u, seqno=%u, "
+ "ring_name=%s, num_ibs=%u, dev=%s",
  __entry->sched_job_id, __get_str(timeline), 
__entry->context,
- __entry->seqno, __get_str(ring), __entry->num_ibs)
+ __entry->seqno, __get_str(ring), __entry->num_ibs, 
__get_str(dname))
+
 );
 
 
-- 
2.40.1

[PATCH v3 7/8] drm/sched: use trace_dma_fence_used_as_dependency

[Pierre-Eric Pelloux-Prayer]

drm_sched_job_add_dependency adds dependencies so use the new
trace event.

Signed-off-by: Pierre-Eric Pelloux-Prayer 
---
 drivers/gpu/drm/scheduler/sched_main.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index 7e90c9f95611..6ee49f70d319 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -84,6 +84,8 @@
 #include 
 #include 
 
+#include 
+
 #define CREATE_TRACE_POINTS
 #include "gpu_scheduler_trace.h"
 
@@ -879,6 +881,8 @@ int drm_sched_job_add_dependency(struct drm_sched_job *job,
if (entry->context != fence->context)
continue;
 
+   trace_dma_fence_used_as_dependency(fence, __func__);
+
if (dma_fence_is_later(fence, entry)) {
dma_fence_put(entry);
xa_store(>dependencies, index, fence, GFP_KERNEL);
-- 
2.40.1

Re: [PATCH] drm/amd: Only allow one entity to control ABM

[Mario Limonciello]

On 2/16/2024 09:05, Harry Wentland wrote:



On 2024-02-16 09:47, Christian König wrote:

Am 16.02.24 um 15:42 schrieb Mario Limonciello:

On 2/16/2024 08:38, Christian König wrote:

Am 16.02.24 um 15:07 schrieb Mario Limonciello:

By exporting ABM to sysfs it's possible that DRM master and software
controlling the sysfs file fight over the value programmed for ABM.

Adjust the module parameter behavior to control who control ABM:
-2: DRM
-1: sysfs (IE via software like power-profiles-daemon)


Well that sounds extremely awkward. Why should a power-profiles-deamon has 
control over the panel power saving features?

I mean we are talking about things like reducing backlight level when the is 
inactivity, don't we?


We're talking about activating the ABM algorithm when the system is in power saving mode; 
not from inactivity.  This allows the user to squeeze out some extra power 
"just" in that situation.

But given the comments on the other patch, I tend to agree with Harry's 
proposal instead that we just drop the DRM property entirely as there are no 
consumers of it.


Yeah, but even then the design to let this be controlled by an userspace deamon 
is questionable. Stuff like that is handled inside the kernel and not exposed 
to userspace usually.



Regarding the "how" and "why" of PPD; besides this panel power savings 
sysfs file there are two other things that are nominally changed.


ACPI platform profile: 
https://www.kernel.org/doc/html/latest/userspace-api/sysfs-platform_profile.html


AMD-Pstate EPP value: 
https://www.kernel.org/doc/html//latest/admin-guide/pm/amd-pstate.html


When a user goes into "power saving" mode both of those are tweaked. 
Before we introduced the EPP tweaking in PPD we did discuss a callback 
within the kernel so that userspace could change "just" the ACPI 
platform profile and everything else would react.  There was pushback on 
this, and so instead knobs are offered for things that should be tweaked 
and the userspace daemon can set up policy for what to do when a a user 
uses a userspace client (such as GNOME or KDE) to change the desired 
system profile.




I think we'll need a bit in our kernel docs describing ABM. Assumptions around 
what it is and does seem to lead to confusion.

The thing is that ABM has a visual impact that not all users like. It would 
make sense for users to be able to change the ABM level as desired, and/or 
configure their power profiles to select a certain ABM level.

ABM will reduce the backlight and compensate by adjusting brightness and 
contrast of the image. It has 5 levels: 0, 1, 2, 3, 4. 0 means off. 4 means 
maximum backlight reduction. IMO, 1 and 2 look okay. 3 and 4 can be quite 
impactful, both to power and visual fidelity.



Aside from this patch Hamza did make some improvements to the kdoc in 
the recent patches, can you read through again and see if you think it 
still needs improvements?



Harry


Regards,
Christian.





Regards,
Christian.


0-4: User via command line

Also introduce a Kconfig option that allows distributions to choose
the default policy that is appropriate for them.

Fixes: f97e4303da16 ("drm/amd/display: add panel_power_savings sysfs entry to eDP 
connectors")
Signed-off-by: Mario Limonciello 
---
Cc: Hamza Mahfooz 
Cc: Harry Wentland 
Cc: Sun peng (Leo) Li 
   drivers/gpu/drm/amd/amdgpu/Kconfig    | 72 +++
   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 23 +++---
   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  6 +-
   3 files changed, 90 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig 
b/drivers/gpu/drm/amd/amdgpu/Kconfig
index 22d88f8ef527..2ab57ccf6f21 100644
--- a/drivers/gpu/drm/amd/amdgpu/Kconfig
+++ b/drivers/gpu/drm/amd/amdgpu/Kconfig
@@ -80,6 +80,78 @@ config DRM_AMDGPU_WERROR
     Add -Werror to the build flags for amdgpu.ko.
     Only enable this if you are warning code for amdgpu.ko.
+choice
+    prompt "Amdgpu panel power Savings"
+    default AMDGPU_SYSFS_ABM
+    help
+    Control the default behavior for adaptive panel power savings.
+
+    Panel power savings features will sacrifice color accuracy
+    in exchange for power savings.
+
+    This can be configured for:
+    - dynamic control by the DRM master
+    - dynamic control by sysfs nodes
+    - statically by the user at kernel compile time
+
+    This value can also be overridden by the amdgpu.abmlevel
+    module parameter.
+
+config AMDGPU_DRM_ABM
+    bool "DRM Master control"
+    help
+    Export a property called 'abm_level' that can be
+    manipulated by the DRM master for supported hardware.
+
+config AMDGPU_SYSFS_ABM
+    bool "sysfs control"
+    help
+    Export a sysfs file 'panel_power_savings' that can be
+    manipulated by userspace for supported hardware.
+
+config AMDGPU_HARDCODE_ABM0
+    bool "No Panel power savings"
+    help
+    Disable panel power savings.
+    It can only 

[PATCH v3 6/8] drm: add drm_mode_atomic_commit event

[Pierre-Eric Pelloux-Prayer]

With this and the dma_fence_used_as_dependency event, a tool can draw the
relationship between the compositing draw, the atomic commit, and vblank.

An example on a 2 monitors system look like this:

gnome-shell-1638[018] .  2571.905124: drm_mode_atomic_commit: 
file=245c3f0c, pid=1165, flags=0201, crtcs={0x1}
gnome-shell-1638[018] .  2571.905147: dma_fence_used_as_dependency: 
driver=drm_sched timeline=gfx_0.0.0 context=270 seqno=73240 
reason=dma_fence_chain_init
gnome-shell-1638[018] .  2571.913226: drm_mode_atomic_commit: 
file=245c3f0c, pid=1165, flags=0201, crtcs={0x0}
gnome-shell-1638[018] .  2571.913250: dma_fence_used_as_dependency: 
driver=drm_sched timeline=gfx_0.0.0 context=270 seqno=73241 
reason=dma_fence_chain_init
-0   [018] d.h3.  2571.915687: drm_vblank_event: crtc=1, 
seq=155747, time=2571916093743, high-prec=true
-0   [018] d.h3.  2571.915968: drm_vblank_event: crtc=0, 
seq=153862, time=2571916377180, high-prec=true

v2: fix unchecked memory allocation

Signed-off-by: Pierre-Eric Pelloux-Prayer 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 21 +
 drivers/gpu/drm/drm_trace.h   | 23 +++
 2 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 29d4940188d4..f31b5c6f870b 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -41,6 +41,7 @@
 #include 
 
 #include "drm_crtc_internal.h"
+#include "drm_trace.h"
 
 /**
  * DOC: overview
@@ -1503,6 +1504,26 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
drm_mode_object_put(obj);
}
 
+   if (trace_drm_mode_atomic_commit_enabled()) {
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc *crtc;
+   int *crtcs;
+   int i, num_crtcs;
+
+   crtcs = kcalloc(dev->mode_config.num_crtc, sizeof(int),
+   GFP_KERNEL);
+
+   if (crtcs) {
+   num_crtcs = 0;
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
+   crtcs[num_crtcs++] = drm_crtc_index(crtc);
+
+   trace_drm_mode_atomic_commit(file_priv, crtcs, 
num_crtcs, arg->flags);
+
+   kfree(crtcs);
+   }
+   }
+
ret = prepare_signaling(dev, state, arg, file_priv, _state,
_fences);
if (ret)
diff --git a/drivers/gpu/drm/drm_trace.h b/drivers/gpu/drm/drm_trace.h
index 11c6dd577e8e..63489923c289 100644
--- a/drivers/gpu/drm/drm_trace.h
+++ b/drivers/gpu/drm/drm_trace.h
@@ -66,6 +66,29 @@ TRACE_EVENT(drm_vblank_event_delivered,
  __entry->seq)
 );
 
+TRACE_EVENT(drm_mode_atomic_commit,
+   TP_PROTO(struct drm_file *file, int *crtcs, int ncrtcs, uint32_t 
flags),
+   TP_ARGS(file, crtcs, ncrtcs, flags),
+   TP_STRUCT__entry(
+   __field(struct drm_file *, file)
+   __dynamic_array(u32, crtcs, ncrtcs)
+   __field(uint32_t, ncrtcs)
+   __field(uint32_t, flags)
+   ),
+   TP_fast_assign(
+   unsigned int i;
+
+   __entry->file = file;
+   for (i = 0; i < ncrtcs; i++)
+   ((u32 *)__get_dynamic_array(crtcs))[i] = crtcs[i];
+   __entry->ncrtcs = ncrtcs;
+   __entry->flags = flags;
+   ),
+   TP_printk("file=%p, pid=%8d, flags=%08x, crtcs=%s", __entry->file,
+ pid_nr(__entry->file->pid), __entry->flags,
+ __print_array(__get_dynamic_array(crtcs), 
__entry->ncrtcs, 4))
+);
+
 #endif /* _DRM_TRACE_H_ */
 
 /* This part must be outside protection */
-- 
2.40.1

[PATCH v3 5/8] drm/amdgpu: add a amdgpu_cs_start trace event

[Pierre-Eric Pelloux-Prayer]

amdgpu_cs_ioctl already exists but serves a different
purpose.

amdgpu_cs_start marks the beginning of the kernel processing of
the ioctl which is useful for tools to map which events belong to
the same submission (without this, the first event would be the
amdgpu_bo_set_list ones).

v2: renamed to amdgpu_cs_start

Signed-off-by: Pierre-Eric Pelloux-Prayer 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c|  2 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 12 
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 0a4b09709cfb..f3369cd0d9a3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1402,6 +1402,8 @@ int amdgpu_cs_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
return r;
}
 
+   trace_amdgpu_cs_start(data);
+
r = amdgpu_cs_pass1(, data);
if (r)
goto error_fini;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index 0e47cbe7e0a9..3f18f570e5ac 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -189,6 +189,18 @@ TRACE_EVENT(amdgpu_cs_ioctl,
  __entry->seqno, __get_str(ring), __entry->num_ibs)
 );
 
+TRACE_EVENT(amdgpu_cs_start,
+   TP_PROTO(union drm_amdgpu_cs *cs),
+   TP_ARGS(cs),
+   TP_STRUCT__entry(
+__field(uint32_t, ctx_id)
+   ),
+   TP_fast_assign(
+  __entry->ctx_id = cs->in.ctx_id;
+   ),
+   TP_printk("context=%u", __entry->ctx_id)
+);
+
 TRACE_EVENT(amdgpu_sched_run_job,
TP_PROTO(struct amdgpu_job *job),
TP_ARGS(job),
-- 
2.40.1

[PATCH v3 4/8] drm/amdgpu: add a amdgpu_bo_fill trace event

[Pierre-Eric Pelloux-Prayer]

Useful to identify why sdma jobs are submitted.

v2: moved from amdgpu_bo_create to amdgpu_bo_fill

Signed-off-by: Pierre-Eric Pelloux-Prayer 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 18 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |  2 ++
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index f539b1d00234..0e47cbe7e0a9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -514,6 +514,24 @@ TRACE_EVENT(amdgpu_bo_move,
__entry->new_placement, __entry->bo_size)
 );
 
+TRACE_EVENT(amdgpu_bo_fill,
+   TP_PROTO(struct amdgpu_bo *bo, uint32_t value),
+   TP_ARGS(bo, value),
+   TP_STRUCT__entry(
+   __field(struct amdgpu_bo *, bo)
+   __field(u64, bo_size)
+   __field(u32, value)
+   ),
+
+   TP_fast_assign(
+   __entry->bo  = bo;
+   __entry->bo_size = amdgpu_bo_size(bo);
+   __entry->value   = value;
+   ),
+   TP_printk("bo=%p, size=%lld, value=0x%08x",
+   __entry->bo, __entry->bo_size, __entry->value)
+);
+
 TRACE_EVENT(amdgpu_ib_pipe_sync,
TP_PROTO(struct amdgpu_job *sched_job, struct dma_fence *fence),
TP_ARGS(sched_job, fence),
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 8722beba494e..7d0b2c1191f8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -2231,6 +2231,8 @@ int amdgpu_fill_buffer(struct amdgpu_bo *bo,
return -EINVAL;
}
 
+   trace_amdgpu_bo_fill(bo, src_data);
+
amdgpu_res_first(bo->tbo.resource, 0, amdgpu_bo_size(bo), );
 
mutex_lock(>mman.gtt_window_lock);
-- 
2.40.1

[PATCH v3 3/8] amdgpu: use trace_dma_fence_sync_to in amdgpu_fence_sync

[Pierre-Eric Pelloux-Prayer]

This makes it possible to understand the dependencies between jobs.
Possible usage of this trace:
* stuttering issues like Mesa !9189
* incorrect synchronization: I don't have a link for this one, but having
  these events was very useful to debug a virtio-gpu / native-context /
  radeonsi sync issue

I have prototype code using this in UMR, as can be see here:
   https://gitlab.freedesktop.org/tomstdenis/umr/-/merge_requests/37

v2: add a macro since every caller passes __func__ as the reason parameter

Signed-off-by: Pierre-Eric Pelloux-Prayer 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 9 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h | 4 +++-
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
index 1b013a44ca99..9a3fdc4be51e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
@@ -30,6 +30,7 @@
  */
 
 #include 
+#include 
 
 #include "amdgpu.h"
 #include "amdgpu_trace.h"
@@ -145,14 +146,16 @@ static bool amdgpu_sync_add_later(struct amdgpu_sync 
*sync, struct dma_fence *f)
 }
 
 /**
- * amdgpu_sync_fence - remember to sync to this fence
+ * amdgpu_sync_fence_with_reason - remember to sync to this fence
  *
  * @sync: sync object to add fence to
  * @f: fence to sync to
+ * @reason: why do we sync to this fence
  *
  * Add the fence to the sync object.
  */
-int amdgpu_sync_fence(struct amdgpu_sync *sync, struct dma_fence *f)
+int amdgpu_sync_fence_with_reason(struct amdgpu_sync *sync, struct dma_fence 
*f,
+ const char *reason)
 {
struct amdgpu_sync_entry *e;
 
@@ -166,6 +169,8 @@ int amdgpu_sync_fence(struct amdgpu_sync *sync, struct 
dma_fence *f)
if (!e)
return -ENOMEM;
 
+   trace_dma_fence_used_as_dependency(f, reason);
+
hash_add(sync->fences, >node, f->context);
e->fence = dma_fence_get(f);
return 0;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h
index cf1e9e858efd..52e7306801de 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h
@@ -47,7 +47,9 @@ struct amdgpu_sync {
 };
 
 void amdgpu_sync_create(struct amdgpu_sync *sync);
-int amdgpu_sync_fence(struct amdgpu_sync *sync, struct dma_fence *f);
+int amdgpu_sync_fence_with_reason(struct amdgpu_sync *sync, struct dma_fence 
*f,
+ const char *reason);
+#define amdgpu_sync_fence(s, f) amdgpu_sync_fence_with_reason(s, f, __func__)
 int amdgpu_sync_resv(struct amdgpu_device *adev, struct amdgpu_sync *sync,
 struct dma_resv *resv, enum amdgpu_sync_mode mode,
 void *owner);
-- 
2.40.1

[PATCH v3 2/8] dma-buf/fence-chain: use trace_dma_fence_sync_to

[Pierre-Eric Pelloux-Prayer]

To inform tools about the relationship between the fences.

Signed-off-by: Pierre-Eric Pelloux-Prayer 
---
 drivers/dma-buf/dma-fence-chain.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/dma-buf/dma-fence-chain.c 
b/drivers/dma-buf/dma-fence-chain.c
index 9663ba1bb6ac..3435078c45b7 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -9,6 +9,8 @@
 
 #include 
 
+#include "trace/events/dma_fence.h"
+
 static bool dma_fence_chain_enable_signaling(struct dma_fence *fence);
 
 /**
@@ -251,6 +253,8 @@ void dma_fence_chain_init(struct dma_fence_chain *chain,
chain->fence = fence;
chain->prev_seqno = 0;
 
+   trace_dma_fence_used_as_dependency(fence, __func__);
+
/* Try to reuse the context of the previous chain node. */
if (prev_chain && __dma_fence_is_later(seqno, prev->seqno, prev->ops)) {
context = prev->context;
-- 
2.40.1

[PATCH v3 1/8] tracing, dma-buf: add a trace_dma_fence_sync_to event

[Pierre-Eric Pelloux-Prayer]

This new event can be used to trace where a given dma_fence is added
as a dependency of some other work.

I plan to use it in amdgpu.

Signed-off-by: Pierre-Eric Pelloux-Prayer 
---
 drivers/dma-buf/dma-fence.c  |  1 +
 include/trace/events/dma_fence.h | 27 +++
 2 files changed, 28 insertions(+)

diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 0393a9bba3a8..e7276c043984 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -23,6 +23,7 @@
 EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit);
 EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal);
 EXPORT_TRACEPOINT_SYMBOL(dma_fence_signaled);
+EXPORT_TRACEPOINT_SYMBOL(dma_fence_used_as_dependency);
 
 static DEFINE_SPINLOCK(dma_fence_stub_lock);
 static struct dma_fence dma_fence_stub;
diff --git a/include/trace/events/dma_fence.h b/include/trace/events/dma_fence.h
index 3963e79ca7b4..5a5d272031ce 100644
--- a/include/trace/events/dma_fence.h
+++ b/include/trace/events/dma_fence.h
@@ -83,6 +83,33 @@ DEFINE_EVENT(dma_fence, dma_fence_wait_end,
TP_ARGS(fence)
 );
 
+TRACE_EVENT(dma_fence_used_as_dependency,
+
+   TP_PROTO(struct dma_fence *fence, const char *reason),
+
+   TP_ARGS(fence, reason),
+
+   TP_STRUCT__entry(
+   __string(driver, fence->ops->get_driver_name(fence))
+   __string(timeline, fence->ops->get_timeline_name(fence))
+   __field(unsigned int, context)
+   __field(unsigned int, seqno)
+   __string(reason, reason)
+   ),
+
+   TP_fast_assign(
+   __assign_str(driver, fence->ops->get_driver_name(fence));
+   __assign_str(timeline, fence->ops->get_timeline_name(fence));
+   __entry->context = fence->context;
+   __entry->seqno = fence->seqno;
+   __assign_str(reason, reason);
+   ),
+
+   TP_printk("driver=%s timeline=%s context=%u seqno=%u reason=%s",
+ __get_str(driver), __get_str(timeline), __entry->context,
+ __entry->seqno, __get_str(reason))
+);
+
 #endif /*  _TRACE_DMA_FENCE_H */
 
 /* This part must be outside protection */
-- 
2.40.1

[PATCH v3 0/8] dma-fence, drm, amdgpu new trace events

[Pierre-Eric Pelloux-Prayer]

This series adds new events to make it easier for tools
like gpuvis or umr to graph the GPUs, kernel and applications
activity.

UMR patches using these events can be found here:
https://gitlab.freedesktop.org/tomstdenis/umr/-/merge_requests/37

V1:
https://patchwork.kernel.org/project/linux-media/patch/20240117184329.479554-1-pierre-eric.pelloux-pra...@amd.com/

Changes from V1:
* uses trace_dma_fence_sync_to from dma-fence-chain.c
* new amdgpu events
* new drm plane commit event

Changes from V2:
* uses trace_dma_fence_used_as_dependency from drm_sched_job_add_dependency
* add devname attribute to the trace_amdgpu_sched_run_job event
* addressed review comments

Pierre-Eric Pelloux-Prayer (8):
  tracing, dma-buf: add a trace_dma_fence_sync_to event
  dma-buf/fence-chain: use trace_dma_fence_sync_to
  amdgpu: use trace_dma_fence_sync_to in amdgpu_fence_sync
  drm/amdgpu: add a amdgpu_bo_fill trace event
  drm/amdgpu: add a amdgpu_cs_start trace event
  drm: add drm_mode_atomic_commit event
  drm/sched: use trace_dma_fence_used_as_dependency
  drm/amdgpu: add devname to trace_amdgpu_sched_run_job

 drivers/dma-buf/dma-fence-chain.c |  4 +++
 drivers/dma-buf/dma-fence.c   |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c|  2 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c  |  9 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h  |  4 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 42 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |  2 ++
 drivers/gpu/drm/drm_atomic_uapi.c | 21 
 drivers/gpu/drm/drm_trace.h   | 23 +
 drivers/gpu/drm/scheduler/sched_main.c|  4 +++
 include/trace/events/dma_fence.h  | 27 +++
 12 files changed, 133 insertions(+), 8 deletions(-)

-- 
2.40.1

Re: [PATCH] drm/amd: Change `jpeg_v4_0_5_start_dpg_mode()` to void

[Alex Deucher]

On Thu, Feb 15, 2024 at 4:58 PM Mario Limonciello
 wrote:
>
> jpeg_v4_0_5_start_dpg_mode() always returns 0 and the return value
> doesn't get used in the caller jpeg_v4_0_5_start(). Modify the
> function to be void.
>
> Reported-by: coverity-bot 
> Addresses-Coverity-ID: 1583635 ("Code maintainability issues")
> Fixes: 0a119d53f74a ("drm/amdgpu/jpeg: add support for jpeg DPG mode")
> Signed-off-by: Mario Limonciello 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_5.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_5.c 
> b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_5.c
> index 3602738874ee..8d1754e35605 100644
> --- a/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_5.c
> +++ b/drivers/gpu/drm/amd/amdgpu/jpeg_v4_0_5.c
> @@ -358,7 +358,7 @@ static int jpeg_v4_0_5_enable_static_power_gating(struct 
> amdgpu_device *adev, in
>   *
>   * Start JPEG block with dpg mode
>   */
> -static int jpeg_v4_0_5_start_dpg_mode(struct amdgpu_device *adev, int 
> inst_idx, bool indirect)
> +static void jpeg_v4_0_5_start_dpg_mode(struct amdgpu_device *adev, int 
> inst_idx, bool indirect)
>  {
> struct amdgpu_ring *ring = adev->jpeg.inst[inst_idx].ring_dec;
> uint32_t reg_data = 0;
> @@ -411,8 +411,6 @@ static int jpeg_v4_0_5_start_dpg_mode(struct 
> amdgpu_device *adev, int inst_idx,
> WREG32_SOC15(JPEG, inst_idx, regUVD_JRBC_RB_CNTL, 0x0002L);
> WREG32_SOC15(JPEG, inst_idx, regUVD_JRBC_RB_SIZE, ring->ring_size / 
> 4);
> ring->wptr = RREG32_SOC15(JPEG, inst_idx, regUVD_JRBC_RB_WPTR);
> -
> -   return 0;
>  }
>
>  /**
> @@ -458,7 +456,7 @@ static int jpeg_v4_0_5_start(struct amdgpu_device *adev)
> VCN_JPEG_DB_CTRL__EN_MASK);
>
> if (adev->pg_flags & AMD_PG_SUPPORT_JPEG_DPG) {
> -   r = jpeg_v4_0_5_start_dpg_mode(adev, i, 
> adev->jpeg.indirect_sram);
> +   jpeg_v4_0_5_start_dpg_mode(adev, i, 
> adev->jpeg.indirect_sram);
> continue;
> }
>
> --
> 2.34.1
>

Re: [PATCH v6 3/3] drm/buddy: Add defragmentation support

[Christian König]

Am 16.02.24 um 15:47 schrieb Matthew Auld:

On 16/02/2024 14:02, Christian König wrote:

Am 16.02.24 um 14:21 schrieb Matthew Auld:

On 16/02/2024 12:33, Christian König wrote:

Am 16.02.24 um 13:23 schrieb Matthew Auld:

On 08/02/2024 15:50, Arunpravin Paneer Selvam wrote:

Add a function to support defragmentation.

v1: Defragment the memory beginning from min_order
 till the required memory space is available.

Signed-off-by: Arunpravin Paneer Selvam 


Suggested-by: Matthew Auld 
---
  drivers/gpu/drm/drm_buddy.c | 67 
+++--

  include/drm/drm_buddy.h |  3 ++


No users?


Other question is how can a buddy allocator fragment in the first 
place?


The fragmentation is due to pages now being tracked as dirty/clear. 
Should the allocator merge together a page that is dirty with a page 
that is cleared? When should it do that? User wants to be able to 
keep the two separate if possible. For example, freeing one single 
dirty page can dirty a huge swathe of your already cleared pages if 
they are merged together. Or do you have some some other ideas here?


Sorry, that was not what I meant. I should probably have been clearer.

That dirty and clean pages are now kept separated is obvious, but why 
do you need to de-fragment them at some point?


Ah, right. At the very least we need to do something similar to this 
at fini(), just to ensure we properly merge everything back together 
so we can correctly tear down the mm. Outside of that the thinking was 
that it might be useful to call when allocating larger min page-sizes. 
You might now be failing the allocation due to fragmentation, and so 
in some cases might be better off running some kind of defrag step 
first, instead of failing the allocation and trying to evict stuff. 
Anyway, if that is not a concern for amdgpu, then we just need to 
handle the fini() case and can keep this internal.


Ah, yes that makes more sense.

So you basically force merge the pages before fini to avoid warnings 
that the buddy isn't empty.


Thanks, that answers my curiosity. But I unfortunately still don't have 
time to dig deep enough into this for a review.


Thanks,
Christian.





Christian.





Christian.




  2 files changed, 59 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_buddy.c 
b/drivers/gpu/drm/drm_buddy.c

index 33ad0cfbd54c..fac423d2cb73 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -276,10 +276,12 @@ drm_get_buddy(struct drm_buddy_block *block)
  }
  EXPORT_SYMBOL(drm_get_buddy);
  -static void __drm_buddy_free(struct drm_buddy *mm,
- struct drm_buddy_block *block)
+static unsigned int __drm_buddy_free(struct drm_buddy *mm,
+ struct drm_buddy_block *block,
+ bool defrag)
  {
  struct drm_buddy_block *parent;
+    unsigned int order;
    while ((parent = block->parent)) {
  struct drm_buddy_block *buddy;
@@ -289,12 +291,14 @@ static void __drm_buddy_free(struct 
drm_buddy *mm,

  if (!drm_buddy_block_is_free(buddy))
  break;
  -    if (drm_buddy_block_is_clear(block) !=
-    drm_buddy_block_is_clear(buddy))
-    break;
+    if (!defrag) {
+    if (drm_buddy_block_is_clear(block) !=
+    drm_buddy_block_is_clear(buddy))
+    break;
  -    if (drm_buddy_block_is_clear(block))
-    mark_cleared(parent);
+    if (drm_buddy_block_is_clear(block))
+    mark_cleared(parent);
+    }


Maybe check if the two blocks are incompatible and chuck a warn if 
they are not? Main thing is not to hide issues with split blocks 
that should have been merged before.



list_del(>link);
  @@ -304,8 +308,49 @@ static void __drm_buddy_free(struct 
drm_buddy *mm,

  block = parent;
  }
  +    order = drm_buddy_block_order(block);
  mark_free(mm, block);
+
+    return order;
+}
+
+/**
+ * drm_buddy_defrag - Defragmentation routine
+ *
+ * @mm: DRM buddy manager
+ * @min_order: minimum order in the freelist to begin
+ * the defragmentation process
+ *
+ * Driver calls the defragmentation function when the
+ * requested memory allocation returns -ENOSPC.
+ */
+void drm_buddy_defrag(struct drm_buddy *mm,
+  unsigned int min_order)


Just wondering if we need "full defag" also? We would probably 
need to call this at fini() anyway.



+{
+    struct drm_buddy_block *block;
+    struct list_head *list;
+    unsigned int order;
+    int i;
+
+    if (min_order > mm->max_order)
+    return;
+
+    for (i = min_order - 1; i >= 0; i--) {


Need to be careful with min_order = 0 ?


+    list = >free_list[i];
+    if (list_empty(list))
+    continue;
+
+    list_for_each_entry_reverse(block, list, link) {


Don't we need the safe_reverse() variant here, since this is 
removing from the list?



+    if (!block->parent)
+    continue;
+
+    

Re: [PATCH] drm/amd: Only allow one entity to control ABM

[Harry Wentland]

On 2024-02-16 09:47, Christian König wrote:
> Am 16.02.24 um 15:42 schrieb Mario Limonciello:
>> On 2/16/2024 08:38, Christian König wrote:
>>> Am 16.02.24 um 15:07 schrieb Mario Limonciello:
 By exporting ABM to sysfs it's possible that DRM master and software
 controlling the sysfs file fight over the value programmed for ABM.

 Adjust the module parameter behavior to control who control ABM:
 -2: DRM
 -1: sysfs (IE via software like power-profiles-daemon)
>>>
>>> Well that sounds extremely awkward. Why should a power-profiles-deamon has 
>>> control over the panel power saving features?
>>>
>>> I mean we are talking about things like reducing backlight level when the 
>>> is inactivity, don't we?
>>
>> We're talking about activating the ABM algorithm when the system is in power 
>> saving mode; not from inactivity.  This allows the user to squeeze out some 
>> extra power "just" in that situation.
>>
>> But given the comments on the other patch, I tend to agree with Harry's 
>> proposal instead that we just drop the DRM property entirely as there are no 
>> consumers of it.
> 
> Yeah, but even then the design to let this be controlled by an userspace 
> deamon is questionable. Stuff like that is handled inside the kernel and not 
> exposed to userspace usually.
> 

I think we'll need a bit in our kernel docs describing ABM. Assumptions around 
what it is and does seem to lead to confusion.

The thing is that ABM has a visual impact that not all users like. It would 
make sense for users to be able to change the ABM level as desired, and/or 
configure their power profiles to select a certain ABM level.

ABM will reduce the backlight and compensate by adjusting brightness and 
contrast of the image. It has 5 levels: 0, 1, 2, 3, 4. 0 means off. 4 means 
maximum backlight reduction. IMO, 1 and 2 look okay. 3 and 4 can be quite 
impactful, both to power and visual fidelity.

Harry

> Regards,
> Christian.
> 
>>
>>>
>>> Regards,
>>> Christian.
>>>
 0-4: User via command line

 Also introduce a Kconfig option that allows distributions to choose
 the default policy that is appropriate for them.

 Fixes: f97e4303da16 ("drm/amd/display: add panel_power_savings sysfs entry 
 to eDP connectors")
 Signed-off-by: Mario Limonciello 
 ---
 Cc: Hamza Mahfooz 
 Cc: Harry Wentland 
 Cc: Sun peng (Leo) Li 
   drivers/gpu/drm/amd/amdgpu/Kconfig    | 72 +++
   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 23 +++---
   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  6 +-
   3 files changed, 90 insertions(+), 11 deletions(-)

 diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig 
 b/drivers/gpu/drm/amd/amdgpu/Kconfig
 index 22d88f8ef527..2ab57ccf6f21 100644
 --- a/drivers/gpu/drm/amd/amdgpu/Kconfig
 +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig
 @@ -80,6 +80,78 @@ config DRM_AMDGPU_WERROR
     Add -Werror to the build flags for amdgpu.ko.
     Only enable this if you are warning code for amdgpu.ko.
 +choice
 +    prompt "Amdgpu panel power Savings"
 +    default AMDGPU_SYSFS_ABM
 +    help
 +    Control the default behavior for adaptive panel power savings.
 +
 +    Panel power savings features will sacrifice color accuracy
 +    in exchange for power savings.
 +
 +    This can be configured for:
 +    - dynamic control by the DRM master
 +    - dynamic control by sysfs nodes
 +    - statically by the user at kernel compile time
 +
 +    This value can also be overridden by the amdgpu.abmlevel
 +    module parameter.
 +
 +config AMDGPU_DRM_ABM
 +    bool "DRM Master control"
 +    help
 +    Export a property called 'abm_level' that can be
 +    manipulated by the DRM master for supported hardware.
 +
 +config AMDGPU_SYSFS_ABM
 +    bool "sysfs control"
 +    help
 +    Export a sysfs file 'panel_power_savings' that can be
 +    manipulated by userspace for supported hardware.
 +
 +config AMDGPU_HARDCODE_ABM0
 +    bool "No Panel power savings"
 +    help
 +    Disable panel power savings.
 +    It can only overridden by the kernel command line.
 +
 +config AMDGPU_HARDCODE_ABM1
 +    bool "25% Panel power savings"
 +    help
 +    Set the ABM panel power savings algorithm to 25%.
 +    It can only overridden by the kernel command line.
 +
 +config AMDGPU_HARDCODE_ABM2
 +    bool "50% Panel power savings"
 +    help
 +    Set the ABM panel power savings algorithm to 50%.
 +    It can only overridden by the kernel command line.
 +
 +config AMDGPU_HARDCODE_ABM3
 +    bool "75% Panel power savings"
 +    help
 +    Set the ABM panel power savings algorithm to 75%.
 +    It can only overridden 

Re: [PATCH v6 3/3] drm/buddy: Add defragmentation support

[Matthew Auld]

On 16/02/2024 14:02, Christian König wrote:

Am 16.02.24 um 14:21 schrieb Matthew Auld:

On 16/02/2024 12:33, Christian König wrote:

Am 16.02.24 um 13:23 schrieb Matthew Auld:

On 08/02/2024 15:50, Arunpravin Paneer Selvam wrote:

Add a function to support defragmentation.

v1: Defragment the memory beginning from min_order
 till the required memory space is available.

Signed-off-by: Arunpravin Paneer Selvam 


Suggested-by: Matthew Auld 
---
  drivers/gpu/drm/drm_buddy.c | 67 
+++--

  include/drm/drm_buddy.h |  3 ++


No users?


Other question is how can a buddy allocator fragment in the first place?


The fragmentation is due to pages now being tracked as dirty/clear. 
Should the allocator merge together a page that is dirty with a page 
that is cleared? When should it do that? User wants to be able to keep 
the two separate if possible. For example, freeing one single dirty 
page can dirty a huge swathe of your already cleared pages if they are 
merged together. Or do you have some some other ideas here?


Sorry, that was not what I meant. I should probably have been clearer.

That dirty and clean pages are now kept separated is obvious, but why do 
you need to de-fragment them at some point?


Ah, right. At the very least we need to do something similar to this at 
fini(), just to ensure we properly merge everything back together so we 
can correctly tear down the mm. Outside of that the thinking was that it 
might be useful to call when allocating larger min page-sizes. You might 
now be failing the allocation due to fragmentation, and so in some cases 
might be better off running some kind of defrag step first, instead of 
failing the allocation and trying to evict stuff. Anyway, if that is not 
a concern for amdgpu, then we just need to handle the fini() case and 
can keep this internal.




Christian.





Christian.




  2 files changed, 59 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 33ad0cfbd54c..fac423d2cb73 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -276,10 +276,12 @@ drm_get_buddy(struct drm_buddy_block *block)
  }
  EXPORT_SYMBOL(drm_get_buddy);
  -static void __drm_buddy_free(struct drm_buddy *mm,
- struct drm_buddy_block *block)
+static unsigned int __drm_buddy_free(struct drm_buddy *mm,
+ struct drm_buddy_block *block,
+ bool defrag)
  {
  struct drm_buddy_block *parent;
+    unsigned int order;
    while ((parent = block->parent)) {
  struct drm_buddy_block *buddy;
@@ -289,12 +291,14 @@ static void __drm_buddy_free(struct drm_buddy 
*mm,

  if (!drm_buddy_block_is_free(buddy))
  break;
  -    if (drm_buddy_block_is_clear(block) !=
-    drm_buddy_block_is_clear(buddy))
-    break;
+    if (!defrag) {
+    if (drm_buddy_block_is_clear(block) !=
+    drm_buddy_block_is_clear(buddy))
+    break;
  -    if (drm_buddy_block_is_clear(block))
-    mark_cleared(parent);
+    if (drm_buddy_block_is_clear(block))
+    mark_cleared(parent);
+    }


Maybe check if the two blocks are incompatible and chuck a warn if 
they are not? Main thing is not to hide issues with split blocks 
that should have been merged before.



list_del(>link);
  @@ -304,8 +308,49 @@ static void __drm_buddy_free(struct 
drm_buddy *mm,

  block = parent;
  }
  +    order = drm_buddy_block_order(block);
  mark_free(mm, block);
+
+    return order;
+}
+
+/**
+ * drm_buddy_defrag - Defragmentation routine
+ *
+ * @mm: DRM buddy manager
+ * @min_order: minimum order in the freelist to begin
+ * the defragmentation process
+ *
+ * Driver calls the defragmentation function when the
+ * requested memory allocation returns -ENOSPC.
+ */
+void drm_buddy_defrag(struct drm_buddy *mm,
+  unsigned int min_order)


Just wondering if we need "full defag" also? We would probably need 
to call this at fini() anyway.



+{
+    struct drm_buddy_block *block;
+    struct list_head *list;
+    unsigned int order;
+    int i;
+
+    if (min_order > mm->max_order)
+    return;
+
+    for (i = min_order - 1; i >= 0; i--) {


Need to be careful with min_order = 0 ?


+    list = >free_list[i];
+    if (list_empty(list))
+    continue;
+
+    list_for_each_entry_reverse(block, list, link) {


Don't we need the safe_reverse() variant here, since this is 
removing from the list?



+    if (!block->parent)
+    continue;
+
+    order = __drm_buddy_free(mm, block, 1);
+    if (order >= min_order)
+    return;
+    }
+    }
  }
+EXPORT_SYMBOL(drm_buddy_defrag);
    /**
   * drm_buddy_free_block - free a block
@@ -321,7 +366,7 @@ void drm_buddy_free_block(struct drm_buddy *mm,
  if (drm_buddy_block_is_clear(block))
  

Re: [PATCH] drm/amd: Only allow one entity to control ABM

[Christian König]

Am 16.02.24 um 15:42 schrieb Mario Limonciello:

On 2/16/2024 08:38, Christian König wrote:

Am 16.02.24 um 15:07 schrieb Mario Limonciello:

By exporting ABM to sysfs it's possible that DRM master and software
controlling the sysfs file fight over the value programmed for ABM.

Adjust the module parameter behavior to control who control ABM:
-2: DRM
-1: sysfs (IE via software like power-profiles-daemon)


Well that sounds extremely awkward. Why should a 
power-profiles-deamon has control over the panel power saving features?


I mean we are talking about things like reducing backlight level when 
the is inactivity, don't we?


We're talking about activating the ABM algorithm when the system is in 
power saving mode; not from inactivity.  This allows the user to 
squeeze out some extra power "just" in that situation.


But given the comments on the other patch, I tend to agree with 
Harry's proposal instead that we just drop the DRM property entirely 
as there are no consumers of it.


Yeah, but even then the design to let this be controlled by an userspace 
deamon is questionable. Stuff like that is handled inside the kernel and 
not exposed to userspace usually.


Regards,
Christian.





Regards,
Christian.


0-4: User via command line

Also introduce a Kconfig option that allows distributions to choose
the default policy that is appropriate for them.

Fixes: f97e4303da16 ("drm/amd/display: add panel_power_savings sysfs 
entry to eDP connectors")

Signed-off-by: Mario Limonciello 
---
Cc: Hamza Mahfooz 
Cc: Harry Wentland 
Cc: Sun peng (Leo) Li 
  drivers/gpu/drm/amd/amdgpu/Kconfig    | 72 
+++

  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 23 +++---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  6 +-
  3 files changed, 90 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig 
b/drivers/gpu/drm/amd/amdgpu/Kconfig

index 22d88f8ef527..2ab57ccf6f21 100644
--- a/drivers/gpu/drm/amd/amdgpu/Kconfig
+++ b/drivers/gpu/drm/amd/amdgpu/Kconfig
@@ -80,6 +80,78 @@ config DRM_AMDGPU_WERROR
    Add -Werror to the build flags for amdgpu.ko.
    Only enable this if you are warning code for amdgpu.ko.
+choice
+    prompt "Amdgpu panel power Savings"
+    default AMDGPU_SYSFS_ABM
+    help
+    Control the default behavior for adaptive panel power savings.
+
+    Panel power savings features will sacrifice color accuracy
+    in exchange for power savings.
+
+    This can be configured for:
+    - dynamic control by the DRM master
+    - dynamic control by sysfs nodes
+    - statically by the user at kernel compile time
+
+    This value can also be overridden by the amdgpu.abmlevel
+    module parameter.
+
+config AMDGPU_DRM_ABM
+    bool "DRM Master control"
+    help
+    Export a property called 'abm_level' that can be
+    manipulated by the DRM master for supported hardware.
+
+config AMDGPU_SYSFS_ABM
+    bool "sysfs control"
+    help
+    Export a sysfs file 'panel_power_savings' that can be
+    manipulated by userspace for supported hardware.
+
+config AMDGPU_HARDCODE_ABM0
+    bool "No Panel power savings"
+    help
+    Disable panel power savings.
+    It can only overridden by the kernel command line.
+
+config AMDGPU_HARDCODE_ABM1
+    bool "25% Panel power savings"
+    help
+    Set the ABM panel power savings algorithm to 25%.
+    It can only overridden by the kernel command line.
+
+config AMDGPU_HARDCODE_ABM2
+    bool "50% Panel power savings"
+    help
+    Set the ABM panel power savings algorithm to 50%.
+    It can only overridden by the kernel command line.
+
+config AMDGPU_HARDCODE_ABM3
+    bool "75% Panel power savings"
+    help
+    Set the ABM panel power savings algorithm to 75%.
+    It can only overridden by the kernel command line.
+
+config AMDGPU_HARDCODE_ABM4
+    bool "100% Panel power savings"
+    help
+    Set the ABM panel power savings algorithm to 100%.
+    It can only overridden by the kernel command line.
+endchoice
+
+config AMDGPU_ABM_POLICY
+    int
+    default -2 if AMDGPU_DRM_ABM
+    default -1 if AMDGPU_SYSFS_ABM
+    default 0 if AMDGPU_HARDCODE_ABM0
+    default 1 if AMDGPU_HARDCODE_ABM1
+    default 2 if AMDGPU_HARDCODE_ABM2
+    default 3 if AMDGPU_HARDCODE_ABM3
+    default 4 if AMDGPU_HARDCODE_ABM4
+    default -1
+
+
  source "drivers/gpu/drm/amd/acp/Kconfig"
  source "drivers/gpu/drm/amd/display/Kconfig"
  source "drivers/gpu/drm/amd/amdkfd/Kconfig"
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c

index af7fae7907d7..00d6c8b58716 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -844,17 +844,24 @@ module_param_named(visualconfirm, 
amdgpu_dc_visual_confirm, uint, 0444);

   * DOC: abmlevel (uint)
   * Override the default ABM (Adaptive Backlight Management) level 
used for DC

   * enabled hardware. 

Re: [PATCH] drm/amd: Only allow one entity to control ABM

[Mario Limonciello]

On 2/16/2024 08:38, Christian König wrote:

Am 16.02.24 um 15:07 schrieb Mario Limonciello:

By exporting ABM to sysfs it's possible that DRM master and software
controlling the sysfs file fight over the value programmed for ABM.

Adjust the module parameter behavior to control who control ABM:
-2: DRM
-1: sysfs (IE via software like power-profiles-daemon)


Well that sounds extremely awkward. Why should a power-profiles-deamon 
has control over the panel power saving features?


I mean we are talking about things like reducing backlight level when 
the is inactivity, don't we?


We're talking about activating the ABM algorithm when the system is in 
power saving mode; not from inactivity.  This allows the user to squeeze 
out some extra power "just" in that situation.


But given the comments on the other patch, I tend to agree with Harry's 
proposal instead that we just drop the DRM property entirely as there 
are no consumers of it.




Regards,
Christian.


0-4: User via command line

Also introduce a Kconfig option that allows distributions to choose
the default policy that is appropriate for them.

Fixes: f97e4303da16 ("drm/amd/display: add panel_power_savings sysfs 
entry to eDP connectors")

Signed-off-by: Mario Limonciello 
---
Cc: Hamza Mahfooz 
Cc: Harry Wentland 
Cc: Sun peng (Leo) Li 
  drivers/gpu/drm/amd/amdgpu/Kconfig    | 72 +++
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 23 +++---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  6 +-
  3 files changed, 90 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig 
b/drivers/gpu/drm/amd/amdgpu/Kconfig

index 22d88f8ef527..2ab57ccf6f21 100644
--- a/drivers/gpu/drm/amd/amdgpu/Kconfig
+++ b/drivers/gpu/drm/amd/amdgpu/Kconfig
@@ -80,6 +80,78 @@ config DRM_AMDGPU_WERROR
    Add -Werror to the build flags for amdgpu.ko.
    Only enable this if you are warning code for amdgpu.ko.
+choice
+    prompt "Amdgpu panel power Savings"
+    default AMDGPU_SYSFS_ABM
+    help
+    Control the default behavior for adaptive panel power savings.
+
+    Panel power savings features will sacrifice color accuracy
+    in exchange for power savings.
+
+    This can be configured for:
+    - dynamic control by the DRM master
+    - dynamic control by sysfs nodes
+    - statically by the user at kernel compile time
+
+    This value can also be overridden by the amdgpu.abmlevel
+    module parameter.
+
+config AMDGPU_DRM_ABM
+    bool "DRM Master control"
+    help
+    Export a property called 'abm_level' that can be
+    manipulated by the DRM master for supported hardware.
+
+config AMDGPU_SYSFS_ABM
+    bool "sysfs control"
+    help
+    Export a sysfs file 'panel_power_savings' that can be
+    manipulated by userspace for supported hardware.
+
+config AMDGPU_HARDCODE_ABM0
+    bool "No Panel power savings"
+    help
+    Disable panel power savings.
+    It can only overridden by the kernel command line.
+
+config AMDGPU_HARDCODE_ABM1
+    bool "25% Panel power savings"
+    help
+    Set the ABM panel power savings algorithm to 25%.
+    It can only overridden by the kernel command line.
+
+config AMDGPU_HARDCODE_ABM2
+    bool "50% Panel power savings"
+    help
+    Set the ABM panel power savings algorithm to 50%.
+    It can only overridden by the kernel command line.
+
+config AMDGPU_HARDCODE_ABM3
+    bool "75% Panel power savings"
+    help
+    Set the ABM panel power savings algorithm to 75%.
+    It can only overridden by the kernel command line.
+
+config AMDGPU_HARDCODE_ABM4
+    bool "100% Panel power savings"
+    help
+    Set the ABM panel power savings algorithm to 100%.
+    It can only overridden by the kernel command line.
+endchoice
+
+config AMDGPU_ABM_POLICY
+    int
+    default -2 if AMDGPU_DRM_ABM
+    default -1 if AMDGPU_SYSFS_ABM
+    default 0 if AMDGPU_HARDCODE_ABM0
+    default 1 if AMDGPU_HARDCODE_ABM1
+    default 2 if AMDGPU_HARDCODE_ABM2
+    default 3 if AMDGPU_HARDCODE_ABM3
+    default 4 if AMDGPU_HARDCODE_ABM4
+    default -1
+
+
  source "drivers/gpu/drm/amd/acp/Kconfig"
  source "drivers/gpu/drm/amd/display/Kconfig"
  source "drivers/gpu/drm/amd/amdkfd/Kconfig"
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c

index af7fae7907d7..00d6c8b58716 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -844,17 +844,24 @@ module_param_named(visualconfirm, 
amdgpu_dc_visual_confirm, uint, 0444);

   * DOC: abmlevel (uint)
   * Override the default ABM (Adaptive Backlight Management) level 
used for DC

   * enabled hardware. Requires DMCU to be supported and loaded.
- * Valid levels are 0-4. A value of 0 indicates that ABM should be 
disabled by
- * default. Values 1-4 control the maximum allowable brightness 
reduction via
- * the ABM algorithm, with 1 being the least reduction 

Re: [PATCH] drm/amd: Only allow one entity to control ABM

[Christian König]

Am 16.02.24 um 15:07 schrieb Mario Limonciello:

By exporting ABM to sysfs it's possible that DRM master and software
controlling the sysfs file fight over the value programmed for ABM.

Adjust the module parameter behavior to control who control ABM:
-2: DRM
-1: sysfs (IE via software like power-profiles-daemon)


Well that sounds extremely awkward. Why should a power-profiles-deamon 
has control over the panel power saving features?


I mean we are talking about things like reducing backlight level when 
the is inactivity, don't we?


Regards,
Christian.


0-4: User via command line

Also introduce a Kconfig option that allows distributions to choose
the default policy that is appropriate for them.

Fixes: f97e4303da16 ("drm/amd/display: add panel_power_savings sysfs entry to eDP 
connectors")
Signed-off-by: Mario Limonciello 
---
Cc: Hamza Mahfooz 
Cc: Harry Wentland 
Cc: Sun peng (Leo) Li 
  drivers/gpu/drm/amd/amdgpu/Kconfig| 72 +++
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 23 +++---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  6 +-
  3 files changed, 90 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig 
b/drivers/gpu/drm/amd/amdgpu/Kconfig
index 22d88f8ef527..2ab57ccf6f21 100644
--- a/drivers/gpu/drm/amd/amdgpu/Kconfig
+++ b/drivers/gpu/drm/amd/amdgpu/Kconfig
@@ -80,6 +80,78 @@ config DRM_AMDGPU_WERROR
  Add -Werror to the build flags for amdgpu.ko.
  Only enable this if you are warning code for amdgpu.ko.
  
+choice

+   prompt "Amdgpu panel power Savings"
+   default AMDGPU_SYSFS_ABM
+   help
+   Control the default behavior for adaptive panel power savings.
+
+   Panel power savings features will sacrifice color accuracy
+   in exchange for power savings.
+
+   This can be configured for:
+   - dynamic control by the DRM master
+   - dynamic control by sysfs nodes
+   - statically by the user at kernel compile time
+
+   This value can also be overridden by the amdgpu.abmlevel
+   module parameter.
+
+config AMDGPU_DRM_ABM
+   bool "DRM Master control"
+   help
+   Export a property called 'abm_level' that can be
+   manipulated by the DRM master for supported hardware.
+
+config AMDGPU_SYSFS_ABM
+   bool "sysfs control"
+   help
+   Export a sysfs file 'panel_power_savings' that can be
+   manipulated by userspace for supported hardware.
+
+config AMDGPU_HARDCODE_ABM0
+   bool "No Panel power savings"
+   help
+   Disable panel power savings.
+   It can only overridden by the kernel command line.
+
+config AMDGPU_HARDCODE_ABM1
+   bool "25% Panel power savings"
+   help
+   Set the ABM panel power savings algorithm to 25%.
+   It can only overridden by the kernel command line.
+
+config AMDGPU_HARDCODE_ABM2
+   bool "50% Panel power savings"
+   help
+   Set the ABM panel power savings algorithm to 50%.
+   It can only overridden by the kernel command line.
+
+config AMDGPU_HARDCODE_ABM3
+   bool "75% Panel power savings"
+   help
+   Set the ABM panel power savings algorithm to 75%.
+   It can only overridden by the kernel command line.
+
+config AMDGPU_HARDCODE_ABM4
+   bool "100% Panel power savings"
+   help
+   Set the ABM panel power savings algorithm to 100%.
+   It can only overridden by the kernel command line.
+endchoice
+
+config AMDGPU_ABM_POLICY
+   int
+   default -2 if AMDGPU_DRM_ABM
+   default -1 if AMDGPU_SYSFS_ABM
+   default 0 if AMDGPU_HARDCODE_ABM0
+   default 1 if AMDGPU_HARDCODE_ABM1
+   default 2 if AMDGPU_HARDCODE_ABM2
+   default 3 if AMDGPU_HARDCODE_ABM3
+   default 4 if AMDGPU_HARDCODE_ABM4
+   default -1
+
+
  source "drivers/gpu/drm/amd/acp/Kconfig"
  source "drivers/gpu/drm/amd/display/Kconfig"
  source "drivers/gpu/drm/amd/amdkfd/Kconfig"
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index af7fae7907d7..00d6c8b58716 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -844,17 +844,24 @@ module_param_named(visualconfirm, 
amdgpu_dc_visual_confirm, uint, 0444);
   * DOC: abmlevel (uint)
   * Override the default ABM (Adaptive Backlight Management) level used for DC
   * enabled hardware. Requires DMCU to be supported and loaded.
- * Valid levels are 0-4. A value of 0 indicates that ABM should be disabled by
- * default. Values 1-4 control the maximum allowable brightness reduction via
- * the ABM algorithm, with 1 being the least reduction and 4 being the most
- * reduction.
+ * Valid levels are -2 through 4.
   *
- * Defaults to -1, or disabled. Userspace can only override this level after
- * boot if it's 

Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors

[Harry Wentland]

On 2024-02-16 03:19, Pekka Paalanen wrote:
> On Fri, 2 Feb 2024 10:28:35 -0500
> Hamza Mahfooz  wrote:
> 
>> We want programs besides the compositor to be able to enable or disable
>> panel power saving features.
> 
> Could you also explain why, in the commit message, please?
> 
> It is unexpected for arbitrary programs to be able to override the KMS
> client, and certainly new ways to do so should not be added without an
> excellent justification.
> 
> Maybe debugfs would be more appropriate if the purpose is only testing
> rather than production environments?
> 
>> However, since they are currently only
>> configurable through DRM properties, that isn't possible. So, to remedy
>> that issue introduce a new "panel_power_savings" sysfs attribute.
> 
> When the DRM property was added, what was used as the userspace to
> prove its workings?
> 

I don't think there ever was a userspace implementation and doubt any
exists today. Part of that is on me. In hindsight, the KMS prop should
have never gone upstream.

I suggest we drop the KMS prop entirely.

As for the color accuracy topic, I think it is important that compositors
can have full control over that if needed, while it's also important
for HW vendors to optimize for power when absolute color accuracy is not
needed. An average end-user writing code or working on their slides
would rather have a longer battery life than a perfectly color-accurate
display. We should probably think of a solution that can support both
use-cases.

Harry

> 
> Thanks,
> pq
> 
>>
>> Cc: Mario Limonciello 
>> Signed-off-by: Hamza Mahfooz 
>> ---
>> v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
>> commit when setting the value, call sysfs_remove_group() in
>> amdgpu_dm_connector_unregister() and add some documentation.
>> ---
>>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++
>>  1 file changed, 76 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index 8590c9f1dda6..3c62489d03dc 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct 
>> drm_connector *connector,
>>  return ret;
>>  }
>>  
>> +/**
>> + * DOC: panel power savings
>> + *
>> + * The display manager allows you to set your desired **panel power 
>> savings**
>> + * level (between 0-4, with 0 representing off), e.g. using the following::
>> + *
>> + *   # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
>> + *
>> + * Modifying this value can have implications on color accuracy, so tread
>> + * carefully.
>> + */
>> +
>> +static ssize_t panel_power_savings_show(struct device *device,
>> +struct device_attribute *attr,
>> +char *buf)
>> +{
>> +struct drm_connector *connector = dev_get_drvdata(device);
>> +struct drm_device *dev = connector->dev;
>> +u8 val;
>> +
>> +drm_modeset_lock(>mode_config.connection_mutex, NULL);
>> +val = to_dm_connector_state(connector->state)->abm_level ==
>> +ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
>> +to_dm_connector_state(connector->state)->abm_level;
>> +drm_modeset_unlock(>mode_config.connection_mutex);
>> +
>> +return sysfs_emit(buf, "%u\n", val);
>> +}
>> +
>> +static ssize_t panel_power_savings_store(struct device *device,
>> + struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> +struct drm_connector *connector = dev_get_drvdata(device);
>> +struct drm_device *dev = connector->dev;
>> +long val;
>> +int ret;
>> +
>> +ret = kstrtol(buf, 0, );
>> +
>> +if (ret)
>> +return ret;
>> +
>> +if (val < 0 || val > 4)
>> +return -EINVAL;
>> +
>> +drm_modeset_lock(>mode_config.connection_mutex, NULL);
>> +to_dm_connector_state(connector->state)->abm_level = val ?:
>> +ABM_LEVEL_IMMEDIATE_DISABLE;
>> +drm_modeset_unlock(>mode_config.connection_mutex);
>> +
>> +drm_kms_helper_hotplug_event(dev);
>> +
>> +return count;
>> +}
>> +
>> +static DEVICE_ATTR_RW(panel_power_savings);
>> +
>> +static struct attribute *amdgpu_attrs[] = {
>> +_attr_panel_power_savings.attr,
>> +NULL
>> +};
>> +
>> +static const struct attribute_group amdgpu_group = {
>> +.name = "amdgpu",
>> +.attrs = amdgpu_attrs
>> +};
>> +
>>  static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
>>  {
>>  struct amdgpu_dm_connector *amdgpu_dm_connector = 
>> to_amdgpu_dm_connector(connector);
>>  
>> +sysfs_remove_group(>kdev->kobj, _group);
>>  drm_dp_aux_unregister(_dm_connector->dm_dp_aux.aux);
>>  }
>>  
>> @@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct 
>> 

[PATCH] drm/amd: Only allow one entity to control ABM

[Mario Limonciello]

By exporting ABM to sysfs it's possible that DRM master and software
controlling the sysfs file fight over the value programmed for ABM.

Adjust the module parameter behavior to control who control ABM:
-2: DRM
-1: sysfs (IE via software like power-profiles-daemon)
0-4: User via command line

Also introduce a Kconfig option that allows distributions to choose
the default policy that is appropriate for them.

Fixes: f97e4303da16 ("drm/amd/display: add panel_power_savings sysfs entry to 
eDP connectors")
Signed-off-by: Mario Limonciello 
---
Cc: Hamza Mahfooz 
Cc: Harry Wentland 
Cc: Sun peng (Leo) Li 
 drivers/gpu/drm/amd/amdgpu/Kconfig| 72 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 23 +++---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  6 +-
 3 files changed, 90 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig 
b/drivers/gpu/drm/amd/amdgpu/Kconfig
index 22d88f8ef527..2ab57ccf6f21 100644
--- a/drivers/gpu/drm/amd/amdgpu/Kconfig
+++ b/drivers/gpu/drm/amd/amdgpu/Kconfig
@@ -80,6 +80,78 @@ config DRM_AMDGPU_WERROR
  Add -Werror to the build flags for amdgpu.ko.
  Only enable this if you are warning code for amdgpu.ko.
 
+choice
+   prompt "Amdgpu panel power Savings"
+   default AMDGPU_SYSFS_ABM
+   help
+   Control the default behavior for adaptive panel power savings.
+
+   Panel power savings features will sacrifice color accuracy
+   in exchange for power savings.
+
+   This can be configured for:
+   - dynamic control by the DRM master
+   - dynamic control by sysfs nodes
+   - statically by the user at kernel compile time
+
+   This value can also be overridden by the amdgpu.abmlevel
+   module parameter.
+
+config AMDGPU_DRM_ABM
+   bool "DRM Master control"
+   help
+   Export a property called 'abm_level' that can be
+   manipulated by the DRM master for supported hardware.
+
+config AMDGPU_SYSFS_ABM
+   bool "sysfs control"
+   help
+   Export a sysfs file 'panel_power_savings' that can be
+   manipulated by userspace for supported hardware.
+
+config AMDGPU_HARDCODE_ABM0
+   bool "No Panel power savings"
+   help
+   Disable panel power savings.
+   It can only overridden by the kernel command line.
+
+config AMDGPU_HARDCODE_ABM1
+   bool "25% Panel power savings"
+   help
+   Set the ABM panel power savings algorithm to 25%.
+   It can only overridden by the kernel command line.
+
+config AMDGPU_HARDCODE_ABM2
+   bool "50% Panel power savings"
+   help
+   Set the ABM panel power savings algorithm to 50%.
+   It can only overridden by the kernel command line.
+
+config AMDGPU_HARDCODE_ABM3
+   bool "75% Panel power savings"
+   help
+   Set the ABM panel power savings algorithm to 75%.
+   It can only overridden by the kernel command line.
+
+config AMDGPU_HARDCODE_ABM4
+   bool "100% Panel power savings"
+   help
+   Set the ABM panel power savings algorithm to 100%.
+   It can only overridden by the kernel command line.
+endchoice
+
+config AMDGPU_ABM_POLICY
+   int
+   default -2 if AMDGPU_DRM_ABM
+   default -1 if AMDGPU_SYSFS_ABM
+   default 0 if AMDGPU_HARDCODE_ABM0
+   default 1 if AMDGPU_HARDCODE_ABM1
+   default 2 if AMDGPU_HARDCODE_ABM2
+   default 3 if AMDGPU_HARDCODE_ABM3
+   default 4 if AMDGPU_HARDCODE_ABM4
+   default -1
+
+
 source "drivers/gpu/drm/amd/acp/Kconfig"
 source "drivers/gpu/drm/amd/display/Kconfig"
 source "drivers/gpu/drm/amd/amdkfd/Kconfig"
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index af7fae7907d7..00d6c8b58716 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -844,17 +844,24 @@ module_param_named(visualconfirm, 
amdgpu_dc_visual_confirm, uint, 0444);
  * DOC: abmlevel (uint)
  * Override the default ABM (Adaptive Backlight Management) level used for DC
  * enabled hardware. Requires DMCU to be supported and loaded.
- * Valid levels are 0-4. A value of 0 indicates that ABM should be disabled by
- * default. Values 1-4 control the maximum allowable brightness reduction via
- * the ABM algorithm, with 1 being the least reduction and 4 being the most
- * reduction.
+ * Valid levels are -2 through 4.
  *
- * Defaults to -1, or disabled. Userspace can only override this level after
- * boot if it's set to auto.
+ *  -2: indicates that ABM should be controlled by DRM property 'abm_level.
+ *  -1: indicates that ABM should be controlled by the sysfs file
+ *  'panel_power_savings'.
+ *   0: indicates that ABM should be disabled.
+ * 1-4: control the maximum allowable brightness reduction via
+ *  the 

Re: [PATCH v6 3/3] drm/buddy: Add defragmentation support

[Christian König]

Am 16.02.24 um 14:21 schrieb Matthew Auld:

On 16/02/2024 12:33, Christian König wrote:

Am 16.02.24 um 13:23 schrieb Matthew Auld:

On 08/02/2024 15:50, Arunpravin Paneer Selvam wrote:

Add a function to support defragmentation.

v1: Defragment the memory beginning from min_order
 till the required memory space is available.

Signed-off-by: Arunpravin Paneer Selvam 


Suggested-by: Matthew Auld 
---
  drivers/gpu/drm/drm_buddy.c | 67 
+++--

  include/drm/drm_buddy.h |  3 ++


No users?


Other question is how can a buddy allocator fragment in the first place?


The fragmentation is due to pages now being tracked as dirty/clear. 
Should the allocator merge together a page that is dirty with a page 
that is cleared? When should it do that? User wants to be able to keep 
the two separate if possible. For example, freeing one single dirty 
page can dirty a huge swathe of your already cleared pages if they are 
merged together. Or do you have some some other ideas here?


Sorry, that was not what I meant. I should probably have been clearer.

That dirty and clean pages are now kept separated is obvious, but why do 
you need to de-fragment them at some point?


Christian.





Christian.




  2 files changed, 59 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 33ad0cfbd54c..fac423d2cb73 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -276,10 +276,12 @@ drm_get_buddy(struct drm_buddy_block *block)
  }
  EXPORT_SYMBOL(drm_get_buddy);
  -static void __drm_buddy_free(struct drm_buddy *mm,
- struct drm_buddy_block *block)
+static unsigned int __drm_buddy_free(struct drm_buddy *mm,
+ struct drm_buddy_block *block,
+ bool defrag)
  {
  struct drm_buddy_block *parent;
+    unsigned int order;
    while ((parent = block->parent)) {
  struct drm_buddy_block *buddy;
@@ -289,12 +291,14 @@ static void __drm_buddy_free(struct drm_buddy 
*mm,

  if (!drm_buddy_block_is_free(buddy))
  break;
  -    if (drm_buddy_block_is_clear(block) !=
-    drm_buddy_block_is_clear(buddy))
-    break;
+    if (!defrag) {
+    if (drm_buddy_block_is_clear(block) !=
+    drm_buddy_block_is_clear(buddy))
+    break;
  -    if (drm_buddy_block_is_clear(block))
-    mark_cleared(parent);
+    if (drm_buddy_block_is_clear(block))
+    mark_cleared(parent);
+    }


Maybe check if the two blocks are incompatible and chuck a warn if 
they are not? Main thing is not to hide issues with split blocks 
that should have been merged before.



list_del(>link);
  @@ -304,8 +308,49 @@ static void __drm_buddy_free(struct 
drm_buddy *mm,

  block = parent;
  }
  +    order = drm_buddy_block_order(block);
  mark_free(mm, block);
+
+    return order;
+}
+
+/**
+ * drm_buddy_defrag - Defragmentation routine
+ *
+ * @mm: DRM buddy manager
+ * @min_order: minimum order in the freelist to begin
+ * the defragmentation process
+ *
+ * Driver calls the defragmentation function when the
+ * requested memory allocation returns -ENOSPC.
+ */
+void drm_buddy_defrag(struct drm_buddy *mm,
+  unsigned int min_order)


Just wondering if we need "full defag" also? We would probably need 
to call this at fini() anyway.



+{
+    struct drm_buddy_block *block;
+    struct list_head *list;
+    unsigned int order;
+    int i;
+
+    if (min_order > mm->max_order)
+    return;
+
+    for (i = min_order - 1; i >= 0; i--) {


Need to be careful with min_order = 0 ?


+    list = >free_list[i];
+    if (list_empty(list))
+    continue;
+
+    list_for_each_entry_reverse(block, list, link) {


Don't we need the safe_reverse() variant here, since this is 
removing from the list?



+    if (!block->parent)
+    continue;
+
+    order = __drm_buddy_free(mm, block, 1);
+    if (order >= min_order)
+    return;
+    }
+    }
  }
+EXPORT_SYMBOL(drm_buddy_defrag);
    /**
   * drm_buddy_free_block - free a block
@@ -321,7 +366,7 @@ void drm_buddy_free_block(struct drm_buddy *mm,
  if (drm_buddy_block_is_clear(block))
  mm->clear_avail += drm_buddy_block_size(mm, block);
  -    __drm_buddy_free(mm, block);
+    __drm_buddy_free(mm, block, 0);
  }
  EXPORT_SYMBOL(drm_buddy_free_block);
  @@ -470,7 +515,7 @@ __alloc_range_bias(struct drm_buddy *mm,
  if (buddy &&
  (drm_buddy_block_is_free(block) &&
   drm_buddy_block_is_free(buddy)))
-    __drm_buddy_free(mm, block);
+    __drm_buddy_free(mm, block, 0);
  return ERR_PTR(err);
  }
  @@ -588,7 +633,7 @@ alloc_from_freelist(struct drm_buddy *mm,
    err_undo:
  if (tmp != order)
-    __drm_buddy_free(mm, block);
+    __drm_buddy_free(mm, block, 0);
  return ERR_PTR(err);
 

Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors

[Hamza Mahfooz]

On 2/16/24 03:19, Pekka Paalanen wrote:

On Fri, 2 Feb 2024 10:28:35 -0500
Hamza Mahfooz  wrote:


We want programs besides the compositor to be able to enable or disable
panel power saving features.


Could you also explain why, in the commit message, please?

It is unexpected for arbitrary programs to be able to override the KMS
client, and certainly new ways to do so should not be added without an
excellent justification.


Also, to be completely honest with you, I'm not sure why it was
initially exposed as a DRM prop, since it's a power management feature.
Which is to say, that it doesn't really make sense to have the
compositor control it.



Maybe debugfs would be more appropriate if the purpose is only testing
rather than production environments?


However, since they are currently only
configurable through DRM properties, that isn't possible. So, to remedy
that issue introduce a new "panel_power_savings" sysfs attribute.


When the DRM property was added, what was used as the userspace to
prove its workings?


Thanks,
pq



Cc: Mario Limonciello 
Signed-off-by: Hamza Mahfooz 
---
v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
 commit when setting the value, call sysfs_remove_group() in
 amdgpu_dm_connector_unregister() and add some documentation.
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++
  1 file changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 8590c9f1dda6..3c62489d03dc 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct 
drm_connector *connector,
return ret;
  }
  
+/**

+ * DOC: panel power savings
+ *
+ * The display manager allows you to set your desired **panel power savings**
+ * level (between 0-4, with 0 representing off), e.g. using the following::
+ *
+ *   # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
+ *
+ * Modifying this value can have implications on color accuracy, so tread
+ * carefully.
+ */
+
+static ssize_t panel_power_savings_show(struct device *device,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct drm_connector *connector = dev_get_drvdata(device);
+   struct drm_device *dev = connector->dev;
+   u8 val;
+
+   drm_modeset_lock(>mode_config.connection_mutex, NULL);
+   val = to_dm_connector_state(connector->state)->abm_level ==
+   ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
+   to_dm_connector_state(connector->state)->abm_level;
+   drm_modeset_unlock(>mode_config.connection_mutex);
+
+   return sysfs_emit(buf, "%u\n", val);
+}
+
+static ssize_t panel_power_savings_store(struct device *device,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct drm_connector *connector = dev_get_drvdata(device);
+   struct drm_device *dev = connector->dev;
+   long val;
+   int ret;
+
+   ret = kstrtol(buf, 0, );
+
+   if (ret)
+   return ret;
+
+   if (val < 0 || val > 4)
+   return -EINVAL;
+
+   drm_modeset_lock(>mode_config.connection_mutex, NULL);
+   to_dm_connector_state(connector->state)->abm_level = val ?:
+   ABM_LEVEL_IMMEDIATE_DISABLE;
+   drm_modeset_unlock(>mode_config.connection_mutex);
+
+   drm_kms_helper_hotplug_event(dev);
+
+   return count;
+}
+
+static DEVICE_ATTR_RW(panel_power_savings);
+
+static struct attribute *amdgpu_attrs[] = {
+   _attr_panel_power_savings.attr,
+   NULL
+};
+
+static const struct attribute_group amdgpu_group = {
+   .name = "amdgpu",
+   .attrs = amdgpu_attrs
+};
+
  static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
  {
struct amdgpu_dm_connector *amdgpu_dm_connector = 
to_amdgpu_dm_connector(connector);
  
+	sysfs_remove_group(>kdev->kobj, _group);

drm_dp_aux_unregister(_dm_connector->dm_dp_aux.aux);
  }
  
@@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct drm_connector *connector)

to_amdgpu_dm_connector(connector);
int r;
  
+	if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {

+   r = sysfs_create_group(>kdev->kobj,
+  _group);
+   if (r)
+   return r;
+   }
+
amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
  
  	if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||



--
Hamza

Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors

[Hamza Mahfooz]

On 2/16/24 03:19, Pekka Paalanen wrote:

On Fri, 2 Feb 2024 10:28:35 -0500
Hamza Mahfooz  wrote:


We want programs besides the compositor to be able to enable or disable
panel power saving features.


Could you also explain why, in the commit message, please?

It is unexpected for arbitrary programs to be able to override the KMS
client, and certainly new ways to do so should not be added without an
excellent justification.

Maybe debugfs would be more appropriate if the purpose is only testing
rather than production environments?


However, since they are currently only
configurable through DRM properties, that isn't possible. So, to remedy
that issue introduce a new "panel_power_savings" sysfs attribute.


When the DRM property was added, what was used as the userspace to
prove its workings?


To my knowledge, it is only used by IGT. Also, it is worth noting that
it is a vendor specific property, so I doubt there are any compositors
out there that felt motivated enough to use it in any capacity.




Thanks,
pq



Cc: Mario Limonciello 
Signed-off-by: Hamza Mahfooz 
---
v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
 commit when setting the value, call sysfs_remove_group() in
 amdgpu_dm_connector_unregister() and add some documentation.
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++
  1 file changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 8590c9f1dda6..3c62489d03dc 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct 
drm_connector *connector,
return ret;
  }
  
+/**

+ * DOC: panel power savings
+ *
+ * The display manager allows you to set your desired **panel power savings**
+ * level (between 0-4, with 0 representing off), e.g. using the following::
+ *
+ *   # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
+ *
+ * Modifying this value can have implications on color accuracy, so tread
+ * carefully.
+ */
+
+static ssize_t panel_power_savings_show(struct device *device,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct drm_connector *connector = dev_get_drvdata(device);
+   struct drm_device *dev = connector->dev;
+   u8 val;
+
+   drm_modeset_lock(>mode_config.connection_mutex, NULL);
+   val = to_dm_connector_state(connector->state)->abm_level ==
+   ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
+   to_dm_connector_state(connector->state)->abm_level;
+   drm_modeset_unlock(>mode_config.connection_mutex);
+
+   return sysfs_emit(buf, "%u\n", val);
+}
+
+static ssize_t panel_power_savings_store(struct device *device,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct drm_connector *connector = dev_get_drvdata(device);
+   struct drm_device *dev = connector->dev;
+   long val;
+   int ret;
+
+   ret = kstrtol(buf, 0, );
+
+   if (ret)
+   return ret;
+
+   if (val < 0 || val > 4)
+   return -EINVAL;
+
+   drm_modeset_lock(>mode_config.connection_mutex, NULL);
+   to_dm_connector_state(connector->state)->abm_level = val ?:
+   ABM_LEVEL_IMMEDIATE_DISABLE;
+   drm_modeset_unlock(>mode_config.connection_mutex);
+
+   drm_kms_helper_hotplug_event(dev);
+
+   return count;
+}
+
+static DEVICE_ATTR_RW(panel_power_savings);
+
+static struct attribute *amdgpu_attrs[] = {
+   _attr_panel_power_savings.attr,
+   NULL
+};
+
+static const struct attribute_group amdgpu_group = {
+   .name = "amdgpu",
+   .attrs = amdgpu_attrs
+};
+
  static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
  {
struct amdgpu_dm_connector *amdgpu_dm_connector = 
to_amdgpu_dm_connector(connector);
  
+	sysfs_remove_group(>kdev->kobj, _group);

drm_dp_aux_unregister(_dm_connector->dm_dp_aux.aux);
  }
  
@@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct drm_connector *connector)

to_amdgpu_dm_connector(connector);
int r;
  
+	if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {

+   r = sysfs_create_group(>kdev->kobj,
+  _group);
+   if (r)
+   return r;
+   }
+
amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
  
  	if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||



--
Hamza

Re: [PATCH v6 3/3] drm/buddy: Add defragmentation support

[Matthew Auld]

On 16/02/2024 12:33, Christian König wrote:

Am 16.02.24 um 13:23 schrieb Matthew Auld:

On 08/02/2024 15:50, Arunpravin Paneer Selvam wrote:

Add a function to support defragmentation.

v1: Defragment the memory beginning from min_order
 till the required memory space is available.

Signed-off-by: Arunpravin Paneer Selvam 


Suggested-by: Matthew Auld 
---
  drivers/gpu/drm/drm_buddy.c | 67 +++--
  include/drm/drm_buddy.h |  3 ++


No users?


Other question is how can a buddy allocator fragment in the first place?


The fragmentation is due to pages now being tracked as dirty/clear. 
Should the allocator merge together a page that is dirty with a page 
that is cleared? When should it do that? User wants to be able to keep 
the two separate if possible. For example, freeing one single dirty page 
can dirty a huge swathe of your already cleared pages if they are merged 
together. Or do you have some some other ideas here?




Christian.




  2 files changed, 59 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 33ad0cfbd54c..fac423d2cb73 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -276,10 +276,12 @@ drm_get_buddy(struct drm_buddy_block *block)
  }
  EXPORT_SYMBOL(drm_get_buddy);
  -static void __drm_buddy_free(struct drm_buddy *mm,
- struct drm_buddy_block *block)
+static unsigned int __drm_buddy_free(struct drm_buddy *mm,
+ struct drm_buddy_block *block,
+ bool defrag)
  {
  struct drm_buddy_block *parent;
+    unsigned int order;
    while ((parent = block->parent)) {
  struct drm_buddy_block *buddy;
@@ -289,12 +291,14 @@ static void __drm_buddy_free(struct drm_buddy *mm,
  if (!drm_buddy_block_is_free(buddy))
  break;
  -    if (drm_buddy_block_is_clear(block) !=
-    drm_buddy_block_is_clear(buddy))
-    break;
+    if (!defrag) {
+    if (drm_buddy_block_is_clear(block) !=
+    drm_buddy_block_is_clear(buddy))
+    break;
  -    if (drm_buddy_block_is_clear(block))
-    mark_cleared(parent);
+    if (drm_buddy_block_is_clear(block))
+    mark_cleared(parent);
+    }


Maybe check if the two blocks are incompatible and chuck a warn if 
they are not? Main thing is not to hide issues with split blocks that 
should have been merged before.



    list_del(>link);
  @@ -304,8 +308,49 @@ static void __drm_buddy_free(struct drm_buddy 
*mm,

  block = parent;
  }
  +    order = drm_buddy_block_order(block);
  mark_free(mm, block);
+
+    return order;
+}
+
+/**
+ * drm_buddy_defrag - Defragmentation routine
+ *
+ * @mm: DRM buddy manager
+ * @min_order: minimum order in the freelist to begin
+ * the defragmentation process
+ *
+ * Driver calls the defragmentation function when the
+ * requested memory allocation returns -ENOSPC.
+ */
+void drm_buddy_defrag(struct drm_buddy *mm,
+  unsigned int min_order)


Just wondering if we need "full defag" also? We would probably need to 
call this at fini() anyway.



+{
+    struct drm_buddy_block *block;
+    struct list_head *list;
+    unsigned int order;
+    int i;
+
+    if (min_order > mm->max_order)
+    return;
+
+    for (i = min_order - 1; i >= 0; i--) {


Need to be careful with min_order = 0 ?


+    list = >free_list[i];
+    if (list_empty(list))
+    continue;
+
+    list_for_each_entry_reverse(block, list, link) {


Don't we need the safe_reverse() variant here, since this is removing 
from the list?



+    if (!block->parent)
+    continue;
+
+    order = __drm_buddy_free(mm, block, 1);
+    if (order >= min_order)
+    return;
+    }
+    }
  }
+EXPORT_SYMBOL(drm_buddy_defrag);
    /**
   * drm_buddy_free_block - free a block
@@ -321,7 +366,7 @@ void drm_buddy_free_block(struct drm_buddy *mm,
  if (drm_buddy_block_is_clear(block))
  mm->clear_avail += drm_buddy_block_size(mm, block);
  -    __drm_buddy_free(mm, block);
+    __drm_buddy_free(mm, block, 0);
  }
  EXPORT_SYMBOL(drm_buddy_free_block);
  @@ -470,7 +515,7 @@ __alloc_range_bias(struct drm_buddy *mm,
  if (buddy &&
  (drm_buddy_block_is_free(block) &&
   drm_buddy_block_is_free(buddy)))
-    __drm_buddy_free(mm, block);
+    __drm_buddy_free(mm, block, 0);
  return ERR_PTR(err);
  }
  @@ -588,7 +633,7 @@ alloc_from_freelist(struct drm_buddy *mm,
    err_undo:
  if (tmp != order)
-    __drm_buddy_free(mm, block);
+    __drm_buddy_free(mm, block, 0);
  return ERR_PTR(err);
  }
  @@ -668,7 +713,7 @@ static int __alloc_range(struct drm_buddy *mm,
  if (buddy &&
  (drm_buddy_block_is_free(block) &&
   drm_buddy_block_is_free(buddy)))
-    __drm_buddy_free(mm, block);
+    

Re: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers

[kernel test robot]

Hi Mario,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip 
linus/master v6.8-rc4 next-20240216]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/drm-Stop-using-select-ACPI_VIDEO-in-all-drivers/20240215-055936
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240214215756.6530-2-mario.limonciello%40amd.com
patch subject: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers
config: alpha-kismet-CONFIG_FB_BACKLIGHT-CONFIG_FB_RADEON-0-0 
(https://download.01.org/0day-ci/archive/20240216/202402162046.jr7hgb8p-...@intel.com/config)
reproduce: 
(https://download.01.org/0day-ci/archive/20240216/202402162046.jr7hgb8p-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202402162046.jr7hgb8p-...@intel.com/

kismet warnings: (new ones prefixed by >>)
>> kismet: WARNING: unmet direct dependencies detected for FB_BACKLIGHT when 
>> selected by FB_RADEON
   .config:171:warning: symbol value 'n' invalid for PANEL_LCD_PIN_E
   .config:253:warning: symbol value 'n' invalid for SATA_MOBILE_LPM_POLICY
   .config:358:warning: symbol value 'n' invalid for PSTORE_BLK_MAX_REASON
   .config:438:warning: symbol value 'n' invalid for KFENCE_SAMPLE_INTERVAL
   .config:623:warning: symbol value 'n' invalid for DRM_XE_JOB_TIMEOUT_MIN
   .config:662:warning: symbol value 'n' invalid for CRYPTO_DEV_QCE_SW_MAX_LEN
   .config:677:warning: symbol value 'n' invalid for AIC79XX_DEBUG_MASK
   .config:773:warning: symbol value 'n' invalid for PANEL_LCD_CHARSET
   .config:804:warning: symbol value 'n' invalid for SND_AC97_POWER_SAVE_DEFAULT
   .config:870:warning: symbol value 'n' invalid for MAGIC_SYSRQ_DEFAULT_ENABLE
   .config:891:warning: symbol value 'n' invalid for 
DRM_I915_MAX_REQUEST_BUSYWAIT
   .config:918:warning: symbol value 'n' invalid for DRM_XE_PREEMPT_TIMEOUT_MIN
   .config:928:warning: symbol value 'n' invalid for NET_EMATCH_STACK
   .config:930:warning: symbol value 'n' invalid for VMCP_CMA_SIZE
   .config:935:warning: symbol value 'n' invalid for SND_AT73C213_TARGET_BITRATE
   .config:1064:warning: symbol value 'n' invalid for AIC79XX_CMDS_PER_DEVICE
   .config:1162:warning: symbol value 'n' invalid for RCU_CPU_STALL_TIMEOUT
   .config:1182:warning: symbol value 'n' invalid for PANEL_LCD_PIN_SDA
   .config:1190:warning: symbol value 'n' invalid for MTDRAM_ERASE_SIZE
   .config:1220:warning: symbol value 'n' invalid for AIC79XX_RESET_DELAY_MS
   .config:1312:warning: symbol value 'n' invalid for SERIAL_UARTLITE_NR_UARTS
   .config:1493:warning: symbol value 'n' invalid for LEGACY_PTY_COUNT
   .config:1636:warning: symbol value 'n' invalid for AIC7XXX_RESET_DELAY_MS
   .config:1637:warning: symbol value 'n' invalid for WATCHDOG_OPEN_TIMEOUT
   .config:1782:warning: symbol value 'n' invalid for IBM_EMAC_POLL_WEIGHT
   .config:1788:warning: symbol value 'n' invalid for 
MTD_REDBOOT_DIRECTORY_BLOCK
   .config:1939:warning: symbol value 'n' invalid for DRM_I915_STOP_TIMEOUT
   .config:2157:warning: symbol value 'n' invalid for SND_HDA_PREALLOC_SIZE
   .config:2205:warning: symbol value 'n' invalid for RCU_FANOUT_LEAF
   .config:2353:warning: symbol value 'n' invalid for PANEL_LCD_BWIDTH
   .config:2384:warning: symbol value 'n' invalid for DRM_XE_TIMESLICE_MAX
   .config:2400:warning: symbol value 'n' invalid for SERIAL_AR933X_NR_UARTS
   .config:2594:warning: symbol value 'n' invalid for PANEL_PARPORT
   .config:2634:warning: symbol value 'n' invalid for KCOV_IRQ_AREA_SIZE
   .config:2681:warning: symbol value 'n' invalid for NOUVEAU_DEBUG_DEFAULT
   .config:2872:warning: symbol value 'n' invalid for KCSAN_REPORT_ONCE_IN_MS
   .config:2971:warning: symbol value 'n' invalid for KCSAN_UDELAY_INTERRUPT
   .config:2994:warning: symbol value 'n' invalid for PANEL_LCD_PIN_BL
   .config:3020:warning: symbol value 'n' invalid for INITRAMFS_ROOT_GID
   .config:3048:warning: symbol value 'n' invalid for 
FTRACE_RECORD_RECURSION_SIZE
   .config:3128:warning: symbol value 'n' invalid for ATM_FORE200E_TX_RETRY
   .config:3165:warning: symbol value 'n' invalid for 
FB_OMAP2_DSS_MIN_FCK_PER_PCK
   .config:3203:warning: symbol value 'n' invalid for 
SND_SOC_SOF_DEBUG_IPC_FLOOD_TEST_NUM
   .config:3465:warning: symbol value 'n' invalid for PSTORE_BLK_CONSOLE_SIZE
   .config:3493:warning: symbol value 'n' invalid for KCSAN_UDELAY_TASK
   .config:3514:warning: symbol value 'n' invalid for MMC_BLOCK_MINORS
   .c

[PATCH 3/3] drm/amdgpu: Remove pcie bw sys entry

[Asad Kamal]

Remove pcie bw sys entry for asics not supporting
such function

Signed-off-by: Asad Kamal 
Reviewed-by: Lijo Lazar 
---
 drivers/gpu/drm/amd/amdgpu/soc15.c | 1 -
 drivers/gpu/drm/amd/pm/amdgpu_pm.c | 3 ++-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c 
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index 7fc55e3262eb..20a4582885cc 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -895,7 +895,6 @@ static const struct amdgpu_asic_funcs 
aqua_vanjaram_asic_funcs =
.get_config_memsize = _get_config_memsize,
.need_full_reset = _need_full_reset,
.init_doorbell_index = _vanjaram_doorbell_index_init,
-   .get_pcie_usage = _get_pcie_usage,
.need_reset_on_init = _need_reset_on_init,
.get_pcie_replay_count = _nbio_get_pcie_replay_count,
.supports_baco = _supports_baco,
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c 
b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
index 087d57850304..1ff7fc821871 100644
--- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
@@ -2174,7 +2174,8 @@ static int default_attr_update(struct amdgpu_device 
*adev, struct amdgpu_device_
*states = ATTR_STATE_UNSUPPORTED;
} else if (DEVICE_ATTR_IS(pcie_bw)) {
/* PCIe Perf counters won't work on APU nodes */
-   if (adev->flags & AMD_IS_APU)
+   if (adev->flags & AMD_IS_APU ||
+   !adev->asic_funcs->get_pcie_usage)
*states = ATTR_STATE_UNSUPPORTED;
} else if (DEVICE_ATTR_IS(unique_id)) {
switch (gc_ver) {
-- 
2.42.0

[PATCH 2/3] Revert "drm/amdgpu: Add pcie usage callback to nbio"

[Asad Kamal]

pcie usage is now handled by fw

This reverts commit 8d759dc6644df4141a151293cb0e77fd8ca379ed.

Signed-off-by: Asad Kamal 
Reviewed-by: Lijo Lazar 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.c | 8 
 drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h | 3 ---
 2 files changed, 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.c
index 51ca544a7094..d085687a47ea 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.c
@@ -53,14 +53,6 @@ u64 amdgpu_nbio_get_pcie_replay_count(struct amdgpu_device 
*adev)
return 0;
 }
 
-void amdgpu_nbio_get_pcie_usage(struct amdgpu_device *adev, uint64_t *count0,
-   uint64_t *count1)
-{
-   if (adev->nbio.funcs->get_pcie_usage)
-   adev->nbio.funcs->get_pcie_usage(adev, count0, count1);
-
-}
-
 int amdgpu_nbio_ras_late_init(struct amdgpu_device *adev, struct ras_common_if 
*ras_block)
 {
int r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h
index 65e35059de40..7b8c03be1d9e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h
@@ -102,8 +102,6 @@ struct amdgpu_nbio_funcs {
u32 (*get_memory_partition_mode)(struct amdgpu_device *adev,
 u32 *supp_modes);
u64 (*get_pcie_replay_count)(struct amdgpu_device *adev);
-   void (*get_pcie_usage)(struct amdgpu_device *adev, uint64_t *count0,
-   uint64_t *count1);
 };
 
 struct amdgpu_nbio {
@@ -116,7 +114,6 @@ struct amdgpu_nbio {
 };
 
 int amdgpu_nbio_ras_sw_init(struct amdgpu_device *adev);
-void amdgpu_nbio_get_pcie_usage(struct amdgpu_device *adev, uint64_t *count0, 
uint64_t *count1);
 int amdgpu_nbio_ras_late_init(struct amdgpu_device *adev, struct ras_common_if 
*ras_block);
 u64 amdgpu_nbio_get_pcie_replay_count(struct amdgpu_device *adev);
 
-- 
2.42.0

[PATCH 1/3] Revert "drm/amdgpu: Add pci usage to nbio v7.9"

[Asad Kamal]

Remove implementation to get pcie usage for nbio v7.9
as pcie usage is handled by fw

This reverts commit 59070fd9ccea58c3363d39f69c25fa98c71eb02f.

Signed-off-by: Asad Kamal 
Reviewed-by: Lijo Lazar 
---
 drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c| 63 ---
 drivers/gpu/drm/amd/amdgpu/soc15.c|  2 +-
 .../asic_reg/nbio/nbio_7_9_0_sh_mask.h|  8 ---
 3 files changed, 1 insertion(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c 
b/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c
index b4723d68eab0..40d1e209eab7 100644
--- a/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c
+++ b/drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c
@@ -35,15 +35,6 @@
 /* Core 0 Port 0 counter */
 #define smnPCIEP_NAK_COUNTER 0x1A340218
 
-#define smnPCIE_PERF_CNTL_TXCLK3   0x1A38021c
-#define smnPCIE_PERF_CNTL_TXCLK7   0x1A380888
-#define smnPCIE_PERF_COUNT_CNTL0x1A380200
-#define smnPCIE_PERF_COUNT0_TXCLK3 0x1A380220
-#define smnPCIE_PERF_COUNT0_TXCLK7 0x1A38088C
-#define smnPCIE_PERF_COUNT0_UPVAL_TXCLK3   0x1A3808F8
-#define smnPCIE_PERF_COUNT0_UPVAL_TXCLK7   0x1A380918
-
-
 static void nbio_v7_9_remap_hdp_registers(struct amdgpu_device *adev)
 {
WREG32_SOC15(NBIO, 0, regBIF_BX0_REMAP_HDP_MEM_FLUSH_CNTL,
@@ -484,59 +475,6 @@ static u64 nbio_v7_9_get_pcie_replay_count(struct 
amdgpu_device *adev)
return (nak_r + nak_g);
 }
 
-static void nbio_v7_9_get_pcie_usage(struct amdgpu_device *adev, uint64_t 
*count0,
-uint64_t *count1)
-{
-   uint32_t perfctrrx = 0;
-   uint32_t perfctrtx = 0;
-
-   /* This reports 0 on APUs, so return to avoid writing/reading registers
-* that may or may not be different from their GPU counterparts
-*/
-   if (adev->flags & AMD_IS_APU)
-   return;
-
-   /* Use TXCLK3 counter group for rx event */
-   /* Use TXCLK7 counter group for tx event */
-   /* Set the 2 events that we wish to watch, defined above */
-   /* 40 is event# for received msgs */
-   /* 2 is event# of posted requests sent */
-   perfctrrx = REG_SET_FIELD(perfctrrx, PCIE_PERF_CNTL_TXCLK3, EVENT0_SEL, 
40);
-   perfctrtx = REG_SET_FIELD(perfctrtx, PCIE_PERF_CNTL_TXCLK7, EVENT0_SEL, 
2);
-
-   /* Write to enable desired perf counters */
-   WREG32_PCIE(smnPCIE_PERF_CNTL_TXCLK3, perfctrrx);
-   WREG32_PCIE(smnPCIE_PERF_CNTL_TXCLK7, perfctrtx);
-
-   /* Zero out and enable SHADOW_WR
-* Write 0x6:
-* Bit 1 = Global Shadow wr(1)
-* Bit 2 = Global counter reset enable(1)
-*/
-   WREG32_PCIE(smnPCIE_PERF_COUNT_CNTL, 0x0006);
-
-   /* Enable Gloabl Counter
-* Write 0x1:
-* Bit 0 = Global Counter Enable(1)
-*/
-   WREG32_PCIE(smnPCIE_PERF_COUNT_CNTL, 0x0001);
-
-   msleep(1000);
-
-   /* Disable Global Counter, Reset and enable SHADOW_WR
-* Write 0x6:
-* Bit 1 = Global Shadow wr(1)
-* Bit 2 = Global counter reset enable(1)
-*/
-   WREG32_PCIE(smnPCIE_PERF_COUNT_CNTL, 0x0006);
-
-   /* Get the upper and lower count  */
-   *count0 = RREG32_PCIE(smnPCIE_PERF_COUNT0_TXCLK3) |
- ((uint64_t)RREG32_PCIE(smnPCIE_PERF_COUNT0_UPVAL_TXCLK3) << 
32);
-   *count1 = RREG32_PCIE(smnPCIE_PERF_COUNT0_TXCLK7) |
- ((uint64_t)RREG32_PCIE(smnPCIE_PERF_COUNT0_UPVAL_TXCLK7) << 
32);
-}
-
 const struct amdgpu_nbio_funcs nbio_v7_9_funcs = {
.get_hdp_flush_req_offset = nbio_v7_9_get_hdp_flush_req_offset,
.get_hdp_flush_done_offset = nbio_v7_9_get_hdp_flush_done_offset,
@@ -561,7 +499,6 @@ const struct amdgpu_nbio_funcs nbio_v7_9_funcs = {
.get_memory_partition_mode = nbio_v7_9_get_memory_partition_mode,
.init_registers = nbio_v7_9_init_registers,
.get_pcie_replay_count = nbio_v7_9_get_pcie_replay_count,
-   .get_pcie_usage = nbio_v7_9_get_pcie_usage,
 };
 
 static void nbio_v7_9_query_ras_error_count(struct amdgpu_device *adev,
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c 
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index c64c01e2944a..7fc55e3262eb 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -895,7 +895,7 @@ static const struct amdgpu_asic_funcs 
aqua_vanjaram_asic_funcs =
.get_config_memsize = _get_config_memsize,
.need_full_reset = _need_full_reset,
.init_doorbell_index = _vanjaram_doorbell_index_init,
-   .get_pcie_usage = _nbio_get_pcie_usage,
+   .get_pcie_usage = _get_pcie_usage,
.need_reset_on_init = _need_reset_on_init,
.get_pcie_replay_count = _nbio_get_pcie_replay_count,
.supports_baco = _supports_baco,
diff --git a/drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_7_9_0_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_7_9_0_sh_mask.h
index e0c28c29ddb0..a22481e7bcdb 100644
--- 

Re: [PATCH 0/6 V4] fdinfo shared stats

[Christian König]

Am 15.02.24 um 15:20 schrieb Alex Deucher:

On Thu, Feb 15, 2024 at 9:18 AM Christian König
 wrote:

Am 12.02.24 um 22:04 schrieb Alex Deucher:

We had a request to add shared buffer stats to fdinfo for amdgpu and
while implementing that, Christian mentioned that just looking at
the GEM handle count doesn't take into account buffers shared with other
subsystems like V4L or RDMA.  Those subsystems don't use GEM, so it
doesn't really matter from a GPU top perspective, but it's more
correct if you actually want to see shared buffers.

After further discussions, add a helper and update all fdinfo
implementations to use that helper for consistency.

v4: switch drm_gem_object_is_shared_for_memory_stats() to an inline function

I'm still not sure if looking at the actual handle count is the right
approach, but it's certainly better than before.

Well, it's consistent across drivers.


Yeah, which makes it easy to change if we find something better.




So Reviewed-by: Christian König  for the
entire series.

Should I take this through drm-misc-next?

Yes, please.


Done.

Regards,
Christian.



Thanks,

Alex


Regards,
Christian.


Alex Deucher (6):
Documentation/gpu: Update documentation on drm-shared-*
drm: add drm_gem_object_is_shared_for_memory_stats() helper
drm: update drm_show_memory_stats() for dma-bufs
drm/amdgpu: add shared fdinfo stats
drm/i915: Update shared stats to use the new gem helper
drm/xe: Update shared stats to use the new gem helper

   Documentation/gpu/drm-usage-stats.rst  |  2 +-
   drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c |  4 
   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++
   drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  6 ++
   drivers/gpu/drm/drm_file.c |  2 +-
   drivers/gpu/drm/i915/i915_drm_client.c |  2 +-
   drivers/gpu/drm/xe/xe_drm_client.c |  2 +-
   include/drm/drm_gem.h  | 13 +
   8 files changed, 38 insertions(+), 4 deletions(-)

Re: [PATCH v6 3/3] drm/buddy: Add defragmentation support

[Christian König]

Am 16.02.24 um 13:23 schrieb Matthew Auld:

On 08/02/2024 15:50, Arunpravin Paneer Selvam wrote:

Add a function to support defragmentation.

v1: Defragment the memory beginning from min_order
 till the required memory space is available.

Signed-off-by: Arunpravin Paneer Selvam 


Suggested-by: Matthew Auld 
---
  drivers/gpu/drm/drm_buddy.c | 67 +++--
  include/drm/drm_buddy.h |  3 ++


No users?


Other question is how can a buddy allocator fragment in the first place?

Christian.




  2 files changed, 59 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 33ad0cfbd54c..fac423d2cb73 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -276,10 +276,12 @@ drm_get_buddy(struct drm_buddy_block *block)
  }
  EXPORT_SYMBOL(drm_get_buddy);
  -static void __drm_buddy_free(struct drm_buddy *mm,
- struct drm_buddy_block *block)
+static unsigned int __drm_buddy_free(struct drm_buddy *mm,
+ struct drm_buddy_block *block,
+ bool defrag)
  {
  struct drm_buddy_block *parent;
+    unsigned int order;
    while ((parent = block->parent)) {
  struct drm_buddy_block *buddy;
@@ -289,12 +291,14 @@ static void __drm_buddy_free(struct drm_buddy *mm,
  if (!drm_buddy_block_is_free(buddy))
  break;
  -    if (drm_buddy_block_is_clear(block) !=
-    drm_buddy_block_is_clear(buddy))
-    break;
+    if (!defrag) {
+    if (drm_buddy_block_is_clear(block) !=
+    drm_buddy_block_is_clear(buddy))
+    break;
  -    if (drm_buddy_block_is_clear(block))
-    mark_cleared(parent);
+    if (drm_buddy_block_is_clear(block))
+    mark_cleared(parent);
+    }


Maybe check if the two blocks are incompatible and chuck a warn if 
they are not? Main thing is not to hide issues with split blocks that 
should have been merged before.



    list_del(>link);
  @@ -304,8 +308,49 @@ static void __drm_buddy_free(struct drm_buddy 
*mm,

  block = parent;
  }
  +    order = drm_buddy_block_order(block);
  mark_free(mm, block);
+
+    return order;
+}
+
+/**
+ * drm_buddy_defrag - Defragmentation routine
+ *
+ * @mm: DRM buddy manager
+ * @min_order: minimum order in the freelist to begin
+ * the defragmentation process
+ *
+ * Driver calls the defragmentation function when the
+ * requested memory allocation returns -ENOSPC.
+ */
+void drm_buddy_defrag(struct drm_buddy *mm,
+  unsigned int min_order)


Just wondering if we need "full defag" also? We would probably need to 
call this at fini() anyway.



+{
+    struct drm_buddy_block *block;
+    struct list_head *list;
+    unsigned int order;
+    int i;
+
+    if (min_order > mm->max_order)
+    return;
+
+    for (i = min_order - 1; i >= 0; i--) {


Need to be careful with min_order = 0 ?


+    list = >free_list[i];
+    if (list_empty(list))
+    continue;
+
+    list_for_each_entry_reverse(block, list, link) {


Don't we need the safe_reverse() variant here, since this is removing 
from the list?



+    if (!block->parent)
+    continue;
+
+    order = __drm_buddy_free(mm, block, 1);
+    if (order >= min_order)
+    return;
+    }
+    }
  }
+EXPORT_SYMBOL(drm_buddy_defrag);
    /**
   * drm_buddy_free_block - free a block
@@ -321,7 +366,7 @@ void drm_buddy_free_block(struct drm_buddy *mm,
  if (drm_buddy_block_is_clear(block))
  mm->clear_avail += drm_buddy_block_size(mm, block);
  -    __drm_buddy_free(mm, block);
+    __drm_buddy_free(mm, block, 0);
  }
  EXPORT_SYMBOL(drm_buddy_free_block);
  @@ -470,7 +515,7 @@ __alloc_range_bias(struct drm_buddy *mm,
  if (buddy &&
  (drm_buddy_block_is_free(block) &&
   drm_buddy_block_is_free(buddy)))
-    __drm_buddy_free(mm, block);
+    __drm_buddy_free(mm, block, 0);
  return ERR_PTR(err);
  }
  @@ -588,7 +633,7 @@ alloc_from_freelist(struct drm_buddy *mm,
    err_undo:
  if (tmp != order)
-    __drm_buddy_free(mm, block);
+    __drm_buddy_free(mm, block, 0);
  return ERR_PTR(err);
  }
  @@ -668,7 +713,7 @@ static int __alloc_range(struct drm_buddy *mm,
  if (buddy &&
  (drm_buddy_block_is_free(block) &&
   drm_buddy_block_is_free(buddy)))
-    __drm_buddy_free(mm, block);
+    __drm_buddy_free(mm, block, 0);
    err_free:
  if (err == -ENOSPC && total_allocated_on_err) {
diff --git a/include/drm/drm_buddy.h b/include/drm/drm_buddy.h
index d81c596dfa38..d0f63e7b5915 100644
--- a/include/drm/drm_buddy.h
+++ b/include/drm/drm_buddy.h
@@ -166,6 +166,9 @@ void drm_buddy_free_list(struct drm_buddy *mm,
   struct list_head *objects,
   unsigned int flags);
  +void drm_buddy_defrag(struct drm_buddy *mm,
+  

Re: [PATCH] drm/amd/display: fix null-pointer dereference on edid reading

[Melissa Wen]

On 02/15, Alex Deucher wrote:
> On Thu, Feb 15, 2024 at 12:35 PM Melissa Wen  wrote:
> >
> > Use i2c adapter when there isn't aux_mode in dc_link to fix a
> > null-pointer derefence that happens when running
> > igt@kms_force_connector_basic in a system with DCN2.1 and HDMI connector
> > detected as below:
> >
> > [  +0.178146] BUG: kernel NULL pointer dereference, address: 
> > 04c0
> > [  +0.10] #PF: supervisor read access in kernel mode
> > [  +0.05] #PF: error_code(0x) - not-present page
> > [  +0.04] PGD 0 P4D 0
> > [  +0.06] Oops:  [#1] PREEMPT SMP NOPTI
> > [  +0.06] CPU: 15 PID: 2368 Comm: kms_force_conne Not tainted 
> > 6.5.0-asdn+ #152
> > [  +0.05] Hardware name: HP HP ENVY x360 Convertible 13-ay1xxx/8929, 
> > BIOS F.01 07/14/2021
> > [  +0.04] RIP: 0010:i2c_transfer+0xd/0x100
> > [  +0.11] Code: ea fc ff ff 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 
> > 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 55 53 
> > <48> 8b 47 10 48 89 fb 48 83 38 00 0f 84 b3 00 00 00 83 3d 2f 80 16
> > [  +0.04] RSP: 0018:9c4f89c0fad0 EFLAGS: 00010246
> > [  +0.05] RAX:  RBX: 0005 RCX: 
> > 0080
> > [  +0.03] RDX: 0002 RSI: 9c4f89c0fb20 RDI: 
> > 04b0
> > [  +0.03] RBP: 9c4f89c0fb80 R08: 0080 R09: 
> > 8d8e0b15b980
> > [  +0.03] R10: 000380e0 R11:  R12: 
> > 0080
> > [  +0.02] R13: 0002 R14: 9c4f89c0fb0e R15: 
> > 9c4f89c0fb0f
> > [  +0.04] FS:  7f9ad2176c40() GS:8d90fe9c() 
> > knlGS:
> > [  +0.03] CS:  0010 DS:  ES:  CR0: 80050033
> > [  +0.04] CR2: 04c0 CR3: 000121bc4000 CR4: 
> > 00750ee0
> > [  +0.03] PKRU: 5554
> > [  +0.03] Call Trace:
> > [  +0.06]  
> > [  +0.06]  ? __die+0x23/0x70
> > [  +0.11]  ? page_fault_oops+0x17d/0x4c0
> > [  +0.08]  ? preempt_count_add+0x6e/0xa0
> > [  +0.08]  ? srso_alias_return_thunk+0x5/0x7f
> > [  +0.11]  ? exc_page_fault+0x7f/0x180
> > [  +0.09]  ? asm_exc_page_fault+0x26/0x30
> > [  +0.13]  ? i2c_transfer+0xd/0x100
> > [  +0.10]  drm_do_probe_ddc_edid+0xc2/0x140 [drm]
> > [  +0.67]  ? srso_alias_return_thunk+0x5/0x7f
> > [  +0.06]  ? _drm_do_get_edid+0x97/0x3c0 [drm]
> > [  +0.43]  ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]
> > [  +0.42]  edid_block_read+0x3b/0xd0 [drm]
> > [  +0.43]  _drm_do_get_edid+0xb6/0x3c0 [drm]
> > [  +0.41]  ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]
> > [  +0.43]  drm_edid_read_custom+0x37/0xd0 [drm]
> > [  +0.44]  amdgpu_dm_connector_mode_valid+0x129/0x1d0 [amdgpu]
> > [  +0.000153]  drm_connector_mode_valid+0x3b/0x60 [drm_kms_helper]
> > [  +0.00]  __drm_helper_update_and_validate+0xfe/0x3c0 [drm_kms_helper]
> > [  +0.00]  ? amdgpu_dm_connector_get_modes+0xb6/0x520 [amdgpu]
> > [  +0.00]  ? srso_alias_return_thunk+0x5/0x7f
> > [  +0.00]  drm_helper_probe_single_connector_modes+0x2ab/0x540 
> > [drm_kms_helper]
> > [  +0.00]  status_store+0xb2/0x1f0 [drm]
> > [  +0.00]  kernfs_fop_write_iter+0x136/0x1d0
> > [  +0.00]  vfs_write+0x24d/0x440
> > [  +0.00]  ksys_write+0x6f/0xf0
> > [  +0.00]  do_syscall_64+0x60/0xc0
> > [  +0.00]  ? srso_alias_return_thunk+0x5/0x7f
> > [  +0.00]  ? syscall_exit_to_user_mode+0x2b/0x40
> > [  +0.00]  ? srso_alias_return_thunk+0x5/0x7f
> > [  +0.00]  ? do_syscall_64+0x6c/0xc0
> > [  +0.00]  ? do_syscall_64+0x6c/0xc0
> > [  +0.00]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
> > [  +0.00] RIP: 0033:0x7f9ad46b4b00
> > [  +0.00] Code: 40 00 48 8b 15 19 b3 0d 00 f7 d8 64 89 02 48 c7 c0 ff 
> > ff ff ff eb b7 0f 1f 00 80 3d e1 3a 0e 00 00 74 17 b8 01 00 00 00 0f 05 
> > <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89
> > [  +0.00] RSP: 002b:7ffcbd3bd6d8 EFLAGS: 0202 ORIG_RAX: 
> > 0001
> > [  +0.00] RAX: ffda RBX:  RCX: 
> > 7f9ad46b4b00
> > [  +0.00] RDX: 0002 RSI: 7f9ad48a7417 RDI: 
> > 0009
> > [  +0.00] RBP: 0002 R08: 0064 R09: 
> > 
> > [  +0.00] R10:  R11: 0202 R12: 
> > 7f9ad48a7417
> > [  +0.00] R13: 0009 R14: 7ffcbd3bd760 R15: 
> > 0001
> > [  +0.00]  
> > [  +0.00] Modules linked in: ctr ccm rfcomm snd_seq_dummy snd_hrtimer 
> > snd_seq snd_seq_device cmac algif_hash algif_skcipher af_alg bnep btusb 
> > btrtl btbcm btintel btmtk bluetooth uvcvideo videobuf2_vmalloc sha3_generic 
> > videobuf2_memops uvc jitterentropy_rng videobuf2_v4l2 videodev drbg 
> > videobuf2_common ansi_cprng mc ecdh_generic ecc qrtr binfmt_misc 
> > hid_sensor_accel_3d hid_sensor_magn_3d hid_sensor_gyro_3d 
> > hid_sensor_trigger 

Re: [PATCH 0/9] PSP 14.0 support

[Christian König]

Am 12.02.24 um 18:58 schrieb Alex Deucher:

This set adds support for PSP 14.0.x.  PSP handles firmware
validation and various low level asic initialization.

The first patch adds register headers and is large so it has
been omitted.

Hawking Zhang (2):
   drm/amdgpu: Add mp v14_0_2 ip headers (v5)
   drm/amdgpu: Add psp v14_0 ip block support

Likun Gao (7):
   drm/amdgpu: use spirom update wait_for helper for psp v14
   drm/amdgpu: support psp ip block for psp v14
   drm/amdgpu/psp: set autoload support by default
   drm/amdgpu/psp: handle TMR type via flag
   drm/amdgpu/psp: set boot_time_tmr flag
   drm/amdgpu: add psp_timeout to limit PSP related operation
   drm/amdgpu: support psp ip block discovery for psp v14


Acked-by: Christian König  for the series.



  drivers/gpu/drm/amd/amdgpu/Makefile   |   3 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |   1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c |   4 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c   |  55 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h   |   3 +
  drivers/gpu/drm/amd/amdgpu/psp_v14_0.c| 672 +
  drivers/gpu/drm/amd/amdgpu/psp_v14_0.h|  32 +
  .../include/asic_reg/mp/mp_14_0_2_offset.h| 468 
  .../include/asic_reg/mp/mp_14_0_2_sh_mask.h   | 692 ++
  9 files changed, 1907 insertions(+), 23 deletions(-)
  create mode 100644 drivers/gpu/drm/amd/amdgpu/psp_v14_0.c
  create mode 100644 drivers/gpu/drm/amd/amdgpu/psp_v14_0.h
  create mode 100644 drivers/gpu/drm/amd/include/asic_reg/mp/mp_14_0_2_offset.h
  create mode 100644 drivers/gpu/drm/amd/include/asic_reg/mp/mp_14_0_2_sh_mask.h

[PATCH v2] drm/amd/display: fix null-pointer dereference on edid reading

[Melissa Wen]

Use i2c adapter when there isn't aux_mode in dc_link to fix a
null-pointer derefence that happens when running
igt@kms_force_connector_basic in a system with DCN2.1 and HDMI connector
detected as below:

[  +0.178146] BUG: kernel NULL pointer dereference, address: 04c0
[  +0.10] #PF: supervisor read access in kernel mode
[  +0.05] #PF: error_code(0x) - not-present page
[  +0.04] PGD 0 P4D 0
[  +0.06] Oops:  [#1] PREEMPT SMP NOPTI
[  +0.06] CPU: 15 PID: 2368 Comm: kms_force_conne Not tainted 6.5.0-asdn+ 
#152
[  +0.05] Hardware name: HP HP ENVY x360 Convertible 13-ay1xxx/8929, BIOS 
F.01 07/14/2021
[  +0.04] RIP: 0010:i2c_transfer+0xd/0x100
[  +0.11] Code: ea fc ff ff 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 
90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 55 53 <48> 8b 47 10 
48 89 fb 48 83 38 00 0f 84 b3 00 00 00 83 3d 2f 80 16
[  +0.04] RSP: 0018:9c4f89c0fad0 EFLAGS: 00010246
[  +0.05] RAX:  RBX: 0005 RCX: 0080
[  +0.03] RDX: 0002 RSI: 9c4f89c0fb20 RDI: 04b0
[  +0.03] RBP: 9c4f89c0fb80 R08: 0080 R09: 8d8e0b15b980
[  +0.03] R10: 000380e0 R11:  R12: 0080
[  +0.02] R13: 0002 R14: 9c4f89c0fb0e R15: 9c4f89c0fb0f
[  +0.04] FS:  7f9ad2176c40() GS:8d90fe9c() 
knlGS:
[  +0.03] CS:  0010 DS:  ES:  CR0: 80050033
[  +0.04] CR2: 04c0 CR3: 000121bc4000 CR4: 00750ee0
[  +0.03] PKRU: 5554
[  +0.03] Call Trace:
[  +0.06]  
[  +0.06]  ? __die+0x23/0x70
[  +0.11]  ? page_fault_oops+0x17d/0x4c0
[  +0.08]  ? preempt_count_add+0x6e/0xa0
[  +0.08]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.11]  ? exc_page_fault+0x7f/0x180
[  +0.09]  ? asm_exc_page_fault+0x26/0x30
[  +0.13]  ? i2c_transfer+0xd/0x100
[  +0.10]  drm_do_probe_ddc_edid+0xc2/0x140 [drm]
[  +0.67]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.06]  ? _drm_do_get_edid+0x97/0x3c0 [drm]
[  +0.43]  ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]
[  +0.42]  edid_block_read+0x3b/0xd0 [drm]
[  +0.43]  _drm_do_get_edid+0xb6/0x3c0 [drm]
[  +0.41]  ? __pfx_drm_do_probe_ddc_edid+0x10/0x10 [drm]
[  +0.43]  drm_edid_read_custom+0x37/0xd0 [drm]
[  +0.44]  amdgpu_dm_connector_mode_valid+0x129/0x1d0 [amdgpu]
[  +0.000153]  drm_connector_mode_valid+0x3b/0x60 [drm_kms_helper]
[  +0.00]  __drm_helper_update_and_validate+0xfe/0x3c0 [drm_kms_helper]
[  +0.00]  ? amdgpu_dm_connector_get_modes+0xb6/0x520 [amdgpu]
[  +0.00]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.00]  drm_helper_probe_single_connector_modes+0x2ab/0x540 
[drm_kms_helper]
[  +0.00]  status_store+0xb2/0x1f0 [drm]
[  +0.00]  kernfs_fop_write_iter+0x136/0x1d0
[  +0.00]  vfs_write+0x24d/0x440
[  +0.00]  ksys_write+0x6f/0xf0
[  +0.00]  do_syscall_64+0x60/0xc0
[  +0.00]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.00]  ? syscall_exit_to_user_mode+0x2b/0x40
[  +0.00]  ? srso_alias_return_thunk+0x5/0x7f
[  +0.00]  ? do_syscall_64+0x6c/0xc0
[  +0.00]  ? do_syscall_64+0x6c/0xc0
[  +0.00]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[  +0.00] RIP: 0033:0x7f9ad46b4b00
[  +0.00] Code: 40 00 48 8b 15 19 b3 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff 
ff eb b7 0f 1f 00 80 3d e1 3a 0e 00 00 74 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 
ff ff 77 58 c3 0f 1f 80 00 00 00 00 48 83 ec 28 48 89
[  +0.00] RSP: 002b:7ffcbd3bd6d8 EFLAGS: 0202 ORIG_RAX: 
0001
[  +0.00] RAX: ffda RBX:  RCX: 7f9ad46b4b00
[  +0.00] RDX: 0002 RSI: 7f9ad48a7417 RDI: 0009
[  +0.00] RBP: 0002 R08: 0064 R09: 
[  +0.00] R10:  R11: 0202 R12: 7f9ad48a7417
[  +0.00] R13: 0009 R14: 7ffcbd3bd760 R15: 0001
[  +0.00]  
[  +0.00] Modules linked in: ctr ccm rfcomm snd_seq_dummy snd_hrtimer 
snd_seq snd_seq_device cmac algif_hash algif_skcipher af_alg bnep btusb btrtl 
btbcm btintel btmtk bluetooth uvcvideo videobuf2_vmalloc sha3_generic 
videobuf2_memops uvc jitterentropy_rng videobuf2_v4l2 videodev drbg 
videobuf2_common ansi_cprng mc ecdh_generic ecc qrtr binfmt_misc 
hid_sensor_accel_3d hid_sensor_magn_3d hid_sensor_gyro_3d hid_sensor_trigger 
industrialio_triggered_buffer kfifo_buf industrialio snd_ctl_led joydev 
hid_sensor_iio_common rtw89_8852ae rtw89_8852a rtw89_pci snd_hda_codec_realtek 
rtw89_core snd_hda_codec_generic intel_rapl_msr ledtrig_audio intel_rapl_common 
snd_hda_codec_hdmi mac80211 snd_hda_intel snd_intel_dspcfg kvm_amd 
snd_hda_codec snd_soc_dmic snd_acp3x_rn snd_acp3x_pdm_dma libarc4 snd_hwdep 
snd_soc_core kvm snd_hda_core cfg80211 snd_pci_acp6x snd_pcm nls_ascii 
snd_timer hp_wmi snd_pci_acp5x 

Re: [PATCH v6 3/3] drm/buddy: Add defragmentation support

[Matthew Auld]

On 08/02/2024 15:50, Arunpravin Paneer Selvam wrote:

Add a function to support defragmentation.

v1: Defragment the memory beginning from min_order
 till the required memory space is available.

Signed-off-by: Arunpravin Paneer Selvam 
Suggested-by: Matthew Auld 
---
  drivers/gpu/drm/drm_buddy.c | 67 +++--
  include/drm/drm_buddy.h |  3 ++


No users?


  2 files changed, 59 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 33ad0cfbd54c..fac423d2cb73 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -276,10 +276,12 @@ drm_get_buddy(struct drm_buddy_block *block)
  }
  EXPORT_SYMBOL(drm_get_buddy);
  
-static void __drm_buddy_free(struct drm_buddy *mm,

-struct drm_buddy_block *block)
+static unsigned int __drm_buddy_free(struct drm_buddy *mm,
+struct drm_buddy_block *block,
+bool defrag)
  {
struct drm_buddy_block *parent;
+   unsigned int order;
  
  	while ((parent = block->parent)) {

struct drm_buddy_block *buddy;
@@ -289,12 +291,14 @@ static void __drm_buddy_free(struct drm_buddy *mm,
if (!drm_buddy_block_is_free(buddy))
break;
  
-		if (drm_buddy_block_is_clear(block) !=

-   drm_buddy_block_is_clear(buddy))
-   break;
+   if (!defrag) {
+   if (drm_buddy_block_is_clear(block) !=
+   drm_buddy_block_is_clear(buddy))
+   break;
  
-		if (drm_buddy_block_is_clear(block))

-   mark_cleared(parent);
+   if (drm_buddy_block_is_clear(block))
+   mark_cleared(parent);
+   }


Maybe check if the two blocks are incompatible and chuck a warn if they 
are not? Main thing is not to hide issues with split blocks that should 
have been merged before.


  
  		list_del(>link);
  
@@ -304,8 +308,49 @@ static void __drm_buddy_free(struct drm_buddy *mm,

block = parent;
}
  
+	order = drm_buddy_block_order(block);

mark_free(mm, block);
+
+   return order;
+}
+
+/**
+ * drm_buddy_defrag - Defragmentation routine
+ *
+ * @mm: DRM buddy manager
+ * @min_order: minimum order in the freelist to begin
+ * the defragmentation process
+ *
+ * Driver calls the defragmentation function when the
+ * requested memory allocation returns -ENOSPC.
+ */
+void drm_buddy_defrag(struct drm_buddy *mm,
+ unsigned int min_order)


Just wondering if we need "full defag" also? We would probably need to 
call this at fini() anyway.



+{
+   struct drm_buddy_block *block;
+   struct list_head *list;
+   unsigned int order;
+   int i;
+
+   if (min_order > mm->max_order)
+   return;
+
+   for (i = min_order - 1; i >= 0; i--) {


Need to be careful with min_order = 0 ?


+   list = >free_list[i];
+   if (list_empty(list))
+   continue;
+
+   list_for_each_entry_reverse(block, list, link) {


Don't we need the safe_reverse() variant here, since this is removing 
from the list?



+   if (!block->parent)
+   continue;
+
+   order = __drm_buddy_free(mm, block, 1);
+   if (order >= min_order)
+   return;
+   }
+   }
  }
+EXPORT_SYMBOL(drm_buddy_defrag);
  
  /**

   * drm_buddy_free_block - free a block
@@ -321,7 +366,7 @@ void drm_buddy_free_block(struct drm_buddy *mm,
if (drm_buddy_block_is_clear(block))
mm->clear_avail += drm_buddy_block_size(mm, block);
  
-	__drm_buddy_free(mm, block);

+   __drm_buddy_free(mm, block, 0);
  }
  EXPORT_SYMBOL(drm_buddy_free_block);
  
@@ -470,7 +515,7 @@ __alloc_range_bias(struct drm_buddy *mm,

if (buddy &&
(drm_buddy_block_is_free(block) &&
 drm_buddy_block_is_free(buddy)))
-   __drm_buddy_free(mm, block);
+   __drm_buddy_free(mm, block, 0);
return ERR_PTR(err);
  }
  
@@ -588,7 +633,7 @@ alloc_from_freelist(struct drm_buddy *mm,
  
  err_undo:

if (tmp != order)
-   __drm_buddy_free(mm, block);
+   __drm_buddy_free(mm, block, 0);
return ERR_PTR(err);
  }
  
@@ -668,7 +713,7 @@ static int __alloc_range(struct drm_buddy *mm,

if (buddy &&
(drm_buddy_block_is_free(block) &&
 drm_buddy_block_is_free(buddy)))
-   __drm_buddy_free(mm, block);
+   __drm_buddy_free(mm, block, 0);
  
  err_free:

if (err == -ENOSPC && total_allocated_on_err) {
diff --git a/include/drm/drm_buddy.h b/include/drm/drm_buddy.h
index d81c596dfa38..d0f63e7b5915 100644
--- 

Re: [PATCH v6 1/3] drm/buddy: Implement tracking clear page feature

[Matthew Auld]

On 08/02/2024 15:49, Arunpravin Paneer Selvam wrote:

- Add tracking clear page feature.

- Driver should enable the DRM_BUDDY_CLEARED flag if it
   successfully clears the blocks in the free path. On the otherhand,
   DRM buddy marks each block as cleared.

- Track the available cleared pages size

- If driver requests cleared memory we prefer cleared memory
   but fallback to uncleared if we can't find the cleared blocks.
   when driver requests uncleared memory we try to use uncleared but
   fallback to cleared memory if necessary.

- When a block gets freed we clear it and mark the freed block as cleared,
   when there are buddies which are cleared as well we can merge them.
   Otherwise, we prefer to keep the blocks as separated.

v1: (Christian)
   - Depends on the flag check DRM_BUDDY_CLEARED, enable the block as
 cleared. Else, reset the clear flag for each block in the list.

   - For merging the 2 cleared blocks compare as below,
 drm_buddy_is_clear(block) != drm_buddy_is_clear(buddy)

v2: (Matthew)
   - Add a wrapper drm_buddy_free_list_internal for the freeing of blocks
 operation within drm buddy.
   - Write a macro block_incompatible() to allocate the required blocks.
   - Update the xe driver for the drm_buddy_free_list change in arguments.

Signed-off-by: Arunpravin Paneer Selvam 
Signed-off-by: Matthew Auld 
Suggested-by: Christian König 


Probably needs a new unit test.

I think we are missing something to forcefully re-merge everything at 
fini()? In theory we can just call the defrag routine. Otherwise we 
might trigger various warnings since the root(s) might still be split.


Also one nit below. Otherwise I think looks good.


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c  |   6 +-
  drivers/gpu/drm/drm_buddy.c   | 192 ++
  drivers/gpu/drm/i915/i915_ttm_buddy_manager.c |   6 +-
  drivers/gpu/drm/tests/drm_buddy_test.c|  10 +-
  drivers/gpu/drm/xe/xe_ttm_vram_mgr.c  |   4 +-
  include/drm/drm_buddy.h   |  18 +-
  6 files changed, 187 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 8db880244324..c0c851409241 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -571,7 +571,7 @@ static int amdgpu_vram_mgr_new(struct ttm_resource_manager 
*man,
return 0;
  
  error_free_blocks:

-   drm_buddy_free_list(mm, >blocks);
+   drm_buddy_free_list(mm, >blocks, 0);
mutex_unlock(>lock);
  error_fini:
ttm_resource_fini(man, >base);
@@ -604,7 +604,7 @@ static void amdgpu_vram_mgr_del(struct ttm_resource_manager 
*man,
  
  	amdgpu_vram_mgr_do_reserve(man);
  
-	drm_buddy_free_list(mm, >blocks);

+   drm_buddy_free_list(mm, >blocks, 0);
mutex_unlock(>lock);
  
  	atomic64_sub(vis_usage, >vis_usage);

@@ -912,7 +912,7 @@ void amdgpu_vram_mgr_fini(struct amdgpu_device *adev)
kfree(rsv);
  
  	list_for_each_entry_safe(rsv, temp, >reserved_pages, blocks) {

-   drm_buddy_free_list(>mm, >allocated);
+   drm_buddy_free_list(>mm, >allocated, 0);
kfree(rsv);
}
if (!adev->gmc.is_app_apu)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index f57e6d74fb0e..33ad0cfbd54c 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -57,6 +57,16 @@ static void list_insert_sorted(struct drm_buddy *mm,
__list_add(>link, node->link.prev, >link);
  }
  
+static void clear_reset(struct drm_buddy_block *block)

+{
+   block->header &= ~DRM_BUDDY_HEADER_CLEAR;
+}
+
+static void mark_cleared(struct drm_buddy_block *block)
+{
+   block->header |= DRM_BUDDY_HEADER_CLEAR;
+}
+
  static void mark_allocated(struct drm_buddy_block *block)
  {
block->header &= ~DRM_BUDDY_HEADER_STATE;
@@ -223,6 +233,12 @@ static int split_block(struct drm_buddy *mm,
mark_free(mm, block->left);
mark_free(mm, block->right);
  
+	if (drm_buddy_block_is_clear(block)) {

+   mark_cleared(block->left);
+   mark_cleared(block->right);
+   clear_reset(block);
+   }
+
mark_split(block);
  
  	return 0;

@@ -273,6 +289,13 @@ static void __drm_buddy_free(struct drm_buddy *mm,
if (!drm_buddy_block_is_free(buddy))
break;
  
+		if (drm_buddy_block_is_clear(block) !=

+   drm_buddy_block_is_clear(buddy))
+   break;
+
+   if (drm_buddy_block_is_clear(block))
+   mark_cleared(parent);
+
list_del(>link);
  
  		drm_block_free(mm, block);

@@ -295,26 +318,61 @@ void drm_buddy_free_block(struct drm_buddy *mm,
  {
BUG_ON(!drm_buddy_block_is_allocated(block));
mm->avail += drm_buddy_block_size(mm, block);
+   if (drm_buddy_block_is_clear(block))
+ 

Re: [PATCH] drm/buddy: Modify duplicate list_splice_tail call

[Christian König]

Am 16.02.24 um 12:46 schrieb Arunpravin Paneer Selvam:



On 2/16/2024 4:41 PM, Matthew Auld wrote:

On 16/02/2024 10:00, Arunpravin Paneer Selvam wrote:

Remove the duplicate list_splice_tail call when the
total_allocated < size condition is true.

Cc:  # 6.7+
Fixes: 8746c6c9dfa3 ("drm/buddy: Fix alloc_range() error handling 
code")

Reported-by: Bert Karwatzki 
Signed-off-by: Arunpravin Paneer Selvam 


---
  drivers/gpu/drm/drm_buddy.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index c1a99bf4dffd..c4222b886db7 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -538,13 +538,13 @@ static int __alloc_range(struct drm_buddy *mm,
  list_add(>left->tmp_link, dfs);
  } while (1);
  -    list_splice_tail(, blocks);
-
  if (total_allocated < size) {
  err = -ENOSPC;
  goto err_free;
  }
  +    list_splice_tail(, blocks);


Sigh. Can we extend the unit test(s) to catch this?

Sure, Let me check.


In the meantime I'm going to push this one to drm-misc-fixes.

Regards,
Christian.



Regards,
Arun.


Reviewed-by: Matthew Auld 


+
  return 0;
    err_undo:

base-commit: a64056bb5a3215bd31c8ce17d609ba0f4d5c55ea

Re: [PATCH v6 1/3] drm/buddy: Implement tracking clear page feature

[Arunpravin Paneer Selvam]

Hi Matthew,

Could you review the v6?

Thanks,
Arun.

On 2/8/2024 9:19 PM, Arunpravin Paneer Selvam wrote:

- Add tracking clear page feature.

- Driver should enable the DRM_BUDDY_CLEARED flag if it
   successfully clears the blocks in the free path. On the otherhand,
   DRM buddy marks each block as cleared.

- Track the available cleared pages size

- If driver requests cleared memory we prefer cleared memory
   but fallback to uncleared if we can't find the cleared blocks.
   when driver requests uncleared memory we try to use uncleared but
   fallback to cleared memory if necessary.

- When a block gets freed we clear it and mark the freed block as cleared,
   when there are buddies which are cleared as well we can merge them.
   Otherwise, we prefer to keep the blocks as separated.

v1: (Christian)
   - Depends on the flag check DRM_BUDDY_CLEARED, enable the block as
 cleared. Else, reset the clear flag for each block in the list.

   - For merging the 2 cleared blocks compare as below,
 drm_buddy_is_clear(block) != drm_buddy_is_clear(buddy)

v2: (Matthew)
   - Add a wrapper drm_buddy_free_list_internal for the freeing of blocks
 operation within drm buddy.
   - Write a macro block_incompatible() to allocate the required blocks.
   - Update the xe driver for the drm_buddy_free_list change in arguments.

Signed-off-by: Arunpravin Paneer Selvam 
Signed-off-by: Matthew Auld 
Suggested-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c  |   6 +-
  drivers/gpu/drm/drm_buddy.c   | 192 ++
  drivers/gpu/drm/i915/i915_ttm_buddy_manager.c |   6 +-
  drivers/gpu/drm/tests/drm_buddy_test.c|  10 +-
  drivers/gpu/drm/xe/xe_ttm_vram_mgr.c  |   4 +-
  include/drm/drm_buddy.h   |  18 +-
  6 files changed, 187 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 8db880244324..c0c851409241 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -571,7 +571,7 @@ static int amdgpu_vram_mgr_new(struct ttm_resource_manager 
*man,
return 0;
  
  error_free_blocks:

-   drm_buddy_free_list(mm, >blocks);
+   drm_buddy_free_list(mm, >blocks, 0);
mutex_unlock(>lock);
  error_fini:
ttm_resource_fini(man, >base);
@@ -604,7 +604,7 @@ static void amdgpu_vram_mgr_del(struct ttm_resource_manager 
*man,
  
  	amdgpu_vram_mgr_do_reserve(man);
  
-	drm_buddy_free_list(mm, >blocks);

+   drm_buddy_free_list(mm, >blocks, 0);
mutex_unlock(>lock);
  
  	atomic64_sub(vis_usage, >vis_usage);

@@ -912,7 +912,7 @@ void amdgpu_vram_mgr_fini(struct amdgpu_device *adev)
kfree(rsv);
  
  	list_for_each_entry_safe(rsv, temp, >reserved_pages, blocks) {

-   drm_buddy_free_list(>mm, >allocated);
+   drm_buddy_free_list(>mm, >allocated, 0);
kfree(rsv);
}
if (!adev->gmc.is_app_apu)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index f57e6d74fb0e..33ad0cfbd54c 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -57,6 +57,16 @@ static void list_insert_sorted(struct drm_buddy *mm,
__list_add(>link, node->link.prev, >link);
  }
  
+static void clear_reset(struct drm_buddy_block *block)

+{
+   block->header &= ~DRM_BUDDY_HEADER_CLEAR;
+}
+
+static void mark_cleared(struct drm_buddy_block *block)
+{
+   block->header |= DRM_BUDDY_HEADER_CLEAR;
+}
+
  static void mark_allocated(struct drm_buddy_block *block)
  {
block->header &= ~DRM_BUDDY_HEADER_STATE;
@@ -223,6 +233,12 @@ static int split_block(struct drm_buddy *mm,
mark_free(mm, block->left);
mark_free(mm, block->right);
  
+	if (drm_buddy_block_is_clear(block)) {

+   mark_cleared(block->left);
+   mark_cleared(block->right);
+   clear_reset(block);
+   }
+
mark_split(block);
  
  	return 0;

@@ -273,6 +289,13 @@ static void __drm_buddy_free(struct drm_buddy *mm,
if (!drm_buddy_block_is_free(buddy))
break;
  
+		if (drm_buddy_block_is_clear(block) !=

+   drm_buddy_block_is_clear(buddy))
+   break;
+
+   if (drm_buddy_block_is_clear(block))
+   mark_cleared(parent);
+
list_del(>link);
  
  		drm_block_free(mm, block);

@@ -295,26 +318,61 @@ void drm_buddy_free_block(struct drm_buddy *mm,
  {
BUG_ON(!drm_buddy_block_is_allocated(block));
mm->avail += drm_buddy_block_size(mm, block);
+   if (drm_buddy_block_is_clear(block))
+   mm->clear_avail += drm_buddy_block_size(mm, block);
+
__drm_buddy_free(mm, block);
  }
  EXPORT_SYMBOL(drm_buddy_free_block);
  
-/**

- * drm_buddy_free_list - free blocks
- *
- * @mm: DRM buddy manager
- * @objects: input 

Re: [PATCH] drm/buddy: Modify duplicate list_splice_tail call

[Arunpravin Paneer Selvam]

On 2/16/2024 4:41 PM, Matthew Auld wrote:

On 16/02/2024 10:00, Arunpravin Paneer Selvam wrote:

Remove the duplicate list_splice_tail call when the
total_allocated < size condition is true.

Cc:  # 6.7+
Fixes: 8746c6c9dfa3 ("drm/buddy: Fix alloc_range() error handling code")
Reported-by: Bert Karwatzki 
Signed-off-by: Arunpravin Paneer Selvam 


---
  drivers/gpu/drm/drm_buddy.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index c1a99bf4dffd..c4222b886db7 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -538,13 +538,13 @@ static int __alloc_range(struct drm_buddy *mm,
  list_add(>left->tmp_link, dfs);
  } while (1);
  -    list_splice_tail(, blocks);
-
  if (total_allocated < size) {
  err = -ENOSPC;
  goto err_free;
  }
  +    list_splice_tail(, blocks);


Sigh. Can we extend the unit test(s) to catch this?

Sure, Let me check.

Regards,
Arun.


Reviewed-by: Matthew Auld 


+
  return 0;
    err_undo:

base-commit: a64056bb5a3215bd31c8ce17d609ba0f4d5c55ea

Re: [PATCH] drm/buddy: Modify duplicate list_splice_tail call

[Matthew Auld]

On 16/02/2024 10:00, Arunpravin Paneer Selvam wrote:

Remove the duplicate list_splice_tail call when the
total_allocated < size condition is true.

Cc:  # 6.7+
Fixes: 8746c6c9dfa3 ("drm/buddy: Fix alloc_range() error handling code")
Reported-by: Bert Karwatzki 
Signed-off-by: Arunpravin Paneer Selvam 
---
  drivers/gpu/drm/drm_buddy.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index c1a99bf4dffd..c4222b886db7 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -538,13 +538,13 @@ static int __alloc_range(struct drm_buddy *mm,
list_add(>left->tmp_link, dfs);
} while (1);
  
-	list_splice_tail(, blocks);

-
if (total_allocated < size) {
err = -ENOSPC;
goto err_free;
}
  
+	list_splice_tail(, blocks);


Sigh. Can we extend the unit test(s) to catch this?

Reviewed-by: Matthew Auld 


+
return 0;
  
  err_undo:


base-commit: a64056bb5a3215bd31c8ce17d609ba0f4d5c55ea

Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors

[Christian König]

Am 02.02.24 um 16:28 schrieb Hamza Mahfooz:

We want programs besides the compositor to be able to enable or disable
panel power saving features.


Well I don't know the full background, but that is usually a no-go.


However, since they are currently only
configurable through DRM properties, that isn't possible.


Maybe I'm repeating others, but I wanted to point it out explicitly: 
This is intentional and not that easily changeable.


If it's a common DRM property, e.g. something standardized among all 
drivers, then amdgpu is not allowed to circumvent that.


Regards,
Christian.


  So, to remedy
that issue introduce a new "panel_power_savings" sysfs attribute.

Cc: Mario Limonciello 
Signed-off-by: Hamza Mahfooz 
---
v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
 commit when setting the value, call sysfs_remove_group() in
 amdgpu_dm_connector_unregister() and add some documentation.
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++
  1 file changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 8590c9f1dda6..3c62489d03dc 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct 
drm_connector *connector,
return ret;
  }
  
+/**

+ * DOC: panel power savings
+ *
+ * The display manager allows you to set your desired **panel power savings**
+ * level (between 0-4, with 0 representing off), e.g. using the following::
+ *
+ *   # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
+ *
+ * Modifying this value can have implications on color accuracy, so tread
+ * carefully.
+ */
+
+static ssize_t panel_power_savings_show(struct device *device,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct drm_connector *connector = dev_get_drvdata(device);
+   struct drm_device *dev = connector->dev;
+   u8 val;
+
+   drm_modeset_lock(>mode_config.connection_mutex, NULL);
+   val = to_dm_connector_state(connector->state)->abm_level ==
+   ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
+   to_dm_connector_state(connector->state)->abm_level;
+   drm_modeset_unlock(>mode_config.connection_mutex);
+
+   return sysfs_emit(buf, "%u\n", val);
+}
+
+static ssize_t panel_power_savings_store(struct device *device,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct drm_connector *connector = dev_get_drvdata(device);
+   struct drm_device *dev = connector->dev;
+   long val;
+   int ret;
+
+   ret = kstrtol(buf, 0, );
+
+   if (ret)
+   return ret;
+
+   if (val < 0 || val > 4)
+   return -EINVAL;
+
+   drm_modeset_lock(>mode_config.connection_mutex, NULL);
+   to_dm_connector_state(connector->state)->abm_level = val ?:
+   ABM_LEVEL_IMMEDIATE_DISABLE;
+   drm_modeset_unlock(>mode_config.connection_mutex);
+
+   drm_kms_helper_hotplug_event(dev);
+
+   return count;
+}
+
+static DEVICE_ATTR_RW(panel_power_savings);
+
+static struct attribute *amdgpu_attrs[] = {
+   _attr_panel_power_savings.attr,
+   NULL
+};
+
+static const struct attribute_group amdgpu_group = {
+   .name = "amdgpu",
+   .attrs = amdgpu_attrs
+};
+
  static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
  {
struct amdgpu_dm_connector *amdgpu_dm_connector = 
to_amdgpu_dm_connector(connector);
  
+	sysfs_remove_group(>kdev->kobj, _group);

drm_dp_aux_unregister(_dm_connector->dm_dp_aux.aux);
  }
  
@@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct drm_connector *connector)

to_amdgpu_dm_connector(connector);
int r;
  
+	if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {

+   r = sysfs_create_group(>kdev->kobj,
+  _group);
+   if (r)
+   return r;
+   }
+
amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
  
  	if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||

[PATCH] drm/buddy: Modify duplicate list_splice_tail call

[Arunpravin Paneer Selvam]

Remove the duplicate list_splice_tail call when the
total_allocated < size condition is true.

Cc:  # 6.7+
Fixes: 8746c6c9dfa3 ("drm/buddy: Fix alloc_range() error handling code")
Reported-by: Bert Karwatzki 
Signed-off-by: Arunpravin Paneer Selvam 
---
 drivers/gpu/drm/drm_buddy.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index c1a99bf4dffd..c4222b886db7 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -538,13 +538,13 @@ static int __alloc_range(struct drm_buddy *mm,
list_add(>left->tmp_link, dfs);
} while (1);
 
-   list_splice_tail(, blocks);
-
if (total_allocated < size) {
err = -ENOSPC;
goto err_free;
}
 
+   list_splice_tail(, blocks);
+
return 0;
 
 err_undo:

base-commit: a64056bb5a3215bd31c8ce17d609ba0f4d5c55ea
-- 
2.25.1

Re: 7840U amdgpu MMVM_L2_PROTECTION_FAULT_STATUS

[Christian König]

Can you bisect where exactly between 6.6.0 and 6.7.4 the problems started?

Thanks,
Christian.

Am 15.02.24 um 16:59 schrieb Michael Zimmermann:

I have a Framework 13 with a 7840U and started having massive GPU
driver issues a few weeks ago (including system freezes).
Unfortunately the information of when exactly this started to happen
is gone, but It should be somewhere in between 6.6.0 and 6.7.4.
I got many different and random dmesg-errors and system behaviors, but
I currently can only reproduce one, so let's focus on that for now.

First some basic info:
I'm on Arch Linux using the `linux` kernel package.(currently at 6.7.4).
I have an external monitor connected via a thinkpad thunderbolt 4 dock.
I am using amdgpu.sg_display=0 and VRAM sharing is configured to
UMA_GAME_OPTIMIZED in the firmware settings.

If I start playing a youtube video in firefox with hardware
acceleration enabled, it stutters until it stops playing after a few
seconds. I can see this in the kernel log. I see this multiple times
for many different addresses.
[ 5641.070540] amdgpu :c1:00.0: amdgpu: [mmhub] page fault
(src_id:0 ring:40 vmid:1 pasid:32786, for process RDD Process pid 3680
thread firefox-bi:cs0 pid 3852)
[ 5641.070549] amdgpu :c1:00.0: amdgpu:   in page starting at
address 0x0002 from client 18
[ 5641.070553] amdgpu :c1:00.0: amdgpu:
MMVM_L2_PROTECTION_FAULT_STATUS:0x00143A51
[ 5641.070556] amdgpu :c1:00.0: amdgpu:  Faulty UTCL2 client
ID: unknown (0x1d)
[ 5641.070559] amdgpu :c1:00.0: amdgpu:  MORE_FAULTS: 0x1
[ 5641.070561] amdgpu :c1:00.0: amdgpu:  WALKER_ERROR: 0x0
[ 5641.070563] amdgpu :c1:00.0: amdgpu:  PERMISSION_FAULTS: 0x5
[ 5641.070565] amdgpu :c1:00.0: amdgpu:  MAPPING_ERROR: 0x0
[ 5641.070567] amdgpu :c1:00.0: amdgpu:  RW: 0x1

Thanks
Michael

Re: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers

[kernel test robot]

Hi Mario,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip 
linus/master v6.8-rc4 next-20240216]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/drm-Stop-using-select-ACPI_VIDEO-in-all-drivers/20240215-055936
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240214215756.6530-2-mario.limonciello%40amd.com
patch subject: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers
config: powerpc-kismet-CONFIG_FB_BACKLIGHT-CONFIG_PMAC_BACKLIGHT-0-0 
(https://download.01.org/0day-ci/archive/20240216/202402161747.txwr5bw4-...@intel.com/config)
reproduce: 
(https://download.01.org/0day-ci/archive/20240216/202402161747.txwr5bw4-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202402161747.txwr5bw4-...@intel.com/

kismet warnings: (new ones prefixed by >>)
>> kismet: WARNING: unmet direct dependencies detected for FB_BACKLIGHT when 
>> selected by PMAC_BACKLIGHT
   .config:247:warning: symbol value 'n' invalid for AIC79XX_DEBUG_MASK
   .config:251:warning: symbol value 'n' invalid for PANEL_LCD_PIN_E
   .config:262:warning: symbol value 'n' invalid for SATA_MOBILE_LPM_POLICY
   .config:356:warning: symbol value 'n' invalid for PSTORE_BLK_MAX_REASON
   .config:407:warning: symbol value 'n' invalid for 
PPC_EARLY_DEBUG_16550_PHYSADDR
   .config:462:warning: symbol value 'n' invalid for KFENCE_SAMPLE_INTERVAL
   .config:563:warning: symbol value 'n' invalid for 
PPC_EARLY_DEBUG_HVSI_VTERMNO
   .config:663:warning: symbol value 'n' invalid for DRM_XE_JOB_TIMEOUT_MIN
   .config:677:warning: symbol value 'n' invalid for CRYPTO_DEV_QCE_SW_MAX_LEN
   .config:710:warning: symbol value 'n' invalid for AIC79XX_CMDS_PER_DEVICE
   .config:725:warning: symbol value 'n' invalid for DATA_SHIFT
   .config:765:warning: symbol value 'n' invalid for PANEL_LCD_PIN_SDA
   .config:793:warning: symbol value 'n' invalid for PANEL_LCD_CHARSET
   .config:854:warning: symbol value 'n' invalid for SND_AC97_POWER_SAVE_DEFAULT
   .config:904:warning: symbol value 'n' invalid for MAGIC_SYSRQ_DEFAULT_ENABLE
   .config:922:warning: symbol value 'n' invalid for 
DRM_I915_MAX_REQUEST_BUSYWAIT
   .config:958:warning: symbol value 'n' invalid for SND_AT73C213_TARGET_BITRATE
   .config:974:warning: symbol value 'n' invalid for DRM_XE_PREEMPT_TIMEOUT_MIN
   .config:986:warning: symbol value 'n' invalid for VMCP_CMA_SIZE
   .config:1270:warning: symbol value 'n' invalid for MTDRAM_ERASE_SIZE
   .config:1365:warning: symbol value 'n' invalid for SERIAL_UARTLITE_NR_UARTS
   .config:1398:warning: symbol value 'n' invalid for AIC79XX_RESET_DELAY_MS
   .config:1548:warning: symbol value 'n' invalid for LEGACY_PTY_COUNT
   .config:1673:warning: symbol value 'n' invalid for LOWMEM_CAM_NUM
   .config:1723:warning: symbol value 'n' invalid for AIC7XXX_RESET_DELAY_MS
   .config:1805:warning: symbol value 'n' invalid for PPC_MEMCONS_OUTPUT_SIZE
   .config:1874:warning: symbol value 'n' invalid for LOWMEM_SIZE
   .config:1899:warning: symbol value 'n' invalid for IBM_EMAC_POLL_WEIGHT
   .config:2030:warning: symbol value 'n' invalid for PANEL_PROFILE
   .config:2042:warning: symbol value 'n' invalid for DRM_I915_STOP_TIMEOUT
   .config:2054:warning: symbol value 'n' invalid for 
MTD_REDBOOT_DIRECTORY_BLOCK
   .config:2180:warning: symbol value 'n' invalid for KCOV_IRQ_AREA_SIZE
   .config:2304:warning: symbol value 'n' invalid for SND_HDA_PREALLOC_SIZE
   .config:2510:warning: symbol value 'n' invalid for PANEL_LCD_BWIDTH
   .config:2523:warning: symbol value 'n' invalid for DRM_XE_TIMESLICE_MAX
   .config:2770:warning: symbol value 'n' invalid for PANEL_PARPORT
   .config:2864:warning: symbol value 'n' invalid for 
SND_SOC_SOF_DEBUG_IPC_FLOOD_TEST_NUM
   .config:2868:warning: symbol value 'n' invalid for NOUVEAU_DEBUG_DEFAULT
   .config:3081:warning: symbol value 'n' invalid for KCSAN_REPORT_ONCE_IN_MS
   .config:3189:warning: symbol value 'n' invalid for KCSAN_UDELAY_INTERRUPT
   .config:3214:warning: symbol value 'n' invalid for PANEL_LCD_PIN_BL
   .config:3227:warning: symbol value 'n' invalid for PSTORE_BLK_CONSOLE_SIZE
   .config:3237:warning: symbol value 'n' invalid for 
DEBUG_OBJECTS_ENABLE_DEFAULT
   .config:3244:warning: symbol value 'n' invalid for INITRAMFS_ROOT_GID
   .config:3335:warning: symbol value 'n' invalid for 
FTRACE_RECORD_RECURSION_SIZE
   .config:3362:warning: symbol value 'n' invalid for ATM_FORE200E_T

Re: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers

[kernel test robot]

Hi Mario,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next-fixes drm-tip/drm-tip 
linus/master v6.8-rc4 next-20240216]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Mario-Limonciello/drm-Stop-using-select-ACPI_VIDEO-in-all-drivers/20240215-055936
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20240214215756.6530-2-mario.limonciello%40amd.com
patch subject: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers
config: alpha-kismet-CONFIG_FB_BACKLIGHT-CONFIG_FB_NVIDIA-0-0 
(https://download.01.org/0day-ci/archive/20240216/202402161633.zhmogq2g-...@intel.com/config)
reproduce: 
(https://download.01.org/0day-ci/archive/20240216/202402161633.zhmogq2g-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202402161633.zhmogq2g-...@intel.com/

kismet warnings: (new ones prefixed by >>)
>> kismet: WARNING: unmet direct dependencies detected for FB_BACKLIGHT when 
>> selected by FB_NVIDIA
   .config:98:warning: symbol value 'n' invalid for SERIAL_AR933X_NR_UARTS
   .config:208:warning: symbol value 'n' invalid for 
USB_GADGET_STORAGE_NUM_BUFFERS
   .config:244:warning: symbol value 'n' invalid for SATA_MOBILE_LPM_POLICY
   .config:345:warning: symbol value 'n' invalid for PSTORE_BLK_MAX_REASON
   .config:427:warning: symbol value 'n' invalid for AIC79XX_DEBUG_MASK
   .config:432:warning: symbol value 'n' invalid for KFENCE_SAMPLE_INTERVAL
   .config:620:warning: symbol value 'n' invalid for DRM_XE_JOB_TIMEOUT_MIN
   .config:652:warning: symbol value 'n' invalid for CRYPTO_DEV_QCE_SW_MAX_LEN
   .config:687:warning: symbol value 'n' invalid for PANEL_LCD_PIN_E
   .config:757:warning: symbol value 'n' invalid for PANEL_LCD_CHARSET
   .config:800:warning: symbol value 'n' invalid for SND_AC97_POWER_SAVE_DEFAULT
   .config:848:warning: symbol value 'n' invalid for MAGIC_SYSRQ_DEFAULT_ENABLE
   .config:853:warning: symbol value 'n' invalid for AIC79XX_CMDS_PER_DEVICE
   .config:865:warning: symbol value 'n' invalid for 
DRM_I915_MAX_REQUEST_BUSYWAIT
   .config:896:warning: symbol value 'n' invalid for SND_AT73C213_TARGET_BITRATE
   .config:907:warning: symbol value 'n' invalid for DRM_XE_PREEMPT_TIMEOUT_MIN
   .config:913:warning: symbol value 'n' invalid for PANEL_LCD_PIN_SDA
   .config:915:warning: symbol value 'n' invalid for NET_EMATCH_STACK
   .config:917:warning: symbol value 'n' invalid for VMCP_CMA_SIZE
   .config:1149:warning: symbol value 'n' invalid for RCU_CPU_STALL_TIMEOUT
   .config:1176:warning: symbol value 'n' invalid for MTDRAM_ERASE_SIZE
   .config:1282:warning: symbol value 'n' invalid for SERIAL_UARTLITE_NR_UARTS
   .config:1453:warning: symbol value 'n' invalid for LEGACY_PTY_COUNT
   .config:1591:warning: symbol value 'n' invalid for AIC7XXX_RESET_DELAY_MS
   .config:1592:warning: symbol value 'n' invalid for WATCHDOG_OPEN_TIMEOUT
   .config:1710:warning: symbol value 'n' invalid for AIC79XX_RESET_DELAY_MS
   .config:1757:warning: symbol value 'n' invalid for IBM_EMAC_POLL_WEIGHT
   .config:1891:warning: symbol value 'n' invalid for DRM_I915_STOP_TIMEOUT
   .config:2178:warning: symbol value 'n' invalid for RCU_FANOUT_LEAF
   .config:2192:warning: symbol value 'n' invalid for KCOV_IRQ_AREA_SIZE
   .config:2327:warning: symbol value 'n' invalid for DRM_XE_TIMESLICE_MAX
   .config:2328:warning: symbol value 'n' invalid for PANEL_LCD_BWIDTH
   .config:2378:warning: symbol value 'n' invalid for 
MTD_REDBOOT_DIRECTORY_BLOCK
   .config:2570:warning: symbol value 'n' invalid for PANEL_PARPORT
   .config:2655:warning: symbol value 'n' invalid for NOUVEAU_DEBUG_DEFAULT
   .config:2846:warning: symbol value 'n' invalid for KCSAN_REPORT_ONCE_IN_MS
   .config:2860:warning: symbol value 'n' invalid for 
SND_SOC_SOF_DEBUG_IPC_FLOOD_TEST_NUM
   .config:2934:warning: symbol value 'n' invalid for XEN_MEMORY_HOTPLUG_LIMIT
   .config:2944:warning: symbol value 'n' invalid for KCSAN_UDELAY_INTERRUPT
   .config:2969:warning: symbol value 'n' invalid for PANEL_LCD_PIN_BL
   .config:2995:warning: symbol value 'n' invalid for INITRAMFS_ROOT_GID
   .config:3101:warning: symbol value 'n' invalid for ATM_FORE200E_TX_RETRY
   .config:3142:warning: symbol value 'n' invalid for 
FB_OMAP2_DSS_MIN_FCK_PER_PCK
   .config:3223:warning: symbol value 'n' invalid for PSTORE_BLK_CONSOLE_SIZE
   .config:3344:warning: symbol value 'n' invalid for BOOKE_WDT_DEFAULT_TIMEOUT
   .config:3426:warning: symbol value 'n' invalid for KCSAN_UDELAY_TA

Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors

[Jani Nikula]

On Thu, 15 Feb 2024, Mario Limonciello  wrote:
> I feel the solution to these concerns is that we should make a knob that 
> controls whether the DRM property is created or the sysfs file is 
> created but not let them happen simultaneously.

*insert the eyeballs emoji here*

I mean no matter what the problem is, this sounds like the solution is
worse than the problem!


BR,
Jani.


-- 
Jani Nikula, Intel

[PATCH] drm/amd/display: fix a possible NULL dereference bug

[Harshit Mogalapalli]

Smatch warns:
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:136
dc_dmub_srv_cmd_list_queue_execute() warn: variable dereferenced
before check 'dc_dmub_srv' (see line 131)

Fix this by moving the dereference "dc_dmub_srv->ctx" after the NULL check.

Fixes: 028bac583449 ("drm/amd/display: decouple dmcub execution to reduce lock 
granularity")
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
Closes: https://lore.kernel.org/r/202311141141.golapxd5-...@intel.com/
Signed-off-by: Harshit Mogalapalli 
---
Only compile tested
---
 drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c 
b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
index 0bc32537e2eb..a4bd46ec6da4 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
@@ -128,7 +128,7 @@ bool dc_dmub_srv_cmd_list_queue_execute(struct dc_dmub_srv 
*dc_dmub_srv,
unsigned int count,
union dmub_rb_cmd *cmd_list)
 {
-   struct dc_context *dc_ctx = dc_dmub_srv->ctx;
+   struct dc_context *dc_ctx;
struct dmub_srv *dmub;
enum dmub_status status;
int i;
@@ -136,6 +136,7 @@ bool dc_dmub_srv_cmd_list_queue_execute(struct dc_dmub_srv 
*dc_dmub_srv,
if (!dc_dmub_srv || !dc_dmub_srv->dmub)
return false;
 
+   dc_ctx = dc_dmub_srv->ctx;
dmub = dc_dmub_srv->dmub;
 
for (i = 0 ; i < count; i++) {
-- 
2.39.3

2024 X.Org Board of Directors Elections Nomination period is NOW

[Christopher Michael]

We are seeking nominations for candidates for election to the X.Org 
Foundation Board of Directors. All X.Org Foundation members are eligible 
for election to the board.


Nominations for the 2024 election are now open and will remain open 
until 23:59 UTC on 26 February 2024.


The Board consists of directors elected from the membership. Each year, 
an election is held to bring the total number of directors to eight. The 
four members receiving the highest vote totals will serve as directors 
for two year terms.


The directors who received two year terms starting in 2023 were 
Arkadiusz Hiler, Christopher Michael, Lyude Paul, and Daniel Vetter. 
They will continue to serve until their term ends in 2024. Current 
directors whose term expires in 2024 are Emma Anholt, Mark Filion, 
Ricardo Garcia, and Alyssa Rosenzweig.



A director is expected to participate in the fortnightly IRC meeting to 
discuss current business and to attend the annual meeting of the X.Org 
Foundation, which will be held at a location determined in advance by 
the Board of Directors.


A member may nominate themselves or any other member they feel is 
qualified. Nominations should be sent to the Election Committee at 
electi...@x.org.


Nominees shall be required to be current members of the X.Org 
Foundation, and submit a personal statement of up to 200 words that will 
be provided to prospective voters. The collected statements, along with 
the statement of contribution to the X.Org Foundation in the member's 
account page on http://members.x.org, will be made available to all 
voters to help them make their voting decisions.


Nominations, membership applications or renewals and completed personal 
statements must be received no later than 23:59 UTC on 26 February 2024.


The slate of candidates will be published 04 March 2024 and candidate 
Q will begin then. The deadline for Xorg membership applications and 
renewals is 07 March 2024.



Cheers,

Christopher Michael, on behalf of the X.Org BoD

Re: [PATCH] drm/amd/display: Add 'replay' NULL check in 'edp_set_replay_allow_active()'

[Chung, ChiaHsuan (Tom)]

Reviewed-by: Tom Chung 

On 2/15/2024 9:31 PM, Srinivasan Shanmugam wrote:

In the first if statement, we're checking if 'replay' is NULL. But in
the second if statement, we're not checking if 'replay' is NULL again
before calling replay->funcs->replay_set_power_opt().

if (replay == NULL && force_static)
 return false;

...

if (link->replay_settings.replay_feature_enabled &&
 replay->funcs->replay_set_power_opt) {
replay->funcs->replay_set_power_opt(replay, *power_opts, panel_inst);
link->replay_settings.replay_power_opt_active = *power_opts;
}

If 'replay' is NULL, this will cause a null pointer dereference.

Fixes the below found by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_edp_panel_control.c:895
 edp_set_replay_allow_active() error: we previously assumed 'replay' could be 
null (see line 887)

Fixes: c7ddc0a800bc ("drm/amd/display: Add Functions to enable Freesync Panel 
Replay")
Cc: Bhawanpreet Lakha
Cc: Roman Li
Cc: Rodrigo Siqueira
Cc: Aurabindo Pillai
Cc: Tom Chung
Suggested-by: Tom Chung
Signed-off-by: Srinivasan Shanmugam
---
  .../drm/amd/display/dc/link/protocols/link_edp_panel_control.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c 
b/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
index 443215b96308..acfbbc638cc6 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
@@ -892,7 +892,8 @@ bool edp_set_replay_allow_active(struct dc_link *link, 
const bool *allow_active,
  
  	/* Set power optimization flag */

if (power_opts && link->replay_settings.replay_power_opt_active != 
*power_opts) {
-   if (link->replay_settings.replay_feature_enabled && 
replay->funcs->replay_set_power_opt) {
+   if (replay != NULL && link->replay_settings.replay_feature_enabled 
&&
+   replay->funcs->replay_set_power_opt) {
replay->funcs->replay_set_power_opt(replay, 
*power_opts, panel_inst);
link->replay_settings.replay_power_opt_active = 
*power_opts;
}

Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors

[Pekka Paalanen]

On Fri, 2 Feb 2024 10:28:35 -0500
Hamza Mahfooz  wrote:

> We want programs besides the compositor to be able to enable or disable
> panel power saving features.

Could you also explain why, in the commit message, please?

It is unexpected for arbitrary programs to be able to override the KMS
client, and certainly new ways to do so should not be added without an
excellent justification.

Maybe debugfs would be more appropriate if the purpose is only testing
rather than production environments?

> However, since they are currently only
> configurable through DRM properties, that isn't possible. So, to remedy
> that issue introduce a new "panel_power_savings" sysfs attribute.

When the DRM property was added, what was used as the userspace to
prove its workings?


Thanks,
pq

> 
> Cc: Mario Limonciello 
> Signed-off-by: Hamza Mahfooz 
> ---
> v2: hide ABM_LEVEL_IMMEDIATE_DISABLE in the read case, force an atomic
> commit when setting the value, call sysfs_remove_group() in
> amdgpu_dm_connector_unregister() and add some documentation.
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 76 +++
>  1 file changed, 76 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 8590c9f1dda6..3c62489d03dc 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6436,10 +6436,79 @@ int amdgpu_dm_connector_atomic_get_property(struct 
> drm_connector *connector,
>   return ret;
>  }
>  
> +/**
> + * DOC: panel power savings
> + *
> + * The display manager allows you to set your desired **panel power savings**
> + * level (between 0-4, with 0 representing off), e.g. using the following::
> + *
> + *   # echo 3 > /sys/class/drm/card0-eDP-1/amdgpu/panel_power_savings
> + *
> + * Modifying this value can have implications on color accuracy, so tread
> + * carefully.
> + */
> +
> +static ssize_t panel_power_savings_show(struct device *device,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct drm_connector *connector = dev_get_drvdata(device);
> + struct drm_device *dev = connector->dev;
> + u8 val;
> +
> + drm_modeset_lock(>mode_config.connection_mutex, NULL);
> + val = to_dm_connector_state(connector->state)->abm_level ==
> + ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
> + to_dm_connector_state(connector->state)->abm_level;
> + drm_modeset_unlock(>mode_config.connection_mutex);
> +
> + return sysfs_emit(buf, "%u\n", val);
> +}
> +
> +static ssize_t panel_power_savings_store(struct device *device,
> +  struct device_attribute *attr,
> +  const char *buf, size_t count)
> +{
> + struct drm_connector *connector = dev_get_drvdata(device);
> + struct drm_device *dev = connector->dev;
> + long val;
> + int ret;
> +
> + ret = kstrtol(buf, 0, );
> +
> + if (ret)
> + return ret;
> +
> + if (val < 0 || val > 4)
> + return -EINVAL;
> +
> + drm_modeset_lock(>mode_config.connection_mutex, NULL);
> + to_dm_connector_state(connector->state)->abm_level = val ?:
> + ABM_LEVEL_IMMEDIATE_DISABLE;
> + drm_modeset_unlock(>mode_config.connection_mutex);
> +
> + drm_kms_helper_hotplug_event(dev);
> +
> + return count;
> +}
> +
> +static DEVICE_ATTR_RW(panel_power_savings);
> +
> +static struct attribute *amdgpu_attrs[] = {
> + _attr_panel_power_savings.attr,
> + NULL
> +};
> +
> +static const struct attribute_group amdgpu_group = {
> + .name = "amdgpu",
> + .attrs = amdgpu_attrs
> +};
> +
>  static void amdgpu_dm_connector_unregister(struct drm_connector *connector)
>  {
>   struct amdgpu_dm_connector *amdgpu_dm_connector = 
> to_amdgpu_dm_connector(connector);
>  
> + sysfs_remove_group(>kdev->kobj, _group);
>   drm_dp_aux_unregister(_dm_connector->dm_dp_aux.aux);
>  }
>  
> @@ -6541,6 +6610,13 @@ amdgpu_dm_connector_late_register(struct drm_connector 
> *connector)
>   to_amdgpu_dm_connector(connector);
>   int r;
>  
> + if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> + r = sysfs_create_group(>kdev->kobj,
> +_group);
> + if (r)
> + return r;
> + }
> +
>   amdgpu_dm_register_backlight_device(amdgpu_dm_connector);
>  
>   if ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) ||



pgpg_X6fygXug.pgp
Description: OpenPGP digital signature