linux-kernel - Re: [alsa-devel] [PATCH 0/2] Graph fixes for using multiple endpoints per port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 12 Dec 2018 07:27:25 -0800
From:   Tony Lindgren <tony@...mide.com>
To:     Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
Cc:     "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        "linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Takashi Iwai <tiwai@...e.com>,
        Peter Ujfalusi <peter.ujfalusi@...com>,
        Mark Brown <broonie@...nel.org>,
        Sebastian Reichel <sre@...nel.org>,
        Jarkko Nikula <jarkko.nikula@...mer.com>
Subject: Re: [alsa-devel] [PATCH 0/2] Graph fixes for using multiple
        endpoints per port

* Kuninori Morimoto <kuninori.morimoto.gx@...esas.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