All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liam Girdwood <lrg@ti.com>
To: Stephen Warren <swarren@nvidia.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"Mark Brown (broonie@opensource.wolfsonmicro.com)"
	<broonie@opensource.wolfsonmicro.com>
Subject: Re: UCM representation questions
Date: Thu, 26 May 2011 12:02:11 +0100	[thread overview]
Message-ID: <4DDE3333.5010907@ti.com> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF0498A485B6@HQMAIL01.nvidia.com>

On 25/05/11 23:38, Stephen Warren wrote:
> Liam Girdwood wrote at Saturday, May 21, 2011 10:20 AM:
>> On 20/05/11 22:48, Stephen Warren wrote:
>>> I have a few more questions how to represent things in UCM.
>>> ...
>>> The WM8903 can capture from one or the other or AMIC/DMIC, but not both.
>>> ...
>>> How to indicate when certain devices can be used together, or are
>>> mutually exclusive?
>>
>> Atm, I don't think we can do this with devices. We can do it with
>> modifiers though (i.e. a modifier can list it's supported devices). It
>> does sound like a useful feature and probably could be based on the
>> modifier supported device code.
> 
> OK, it looks pretty easy to modify the code to parse and implement
> something like:
> 
> SectionDevice."AMIC".0 {
>     Comment "Analog Microphone Jack"
> 
>     ConflictingDevice [
>         "DMIC",
>         "foo"
>     ]
> ...
> }
> 
> SectionDevice."DMIC".0 {
>     Comment "Internal Digital Microphone"
> 
>     ConflictingDevice [
>         "AMIC"
>     ]
> ...
> }
> 
> Does that look reasonable?

Yes, although does it make more sense using "SupportedDevice" instead ? 

> 
> However, the application is going to want to query these conflict lists,
> and probably a modifier's SupportedDevice list too.
> 
> Should snd_use_case_get be modified to accept a query on e.g.:
> 
> _SupportedDevice/${modifier}
> _ConflictingDevice/${device}
> 
> Both returning say a comma separate list of strings i.e. "DMIC,foo". I
> guess the "get" code could reserve any string starting with "_" for this
> kind of "system" value looking instead of user-defined Value[] lookup.
> 
> How does that sound?
> 

Yeah, this sounds like it would be useful and let the apps know the correct device dependencies.

> If that's good, I'll try to make time to implement this.
> 

Ok, sounds good.

Liam

  reply	other threads:[~2011-05-26 11:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-20 21:48 UCM representation questions Stephen Warren
2011-05-21 16:20 ` Liam Girdwood
2011-05-25 22:38   ` Stephen Warren
2011-05-26 11:02     ` Liam Girdwood [this message]
2011-05-26 17:13       ` Stephen Warren
2011-05-27  1:31         ` Mark Brown
2011-05-27  9:20           ` Liam Girdwood

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=4DDE3333.5010907@ti.com \
    --to=lrg@ti.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=swarren@nvidia.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 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.