On 04-01-2024 22:52, Mark Brown wrote:
On Thu, Jan 04, 2024 at 06:07:22PM +0100, Thierry Reding wrote:
On Tue, Dec 26, 2023 at 09:58:02PM +0530, Sameer Pujar wrote:
/-----> codec1 endpoint
/
CPU endpoint \
\-----> codec2 endpoint
Can you describe the use-case? Is there a need to switch between codec1
and codec2 endpoints or do they receive the same data in parallel all
the time?
Could this perhaps be described by adding multiple CPU ports with one
endpoint each?
Don't know about the specific use case that Sameer is looking at but to
me this looks like a surround sound setup where multiple stereo (or
mono) DACs are wired in parallel, either with a TDM setup or with
multiple data lines. There's multiple CODECs all taking input from a
single host controller.
Yes, it is a TDM use case where the same clock and data line is shared
with multiple CODECs. Each CODEC is expected to pickup data based on the
allotted TDM slot.
It is possible to create multiple CPU dummy endpoints and use these in
DT binding for each CODEC. I am not sure if this is the best way right
now. There are few things to note here with dummy endpoints. First, it
leads to bit of duplication of endpoint DAIs and DAI links for these.
Please note that host controller pins are actually shared with external
CODECs. So shouldn't DT provide a way to represent this connection?
Second, ASoC provides a way to represent multiple CODECs on a single DAI
link in the driver and my concern is to understand if present binding
can be extended to represent this scenario. Third, one of the user
wanted to connect 6 CODECs and that is the maximum request I have seen
so far. I can expose additional dummy CPU DAIs keeping this maximum
request in mind, but not sure if users would like to extend it further.
The concern I have is, how can we make this easily extendible and
simpler to use?
With custom DT bindings it may be simpler to resolve this, but Tegra
audio presently relies on standard graph remote-endpoints binding. So I
guess diverging from this may not be preferable?
