On Tue, Jul 30, 2024 at 12:30:38PM +0200, Stephan Gerhold wrote:
On Sun, Jul 28, 2024 at 12:30:12PM +0200, Krzysztof Kozlowski wrote:
This was added to the common driver code but it does not mean it is reasonable binding. I don't understand why for example we even accept here aux-devs, instead of putting them into one of DAI links.
The auxiliary devices (typically analog audio components) are not necessarily related to one particular digital audio interface link. It is typically the case (e.g. an analog speaker amplifier connected in parallel to the headphone output of one of the codecs), but I don't think we can assume that as a general rule. There are often multiple DAI links that go to one codec and then it might be tricky to decide which of the DAI links the aux-dev belongs to.
Right, aux devices may cover more than one DAI link (eg, if there's a CODEC that can do mixing and they're connected to an analog output) or may in rare cases not fit with one at all (there's use cases where you have a sound card that has no DAIs and is all analog bypass).
The pin-switches and widgets could be used, but are they? The only valid argument to keep them is that you added them to common driver code.
These go hand in hand with the aux-devs property. If you have multiple analog audio components connected to a codec output (e.g. an analog speaker amplifier connected to the codec headphone output) then the pin-switches/widgets describe that the output paths (speaker and headphones) should be separately controllable.
Plus the above cases where you don't have a direct mapping with aux devs and DAIs also apply to pin switches since they're in the analog domain.