Re: Query on audio-graph-card DT binding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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?




[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux