* Kuninori Morimoto <kuninori.morimoto.gx@xxxxxxxxxxx> [181212 06:52]: > > Hi Tony, again > > > > > https://patchwork.kernel.org/patch/10712877/ > > > > > > Hmm, so do you have multiple separate ports at the "&sound" node > > > hardware? If so then yeah multiple ports make sense. > > > > > > But if you only a single physical (I2S?) port at the > > > "&sound" node hardware, then IMO you should only have one > > > port and multiple endpoints there according to the graph.txt > > > binding doc. > > > > > > In my McBSP case there is only a single physical I2S port > > > that can be TDM split into timeslots. > > > > Mine has 4 DAIs. Each DAI can output 2ch. > > These will be merged and wil be 8ch TDM and goes to Codec. > > But hmm.. it is 4 DAIs, but 1 "physical" interface... > > > > So, your patch seems correct, but will breaks DPCM... > > I will confirm it. > > I thought "port" = "DAI", but yeah, "port" = "physical interface". OK good to hear :) > Then, my issue is that we can't judge DAI size from DT. > For example, MIXer case, 2 CPU DAIs are connected to 1 Codec. > > DAI0 --- CPU --- Codec > DAI1 / > > In this case, CPU side needs 2 DAIs, > Codec side needs 1 DAI only. Oh so the other way around compared to my use case. Hmm. > For both CPU/Codec case, OF graph will be like below, > and we can't judge DAIs size from this. > > port { > ep0: endpint@0 { > remote-endpoint = <xxx>; > }; > ep1: endpint@1 { > remote-endpoint = <xxx>; > }; > } Hmm I too need to add secondary DAIs for McBSP in addition to the primary DAI controlling the McBSP hardware resources. > To solve this issue, we need to use "reg" for it. > Then, we can get correct DAI ID. Hmm yeah maybe. Just to think of other options, maybe also the #size-cells could be used? As the binding allows adding #address-cells and #size-cells to the port node.. Usually if you refer a subnode of a device you just use #address=cells = <2> where the second field would be for the offset. So maybe this could be used for 1 DAI this way: /* Codec has 1 DAI */ Codec { port { #address-cells = <2>; #size-cells = <1>; ep: endpoint { remote-endpoint = <xxx>; }; }; } Where this codec would then need to be referenced with just an additional instance number: foo = <&ep 0>; bar = <&ep 1>; ... And then for a codec with 2 DAIs the usual #size-cells = <1> would be used with numbered endpoints for each DAI the way you already described: port { ep0: endpint@0 { remote-endpoint = <xxx>; }; ep1: endpint@1 { remote-endpoint = <xxx>; }; } Do you think that would work? > Can you agree this ? we need extra patch, > but it can solve your / my problem. Yes it's starting to make sense :) > 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? > 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. Regards, Tony