question on snd_soc_dai_link_event

question on snd_soc_dai_link_event

[Sebastien LEDUC]

Hi,
I have one question about current implementation of function snd_soc_dai_link_event
Currently, on power up, it calls hw_params on the source and sink dai drivers, and digital_mute(0) on the sink dai driver

I wonder why it does not call the full hw_params / prepare / trigger sequence on both dai drivers to start the 2 DAIs.

Thanks in advance
Regards,
Sebastien 

Re: question on snd_soc_dai_link_event

[Mark Brown]

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

On Fri, Oct 26, 2012 at 01:58:54PM +0200, Sebastien LEDUC wrote:

Fix your mailer to word wrap within paragraphs, it makes your mails hard
to read if you don't do this.  I've reflowed for legibility.

> I wonder why it does not call the full hw_params / prepare / trigger
> sequence on both dai drivers to start the 2 DAIs.

None of the drivers that use this actually have any of those calls so I
didn't bother.  Especially in the case of trigger it's unlikely that an
off-SoC device without DMA would need this, though of course it could
happen.

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

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

Re: question on snd_soc_dai_link_event

[Sebastien LEDUC]

Hi Mark

One further question on the dai_link widget mechanism.

Currently the code in soc_probe_link_dais, the code will call snd_soc_dapm_new_pcm
to create the dai_link widget and the routes.

For a capture stream, it creates the following routes:
Cpu_dai widget -> dai_link widget -> codec_dai widget

And for a playback stream:
Codec_dai widget -> dai_link widget -> cpu_dai widget

Shouldn't it be the opposite directions in both cases?
Or did I miss something?

Thanks
Regards
Sebastien

Re: question on snd_soc_dai_link_event

[Mark Brown]

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

On Wed, Nov 21, 2012 at 06:56:55PM +0100, Sebastien LEDUC wrote:

> For a capture stream, it creates the following routes:
> Cpu_dai widget -> dai_link widget -> codec_dai widget

> And for a playback stream:
> Codec_dai widget -> dai_link widget -> cpu_dai widget

Remember that for a CODEC<->CODEC link both devices will be CODECs so
their widgets have the opposite sense as everything is named in a CPU
centric fashion.  The important thing is that we link playback to
capture and capture to playback.

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

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

Re: question on snd_soc_dai_link_event

[Sebastien LEDUC]

Hi Mark,
Coming back on this topic:
We are trying to use the codec <-> codec approach to model our 
on-SoC DSP. 
So in our case it would be quite important that the full sequence
of ops is called, so that we are not dependent on which ops the codec
we use is relying on.

I am even thinking that it could be worth creating an internal PCM 
for the  dai link that has the params field, and to call the standard
soc functions (soc_pcm_open, ...) on it from the dai_link widget DAPM 
callback to start / stop the PCM.

Any feedback?

Thanks
Regards
Sebastien

> -----Original Message-----
> From: Mark Brown [mailto:broonie@opensource.wolfsonmicro.com]
> Sent: Friday, October 26, 2012 7:02 PM
> To: Sebastien LEDUC
> Cc: alsa-devel@alsa-project.org; Liam Girdwood (lrg@ti.com)
> Subject: Re: question on snd_soc_dai_link_event
> 
> On Fri, Oct 26, 2012 at 01:58:54PM +0200, Sebastien LEDUC wrote:
> 
> Fix your mailer to word wrap within paragraphs, it makes your mails hard
> to read if you don't do this.  I've reflowed for legibility.
> 
> > I wonder why it does not call the full hw_params / prepare / trigger
> > sequence on both dai drivers to start the 2 DAIs.
> 
> None of the drivers that use this actually have any of those calls so I
> didn't bother.  Especially in the case of trigger it's unlikely that an
> off-SoC device without DMA would need this, though of course it could
> happen.

Re: question on snd_soc_dai_link_event

[Mark Brown]

On Fri, Jan 18, 2013 at 03:07:29PM +0100, Sebastien LEDUC wrote:

Once again, don't top post.

> I am even thinking that it could be worth creating an internal PCM 
> for the  dai link that has the params field, and to call the standard
> soc functions (soc_pcm_open, ...) on it from the dai_link widget DAPM 
> callback to start / stop the PCM.

> Any feedback?

I think what's important here is that any resulting code looks sane and
works well; I'm not sure that going all the way up the stack is going to
help with that as you're more likely to expose assumptions about the
calling environment but I've not paid it much concrete attention.