Re: [PATCH 5/7] ASoC: SDCA: Add basic system suspend support

[Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>]

On 12/10/25 15:43, Charles Keepax wrote:
> On Tue, Dec 09, 2025 at 12:11:27PM +0000, Pierre-Louis Bossart wrote:
>> On 11/25/25 15:21, Charles Keepax wrote:
>>> Add basic system suspend support. Disable the IRQs and force runtime
>>> suspend, during system suspend, because the device will likely fully
>>> power down during suspend.
>>
>> Power-down during system suspend (seems natural) or power-down
>> during pm_runtime suspend (depends on what the host does during
>> clock_stop)?
> 
> At the moment this is written to support FDL after system
> suspend only. Which is fairly typical of most devices I have seen
> (Cirrus and non-Cirrus). Generally as runtime suspends happen
> so often it is preferred not to download firmware there due to
> time constraints.
> 
> This is definitely up for debate, my primary issue with allowing
> firmware download at the runtime level is that SDCA gives you no
> way to tell that the device is ready to rock. The only way I have
> been able to divine to do this is to wait for an FDL irq and if
> one doesn't come within a reasonable time out move on. However,
> that waiting would add a considerable delay to runtime resume
> even if no firmware was downloaded, which feels problematic.
> 
> I guess my two questions would be:
> 1) Do we really want to support downloading firmware on runtime
>    suspend? I am doubtful it is really usable due to latency.
> 2) If we do, do you have any ideas about how to determine if the
>    device needs firmware?

It depends what happens during runtime suspend at the host level.

In the case where the host issues a BUS_RESET even during pm_runtime resume, you will have to re-initialize the device completely, no?

If the runtime suspend only does a clock stop, then presumably there's nothing to do on resume on the device side, i.e. no firmware to reload.