There are two cases here.
1> Controller Instance support ClockStop Mode0, we mostly use the generic core to do that except in resume path we make sure that we start the clock.
2> Controller Instances which that do not support ClockStop, we do soft reset of controller along with hard resetting slaves.
both are fine. we have similar cases defined in sdw_intel.h
+static int swrm_runtime_resume(struct device *dev) +{ + struct qcom_swrm_ctrl *ctrl = dev_get_drvdata(dev); + int ret;
+ clk_prepare_enable(ctrl->hclk);
+ if (ctrl->clk_stop_bus_reset) { + reinit_completion(&ctrl->enumeration); + ctrl->reg_write(ctrl, SWRM_COMP_SW_RESET, 0x01); + qcom_swrm_get_device_status(ctrl);
don't you need some sort of delay before checking the controller and device status? The bus reset sequence takes 4096 bits, that's a non-zero time.
This is soft reset not full Bus Reset as WSA slaves have hard reset pins that will be toggled as part of suspend-resume.
Above you mentioned the peripherals go through a reset as well, in which case they can only re-attach on the bus after 16 frames best case - they need to observe a full cycle of the dynamic sync before changing status.
That's still a non-zero delay (0.3ms for a 48kHz frame rate)
+ sdw_handle_slave_status(&ctrl->bus, ctrl->status); + qcom_swrm_init(ctrl);