[PATCH RESEND] drm/amd/pm: drop unneeded dpm features disablement for SMU 13.0.4/11
PMFW will handle the features disablement properly for gpu reset case,
driver involvement may cause some unexpected issues.
Signed-off-by: Tim Huang
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index ec52830dde24..8bae3fe869cd 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -1497,6 +1497,20 @@ static int smu_disable_dpms(struct smu_context *smu)
}
}
+ /*
+* For SMU 13.0.4/11, PMFW will handle the features disablement properly
+* for gpu reset case. Driver involvement is unnecessary.
+*/
+ if (amdgpu_in_reset(adev)) {
+ switch (adev->ip_versions[MP1_HWIP][0]) {
+ case IP_VERSION(13, 0, 4):
+ case IP_VERSION(13, 0, 11):
+ return 0;
+ default:
+ break;
+ }
+ }
+
/*
* For gpu reset, runpm and hibernation through BACO,
* BACO feature has to be kept enabled.
--
2.25.1
[linux-next:master] BUILD REGRESSION 9fbee811e479aca2f3523787cae1f46553141b40
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 9fbee811e479aca2f3523787cae1f46553141b40 Add linux-next specific files for 20230125 Error/Warning: (recently discovered and may have been fixed) ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/idma64.ko] undefined! drivers/gpu/drm/amd/amdgpu/../display/dc/link/accessories/link_dp_trace.c:148:6: warning: no previous prototype for 'link_dp_trace_set_edp_power_timestamp' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/accessories/link_dp_trace.c:158:10: warning: no previous prototype for 'link_dp_trace_get_edp_poweron_timestamp' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/accessories/link_dp_trace.c:163:10: warning: no previous prototype for 'link_dp_trace_get_edp_poweroff_timestamp' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:1294:32: warning: variable 'result_write_min_hblank' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:1295:32: warning: variable 'result_write_min_hblank' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:278:42: warning: variable 'ds_port' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:279:42: warning: variable 'ds_port' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training.c:1585:38: warning: variable 'result' set but not used [-Wunused-but-set-variable] Unverified Error/Warning (likely false positive, please contact us if interested): drivers/media/i2c/max9286.c:802 max9286_s_stream() error: buffer overflow 'priv->fmt' 4 <= 32 drivers/nvmem/imx-ocotp.c:599:21: sparse: sparse: symbol 'imx_ocotp_layout' was not declared. Should it be static? net/devlink/leftover.c:7160 devlink_fmsg_prepare_skb() error: uninitialized symbol 'err'. Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- arc-randconfig-m031-20230123 | `-- drivers-media-i2c-max9286.c-max9286_s_stream()-error:buffer-overflow-priv-fmt |-- loongarch-randconfig-r014-20230123 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-accessories-link_dp_trace.c:warning:no-previous-prototype-for-link_dp_trace_get_edp_poweroff_timestamp | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-accessories-link_dp_trace.c:warning:no-previous-prototype-for-link_dp_trace_get_edp_poweron_timestamp | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-accessories-link_dp_trace.c:warning:no-previous-prototype-for-link_dp_trace_set_edp_power_timestamp | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:variable-ds_port-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:variable-result_write_min_hblank-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_training.c:warning:variable-result-set-but-not-used |-- riscv-randconfig-s033-20230123 | `-- drivers-nvmem-imx-ocotp.c:sparse:sparse:symbol-imx_ocotp_layout-was-not-declared.-Should-it-be-static |-- s390-allmodconfig | |-- ERROR:devm_platform_ioremap_resource-drivers-dma-fsl-edma.ko-undefined | `-- ERROR:devm_platform_ioremap_resource-drivers-dma-idma64.ko-undefined |-- s390-randconfig-c042-20230123 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-accessories-link_dp_trace.c:warning:no-previous-prototype-for-link_dp_trace_get_edp_poweroff_timestamp | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-accessories-link_dp_trace.c:warning:no-previous-prototype-for-link_dp_trace_get_edp_poweron_timestamp | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-accessories-link_dp_trace.c:warning:no-previous-prototype-for-link_dp_trace_set_edp_power_timestamp | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:variable-ds_port-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:variable-result_write_min_hblank-set-but-not-used |-- s390-randconfig-r032-20230123 | `-- ERROR:devm_platform_ioremap_resource-drivers-dma-idma64.ko-undefined `-- x86_64-randconfig-m001-20230123 `-- net-devlink-leftover.c-devlink_fmsg_prepare_skb()-error:uninitialized-symbol-err-. elapsed time: 4125m configs tested: 62 configs skipped: 2 gcc tested configs: um i386_defconfig x86_64allnoconfig um x86_64_defconfig x86_64 rhel-8.3-func powerpc allnoconfig x86_64rhel-8.3-kselftests x86_64
[pull] amdgpu drm-next-6.3
Hi Dave, Daniel, A few more new things for 6.3. The following changes since commit b4a9b36e69e935104e52e561aa9a82d39b5efc36: Documentation/gpu: update dGPU asic info table (2023-01-19 17:24:26 -0500) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-6.3-2023-01-27 for you to fetch changes up to cdf657fc1f4c9758f86ae3adeb32ee68cbd90691: amdgpu: fix build on non-DCN platforms. (2023-01-27 17:25:40 -0500) amd-drm-next-6.3-2023-01-27: amdgpu: - GC11 fixes - SMU13 fixes - Freesync fixes - DP MST fixes - DP MST code rework and cleanup - AV1 fixes for VCN4 - DCN 3.2.x fixes - PSR fixes - DML optimizations - DC link code rework Alex Deucher (1): drm/amdgpu/vcn4: add missing encoder cap Alvin Lee (4): drm/amd/display: Allow idle optimization after turning off all pipes drm/amd/display: Disable SubVP for PSR panels drm/amd/display: Use |= when assigning wm_optimized_required drm/amd/display: Set init freq for DCFCLK DS Anthony Koo (1): drm/amd/display: [FW Promotion] Release 0.0.150.0 Aric Cyr (2): drm/amd/display: 3.2.219 drm/amd/display: 3.2.220 Aurabindo Pillai (3): drm/amd/display: Revert "ignore msa parameter only if freesync is enabled" drm/amd/display: set allow_freesync parameter in DM drm/amd/display: Fix timing not changning when freesync video is enabled Dave Airlie (1): amdgpu: fix build on non-DCN platforms. David (Ming Qiang) Wu (1): drm/amdgpu: limit AV1 to the first instance on VCN4 encode Dillon Varone (1): drm/amd/display: Disable MALL SS and messages for PSR supported configs Evan Quan (1): drm/amd/pm: add missing AllowIHInterrupt message mapping for SMU13.0.0 Hamza Mahfooz (1): drm/amd/display: use a more appropriate return value in dp_retrieve_lttpr_cap() Ilya Bakoulin (1): drm/amd/display: Speed up DML fast_validate path Jingwen Zhu (1): drm/amd/display: avoid disable otg when dig was disabled Jonathan Kim (1): drm/amdgpu: remove unconditional trap enable on add gfx11 queues Li Ma (2): drm/amdgpu: enable imu firmware for GC 11.0.4 drm/amdgpu: declare firmware for new MES 11.0.4 Lyude Paul (1): drm/amdgpu/display/mst: Fix mst_state->pbn_div and slot count assignments Qingqing Zhuo (1): drm/amd/display: force connector state when bpc changes during compliance Robin Chen (1): drm/amd/display: Pass DSC slice height to PSR FW Roman Li (1): drm/amd/display: Set hvm_enabled flag for S/G mode Saaem Rizvi (1): drm/amd/display: Correcting prefetch mode for fast validate Samson Tam (1): drm/amd/display: adjust MALL size available for DCN32 and DCN321 Stylon Wang (2): drm/amd/display: Guard Freesync HDMI parsing with dc_lock drm/amd/display: Properly reuse completion structure Sung Joon Kim (1): drm/amd/display: Enable AdaptiveSync in DC interface Tim Huang (1): drm/amdgpu: skip psp suspend for IMU enabled ASICs mode2 reset Wayne Lin (6): drm/amdgpu/display/mst: limit payload to be updated one by one drm/amdgpu/display/mst: update mst_mgr relevant variable when long HPD drm/drm_print: correct format problem drm/display/dp_mst: Correct the kref of port. drm/amdgpu/display/mst: adjust the naming of mst_port and port of aconnector drm/amdgpu/display/mst: adjust the logic in 2nd phase of updating payload Wenjing Liu (5): drm/amd/display: create accessories, hwss and protocols sub folders in link drm/amd/display: move eDP panel control logic to link_edp_panel_control drm/amd/display: move dp irq handler functions from dc_link_dp to link_dp_irq_handler drm/amd/display: move dp cts functions from dc_link_dp to link_dp_cts drm/amd/display: merge dc_link_dp into dc_link drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 12 + drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h |4 +- drivers/gpu/drm/amd/amdgpu/imu_v11_0.c |1 + drivers/gpu/drm/amd/amdgpu/mes_v11_0.c |3 +- drivers/gpu/drm/amd/amdgpu/soc21.c |1 + drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c | 62 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 138 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |9 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c |2 +- .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 18 +- .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 200 +- .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 54 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c |2 +- drivers/gpu/drm/amd/display/dc/Makefile|3 +- drivers/gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c |1 + .../amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c |1 +
Re: [PATCH] drm/amd/display: Properly handle additional cases where DCN is not supported
[AMD Official Use Only - General]
Reviewed-by: Aurabindo Pillai
--
Regards,
Aurabindo
From: Deucher, Alexander
Sent: Friday, January 27, 2023 1:05 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Pillai, Aurabindo
Subject: [PATCH] drm/amd/display: Properly handle additional cases where DCN is
not supported
There could be boards with DCN listed in IP discovery, but no
display hardware actually wired up. In this case the vbios
display table will not be populated. Detect this case and
skip loading DM when we detect it.
v2: Mark DCN as harvested as well so other display checks
elsewhere in the driver are handled properly.
Cc: Aurabindo Pillai
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 42d99bf4bbc9..fe66b7aec248 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4563,6 +4563,17 @@ static int dm_init_microcode(struct amdgpu_device *adev)
static int dm_early_init(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+ struct amdgpu_mode_info *mode_info = >mode_info;
+ struct atom_context *ctx = mode_info->atom_context;
+ int index = GetIndexIntoMasterTable(DATA, Object_Header);
+ u16 data_offset;
+
+ /* if there is no object header, skip DM */
+ if (!amdgpu_atom_parse_data_header(ctx, index, NULL, NULL, NULL,
_offset)) {
+ adev->harvest_ip_mask |= AMD_HARVEST_IP_DMU_MASK;
+ dev_info(adev->dev, "No object header, skipping DM\n");
+ return -ENOENT;
+ }
switch (adev->asic_type) {
#if defined(CONFIG_DRM_AMD_DC_SI)
--
2.39.1
[PATCH] drm/amd/display: Properly handle additional cases where DCN is not supported
There could be boards with DCN listed in IP discovery, but no
display hardware actually wired up. In this case the vbios
display table will not be populated. Detect this case and
skip loading DM when we detect it.
v2: Mark DCN as harvested as well so other display checks
elsewhere in the driver are handled properly.
Cc: Aurabindo Pillai
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 42d99bf4bbc9..fe66b7aec248 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4563,6 +4563,17 @@ static int dm_init_microcode(struct amdgpu_device *adev)
static int dm_early_init(void *handle)
{
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+ struct amdgpu_mode_info *mode_info = >mode_info;
+ struct atom_context *ctx = mode_info->atom_context;
+ int index = GetIndexIntoMasterTable(DATA, Object_Header);
+ u16 data_offset;
+
+ /* if there is no object header, skip DM */
+ if (!amdgpu_atom_parse_data_header(ctx, index, NULL, NULL, NULL,
_offset)) {
+ adev->harvest_ip_mask |= AMD_HARVEST_IP_DMU_MASK;
+ dev_info(adev->dev, "No object header, skipping DM\n");
+ return -ENOENT;
+ }
switch (adev->asic_type) {
#if defined(CONFIG_DRM_AMD_DC_SI)
--
2.39.1
Re: [PATCH v3 01/10] drm/client: Test for connectors before sending hotplug event
On Wednesday, January 25th, 2023 at 21:04, Thomas Zimmermann wrote: > Not having connectors indicates a driver bug. Is it? What if all connectors are of the DP-MST type, ie. they are created on-the-fly?
[PATCH] drm/amd/display: add missing cyanskillfish check
For clkmgr setup.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c
index 69691daf4dbb..91f7e7386da4 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/clk_mgr.c
@@ -269,7 +269,8 @@ struct clk_mgr *dc_clk_mgr_create(struct dc_context *ctx,
struct pp_smu_funcs *p
dcn3_clk_mgr_construct(ctx, clk_mgr, pp_smu, dccg);
return _mgr->base;
}
- if (asic_id.chip_id == DEVICE_ID_NV_13FE) {
+ if ((asic_id.chip_id == DEVICE_ID_NV_13FE) ||
+ (asic_id.chip_id == DEVICE_ID_NV_143F)) {
dcn201_clk_mgr_construct(ctx, clk_mgr, pp_smu, dccg);
return _mgr->base;
}
--
2.39.1
[RFC PATCH] drm/amdgpu: add force_sg_display module parameter (v2)
Add a module parameter to force sg (scatter/gather) display on APUs. Normally we allow displays in both VRAM and GTT, but this option forces displays into GTT so we can explicitly test more scenarios with GTT. v2: fix checks Signed-off-by: Alex Deucher --- For reference since the original patch was buggy. drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 12 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 +++ 3 files changed, 17 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h index 872450a3a164..73d0a0807138 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h @@ -244,6 +244,8 @@ extern int amdgpu_num_kcq; #define AMDGPU_VCNFW_LOG_SIZE (32 * 1024) extern int amdgpu_vcnfw_log; +extern int amdgpu_force_sg_display; + #define AMDGPU_VM_MAX_NUM_CTX 4096 #define AMDGPU_SG_THRESHOLD(256*1024*1024) #define AMDGPU_DEFAULT_GTT_SIZE_MB 3072ULL /* 3GB by default */ diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index 4cf2028b5235..c8975c2da853 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -943,6 +943,18 @@ MODULE_PARM_DESC(smu_pptable_id, "specify pptable id to be used (-1 = auto(default) value, 0 = use pptable from vbios, > 0 = soft pptable id)"); module_param_named(smu_pptable_id, amdgpu_smu_pptable_id, int, 0444); +/** + * DOC: force_sg_display (int) + * Force display buffers into GTT (scatter/gather) memory for APUs. + * This is used to force GTT only for displays rather than displaying from + * either VRAM (carve out) or GTT. + * + * Defaults to 0, or disabled. + */ +int amdgpu_force_sg_display; +MODULE_PARM_DESC(force_sg_display, "Force S/G display (0 = off (default), 1 = force display to use GTT) "); +module_param_named(force_sg_display, amdgpu_force_sg_display, int, 0444); + /* These devices are not supported by amdgpu. * They are supported by the mach64, r128, radeon drivers */ diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index 981010de0a28..840190dd78e4 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -1516,6 +1516,9 @@ uint32_t amdgpu_bo_get_preferred_domain(struct amdgpu_device *adev, if (adev->gmc.real_vram_size <= AMDGPU_SG_THRESHOLD) domain = AMDGPU_GEM_DOMAIN_GTT; } + if ((domain == (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT)) && + amdgpu_force_sg_display && adev->mode_info.gpu_vm_support) + domain = AMDGPU_GEM_DOMAIN_GTT; return domain; } -- 2.39.1
Re: [PATCH v3 04/10] drm/fbdev-generic: Initialize fb-helper structure in generic setup
On Fri, Jan 27, 2023 at 03:21:30PM +0100, Thomas Zimmermann wrote: > Hi > > Am 25.01.23 um 22:03 schrieb Sam Ravnborg: > > Hi Thomas, > > > > On Wed, Jan 25, 2023 at 09:04:09PM +0100, Thomas Zimmermann wrote: > > > Initialize the fb-helper structure immediately after its allocation > > > in drm_fbdev_generic_setup(). That will make it easier to fill it with > > > driver-specific values, such as the preferred BPP. > > > > > > Signed-off-by: Thomas Zimmermann > > > Reviewed-by: Javier Martinez Canillas > > > --- > > > drivers/gpu/drm/drm_fbdev_generic.c | 13 + > > > 1 file changed, 9 insertions(+), 4 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/drm_fbdev_generic.c > > > b/drivers/gpu/drm/drm_fbdev_generic.c > > > index 135d58b8007b..63f66325a8a5 100644 > > > --- a/drivers/gpu/drm/drm_fbdev_generic.c > > > +++ b/drivers/gpu/drm/drm_fbdev_generic.c > > > @@ -385,8 +385,6 @@ static int drm_fbdev_client_hotplug(struct > > > drm_client_dev *client) > > > if (dev->fb_helper) > > > return drm_fb_helper_hotplug_event(dev->fb_helper); > > > - drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs); > > > - > > > ret = drm_fb_helper_init(dev, fb_helper); > > > if (ret) > > > goto err; > > > > From the documentation: > > The drm_fb_helper_prepare() > > helper must be called first to initialize the minimum required to make > > hotplug detection work. > > ... > > To finish up the fbdev helper initialization, the > > drm_fb_helper_init() function is called. > > > > So this change do not follow the documentation as drm_fb_helper_init() > > is now called before drm_fb_helper_prepare() > > No, we now call drm_fb_helper_prepare() from within > drm_fbdev_generic_setup(), right after allocating the fb_helper. > drm_fb_helper_init() will only be called after the client received a > hot-plug event. > > > > > I did not follow all the code - but my gut feeling is that the > > documentation is right. > > The docs are of low quality. The _prepare() helper is the actual init > function and _init() only sets the fb_helper in the device instance. OK, thanks for the follow-up. Sam
Re: [PATCH v3 01/10] drm/client: Test for connectors before sending hotplug event
On Fri, Jan 27, 2023 at 03:13:50PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 25.01.23 um 21:52 schrieb Sam Ravnborg:
> > Hi Thomas,
> >
> > On Wed, Jan 25, 2023 at 09:04:06PM +0100, Thomas Zimmermann wrote:
> > > Test for connectors in the client code and remove a similar test
> > > from the generic fbdev emulation. Do nothing if the test fails.
> > > Not having connectors indicates a driver bug.
> > >
> > > Signed-off-by: Thomas Zimmermann
> > > Reviewed-by: Javier Martinez Canillas
> > > ---
> > > drivers/gpu/drm/drm_client.c| 5 +
> > > drivers/gpu/drm/drm_fbdev_generic.c | 5 -
> > > 2 files changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> > > index 262ec64d4397..09ac191c202d 100644
> > > --- a/drivers/gpu/drm/drm_client.c
> > > +++ b/drivers/gpu/drm/drm_client.c
> > > @@ -198,6 +198,11 @@ void drm_client_dev_hotplug(struct drm_device *dev)
> > > if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > > return;
> > > + if (!dev->mode_config.num_connector) {
> > > + drm_dbg_kms(dev, "No connectors found, will not send hotplug
> > > events!\n");
> > > + return;
> > This deserves a more visible logging - if a driver fails here it would
> > be good to spot it in the normal kernel log.
> > drm_info or drm_notice?
>
> But is that really noteworthy? AFAIK, this situation can legally happen. So
> if it's expected, why should we print a message about it?
I was reading it as a driver error - as that's not the case current code
is fine.
Sam
RE: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"
[Public]
> -Original Message-
> From: Linux kernel regression tracking (Thorsten Leemhuis)
>
> Sent: Friday, January 27, 2023 03:15
> To: Greg KH ; Limonciello, Mario
>
> Cc: dri-de...@lists.freedesktop.org; sta...@vger.kernel.org;
> stanislav.lisovs...@intel.com; Zuo, Jerry ; amd-
> g...@lists.freedesktop.org; Lin, Wayne ; Guenter
> Roeck ; bske...@redhat.com
> Subject: Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into
> the atomic state"
>
> On 27.01.23 08:39, Greg KH wrote:
> > On Fri, Jan 20, 2023 at 11:51:04AM -0600, Limonciello, Mario wrote:
> >> On 1/20/2023 11:46, Guenter Roeck wrote:
> >>> On Thu, Jan 12, 2023 at 04:50:44PM +0800, Wayne Lin wrote:
> This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.
>
> [Why]
> Changes cause regression on amdgpu mst.
> E.g.
> In fill_dc_mst_payload_table_from_drm(), amdgpu expects to
> add/remove payload
> one by one and call fill_dc_mst_payload_table_from_drm() to update
> the HW
> maintained payload table. But previous change tries to go through all
> the
> payloads in mst_state and update amdpug hw maintained table in once
> everytime
> driver only tries to add/remove a specific payload stream only. The
> newly
> design idea conflicts with the implementation in amdgpu nowadays.
>
> [How]
> Revert this patch first. After addressing all regression problems caused
> by
> this previous patch, will add it back and adjust it.
> >>>
> >>> Has there been any progress on this revert, or on fixing the underlying
> >>> problem ?
> >>>
> >>> Thanks,
> >>> Guenter
> >>
> >> Hi Guenter,
> >>
> >> Wayne is OOO for CNY, but let me update you.
> >>
> >> Harry has sent out this series which is a collection of proper fixes.
> >> https://patchwork.freedesktop.org/series/113125/
> >>
> >> Once that's reviewed and accepted, 4 of them are applicable for 6.1.
> >
> > Any hint on when those will be reviewed and accepted? patchwork
> doesn't
> > show any activity on them, or at least I can't figure it out...
>
> I didn't look closer (hence please correct me if I'm wrong), but the
> core changes afaics are in the DRM pull airlied send a few hours ago to
> Linus (note the "amdgpu […] DP MST fixes" line):
>
> https://lore.kernel.org/all/CAPM%3D9tzuu4xnx6T5v7sKsK%2BA5HEaPOc1ie
> myznsyqzgztj%3d...@mail.gmail.com/
That's right. There are 4 commits in that PR with the appropriate stable tags
that should fix the majority of the MST issues introduced in 6.1 by
4d07b0bc40340
("drm/display/dp_mst: Move all payload info into the atomic state"):
drm/amdgpu/display/mst: Fix mst_state->pbn_div and slot count assignments
drm/amdgpu/display/mst: limit payload to be updated one by one
drm/amdgpu/display/mst: update mst_mgr relevant variable when long HPD
drm/display/dp_mst: Correct the kref of port.
There will be follow ups for any remaining corner cases.
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"
Hey Greg, On 1/27/23 02:39, Greg KH wrote: On Fri, Jan 20, 2023 at 11:51:04AM -0600, Limonciello, Mario wrote: On 1/20/2023 11:46, Guenter Roeck wrote: On Thu, Jan 12, 2023 at 04:50:44PM +0800, Wayne Lin wrote: This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f. [Why] Changes cause regression on amdgpu mst. E.g. In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove payload one by one and call fill_dc_mst_payload_table_from_drm() to update the HW maintained payload table. But previous change tries to go through all the payloads in mst_state and update amdpug hw maintained table in once everytime driver only tries to add/remove a specific payload stream only. The newly design idea conflicts with the implementation in amdgpu nowadays. [How] Revert this patch first. After addressing all regression problems caused by this previous patch, will add it back and adjust it. Has there been any progress on this revert, or on fixing the underlying problem ? Thanks, Guenter Hi Guenter, Wayne is OOO for CNY, but let me update you. Harry has sent out this series which is a collection of proper fixes. https://patchwork.freedesktop.org/series/113125/ Once that's reviewed and accepted, 4 of them are applicable for 6.1. Any hint on when those will be reviewed and accepted? patchwork doesn't show any activity on them, or at least I can't figure it out... These patches have already made it into amd-staging-drm-next and as of https://lore.kernel.org/amd-gfx/20230125220153.320248-1-alexander.deuc...@amd.com/ they should land in drm-next soon if they haven't already. thanks, greg k-h -- Hamza
Re: [PATCH v3 04/10] drm/fbdev-generic: Initialize fb-helper structure in generic setup
Hi
Am 25.01.23 um 22:03 schrieb Sam Ravnborg:
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:09PM +0100, Thomas Zimmermann wrote:
Initialize the fb-helper structure immediately after its allocation
in drm_fbdev_generic_setup(). That will make it easier to fill it with
driver-specific values, such as the preferred BPP.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_fbdev_generic.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index 135d58b8007b..63f66325a8a5 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -385,8 +385,6 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev
*client)
if (dev->fb_helper)
return drm_fb_helper_hotplug_event(dev->fb_helper);
- drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs);
-
ret = drm_fb_helper_init(dev, fb_helper);
if (ret)
goto err;
From the documentation:
The drm_fb_helper_prepare()
helper must be called first to initialize the minimum required to make
hotplug detection work.
...
To finish up the fbdev helper initialization, the
drm_fb_helper_init() function is called.
So this change do not follow the documentation as drm_fb_helper_init()
is now called before drm_fb_helper_prepare()
No, we now call drm_fb_helper_prepare() from within
drm_fbdev_generic_setup(), right after allocating the fb_helper.
drm_fb_helper_init() will only be called after the client received a
hot-plug event.
I did not follow all the code - but my gut feeling is that the
documentation is right.
The docs are of low quality. The _prepare() helper is the actual init
function and _init() only sets the fb_helper in the device instance.
Best regards
Thomas
Sam
@@ -456,12 +454,12 @@ void drm_fbdev_generic_setup(struct drm_device *dev,
fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL);
if (!fb_helper)
return;
+ drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs);
ret = drm_client_init(dev, _helper->client, "fbdev", _fbdev_client_funcs);
if (ret) {
- kfree(fb_helper);
drm_err(dev, "Failed to register client: %d\n", ret);
- return;
+ goto err_drm_client_init;
}
/*
@@ -484,5 +482,12 @@ void drm_fbdev_generic_setup(struct drm_device *dev,
drm_dbg_kms(dev, "client hotplug ret=%d\n", ret);
drm_client_register(_helper->client);
+
+ return;
+
+err_drm_client_init:
+ drm_fb_helper_unprepare(fb_helper);
+ kfree(fb_helper);
+ return;
}
EXPORT_SYMBOL(drm_fbdev_generic_setup);
--
2.39.0
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v3 02/10] drm/client: Add hotplug_failed flag
Hi
Am 25.01.23 um 21:57 schrieb Sam Ravnborg:
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:07PM +0100, Thomas Zimmermann wrote:
Signal failed hotplugging with a flag in struct drm_client_dev. If set,
the client helpers will not further try to set up the fbdev display.
This used to be signalled with a combination of cleared pointers in
struct drm_fb_helper,
I failed to find where we clear the pointers. What do I miss?
Those pointer fields, dev and funcs, where allocated with kzalloc(). The
error path in drm_fbdev_client_hotplug() later reset them to NULL again
if an error occured.
Best regards
Thomas
(I had assumed we would stop clearing the pointers after this change).
Sam
which prevents us from initializing these pointers
early after allocation.
The change also harmonizes behavior among DRM clients. Additional DRM
clients will now handle failed hotplugging like fbdev does.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_client.c| 5 +
drivers/gpu/drm/drm_fbdev_generic.c | 4
include/drm/drm_client.h| 8
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 09ac191c202d..009e7b10455c 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -208,8 +208,13 @@ void drm_client_dev_hotplug(struct drm_device *dev)
if (!client->funcs || !client->funcs->hotplug)
continue;
+ if (client->hotplug_failed)
+ continue;
+
ret = client->funcs->hotplug(client);
drm_dbg_kms(dev, "%s: ret=%d\n", client->name, ret);
+ if (ret)
+ client->hotplug_failed = true;
}
mutex_unlock(>clientlist_mutex);
}
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index 3d455a2e3fb5..135d58b8007b 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -382,10 +382,6 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev
*client)
struct drm_device *dev = client->dev;
int ret;
- /* Setup is not retried if it has failed */
- if (!fb_helper->dev && fb_helper->funcs)
- return 0;
-
if (dev->fb_helper)
return drm_fb_helper_hotplug_event(dev->fb_helper);
diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
index 4fc8018eddda..39482527a775 100644
--- a/include/drm/drm_client.h
+++ b/include/drm/drm_client.h
@@ -106,6 +106,14 @@ struct drm_client_dev {
* @modesets: CRTC configurations
*/
struct drm_mode_set *modesets;
+
+ /**
+* @hotplug failed:
+*
+* Set by client hotplug helpers if the hotplugging failed
+* before. It is usually not tried again.
+*/
+ bool hotplug_failed;
};
int drm_client_init(struct drm_device *dev, struct drm_client_dev *client,
--
2.39.0
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] ALSA: hda/hdmi: Use only dynamic PCM device allocation #forregzbot
[TLDR: This mail in primarily relevant for Linux kernel regression tracking. See link in footer if these mails annoy you.] On 26.12.22 14:26, Thorsten Leemhuis wrote: > On 25.12.22 13:14, Michael Laß wrote: >> CC'ing amd-gfx as this might be an issue in the amd driver. >> >> This change causes a regression in Linux 6.1 at least on some AMD APUs. >> There are reports from users with Ryzen 4750U, 5800U and 5850U chips >> where the HDMI sound devices don't show up anymore. I'm affected by >> this as well. >> >> Reverting this commit (ef6f5494) makes the HDMI audio devices show up >> again. I verified that this is still an issue in current Linux git >> (72a85e2b). > > Thanks for the report. To be sure below issue doesn't fall through the > cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression > tracking bot: > > #regzbot ^introduced ef6f5494faf6a37c74990689a > #regzbot title alsa: hda/hdmi: HDMI sound devices don't show up anymore > with some AMD APUs > #regzbot ignore-activity #regzbot fix: 090ddad4c7a9 #regzbot ignore-activity Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr That page also explains what to do if mails like this annoy you.
Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"
On 27.01.23 08:39, Greg KH wrote: > On Fri, Jan 20, 2023 at 11:51:04AM -0600, Limonciello, Mario wrote: >> On 1/20/2023 11:46, Guenter Roeck wrote: >>> On Thu, Jan 12, 2023 at 04:50:44PM +0800, Wayne Lin wrote: This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f. [Why] Changes cause regression on amdgpu mst. E.g. In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove payload one by one and call fill_dc_mst_payload_table_from_drm() to update the HW maintained payload table. But previous change tries to go through all the payloads in mst_state and update amdpug hw maintained table in once everytime driver only tries to add/remove a specific payload stream only. The newly design idea conflicts with the implementation in amdgpu nowadays. [How] Revert this patch first. After addressing all regression problems caused by this previous patch, will add it back and adjust it. >>> >>> Has there been any progress on this revert, or on fixing the underlying >>> problem ? >>> >>> Thanks, >>> Guenter >> >> Hi Guenter, >> >> Wayne is OOO for CNY, but let me update you. >> >> Harry has sent out this series which is a collection of proper fixes. >> https://patchwork.freedesktop.org/series/113125/ >> >> Once that's reviewed and accepted, 4 of them are applicable for 6.1. > > Any hint on when those will be reviewed and accepted? patchwork doesn't > show any activity on them, or at least I can't figure it out... I didn't look closer (hence please correct me if I'm wrong), but the core changes afaics are in the DRM pull airlied send a few hours ago to Linus (note the "amdgpu […] DP MST fixes" line): https://lore.kernel.org/all/capm%3d9tzuu4xnx6t5v7sksk%2ba5heapoc1iemyznsyqzgztj%3d...@mail.gmail.com/ Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page.
Re: [PATCH v3 01/10] drm/client: Test for connectors before sending hotplug event
Hi
Am 25.01.23 um 21:52 schrieb Sam Ravnborg:
Hi Thomas,
On Wed, Jan 25, 2023 at 09:04:06PM +0100, Thomas Zimmermann wrote:
Test for connectors in the client code and remove a similar test
from the generic fbdev emulation. Do nothing if the test fails.
Not having connectors indicates a driver bug.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
---
drivers/gpu/drm/drm_client.c| 5 +
drivers/gpu/drm/drm_fbdev_generic.c | 5 -
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 262ec64d4397..09ac191c202d 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -198,6 +198,11 @@ void drm_client_dev_hotplug(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return;
+ if (!dev->mode_config.num_connector) {
+ drm_dbg_kms(dev, "No connectors found, will not send hotplug
events!\n");
+ return;
This deserves a more visible logging - if a driver fails here it would
be good to spot it in the normal kernel log.
drm_info or drm_notice?
But is that really noteworthy? AFAIK, this situation can legally happen.
So if it's expected, why should we print a message about it?
Best regards
Thomas
The original code had this on the debug level, but when moving the log
level could also be updated.
Sam
+ }
+
mutex_lock(>clientlist_mutex);
list_for_each_entry(client, >clientlist, list) {
if (!client->funcs || !client->funcs->hotplug)
diff --git a/drivers/gpu/drm/drm_fbdev_generic.c
b/drivers/gpu/drm/drm_fbdev_generic.c
index 0a4c160e0e58..3d455a2e3fb5 100644
--- a/drivers/gpu/drm/drm_fbdev_generic.c
+++ b/drivers/gpu/drm/drm_fbdev_generic.c
@@ -389,11 +389,6 @@ static int drm_fbdev_client_hotplug(struct drm_client_dev
*client)
if (dev->fb_helper)
return drm_fb_helper_hotplug_event(dev->fb_helper);
- if (!dev->mode_config.num_connector) {
- drm_dbg_kms(dev, "No connectors found, will not create
framebuffer!\n");
- return 0;
- }
-
drm_fb_helper_prepare(dev, fb_helper, _fb_helper_generic_funcs);
ret = drm_fb_helper_init(dev, fb_helper);
--
2.39.0
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"
On Fri, Jan 20, 2023 at 11:51:04AM -0600, Limonciello, Mario wrote: > On 1/20/2023 11:46, Guenter Roeck wrote: > > On Thu, Jan 12, 2023 at 04:50:44PM +0800, Wayne Lin wrote: > > > This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f. > > > > > > [Why] > > > Changes cause regression on amdgpu mst. > > > E.g. > > > In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove > > > payload > > > one by one and call fill_dc_mst_payload_table_from_drm() to update the HW > > > maintained payload table. But previous change tries to go through all the > > > payloads in mst_state and update amdpug hw maintained table in once > > > everytime > > > driver only tries to add/remove a specific payload stream only. The newly > > > design idea conflicts with the implementation in amdgpu nowadays. > > > > > > [How] > > > Revert this patch first. After addressing all regression problems caused > > > by > > > this previous patch, will add it back and adjust it. > > > > Has there been any progress on this revert, or on fixing the underlying > > problem ? > > > > Thanks, > > Guenter > > Hi Guenter, > > Wayne is OOO for CNY, but let me update you. > > Harry has sent out this series which is a collection of proper fixes. > https://patchwork.freedesktop.org/series/113125/ > > Once that's reviewed and accepted, 4 of them are applicable for 6.1. Any hint on when those will be reviewed and accepted? patchwork doesn't show any activity on them, or at least I can't figure it out... thanks, greg k-h
