On 05-01-2024 13:41, Thierry Reding wrote:
On Fri, Jan 05, 2024 at 10:24:18AM +0530, Sameer Pujar wrote:
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?
This seems like a legitimate use-case for the graph bindings, but
perhaps one that nobody has run into yet. It might be worth looking into
extending the bindings to account for this.
I think there are two pieces for this. On one hand we have the DTC that
complains, which I think is what you were seeing. It's a bit tricky to
update because it checks for bidirectionality of the endpoints, which is
trivial to do with 1:1 but more complicated with 1:N relationships. I've
done some prototyping but not sure if my test DT is exactly what you
need. Can you send a snippet of what your DT looks like to test the DTC
changes against?
This is the snippet I was trying to test:
diff --git a/arch/arm64/boot/dts/nvidia/tegra234-p3737-0000.dtsi
b/arch/arm64/boot/dts/nvidia/tegra234-p3737-0000.dtsi
index eb79e80..22a97e2 100644
--- a/arch/arm64/boot/dts/nvidia/tegra234-p3737-0000.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra234-p3737-0000.dtsi
@@ -13,7 +13,8 @@
port@1 {
endpoint {
dai-format = "i2s";
- remote-endpoint = <&rt5640_ep>;
+ remote-endpoint = <&rt5640_ep>,
+ <&rt5640_ep2>;
};
};
};
@@ -53,10 +54,14 @@
sound-name-prefix = "CVB-RT";
port {
- rt5640_ep: endpoint {
+ rt5640_ep: endpoint@0 {
remote-endpoint =
<&i2s1_dap>;
mclk-fs = <256>;
};
+
+ rt5640_ep2: endpoint@1 {
+ remote-endpoint =
<&i2s1_dap>;
+ };
};
};
};
The other part is the DT schema which currently restricts the
remote-endpoint property to be a single phandle. We would want
phandle-array in this case with an updated description. Something like
this:
--- >8 ---
diff --git a/dtschema/schemas/graph.yaml b/dtschema/schemas/graph.yaml
index bca450514640..1459b88b9b77 100644
--- a/dtschema/schemas/graph.yaml
+++ b/dtschema/schemas/graph.yaml
@@ -42,8 +42,9 @@ $defs:
remote-endpoint:
description: |
- phandle to an 'endpoint' subnode of a remote device node.
- $ref: /schemas/types.yaml#/definitions/phandle
+ A list of phandles to 'endpoint' subnodes of one or more remote
+ device node.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
port-base:
type: object
--- >8 ---
Thierry
