All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: jassi brar <jassisinghbrar@gmail.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 09:58:45 +0100	[thread overview]
Message-ID: <20100430085845.GC28241@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <r2m1b68c6791004291828p77188d3frcb7ef516823e0477@mail.gmail.com>

On Fri, Apr 30, 2010 at 10:28:57AM +0900, jassi brar wrote:
> On Fri, Apr 30, 2010 at 7:18 AM, Mark Brown

> > 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.

...

> 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.

Yes, the capability information I suggested above would be required to
implement such a thing.  It does need to be very much optional, though,
to allow room for more complex systems.

      reply	other threads:[~2010-04-30  8:58 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
2010-04-30  8:58     ` Mark Brown [this message]

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=20100430085845.GC28241@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=jassisinghbrar@gmail.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 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.