lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 20 Jan 2021 16:15:08 -0600
From:   Pierre-Louis Bossart <>
To:     Srinivas Kandagatla <>,,
Subject: Re: [RFC PATCH 1/2] soundwire: add support for static port mapping

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?

Powered by blists - more mailing lists