linux-kernel - Re: [RFC] DPCM for Tegra

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 4 May 2020 18:55:55 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Sameer Pujar <spujar@...dia.com>
Cc:     perex@...ex.cz, tiwai@...e.com, kuninori.morimoto.gx@...esas.com,
        lgirdwood@...il.com, thierry.reding@...il.com,
        jonathanh@...dia.com, digetx@...il.com,
        alsa-devel@...a-project.org, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org, sharadg@...dia.com,
        mkumard@...dia.com, viswanathl@...dia.com, rlokhande@...dia.com,
        dramesh@...dia.com, atalambedu@...dia.com, nwartikar@...dia.com,
        swarren@...dia.com, nicoleotsuka@...il.com
Subject: Re: [RFC] DPCM for Tegra

On Thu, Apr 30, 2020 at 06:11:23PM +0530, Sameer Pujar wrote:

>  a) Can I use a DAPM Mux control to activate a BE path? This in turn can
>     program required switch in XBAR.

If it works then sure, that seems sensible.

>  b) I have modelled SFC and MIXER as backends. Is this allowed?
> 
>     This was done to include SFC or MIXER HW components as part of the
>     sound card and use like below in one of the audio use cases.
>  
>     ADMAIF1(FE) --> SFC(BE1) --> I2S(BE2) ... OR
>     ADMAIF2(FE) --> SFC(BE1) --> I2S(BE2) ...

This is the sort of setup that'd be a lot happier using a component
model.

>     I used following workaround to connect multiple BE components.
>     With this I can see PCM callbacks happen for all BE DAIs along the DAPM
>     path. The obective was to connect multiple components together and (a)
>     was used to connect one component to another. Each "-->" here connects
>     two components and it is a switch in XBAR. 

This doesn't strike me as something that's likely to be robust but given
that that applies to DPCM in general so long as it doesn't break anyone
else's existing stuff I guess it should be viable, it's not like there
are actually good options that you could use currently.  It's really
hard to get enthusiastic about it though.

>  c) Hostless mode did NOT work:
>      - Following audio path was intended to be tested:
>        I2S1 --> SFC --> I2S2

>      - [3] offers two options:
>          * CODEC<->CODEC: If I were to use a separate DAI link for each BE to BE
>            connection, then it will result in a similar design what we have
>            currently.

This is more in line with components so will probably be easier going
forwards.

>          * Hostless: I did not come across references for this.
>            (Any references in this regard will be helpful)

Not sure anyone has ever done this with DPCM, could be wrong though.

> May be the current Tegra ASoC design is more suitable for component model as you
> had previously mentioned. I wanted to understand if above, especially (a) and (b),
> are acceptable in this regard or if there are better options to interconnect
> multiple ASoC components.

In general most systems would be happier with components but yeah, I
think that's particularly the case for something as powerful and
flexible as your hardware seems to be.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)