From: Tony Lindgren <tony@atomide.com>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Takashi Iwai <tiwai@suse.com>,
Peter Ujfalusi <peter.ujfalusi@ti.com>,
Mark Brown <broonie@kernel.org>,
Sebastian Reichel <sre@kernel.org>,
Jarkko Nikula <jarkko.nikula@bitmer.com>
Subject: Re: [alsa-devel] [PATCH 0/2] Graph fixes for using multiple endpoints per port
Date: Wed, 12 Dec 2018 07:27:25 -0800 [thread overview]
Message-ID: <20181212152725.GE6707@atomide.com> (raw)
In-Reply-To: <87k1kfs0u5.wl-kuninori.morimoto.gx@renesas.com>
* Kuninori Morimoto <kuninori.morimoto.gx@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
next prev parent reply other threads:[~2018-12-12 15:27 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-11 2:05 Tony Lindgren
2018-12-11 2:05 ` [PATCH 1/2] ASoC: simple-card-utils: revert port changes to follow graph binding Tony Lindgren
2018-12-11 2:05 ` [PATCH 2/2] ASoC: audio-graph-card: Fix parsing of multiple endpoints Tony Lindgren
2018-12-11 3:31 ` [PATCH 0/2] Graph fixes for using multiple endpoints per port Kuninori Morimoto
2018-12-11 4:52 ` Tony Lindgren
2018-12-11 5:16 ` Kuninori Morimoto
2018-12-11 5:30 ` Kuninori Morimoto
2018-12-11 5:44 ` Tony Lindgren
2018-12-11 5:35 ` Tony Lindgren
2018-12-11 6:14 ` Kuninori Morimoto
2018-12-11 14:16 ` Tony Lindgren
2018-12-11 23:16 ` Kuninori Morimoto
2018-12-12 0:12 ` Kuninori Morimoto
2018-12-12 0:43 ` Tony Lindgren
2018-12-12 0:50 ` Tony Lindgren
2018-12-12 0:19 ` Tony Lindgren
2018-12-12 2:11 ` Kuninori Morimoto
2018-12-12 6:51 ` [alsa-devel] " Kuninori Morimoto
2018-12-12 15:27 ` Tony Lindgren [this message]
2018-12-13 0:24 ` Kuninori Morimoto
2018-12-13 0:40 ` Tony Lindgren
2018-12-13 1:06 ` Kuninori Morimoto
2018-12-13 1:13 ` Tony Lindgren
2018-12-12 13:05 ` Peter Ujfalusi
2018-12-12 14:50 ` Tony Lindgren
2018-12-13 6:53 ` Peter Ujfalusi
2018-12-13 16:55 ` Tony Lindgren
2018-12-12 12:48 ` Peter Ujfalusi
2018-12-12 14:58 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181212152725.GE6707@atomide.com \
--to=tony@atomide.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=jarkko.nikula@bitmer.com \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=peter.ujfalusi@ti.com \
--cc=sre@kernel.org \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®