linux-kernel - Re: [RFC PATCH 0/3] Separate BE DAI HW constraints from FE ones

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]

Message-ID: <20210416185538.GK5560@sirena.org.uk>
Date:   Fri, 16 Apr 2021 19:55:38 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc:     Codrin.Ciubotariu@...rochip.com, alsa-devel@...a-project.org,
        lgirdwood@...il.com, linux-kernel@...r.kernel.org, tiwai@...e.com,
        gustavoars@...nel.org, mirq-linux@...e.qmqm.pl
Subject: Re: [RFC PATCH 0/3] Separate BE DAI HW constraints from FE ones

On Fri, Apr 16, 2021 at 11:47:01AM -0500, Pierre-Louis Bossart wrote:
> On 4/16/21 11:31 AM, Mark Brown wrote:

> > Not really written down that I can think of.  I think the next steps
> > that I can think of right now are unfortunately bigger and harder ones,
> > mainly working out a way to represent digital configuration as a graph
> > that can be attached to/run in parallel with DAPM other people might
> > have some better ideas though.  Sorry, I appreciate that this isn't
> > super helpful :/

> I see a need for this in our future SoundWire/SDCA work. So far I was
> planning to model the entities as 'widgets' and lets DAPM propagate
> activation information for power management, however there are also bits of
> information in 'Clusters' (number of channels and spatial relationships)
> that could change dynamically and would be interesting to propagate across
> entities, so that when we get a stream of data on the bus we know what it
> is.

Yes, I was thinking along similar lines last time I looked at it - I was
using the term digital domains.  You'd need some impedence matching
objects for things like SRCs, and the ability to flag which
configuration matters within a domain (eg, a lot of things will covert
to the maximum supported bit width for internal operation so bit width
only matters on external interfaces) but I think for a first pass we can
get away with forcing everything other than what DPCM has as front ends
into static configurations.

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