linux-kernel - Re: [PATCH 1/3] ASoC: SDCA: Create DAPM widgets and routes from DisCo

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: <2b899796-b9fc-49ef-a4a7-858baa90a36b@linux.dev>
Date: Mon, 24 Mar 2025 16:15:24 -0500
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>
To: Charles Keepax <ckeepax@...nsource.cirrus.com>, broonie@...nel.org
Cc: lgirdwood@...il.com, yung-chuan.liao@...ux.intel.com,
 peter.ujfalusi@...ux.intel.com, linux-sound@...r.kernel.org,
 linux-kernel@...r.kernel.org, patches@...nsource.cirrus.com
Subject: Re: [PATCH 1/3] ASoC: SDCA: Create DAPM widgets and routes from DisCo

Thanks for starting this Charles.

> Use the previously parsed DisCo information from ACPI to create DAPM
> widgets and routes representing a SDCA Function. For the most part SDCA
> maps well to the DAPM abstractions.

except when it doesn't, eh?

> The primary point of interest is the SDCA Power Domain Entities
> (PDEs), which actually control the power status of the device. Whilst
> these PDEs are the primary widgets the other parts of the SDCA graph
> are added to maintain a consistency with the hardware abstract, and
> allow routing to take effect.
> 
> Other minor points of slightly complexity include, the Group Entities
> (GEs) these set the value of several other controls, typically
> Selector Units (SUs) for enabling a cetain jack configuration. These
> are easily modelled creating a single control and sharing it among
> the controlled muxes.

It wasn't able to follow the last sentence, what are 'these'?

I am not sure we can expose and control any SUs since their configuration is set in hardware depending on the GE settings. IIRC the SU values should be considered as read-only.

> SDCA also has a slight habit of having fully connected paths, relying
> more on activating the PDEs to enable functionality. This doesn't map
> quite so perfectly to DAPM which considers the path a reason to power
> the PDE. Whilst in the current specification Mixer Units are defined as
> fixed-function, in DAPM we create a virtual control for each input. This
> allows paths to be connected/disconnected, providing a more ASoC style
> approach to managing the power.

Humm, maybe my analysis was too naive but the SDCA PDE seemed like a DAPM power supply to me.
When a path becomes active, DAPM turns on the power for you, and power is turned off some time after the path becomes inactive.

Why would we need to have a control to force the power to be turned on? 
And there are quite a few topologies without any Mixer Units so can we depend on a solution that's not applicable across all topologies?
And last PDEs are typically related to terminals, while Mixer Units are usually for host-generated streams.

It would also help to define which power levels you wanted to control for PDEs. For me, only PS0 and PS3 can currently be modeled, I have no idea how PS1 with its degraded quality would be used, and PS2 depends on firmware.