Created attachment 145320 [details] dmesg logs Steps to Reproduce =============== 1. Connect 2 external monitors to the DUT Via DP MST Hub 2. Unplug from the typec end of the DP MST hub of the external monitors and observe this error in the dmesg "[drm:intel_mst_disable_dp] ERROR failed to update payload -22" Expected Result ============= There must not be any errors in the dmesg Actual Result =========== drm error during unplug from the typec end of the DP MST hub of the external monitors "[drm:intel_mst_disable_dp] ERROR failed to update payload -22" Build versions: CPU: Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz (8 cores) Kernel: Linux 5.3.0-rc7-18003-g3ced322fa271 x86_64 (DRM-TIP) Note: 0. No functionality is getting affected. 1.Though there were these drm messages, there were no distortions in the display (both external monitors and the eDP) 2. This error (ie., "[drm:intel_mst_disable_dp] ERROR failed to update payload -22") is seen when you try to remove the dock itself (which has two external monitors connected via DP cables 3.This error is not seen, when you try to unplug the DP cables (where monitors are connected) from the dock. 4. "No Signal" is seen immediately , when try to unplug the dock. 5. Attached the dmesg logs with the following sequence adding some markers where you plug and unplug the dock and whether the outputs are ok/not ok after the plug-in like the following: <boot the machine without the dock being connected> # echo "Plug dock" > /dev/kmsg <plug the dock with the 2 monitors already attached to it> # echo "Outputs ok/not ok" > /dev/kmsg # echo "Unplug dock" > /dev/kmsg <unplug the dock> <repeat from 2. until you see the problem and after that a few iterations> dmesg > dmesg.log Solutions: I would like to propose the following solutions based on my knowledge: 1. Change the print error message to WARNING message OR 2. Check if the device is not connected, then don't throw this payload error, throw some Warning message else throw this payload error Thanks, -Srini
Can I use the "connector_status_connected" & "connector_status_disconnected" of "enum drm_connector_status" to check the status of the DP_MST dock is being connected or not connected? May I know if there is any other functions that gets affected by adding this check apart from "intel_mst_disable_dp" Thanks -Srini
If the above "connector_status_disconnected" is not feasible, could you please help me to check where can I find the following: 1. Whether the typeC is connected or not? 2. If the typec is disconnected how can we utilize this function by exporting it in "intel_mst_disable_dp", so that we can skip this error & print some warning message Thanks, -Srini
Sorry the dmesg logs I have attached is for Linux version 4.19.67-06331-g96a3acdc3724, soon I will attach the dmesg logs for drm-tip kernel as well
Thanks Srini for reporting this, could you please also create the logs with drm-tip with drm.debug = 0xe instead of 0x1e so that there is less noise in the logs. Manasi
Created attachment 145330 [details] dmesg logs of drm-tip kernel
Thanks for your quick responses Manasi I have attached the drm-tip logs in the attachment. -Srini
Not sure how much it's related to this issue i915 0000:00:02.0: Direct firmware load for i915/kbl_dmc_ver1_04.bin failed with error -2 [ 0.628494] i915 0000:00:02.0: Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin. Disabling runtime power management. [ 0.628496] i915 0000:00:02.0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i91 Setting the priority and severity based on the user impact. Component can be set when we know what it is.
(In reply to Lakshmi from comment #7) > Not sure how much it's related to this issue > > i915 0000:00:02.0: Direct firmware load for i915/kbl_dmc_ver1_04.bin failed > with error -2 > [ 0.628494] i915 0000:00:02.0: Failed to load DMC firmware > i915/kbl_dmc_ver1_04.bin. Disabling runtime power management. > [ 0.628496] i915 0000:00:02.0: DMC firmware homepage: > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ > tree/i91 > > Setting the priority and severity based on the user impact. Component can be > set when we know what it is. @Jon, Any comments here?
Not really sure if related but would make sense to have all fw in place in /lib/firmware/i915
Created attachment 145343 [details] [review] Patch to fix the ERROR failed to update payload -22 I have attached the patch to fix this payload error, Could you please let me know your feedbacks or inputs on the same please?
https://patchwork.freedesktop.org/series/66837/
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/411.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.