| Message ID | 20230925110946.3156100-1-chancel.liu@nxp.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | [v2,1/2] ASoC: dt-bindings: fsl_rpmsg: List DAPM endpoints ignoring system suspend | expand |
On Mon, Sep 25, 2023 at 07:09:45PM +0800, Chancel Liu wrote: > + 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.
> > + 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
On Wed, Sep 27, 2023 at 03:07:49AM +0000, Chancel Liu wrote: > > 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? This is a card problem - the driver for rpmsg shouldn't need to worry about it. Any bindings extensions should be at the card level rather than in a specific driver, we could probably use something in the generic properties that they're all using.
> > > 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? > > This is a card problem - the driver for rpmsg shouldn't need to worry about it. > Any bindings extensions should be at the card level rather than in a specific > driver, we could probably use something in the generic properties that they're > all using. Instead of "fsl,lpa-widgets", I would like to add a common property "ignore-suspend-widgets" in sound-card-common.yaml file. So not only rpmsg sound cards but also other sound cards which have such feature can use this property to define wanted widgets ignoring suspend. What do you think about that? Regards, Chancel Liu
On Sat, Oct 07, 2023 at 11:13:49AM +0000, Chancel Liu wrote: > Instead of "fsl,lpa-widgets", I would like to add a common property > "ignore-suspend-widgets" in sound-card-common.yaml file. So not only rpmsg > sound cards but also other sound cards which have such feature can use this > property to define wanted widgets ignoring suspend. > What do you think about that? We can perhaps bikeshed the name a bit to be more focused on the use case but yes, that sounds reasonable.
diff --git a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml index 188f38baddec..d8fd17615bf2 100644 --- a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml @@ -91,6 +91,21 @@ properties: - rpmsg-audio-channel - rpmsg-micfil-channel + 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. + required: - compatible
Add a property to list 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. Signed-off-by: Chancel Liu <chancel.liu@nxp.com> --- .../devicetree/bindings/sound/fsl,rpmsg.yaml | 15 +++++++++++++++ 1 file changed, 15 insertions(+)