[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqLyYE_nmGfPEF_H9NxKK1HX1BbwWkUmw-PSWo6TANr5ZQ@mail.gmail.com>
Date: Tue, 6 Dec 2016 09:03:21 -0600
From: Rob Herring <robh@...nel.org>
To: Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
Cc: Mark Brown <broonie@...nel.org>,
Linux-ALSA <alsa-devel@...a-project.org>,
Liam Girdwood <lgirdwood@...il.com>,
Simon <horms@...ge.net.au>,
Laurent <laurent.pinchart@...asonboard.com>,
Guennadi <g.liakhovetski@....de>,
Grant Likely <grant.likely@...aro.org>,
Frank Rowand <frowand.list@...il.com>,
Linux-DT <devicetree@...r.kernel.org>,
Linux-Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 11/14] ASoC: add simple-graph-card document
On Mon, Dec 5, 2016 at 6:57 PM, Kuninori Morimoto
<kuninori.morimoto.gx@...esas.com> wrote:
>
> Hi Rob
>
>> I'd expect the top level node to be the card node that knows how to find
>> all the components. The graph should reflect the data flow. For example,
>> the data goes to audio DSP to I2S host to codec to amp.
>
> Do you mean, is this OK for OF graph ?
Yes, something like this.
> in driver point of view, "I2S" is sound card here.
Well, that seems odd to me because I2S should just be the h/w block
that interfaces to I2S/SSI signals. I'd expect you still have a card
node that references these nodes. Maybe it just references the DSP and
then you walk the graph from there to find the I2S controller and
codec.
>
> I2S {
> port {
> i2s-dsp: endpoint {
> remote-endpoint = <&dsp>;
> }
> i2s-codec: endpoint {
> remote-endpoint = <&codec>;
> }
> }
> }
>
> DSP {
> port {
> dsp: endpoint {
> remote-endpoint = <&i2s-dsp>;
> }
> }
> }
>
> Codec {
> port {
> codec: endpoint {
> remote-endpoint = <&i2s-codec>;
> }
> }
> }
Powered by blists - more mailing lists