Re: [EXT] Re: Re: [PATCH v2 1/2] ASoC: dt-bindings: fsl_rpmsg: List DAPM endpoints ignoring system suspend
On Sat, Oct 07, 2023 at 11:13:49AM +, 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. signature.asc Description: PGP signature
RE: [EXT] Re: Re: [PATCH v2 1/2] ASoC: dt-bindings: fsl_rpmsg: List DAPM endpoints ignoring system 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? > > 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
Re: Re: [PATCH v2 1/2] ASoC: dt-bindings: fsl_rpmsg: List DAPM endpoints ignoring system suspend
On Wed, Sep 27, 2023 at 03:07:49AM +, 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. signature.asc Description: PGP signature
RE: Re: [PATCH v2 1/2] ASoC: dt-bindings: fsl_rpmsg: List DAPM endpoints ignoring system suspend
> > + 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
Re: [PATCH v2 1/2] ASoC: dt-bindings: fsl_rpmsg: List DAPM endpoints ignoring system suspend
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. signature.asc Description: PGP signature
