Re: [alsa-devel] [PATCH v2 3/5] ASoC: core: add support to snd_soc_dai_get_sdw_stream()

[Pierre-Louis Bossart]

On 10/9/19 11:01 AM, Srinivas Kandagatla wrote:
> On 09/10/2019 15:29, Pierre-Louis Bossart wrote:
> > On 10/9/19 3:32 AM, Srinivas Kandagatla wrote:
> > > Hi Pierre,
> > >
> > > On 14/08/2019 15:09, Pierre-Louis Bossart wrote:
> > > > On 8/13/19 11:11 PM, Vinod Koul wrote:
> > > > > On 13-08-19, 20:58, Mark Brown wrote:
> > > > > > On Tue, Aug 13, 2019 at 02:38:53PM -0500, Pierre-Louis Bossart wrote:
> > > > > >
> > > > > > > Indeed. I don't have a full understanding of that part to be 
> > > > > > > honest, nor why
> > > > > > > we need something SoundWire-specific. We already abused the 
> > > > > > > set_tdm_slot API
> > > > > > > to store an HDaudio stream, now we have a rather confusing stream
> > > > > > > information for SoundWire and I have about 3 other 'stream' 
> > > > > > > contexts in
> > > > > > > SOF... I am still doing basic cleanups but this has been on my 
> > > > > > > radar for a
> > > > > > > while.
> > > > > >
> > > > > > There is something to be said for not abusing the TDM slot API if 
> > > > > > it can
> > > > > > make things clearer by using bus-idiomatic mechanisms, but it does 
> > > > > > mean
> > > > > > everything needs to know about each individual bus :/ .
> > > > >
> > > > > Here ASoC doesn't need to know about sdw bus. As Srini explained, this
> > > > > helps in the case for him to get the stream context and set the stream
> > > > > context from the machine driver.
> > > > >
> > > > > Nothing else is expected to be done from this API. We already do a set
> > > > > using snd_soc_dai_set_sdw_stream(). Here we add the 
> > > > > snd_soc_dai_get_sdw_stream() to query
> > > >
> > > > I didn't see a call to snd_soc_dai_set_sdw_stream() in Srini's code?
> > >
> > >
> > > There is a snd_soc_dai_get_sdw_stream() to get stream context and we 
> > > add slave streams(amplifier in this case) to that context using 
> > > sdw_stream_add_slave() in machine driver[1].
> > >
> > > Without this helper there is no way to link slave streams to stream 
> > > context in non dai based setup like smart speaker amplifiers.
> > >
> > > Currently this driver is blocked on this patch, If you think there 
> > > are other ways to do this, am happy to try them out.
> >
> > So to be clear, you are *not* using snd_soc_dai_set_sdw_stream?
> Yes, am not using snd_soc_dai_set_sdw_stream().

It's been a while since this thread started, and I still don't quite get 
the concepts or logic.

First, I don't understand what the problem with "aux" devices is. All 
the SoundWire stuff is based on the concept of DAI, so I guess I am 
missing why introducing the "aux" device changes anything.

Next, a 'stream' connects multiple DAIs to transmit information from 
sources to sinks. A DAI in itself is created without having any notion 
of which stream it will be associated with. This can only be done with 
machine level information.

If you query a DAI to get a stream context, then how is this stream 
context allocated in the first place? It looks like a horse and cart 
problem. Or you are assuming that a specific DAI provides the context, 
and that all other DAIs do not expose this .get_sdw_stream()? What if 
more that 1 DAI provide a stream context?

And last, I am even more lost since w/ the existing codec drivers we 
have, sdw_stream_add_slave() is called from the dai .hw_params callback, 
once you have information on formats/rates, etc. using 
sdw_stream_add_slave() from a machine driver looks like an even bigger 
stretch. I really thought the machine driver would only propagate the 
notion of stream to all DAIs that are part of the same dailink.

I am not trying to block the Qualcomm implementation, just would like to 
make sure the assumptions are clear and that we are not using the same 
API in completely different ways.