From: jassi brar <jassisinghbrar@gmail.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: ALSA development <alsa-devel@alsa-project.org>,
Timur Tabi <timur@freescale.com>,
Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: asoc: problem with snd_soc_dai_set_fmt()
Date: Fri, 30 Apr 2010 10:28:57 +0900 [thread overview]
Message-ID: <r2m1b68c6791004291828p77188d3frcb7ef516823e0477@mail.gmail.com> (raw)
In-Reply-To: <20100429221808.GB23958@opensource.wolfsonmicro.com>
On Fri, Apr 30, 2010 at 7:18 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Thu, Apr 29, 2010 at 04:22:17PM -0500, Timur Tabi wrote:
>> int snd_soc_dai_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
>> {
>> if (dai->driver && dai->driver->ops->set_fmt)
>> return dai->driver->ops->set_fmt(dai, fmt);
>> else
>> return 0;
>> }
>
> Due to the above issue I don't think this is a good idea - we really
> ought to let the machine driver know if the request it made was ignored
> in case it is trying to set up something that can't be supported.
> Another short term option would be to change the error code to be
> something a bit more distinctive than -EINVAL. If we want to support
> very generic machine drivers that genuinely don't know what hardware is
> able to do I think we'd be be better off doing something like adding
> capability masks to the drivers so these functions can validate what
> they're being asked to do, at which point we know the actual format so
> returning 0 isn't an issue.
>
> The current expectation is that the machine driver knows what the
> hardware is capable of and won't try to set anything silly, in the case
> of fixed format devices that don't implement set_fmt() that consists of
> just not calling set_fmt() for the DAI at all.
Though I am ok with the status quo -- snd_soc_dai_ops members being
truly optional and machine driver writers knowing both the DAIs and calling
only appropriate functions, but if we are to move to more generic machine
drivers how about hiding such members of snd_soc_dai_ops from machine
drivers and let the machine drivers specify the exact requirement to ASoC
via some generic enough data structure. Part of that configuration can be
done by ASoC while the platform specific stuff passed onto DAI drivers.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2010-04-30 1:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-29 21:22 asoc: problem with snd_soc_dai_set_fmt() Timur Tabi
2010-04-29 22:18 ` Mark Brown
2010-04-29 23:30 ` Timur Tabi
2010-04-30 10:37 ` Mark Brown
2010-04-30 1:28 ` jassi brar [this message]
2010-04-30 8:58 ` Mark Brown
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=r2m1b68c6791004291828p77188d3frcb7ef516823e0477@mail.gmail.com \
--to=jassisinghbrar@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=lrg@slimlogic.co.uk \
--cc=timur@freescale.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).