alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Jaroslav Kysela <perex@perex.cz>
Cc: oder_chiou@realtek.com, jack.yu@realtek.com,
	alsa-devel@alsa-project.org, lars@metafoo.de,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	lgirdwood@gmail.com, derek.fang@realtek.com, bard.liao@intel.com,
	shumingf@realtek.com, flove@realtek.com,
	pierre-louis.bossart@intel.com
Subject: Re: [PATCH v2] ASoC: rt1316: Add RT1316 SDCA vendor-specific driver
Date: Mon, 22 Feb 2021 13:35:44 +0000	[thread overview]
Message-ID: <20210222133544.GA6127@sirena.org.uk> (raw)
In-Reply-To: <37e136a7-01de-412a-6527-e3b6b6038de1@perex.cz>

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

On Sat, Feb 20, 2021 at 06:55:06PM +0100, Jaroslav Kysela wrote:

> The problem with ASoC tree is that many of those controls are not supposed to
> be configured/used by the end user, but in UCM or other higher level layer
> configuration, because they're a part of the hw/driver setup.

> I think that we should classify those controls so the standard user space
> tools can hide them, but it's another problem.

Well, as has been discussed in the past ideally ALSA would have a
mechanism for exposing topology information and userspace would have
some chance of picking which controls make sense for use on non-trivial
hardware.  The particular set of controls that it makes sense to adjust
from userspace is going to vary depending on the use case, it's not
something that can be decided in the kernel.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2021-02-22 13:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-18  9:12 [PATCH v2] ASoC: rt1316: Add RT1316 SDCA vendor-specific driver shumingf
2021-02-18  9:44 ` Jaroslav Kysela
2021-02-18 14:49   ` Pierre-Louis Bossart
2021-02-20 17:55     ` Jaroslav Kysela
2021-02-22 13:35       ` Mark Brown [this message]
2021-02-22 15:48       ` Pierre-Louis Bossart

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=20210222133544.GA6127@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=bard.liao@intel.com \
    --cc=derek.fang@realtek.com \
    --cc=flove@realtek.com \
    --cc=jack.yu@realtek.com \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=oder_chiou@realtek.com \
    --cc=perex@perex.cz \
    --cc=pierre-louis.bossart@intel.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=shumingf@realtek.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).