linux-kernel - [PATCH 0/7] PinePhone BT audio bringup

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-next>] [day] [month] [year] [list]

Message-Id: <20201106041513.38481-1-samuel@sholland.org>
Date:   Thu,  5 Nov 2020 22:15:06 -0600
From:   Samuel Holland <samuel@...lland.org>
To:     Maxime Ripard <mripard@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...l.net>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Rob Herring <robh+dt@...nel.org>
Cc:     alsa-devel@...a-project.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        phone-devel@...r.kernel.org, Samuel Holland <samuel@...lland.org>
Subject: [PATCH 0/7] PinePhone BT audio bringup

This series makes use of the additional DAIs recently added to the
sun8i-codec driver to add hardware routing for BT SCO (headset) audio
on the PinePhone.

The BT audio connection is represented by the "dummy" bt-sco codec. The
connection to the Quectel EG-25G modem via AIF2 works as well, but I do
not include it here because there is no appropriate codec driver in
tree. We have been using an out-of-tree "dummy" codec driver similar to
bt-sco, and I'm not sure if such a driver would be desired upstream.

The modem has a similar amount of configurability as the rtl8723cs BT
chip. For the BT chip, the DAI format and PCM parameters are set in a
configuration firmware file and loaded at driver load time. For the
modem, the DAI format and PCM parameters are set by (and can be queried
from) an AT command. However, this AT command requires a modem restart
to take effect, so the parameters cannot feasibly be changed at runtime.

With a dummy driver, we pick some "standard" set of PCM parameters, e.g.
16 bit mono at 8 or 16 kHz, and assume the hardware agrees. Similarly,
we assume the DAI format pre-programmed in the remote hardware matches
what is configured in the DAI link (in this case, in the device tree).

Is that the right way to model this? Or does the modem (and maybe even
the BT chip) deserve a more featureful driver that reads and/or programs
the format and params at probe time?

Because of those unanswered questions, I'm sending BT SCO support
first/only.

Regards,
Samuel

Arnaud Ferraris (1):
  arm64: dts: allwinner: pinephone: Set audio card name

Samuel Holland (6):
  ASoC: dt-bindings: sun8i-codec: Increase #sound-dai-cells
  ARM: dts: sun8i-a33: Allow using multiple codec DAIs
  arm64: dts: allwinner: a64: Allow using multiple codec DAIs
  arm64: dts: allwinner: a64: Add pinmux nodes for AIF2/AIF3
  arm64: dts: allwinner: a64: Allow multiple DAI links
  arm64: dts: allwinner: pinephone: Add support for Bluetooth audio

 .../sound/allwinner,sun8i-a33-codec.yaml      |  2 +-
 arch/arm/boot/dts/sun8i-a33.dtsi              |  4 +-
 .../dts/allwinner/sun50i-a64-pinephone.dtsi   | 25 +++++++++++++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 37 ++++++++++++++-----
 4 files changed, 55 insertions(+), 13 deletions(-)

-- 
2.26.2