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: sanyog.r.kale@intel.com, gregkh@linuxfoundation.org,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/2] soundwire: add support for static port mapping
Date: Wed, 20 Jan 2021 16:15:08 -0600	[thread overview]
Message-ID: <fcc1b199-644d-8c7f-5e8b-d12b0d9c9a04@linux.intel.com> (raw)
In-Reply-To: <20210120180110.8357-2-srinivas.kandagatla@linaro.org>



On 1/20/21 12:01 PM, Srinivas Kandagatla wrote:
> Some of the soundwire controllers can have static functions assigned
> to each port, like some ports can only do PCM or PDM. This is the situation
> with some of the Qualcomm Controllers.
> 
> In such cases its not correct to assign/map any free port on master
> during streaming.
> 
> So, this patch provides a way to pass mapped port number along
> with the port config, so that master can assign correct ports based
> on the provided static mapping.

I am not sure I understand the problem or what's different between Intel 
and Qualcomm.

On the Intel side we also have fixed-function ports, some for PDM and 
some for PCM. They are not interchangeable, and they are also dedicated 
for each link.

We don't dynamically allocate ports on the master side, the mapping is 
defined by the dai->id and is static. There is a 1:1 relationship 
between dai->id and port_number. See intel_register_dai() and 
intel_hw_params() in drivers/soundwire/intel.c

In the machine driver we make use of specific master DAIs in the dailink 
definitions, just like regular ASoC solutions, so which DAIs you use in 
the machine driver defines what ports end-up being used. There is 
nothing fancy or dynamic here, the dai/port allocation is defined by the 
dailinks. This is a static/worst-case allocation, we don't reassign 
ports depending on use-cases, etc.

The only thing that is dynamic is that the programming of each port is 
handled based on the bandwidth needs of that port, i.e if you play 16 or 
24 bits you'd get fewer or more bitSlots allocated to that dai/port, and 
the DPn registers are updated if you have concurrent streaming on other 
ports. If you only have a fixed set of payloads, as in the existing 
amplifier cases, you can hard-code this allocation as well.

Does this help and can you align on what Intel started with?


WARNING: multiple messages have this Message-ID (diff)
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: Wed, 20 Jan 2021 16:15:08 -0600	[thread overview]
Message-ID: <fcc1b199-644d-8c7f-5e8b-d12b0d9c9a04@linux.intel.com> (raw)
In-Reply-To: <20210120180110.8357-2-srinivas.kandagatla@linaro.org>



On 1/20/21 12:01 PM, Srinivas Kandagatla wrote:
> Some of the soundwire controllers can have static functions assigned
> to each port, like some ports can only do PCM or PDM. This is the situation
> with some of the Qualcomm Controllers.
> 
> In such cases its not correct to assign/map any free port on master
> during streaming.
> 
> So, this patch provides a way to pass mapped port number along
> with the port config, so that master can assign correct ports based
> on the provided static mapping.

I am not sure I understand the problem or what's different between Intel 
and Qualcomm.

On the Intel side we also have fixed-function ports, some for PDM and 
some for PCM. They are not interchangeable, and they are also dedicated 
for each link.

We don't dynamically allocate ports on the master side, the mapping is 
defined by the dai->id and is static. There is a 1:1 relationship 
between dai->id and port_number. See intel_register_dai() and 
intel_hw_params() in drivers/soundwire/intel.c

In the machine driver we make use of specific master DAIs in the dailink 
definitions, just like regular ASoC solutions, so which DAIs you use in 
the machine driver defines what ports end-up being used. There is 
nothing fancy or dynamic here, the dai/port allocation is defined by the 
dailinks. This is a static/worst-case allocation, we don't reassign 
ports depending on use-cases, etc.

The only thing that is dynamic is that the programming of each port is 
handled based on the bandwidth needs of that port, i.e if you play 16 or 
24 bits you'd get fewer or more bitSlots allocated to that dai/port, and 
the DPn registers are updated if you have concurrent streaming on other 
ports. If you only have a fixed set of payloads, as in the existing 
amplifier cases, you can hard-code this allocation as well.

Does this help and can you align on what Intel started with?


  reply	other threads:[~2021-01-21  0:48 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 [this message]
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
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=fcc1b199-644d-8c7f-5e8b-d12b0d9c9a04@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.