Re: ASoC:Question rate constraint between the dais

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2257 bytes --]

On Sat, Mar 17, 2012 at 03:49:06PM -0400, Trent Piepho wrote:
> On Sat, Mar 17, 2012 at 7:48 AM, Mark Brown
> > On Fri, Mar 16, 2012 at 06:01:44PM -0400, Trent Piepho wrote:

> > > Since the constraint is based on the current configuration of another
> > > DAI, the two DAIs need some way to query each other's parameters.  The

> > Since they're both provided by the same driver this is trivial.

> It's not that trivial with the sub-streams in question aren't in the
> same instance of the driver, e.g. playback and record.  Say you had

It's very easy to go back from the DAI to the CODEC, there's a direct
pointer.

> two WM8988 codecs, how does one codec get a handle to the other?

Such a constraint would be machine imposed, not CODEC imposed - the case
the Intel guys were talking about was a constraint between the two
interfaces on a single CODEC.  There's no way the driver for one CODEC
should be doing anything about another CODEC.

> There's no global list of codecs in the driver, so you have to add
> something like that. Or change the device tree binding to give the

You're talking about a totally different use case here, there's way more
issues than just the constraints getting multiple CODECs on the same
link to play nicely.  

> slave codec a phandle to the master codec.

No, that wouldn't be sensible - this should all be handled at the DAI
level.  Adding explicit code in individual CODEC drivers for this would
be an awful lot of duplication.

> Does PulseAudio handle it if hw_params fails?  From what I've seen,
> most applications just fail if hw_params fails.

I've no idea what PulseAudio does; I suppose someone who's interested
could look at the code.  Most applications do just fail, like I say it's
exceptionally rare to hit any of thist stuff.

> are in state >= SETUP, verify that the hw_params are still valid and
> if not, update the constraints and return an error.  But it is not
> until line 455 that the substream has actually finished getting the

So long as the driver takes care that only one of multiple concurrent
hw_params() calls manages to successfully return we should be fine, once
the hw_params() call has returned we're committed to flagging success.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]