> > + fsl,lpa-widgets: > > + $ref: /schemas/types.yaml#/definitions/non-unique-string-array > > + description: | > > + A list of DAPM endpoints which mark paths between these > endpoints should > > + not be disabled when system enters in suspend state. LPA means low power > > + audio case. On asymmetric multiprocessor, there are Cortex-A core > and > > + Cortex-M core, Linux is running on Cortex-A core, RTOS or other OS is > > + running on Cortex-M core. The audio hardware devices can be > controlled by > > + Cortex-M. LPA can be explained as a mechanism that Cortex-A > allocates a > > + large buffer and fill audio data, then Cortex-A can enter into suspend > > + for the purpose of power saving. Cortex-M continues to play the > sound > > + during suspend phase of Cortex-A. When the data in buffer is > consumed, > > + Cortex-M will trigger the Cortex-A to wakeup to fill data. LPA > requires > > + some audio paths still enabled when Cortex-A enters into suspend. > > This is a fairly standard DSP playback case as far as I can see so it > should work with DAPM without needing this obviously use case specific > stuff peering into the Linux implementation. Generally this is done by > tagging endpoint widgets and DAIs as ignore_suspend, DAPM will then > figure out the rest of the widgets in the path. Yes, indeed I meant to let driver get DAPM endpoints from the "fsl,lpa-widgets" property and then set these endpoints as ignore_suspend if the sound card is running in this use case. Do you think the description for the use case can be simplified since it's a common use case? Regards, Chancel Liu
