All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	vkoul@kernel.org, yung-chuan.liao@linux.intel.com
Cc: gregkh@linuxfoundation.org, sanyog.r.kale@intel.com,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] soundwire: add support for static port mapping
Date: Fri, 22 Jan 2021 10:42:36 -0600	[thread overview]
Message-ID: <adb91730-35db-db7a-75b3-4771723de945@linux.intel.com> (raw)
In-Reply-To: <e962caa8-89c3-4a22-5932-4498c406e8f8@linaro.org>


>> No, what I was saying is that you need to define multiple streams e.g.
>> - headset capture (configured with or without click suppression)
>> - mic capture (configured with AMICs or DMICs)
>> - playback (or possibly different endpoint specific streams depending 
>> on whether concurrency between endpoint is possible)
>>
>> if you change the configuration, you have to tear down the stream and 
>> reconfigure it - and for this we already have the required API and you 
>> can guarantee that the configuration for that stream is consistent 
>> between master and slave(s).
> 
> Yes, we make sure that new configuration is only applied before the 
> stream is started, and not in middle of already started stream.

ok, we are almost in agreement but...

>>> All am saying is that codec can decide which ports it has to select 
>>> based on mixer setting before the stream is setup/started. This 
>>> updated mapping between slv port and master ports is passed as part 
>>> of the port_config in sdw_stream_add_slave().
>>
>> if you completely remove the stream and re-add it with updated 
>> configuration things should work.
> 
> That's exactly what we do currently!
> 
> The updated ports due to new configuration ex: for "mic capture" dailink 
> needs to be communicated from slave(codec) to master so that it can 
> allocate correct ports. That is what this patch is trying to do (share 
> current port map information).

.. we have a disconnect on how to do this configuration update.

The 'stream' support was designed so that a stream can be split across 
multiple devices (both masters and slaves). With this design we need to 
have a central configuration and distribute the information to all 
devices taking part of the stream.

It seems you are in a different solution-space, where the codec driver 
needs to notify the master of which ports it needs to use?

I also don't see where the mapping is actually set. Patch 2 uses a 
mapping but there's no codec driver change that defines the mapping?

Do you actually call sdw_stream_add_slave() with a new mapping?

It feels we are missing the codec part to really see what you are trying 
to do?


  reply	other threads:[~2021-01-22 17:03 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20 18:01 [RFC PATCH 0/2] soundwire: add static port mapping support Srinivas Kandagatla
2021-01-20 18:01 ` Srinivas Kandagatla
2021-01-20 18:01 ` [RFC PATCH 1/2] soundwire: add support for static port mapping Srinivas Kandagatla
2021-01-20 18:01   ` Srinivas Kandagatla
2021-01-20 22:15   ` Pierre-Louis Bossart
2021-01-20 22:15     ` Pierre-Louis Bossart
2021-01-21 11:35     ` Srinivas Kandagatla
2021-01-21 11:35       ` Srinivas Kandagatla
2021-01-21 14:56       ` Pierre-Louis Bossart
2021-01-21 15:41         ` Srinivas Kandagatla
2021-01-21 18:00           ` Pierre-Louis Bossart
2021-01-21 18:41             ` Srinivas Kandagatla
2021-01-21 21:30               ` Pierre-Louis Bossart
2021-01-22  7:05                 ` Srinivas Kandagatla
2021-01-22 15:32                   ` Pierre-Louis Bossart
2021-01-22 15:46                     ` Srinivas Kandagatla
2021-01-22 16:42                       ` Pierre-Louis Bossart [this message]
2021-01-25 16:23                         ` Srinivas Kandagatla
2021-02-01 10:27                           ` Vinod Koul
2021-02-01 10:27                             ` Vinod Koul
2021-02-19 10:35                             ` Srinivas Kandagatla
2021-02-19 10:35                               ` Srinivas Kandagatla
2021-02-19 19:52                               ` Pierre-Louis Bossart
2021-02-19 19:52                                 ` Pierre-Louis Bossart
2021-02-22 13:40                                 ` Srinivas Kandagatla
2021-02-22 13:40                                   ` Srinivas Kandagatla
2021-01-20 18:01 ` [RFC PATCH 2/2] soundwire: qcom: " Srinivas Kandagatla
2021-01-20 18:01   ` Srinivas Kandagatla

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=adb91730-35db-db7a-75b3-4771723de945@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sanyog.r.kale@intel.com \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=vkoul@kernel.org \
    --cc=yung-chuan.liao@linux.intel.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.