> 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);
