All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Takashi Iwai <tiwai@suse.de>
Cc: Jeremy McDermond <mcdermj@xenotropic.com>, alsa-devel@alsa-project.org
Subject: Re: ASoC: Machine Driver Interaction with Codec Drivers
Date: Thu, 9 Jun 2016 12:31:12 +0200	[thread overview]
Message-ID: <57594570.7020100@metafoo.de> (raw)
In-Reply-To: <s5hinxihetz.wl-tiwai@suse.de>

On 06/09/2016 11:49 AM, Takashi Iwai wrote:
> On Wed, 08 Jun 2016 21:14:01 +0200,
> Lars-Peter Clausen wrote:
>>
>> Hi,
>>
>> No this is currently not really supported. There were some ideas for this a
>> long long time ago, but it never got implemented. And today basically
>> everybody takes care of hiding the controls from userspace.
>>
>> That does not mean it does not make sense to have such a feature, but it
>> needs somebody with a motivation to implement it.
> 
> The devils live in details.  Actually a primary question is in which
> level we should cover it.  For example, can we disable DAPM pins from
> the machine driver?  This will reduce not only kctls but DAPM paths.
> Or should we mark kctls just as invisible?  Or, would it be suitable
> rather to hide such a thing in user-space?

For DAPM we already do this. Even automatically the DAPM core is capable of
figuring out which paths are unused and will never be powered-up. The path
will still exist in the graph but it will be ignored for all operations and
not significantly affect performance.

And I think the idea back then was to track which controls are on which
paths and if it is on a non-connected path disable the control. What's a bit
tricky is if you have a mixer or mux and only some of the output/input paths
are not connected. Also for most controls we do not have the information
where they are placed within the graph.

  reply	other threads:[~2016-06-09 10:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-08  3:13 ASoC: Machine Driver Interaction with Codec Drivers Jeremy McDermond
2016-06-08 19:14 ` Lars-Peter Clausen
2016-06-09  9:49   ` Takashi Iwai
2016-06-09 10:31     ` Lars-Peter Clausen [this message]
2016-06-10  4:07     ` Vinod Koul
2016-06-13 21:37   ` Jeremy McDermond
2016-06-14  8:35     ` Lars-Peter Clausen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57594570.7020100@metafoo.de \
    --to=lars@metafoo.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=mcdermj@xenotropic.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.