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.
Attachment:
signature.asc
Description: PGP signature
