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.
