linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	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: Thu, 21 Jan 2021 15:41:23 +0000	[thread overview]
Message-ID: <c6278763-57d9-2631-7b43-829259a9ea1f@linaro.org> (raw)
In-Reply-To: <9a688b02-80a6-fb1f-d6fa-36ba2d88d3b9@linux.intel.com>



On 21/01/2021 14:56, Pierre-Louis Bossart wrote:
> 
> 
>> Port allocations are something like this:
>>
>> RX: (Simple)
>> Port 1 -> HPH L/R
>> Port 2 -> CLASS H Amp
>> Port 3 -> COMP
>> Port 4 -> DSD.
>>
>> TX: (This get bit more complicated)
>> Port 1: PCM
>> Port 2: ADC 1 & 2
>> Port 3: ADC 3 & 4
>> Port 4: DMIC-0, DMIC-1, DIMC-2 , DMIC-3 and MBHC
>> Port 5: DMIC-4, DMIC-5, DMIC-6 and DMIC-7
>>
>> We handle the port allocation dynamically based on mixer and dapm 
>> widgets in my code! Also channel allocations are different for each 
>> function!
> 
> Sorry, I am not following here. What is dynamic here and use-case 
> dependent? And is this a mapping on the master or the codec sides that 
> you want to modify?

[SLAVE]-------[MASTER]
NA-------------Port 1: PCM
Port 1---------Port 2: ADC 1 & 2
Port 2---------Port 3: ADC 3 & 4
Port 3---------Port 4: DMIC-0, DMIC-1, DIMC-2 , DMIC-3 and MBHC
Port 4---------Port 5: DMIC-4, DMIC-5, DMIC-6 and DMIC-7


Mapping is still static however Number of ports selection and channel 
mask will be dynamic here.


Example: for Headset MIC usecase we will be using Slv Port1, Slv Port3 
along with Mstr Port2 and Master Port4

Similarly for usecases like Digital MIC or other Analog MICs.


> 
>>> Does this help and can you align on what Intel started with?
>>
>> Firstly, This is where the issue comes, if we go with the 
>> suggested(dai->id) solution, we would end up with a long list of 
>> dai-links with different combinations of both inputs/output 
>> connections and usecases. Again we have to deal with limited DSP 
>> resources too!
>>
>> Secondly, The check [1] in stream.c will not allow more than one 
>> master port config to be added to master runtime. Ex: RX Port 1, 2, 3 
>> is used for Headset Playback.
> 
> I am confused here, we do have examples in existing codec drivers where 
> we use multiple ports for a single stream, e.g. for IV feedback we use 2 
> ports.

Is this on multi_link? which is why it might be working for you.

> 

Currently we have below check in sdw_stream_add_master().

if (!bus->multi_link && stream->m_rt_count > 0) {
	dev_err(bus->dev, "Multilink not supported, link %d\n", bus->link_id);
	ret = -EINVAL;
	goto unlock;
}

If we have single master(like my case) and dai-links which have more 
then one port  will be calling  sdw_stream_add_master() for each port, 
so m_rt_count above check will fail for the second call!



> In your "RX Port 1, 2, 3" example, are you referring to the codec or the 
> master side? If it's for the codec, it's already supported, see e.g. 

Master side.

> https://github.com/thesofproject/linux/pull/2514, we use DP2 and DP4 for 

This fine on slave side! Issue is on the master side!

> the same stream. This is done with the port_config capability.
> 
> 

  reply	other threads:[~2021-01-21 15:42 UTC|newest]

Thread overview: 19+ 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 ` [RFC PATCH 1/2] soundwire: add support for static port mapping Srinivas Kandagatla
2021-01-20 22:15   ` Pierre-Louis Bossart
2021-01-21 11:35     ` Srinivas Kandagatla
2021-01-21 14:56       ` Pierre-Louis Bossart
2021-01-21 15:41         ` Srinivas Kandagatla [this message]
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
2021-01-25 16:23                         ` Srinivas Kandagatla
2021-02-01 10:27                           ` Vinod Koul
2021-02-19 10:35                             ` Srinivas Kandagatla
2021-02-19 19:52                               ` Pierre-Louis Bossart
2021-02-22 13:40                                 ` Srinivas Kandagatla
2021-01-20 18:01 ` [RFC PATCH 2/2] soundwire: qcom: " 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=c6278763-57d9-2631-7b43-829259a9ea1f@linaro.org \
    --to=srinivas.kandagatla@linaro.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=sanyog.r.kale@intel.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).