[v2,05/12] ASoC: doc: dapm: clarify it's an internal API

Commit Message

Luca Ceresoli April 26, 2024, 4:56 p.m. UTC

Clarify DAPM does not expose any API to user space, and adapt the paragraph
accordingly.

Reviewed-by: Alexandre Belloni <[e-mail]>
Reviewed-by: Bagas Sanjaya <[e-mail]>
Signed-off-by: Luca Ceresoli <[e-mail]>
---
 Documentation/sound/soc/dapm.rst | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

Comments

Mark Brown April 29, 2024, 2:42 p.m. UTC | #1

On Fri, Apr 26, 2024 at 06:56:38PM +0200, Luca Ceresoli wrote:

> Clarify DAPM does not expose any API to user space, and adapt the paragraph
> accordingly.

That's not strictly true, there's a couple of sysfs tuneables and all
the routing is via userspace controls plus we've got stuff like pin
switches.

Patch

diff --git a/Documentation/sound/soc/dapm.rst b/Documentation/sound/soc/dapm.rst
index be849879274d..f96a32f137aa 100644
--- a/Documentation/sound/soc/dapm.rst
+++ b/Documentation/sound/soc/dapm.rst
@@ -11,9 +11,10 @@  subsystem at all times. It is independent of other kernel power
 management frameworks and, as such, can easily co-exist with them.
 
 DAPM is also completely transparent to all user space applications as
-all power switching is done within the ASoC core. No code changes or
-recompiling are required for user space applications. DAPM makes power
-switching decisions based upon any audio stream (capture/playback)
+all power switching is done internally to the ASoC core. For this reason
+DAPM does not expose a kernel API to user space and no code changes or
+recompiling are required for user space applications to use it. DAPM makes
+power switching decisions based upon any audio stream (capture/playback)
 activity and audio mixer settings within the device.
 
 DAPM spans the whole machine. It covers power control within the entire