Hi Tony
/* Codec has 1 DAI */ Codec { port { #address-cells = <2>; #size-cells = <1>;
ep: endpoint { remote-endpoint = <xxx>; }; };}
(snip)
foo = <&ep 0>; bar = <&ep 1>;
Ahh, it looks nice idea ! but hmm..., it seems dtc doesn't allow us to use #address-cells = <2> for "remote-endpoint".
--- ${LINUX}/scripts/dtc/checks.c --- static struct node *get_remote_endpoint(struct check *c, struct dt_info *dti, struct node *endpoint) { ... prop = get_property(endpoint, "remote-endpoint"); if (!prop) return NULL;
=> phandle = propval_cell(prop); /* Give up if this is an overlay with external references */ ... }
I'm not good at dtc, but propval_cell() is assuming it is single address cell. We will have many assert warning on
remote-endpoint = <&xxx 0>;
Can you please double check it ?
And, I'm wonder remote-endpoint need to cross pointing, right ? one way looks nice by address-cells <2>, but other way is ?
port { cpu-ep0: endpoint@0 { remote-endpoint = <&codec-ep 0>; }; cpu-ep1: endpoint@1 { remote-endpoint = <&codec-ep 1>; }; };
port { #address-cells = <2>; #size-cells = <1>; codec-ep: endpoint { (*1) remote-endpoint = <&cpu-ep0>; }; };
This case, cpu-epX -> codec-ep are OK. But, codec-ep -> cpu-epX case can point only 1 endpoint (*1). I'm not sure, but maybe this is not a OF graph policy (?)
Can you agree this ? we need extra patch, but it can solve your / my problem.
Yes it's starting to make sense :)
Thanks
Now I'm posting patches to merging "audio-graph-card" and "DPCM ver audio-graph-card". If you are OK, I will include above solution patch to this patch-set.
Sure, maybe please first check if the #size-cells = <2> option would work though?
maybe #address-cells, instead of #size-cells ;P But, yeah, please double check it too.
Current audio-graph doesn't expect your use-case, and I want to avoid conflict.
So, "merged" audio-graph should solve your use-case. If you can agree about this, I will post patch-set.
Yeah I agree, just still wondering what might be the best way to represent 1 DAI vs 2 DAIs.
According to OF graph maintainer, he said that counting port / endpoint are not guaranteed, and we need to use "reg". (It is the reason of b6f3fc005a2c8b425d7a0973b43bef05890bf479)
If you could double checked, and we could agreed that "reg" is the solution for us. I will post patches.
Best regards --- Kuninori Morimoto