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

[Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>]

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.