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: <4D50785A.7050801@metafoo.de>
Date:	Mon, 07 Feb 2011 23:55:22 +0100
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	Liam Girdwood <lrg@...mlogic.co.uk>, alsa-devel@...a-project.org,
	linux-kernel@...r.kernel.org,
	"Marcel Holtmann \"" <marcel@...tmann.org>
Subject: Adding bluetooth PCM interface support to ASoC (Was: Re: [PATCH 6/7]
 ASoC: Samsung: neo1973_gta02: Fix bluetooth DAI registration)

On 02/07/2011 07:17 PM, Mark Brown wrote:
>>> The bluetooth chip is an actual device which I can point to on the
>>> board and schematic, having a struct device to represent a device that's
>>> actually present doesn't seem like a great leap.
> 
>> Well, there is an actual device representing the bt device, but since
>> this is the standard bt usb device I have no idea how we would get an
>> reference to it from within the sound board driver.
> 
> If you've got a real device and a driver binding to it then you can make
> the driver for that device register the DAI from its probe function, no
> need for the machine driver to get involved.
>

The audio hardware setup of the board looks roughly like this:

  [### SOC ###]
   |         |
   | USB     | I2S
   |         |
 [BT]----[Codec]----[Modem]
     PCM        Analog

So the bluetooth chip is handeld by the standard USB BT HCI driver.

I did some research on the topic and it seems that this is a pretty common
setup in embedded devices.
Audio to the bluetooth chip can either be send over the HCI interface (USB in
this case) from the CPU or over the PCM interface from the codec, so that audio
data from the modem to a bluetooth headset doesn't have to be routed through
the CPU.
The PCM interface seems to be part of the bluetooth standard and there are even
registers (PSKEY_PCM_CONFIG32) to configure the PCM format and bit-rate.

This and that neo1973 devices dont seem the only ones using such a setup, it
would naturally make sense to write an ASoC driver to negotiate the PCM format
between the codec and bluetooth chip and maybe do power management. (And
ofcourse register a dai_device).

But the bluetooth audio support seems to be entirely written in userspace. The
in-kernel bluetooth drivers in general seem only to provide a common interface
to the underlying hardware and all of the higher level functionality seems to
be implemented in userspace.
So right now I have no idea where to start if one wanted to add a ASoC driver
which did the bt-dai configuration.

I've Cced Marcel Holtmann and the bluez mailinglist, maybe someone can give
some input on subject.

- Lars
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ