Re: [PATCH] ASoC: dt-bindings: qcom,apq8016-sbc-sndcard: move to separate binding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux