From: Patrick Lai <plai@codeaurora.org>
To: Tanu Kaskinen <tanuk@iki.fi>
Cc: alsa-devel <alsa-devel@alsa-project.org>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
Liam Girdwood <lrg@ti.com>
Subject: Re: ucm: hardware resource arbitration
Date: Wed, 12 Sep 2012 15:51:15 -0700 [thread overview]
Message-ID: <505111E3.9090506@codeaurora.org> (raw)
In-Reply-To: <1347458022.6888.31.camel@laptop>
On 9/12/2012 6:53 AM, Tanu Kaskinen wrote:
> On Mon, 2012-09-10 at 23:49 -0700, Patrick Lai wrote:
>> Hi,
>>
>> I have two use cases which can acquire same CODEC path but they cannot
>> run concurrently through mixing. When such scenario does arise,
>> arbitration is required based on priority of use cases. On the other
>> hand, same use cases on different platform may use different CODEC
>> paths so arbitration is not required. In order to decide whether
>> arbitration is required, I think the best place to do so is in UCM. I
>> looked at existing UCM APIs but I do not believe existing APIs have
>> concept of arbitration built in. If I am wrong, how can I handle
>> arbitration with existing UCM APIs. If I am correct, is there anyone
>> looking to expand UCM APIs for similar scenario?
>
> In my opinion routing priorities don't belong in the UCM configuration.
> UI designers will want to dictate the routing policy (i.e. what device
> to prefer in which use case).
Thanks for your feedback. Actually, I am not looking at routing policy
in term of preferred device for a given use case. I agree that
something above alsa/ucm should decide. My problem is two use cases
cannot co-exist on certain platforms but not on the others. Two use
cases are coming from two SW entities which are not aware of each other
but they all talk to UCM for hardware configuration. Each SW entity
decides its own use case and preferred device. Please correct me if I am
wrong. UCM is designed to abstract hardware configuration detail. So, it
seems appropriate to me that UCM can contain information about the use
cases a given platform can support/not support concurrently. Since
UCM(assuming it's singleton) is the entity that has visibility to all
use cases exercised by all SW entities, It makes sense to me to have UCM
notify clients if its use case is to be preempted. Even if we want to
create a resource manager on top of UCM for two SW entities to
communicate, does UCM already have API allowing client to know its use
case is a go or no go?
Thanks
Patrick
The same hardware may end up being used in
> different products, and the UI designers for those different products
> may not all want the same policy. Therefore, I don't want UCM
> configurations to include any routing policy. The policy configuration
> belongs to some component that sits above alsa and UCM.
>
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2012-09-12 22:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-11 6:49 ucm: hardware resource arbitration Patrick Lai
2012-09-12 13:53 ` Tanu Kaskinen
2012-09-12 22:51 ` Patrick Lai [this message]
2012-09-16 6:40 ` Tanu Kaskinen
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=505111E3.9090506@codeaurora.org \
--to=plai@codeaurora.org \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=lrg@ti.com \
--cc=tanuk@iki.fi \
/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).