| Message ID | 20231011114759.1073757-1-chancel.liu@nxp.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | [v3,1/2] ASoC: dt-bindings: sound-card-common: List DAPM endpoints ignoring system suspend | expand |
On Wed, Oct 11, 2023 at 07:47:58PM +0800, Chancel Liu wrote: > + 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. For example on asymmetric multiprocessor, there are Cortex-A I suspect that the DT maintainers would prefer that this description be workshopped a bit to remove the Linux specifics. I think the key thing here is that these are endpoints that can be active over suspend of the main application processor that the current operating system is running (system DT stuff is an interesting corner case here...), and the example is probably a bit specific. Other bindings use "audio sound widgets" rather than "DAPM widgets". We also shouldn't see that these endpoints "should not be disabled" since that implies that they should be left on even if they aren't active which isn't quite the case, instead it's that we can continue playing an audio stream through them in suspend.
On Wed, Oct 11, 2023 at 10:21:33PM +0100, Mark Brown wrote: > On Wed, Oct 11, 2023 at 07:47:58PM +0800, Chancel Liu wrote: > > > + 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. For example on asymmetric multiprocessor, there are Cortex-A > > I suspect that the DT maintainers would prefer that this description be > workshopped a bit to remove the Linux specifics. And Cortex A/M specifics if this is a common binding. > I think the key thing > here is that these are endpoints that can be active over suspend of the > main application processor that the current operating system is running > (system DT stuff is an interesting corner case here...), and the example > is probably a bit specific. Other bindings use "audio sound widgets" > rather than "DAPM widgets". > > We also shouldn't see that these endpoints "should not be disabled" > since that implies that they should be left on even if they aren't > active which isn't quite the case, instead it's that we can continue > playing an audio stream through them in suspend. This seems like one of those things that everyone has/does, and everyone handles it a bit differently. I applaud trying to do something common, but it isn't really common until we have multiple users. Rob
> > I think the key thing > > here is that these are endpoints that can be active over suspend of > > the main application processor that the current operating system is > > running (system DT stuff is an interesting corner case here...), and > > the example is probably a bit specific. Other bindings use "audio sound > widgets" > > rather than "DAPM widgets". > > > > We also shouldn't see that these endpoints "should not be disabled" > > since that implies that they should be left on even if they aren't > > active which isn't quite the case, instead it's that we can continue > > playing an audio stream through them in suspend. > > This seems like one of those things that everyone has/does, and everyone > handles it a bit differently. I applaud trying to do something common, but it > isn't really common until we have multiple users. > > Rob Thanks Mark and Rob for your advice. In fact, it's common use case. We can see many drivers set widgets ignoring suspend. I will remove the linux specifics and focus on the key concept. How about the modification on the property name and description as following: ignore-suspend-widgets: description: | A list of audio sound widgets which are marked ignoring system suspend. Paths between these endpoints are still active over suspend of the main application processor that the current operating system is running. Regards, Chancel Liu
On Mon, Oct 16, 2023 at 12:08:56PM +0000, Chancel Liu wrote: > Thanks Mark and Rob for your advice. In fact, it's common use case. We can see > many drivers set widgets ignoring suspend. I will remove the linux specifics > and focus on the key concept. How about the modification on the property name > and description as following: > ignore-suspend-widgets: > description: | > A list of audio sound widgets which are marked ignoring system suspend. > Paths between these endpoints are still active over suspend of the main > application processor that the current operating system is running. That's probably fine from my point of view. There's likely a better way of saying system suspend but I'm not immediately seeing it and it could always be improved later.
diff --git a/Documentation/devicetree/bindings/sound/sound-card-common.yaml b/Documentation/devicetree/bindings/sound/sound-card-common.yaml index 3a941177f684..f43147c78651 100644 --- a/Documentation/devicetree/bindings/sound/sound-card-common.yaml +++ b/Documentation/devicetree/bindings/sound/sound-card-common.yaml @@ -17,6 +17,20 @@ properties: pair of strings, the first being the connection's sink, the second being the connection's source. + 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. For example 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. LPA requires some audio paths + still enabled when Cortex-A enters into suspend. + model: $ref: /schemas/types.yaml#/definitions/string description: User specified audio sound card name
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. For example 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. LPA requires some audio paths still enabled when Cortex-A enters into suspend. Signed-off-by: Chancel Liu <chancel.liu@nxp.com> --- .../bindings/sound/sound-card-common.yaml | 14 ++++++++++++++ 1 file changed, 14 insertions(+)