* Kuninori Morimoto <kuninori.morimoto...@renesas.com> [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
