diff mbox series

[v3,1/2] ASoC: dt-bindings: sound-card-common: List DAPM endpoints ignoring system suspend

Message ID 20231011114759.1073757-1-chancel.liu@nxp.com (mailing list archive)
State New, archived
Headers show
Series [v3,1/2] ASoC: dt-bindings: sound-card-common: List DAPM endpoints ignoring system suspend | expand

Commit Message

Chancel Liu Oct. 11, 2023, 11:47 a.m. UTC
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(+)

Comments

Mark Brown Oct. 11, 2023, 9:21 p.m. UTC | #1
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.
Rob Herring (Arm) Oct. 12, 2023, 8:47 p.m. UTC | #2
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
Chancel Liu Oct. 16, 2023, 12:08 p.m. UTC | #3
> >  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
Mark Brown Oct. 16, 2023, 1:17 p.m. UTC | #4
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 mbox series

Patch

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