linux-kernel - Re: [RFC PATCH 0/5] Apple Macs machine-level ASoC driver

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: <YmKPQ6kLCPz+2XTJ@sirena.org.uk>
Date:   Fri, 22 Apr 2022 12:19:31 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Martin Povišer <povik@...ebit.org>
Cc:     Martin Povišer <povik+lin@...ebit.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Mark Kettenis <kettenis@...nbsd.org>,
        Hector Martin <marcan@...can.st>,
        Sven Peter <sven@...npeter.dev>
Subject: Re: [RFC PATCH 0/5] Apple Macs machine-level ASoC driver

On Fri, Apr 22, 2022 at 12:43:30PM +0200, Martin Povišer wrote:

> I looked in the TAS2770 and TAS2764 drivers/datasheets, and to answer
> the questions we had:

>  * VSENSE/ISENSE output slots are configured independently of audio samples
>    routing. Kernel drivers configure the slots based on the 'ti,imon-slot-no'
>    and 'ti,vmon-slot-no' properties of devicetree.

>  * By default codecs transmit Hi-Z for duration of unused slots.

> So once we supply the devicetree props it should be electrically sound
> under any configuration of userspace knobs.

Great, that's a relief.

> One final thought on the playback routing controls: On systems with >2
> speakers, the codecs need to be assigned slots through set_tdm_slot.
> The macaudio driver RFCed here assigns a single slot to each speaker,
> making the effect of each speaker's routing control this:

>   'I2C offset' -- uses a random slot

>   'Left' 'Right' 'LeftRight' -- uses the single slot we configured

> I suppose I better assign two slots to speakers in each left-right pair
> of the same kind (e.g. woofer 1, woofer 2, tweeter). This way the
> routing control will mimic its behavior from simple stereo systems but
> replicated within each left-right pair.  (I would prefer to hide the
> controls altogether, but as I learned that hiding things unless proven
> dangerous is an ASoC non-goal, this way I can make the controls do
> something interesting.)

I don't quite grasp the difference between the arrangement you're
proposing and assigning a single slot to each speaker?  Possibly it's
just a reordering of the slots?

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)