Re: Query on audio-graph-card DT binding

[Sameer Pujar <spujar@nvidia.com>]

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?