On Mon, Feb 19, 2024 at 11:41:41AM +0100, Johan Hovold wrote: > It seems my initial suspicion that at least some of these regressions > were related to the runtime PM work was correct. The hard resets happens > when the DP controller is runtime suspended after being probed: > [ 17.074925] bus: 'platform': __driver_probe_device: matched device aea0000.displayport-controller with driver msm-dp-display > [ 17.112000] msm-dp-display aea0000.displayport-controller: dp_display_probe - populate aux bus > [ 17.125208] msm-dp-display aea0000.displayport-controller: dp_pm_runtime_resume > [ 17.197909] msm-dp-display aea0000.displayport-controller: dp_pm_runtime_suspend > [ 17.198079] probe of aea0Format: Log Type - Time(microsec) - Message - Optional Info > Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic > S - QC_IMAGE_VERSION_STRING=BOOT.MXF.1.1-00470-MAKENA-1 > S - IMAGE_VARIANT_STRING=SocMakenaWP > S - OEM_IMAGE_VERSION_STRING=crm-ubuntu92 > > < machine is reset by hypervisor > > > Presumably the reset happens when controller is being shut down while > still being used by the EFI framebuffer. > > In the cases where the machines survives boot, the controller is never > suspended. > > When investigating this I've also seen intermittent: > > [drm:dp_display_probe [msm]] *ERROR* device tree parsing failed Note that there are further indications there may be more than one bug here too. I definitely see hard resets when dp_pm_runtime_suspend() is shutting down the eDP PHY, but there are occasional resets also if I instrument DP controller probe() to resume and then prevent the controller from suspending until after a timeout (e.g. to be used as a temporary workaround): [ 15.676495] bus: 'platform': __driver_probe_device: matched device aea0000.displayport-controller with driver msm-dp-display [ 15.769392] msm-dp-display aea0000.displayport-controller: dp_display_probe - populate aux bus [ 15.778808] msm-dp-display aea0000.displayport-controller: dp_display_probe - scheduling handover [ 15.789931] probe of aea0000.displayport-controller returned 0 after 91121 usecs [ 15.790460] bus: 'dp-aux': __driver_probe_device: matched device aux-aea0000.displayport-controller with driver panel-simple-dp-aux Format: Log Type - Time(microsec) - Message - Optional Info Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic S - QC_IMAGE_VERSION_STRING=BOOT.MXF.1.1-00470-MAKENA-1 I'll wait for the maintainers and authors of this code to comment, but it seems the runtime PM work is broken in multiple ways. Johan
