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

[Charles Keepax <ckeepax@opensource.cirrus.com>]

On Thu, Dec 11, 2025 at 04:03:02PM +0530, Vinod Koul wrote:
> On 10-12-25, 14: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:
> > 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.
> 
> What is the typical time to have firmware downloaded and get the irq?

There isn't really an answer to that, it will vary alot based on
the host, the firmware size, the device itself. The timeout we
use to wait for the FDL IRQ in the kernel is currently 100mS, but
that isn't determined by the specification so may need extended
when new hardware arrives. For our device on a MTL UPX, with the
current firmware, and that 100mS timeout, it takes just over 300mS
to complete FDL.

> > 1) Do we really want to support downloading firmware on runtime
> >    suspend? I am doubtful it is really usable due to latency.
> 
> I feel there is no way around. We cant do this async

Obviously agree, if we need to download firmware we have to,
but I think you misunderstand my point. Currently, we don't
have anything that requires this, so why not add support when
we do? I think there is a reasonable chance no one will use the
feature and even if I did add support now, it won't be tested.
Furthermore, there is nothing in the current code that prevents
adding support for this in the future.

> Best is to speed up loading by having firmware cached in the kernel so
> userspace delays can be avoided (unless ofcourse it is humongous size)
> If device needs firmware, we have to download, dont see a choice here

Caching the firmware makes very minimal difference (on my system
pull firmware from user-space takes less than 1% of the time),
the majority of the time is a) spend pumping data through the bus,
b) waiting to ensure are no new FDL IRQs.

> > 2) If we do, do you have any ideas about how to determine if the
> >    device needs firmware?
> 
> Driver should know and first thing in resume, download the firmware,
> maybe a flag in device properties?

Yeah I think that would be about my best guess at how we would
could reduce the impact of this change. We could add a quirk to
say skip runtime download for this device/system. That would mean
new hardware would work albeit a bit sluggishly and established
systems/devices could quirk for a reasonable user-experience. But
I can't say I love that as a solution.

Thanks,
Charles