Re: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers
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
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
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/tests/drm_buddy: avoid 64-bit calculation
On 2/16/24 12:24, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The newly added drm_test_buddy_alloc_contiguous() test fails to link on
> 32-bit targets because of inadvertent 64-bit calculations:
>
> ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/tests/drm_buddy_test.ko]
> undefined!
> ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/tests/drm_buddy_test.ko]
> undefined!
>
>>From what I can tell, the numbers cannot possibly overflow a 32-bit size,
> so use different types for these.
>
> I noticed that the function has another possible flaw in that is mixes
> what it calls pages with 4KB units. This is a big confusing at best,
> or possibly broken when built on machines with larger pages.
>
> Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test")
> Signed-off-by: Arnd Bergmann
Tested-by: Randy Dunlap
Thanks.
> ---
> drivers/gpu/drm/tests/drm_buddy_test.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
> b/drivers/gpu/drm/tests/drm_buddy_test.c
> index fee6bec757d1..50a5f98cd5bd 100644
> --- a/drivers/gpu/drm/tests/drm_buddy_test.c
> +++ b/drivers/gpu/drm/tests/drm_buddy_test.c
> @@ -21,7 +21,8 @@ static inline u64 get_size(int order, u64 chunk_size)
>
> static void drm_test_buddy_alloc_contiguous(struct kunit *test)
> {
> - u64 mm_size, ps = SZ_4K, i, n_pages, total;
> + u64 mm_size, total;
> + u32 i, ps = SZ_4K, n_pages;
> struct drm_buddy_block *block;
> struct drm_buddy mm;
> LIST_HEAD(left);
> @@ -29,7 +30,8 @@ static void drm_test_buddy_alloc_contiguous(struct kunit
> *test)
> LIST_HEAD(right);
> LIST_HEAD(allocated);
>
> - mm_size = 16 * 3 * SZ_4K;
> + n_pages = 16 * 3;
> + mm_size = n_pages * SZ_4K;
>
> KUNIT_EXPECT_FALSE(test, drm_buddy_init(, mm_size, ps));
>
> @@ -42,7 +44,6 @@ static void drm_test_buddy_alloc_contiguous(struct kunit
> *test)
>*/
>
> i = 0;
> - n_pages = mm_size / ps;
> do {
> struct list_head *list;
> int slot = i % 3;
--
#Randy
Re: (subset) [PATCH v3 0/4] Add display support for Fairphone 4
On Fri, 16 Feb 2024 11:10:47 +0100, Luca Weiss wrote: > Introduce the bindings and panel driver for the LCD panel with the model > number 9A-3R063-1102B from DJN which is using the HX83112A driver IC. It > is used on the Fairphone 4 smartphone. > > Then we can add the panel to the device dts and also enable the GPU. > > > [...] Applied, thanks! [3/4] arm64: dts: qcom: sm6350: Remove "disabled" state of GMU commit: 2abe4a310cc742332038aed5f9f4a15e65a0bcc1 [4/4] arm64: dts: qcom: sm7225-fairphone-fp4: Enable display and GPU commit: 891af1aa1ea42514b9a7f42caaa1fa0c32f8e232 Best regards, -- Bjorn Andersson
[PATCH v4 17/19] drm/msm/dpu: modify timing engine programming for YUV420 over DP
Adjust the encoder timing engine setup programming in the case of video
mode for YUV420 over DP to accommodate CDM.
Changes in v3:
- Move drm_display_mode's hskew division to another patch
- Minor cleanup
Changes in v2:
- Move timing engine programming to this patch
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index 86c57c8b7e784..5cb816ea4dcc0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -236,7 +236,7 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
struct drm_display_mode mode;
struct dpu_hw_intf_timing_params timing_params = { 0 };
const struct dpu_format *fmt = NULL;
- u32 fmt_fourcc = DRM_FORMAT_RGB888;
+ u32 fmt_fourcc;
unsigned long lock_flags;
struct dpu_hw_intf_cfg intf_cfg = { 0 };
@@ -255,7 +255,9 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
DPU_DEBUG_VIDENC(phys_enc, "enabling mode:\n");
drm_mode_debug_printmodeline();
- if (phys_enc->split_role != ENC_ROLE_SOLO) {
+ fmt_fourcc = dpu_encoder_get_drm_fmt(phys_enc);
+
+ if (phys_enc->split_role != ENC_ROLE_SOLO || fmt_fourcc ==
DRM_FORMAT_YUV420) {
mode.hdisplay >>= 1;
mode.htotal >>= 1;
mode.hsync_start >>= 1;
@@ -275,6 +277,8 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
fmt = dpu_get_dpu_format(fmt_fourcc);
DPU_DEBUG_VIDENC(phys_enc, "fmt_fourcc 0x%X\n", fmt_fourcc);
+ if (phys_enc->hw_cdm)
+ intf_cfg.cdm = phys_enc->hw_cdm->idx;
intf_cfg.intf = phys_enc->hw_intf->idx;
intf_cfg.intf_mode_sel = DPU_CTL_MODE_SEL_VID;
intf_cfg.stream_sel = 0; /* Don't care value for video mode */
--
2.39.2
[PATCH v4 18/19] drm/msm/dpu: reserve CDM blocks for DP if mode is YUV420
Reserve CDM blocks for DP if the mode format is YUV420. Currently this
reservation only works for writeback and DP if the format is YUV420. But
this can be easily extented to other YUV formats for DP.
Changes in v2:
- Minor code simplification
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 22 +
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 84778adc7f791..e636215c8f834 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -635,6 +635,7 @@ static int dpu_encoder_virt_atomic_check(
struct dpu_kms *dpu_kms;
struct drm_display_mode *adj_mode;
struct msm_display_topology topology;
+ struct msm_display_info *disp_info;
struct dpu_global_state *global_state;
struct drm_framebuffer *fb;
struct drm_dsc_config *dsc;
@@ -651,6 +652,7 @@ static int dpu_encoder_virt_atomic_check(
DPU_DEBUG_ENC(dpu_enc, "\n");
priv = drm_enc->dev->dev_private;
+ disp_info = _enc->disp_info;
dpu_kms = to_dpu_kms(priv->kms);
adj_mode = _state->adjusted_mode;
global_state = dpu_kms_get_global_state(crtc_state->state);
@@ -678,21 +680,24 @@ static int dpu_encoder_virt_atomic_check(
topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode,
crtc_state, dsc);
/*
-* Use CDM only for writeback at the moment as other interfaces cannot
handle it.
-* if writeback itself cannot handle cdm for some reason it will fail
in its atomic_check()
+* Use CDM only for writeback or DP at the moment as other interfaces
cannot handle it.
+* If writeback itself cannot handle cdm for some reason it will fail
in its atomic_check()
* earlier.
*/
- if (dpu_enc->disp_info.intf_type == INTF_WB &&
conn_state->writeback_job) {
+ if (disp_info->intf_type == INTF_WB && conn_state->writeback_job) {
fb = conn_state->writeback_job->fb;
if (fb &&
DPU_FORMAT_IS_YUV(to_dpu_format(msm_framebuffer_format(fb
topology.needs_cdm = true;
- if (topology.needs_cdm && !dpu_enc->cur_master->hw_cdm)
- crtc_state->mode_changed = true;
- else if (!topology.needs_cdm && dpu_enc->cur_master->hw_cdm)
- crtc_state->mode_changed = true;
+ } else if (disp_info->intf_type == INTF_DP) {
+ if
(msm_dp_is_yuv_420_enabled(priv->dp[disp_info->h_tile_instance[0]], adj_mode))
+ topology.needs_cdm = true;
}
+ if (topology.needs_cdm && !dpu_enc->cur_master->hw_cdm)
+ crtc_state->mode_changed = true;
+ else if (!topology.needs_cdm && dpu_enc->cur_master->hw_cdm)
+ crtc_state->mode_changed = true;
/*
* Release and Allocate resources on every modeset
* Dont allocate when active is false.
@@ -1133,7 +1138,8 @@ static void dpu_encoder_virt_atomic_mode_set(struct
drm_encoder *drm_enc,
dpu_enc->dsc_mask = dsc_mask;
- if (dpu_enc->disp_info.intf_type == INTF_WB &&
conn_state->writeback_job) {
+ if ((dpu_enc->disp_info.intf_type == INTF_WB &&
conn_state->writeback_job) ||
+ dpu_enc->disp_info.intf_type == INTF_DP) {
struct dpu_hw_blk *hw_cdm = NULL;
dpu_rm_get_assigned_resources(_kms->rm, global_state,
--
2.39.2
[PATCH v4 19/19] drm/msm/dp: allow YUV420 mode for DP connector when CDM available
All the components of YUV420 over DP are added. Therefore, let's mark the
connector property as true for DP connector when the DP type is not eDP
and when there is a CDM block available.
Changes in v3:
- Move setting the connector's ycbcr_420_allowed parameter so
that it is not dependent on if the dp_display is not eDP
Changes in v2:
- Check for if dp_catalog has a CDM block available instead of
checking if VSC SDP is allowed when setting the dp connector's
ycbcr_420_allowed parameter
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 +++-
drivers/gpu/drm/msm/dp/dp_display.c | 4 ++--
drivers/gpu/drm/msm/dp/dp_drm.c | 6 +-
drivers/gpu/drm/msm/dp/dp_drm.h | 3 ++-
drivers/gpu/drm/msm/msm_drv.h | 5 +++--
5 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 723cc1d821431..8d326fb36550a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -565,6 +565,7 @@ static int _dpu_kms_initialize_displayport(struct
drm_device *dev,
{
struct drm_encoder *encoder = NULL;
struct msm_display_info info;
+ bool yuv_supported;
int rc;
int i;
@@ -583,7 +584,8 @@ static int _dpu_kms_initialize_displayport(struct
drm_device *dev,
return PTR_ERR(encoder);
}
- rc = msm_dp_modeset_init(priv->dp[i], dev, encoder);
+ yuv_supported = !!dpu_kms->catalog->cdm;
+ rc = msm_dp_modeset_init(priv->dp[i], dev, encoder,
yuv_supported);
if (rc) {
DPU_ERROR("modeset_init failed for DP, rc = %d\n", rc);
return rc;
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index b5a67835ce6d1..a435847f1d948 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1472,7 +1472,7 @@ static int dp_display_get_next_bridge(struct msm_dp *dp)
}
int msm_dp_modeset_init(struct msm_dp *dp_display, struct drm_device *dev,
- struct drm_encoder *encoder)
+ struct drm_encoder *encoder, bool yuv_supported)
{
struct dp_display_private *dp_priv;
int ret;
@@ -1488,7 +1488,7 @@ int msm_dp_modeset_init(struct msm_dp *dp_display, struct
drm_device *dev,
return ret;
}
- dp_display->connector = dp_drm_connector_init(dp_display, encoder);
+ dp_display->connector = dp_drm_connector_init(dp_display, encoder,
yuv_supported);
if (IS_ERR(dp_display->connector)) {
ret = PTR_ERR(dp_display->connector);
DRM_DEV_ERROR(dev->dev,
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
index 46e6889037e88..a819a4ff76a9f 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.c
+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
@@ -353,7 +353,8 @@ int dp_bridge_init(struct msm_dp *dp_display, struct
drm_device *dev,
}
/* connector initialization */
-struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display, struct
drm_encoder *encoder)
+struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display, struct
drm_encoder *encoder,
+ bool yuv_supported)
{
struct drm_connector *connector = NULL;
@@ -364,6 +365,9 @@ struct drm_connector *dp_drm_connector_init(struct msm_dp
*dp_display, struct dr
if (!dp_display->is_edp)
drm_connector_attach_dp_subconnector_property(connector);
+ if (yuv_supported)
+ connector->ycbcr_420_allowed = true;
+
drm_connector_attach_encoder(connector, encoder);
return connector;
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.h b/drivers/gpu/drm/msm/dp/dp_drm.h
index b3d684db2383b..45e57ac25a4d9 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.h
+++ b/drivers/gpu/drm/msm/dp/dp_drm.h
@@ -19,7 +19,8 @@ struct msm_dp_bridge {
#define to_dp_bridge(x) container_of((x), struct msm_dp_bridge, bridge)
-struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display, struct
drm_encoder *encoder);
+struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display, struct
drm_encoder *encoder,
+ bool yuv_supported);
int dp_bridge_init(struct msm_dp *dp_display, struct drm_device *dev,
struct drm_encoder *encoder);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index b876ebd48effe..37335777f5c09 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -385,7 +385,7 @@ static inline struct drm_dsc_config
*msm_dsi_get_dsc_config(struct msm_dsi *msm_
int __init msm_dp_register(void);
void __exit msm_dp_unregister(void);
[PATCH v4 12/19] drm/msm/dp: move parity calculation to dp_utils
Parity calculation is necessary for VSC SDP implementation. Therefore
create new files dp_utils.c and dp_utils.h and move the parity
calculating functions here. This ensures that they are usable by SDP
programming in both dp_catalog.c and dp_audio.c
Changes in v3:
- Change ordering of the header byte macros
Changes in v2:
- Create new files dp_utils.c and dp_utils.h
- Move the parity calculation to these new files instead of
having them in dp_catalog.c and dp_catalog.h
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Makefile | 3 +-
drivers/gpu/drm/msm/dp/dp_audio.c | 101 +-
drivers/gpu/drm/msm/dp/dp_utils.c | 73 +
drivers/gpu/drm/msm/dp/dp_utils.h | 22 +++
4 files changed, 112 insertions(+), 87 deletions(-)
create mode 100644 drivers/gpu/drm/msm/dp/dp_utils.c
create mode 100644 drivers/gpu/drm/msm/dp/dp_utils.h
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index b1173128b5b97..998b155e4a979 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -129,7 +129,8 @@ msm-$(CONFIG_DRM_MSM_DP)+= dp/dp_aux.o \
dp/dp_panel.o \
dp/dp_parser.o \
dp/dp_power.o \
- dp/dp_audio.o
+ dp/dp_audio.o \
+ dp/dp_utils.o
msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o
diff --git a/drivers/gpu/drm/msm/dp/dp_audio.c
b/drivers/gpu/drm/msm/dp/dp_audio.c
index 4a2e479723a85..7634e4b742084 100644
--- a/drivers/gpu/drm/msm/dp/dp_audio.c
+++ b/drivers/gpu/drm/msm/dp/dp_audio.c
@@ -15,13 +15,7 @@
#include "dp_audio.h"
#include "dp_panel.h"
#include "dp_display.h"
-
-#define HEADER_BYTE_2_BIT 0
-#define PARITY_BYTE_2_BIT 8
-#define HEADER_BYTE_1_BIT 16
-#define PARITY_BYTE_1_BIT 24
-#define HEADER_BYTE_3_BIT 16
-#define PARITY_BYTE_3_BIT 24
+#include "dp_utils.h"
struct dp_audio_private {
struct platform_device *audio_pdev;
@@ -36,71 +30,6 @@ struct dp_audio_private {
struct dp_audio dp_audio;
};
-static u8 dp_audio_get_g0_value(u8 data)
-{
- u8 c[4];
- u8 g[4];
- u8 ret_data = 0;
- u8 i;
-
- for (i = 0; i < 4; i++)
- c[i] = (data >> i) & 0x01;
-
- g[0] = c[3];
- g[1] = c[0] ^ c[3];
- g[2] = c[1];
- g[3] = c[2];
-
- for (i = 0; i < 4; i++)
- ret_data = ((g[i] & 0x01) << i) | ret_data;
-
- return ret_data;
-}
-
-static u8 dp_audio_get_g1_value(u8 data)
-{
- u8 c[4];
- u8 g[4];
- u8 ret_data = 0;
- u8 i;
-
- for (i = 0; i < 4; i++)
- c[i] = (data >> i) & 0x01;
-
- g[0] = c[0] ^ c[3];
- g[1] = c[0] ^ c[1] ^ c[3];
- g[2] = c[1] ^ c[2];
- g[3] = c[2] ^ c[3];
-
- for (i = 0; i < 4; i++)
- ret_data = ((g[i] & 0x01) << i) | ret_data;
-
- return ret_data;
-}
-
-static u8 dp_audio_calculate_parity(u32 data)
-{
- u8 x0 = 0;
- u8 x1 = 0;
- u8 ci = 0;
- u8 iData = 0;
- u8 i = 0;
- u8 parity_byte;
- u8 num_byte = (data & 0xFF00) > 0 ? 8 : 2;
-
- for (i = 0; i < num_byte; i++) {
- iData = (data >> i*4) & 0xF;
-
- ci = iData ^ x1;
- x1 = x0 ^ dp_audio_get_g1_value(ci);
- x0 = dp_audio_get_g0_value(ci);
- }
-
- parity_byte = x1 | (x0 << 4);
-
- return parity_byte;
-}
-
static u32 dp_audio_get_header(struct dp_catalog *catalog,
enum dp_catalog_audio_sdp_type sdp,
enum dp_catalog_audio_header_type header)
@@ -134,7 +63,7 @@ static void dp_audio_stream_sdp(struct dp_audio_private
*audio)
DP_AUDIO_SDP_STREAM, DP_AUDIO_SDP_HEADER_1);
new_value = 0x02;
- parity_byte = dp_audio_calculate_parity(new_value);
+ parity_byte = dp_utils_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_1_BIT)
| (parity_byte << PARITY_BYTE_1_BIT));
drm_dbg_dp(audio->drm_dev,
@@ -147,7 +76,7 @@ static void dp_audio_stream_sdp(struct dp_audio_private
*audio)
value = dp_audio_get_header(catalog,
DP_AUDIO_SDP_STREAM, DP_AUDIO_SDP_HEADER_2);
new_value = value;
- parity_byte = dp_audio_calculate_parity(new_value);
+ parity_byte = dp_utils_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_2_BIT)
| (parity_byte << PARITY_BYTE_2_BIT));
drm_dbg_dp(audio->drm_dev,
@@ -162,7 +91,7 @@ static void dp_audio_stream_sdp(struct dp_audio_private
*audio)
DP_AUDIO_SDP_STREAM, DP_AUDIO_SDP_HEADER_3);
new_value = audio->channels - 1;
- parity_byte = dp_audio_calculate_parity(new_value);
+ parity_byte = dp_utils_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_3_BIT)
|
[PATCH v4 13/19] drm/msm/dp: add VSC SDP support for YUV420 over DP
Add support to pack and send the VSC SDP packet for DP. This therefore
allows the transmision of format information to the sinks which is
needed for YUV420 support over DP.
Changes in v4:
- Remove struct msm_dp_sdp_with_parity
- Use dp_utils_pack_sdp_header() to pack the SDP header and
parity bytes into a buffer
- Use this buffer when writing the VSC SDP data in
dp_catalog_panel_send_vsc_sdp()
- Write to all of the MMSS_DP_GENERIC0 registers instead of just
the ones with non-zero values
Changes in v3:
- Create a new struct, msm_dp_sdp_with_parity, which holds the
packing information for VSC SDP
- Use drm_dp_vsc_sdp_pack() to pack the data into the new
msm_dp_sdp_with_parity struct instead of specifically packing
for YUV420 format
- Modify dp_catalog_panel_send_vsc_sdp() to send the VSC SDP
data using the new msm_dp_sdp_with_parity struct
Changes in v2:
- Rename GENERIC0_SDPSIZE macro to GENERIC0_SDPSIZE_VALID
- Remove dp_sdp from the dp_catalog struct since this data is
being allocated at the point used
- Create a new function in dp_utils to pack the VSC SDP data
into a buffer
- Create a new function that packs the SDP header bytes into a
buffer. This function is made generic so that it can be
utilized by dp_audio
header bytes into a buffer
- Create a new function in dp_utils that takes the packed buffer
and writes to the DP_GENERIC0_* registers
- Split the dp_catalog_panel_config_vsc_sdp() function into two
to disable/enable sending VSC SDP packets
- Check the DP HW version using the original useage of
dp_catalog_hw_revision() and correct the version checking
logic
- Rename dp_panel_setup_vsc_sdp() to
dp_panel_setup_vsc_sdp_yuv_420() to explicitly state that
currently VSC SDP is only being set up to support YUV420 modes
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 107
drivers/gpu/drm/msm/dp/dp_catalog.h | 7 ++
drivers/gpu/drm/msm/dp/dp_ctrl.c| 4 ++
drivers/gpu/drm/msm/dp/dp_panel.c | 55 ++
drivers/gpu/drm/msm/dp/dp_reg.h | 3 +
drivers/gpu/drm/msm/dp/dp_utils.c | 56 +++
drivers/gpu/drm/msm/dp/dp_utils.h | 4 ++
7 files changed, 236 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 5d84c089e520a..c6e57812a239e 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -901,6 +901,113 @@ int dp_catalog_panel_timing_cfg(struct dp_catalog
*dp_catalog)
return 0;
}
+static void dp_catalog_panel_send_vsc_sdp(struct dp_catalog *dp_catalog,
struct dp_sdp *vsc_sdp,
+ u32 *header)
+{
+ struct dp_catalog_private *catalog;
+ u32 val;
+ int i;
+
+ if (!dp_catalog) {
+ DRM_ERROR("invalid input\n");
+ return;
+ }
+
+ catalog = container_of(dp_catalog, struct dp_catalog_private,
dp_catalog);
+
+ dp_write_link(catalog, MMSS_DP_GENERIC0_0, header[0]);
+ dp_write_link(catalog, MMSS_DP_GENERIC0_1, header[1]);
+
+ for (i = 0; i < sizeof(vsc_sdp->db); i += 4) {
+ val = ((vsc_sdp->db[i]) | (vsc_sdp->db[i + 1] << 8) |
(vsc_sdp->db[i + 2] << 16) |
+ (vsc_sdp->db[i + 3] << 24));
+ dp_write_link(catalog, MMSS_DP_GENERIC0_2 + i, val);
+ }
+}
+
+static void dp_catalog_panel_update_sdp(struct dp_catalog *dp_catalog)
+{
+ struct dp_catalog_private *catalog;
+ u32 hw_revision;
+
+ catalog = container_of(dp_catalog, struct dp_catalog_private,
dp_catalog);
+
+ hw_revision = dp_catalog_hw_revision(dp_catalog);
+ if (hw_revision < DP_HW_VERSION_1_2 && hw_revision >=
DP_HW_VERSION_1_0) {
+ dp_write_link(catalog, MMSS_DP_SDP_CFG3, 0x01);
+ dp_write_link(catalog, MMSS_DP_SDP_CFG3, 0x00);
+ }
+}
+
+void dp_catalog_panel_enable_vsc_sdp(struct dp_catalog *dp_catalog, struct
dp_sdp *vsc_sdp,
+u32 *header)
+{
+ struct dp_catalog_private *catalog;
+ u32 cfg, cfg2, misc;
+
+ if (!dp_catalog) {
+ DRM_ERROR("invalid input\n");
+ return;
+ }
+
+ catalog = container_of(dp_catalog, struct dp_catalog_private,
dp_catalog);
+
+ cfg = dp_read_link(catalog, MMSS_DP_SDP_CFG);
+ cfg2 = dp_read_link(catalog, MMSS_DP_SDP_CFG2);
+ misc = dp_read_link(catalog, REG_DP_MISC1_MISC0);
+
+ cfg |= GEN0_SDP_EN;
+ dp_write_link(catalog, MMSS_DP_SDP_CFG, cfg);
+
+ cfg2 |= GENERIC0_SDPSIZE_VALID;
+ dp_write_link(catalog, MMSS_DP_SDP_CFG2, cfg2);
+
+
[PATCH v4 01/19] drm/msm/dpu: allow certain formats for CDM for DP
CDM block supports formats other than H1V2 for DP. Since we are now
adding support for CDM over DP, relax the checks to allow all other
formats for DP other than H1V2.
Changes in v2:
- Add fixes tag
- Move patch to top of series
Fixes: 0afac0ba6024 ("drm/msm/dpu: add dpu_hw_cdm abstraction for CDM block")
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c
index e9cdc7934a499..9016b3ade6bc3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c
@@ -186,7 +186,7 @@ static int dpu_hw_cdm_enable(struct dpu_hw_cdm *ctx, struct
dpu_hw_cdm_cfg *cdm)
dpu_hw_cdm_setup_cdwn(ctx, cdm);
if (cdm->output_type == CDM_CDWN_OUTPUT_HDMI) {
- if (fmt->chroma_sample != DPU_CHROMA_H1V2)
+ if (fmt->chroma_sample == DPU_CHROMA_H1V2)
return -EINVAL; /*unsupported format */
opmode = CDM_HDMI_PACK_OP_MODE_EN;
opmode |= (fmt->chroma_sample << 1);
--
2.39.2
[PATCH v4 11/19] drm/msm/dp: change clock related programming for YUV420 over DP
Change all relevant DP controller related programming for YUV420 cases.
Namely, change the pixel clock math to consider YUV420 and modify the
MVID programming to consider YUV420.
Changes in v2:
- Move configuration control programming to a different commit
- Slight code simplification
- Add VSC SDP check when doing mode_pclk_khz division in
dp_bridge_mode_valid
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 5 -
drivers/gpu/drm/msm/dp/dp_catalog.h | 2 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c| 9 ++---
drivers/gpu/drm/msm/dp/dp_display.c | 4
4 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 5142aeb705a44..5d84c089e520a 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -442,7 +442,7 @@ void dp_catalog_ctrl_config_misc(struct dp_catalog
*dp_catalog,
void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog,
u32 rate, u32 stream_rate_khz,
- bool fixed_nvid)
+ bool fixed_nvid, bool is_ycbcr_420)
{
u32 pixel_m, pixel_n;
u32 mvid, nvid, pixel_div = 0, dispcc_input_rate;
@@ -485,6 +485,9 @@ void dp_catalog_ctrl_config_msa(struct dp_catalog
*dp_catalog,
nvid = temp;
}
+ if (is_ycbcr_420)
+ mvid /= 2;
+
if (link_rate_hbr2 == rate)
nvid *= 2;
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h
b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 38786e855b51a..6cb5e2a243de2 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.h
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
@@ -96,7 +96,7 @@ void dp_catalog_ctrl_mainlink_ctrl(struct dp_catalog
*dp_catalog, bool enable);
void dp_catalog_ctrl_psr_mainlink_enable(struct dp_catalog *dp_catalog, bool
enable);
void dp_catalog_ctrl_config_misc(struct dp_catalog *dp_catalog, u32 cc, u32
tb);
void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog, u32 rate,
- u32 stream_rate_khz, bool fixed_nvid);
+ u32 stream_rate_khz, bool fixed_nvid, bool
is_ycbcr_420);
int dp_catalog_ctrl_set_pattern_state_bit(struct dp_catalog *dp_catalog, u32
pattern);
u32 dp_catalog_hw_revision(const struct dp_catalog *dp_catalog);
void dp_catalog_ctrl_reset(struct dp_catalog *dp_catalog);
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 6692d81adb195..bffb7bac2c2c8 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -955,7 +955,7 @@ static void dp_ctrl_calc_tu_parameters(struct
dp_ctrl_private *ctrl,
in.hporch = drm_mode->htotal - drm_mode->hdisplay;
in.nlanes = ctrl->link->link_params.num_lanes;
in.bpp = ctrl->panel->dp_mode.bpp;
- in.pixel_enc = 444;
+ in.pixel_enc = ctrl->panel->dp_mode.out_fmt_is_yuv_420 ? 420 : 444;
in.dsc_en = 0;
in.async_en = 0;
in.fec_en = 0;
@@ -1761,6 +1761,8 @@ int dp_ctrl_on_link(struct dp_ctrl *dp_ctrl)
ctrl->link->link_params.rate = rate;
ctrl->link->link_params.num_lanes =
ctrl->panel->link_info.num_lanes;
+ if (ctrl->panel->dp_mode.out_fmt_is_yuv_420)
+ pixel_rate >>= 1;
}
drm_dbg_dp(ctrl->drm_dev, "rate=%d, num_lanes=%d, pixel_rate=%lu\n",
@@ -1876,7 +1878,7 @@ int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl, bool
force_link_train)
pixel_rate = pixel_rate_orig = ctrl->panel->dp_mode.drm_mode.clock;
- if (dp_ctrl->wide_bus_en)
+ if (dp_ctrl->wide_bus_en || ctrl->panel->dp_mode.out_fmt_is_yuv_420)
pixel_rate >>= 1;
drm_dbg_dp(ctrl->drm_dev, "rate=%d, num_lanes=%d, pixel_rate=%lu\n",
@@ -1915,7 +1917,8 @@ int dp_ctrl_on_stream(struct dp_ctrl *dp_ctrl, bool
force_link_train)
dp_catalog_ctrl_config_msa(ctrl->catalog,
ctrl->link->link_params.rate,
- pixel_rate_orig, dp_ctrl_use_fixed_nvid(ctrl));
+ pixel_rate_orig, dp_ctrl_use_fixed_nvid(ctrl),
+ ctrl->panel->dp_mode.out_fmt_is_yuv_420);
dp_ctrl_setup_tr_unit(ctrl);
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 4b1b79b74bc72..3b7c3a7fd4993 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -934,6 +934,10 @@ enum drm_mode_status dp_bridge_mode_valid(struct
drm_bridge *bridge,
dp_display = container_of(dp, struct dp_display_private, dp_display);
link_info = _display->panel->link_info;
+ if (drm_mode_is_420_only(>connector->display_info, mode) &&
+ dp_display->panel->vsc_sdp_supported)
+ mode_pclk_khz /= 2;
+
[PATCH v4 14/19] drm/msm/dpu: add support of new peripheral flush mechanism
From: Kuogee Hsieh
Introduce a peripheral flushing mechanism to decouple peripheral
metadata flushing from timing engine related flush.
Changes in v2:
- Fixed some misalignment issues
Signed-off-by: Kuogee Hsieh
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 17 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 10 ++
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index e76565c3e6a43..a06f69d0b257d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -39,6 +39,7 @@
#define CTL_WB_FLUSH 0x108
#define CTL_INTF_FLUSH0x110
#define CTL_CDM_FLUSH0x114
+#define CTL_PERIPH_FLUSH 0x128
#define CTL_INTF_MASTER 0x134
#define CTL_DSPP_n_FLUSH(n) ((0x13C) + ((n) * 4))
@@ -49,6 +50,7 @@
#define MERGE_3D_IDX 23
#define DSC_IDX22
#define CDM_IDX 26
+#define PERIPH_IDX 30
#define INTF_IDX 31
#define WB_IDX 16
#define DSPP_IDX 29 /* From DPU hw rev 7.x.x */
@@ -151,6 +153,10 @@ static inline void dpu_hw_ctl_trigger_flush_v1(struct
dpu_hw_ctl *ctx)
ctx->pending_dspp_flush_mask[dspp - DSPP_0]);
}
+ if (ctx->pending_flush_mask & BIT(PERIPH_IDX))
+ DPU_REG_WRITE(>hw, CTL_PERIPH_FLUSH,
+ ctx->pending_periph_flush_mask);
+
if (ctx->pending_flush_mask & BIT(DSC_IDX))
DPU_REG_WRITE(>hw, CTL_DSC_FLUSH,
ctx->pending_dsc_flush_mask);
@@ -311,6 +317,13 @@ static void dpu_hw_ctl_update_pending_flush_intf_v1(struct
dpu_hw_ctl *ctx,
ctx->pending_flush_mask |= BIT(INTF_IDX);
}
+static void dpu_hw_ctl_update_pending_flush_periph_v1(struct dpu_hw_ctl *ctx,
+ enum dpu_intf intf)
+{
+ ctx->pending_periph_flush_mask |= BIT(intf - INTF_0);
+ ctx->pending_flush_mask |= BIT(PERIPH_IDX);
+}
+
static void dpu_hw_ctl_update_pending_flush_merge_3d_v1(struct dpu_hw_ctl *ctx,
enum dpu_merge_3d merge_3d)
{
@@ -680,6 +693,10 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops,
ops->reset_intf_cfg = dpu_hw_ctl_reset_intf_cfg_v1;
ops->update_pending_flush_intf =
dpu_hw_ctl_update_pending_flush_intf_v1;
+
+ ops->update_pending_flush_periph =
+ dpu_hw_ctl_update_pending_flush_periph_v1;
+
ops->update_pending_flush_merge_3d =
dpu_hw_ctl_update_pending_flush_merge_3d_v1;
ops->update_pending_flush_wb =
dpu_hw_ctl_update_pending_flush_wb_v1;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
index ff85b5ee0acf8..ef56280bea932 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
@@ -122,6 +122,15 @@ struct dpu_hw_ctl_ops {
void (*update_pending_flush_intf)(struct dpu_hw_ctl *ctx,
enum dpu_intf blk);
+ /**
+* OR in the given flushbits to the cached pending_(periph_)flush_mask
+* No effect on hardware
+* @ctx : ctl path ctx pointer
+* @blk : interface block index
+*/
+ void (*update_pending_flush_periph)(struct dpu_hw_ctl *ctx,
+ enum dpu_intf blk);
+
/**
* OR in the given flushbits to the cached pending_(merge_3d_)flush_mask
* No effect on hardware
@@ -264,6 +273,7 @@ struct dpu_hw_ctl {
u32 pending_flush_mask;
u32 pending_intf_flush_mask;
u32 pending_wb_flush_mask;
+ u32 pending_periph_flush_mask;
u32 pending_merge_3d_flush_mask;
u32 pending_dspp_flush_mask[DSPP_MAX - DSPP_0];
u32 pending_dsc_flush_mask;
--
2.39.2
[PATCH v4 16/19] drm/msm/dpu: modify encoder programming for CDM over DP
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Changes in v4:
- Remove hw_cdm check in dpu_encoder_needs_periph_flush()
- Remove hw_cdm check when getting the fmt_fourcc in
dpu_encoder_phys_vid_enable()
Changes in v2:
- Move timing engine programming to a separate patch from this
one
- Move update_pending_flush_periph() invocation completely to
this patch
- Change the logic of dpu_encoder_get_drm_fmt() so that it only
calls drm_mode_is_420_only() instead of doing additional
unnecessary checks
- Create new functions msm_dp_needs_periph_flush() and it's
supporting function dpu_encoder_needs_periph_flush() to check
if the mode is YUV420 and VSC SDP is enabled before doing a
peripheral flush
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 35 +++
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 13 +++
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 16 +
drivers/gpu/drm/msm/dp/dp_display.c | 18 ++
drivers/gpu/drm/msm/msm_drv.h | 17 -
5 files changed, 98 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index b53a1b545742b..84778adc7f791 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -218,6 +218,41 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
};
+u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc;
+ struct dpu_encoder_virt *dpu_enc;
+ struct drm_display_info *info;
+ struct drm_display_mode *mode;
+
+ drm_enc = phys_enc->parent;
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ info = _enc->connector->display_info;
+ mode = _enc->cached_mode;
+
+ if (drm_mode_is_420_only(info, mode))
+ return DRM_FORMAT_YUV420;
+
+ return DRM_FORMAT_RGB888;
+}
+
+bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc)
+{
+ struct drm_encoder *drm_enc;
+ struct dpu_encoder_virt *dpu_enc;
+ struct msm_display_info *disp_info;
+ struct msm_drm_private *priv;
+ struct drm_display_mode *mode;
+
+ drm_enc = phys_enc->parent;
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ disp_info = _enc->disp_info;
+ priv = drm_enc->dev->dev_private;
+ mode = _enc->cached_mode;
+
+ return phys_enc->hw_intf->cap->type == INTF_DP &&
+
msm_dp_needs_periph_flush(priv->dp[disp_info->h_tile_instance[0]], mode);
+}
bool dpu_encoder_is_widebus_enabled(const struct drm_encoder *drm_enc)
{
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index f43d57d9c74e1..211a3d90eb690 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -341,6 +341,19 @@ static inline enum dpu_3d_blend_mode
dpu_encoder_helper_get_3d_blend_mode(
*/
unsigned int dpu_encoder_helper_get_dsc(struct dpu_encoder_phys *phys_enc);
+/**
+ * dpu_encoder_get_drm_fmt - return DRM fourcc format
+ * @phys_enc: Pointer to physical encoder structure
+ */
+u32 dpu_encoder_get_drm_fmt(struct dpu_encoder_phys *phys_enc);
+
+/**
+ * dpu_encoder_needs_periph_flush - return true if physical encoder requires
+ * peripheral flush
+ * @phys_enc: Pointer to physical encoder structure
+ */
+bool dpu_encoder_needs_periph_flush(struct dpu_encoder_phys *phys_enc);
+
/**
* dpu_encoder_helper_split_config - split display configuration helper
function
* This helper function may be used by physical encoders to configure
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index f02411b062c4c..86c57c8b7e784 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -415,8 +415,12 @@ static int dpu_encoder_phys_vid_control_vblank_irq(
static void dpu_encoder_phys_vid_enable(struct dpu_encoder_phys *phys_enc)
{
struct dpu_hw_ctl *ctl;
+ const struct dpu_format *fmt;
+ u32 fmt_fourcc;
ctl = phys_enc->hw_ctl;
+ fmt_fourcc = dpu_encoder_get_drm_fmt(phys_enc);
+ fmt = dpu_get_dpu_format(fmt_fourcc);
DPU_DEBUG_VIDENC(phys_enc, "\n");
@@ -425,6 +429,8 @@ static void dpu_encoder_phys_vid_enable(struct
dpu_encoder_phys *phys_enc)
dpu_encoder_helper_split_config(phys_enc, phys_enc->hw_intf->idx);
+ dpu_encoder_helper_phys_setup_cdm(phys_enc, fmt, CDM_CDWN_OUTPUT_HDMI);
+
dpu_encoder_phys_vid_setup_timing_engine(phys_enc);
/*
@@ -440,6 +446,16 @@
[PATCH v4 15/19] drm/msm/dp: enable SDP and SDE periph flush update
DP controller can be setup to operate in either SDP update flush mode or
peripheral flush mode based on the DP controller hardware version.
Starting in DP v1.2, the hardware documents require the use of
peripheral flush mode for SDP packets such as PPS OR VSC SDP packets.
In-line with this guidance, lets program the DP controller to use
peripheral flush mode starting DP v1.2
Changes in v4:
- Clear up that DP_MAINLINK_CTRL_FLUSH_MODE register requires
the use of bits [24:23]
- Modify macros DP_MAINLINK_FLUSH_MODE_UPDATE_SDP and
DP_MAINLINK_FLUSH_MODE_SDP_PERIPH_UPDATE to explicitly set
their values in the bits of DP_MAINLINK_CTRL_FLUSH_MODE_MASK
Changes in v3:
- Clear up that the DP_MAINLINK_FLUSH_MODE_SDE_PERIPH_UPDATE
macro is setting bits [24:23] to a value of 3
Changes in v2:
- Use the original dp_catalog_hw_revision() function to
correctly check the DP HW version
Signed-off-by: Paloma Arellano
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 17 +
drivers/gpu/drm/msm/dp/dp_catalog.h | 1 +
drivers/gpu/drm/msm/dp/dp_ctrl.c| 1 +
drivers/gpu/drm/msm/dp/dp_reg.h | 6 ++
4 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index c6e57812a239e..6619a20ffa923 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -440,6 +440,23 @@ void dp_catalog_ctrl_config_misc(struct dp_catalog
*dp_catalog,
dp_write_link(catalog, REG_DP_MISC1_MISC0, misc_val);
}
+void dp_catalog_setup_peripheral_flush(struct dp_catalog *dp_catalog)
+{
+ u32 mainlink_ctrl, hw_revision;
+ struct dp_catalog_private *catalog = container_of(dp_catalog,
+ struct dp_catalog_private, dp_catalog);
+
+ mainlink_ctrl = dp_read_link(catalog, REG_DP_MAINLINK_CTRL);
+
+ hw_revision = dp_catalog_hw_revision(dp_catalog);
+ if (hw_revision >= DP_HW_VERSION_1_2)
+ mainlink_ctrl |= DP_MAINLINK_FLUSH_MODE_SDE_PERIPH_UPDATE;
+ else
+ mainlink_ctrl |= DP_MAINLINK_FLUSH_MODE_UPDATE_SDP;
+
+ dp_write_link(catalog, REG_DP_MAINLINK_CTRL, mainlink_ctrl);
+}
+
void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog,
u32 rate, u32 stream_rate_khz,
bool fixed_nvid, bool is_ycbcr_420)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h
b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 4bdc087410a68..8ad0672157df8 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.h
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
@@ -98,6 +98,7 @@ void dp_catalog_ctrl_config_ctrl(struct dp_catalog
*dp_catalog, u32 config);
void dp_catalog_ctrl_lane_mapping(struct dp_catalog *dp_catalog);
void dp_catalog_ctrl_mainlink_ctrl(struct dp_catalog *dp_catalog, bool enable);
void dp_catalog_ctrl_psr_mainlink_enable(struct dp_catalog *dp_catalog, bool
enable);
+void dp_catalog_setup_peripheral_flush(struct dp_catalog *dp_catalog);
void dp_catalog_ctrl_config_misc(struct dp_catalog *dp_catalog, u32 cc, u32
tb);
void dp_catalog_ctrl_config_msa(struct dp_catalog *dp_catalog, u32 rate,
u32 stream_rate_khz, bool fixed_nvid, bool
is_ycbcr_420);
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index a42b29f9902c1..a17b9a22858da 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -165,6 +165,7 @@ static void dp_ctrl_configure_source_params(struct
dp_ctrl_private *ctrl)
dp_catalog_ctrl_lane_mapping(ctrl->catalog);
dp_catalog_ctrl_mainlink_ctrl(ctrl->catalog, true);
+ dp_catalog_setup_peripheral_flush(ctrl->catalog);
dp_ctrl_config_ctrl(ctrl);
diff --git a/drivers/gpu/drm/msm/dp/dp_reg.h b/drivers/gpu/drm/msm/dp/dp_reg.h
index aa9f6c3e4ddeb..3835c7f5cb984 100644
--- a/drivers/gpu/drm/msm/dp/dp_reg.h
+++ b/drivers/gpu/drm/msm/dp/dp_reg.h
@@ -6,6 +6,9 @@
#ifndef _DP_REG_H_
#define _DP_REG_H_
+#include
+#include
+
/* DP_TX Registers */
#define REG_DP_HW_VERSION (0x)
@@ -102,6 +105,9 @@
#define DP_MAINLINK_CTRL_ENABLE(0x0001)
#define DP_MAINLINK_CTRL_RESET (0x0002)
#define DP_MAINLINK_CTRL_SW_BYPASS_SCRAMBLER (0x0010)
+#define DP_MAINLINK_CTRL_FLUSH_MODE_MASK GENMASK(24, 23)
+#define DP_MAINLINK_FLUSH_MODE_UPDATE_SDP
FIELD_PREP(DP_MAINLINK_CTRL_FLUSH_MODE_MASK, 1)
+#define DP_MAINLINK_FLUSH_MODE_SDE_PERIPH_UPDATE
FIELD_PREP(DP_MAINLINK_CTRL_FLUSH_MODE_MASK, 3)
#define DP_MAINLINK_FB_BOUNDARY_SEL(0x0200)
#define REG_DP_STATE_CTRL (0x0004)
--
2.39.2
[PATCH v4 09/19] drm/msm/dpu: move widebus logic to its own API
Widebus enablement is decided by the interfaces based on their specific
checks and that already happens with DSI/DP specific helpers. Let's
invoke these helpers from dpu_encoder_is_widebus_enabled() to make it
cleaner overall.
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 29 -
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 4 +++
2 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 1905e8653b77a..b53a1b545742b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -221,9 +221,21 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
bool dpu_encoder_is_widebus_enabled(const struct drm_encoder *drm_enc)
{
- const struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
+ const struct dpu_encoder_virt *dpu_enc;
+ struct msm_drm_private *priv = drm_enc->dev->dev_private;
+ const struct msm_display_info *disp_info;
+ int index;
+
+ dpu_enc = to_dpu_encoder_virt(drm_enc);
+ disp_info = _enc->disp_info;
+ index = disp_info->h_tile_instance[0];
+
+ if (disp_info->intf_type == INTF_DP)
+ return msm_dp_wide_bus_available(priv->dp[index]);
+ else if (disp_info->intf_type == INTF_DSI)
+ return msm_dsi_wide_bus_enabled(priv->dsi[index]);
- return dpu_enc->wide_bus_en;
+ return false;
}
bool dpu_encoder_is_dsc_enabled(const struct drm_encoder *drm_enc)
@@ -1195,26 +1207,17 @@ static void dpu_encoder_virt_atomic_enable(struct
drm_encoder *drm_enc,
struct dpu_encoder_virt *dpu_enc = NULL;
int ret = 0;
struct drm_display_mode *cur_mode = NULL;
- struct msm_drm_private *priv = drm_enc->dev->dev_private;
- struct msm_display_info *disp_info;
- int index;
dpu_enc = to_dpu_encoder_virt(drm_enc);
- disp_info = _enc->disp_info;
- index = disp_info->h_tile_instance[0];
-
dpu_enc->dsc = dpu_encoder_get_dsc_config(drm_enc);
atomic_set(_enc->frame_done_timeout_cnt, 0);
- if (disp_info->intf_type == INTF_DP)
- dpu_enc->wide_bus_en =
msm_dp_wide_bus_available(priv->dp[index]);
- else if (disp_info->intf_type == INTF_DSI)
- dpu_enc->wide_bus_en =
msm_dsi_wide_bus_enabled(priv->dsi[index]);
-
mutex_lock(_enc->enc_lock);
cur_mode = _enc->base.crtc->state->adjusted_mode;
+ dpu_enc->wide_bus_en = dpu_encoder_is_widebus_enabled(drm_enc);
+
trace_dpu_enc_enable(DRMID(drm_enc), cur_mode->hdisplay,
cur_mode->vdisplay);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index fe6b1d312a742..67aef59c1f99c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -156,6 +156,10 @@ int dpu_encoder_get_linecount(struct drm_encoder *drm_enc);
*/
int dpu_encoder_get_vsync_count(struct drm_encoder *drm_enc);
+/**
+ * dpu_encoder_is_widebus_enabled - return bool value if widebus is enabled
+ * @drm_enc:Pointer to previously created drm encoder structure
+ */
bool dpu_encoder_is_widebus_enabled(const struct drm_encoder *drm_enc);
/**
--
2.39.2
[PATCH v4 10/19] drm/msm/dp: program config ctrl for YUV420 over DP
Change relevant DP controller related programming for YUV420 cases. Program the configuration control register to indicate YUV420. Changes in v2: - Create a new patch only for configuration control programming Signed-off-by: Paloma Arellano Reviewed-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dp/dp_ctrl.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c index fb588fde298a2..6692d81adb195 100644 --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c @@ -128,6 +128,9 @@ static void dp_ctrl_config_ctrl(struct dp_ctrl_private *ctrl) /* Default-> LSCLK DIV: 1/4 LCLK */ config |= (2 << DP_CONFIGURATION_CTRL_LSCLK_DIV_SHIFT); + if (ctrl->panel->dp_mode.out_fmt_is_yuv_420) + config |= DP_CONFIGURATION_CTRL_RGB_YUV; /* YUV420 */ + /* Scrambler reset enable */ if (drm_dp_alternate_scrambler_reset_cap(dpcd)) config |= DP_CONFIGURATION_CTRL_ASSR; -- 2.39.2
[PATCH v4 05/19] drm/msm/dpu: move dpu_encoder_helper_phys_setup_cdm to dpu_encoder
Move dpu_encoder_helper_phys_setup_cdm to dpu_encoder in preparation for
implementing YUV420 over DP, which requires CDM compatibility.
Changes in v2:
- Slightly change the wording of the commit text to make clear
that YUV over DP requires CDM
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 78 +
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 9 ++
.../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 83 ---
3 files changed, 87 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 8932f38a41b2d..1905e8653b77a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2117,6 +2117,84 @@ void dpu_encoder_helper_phys_cleanup(struct
dpu_encoder_phys *phys_enc)
ctl->ops.clear_pending_flush(ctl);
}
+void dpu_encoder_helper_phys_setup_cdm(struct dpu_encoder_phys *phys_enc,
+ const struct dpu_format *dpu_fmt,
+ u32 output_type)
+{
+ struct dpu_hw_cdm *hw_cdm;
+ struct dpu_hw_cdm_cfg *cdm_cfg;
+ struct dpu_hw_pingpong *hw_pp;
+ int ret;
+
+ if (!phys_enc)
+ return;
+
+ cdm_cfg = _enc->cdm_cfg;
+ hw_pp = phys_enc->hw_pp;
+ hw_cdm = phys_enc->hw_cdm;
+
+ if (!hw_cdm)
+ return;
+
+ if (!DPU_FORMAT_IS_YUV(dpu_fmt)) {
+ DPU_DEBUG("[enc:%d] cdm_disable fmt:%x\n",
DRMID(phys_enc->parent),
+ dpu_fmt->base.pixel_format);
+ if (hw_cdm->ops.bind_pingpong_blk)
+ hw_cdm->ops.bind_pingpong_blk(hw_cdm, PINGPONG_NONE);
+
+ return;
+ }
+
+ memset(cdm_cfg, 0, sizeof(struct dpu_hw_cdm_cfg));
+
+ cdm_cfg->output_width = phys_enc->cached_mode.hdisplay;
+ cdm_cfg->output_height = phys_enc->cached_mode.vdisplay;
+ cdm_cfg->output_fmt = dpu_fmt;
+ cdm_cfg->output_type = output_type;
+ cdm_cfg->output_bit_depth = DPU_FORMAT_IS_DX(dpu_fmt) ?
+ CDM_CDWN_OUTPUT_10BIT : CDM_CDWN_OUTPUT_8BIT;
+ cdm_cfg->csc_cfg = _csc10_rgb2yuv_601l;
+
+ /* enable 10 bit logic */
+ switch (cdm_cfg->output_fmt->chroma_sample) {
+ case DPU_CHROMA_RGB:
+ cdm_cfg->h_cdwn_type = CDM_CDWN_DISABLE;
+ cdm_cfg->v_cdwn_type = CDM_CDWN_DISABLE;
+ break;
+ case DPU_CHROMA_H2V1:
+ cdm_cfg->h_cdwn_type = CDM_CDWN_COSITE;
+ cdm_cfg->v_cdwn_type = CDM_CDWN_DISABLE;
+ break;
+ case DPU_CHROMA_420:
+ cdm_cfg->h_cdwn_type = CDM_CDWN_COSITE;
+ cdm_cfg->v_cdwn_type = CDM_CDWN_OFFSITE;
+ break;
+ case DPU_CHROMA_H1V2:
+ default:
+ DPU_ERROR("[enc:%d] unsupported chroma sampling type\n",
+ DRMID(phys_enc->parent));
+ cdm_cfg->h_cdwn_type = CDM_CDWN_DISABLE;
+ cdm_cfg->v_cdwn_type = CDM_CDWN_DISABLE;
+ break;
+ }
+
+ DPU_DEBUG("[enc:%d] cdm_enable:%d,%d,%X,%d,%d,%d,%d]\n",
+ DRMID(phys_enc->parent), cdm_cfg->output_width,
+ cdm_cfg->output_height,
cdm_cfg->output_fmt->base.pixel_format,
+ cdm_cfg->output_type, cdm_cfg->output_bit_depth,
+ cdm_cfg->h_cdwn_type, cdm_cfg->v_cdwn_type);
+
+ if (hw_cdm->ops.enable) {
+ cdm_cfg->pp_id = hw_pp->idx;
+ ret = hw_cdm->ops.enable(hw_cdm, cdm_cfg);
+ if (ret < 0) {
+ DPU_ERROR("[enc:%d] failed to enable CDM; ret:%d\n",
+ DRMID(phys_enc->parent), ret);
+ return;
+ }
+ }
+}
+
#ifdef CONFIG_DEBUG_FS
static int _dpu_encoder_status_show(struct seq_file *s, void *data)
{
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index 204d7cc3c1de8..f43d57d9c74e1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -381,6 +381,15 @@ int dpu_encoder_helper_wait_for_irq(struct
dpu_encoder_phys *phys_enc,
*/
void dpu_encoder_helper_phys_cleanup(struct dpu_encoder_phys *phys_enc);
+/**
+ * dpu_encoder_helper_phys_setup_cdm - setup chroma down sampling block
+ * @phys_enc: Pointer to physical encoder
+ * @output_type: HDMI/WB
+ */
+void dpu_encoder_helper_phys_setup_cdm(struct dpu_encoder_phys *phys_enc,
+ const struct dpu_format *dpu_fmt,
+ u32 output_type);
+
/**
* dpu_encoder_vblank_callback - Notify virtual encoder of vblank IRQ reception
* @drm_enc:Pointer to drm encoder structure
diff --git
[PATCH v4 07/19] drm/msm/dp: store mode YUV420 information to be used by rest of DP
Wide bus is not supported when the mode is YUV420 in DP. In preparation
for changing the DPU programming to reflect this, the value and
assignment location of wide_bus_en for the DP submodules must be
changed. Move it from boot time in dp_init_sub_modules() to run time in
dp_display_mode_set.
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 17 +
drivers/gpu/drm/msm/dp/dp_panel.h | 1 +
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 792191f67717f..1a84f68e2b59a 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -785,10 +785,6 @@ static int dp_init_sub_modules(struct dp_display_private
*dp)
goto error_ctrl;
}
- /* populate wide_bus_supported to different layers */
- dp->ctrl->wide_bus_en = dp->wide_bus_supported;
- dp->catalog->wide_bus_en = dp->wide_bus_supported;
-
return rc;
error_ctrl:
@@ -809,6 +805,7 @@ static int dp_display_set_mode(struct msm_dp *dp_display,
drm_mode_copy(>panel->dp_mode.drm_mode, >drm_mode);
dp->panel->dp_mode.bpp = mode->bpp;
dp->panel->dp_mode.capabilities = mode->capabilities;
+ dp->panel->dp_mode.out_fmt_is_yuv_420 = mode->out_fmt_is_yuv_420;
dp_panel_init_panel_info(dp->panel);
return 0;
}
@@ -1403,6 +1400,9 @@ bool msm_dp_wide_bus_available(const struct msm_dp
*dp_display)
dp = container_of(dp_display, struct dp_display_private, dp_display);
+ if (dp->dp_mode.out_fmt_is_yuv_420)
+ return false;
+
return dp->wide_bus_supported;
}
@@ -1616,6 +1616,15 @@ void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
dp_display->dp_mode.h_active_low =
!!(dp_display->dp_mode.drm_mode.flags & DRM_MODE_FLAG_NHSYNC);
+
+ dp_display->dp_mode.out_fmt_is_yuv_420 =
+ drm_mode_is_420_only(>connector->display_info,
adjusted_mode);
+
+ /* populate wide_bus_support to different layers */
+ dp_display->ctrl->wide_bus_en =
+ dp_display->dp_mode.out_fmt_is_yuv_420 ? false :
dp_display->wide_bus_supported;
+ dp_display->catalog->wide_bus_en =
+ dp_display->dp_mode.out_fmt_is_yuv_420 ? false :
dp_display->wide_bus_supported;
}
void dp_bridge_hpd_enable(struct drm_bridge *bridge)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.h
b/drivers/gpu/drm/msm/dp/dp_panel.h
index a0dfc579c5f9f..6ec68be9f2366 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.h
+++ b/drivers/gpu/drm/msm/dp/dp_panel.h
@@ -19,6 +19,7 @@ struct dp_display_mode {
u32 bpp;
u32 h_active_low;
u32 v_active_low;
+ bool out_fmt_is_yuv_420;
};
struct dp_panel_in {
--
2.39.2
[PATCH v4 04/19] drm/msm/dpu: allow dpu_encoder_helper_phys_setup_cdm to work for DP
Generalize dpu_encoder_helper_phys_setup_cdm to be compatible with DP.
Changes in v2:
- Minor formatting changes
- Move the modification of the dimensions for CDM setup to a new
patch
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 4 +--
.../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 27 ++-
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index 993f263433314..204d7cc3c1de8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -154,6 +154,7 @@ enum dpu_intr_idx {
* @hw_wb: Hardware interface to the wb registers
* @hw_cdm:Hardware interface to the CDM registers
* @dpu_kms: Pointer to the dpu_kms top level
+ * @cdm_cfg: CDM block config needed to store WB/DP block's CDM
configuration
* @cached_mode: DRM mode cached at mode_set time, acted on in enable
* @vblank_ctl_lock: Vblank ctl mutex lock to protect vblank_refcount
* @enabled: Whether the encoder has enabled and running a mode
@@ -184,6 +185,7 @@ struct dpu_encoder_phys {
struct dpu_hw_wb *hw_wb;
struct dpu_hw_cdm *hw_cdm;
struct dpu_kms *dpu_kms;
+ struct dpu_hw_cdm_cfg cdm_cfg;
struct drm_display_mode cached_mode;
struct mutex vblank_ctl_lock;
enum dpu_enc_split_role split_role;
@@ -213,7 +215,6 @@ static inline int dpu_encoder_phys_inc_pending(struct
dpu_encoder_phys *phys)
* @wbirq_refcount: Reference count of writeback interrupt
* @wb_done_timeout_cnt: number of wb done irq timeout errors
* @wb_cfg: writeback block config to store fb related details
- * @cdm_cfg: cdm block config needed to store writeback block's CDM
configuration
* @wb_conn: backpointer to writeback connector
* @wb_job: backpointer to current writeback job
* @dest: dpu buffer layout for current writeback output buffer
@@ -223,7 +224,6 @@ struct dpu_encoder_phys_wb {
atomic_t wbirq_refcount;
int wb_done_timeout_cnt;
struct dpu_hw_wb_cfg wb_cfg;
- struct dpu_hw_cdm_cfg cdm_cfg;
struct drm_writeback_connector *wb_conn;
struct drm_writeback_job *wb_job;
struct dpu_hw_fmt_layout dest;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
index ec9e053d3947d..072fc6950e496 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c
@@ -269,28 +269,21 @@ static void dpu_encoder_phys_wb_setup_ctl(struct
dpu_encoder_phys *phys_enc)
* This API does not handle
DPU_CHROMA_H1V2.
* @phys_enc:Pointer to physical encoder
*/
-static void dpu_encoder_helper_phys_setup_cdm(struct dpu_encoder_phys
*phys_enc)
+static void dpu_encoder_helper_phys_setup_cdm(struct dpu_encoder_phys
*phys_enc,
+ const struct dpu_format *dpu_fmt,
+ u32 output_type)
{
struct dpu_hw_cdm *hw_cdm;
struct dpu_hw_cdm_cfg *cdm_cfg;
struct dpu_hw_pingpong *hw_pp;
- struct dpu_encoder_phys_wb *wb_enc;
- const struct msm_format *format;
- const struct dpu_format *dpu_fmt;
- struct drm_writeback_job *wb_job;
int ret;
if (!phys_enc)
return;
- wb_enc = to_dpu_encoder_phys_wb(phys_enc);
- cdm_cfg = _enc->cdm_cfg;
+ cdm_cfg = _enc->cdm_cfg;
hw_pp = phys_enc->hw_pp;
hw_cdm = phys_enc->hw_cdm;
- wb_job = wb_enc->wb_job;
-
- format = msm_framebuffer_format(wb_enc->wb_job->fb);
- dpu_fmt = dpu_get_dpu_format_ext(format->pixel_format,
wb_job->fb->modifier);
if (!hw_cdm)
return;
@@ -309,7 +302,7 @@ static void dpu_encoder_helper_phys_setup_cdm(struct
dpu_encoder_phys *phys_enc)
cdm_cfg->output_width = phys_enc->cached_mode.hdisplay;
cdm_cfg->output_height = phys_enc->cached_mode.vdisplay;
cdm_cfg->output_fmt = dpu_fmt;
- cdm_cfg->output_type = CDM_CDWN_OUTPUT_WB;
+ cdm_cfg->output_type = output_type;
cdm_cfg->output_bit_depth = DPU_FORMAT_IS_DX(dpu_fmt) ?
CDM_CDWN_OUTPUT_10BIT : CDM_CDWN_OUTPUT_8BIT;
cdm_cfg->csc_cfg = _csc10_rgb2yuv_601l;
@@ -462,6 +455,14 @@ static void dpu_encoder_phys_wb_setup(
struct dpu_hw_wb *hw_wb = phys_enc->hw_wb;
struct drm_display_mode mode = phys_enc->cached_mode;
struct drm_framebuffer *fb = NULL;
+ struct dpu_encoder_phys_wb *wb_enc = to_dpu_encoder_phys_wb(phys_enc);
+ struct drm_writeback_job *wb_job;
+ const struct msm_format *format;
+ const struct dpu_format *dpu_fmt;
+
+
[PATCH v4 06/19] drm/msm/dp: rename wide_bus_en to wide_bus_supported
Rename wide_bus_en to wide_bus_supported in dp_display_private to
correctly establish that the parameter is referencing if wide bus is
supported instead of enabled.
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 42 ++---
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index c8e1bbebdffe2..792191f67717f 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -114,7 +114,7 @@ struct dp_display_private {
struct dp_event event_list[DP_EVENT_Q_MAX];
spinlock_t event_lock;
- bool wide_bus_en;
+ bool wide_bus_supported;
struct dp_audio *audio;
};
@@ -123,7 +123,7 @@ struct msm_dp_desc {
phys_addr_t io_start;
unsigned int id;
unsigned int connector_type;
- bool wide_bus_en;
+ bool wide_bus_supported;
};
static const struct msm_dp_desc sc7180_dp_descs[] = {
@@ -132,8 +132,8 @@ static const struct msm_dp_desc sc7180_dp_descs[] = {
};
static const struct msm_dp_desc sc7280_dp_descs[] = {
- { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
+ { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_supported = true },
{}
};
@@ -145,22 +145,22 @@ static const struct msm_dp_desc sc8180x_dp_descs[] = {
};
static const struct msm_dp_desc sc8280xp_dp_descs[] = {
- { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- { .io_start = 0x0ae98000, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- { .io_start = 0x2209, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- { .io_start = 0x22098000, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- { .io_start = 0x2209a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
- { .io_start = 0x220a, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
+ { .io_start = 0x0ae9, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
+ { .io_start = 0x0ae98000, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
+ { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
+ { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
+ { .io_start = 0x2209, .id = MSM_DP_CONTROLLER_0, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
+ { .io_start = 0x22098000, .id = MSM_DP_CONTROLLER_1, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
+ { .io_start = 0x2209a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
+ { .io_start = 0x220a, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_supported = true },
{}
};
static const struct msm_dp_desc sc8280xp_edp_descs[] = {
- { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
- { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
- { .io_start = 0x2209a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
- { .io_start = 0x220a, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
+ { .io_start = 0x0ae9a000, .id = MSM_DP_CONTROLLER_2, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_supported = true },
+ { .io_start = 0x0aea, .id = MSM_DP_CONTROLLER_3, .connector_type =
DRM_MODE_CONNECTOR_eDP, .wide_bus_supported = true },
+ { .io_start = 0x2209a000, .id =
[PATCH v4 08/19] drm/msm/dp: check if VSC SDP is supported in DP programming
In the DP driver, check if VSC SDP is supported and propagate this value
to dp_panel. In dp_display's dp_mode, the out_fmt_is_yuv_420 parameter
must also utilize this value since YUV420 is only allowed when VSC SDP
is supported.
Changes in v2:
- Move DP programming when VSC SDP is supported to this patch
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 5 -
drivers/gpu/drm/msm/dp/dp_panel.c | 1 +
drivers/gpu/drm/msm/dp/dp_panel.h | 1 +
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 1a84f68e2b59a..4b1b79b74bc72 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1596,8 +1596,10 @@ void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
struct msm_dp_bridge *dp_bridge = to_dp_bridge(drm_bridge);
struct msm_dp *dp = dp_bridge->dp_display;
struct dp_display_private *dp_display;
+ struct dp_panel *dp_panel;
dp_display = container_of(dp, struct dp_display_private, dp_display);
+ dp_panel = dp_display->panel;
memset(_display->dp_mode, 0x0, sizeof(struct dp_display_mode));
@@ -1618,7 +1620,8 @@ void dp_bridge_mode_set(struct drm_bridge *drm_bridge,
!!(dp_display->dp_mode.drm_mode.flags & DRM_MODE_FLAG_NHSYNC);
dp_display->dp_mode.out_fmt_is_yuv_420 =
- drm_mode_is_420_only(>connector->display_info,
adjusted_mode);
+ drm_mode_is_420_only(>connector->display_info,
adjusted_mode) &&
+ dp_panel->vsc_sdp_supported;
/* populate wide_bus_support to different layers */
dp_display->ctrl->wide_bus_en =
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 127f6af995cd1..db1942794f1a4 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -53,6 +53,7 @@ static int dp_panel_read_dpcd(struct dp_panel *dp_panel)
if (rc)
return rc;
+ dp_panel->vsc_sdp_supported = drm_dp_vsc_sdp_supported(panel->aux,
dpcd);
link_info = _panel->link_info;
link_info->revision = dpcd[DP_DPCD_REV];
major = (link_info->revision >> 4) & 0x0f;
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.h
b/drivers/gpu/drm/msm/dp/dp_panel.h
index 6ec68be9f2366..e843f5062d1f6 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.h
+++ b/drivers/gpu/drm/msm/dp/dp_panel.h
@@ -46,6 +46,7 @@ struct dp_panel {
struct dp_display_mode dp_mode;
struct dp_panel_psr psr_cap;
bool video_test;
+ bool vsc_sdp_supported;
u32 vic;
u32 max_dp_lanes;
--
2.39.2
[PATCH v4 03/19] drm/msm/dpu: pass mode dimensions instead of fb size in CDM setup
Modify the output width and height parameters of hw_cdm to utilize the physical encoder's data instead of obtaining the information from the framebuffer. CDM is to be set up to utilize the actual output data since at CDM setup, there is no difference between the two sources. Changes in v2: - Move the modification of the dimensions for CDM setup to this new patch Signed-off-by: Paloma Arellano Reviewed-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c index 4cd2d9e3131a4..ec9e053d3947d 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c @@ -306,8 +306,8 @@ static void dpu_encoder_helper_phys_setup_cdm(struct dpu_encoder_phys *phys_enc) memset(cdm_cfg, 0, sizeof(struct dpu_hw_cdm_cfg)); - cdm_cfg->output_width = wb_job->fb->width; - cdm_cfg->output_height = wb_job->fb->height; + cdm_cfg->output_width = phys_enc->cached_mode.hdisplay; + cdm_cfg->output_height = phys_enc->cached_mode.vdisplay; cdm_cfg->output_fmt = dpu_fmt; cdm_cfg->output_type = CDM_CDWN_OUTPUT_WB; cdm_cfg->output_bit_depth = DPU_FORMAT_IS_DX(dpu_fmt) ? -- 2.39.2
[PATCH v4 02/19] drm/msm/dpu: add division of drm_display_mode's hskew parameter
Setting up the timing engine when the physical encoder has a split role
neglects dividing the drm_display_mode's hskew parameter. Let's fix this
since this must also be done in preparation for implementing YUV420 over
DP.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index f562beb6f7971..f02411b062c4c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -260,12 +260,14 @@ static void dpu_encoder_phys_vid_setup_timing_engine(
mode.htotal >>= 1;
mode.hsync_start >>= 1;
mode.hsync_end >>= 1;
+ mode.hskew >>= 1;
DPU_DEBUG_VIDENC(phys_enc,
- "split_role %d, halve horizontal %d %d %d %d\n",
+ "split_role %d, halve horizontal %d %d %d %d %d\n",
phys_enc->split_role,
mode.hdisplay, mode.htotal,
- mode.hsync_start, mode.hsync_end);
+ mode.hsync_start, mode.hsync_end,
+ mode.hskew);
}
drm_mode_to_intf_timing_params(phys_enc, , _params);
--
2.39.2
[PATCH v4 00/19] Add support for CDM over DP
The Chroma Down Sampling (CDM) block is a hardware component in the DPU pipeline that includes a CSC block capable of converting RGB input from the DPU to YUV data. This block can be used with either HDMI, DP, or writeback interfaces. This series adds support for the CDM block to be used with DP in YUV420 mode format. This series allows selection of the YUV420 format for monitors which support certain resolutions only in YUV420 thus unblocking the validation of many other resolutions which were previously filtered out if the connector did not support YUV420. This was validated using a DP connected monitor requiring the use of YUV420 format. This series is dependent on [1], [2], and [3]: [1] https://patchwork.freedesktop.org/series/118831/ [2] https://patchwork.freedesktop.org/series/129395/ [3] https://patchwork.freedesktop.org/series/129864/ Changes in v4: - Use dp_utils_pack_sdp_header() to pack the SDP header and parity bytes into a buffer - Use this buffer when writing the VSC SDP data in dp_catalog_panel_send_vsc_sdp() and write to all the MMSS_DP_GENERIC0 registers - Clear up that DP_MAINLINK_CTRL_FLUSH_MODE register requires the use of bits [24:23] - Modify certain macros to explicitly set their values in the bits of DP_MAINLINK_CTRL_FLUSH_MODE_MASK - Remove hw_cdm check in dpu_encoder_needs_periph_flush() and dpu_encoder_phys_vid_enable() Changes in v3: - Change ordering of the header byte macros in dp_utils.h - Create a new struct, msm_dp_sdp_with_parity - Utilize drm_dp_vsc_sdp_pack() from a new added dependency of series [3] to pack the VSC SDP data into the new msm_dp_sdp_with_parity struct instead of packing only for YUV420 - Modify dp_catalog_panel_send_vsc_sdp() so that it sends the VSC SDP data using the new msm_dp_sdp_with_parity struct - Clear up that the DP_MAINLINK_FLUSH_MODE_SDE_PERIPH_UPDATE macro is setting multiple bits and not just one - Move the connector's ycbcr_420_allowed parameter so it is no longer dependent on if the dp_display is not eDP Changes in v2: - Minor formatting changes throughout - Move 'fixes' patch to the top - Move VSC SDP support check API from dp_panel.c to drm_dp_helper.c - Create a separate patch for modifying the dimensions for CDM setup to be non-WB specific - Remove a patch that modified the INTF_CONFIG2 register in favor of having this series be dependent on [2] - Separate configuration ctrl programming from clock related programming into two patches - Add a VSC SDP check in dp_bridge_mode_valid() - Move parity calculation functions to new files dp_utils.c and dp_utils.h - Remove dp_catalog_hw_revision() changes and utilize the original version of the function when checking the DP hardware version - Create separate packing and programming functions for the VSC SDP - Make the packing header bytes function generic so it can be used with dp_audio.c - Create two separate enable/disable VSC SDP functions instead of having one with the ability to do both - Move timing engine programming to a separate patch from original encoder programming patch - Move update_pending_flush_periph() code to be in the same patch as the encoder programming - Create new API's to check if the dpu encoder needs a peripheral flush - Allow YUV420 modes for the DP connector when there's a CDM block available instead of checking if VSC SDP is supported Kuogee Hsieh (1): drm/msm/dpu: add support of new peripheral flush mechanism Paloma Arellano (18): drm/msm/dpu: allow certain formats for CDM for DP drm/msm/dpu: add division of drm_display_mode's hskew parameter drm/msm/dpu: pass mode dimensions instead of fb size in CDM setup drm/msm/dpu: allow dpu_encoder_helper_phys_setup_cdm to work for DP drm/msm/dpu: move dpu_encoder_helper_phys_setup_cdm to dpu_encoder drm/msm/dp: rename wide_bus_en to wide_bus_supported drm/msm/dp: store mode YUV420 information to be used by rest of DP drm/msm/dp: check if VSC SDP is supported in DP programming drm/msm/dpu: move widebus logic to its own API drm/msm/dp: program config ctrl for YUV420 over DP drm/msm/dp: change clock related programming for YUV420 over DP drm/msm/dp: move parity calculation to dp_utils drm/msm/dp: add VSC SDP support for YUV420 over DP drm/msm/dp: enable SDP and SDE periph flush update drm/msm/dpu: modify encoder programming for CDM over DP drm/msm/dpu: modify timing engine programming for YUV420 over DP drm/msm/dpu: reserve CDM blocks for DP if mode is YUV420 drm/msm/dp: allow YUV420 mode for DP connector when CDM available drivers/gpu/drm/msm/Makefile
Re: [PATCH 0/3] drm/panel: add one more Leadtek panel, the ltk101b4029w
On Thu, 15 Feb 2024 10:05:12 +0100, Heiko Stuebner wrote: > Similar in setup to the ltk500hd1829, group it with this driver. > > Heiko Stuebner (3): > drm/panel: ltk500hd1829: make room for more similar panels > dt-bindings: display: ltk500hd1829: add variant compatible for > ltk101b4029w > drm/panel: ltk500hd1829: add panel type for ltk101b4029w > > [...] Applied, thanks! Adapted the commit message in the binding patch to show where the panels are similar but also different (init-sequence) [1/3] drm/panel: ltk500hd1829: make room for more similar panels commit: f9488c160d6e8e5e548452a0d36057a1f8c04045 [2/3] dt-bindings: display: ltk500hd1829: add variant compatible for ltk101b4029w commit: c71efc6337135670164334404ef11506b31b7a81 [3/3] drm/panel: ltk500hd1829: add panel type for ltk101b4029w commit: 239cce651ea617002ff26f068f2568b2baf6421a Best regards, -- Heiko Stuebner
Re: [PATCH 1/2] dt-bindings: vendor-prefixes: add prefix for admatec GmbH
On Thu, 15 Feb 2024 10:04:41 +0100, Heiko Stuebner wrote: > From: Heiko Stuebner > > admatec GmbH is a german supplier for industrial displays. > > Applied, thanks! Adding the link to the manufacturer Conor suggested. [1/2] dt-bindings: vendor-prefixes: add prefix for admatec GmbH commit: 9de552935b6ceaa113d205232fde70e5345bdf29 [2/2] dt-bindings: display: panel-lvds: Add compatible for admatec 9904370 panel commit: c530379a6876eb4c9c4a83f1b65d8cd9d66ee229 Best regards, -- Heiko Stuebner
Re: Re: [PULL] drm-misc-fixes
Hi Maxime, Dave,
On Thu, Feb 15, 2024 at 5:45 PM Geert Uytterhoeven wrote:
> On Thu, Feb 15, 2024 at 5:09 PM Maxime Ripard wrote:
> On Thu, Feb 15, 2024 at 01:41:24PM +0100, Geert Uytterhoeven wrote:
> > > On Thu, 15 Feb 2024, Maxime Ripard wrote:
> > > > Matthew Auld (1):
> > > > drm/tests/drm_buddy: add alloc_contiguous test
> > >
> > > Please drop this one.
> > >
> > > nore...@ellerman.id.au reported a build failure on m68k (and presumably
> > > other 32-bit platforms) in next-20240215:
> > >
> > > ERROR: modpost: "__umoddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko]
> > > undefined!
> > > ERROR: modpost: "__moddi3" [drivers/gpu/drm/tests/drm_buddy_test.ko]
> > > undefined!
> > >
> > > Reverting commit a64056bb5a3215bd ("drm/tests/drm_buddy: add
> > > alloc_contiguous test") fixes the issue.
> >
> > From a quick cross-compile test with arm(32), it seems to work there
> > interestingly:
> >
> > ./tools/testing/kunit/kunit.py run \
> > --kunitconfig=drivers/gpu/drm//tests \
> > --cross_compile arm-linux-gnu- --arch arm
>
> shmobile_defconfig + CONFIG_DRM_KUNIT_TEST=y + CONFIG_KUNIT=y:
>
> arm-linux-gnueabihf-ld: drivers/gpu/drm/tests/drm_buddy_test.o: in
> function `drm_test_buddy_alloc_contiguous':
> drm_buddy_test.c:(.text+0xe0): undefined reference to `__aeabi_uldivmod'
>
> > But I agree, with should wait for a fix or a revert before merging this.
>
> Great, thanks!
Unfortunately the breakage still made it upstream.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 00/28] Plane Color Pipeline support for Intel platforms
On 2024-02-13 01:48, Uma Shankar wrote: > This series intends to add support for Plane Color Management for > Intel platforms. This is based on the design which has been agreed > upon by the community. Series implementing the design for generic > DRM core has been sent out by Harry Wentland and is under review > below: > https://patchwork.freedesktop.org/series/123446/ > > The base work of above series is squashed under 1 patch and support > for Intel platform is added on top of it. > Any reviews on the original core design is expected to be done in > Harry's series to avoid any forking of the discussion. > > We have added some changes/fixes to the Harry's core DRM changes, > being put up as separate patches on top of squashed patch. These are > expected to get included in the main series from Harry once agreed upon. > > Changes added on core design: > 1. Below patches implement some fixes on original series > drm: Add missing function declarations > drm: handle NULL next colorop in drm_colorop_set_next_property > drm: Fix error logging in set Color Pipeline > > 2. Implemented a HW capability property to expose segmented luts. > drm: Add Color lut range attributes > drm: Add Color ops capability property > drm: Define helper to create color ops capability property > drm: Define helper for adding capability property for 1D LUT > > This helps in generically defining the hardware lut capabilities, > lut distribution, precision, segmented or PWL LUTS. > > 3. Added support for enhanced prescision, 3x3 matrix and 1d LUT: > drm: Add Enhanced LUT precision structure > drm: Add support for 3x3 CTM > drm: Add 1D LUT color op > > On top of this base work for DRM core plane color pipeline design, > implementation is done for Intel hardware platforms. Below patches > include the same: > > drm/i915: Add identifiers for intel color blocks > drm/i915: Add intel_color_op > drm/i915/color: Add helper to allocate intel colorop > drm/i915/color: Add helper to create intel colorop > drm/i915/color: Create a transfer function color pipeline > drm/i915/color: Add and attach COLORPIPELINE plane property > drm/i915/color: Add framework to set colorop > drm/i915/color: Add callbacks to set plane CTM > drm/i915/color: Add framework to program PRE/POST CSC LUT > FIXME: force disable legacy plane color properties for TGL and beyond > drm/i915/color: Enable Plane Color Pipelines > drm/i915: Define segmented Lut and add capabilities to colorop > drm/i915/color: Add plane CTM callback for TGL and beyond > drm/i915: Add register definitions for Plane Degamma > drm/i915: Add register definitions for Plane Post CSC > drm/i915/color: Program Pre-CSC registers > drm/i915/xelpd: Program Plane Post CSC Registers > > Bhanu from Intel will be sending out the igt changes to help test the > color pipeline implementation based on the current igt changes sent out > by Harry. > https://patchwork.freedesktop.org/series/123448/ > > Planned Next Steps: > 1. Work with Harry and community and get DRM core changes for color > pipeline merged. We'll need a userspace to implement support before merging, but we're working to enabling all color properties gamescope currently uses for the SteamDeck color management to the Color Pipeline API, which should help us get there. It's still a journey but I think the path is clear. I'll send a new version of my patch series next week, including some AMD implementation (not the entire AMD pipeline yet). We're also adding a 1D_LUT type that's much simpler, basically a copy of what the drm_crtc currently uses. One option is to keep both types, another is to see if AMD's LUT can be expressed using the caps that you define. I think it should be possible to express it as a single segment. There might be another few changes in the core that might help you. Like seeing the value of the client cap in the driver. It's really good to see your work. With that we'll have three driver implementations: VKMS, Intel, AMD,, which shows broad usability of this approach. Harry > 2. Implement pipe color management (post blending) based on the current > color pipeline design. > 3. Work with compositor maintainers to get color processing implemented > using display hardware, thereby avoid any GL or GPU shaders. > > Thanks to all the community maintainers and contributors who have helped > to get this support in upstream Linux. Looking forward to collaborate, > work together and get this merged. > > Cc: Ville Syrjala > Cc: Pekka Paalanen > Cc: Simon Ser > Cc: Harry Wentland > Cc: Melissa Wen > Cc: Jonas Ådahl > Cc: Sebastian Wick > Cc: Shashank Sharma > Cc: Alexander Goins > Cc: Joshua Ashton > Cc: Michel Dänzer > Cc: Aleix Pol > Cc: Xaver Hugl > Cc: Victoria Brekenfeld > Cc: Sima > Cc: Naseer Ahmed > Cc: Christopher Braga > Cc: Abhinav Kumar > Cc: Arthur Grillo > Cc: Hector Martin > Cc: Liviu Dudau > Cc: Sasha McIntosh > Cc: Chaitanya Kumar Borah > > Chaitanya Kumar Borah (16): > drm: Add
Re: [PATCH] drm/panel: boe-tv101wum-nl6: make use of prepare_prev_first
On 2/16/2024 12:31 PM, Douglas Anderson wrote:
The panel on sc7180-trogdor-wormdingler and
sc7180-trogdor-quackingstick hasn't been coming up since commit
9e15123eca79 ("drm/msm/dsi: Stop unconditionally powering up DSI hosts
at modeset"). Let's add "prepare_prev_first" as has been done for many
other DSI panels.
Fixes: 9e15123eca79 ("drm/msm/dsi: Stop unconditionally powering up DSI hosts at
modeset")
Signed-off-by: Douglas Anderson
Hi Doug,
Reviewed-by: Jessica Zhang
Thanks,
Jessica Zhang
---
This of course gets into debates about getting a nicer solution that
doesn't involve adding "prepare_prev_first" to every DSI panel out
there, maybe building on Dmitry's work [1]. While it would be nice if
we could get there, getting this landed is easy to backport to stable
trees and gets the panel working again.
[1]
https://lore.kernel.org/r/20231016165355.1327217-4-dmitry.barysh...@linaro.org
drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index c4c0f08e9202..bc08814954f9 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -1871,6 +1871,8 @@ static int boe_panel_add(struct boe_panel *boe)
gpiod_set_value(boe->enable_gpio, 0);
+ boe->base.prepare_prev_first = true;
+
drm_panel_init(>base, dev, _panel_funcs,
DRM_MODE_CONNECTOR_DSI);
err = of_drm_get_panel_orientation(dev->of_node, >orientation);
--
2.44.0.rc0.258.g7320e95886-goog
Re: [PATCH] drm/amd: Drop abm_level property
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
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
[PATCH v2 1/2] Revert "leds: Only descend into leds directory when CONFIG_NEW_LEDS is set"
This reverts commit b1ae40a5db6191c42e2e45d726407096f030ee08.
The ExpressWire library introduced in commit 25ae5f5f4168 ("leds:
Introduce ExpressWire library") does not depend on NEW_LEDS, but without
this revert it would never get compiled if NEW_LEDS is not enabled.
Revert this commit to allow the library to be compiled.
Link:
https://lore.kernel.org/2cacd8dc-6150-4aa2-af9e-830a202fb...@app.fastmail.com
Suggested-by: Arnd Bergmann
Reviewed-by: Daniel Thompson
Signed-off-by: Duje Mihanović
---
Changes in v2:
- Add "commit" before hash to silence checkpatch
---
drivers/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/Makefile b/drivers/Makefile
index 37fd6ce3bd7f..3bf5cab4b451 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -135,7 +135,7 @@ obj-$(CONFIG_CPU_IDLE) += cpuidle/
obj-y += mmc/
obj-y += ufs/
obj-$(CONFIG_MEMSTICK) += memstick/
-obj-$(CONFIG_NEW_LEDS) += leds/
+obj-y += leds/
obj-$(CONFIG_INFINIBAND) += infiniband/
obj-y += firmware/
obj-$(CONFIG_CRYPTO) += crypto/
--
2.43.1
[PATCH v2 0/2] leds: expresswire: Fix dependencies
LEDS_EXPRESSWIRE does not depend on NEW_LEDS in practice but still does in Kconfig. Fix up its Kconfig entry to reflect this and fix a Kconfig warning. Signed-off-by: Duje Mihanović --- Changes in v2: - Fix checkpatch errors - Pull Daniel's Reviewed-by - Link to v1: https://lore.kernel.org/r/20240212-expresswire-deps-v1-0-685ad10cd...@skole.hr --- Duje Mihanović (2): Revert "leds: Only descend into leds directory when CONFIG_NEW_LEDS is set" leds: expresswire: don't depend on NEW_LEDS drivers/Makefile | 2 +- drivers/leds/Kconfig | 10 ++ 2 files changed, 7 insertions(+), 5 deletions(-) --- base-commit: ae00c445390b349e070a64dc62f08aa878db7248 change-id: 20240212-expresswire-deps-e895e8da8ea3 Best regards, -- Duje Mihanović
[PATCH v2 2/2] leds: expresswire: don't depend on NEW_LEDS
The ExpressWire library does not depend on NEW_LEDS and selecting it
from a subsystem other than LEDs may cause Kconfig warnings:
WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
Depends on [n]: NEW_LEDS [=n] && GPIOLIB [=y]
Selected by [y]:
- BACKLIGHT_KTD2801 [=y] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=y]
Move it out of the "if NEW_LEDS" block to allow selection from other
subsystems (in particular backlight) without raising this warning.
Reported-by: Arnd Bergmann
Closes: https://lore.kernel.org/20240212111819.936815-1-a...@kernel.org
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202402161410.ig9i4odj-...@intel.com/
Suggested-by: Daniel Thompson
Fixes: 25ae5f5f4168 ("leds: Introduce ExpressWire library")
Reviewed-by: Daniel Thompson
Signed-off-by: Duje Mihanović
---
Changes in v2:
- Change Link: to Closes: to silence checkpatch
- Add kernel test robot's error report
---
drivers/leds/Kconfig | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 52328d295b4e..66998b938ed3 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -6,6 +6,12 @@ config LEDS_GPIO_REGISTER
As this function is used by arch code it must not be compiled as a
module.
+# This library does not depend on NEW_LEDS and must be independent so it can be
+# selected from other subsystems (specifically backlight).
+config LEDS_EXPRESSWIRE
+ bool
+ depends on GPIOLIB
+
menuconfig NEW_LEDS
bool "LED Support"
help
@@ -186,10 +192,6 @@ config LEDS_EL15203000
To compile this driver as a module, choose M here: the module
will be called leds-el15203000.
-config LEDS_EXPRESSWIRE
- bool
- depends on GPIOLIB
-
config LEDS_TURRIS_OMNIA
tristate "LED support for CZ.NIC's Turris Omnia"
depends on LEDS_CLASS_MULTICOLOR
--
2.43.1
[PATCH] drm/ci: skip suspend tests for both msm-sc7180 machines
The commit ea489a3d983b ("drm/ci: add sc7180-trogdor-kingoftown")
dropped the msm-sc7180-skips.txt file, which disabled suspend-to-RAM
tests. However testing shows that STR tests still can fail. Restore the
skiplist, applying it to both limozeen and kingoftown machines.
Fixes: ea489a3d983b ("drm/ci: add sc7180-trogdor-kingoftown")
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-skips.txt | 2 ++
.../drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-skips.txt | 2 ++
2 files changed, 4 insertions(+)
create mode 100644
drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-skips.txt
create mode 100644
drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-skips.txt
diff --git a/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-skips.txt
b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-skips.txt
new file mode 100644
index ..327039f70252
--- /dev/null
+++ b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-kingoftown-skips.txt
@@ -0,0 +1,2 @@
+# Suspend to RAM seems to be broken on this machine
+.*suspend.*
diff --git
a/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-skips.txt
b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-skips.txt
new file mode 100644
index ..327039f70252
--- /dev/null
+++ b/drivers/gpu/drm/ci/xfails/msm-sc7180-trogdor-lazor-limozeen-skips.txt
@@ -0,0 +1,2 @@
+# Suspend to RAM seems to be broken on this machine
+.*suspend.*
--
2.39.2
[PATCH] drm/panel: boe-tv101wum-nl6: make use of prepare_prev_first
The panel on sc7180-trogdor-wormdingler and
sc7180-trogdor-quackingstick hasn't been coming up since commit
9e15123eca79 ("drm/msm/dsi: Stop unconditionally powering up DSI hosts
at modeset"). Let's add "prepare_prev_first" as has been done for many
other DSI panels.
Fixes: 9e15123eca79 ("drm/msm/dsi: Stop unconditionally powering up DSI hosts
at modeset")
Signed-off-by: Douglas Anderson
---
This of course gets into debates about getting a nicer solution that
doesn't involve adding "prepare_prev_first" to every DSI panel out
there, maybe building on Dmitry's work [1]. While it would be nice if
we could get there, getting this landed is easy to backport to stable
trees and gets the panel working again.
[1]
https://lore.kernel.org/r/20231016165355.1327217-4-dmitry.barysh...@linaro.org
drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index c4c0f08e9202..bc08814954f9 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -1871,6 +1871,8 @@ static int boe_panel_add(struct boe_panel *boe)
gpiod_set_value(boe->enable_gpio, 0);
+ boe->base.prepare_prev_first = true;
+
drm_panel_init(>base, dev, _panel_funcs,
DRM_MODE_CONNECTOR_DSI);
err = of_drm_get_panel_orientation(dev->of_node, >orientation);
--
2.44.0.rc0.258.g7320e95886-goog
[PATCH] drm/tests/drm_buddy: avoid 64-bit calculation
From: Arnd Bergmann
The newly added drm_test_buddy_alloc_contiguous() test fails to link on
32-bit targets because of inadvertent 64-bit calculations:
ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/tests/drm_buddy_test.ko]
undefined!
ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/tests/drm_buddy_test.ko]
undefined!
>From what I can tell, the numbers cannot possibly overflow a 32-bit size,
so use different types for these.
I noticed that the function has another possible flaw in that is mixes
what it calls pages with 4KB units. This is a big confusing at best,
or possibly broken when built on machines with larger pages.
Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/tests/drm_buddy_test.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index fee6bec757d1..50a5f98cd5bd 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -21,7 +21,8 @@ static inline u64 get_size(int order, u64 chunk_size)
static void drm_test_buddy_alloc_contiguous(struct kunit *test)
{
- u64 mm_size, ps = SZ_4K, i, n_pages, total;
+ u64 mm_size, total;
+ u32 i, ps = SZ_4K, n_pages;
struct drm_buddy_block *block;
struct drm_buddy mm;
LIST_HEAD(left);
@@ -29,7 +30,8 @@ static void drm_test_buddy_alloc_contiguous(struct kunit
*test)
LIST_HEAD(right);
LIST_HEAD(allocated);
- mm_size = 16 * 3 * SZ_4K;
+ n_pages = 16 * 3;
+ mm_size = n_pages * SZ_4K;
KUNIT_EXPECT_FALSE(test, drm_buddy_init(, mm_size, ps));
@@ -42,7 +44,6 @@ static void drm_test_buddy_alloc_contiguous(struct kunit
*test)
*/
i = 0;
- n_pages = mm_size / ps;
do {
struct list_head *list;
int slot = i % 3;
--
2.39.2
[PATCH 3/3] drm/sun4i: Fix layer zpos change/atomic modesetting
From: Ondrej Jirman
Identical configurations of planes can lead to different (and wrong)
layer -> pipe routing at HW level, depending on the order of atomic
plane changes.
For example:
- Layer 1 is configured to zpos 0 and thus uses pipe 0. No other layer
is enabled. This is a typical situation at boot.
- When a compositor takes over and layer 3 is enabled,
sun8i_ui_layer_enable() will get called with old_zpos=0 zpos=1, which
will lead to incorrect disabling of pipe 0 and enabling of pipe 1.
What happens is that sun8i_ui_layer_enable() function may disable
blender pipes even if it is no longer assigned to its layer.
To correct this, move the routing setup out of individual plane's
atomic_update into crtc's atomic_update, where it can be calculated
and updated all at once.
Remove the atomic_disable callback because it is no longer needed.
Signed-off-by: Ondrej Jirman
---
drivers/gpu/drm/sun4i/sun8i_mixer.c| 73 +
drivers/gpu/drm/sun4i/sun8i_mixer.h| 6 +++
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 73 +
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 74 +-
4 files changed, 83 insertions(+), 143 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index bdeb9b80e038..21331d4ffe01 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -250,12 +250,85 @@ int sun8i_mixer_drm_format_to_hw(u32 format, u32
*hw_format)
return -EINVAL;
}
+static void sun8i_layer_enable(struct sun8i_layer *layer, bool enable)
+{
+ u32 ch_base = sun8i_channel_base(layer->mixer, layer->channel);
+ u32 val, reg, mask;
+
+ if (layer->type == SUN8I_LAYER_TYPE_UI) {
+ val = enable ? SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN : 0;
+ mask = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN;
+ reg = SUN8I_MIXER_CHAN_UI_LAYER_ATTR(ch_base, layer->overlay);
+ } else {
+ val = enable ? SUN8I_MIXER_CHAN_VI_LAYER_ATTR_EN : 0;
+ mask = SUN8I_MIXER_CHAN_VI_LAYER_ATTR_EN;
+ reg = SUN8I_MIXER_CHAN_VI_LAYER_ATTR(ch_base, layer->overlay);
+ }
+
+ regmap_update_bits(layer->mixer->engine.regs, reg, mask, val);
+}
+
static void sun8i_mixer_commit(struct sunxi_engine *engine,
struct drm_crtc *crtc,
struct drm_atomic_state *state)
{
+ struct sun8i_mixer *mixer = engine_to_sun8i_mixer(engine);
+ u32 bld_base = sun8i_blender_base(mixer);
+ struct drm_plane_state *plane_state;
+ struct drm_plane *plane;
+ u32 route = 0, pipe_en = 0;
+
DRM_DEBUG_DRIVER("Committing changes\n");
+ drm_for_each_plane(plane, state->dev) {
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
+ bool enable;
+ int zpos;
+
+ if (!(plane->possible_crtcs & drm_crtc_mask(crtc)) ||
layer->mixer != mixer)
+ continue;
+
+ plane_state = drm_atomic_get_new_plane_state(state, plane);
+ if (!plane_state)
+ plane_state = plane->state;
+
+ enable = plane_state->crtc && plane_state->visible;
+ zpos = plane_state->normalized_zpos;
+
+ DRM_DEBUG_DRIVER(" plane %d: chan=%d ovl=%d en=%d zpos=%d\n",
+plane->base.id, layer->channel, layer->overlay,
+enable, zpos);
+
+ /*
+* We always update the layer enable bit, because it can clear
+* spontaneously for unknown reasons.
+*/
+ sun8i_layer_enable(layer, enable);
+
+ if (!enable)
+ continue;
+
+ /* Route layer to pipe based on zpos */
+ route |= layer->channel <<
SUN8I_MIXER_BLEND_ROUTE_PIPE_SHIFT(zpos);
+ pipe_en |= SUN8I_MIXER_BLEND_PIPE_CTL_EN(zpos);
+ }
+
+ regmap_update_bits(mixer->engine.regs,
+ SUN8I_MIXER_BLEND_ROUTE(bld_base),
+ SUN8I_MIXER_BLEND_ROUTE_PIPE_MSK(0) |
+ SUN8I_MIXER_BLEND_ROUTE_PIPE_MSK(1) |
+ SUN8I_MIXER_BLEND_ROUTE_PIPE_MSK(2) |
+ SUN8I_MIXER_BLEND_ROUTE_PIPE_MSK(3),
+ route);
+
+ regmap_update_bits(mixer->engine.regs,
+ SUN8I_MIXER_BLEND_PIPE_CTL(bld_base),
+ SUN8I_MIXER_BLEND_PIPE_CTL_EN(0) |
+ SUN8I_MIXER_BLEND_PIPE_CTL_EN(1) |
+ SUN8I_MIXER_BLEND_PIPE_CTL_EN(2) |
+ SUN8I_MIXER_BLEND_PIPE_CTL_EN(3),
+ pipe_en);
+
regmap_write(engine->regs, SUN8I_MIXER_GLOBAL_DBUFF,
SUN8I_MIXER_GLOBAL_DBUFF_ENABLE);
}
diff --git
[PATCH 0/3] Move blender setup from individual planes to crtc commit in sun4i-drm
From: Ondrej Jirman This series refactors blender setup from individual planes to a common place where it can be performed at once and is easier to reason about. In the process this fixes a few bugs that allowed blender pipes to be disabled while corresponding DRM planes were requested to be enabled. Please take a look. :) Thank you very much, Ondřej Jirman Ondrej Jirman (3): drm/sun4i: Unify sun8i_*_layer structs drm/sun4i: Add more parameters to sunxi_engine commit callback drm/sun4i: Fix layer zpos change/atomic modesetting drivers/gpu/drm/sun4i/sun4i_backend.c | 4 +- drivers/gpu/drm/sun4i/sun4i_crtc.c | 2 +- drivers/gpu/drm/sun4i/sun8i_mixer.c| 82 +++- drivers/gpu/drm/sun4i/sun8i_mixer.h| 20 ++ drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 85 +++-- drivers/gpu/drm/sun4i/sun8i_ui_layer.h | 20 ++ drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 86 +++--- drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 20 ++ drivers/gpu/drm/sun4i/sunxi_engine.h | 13 +++- 9 files changed, 137 insertions(+), 195 deletions(-) -- 2.43.0
[PATCH 1/3] drm/sun4i: Unify sun8i_*_layer structs
From: Ondrej Jirman
These structs are identical, use a single struct to represent private
data for the DRM plane. This is a preparation for configuring layer
routing from the CRTC (mixer) instead of current approach of setting
up routing from individual layer's atomic_update callback.
Signed-off-by: Ondrej Jirman
---
drivers/gpu/drm/sun4i/sun8i_mixer.c| 4 ++--
drivers/gpu/drm/sun4i/sun8i_mixer.h| 14 ++
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 14 +++---
drivers/gpu/drm/sun4i/sun8i_ui_layer.h | 20
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 14 +++---
drivers/gpu/drm/sun4i/sun8i_vi_layer.h | 20
6 files changed, 38 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 01382860aaee..1e681314e379 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -271,7 +271,7 @@ static struct drm_plane **sun8i_layers_init(struct
drm_device *drm,
return ERR_PTR(-ENOMEM);
for (i = 0; i < mixer->cfg->vi_num; i++) {
- struct sun8i_vi_layer *layer;
+ struct sun8i_layer *layer;
layer = sun8i_vi_layer_init_one(drm, mixer, i);
if (IS_ERR(layer)) {
@@ -284,7 +284,7 @@ static struct drm_plane **sun8i_layers_init(struct
drm_device *drm,
}
for (i = 0; i < mixer->cfg->ui_num; i++) {
- struct sun8i_ui_layer *layer;
+ struct sun8i_layer *layer;
layer = sun8i_ui_layer_init_one(drm, mixer, i);
if (IS_ERR(layer)) {
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h
b/drivers/gpu/drm/sun4i/sun8i_mixer.h
index 85c94884fb9a..5a610ee30301 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include "sunxi_engine.h"
@@ -185,6 +186,19 @@ struct sun8i_mixer {
struct clk *mod_clk;
};
+struct sun8i_layer {
+ struct drm_planeplane;
+ struct sun8i_mixer *mixer;
+ int channel;
+ int overlay;
+};
+
+static inline struct sun8i_layer *
+plane_to_sun8i_layer(struct drm_plane *plane)
+{
+ return container_of(plane, struct sun8i_layer, plane);
+}
+
static inline struct sun8i_mixer *
engine_to_sun8i_mixer(struct sunxi_engine *engine)
{
diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
index ca75ca0835a6..248fbb606ede 100644
--- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
@@ -232,7 +232,7 @@ static int sun8i_ui_layer_atomic_check(struct drm_plane
*plane,
{
struct drm_plane_state *new_plane_state =
drm_atomic_get_new_plane_state(state,
plane);
- struct sun8i_ui_layer *layer = plane_to_sun8i_ui_layer(plane);
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
struct drm_crtc *crtc = new_plane_state->crtc;
struct drm_crtc_state *crtc_state;
int min_scale, max_scale;
@@ -264,7 +264,7 @@ static void sun8i_ui_layer_atomic_disable(struct drm_plane
*plane,
{
struct drm_plane_state *old_state =
drm_atomic_get_old_plane_state(state,
plane);
- struct sun8i_ui_layer *layer = plane_to_sun8i_ui_layer(plane);
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
unsigned int old_zpos = old_state->normalized_zpos;
struct sun8i_mixer *mixer = layer->mixer;
@@ -279,7 +279,7 @@ static void sun8i_ui_layer_atomic_update(struct drm_plane
*plane,
plane);
struct drm_plane_state *new_state =
drm_atomic_get_new_plane_state(state,
plane);
- struct sun8i_ui_layer *layer = plane_to_sun8i_ui_layer(plane);
+ struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
unsigned int zpos = new_state->normalized_zpos;
unsigned int old_zpos = old_state->normalized_zpos;
struct sun8i_mixer *mixer = layer->mixer;
@@ -345,13 +345,13 @@ static const uint64_t sun8i_layer_modifiers[] = {
DRM_FORMAT_MOD_INVALID
};
-struct sun8i_ui_layer *sun8i_ui_layer_init_one(struct drm_device *drm,
- struct sun8i_mixer *mixer,
- int index)
+struct sun8i_layer *sun8i_ui_layer_init_one(struct drm_device *drm,
+ struct sun8i_mixer *mixer,
+ int index)
{
enum drm_plane_type type = DRM_PLANE_TYPE_OVERLAY;
int channel
[PATCH 2/3] drm/sun4i: Add more parameters to sunxi_engine commit callback
From: Ondrej Jirman
These will be needed later on when we move layer configuration to
crtc update.
Signed-off-by: Ondrej Jirman
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 4 +++-
drivers/gpu/drm/sun4i/sun4i_crtc.c| 2 +-
drivers/gpu/drm/sun4i/sun8i_mixer.c | 5 -
drivers/gpu/drm/sun4i/sunxi_engine.h | 13 ++---
4 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 335fd0edb904..e89eb96d3131 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -69,7 +69,9 @@ static void sun4i_backend_disable_color_correction(struct
sunxi_engine *engine)
SUN4I_BACKEND_OCCTL_ENABLE, 0);
}
-static void sun4i_backend_commit(struct sunxi_engine *engine)
+static void sun4i_backend_commit(struct sunxi_engine *engine,
+struct drm_crtc *crtc,
+struct drm_atomic_state *state)
{
DRM_DEBUG_DRIVER("Committing changes\n");
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
b/drivers/gpu/drm/sun4i/sun4i_crtc.c
index c06d7cd45388..18e74047b0f5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
@@ -91,7 +91,7 @@ static void sun4i_crtc_atomic_flush(struct drm_crtc *crtc,
DRM_DEBUG_DRIVER("Committing plane changes\n");
- sunxi_engine_commit(scrtc->engine);
+ sunxi_engine_commit(scrtc->engine, crtc, state);
if (event) {
crtc->state->event = NULL;
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 1e681314e379..bdeb9b80e038 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
#include
#include
@@ -249,7 +250,9 @@ int sun8i_mixer_drm_format_to_hw(u32 format, u32 *hw_format)
return -EINVAL;
}
-static void sun8i_mixer_commit(struct sunxi_engine *engine)
+static void sun8i_mixer_commit(struct sunxi_engine *engine,
+ struct drm_crtc *crtc,
+ struct drm_atomic_state *state)
{
DRM_DEBUG_DRIVER("Committing changes\n");
diff --git a/drivers/gpu/drm/sun4i/sunxi_engine.h
b/drivers/gpu/drm/sun4i/sunxi_engine.h
index ec8cf9b2bda4..ec0c4932f15c 100644
--- a/drivers/gpu/drm/sun4i/sunxi_engine.h
+++ b/drivers/gpu/drm/sun4i/sunxi_engine.h
@@ -7,6 +7,7 @@
#define _SUNXI_ENGINE_H_
struct drm_plane;
+struct drm_crtc;
struct drm_device;
struct drm_crtc_state;
struct drm_display_mode;
@@ -59,7 +60,9 @@ struct sunxi_engine_ops {
*
* This function is optional.
*/
- void (*commit)(struct sunxi_engine *engine);
+ void (*commit)(struct sunxi_engine *engine,
+ struct drm_crtc *crtc,
+ struct drm_atomic_state *state);
/**
* @layers_init:
@@ -144,12 +147,16 @@ struct sunxi_engine {
/**
* sunxi_engine_commit() - commit all changes of the engine
* @engine:pointer to the engine
+ * @crtc: pointer to crtc the engine is associated with
+ * @state: atomic state
*/
static inline void
-sunxi_engine_commit(struct sunxi_engine *engine)
+sunxi_engine_commit(struct sunxi_engine *engine,
+ struct drm_crtc *crtc,
+ struct drm_atomic_state *state)
{
if (engine->ops && engine->ops->commit)
- engine->ops->commit(engine);
+ engine->ops->commit(engine, crtc, state);
}
/**
--
2.43.0
[PATCH 3/3] drm/vc4: vec: Add the margin properties to the connector
All the handling for the properties was present, but they were never attached to the connector to allow userspace to change them. Add them to the connector. Signed-off-by: Dave Stevenson --- drivers/gpu/drm/vc4/vc4_vec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c index f9e134dd1e3b..0aed18920d18 100644 --- a/drivers/gpu/drm/vc4/vc4_vec.c +++ b/drivers/gpu/drm/vc4/vc4_vec.c @@ -528,6 +528,8 @@ static int vc4_vec_connector_init(struct drm_device *dev, struct vc4_vec *vec) drm_object_attach_property(>base, prop, VC4_VEC_TV_MODE_NTSC); + drm_connector_attach_tv_margin_properties(connector); + drm_connector_attach_encoder(connector, >encoder.base); return 0; -- 2.25.1
[PATCH 2/3] drm/vc4: Add monochrome mode to the VEC.
The VEC supports not producing colour bursts for monochrome output.
It also has an option for disabling the chroma input to remove
chroma from the signal.
Now that there is a DRM_MODE_TV_MODE_MONOCHROME defined, plumb
this in.
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_vec.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
index 268f18b10ee0..f9e134dd1e3b 100644
--- a/drivers/gpu/drm/vc4/vc4_vec.c
+++ b/drivers/gpu/drm/vc4/vc4_vec.c
@@ -234,6 +234,7 @@ enum vc4_vec_tv_mode_id {
VC4_VEC_TV_MODE_PAL_60,
VC4_VEC_TV_MODE_PAL_N,
VC4_VEC_TV_MODE_SECAM,
+ VC4_VEC_TV_MODE_MONOCHROME,
};
struct vc4_vec_tv_mode {
@@ -324,6 +325,22 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
.config1 = VEC_CONFIG1_C_CVBS_CVBS,
.custom_freq = 0x29c71c72,
},
+ {
+ /* 50Hz mono */
+ .mode = DRM_MODE_TV_MODE_MONOCHROME,
+ .expected_htotal = 864,
+ .config0 = VEC_CONFIG0_PAL_BDGHI_STD | VEC_CONFIG0_BURDIS |
+ VEC_CONFIG0_CHRDIS,
+ .config1 = VEC_CONFIG1_C_CVBS_CVBS,
+ },
+ {
+ /* 60Hz mono */
+ .mode = DRM_MODE_TV_MODE_MONOCHROME,
+ .expected_htotal = 858,
+ .config0 = VEC_CONFIG0_PAL_M_STD | VEC_CONFIG0_BURDIS |
+ VEC_CONFIG0_CHRDIS,
+ .config1 = VEC_CONFIG1_C_CVBS_CVBS,
+ },
};
static inline const struct vc4_vec_tv_mode *
@@ -351,6 +368,7 @@ static const struct drm_prop_enum_list
legacy_tv_mode_names[] = {
{ VC4_VEC_TV_MODE_PAL_M, "PAL-M", },
{ VC4_VEC_TV_MODE_PAL_N, "PAL-N", },
{ VC4_VEC_TV_MODE_SECAM, "SECAM", },
+ { VC4_VEC_TV_MODE_MONOCHROME, "Mono", },
};
static enum drm_connector_status
@@ -406,6 +424,10 @@ vc4_vec_connector_set_property(struct drm_connector
*connector,
state->tv.mode = DRM_MODE_TV_MODE_SECAM;
break;
+ case VC4_VEC_TV_MODE_MONOCHROME:
+ state->tv.mode = DRM_MODE_TV_MODE_MONOCHROME;
+ break;
+
default:
return -EINVAL;
}
@@ -453,6 +475,9 @@ vc4_vec_connector_get_property(struct drm_connector
*connector,
*val = VC4_VEC_TV_MODE_SECAM;
break;
+ case DRM_MODE_TV_MODE_MONOCHROME:
+ return VC4_VEC_TV_MODE_MONOCHROME;
+
default:
return -EINVAL;
}
@@ -754,7 +779,8 @@ static int vc4_vec_bind(struct device *dev, struct device
*master, void *data)
BIT(DRM_MODE_TV_MODE_PAL) |
BIT(DRM_MODE_TV_MODE_PAL_M) |
BIT(DRM_MODE_TV_MODE_PAL_N) |
- BIT(DRM_MODE_TV_MODE_SECAM));
+ BIT(DRM_MODE_TV_MODE_SECAM) |
+ BIT(DRM_MODE_TV_MODE_MONOCHROME));
if (ret)
return ret;
--
2.25.1
[PATCH 1/3] drm: Add DRM_MODE_TV_MODE_MONOCHROME
From: Nick Hollinghurst
Add this as a value for enum_drm_connector_tv_mode, represented
by the string "Mono", to generate video with no colour encoding
or bursts. Define it to have no pedestal (since only NTSC-M calls
for a pedestal).
Change default mode creation to acommodate the new tv_mode value
which comprises both 525-line and 625-line formats.
Signed-off-by: Nick Hollinghurst
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/drm_connector.c| 7 +++
drivers/gpu/drm/drm_modes.c| 5 -
drivers/gpu/drm/drm_probe_helper.c | 5 +++--
include/drm/drm_connector.h| 7 +++
4 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b0516505f7ae..fe05d27f3404 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1005,6 +1005,7 @@ static const struct drm_prop_enum_list
drm_tv_mode_enum_list[] = {
{ DRM_MODE_TV_MODE_PAL_M, "PAL-M" },
{ DRM_MODE_TV_MODE_PAL_N, "PAL-N" },
{ DRM_MODE_TV_MODE_SECAM, "SECAM" },
+ { DRM_MODE_TV_MODE_MONOCHROME, "Mono" },
};
DRM_ENUM_NAME_FN(drm_get_tv_mode_name, drm_tv_mode_enum_list)
@@ -1697,6 +1698,12 @@
EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property);
* TV Mode is CCIR System B (aka 625-lines) together with
* the SECAM Color Encoding.
*
+ * Mono:
+ *
+ * Use timings appropriate to the DRM mode, including
+ * equalizing pulses for a 525-line or 625-line mode,
+ * with no pedestal or color encoding.
+ *
* Drivers can set up this property by calling
* drm_mode_create_tv_properties().
*/
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c4f88c3a93b7..d274e7b00b79 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -530,7 +530,8 @@ static int fill_analog_mode(struct drm_device *dev,
* @interlace: whether to compute an interlaced mode
*
* This function creates a struct drm_display_mode instance suited for
- * an analog TV output, for one of the usual analog TV mode.
+ * an analog TV output, for one of the usual analog TV modes. Where
+ * this is DRM_MODE_TV_MODE_MONOCHROME, a 625-line mode will be created.
*
* Note that @hdisplay is larger than the usual constraints for the PAL
* and NTSC timings, and we'll choose to ignore most timings constraints
@@ -568,6 +569,8 @@ struct drm_display_mode *drm_analog_tv_mode(struct
drm_device *dev,
case DRM_MODE_TV_MODE_PAL_N:
fallthrough;
case DRM_MODE_TV_MODE_SECAM:
+ fallthrough;
+ case DRM_MODE_TV_MODE_MONOCHROME:
analog = DRM_MODE_ANALOG_PAL;
break;
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index d1e1ade66f81..9254dc2af873 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -1211,8 +1211,9 @@ int drm_connector_helper_tv_get_modes(struct
drm_connector *connector)
for (i = 0; i < tv_mode_property->num_values; i++)
supported_tv_modes |= BIT(tv_mode_property->values[i]);
- if ((supported_tv_modes & ntsc_modes) &&
- (supported_tv_modes & pal_modes)) {
+ if (((supported_tv_modes & ntsc_modes) &&
+(supported_tv_modes & pal_modes)) ||
+ (supported_tv_modes & BIT(DRM_MODE_TV_MODE_MONOCHROME))) {
uint64_t default_mode;
if (drm_object_property_get_default_value(>base,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fe88d7fc6b8f..90fd0ea0ca09 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -200,6 +200,13 @@ enum drm_connector_tv_mode {
*/
DRM_MODE_TV_MODE_SECAM,
+ /**
+* @DRM_MODE_TV_MODE_MONOCHROME: Use timings appropriate to
+* the DRM mode, including equalizing pulses for a 525-line
+* or 625-line mode, with no pedestal or color encoding.
+*/
+ DRM_MODE_TV_MODE_MONOCHROME,
+
/**
* @DRM_MODE_TV_MODE_MAX: Number of analog TV output modes.
*
--
2.25.1
[PATCH 0/3] vc4 VEC (analogue video) updates - margins and monochrome
Hi All A couple of patches to vc4, including adding a new "TV mode" enum for monochrome output (yes we have some users who wish for monochrome). Adding mono has raised a query here as to whether the the TV_MODE is meant to describe the timing, or just the colour encoding. The description for NTSC references "CCIR System M (aka 525-lines)", and PAL references "CCIR System B" which is the 625 line standard. PAL-60 is absent from the enum, but support has been added to vc4 by selecting DRM_MODE_TV_MODE_PAL but with the NTSC (CCIR System M) timings. Is that the correct implementation? In which case the description for PAL should drop the CCIR System B reference as selecting the "TV mode" doesn't dictate the timing. Monochrome is in the same boat as it can adopt either 525 or 625 line timing, or indeed anything else. Pi5 can support System A 405-line and the French 819-line mono modes as well. If "TV mode" does dictate the timing as well as the colour encoding, then we need to add PAL-60, and 2 modes for mono (extending to 4 for 405 and 819 line modes later). If not, we ought to update the description. Thoughts? Thanks Dave Dave Stevenson (2): drm/vc4: Add monochrome mode to the VEC. drm/vc4: vec: Add the margin properties to the connector Nick Hollinghurst (1): drm: Add DRM_MODE_TV_MODE_MONOCHROME drivers/gpu/drm/drm_connector.c| 7 +++ drivers/gpu/drm/drm_modes.c| 5 - drivers/gpu/drm/drm_probe_helper.c | 5 +++-- drivers/gpu/drm/vc4/vc4_vec.c | 30 +- include/drm/drm_connector.h| 7 +++ 5 files changed, 50 insertions(+), 4 deletions(-) -- 2.25.1
[PATCH v3] drm/i915/guc: Simplify/extend platform check for Wa_14018913170
From: John Harrison
The above w/a is required for every platform that the i915 driver
supports. It is fixed on the latest platforms but they are only
supported by Xe instead of i915. So just remove the platform check
completely and keep the code simple.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 2b450c43bbd7f..a3662edb42032 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -321,8 +321,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
/* Wa_14018913170 */
if (GUC_FIRMWARE_VER(guc) >= MAKE_GUC_VER(70, 7, 0)) {
- if (IS_DG2(gt->i915) || IS_METEORLAKE(gt->i915) ||
IS_PONTEVECCHIO(gt->i915))
- flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
+ flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
}
return flags;
--
2.43.0
Re: [PATCH] drm/amd: Only allow one entity to control ABM
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 v3 2/4] dt-bindings: display/msm: Document MDSS on X1E80100
On Fri, 16 Feb 2024 19:01:06 +0200, Abel Vesa wrote: > Document the MDSS hardware found on the Qualcomm X1E80100 platform. > > Reviewed-by: Krzysztof Kozlowski > Signed-off-by: Abel Vesa > --- > .../bindings/display/msm/qcom,x1e80100-mdss.yaml | 253 > + > 1 file changed, 253 insertions(+) > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.example.dts:24:18: fatal error: dt-bindings/clock/qcom,x1e80100-dispcc.h: No such file or directory 24 | #include | ^~ compilation terminated. make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.example.dtb] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1428: dt_binding_check] Error 2 make: *** [Makefile:240: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240216-x1e80100-display-v3-2-28b1c33ac...@linaro.org The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH] drm/nouveau/mmu/r535: uninitialized variable in r535_bar_new_()
On 2/13/24 19:09, Dan Carpenter wrote:
If gf100_bar_new_() fails then "bar" is not initialized.
Fixes: 5bf0257136a2 ("drm/nouveau/mmu/r535: initial support")
Signed-off-by: Dan Carpenter
Applied to drm-misc-fixes, thanks!
---
It looks like this was intended to handle a failure from the "rm" func
but "rm" can't actually fail so it's easier to write the error handling
for the code as-is.
drivers/gpu/drm/nouveau/nvkm/subdev/bar/r535.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/r535.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/r535.c
index 4135690326f4..3a30bea30e36 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/r535.c
@@ -168,12 +168,11 @@ r535_bar_new_(const struct nvkm_bar_func *hw, struct
nvkm_device *device,
rm->flush = r535_bar_flush;
ret = gf100_bar_new_(rm, device, type, inst, );
- *pbar = bar;
if (ret) {
- if (!bar)
- kfree(rm);
+ kfree(rm);
return ret;
}
+ *pbar = bar;
bar->flushBAR2PhysMode = ioremap(device->func->resource_addr(device, 3), PAGE_SIZE);
if (!bar->flushBAR2PhysMode)
Re: [PATCH] nouveau: fix function cast warnings
On 2/13/24 10:57, Arnd Bergmann wrote:
From: Arnd Bergmann
clang-16 warns about casting between incompatible function types:
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c:161:10: error: cast from
'void (*)(const struct firmware *)' to 'void (*)(void *)' converts to
incompatible function type [-Werror,-Wcast-function-type-strict]
161 | .fini = (void(*)(void *))release_firmware,
This one was done to use the generic shadow_fw_release() function as a
callback for struct nvbios_source. Change it to use the same prototype
as the other five instances, with a trivial helper function that actually
calls release_firmware.
Fixes: 70c0f263cc2e ("drm/nouveau/bios: pull in basic vbios subdev, more to come
later")
Signed-off-by: Arnd Bergmann
Applied to drm-misc-fixes, thanks!
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
index 19188683c8fc..8c2bf1c16f2a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
@@ -154,11 +154,17 @@ shadow_fw_init(struct nvkm_bios *bios, const char *name)
return (void *)fw;
}
+static void
+shadow_fw_release(void *fw)
+{
+ release_firmware(fw);
+}
+
static const struct nvbios_source
shadow_fw = {
.name = "firmware",
.init = shadow_fw_init,
- .fini = (void(*)(void *))release_firmware,
+ .fini = shadow_fw_release,
.read = shadow_fw_read,
.rw = false,
};
Re: [PATCH v2 1/6] tracing, dma-buf: add a trace_dma_fence_sync_to event
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 0/1] Always record job cycle and timestamp information
On 16/02/2024 16:57, Daniel Vetter wrote: On Wed, Feb 14, 2024 at 01:52:05PM +, Steven Price wrote: Hi Adrián, On 14/02/2024 12:14, Adrián Larumbe wrote: A driver user expressed interest in being able to access engine usage stats through fdinfo when debugfs is not built into their kernel. In the current implementation, this wasn't possible, because it was assumed even for inflight jobs enabling the cycle counter and timestamp registers would incur in additional power consumption, so both were kept disabled until toggled through debugfs. A second read of the TRM made me think otherwise, but this is something that would be best clarified by someone from ARM's side. I'm afraid I can't give a definitive answer. This will probably vary depending on implementation. The command register enables/disables "propagation" of the cycle/timestamp values. This propagation will cost some power (gates are getting toggled) but whether that power is completely in the noise of the GPU as a whole I can't say. The out-of-tree kbase driver only enables the counters for jobs explicitly marked (BASE_JD_REQ_PERMON) or due to an explicit connection from a profiler. I'd be happier moving the debugfs file to sysfs rather than assuming that the power consumption is small enough for all platforms. Ideally we'd have some sort of kernel interface for a profiler to inform the kernel what it is interested in, but I can't immediately see how to make that useful across different drivers. kbase's profiling support is great with our profiling tools, but there's a very strong connection between the two. Yeah I'm not sure whether a magic (worse probably per-driver massively different) file in sysfs is needed to enable gpu perf monitoring stats in fdinfo. I get that we do have a bit a gap because the linux perf pmu stuff is global, and you want per-process, and there's kinda no per-process support for perf stats for devices. But that's probably the direction we want to go, not so much fdinfo. At least for hardware performance counters and things like that. Iirc the i915 pmu support had some integration for per-process support, you might want to chat with Tvrtko for kernel side and Lionel for more userspace side. At least if I'm not making a complete mess and my memory is vaguely related to reality. Adding them both. Yeah there are two separate things, i915 PMU and i915 Perf/OA. If my memory serves me right I indeed did have a per-process support for i915 PMU implemented as an RFC (or at least a branch somewhere) some years back. IIRC it only exposed the per engine GPU utilisation and did not find it very useful versus the complexity. (I think it at least required maintaining a map of drm clients per task.) Our more useful profiling is using a custom Perf/OA interface (Observation Architecture) which is possibly similar to kbase mentioned above. Why it is a custom interface is explained in a large comment on top of i915_perf.c. Not sure if all of them still hold but on the overall perf does not sound like the right fit for detailed GPU profiling. Also PMU drivers are very challenging to get the implementation right, since locking model and atomicity requirements are quite demanding. From my point of view, at least it is my initial thinking, if custom per driver solutions are strongly not desired, it could be interesting to look into whether there is enough commonality, in at least concepts, to see if a new DRM level common but extensible API would be doable. Even then it may be tricky to "extract" enough common code to justify it. Regards, Tvrtko Cheers, Sima Steve Adrián Larumbe (1): drm/panfrost: Always record job cycle and timestamp information drivers/gpu/drm/panfrost/Makefile | 2 -- drivers/gpu/drm/panfrost/panfrost_debugfs.c | 21 -- drivers/gpu/drm/panfrost/panfrost_debugfs.h | 14 drivers/gpu/drm/panfrost/panfrost_device.h | 1 - drivers/gpu/drm/panfrost/panfrost_drv.c | 5 - drivers/gpu/drm/panfrost/panfrost_job.c | 24 - drivers/gpu/drm/panfrost/panfrost_job.h | 1 - 7 files changed, 9 insertions(+), 59 deletions(-) delete mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.c delete mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.h base-commit: 6b1f93ea345947c94bf3a7a6e668a2acfd310918 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 17/27] sparc32: Drop run-time patching of ASI instructions
On 2023-12-19 23:03, Sam Ravnborg via B4 Relay wrote: > From: Sam Ravnborg > > With only LEON supported there is no need to run-time patch > the instructions to match ASI. > > Move a few functions back to C with inline asm, now that > run-time patching is not needed. > > Deleted a few functions that turns out not to be used rather > than re-implement them in C. ... > diff --git a/arch/sparc/include/asm/sections.h > b/arch/sparc/include/asm/sections.h > index 08f833453ab3..e9d28148850b 100644 > --- a/arch/sparc/include/asm/sections.h > +++ b/arch/sparc/include/asm/sections.h > @@ -8,7 +8,4 @@ > /* sparc entry point */ > extern char _start[]; > > -extern char __leon_1insn_patch[]; > -extern char __leon_1insn_patch_end[]; > - > #endif > diff --git a/arch/sparc/include/asm/winmacro.h > b/arch/sparc/include/asm/winmacro.h > index b6e911f5d93c..c496b04cdfaf 100644 > --- a/arch/sparc/include/asm/winmacro.h > +++ b/arch/sparc/include/asm/winmacro.h > @@ -108,18 +108,11 @@ > 661: rd %tbr, %idreg; \ > srl %idreg, 10, %idreg; \ > and %idreg, 0xc, %idreg;\ These three lines, including the label, should also be removed as they are not for LEON. Additionally, I think it would be best to split out removing the cpuid instruction fixups to one patch and the MMU ASI instruction fixups to another patch. > - .section.cpuid_patch, "ax"; \ > - /* Instruction location. */ \ > - .word 661b; \ > - /* SUN4D implementation. */ \ > - lda [%g0] ASI_M_VIKING_TMP1, %idreg; \ > - sll %idreg, 2, %idreg; \ > - nop;\ > - /* LEON implementation. */ \ > + \ > rd %asr17, %idreg; \ > srl %idreg, 0x1c, %idreg; \ > sll %idreg, 0x02, %idreg; \ > - .previous; \ > + \ > sethi%hi(current_set), %dest_reg; \ > or %dest_reg, %lo(current_set), %dest_reg;\ > ld [%idreg + %dest_reg], %dest_reg; > diff --git a/arch/sparc/kernel/entry.S b/arch/sparc/kernel/entry.S > index 0f2417ee3f95..9cf8f87e8c42 100644 > --- a/arch/sparc/kernel/entry.S > +++ b/arch/sparc/kernel/entry.S The hard_smp_processor_id function also needs to be reduced to just the LEON code. With the patching removed, SMP otherwise breaks with CPUs other than CPU 0 getting stuck. Thanks, Andreas
Re: [PATCH v5 10/13] drm/mediatek: Support CRC in display driver
On Fri, Feb 16, 2024 at 06:04:43PM +0100, Daniel Vetter wrote:
> On Thu, Feb 15, 2024 at 06:11:16PM +0800, Hsiao Chien Sung wrote:
> > Register CRC related function pointers to support
> > CRC retrieval.
> >
> > Signed-off-by: Hsiao Chien Sung
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 239
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 39
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 +
> > 3 files changed, 281 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 14cf75fa217f9..6cb1ed419dee7 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -68,6 +68,9 @@ struct mtk_drm_crtc {
> > /* lock for display hardware access */
> > struct mutexhw_lock;
> > boolconfig_updating;
> > +
> > + struct mtk_ddp_comp *crc_provider;
> > + unsigned intframes;
> > };
> >
> > struct mtk_crtc_state {
> > @@ -635,6 +638,14 @@ static void mtk_crtc_ddp_irq(void *data)
> > struct drm_crtc *crtc = data;
> > struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > struct mtk_drm_private *priv = crtc->dev->dev_private;
> > + struct mtk_ddp_comp *comp = mtk_crtc->crc_provider;
> > +
> > + /*
> > +* crc providers should make sure the crc is always correct
> > +* by resetting it in .crc_read()
> > +*/
> > + if (crtc->crc.opened)
> > + comp->funcs->crc_read(comp->dev);
> >
> > #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> > if (!priv->data->shadow_register && !mtk_crtc->cmdq_client.chan)
> > @@ -646,6 +657,24 @@ static void mtk_crtc_ddp_irq(void *data)
> > if (!priv->data->shadow_register)
> > mtk_crtc_ddp_config(crtc, NULL);
> > #endif
> > +
> > + /*
> > +* drm_crtc_add_crc_entry() could take more than 50ms to finish
> > +* put it at the end of the isr
> > +*/
>
> Uh this looks really scary, especially since you put this before the call
> to drm_crtc_handle_vblank in the function below, which really shouldn't be
> unecessarily delayed (because that's the one that takes the vblank
> timestamp).
>
> This sounds like the perfect application for a vblank worker though, so
> you please look into drm_vblank_work.h. And if that is not useable due to
> hardware constraint, then please explain in a comment here and in the
> commit message why you cannot use that and have to roll your own. vblank
> work really should be your first choice here, because:
> - it's designed for expensive vblank work
> - it gives you all the flush/cancel_sync functions you need for disabling
> crc again, and in a race-free implementation. Much better to use common
> code than to reinvent synchronization wheels in drivers :-)
>
> > + if (crtc->crc.opened) {
>
> Because this is probably not race-free, so we need something solid here.
Since it's maybe a bit tricky to see how to use drm_vblank_work:
- in your crtc initialization you also need to setup the crc work with
drm_vblank_work_init().
- Your mtk_drm_crtc_set_sourc needs to actually enable the crc by calling
drm_vblank_work_schedule for current vblank + 1, so that it immediately
starts
- your vblank worker itself needs to again re-arm itself with
drm_vblank_work_schedule, again for the very next vblank
- then your set_source also needs to handle the case where you disable the
crc again (source == NULL) by calling drm_vblank_work_cancel_sync
- also you probably need to call drm_vblank_work_flush when shutting down
the crtc, or you might have use-after-free issues on driver unload.
Could probably also just put that in your crtc release function.
No changes to your interrupt handler needed, and also definitely no
digging around in drm_crtc->crc data structure without locking - that's
entirely internal to the common crc code and drivers must never look
into it.
Cheers, Sima
>
>
> > + /*
> > +* skip the first crc because the first frame is configured by
> > +* mtk_crtc_ddp_hw_init() when atomic enable
> > +*/
> > + if (++mtk_crtc->frames > 1) {
> > + drm_crtc_add_crc_entry(crtc, true,
> > + drm_crtc_vblank_count(crtc),
> > +
> > comp->funcs->crc_entry(comp->dev));
> > + }
> > + } else {
> > + mtk_crtc->frames = 0;
> > + }
> > mtk_drm_finish_page_flip(mtk_crtc);
> > }
> >
> > @@ -704,6 +733,40 @@ static void mtk_drm_crtc_update_output(struct drm_crtc
> > *crtc,
> > }
> > }
> >
> > +static int mtk_drm_crtc_set_crc_source(struct drm_crtc *crtc, const char
> > *src)
> > +{
> > + if (src && strcmp(src, "auto") != 0) {
> > + DRM_ERROR("%s(crtc-%d): unknown source '%s'\n",
> > + __func__, drm_crtc_index(crtc),
Re: [PATCH v6 1/5] drm: Stop using `select ACPI_VIDEO` in all drivers
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: [git pull] drm fixes for 6.8-rc5
The pull request you sent on Fri, 16 Feb 2024 17:20:39 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2024-02-16 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/ca6a62f9fe23713ea2b58a256a1ab27b9cc5a05a Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH] char/agp: remove agp_bridge_data::type
On Tue, Feb 13, 2024 at 12:15:11PM +0100, Jiri Slaby (SUSE) wrote:
> agp_bridge_data::type is unused (and I cannot find when was used last).
>
> Therefore, remove it.
>
> Found by https://github.com/jirislaby/clang-struct.
>
> Signed-off-by: Jiri Slaby (SUSE)
> Cc: David Airlie
> Cc: dri-devel@lists.freedesktop.org
Thanks, pushed to drm-misc-next.
-Sima
> ---
> drivers/char/agp/agp.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
> index 5c36ab85f80b..67d7be800a7c 100644
> --- a/drivers/char/agp/agp.h
> +++ b/drivers/char/agp/agp.h
> @@ -138,7 +138,6 @@ struct agp_bridge_data {
> unsigned long gart_bus_addr;
> unsigned long gatt_bus_addr;
> u32 mode;
> - enum chipset_type type;
> unsigned long *key_list;
> atomic_t current_memory_agp;
> atomic_t agp_in_use;
> --
> 2.43.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v5 10/13] drm/mediatek: Support CRC in display driver
On Thu, Feb 15, 2024 at 06:11:16PM +0800, Hsiao Chien Sung wrote:
> Register CRC related function pointers to support
> CRC retrieval.
>
> Signed-off-by: Hsiao Chien Sung
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 239
> drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 39
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 +
> 3 files changed, 281 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 14cf75fa217f9..6cb1ed419dee7 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -68,6 +68,9 @@ struct mtk_drm_crtc {
> /* lock for display hardware access */
> struct mutexhw_lock;
> boolconfig_updating;
> +
> + struct mtk_ddp_comp *crc_provider;
> + unsigned intframes;
> };
>
> struct mtk_crtc_state {
> @@ -635,6 +638,14 @@ static void mtk_crtc_ddp_irq(void *data)
> struct drm_crtc *crtc = data;
> struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> struct mtk_drm_private *priv = crtc->dev->dev_private;
> + struct mtk_ddp_comp *comp = mtk_crtc->crc_provider;
> +
> + /*
> + * crc providers should make sure the crc is always correct
> + * by resetting it in .crc_read()
> + */
> + if (crtc->crc.opened)
> + comp->funcs->crc_read(comp->dev);
>
> #if IS_REACHABLE(CONFIG_MTK_CMDQ)
> if (!priv->data->shadow_register && !mtk_crtc->cmdq_client.chan)
> @@ -646,6 +657,24 @@ static void mtk_crtc_ddp_irq(void *data)
> if (!priv->data->shadow_register)
> mtk_crtc_ddp_config(crtc, NULL);
> #endif
> +
> + /*
> + * drm_crtc_add_crc_entry() could take more than 50ms to finish
> + * put it at the end of the isr
> + */
Uh this looks really scary, especially since you put this before the call
to drm_crtc_handle_vblank in the function below, which really shouldn't be
unecessarily delayed (because that's the one that takes the vblank
timestamp).
This sounds like the perfect application for a vblank worker though, so
you please look into drm_vblank_work.h. And if that is not useable due to
hardware constraint, then please explain in a comment here and in the
commit message why you cannot use that and have to roll your own. vblank
work really should be your first choice here, because:
- it's designed for expensive vblank work
- it gives you all the flush/cancel_sync functions you need for disabling
crc again, and in a race-free implementation. Much better to use common
code than to reinvent synchronization wheels in drivers :-)
> + if (crtc->crc.opened) {
Because this is probably not race-free, so we need something solid here.
Cheers, Sima
> + /*
> + * skip the first crc because the first frame is configured by
> + * mtk_crtc_ddp_hw_init() when atomic enable
> + */
> + if (++mtk_crtc->frames > 1) {
> + drm_crtc_add_crc_entry(crtc, true,
> +drm_crtc_vblank_count(crtc),
> +
> comp->funcs->crc_entry(comp->dev));
> + }
> + } else {
> + mtk_crtc->frames = 0;
> + }
> mtk_drm_finish_page_flip(mtk_crtc);
> }
>
> @@ -704,6 +733,40 @@ static void mtk_drm_crtc_update_output(struct drm_crtc
> *crtc,
> }
> }
>
> +static int mtk_drm_crtc_set_crc_source(struct drm_crtc *crtc, const char
> *src)
> +{
> + if (src && strcmp(src, "auto") != 0) {
> + DRM_ERROR("%s(crtc-%d): unknown source '%s'\n",
> + __func__, drm_crtc_index(crtc), src);
> + return -EINVAL;
> + }
> + return 0;
> +}
> +
> +static int mtk_drm_crtc_verify_crc_source(struct drm_crtc *crtc,
> + const char *src,
> + size_t *cnt)
> +{
> + struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> + struct mtk_ddp_comp *comp = mtk_crtc->crc_provider;
> +
> + if (!comp) {
> + DRM_ERROR("%s(crtc-%d): no crc provider\n",
> + __func__, drm_crtc_index(crtc));
> + return -ENOENT;
> + }
> +
> + if (src && strcmp(src, "auto") != 0) {
> + DRM_ERROR("%s(crtc-%d): unknown source '%s'\n",
> + __func__, drm_crtc_index(crtc), src);
> + return -EINVAL;
> + }
> +
> + *cnt = comp->funcs->crc_cnt(comp->dev);
> +
> + return 0;
> +}
> +
> int mtk_drm_crtc_plane_check(struct drm_crtc *crtc, struct drm_plane *plane,
>struct mtk_plane_state *state)
> {
> @@ -841,6 +904,8 @@ static const struct drm_crtc_funcs mtk_crtc_funcs = {
> .atomic_destroy_state = mtk_drm_crtc_destroy_state,
> .enable_vblank =
[PATCH v3 0/4] drm/msm: Add display support for X1E80100
This patchset adds support for display for X1E80100. The support for embedded DisplayPort on this platform will not be enabled using the connetor type from driver match data, but through some 'is-edp' property via DT. This subsequent work will be part of a separate patchset. Signed-off-by: Abel Vesa --- Changes in v3: - Added Dmitry's R-b tag to the mdss patch - Swapped order of first two patches, as suggested by Rob - Added "additionalProperties: true" to all pattern properties in MDSS schema - Link to v2: https://lore.kernel.org/r/20240214-x1e80100-display-v2-0-cf05ba887...@linaro.org Changes in v2: - Dropped the 4th patch: "drm/msm/dp: Try looking for link-frequencies into the port@0's endpoint first" - Fixed the qcom,x1e80100-mdss schema by including some missing headers in the example - Added TODO comment for reg_bus_bw - Switched to SDMA features mask - Added Krzysztof's R-b tag to mdss schema patch - Added Dmitry's R-b tag to the dpu patch - Link to v1: https://lore.kernel.org/r/20240129-x1e80100-display-v1-0-0d9eb8254...@linaro.org --- Abel Vesa (4): dt-bindings: display/msm: Document the DPU for X1E80100 dt-bindings: display/msm: Document MDSS on X1E80100 drm/msm: mdss: Add X1E80100 support drm/msm/dpu: Add X1E80100 support .../bindings/display/msm/qcom,sm8650-dpu.yaml | 4 +- .../bindings/display/msm/qcom,x1e80100-mdss.yaml | 253 .../drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 449 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 1 + drivers/gpu/drm/msm/msm_mdss.c | 13 + 7 files changed, 722 insertions(+), 1 deletion(-) --- base-commit: 85a96a047f413da4b663919a4ced39a4715c6835 change-id: 20231201-x1e80100-display-a46324400baf Best regards, -- Abel Vesa
[PATCH v3 4/4] drm/msm/dpu: Add X1E80100 support
Add definitions for the display hardware used on the Qualcomm X1E80100
platform.
Co-developed-by: Abhinav Kumar
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
.../drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 449 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 1 +
4 files changed, 453 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h
new file mode 100644
index ..9a9f7092c526
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h
@@ -0,0 +1,449 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2023, Linaro Limited
+ */
+
+#ifndef _DPU_9_2_X1E80100_H
+#define _DPU_9_2_X1E80100_H
+
+static const struct dpu_caps x1e80100_dpu_caps = {
+ .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .max_mixer_blendstages = 0xb,
+ .has_src_split = true,
+ .has_dim_layer = true,
+ .has_idle_pc = true,
+ .has_3d_merge = true,
+ .max_linewidth = 5120,
+ .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+};
+
+static const struct dpu_mdp_cfg x1e80100_mdp = {
+ .name = "top_0",
+ .base = 0, .len = 0x494,
+ .features = BIT(DPU_MDP_PERIPH_0_REMOVED),
+ .clk_ctrls = {
+ [DPU_CLK_CTRL_REG_DMA] = { .reg_off = 0x2bc, .bit_off = 20 },
+ },
+};
+
+/* FIXME: get rid of DPU_CTL_SPLIT_DISPLAY in favour of proper ACTIVE_CTL
support */
+static const struct dpu_ctl_cfg x1e80100_ctl[] = {
+ {
+ .name = "ctl_0", .id = CTL_0,
+ .base = 0x15000, .len = 0x290,
+ .features = CTL_SM8550_MASK | BIT(DPU_CTL_SPLIT_DISPLAY),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 9),
+ }, {
+ .name = "ctl_1", .id = CTL_1,
+ .base = 0x16000, .len = 0x290,
+ .features = CTL_SM8550_MASK | BIT(DPU_CTL_SPLIT_DISPLAY),
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 10),
+ }, {
+ .name = "ctl_2", .id = CTL_2,
+ .base = 0x17000, .len = 0x290,
+ .features = CTL_SM8550_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 11),
+ }, {
+ .name = "ctl_3", .id = CTL_3,
+ .base = 0x18000, .len = 0x290,
+ .features = CTL_SM8550_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 12),
+ }, {
+ .name = "ctl_4", .id = CTL_4,
+ .base = 0x19000, .len = 0x290,
+ .features = CTL_SM8550_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 13),
+ }, {
+ .name = "ctl_5", .id = CTL_5,
+ .base = 0x1a000, .len = 0x290,
+ .features = CTL_SM8550_MASK,
+ .intr_start = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 23),
+ },
+};
+
+static const struct dpu_sspp_cfg x1e80100_sspp[] = {
+ {
+ .name = "sspp_0", .id = SSPP_VIG0,
+ .base = 0x4000, .len = 0x344,
+ .features = VIG_SDM845_MASK_SDMA,
+ .sblk = _vig_sblk_qseed3_3_3,
+ .xin_id = 0,
+ .type = SSPP_TYPE_VIG,
+ }, {
+ .name = "sspp_1", .id = SSPP_VIG1,
+ .base = 0x6000, .len = 0x344,
+ .features = VIG_SDM845_MASK_SDMA,
+ .sblk = _vig_sblk_qseed3_3_3,
+ .xin_id = 4,
+ .type = SSPP_TYPE_VIG,
+ }, {
+ .name = "sspp_2", .id = SSPP_VIG2,
+ .base = 0x8000, .len = 0x344,
+ .features = VIG_SDM845_MASK_SDMA,
+ .sblk = _vig_sblk_qseed3_3_3,
+ .xin_id = 8,
+ .type = SSPP_TYPE_VIG,
+ }, {
+ .name = "sspp_3", .id = SSPP_VIG3,
+ .base = 0xa000, .len = 0x344,
+ .features = VIG_SDM845_MASK_SDMA,
+ .sblk = _vig_sblk_qseed3_3_3,
+ .xin_id = 12,
+ .type = SSPP_TYPE_VIG,
+ }, {
+ .name = "sspp_8", .id = SSPP_DMA0,
+ .base = 0x24000, .len = 0x344,
+ .features = DMA_SDM845_MASK_SDMA,
+ .sblk = _dma_sblk,
+ .xin_id = 1,
+ .type = SSPP_TYPE_DMA,
+ }, {
+ .name = "sspp_9", .id = SSPP_DMA1,
+ .base = 0x26000, .len = 0x344,
+ .features = DMA_SDM845_MASK_SDMA,
+ .sblk = _dma_sblk,
+ .xin_id = 5,
+ .type = SSPP_TYPE_DMA,
+ }, {
+ .name = "sspp_10", .id = SSPP_DMA2,
+ .base = 0x28000, .len = 0x344,
+ .features = DMA_SDM845_MASK_SDMA,
+ .sblk = _dma_sblk,
+ .xin_id = 9,
+
[PATCH v3 3/4] drm/msm: mdss: Add X1E80100 support
Add support for MDSS on X1E80100.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/msm_mdss.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 35423d10aafa..6eda501e2a1a 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -636,6 +636,18 @@ static const struct msm_mdss_data sm8550_data = {
.macrotile_mode = 1,
.reg_bus_bw = 57000,
};
+
+static const struct msm_mdss_data x1e80100_data = {
+ .ubwc_enc_version = UBWC_4_0,
+ .ubwc_dec_version = UBWC_4_3,
+ .ubwc_swizzle = 6,
+ .ubwc_static = 1,
+ /* TODO: highest_bank_bit = 2 for LP_DDR4 */
+ .highest_bank_bit = 3,
+ .macrotile_mode = 1,
+ /* TODO: Add reg_bus_bw with real value */
+};
+
static const struct of_device_id mdss_dt_match[] = {
{ .compatible = "qcom,mdss" },
{ .compatible = "qcom,msm8998-mdss", .data = _data },
@@ -656,6 +668,7 @@ static const struct of_device_id mdss_dt_match[] = {
{ .compatible = "qcom,sm8450-mdss", .data = _data },
{ .compatible = "qcom,sm8550-mdss", .data = _data },
{ .compatible = "qcom,sm8650-mdss", .data = _data},
+ { .compatible = "qcom,x1e80100-mdss", .data = _data},
{}
};
MODULE_DEVICE_TABLE(of, mdss_dt_match);
--
2.34.1
[PATCH v3 1/4] dt-bindings: display/msm: Document the DPU for X1E80100
Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as they are similar. Signed-off-by: Abel Vesa --- Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml index a01d15a03317..c4087cc5abbd 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml @@ -13,7 +13,9 @@ $ref: /schemas/display/msm/dpu-common.yaml# properties: compatible: -const: qcom,sm8650-dpu +enum: + - qcom,sm8650-dpu + - qcom,x1e80100-dpu reg: items: -- 2.34.1
[PATCH v3 2/4] dt-bindings: display/msm: Document MDSS on X1E80100
Document the MDSS hardware found on the Qualcomm X1E80100 platform.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Abel Vesa
---
.../bindings/display/msm/qcom,x1e80100-mdss.yaml | 253 +
1 file changed, 253 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml
b/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml
new file mode 100644
index ..09a034b9ee7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml
@@ -0,0 +1,253 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/qcom,x1e80100-mdss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm X1E80100 Display MDSS
+
+maintainers:
+ - Abel Vesa
+
+description:
+ X1E80100 MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks
like
+ DPU display controller, DP interfaces, etc.
+
+$ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+ compatible:
+const: qcom,x1e80100-mdss
+
+ clocks:
+items:
+ - description: Display AHB
+ - description: Display hf AXI
+ - description: Display core
+
+ iommus:
+maxItems: 1
+
+ interconnects:
+maxItems: 3
+
+ interconnect-names:
+maxItems: 3
+
+patternProperties:
+ "^display-controller@[0-9a-f]+$":
+type: object
+additionalProperties: true
+properties:
+ compatible:
+const: qcom,x1e80100-dpu
+
+ "^displayport-controller@[0-9a-f]+$":
+type: object
+additionalProperties: true
+properties:
+ compatible:
+const: qcom,x1e80100-dp
+
+ "^phy@[0-9a-f]+$":
+type: object
+additionalProperties: true
+properties:
+ compatible:
+const: qcom,x1e80100-dp-phy
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+display-subsystem@ae0 {
+compatible = "qcom,x1e80100-mdss";
+reg = <0x0ae0 0x1000>;
+reg-names = "mdss";
+
+interconnects = <_noc MASTER_MDP 0 _noc SLAVE_LLCC 0>,
+<_virt MASTER_LLCC 0 _virt SLAVE_EBI1 0>,
+<_noc MASTER_APPSS_PROC 0 _noc
SLAVE_DISPLAY_CFG 0>;
+interconnect-names = "mdp0-mem", "mdp1-mem", "cpu-cfg";
+
+resets = <_core_bcr>;
+
+power-domains = <_gdsc>;
+
+clocks = < DISP_CC_MDSS_AHB_CLK>,
+ < GCC_DISP_HF_AXI_CLK>,
+ < DISP_CC_MDSS_MDP_CLK>;
+clock-names = "bus", "nrt_bus", "core";
+
+interrupts = ;
+interrupt-controller;
+#interrupt-cells = <1>;
+
+iommus = <_smmu 0x1c00 0x2>;
+
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;
+
+display-controller@ae01000 {
+compatible = "qcom,x1e80100-dpu";
+reg = <0x0ae01000 0x8f000>,
+ <0x0aeb 0x2008>;
+reg-names = "mdp", "vbif";
+
+clocks = <_axi_clk>,
+ <_ahb_clk>,
+ <_mdp_lut_clk>,
+ <_mdp_clk>,
+ <_mdp_vsync_clk>;
+clock-names = "nrt_bus",
+ "iface",
+ "lut",
+ "core",
+ "vsync";
+
+assigned-clocks = <_mdp_vsync_clk>;
+assigned-clock-rates = <1920>;
+
+operating-points-v2 = <_opp_table>;
+power-domains = < RPMHPD_MMCX>;
+
+interrupt-parent = <>;
+interrupts = <0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+dpu_intf1_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+
+port@1 {
+reg = <1>;
+dpu_intf2_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+
+mdp_opp_table: opp-table {
+compatible = "operating-points-v2";
+
+opp-2 {
+opp-hz = /bits/ 64 <2>;
+required-opps = <_opp_low_svs>;
+};
+
+opp-32500 {
+opp-hz = /bits/ 64 <32500>;
+required-opps = <_opp_svs>;
+};
+
+opp-37500 {
+opp-hz = /bits/ 64 <37500>;
+required-opps = <_opp_svs_l1>;
+};
+
+opp-51400 {
+opp-hz = /bits/ 64 <51400>;
+required-opps = <_opp_nom>;
+};
+};
+};
+
Re: [PATCH 1/3] drm/radeon: Use RMW accessors for changing LNKCTL2
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 0/1] Always record job cycle and timestamp information
On Wed, Feb 14, 2024 at 01:52:05PM +, Steven Price wrote: > Hi Adrián, > > On 14/02/2024 12:14, Adrián Larumbe wrote: > > A driver user expressed interest in being able to access engine usage stats > > through fdinfo when debugfs is not built into their kernel. In the current > > implementation, this wasn't possible, because it was assumed even for > > inflight jobs enabling the cycle counter and timestamp registers would > > incur in additional power consumption, so both were kept disabled until > > toggled through debugfs. > > > > A second read of the TRM made me think otherwise, but this is something > > that would be best clarified by someone from ARM's side. > > I'm afraid I can't give a definitive answer. This will probably vary > depending on implementation. The command register enables/disables > "propagation" of the cycle/timestamp values. This propagation will cost > some power (gates are getting toggled) but whether that power is > completely in the noise of the GPU as a whole I can't say. > > The out-of-tree kbase driver only enables the counters for jobs > explicitly marked (BASE_JD_REQ_PERMON) or due to an explicit connection > from a profiler. > > I'd be happier moving the debugfs file to sysfs rather than assuming > that the power consumption is small enough for all platforms. > > Ideally we'd have some sort of kernel interface for a profiler to inform > the kernel what it is interested in, but I can't immediately see how to > make that useful across different drivers. kbase's profiling support is > great with our profiling tools, but there's a very strong connection > between the two. Yeah I'm not sure whether a magic (worse probably per-driver massively different) file in sysfs is needed to enable gpu perf monitoring stats in fdinfo. I get that we do have a bit a gap because the linux perf pmu stuff is global, and you want per-process, and there's kinda no per-process support for perf stats for devices. But that's probably the direction we want to go, not so much fdinfo. At least for hardware performance counters and things like that. Iirc the i915 pmu support had some integration for per-process support, you might want to chat with Tvrtko for kernel side and Lionel for more userspace side. At least if I'm not making a complete mess and my memory is vaguely related to reality. Adding them both. Cheers, Sima > > Steve > > > Adrián Larumbe (1): > > drm/panfrost: Always record job cycle and timestamp information > > > > drivers/gpu/drm/panfrost/Makefile | 2 -- > > drivers/gpu/drm/panfrost/panfrost_debugfs.c | 21 -- > > drivers/gpu/drm/panfrost/panfrost_debugfs.h | 14 > > drivers/gpu/drm/panfrost/panfrost_device.h | 1 - > > drivers/gpu/drm/panfrost/panfrost_drv.c | 5 - > > drivers/gpu/drm/panfrost/panfrost_job.c | 24 - > > drivers/gpu/drm/panfrost/panfrost_job.h | 1 - > > 7 files changed, 9 insertions(+), 59 deletions(-) > > delete mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.c > > delete mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.h > > > > > > base-commit: 6b1f93ea345947c94bf3a7a6e668a2acfd310918 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
RE: [PATCH] drm: xlnx: dp: Reset DisplayPort IP
[AMD Official Use Only - General] Hi Rohit, Thanks for the patch. > -Original Message- > From: dri-devel On Behalf Of > Rohit Visavalia > Sent: Friday, February 16, 2024 1:41 PM > To: gre...@linuxfoundation.org; laurent.pinch...@ideasonboard.com; > maarten.lankho...@linux.intel.com; mrip...@kernel.org; > tzimmerm...@suse.de; airl...@gmail.com; dan...@ffwll.ch; Simek, Michal > ; dri-devel@lists.freedesktop.org; linux-arm- > ker...@lists.infradead.org > Cc: linux-ker...@vger.kernel.org > Subject: [PATCH] drm: xlnx: dp: Reset DisplayPort IP > > Assert DisplayPort reset signal before deasserting, > it is to clear out any registers programmed before booting kernel. > > Signed-off-by: Rohit Visavalia > --- > drivers/gpu/drm/xlnx/zynqmp_dp.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c > b/drivers/gpu/drm/xlnx/zynqmp_dp.c > index 1846c4971fd8..5a40aa1d4283 100644 > --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c > +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c > @@ -1714,6 +1714,10 @@ int zynqmp_dp_probe(struct zynqmp_dpsub > *dpsub) > goto err_free; > } > > + ret = zynqmp_dp_reset(dp, true); > + if (ret < 0) > + return ret; > + > ret = zynqmp_dp_reset(dp, false); > if (ret < 0) > goto err_free; > -- > 2.25.1 This looks good to me. Reviewed-by: Vishal Sagar Regards Vishal Sagar
Re: [PATCH v2 1/6] tracing, dma-buf: add a trace_dma_fence_sync_to event
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
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
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()
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] nouveau: offload fence uevents work to workqueue
On Tue, Feb 13, 2024 at 06:39:20PM +0100, Danilo Krummrich wrote: > On 2/9/24 19:52, Daniel Vetter wrote: > > On Fri, Feb 09, 2024 at 06:41:32PM +0100, Danilo Krummrich wrote: > > > On 2/6/24 15:03, Daniel Vetter wrote: > > > > On Mon, Feb 05, 2024 at 11:00:04PM +0100, Danilo Krummrich wrote: > > > > > On 2/5/24 22:08, Dave Airlie wrote: > > > > > > On Tue, 6 Feb 2024 at 02:22, Danilo Krummrich > > > > > > wrote: > > > > > > > > > > > > > > On 1/29/24 02:50, Dave Airlie wrote: > > > > > > > > From: Dave Airlie > > > > > > > > > > > > > > > > This should break the deadlock between the fctx lock and the > > > > > > > > irq lock. > > > > > > > > > > > > > > > > This offloads the processing off the work from the irq into a > > > > > > > > workqueue. > > > > > > > > > > > > > > > > Signed-off-by: Dave Airlie > > > > > > > > > > > > > > Nouveau's scheduler uses a dedicated wq, hence from this > > > > > > > perspective it's > > > > > > > safe deferring fence signalling to the kernel global wq. However, > > > > > > > I wonder > > > > > > > if we could create deadlocks by building dependency chains into > > > > > > > other > > > > > > > drivers / kernel code that, by chance, makes use of the kernel > > > > > > > global wq as > > > > > > > well. > > > > > > > > > > > > > > Admittedly, even if, it's gonna be extremely unlikely given that > > > > > > > WQ_MAX_ACTIVE == 512. But maybe it'd be safer to use a dedicated > > > > > > > wq. > > > > > > > > > > > > > > Also, do we need to CC stable? > > > > > > > > > > > > I pushed this to Linus at the end of last week, since the hangs in > > > > > > 6.7 > > > > > > take out the complete system and I wanted it in stable. > > > > > > > > > > > > It might be safer to use a dedicated wq, is the concern someone is > > > > > > waiting on a fence in a workqueue somewhere else so we will never > > > > > > signal it? > > > > > > > > > > Yes, if some other work is waiting for this fence (or something else > > > > > in the same > > > > > dependency chain) to signal it can prevent executing the work > > > > > signaling this fence, > > > > > in case both are scheduled on the same wq. As mentioned, with the > > > > > kernel global wq > > > > > this would be rather unlikely to lead to an actual stall with > > > > > WQ_MAX_ACTIVE == 512, > > > > > but formally the race condition exists. I guess a malicious attacker > > > > > could try to > > > > > intentionally push jobs directly or indirectly depending on this > > > > > fence to a driver > > > > > which queues them up on a scheduler using the kernel global wq. > > > > > > > > I think if you add dma_fence_signalling annotations (aside, there's some > > > > patch from iirc Thomas Hellstrom to improve them and cut down on some > > > > false positives, but I lost track) then I think you won't get any splats > > > > because the wq subsystem assumes that WC_MAX_ACTIVE is close enough to > > > > infinity to not matter. > > > > > > As mentioned, for the kernel global wq it's 512. (Intentionally) feeding > > > the kernel > > > with enough jobs to to provoke a deadlock doesn't seem impossible to me. > > > > > > I think it'd be safer to just establish not to use the kernel global wq > > > for executing > > > work in the fence signalling critical path. > > > > > > We could also run into similar problems with a dedicated wq, e.g. when > > > drivers share > > > a wq between drm_gpu_scheduler instances (see [1]), however, I'm not sure > > > we can catch > > > that with lockdep. > > > > I think if you want to fix it perfectly you'd need to set the max number > > of wq to the number of engines (or for dynamic/fw scheduled engines to the > > number of context) you have. Or whatever limit to the number of parallel > > timelines there is.> I guess this would need a new wq function to > > update? drm/sched code could > > be able to set that for drivers, so drivers cannot get this wrong. > > Not sure I can follow. The scheduler instance might be per context and bind > queue. In this case it gets the shared wq passed, but doesn't know how many > other scheduler instances share the same one. Yeah that's why maybe more of that logic should be in the drm/sched code instead of drivers just cleverly using what's there ... > Additionally, there might be drivers not using the DRM scheduler for for bind > queues at all (I think Xe does not). Uh ... maybe we should do this the same across all drivers? But I also thought that Xe was flat-out synchronous and only had an out-fence since you need a userspace thread in mesa for vk semantics anyway. If xe hand-rolled a scheduler I'm not going to be very amused. > > If we don't do something like that then I'm not sure there's really much > > benefit - instead of carefully timing 512 dma_fence on the global wq you > > just need to create a pile of context (at least on intel's guc that's > > absolutely no issue) and then careful time them. > > Well, that's true. I'd still argue that
Re: [PATCH 8/8] accel/ivpu: Rename VPU to NPU in message strings
On 2/14/2024 1:13 AM, Jacek Lawrynowicz wrote: VPU was renamed to NPU but due to large overhead of renaming all the sources only user visible messages are being updated. Signed-off-by: Jacek Lawrynowicz Reviewed-by: Jeffrey Hugo
Re: [PATCH v2 6/6] drm: add drm_mode_atomic_commit event
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 7/8] accel/ivpu: Refactor BO creation functions
On 2/14/2024 1:13 AM, Jacek Lawrynowicz wrote: From: "Wachowski, Karol" Rename BO allocate/create functions, so the code is more consistent. There are now two matching buffer creation functions: - ivpu_bo_create_ioctl() - create a BO from user space - ivpu_bo_create() - create a BO from kernel space ivpu_bo_alloc() is now only used to allocate struct ivpu_bo which better matches its name. Signed-off-by: Wachowski, Karol Missing your SOB. Otherwise looks good to me. -Jeff
Re: [PATCH 6/8] accel/ivpu: Fix ivpu_reset_engine_fn merge issue
On 2/14/2024 1:13 AM, Jacek Lawrynowicz wrote: ivpu_reset_engine_fn and ivpu_reset_engine_fops were separated during merge so move them back together to keep the file consistent. Signed-off-by: Jacek Lawrynowicz Reviewed-by: Jeffrey Hugo
Re: [PATCH 5/8] accel/ivpu: Use lazy allocation for doorbell IDs
On 2/14/2024 1:13 AM, Jacek Lawrynowicz wrote: From: "Wachowski, Karol" Reserve/allocate and free doorbells for command queues when needed using xarray. This allows to avoid reserving a doorbell for a contexts that never issues a job. Signed-off-by: Wachowski, Karol Missing your SOB. Otherwise looks good to me. -Jeff
Re: [PATCH 4/8] accel/ivpu: Add support for FW boot param system_time_us
On 2/14/2024 1:13 AM, Jacek Lawrynowicz wrote: From: Krystian Pradzynski Add support for FW boot API param system_time_us. According to the API description this field should be set to system time in microseconds starting from 1970. Signed-off-by: Krystian Pradzynski Missing your SOB. Otherwise looks good to me. -Jeff
Re: [PATCH v2 1/6] tracing, dma-buf: add a trace_dma_fence_sync_to event
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
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 3/8] accel/ivpu: Update FW API headers
On 2/14/2024 1:13 AM, Jacek Lawrynowicz wrote: Update Boot API to 3.22.0 and JSM API to 3.15.6 Signed-off-by: Jacek Lawrynowicz Reviewed-by: Jeffrey Hugo
Re: [PATCH 2/8] accel/ivpu: Remove legacy firmware name
On 2/14/2024 1:12 AM, Jacek Lawrynowicz wrote: We are now using NPU IP generation based FW names instead of platform code names, so mtl_vpu.bin can be removed. Signed-off-by: Jacek Lawrynowicz Reviewed-by: Jeffrey Hugo
Re: [PATCH 1/8] accel/ivpu: Rename TILE_SKU_BOTH_MTL to TILE_SKU_BOTH
On 2/14/2024 1:12 AM, Jacek Lawrynowicz wrote: Remove legacy postfix from TILE_SKU_BOTH macro. This was missed when renaming MTL to VPU37XX. Signed-off-by: Jacek Lawrynowicz Reviewed-by: Jeffrey Hugo
Re: [PATCH v2 0/6] dma-fence, drm, amdgpu new trace events
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
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
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
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
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
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
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
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
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 pgpxlqSjZNaVG.pgp Description: OpenPGP digital signature
Re: [PATCH] drm/amd: Only allow one entity to control ABM
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] drm/dp: Don't attempt AUX transfers when eDP panels are not powered
Hi,
On Fri, Feb 16, 2024 at 12:21 AM Javier Martinez Canillas
wrote:
>
> > The kernel tree we landed on was the v5.15 tree, which is currently
> > serving all Qualcomm sc7180-based Chromebooks, all Mediatek 8173
> > Chromebooks and all Mediatek 8186 Chromebooks. There are also a pile
> > of x86 Chromebooks running our v5.15 kernel. This code shouldn't
> > affect them because (unless I'm mistaken) they don't use the two
> > affected panel drivers. In any case, I haven't heard any screams from
> > them either. Given my landing plans of "the week of the 26th", this
> > still gives another 1.5 weeks for any screams to reach my ears.
> >
> > ...or are you looking for non-ChromeOS test reports? I'm not sure how
> > to encourage those. I suppose sometimes folks at Red Hat end up
> > stumbling over similar panel problems to those of us in ChromeOS.
> > Maybe +Javier would be interested in providing a Tested-by?
> >
>
> I do have a SC7180 based HP X2 Chromebook and could test your patch (not
> today but I could do it early next week), although I haven't followed so
> if you could please let me know what exactly do you want me to verify.
>
> AFAIU the problem is that the fwupd daemon tries to scan DP busses even if
> the panel is turned off and that's what takes a lot of time (due retries),
> and your patch makes the driver to bail out immediately ? If that's the
> case, I guess that just starting fwupd daemon with an without your patch
> while the panel is turned off could be a good test ?
Sorry! I wasn't trying to sign you up for extra work. I'm not
convinced that any extra verification on a Chromebook is all that
valuable since that's pretty covered by the fact that we've already
pushed this patch out to real users on Chromebooks. I think Neil was
hoping for some confirmation that my patch didn't break someone else's
hardware. I think maybe good enough is if you have some type of
hardware that uses eDP and that you could verify that my patch does
break anything about it?
I'm not aware of anyone with extensive DP AUX character device usage.
I guess I thought of Javier because I remembered him at least also
using fwupd and some of the fwupd plugins try to talk to DP things
over the DP AUX character device.
If someone is really in a testing mood and wanted to stress the char
device, I guess something simple like "hexdump -C /dev/drm_dp_aux*"
for whatever eDP AUX is associated with eDP would at least do some
reading. You could stress turning the display on and off while doing
that with and without my patch. Presumably it will be better (error
out more quickly) with my patch.
If you wanted to stress the i2c path, you could do something like this
(the grep assumes you're using ti-sn65dsi86 as your eDP bridge chip,
but hopefully easy to adjust):
bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/')
i2cdump ${bus} 0x50 i
That should dump your EDID. Again it should error out quickly when the
panel is off after my patch but should start working again when the
panel is on.
Hmmm, thinking about all the above, I guess there is one case that
_could_ be broken by my patch. I really hope not, though. If someone
has a panel that's on an always-on rail or on a shared rail with some
other device (like the touchscreen) that's keeping the panel power on
then without my patch it would be possible to do DP AUX transactions
even when the panel was "off" from Linux's point of view. It would
have worked mostly due to luck, but now luck will run out and it will
stop working. I really hope nobody has userspace that is relying on
this, but I suppose it's always possible that somewhere, someone's
userspace is. If you are or know of someone who is then please shout.
-Doug
Re: [PATCH v3 2/8] dma-buf/fence-chain: use trace_dma_fence_sync_to
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 v3 1/8] tracing, dma-buf: add a trace_dma_fence_sync_to event
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 v3 0/8] dma-fence, drm, amdgpu new trace events
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(-)
[PATCH v3 8/8] drm/amdgpu: add devname to trace_amdgpu_sched_run_job
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
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
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
