| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
The Intel Version Read command is used to retrieve information
about hardware and firmware version/revision of Intel Bluetooth
controllers. This is an Intel generic command used in USB and
UART drivers.
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Older Intel controllers need to enter manufacturing mode to perform
some vendor specific operations (patching, configuration...).
Add enter/exit manufaturing methods and refactor existing
manufacturing code.
Exit can be configured to perform a reset. Reset can be performed
either with patches activated or deactivated.
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
|
|
|
|
|
|
|
|
| |
The Intel Bluetooth controllers can emit extra vendor specific events in
error conditions or for debugging purposes. To make the life easier for
engineers, enable them by default. When the vendor_diag options has been
enabled, then additional debug events are also enabled.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
|
|
|
|
|
|
|
| |
For the older controllers like Wilkens Peak and Stone Peak, enabling the
traces requires to switch into manufacturer mode first. This patch does
exactly that, but only for these older controllers.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
|
|
|
|
|
|
| |
For Intel controllers with firmware that allows tracing of baseband
functionality this allows enabling it via set_diag driver callback.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add regmap ibt to support Intel Bluetooth silicon register access
over HCI. Intel BT/FM combo chip allows to read/write some registers
(e.g. FM registers) via its HCI interface.
Read/Write operations are performed via a HCI transaction composed of
a HCI command (host->controller) followed by a HCI command complete
event (controller->host). Read/Write Command opcodes can be specified
to the regmap init function.
We define data formats which are intel/vendor specific.
Register Read/Write HCI command payload (Host):
Field: | REG ADDR | MODE | DATA_LEN | DATA... |
size: | 32b | 8b | 8b | 8b* |
Register Read HCI command complete event payload (Controller):
Field: | CMD STATUS | REG ADDR | DATA... |
size: | 8b | 32b | 8b* |
Register Write HCI command complete event payload (Controller):
Field: | CMD_STATUS |
size: | 8b |
Since this payload is HCI encapsulated, Little Endian byte order is
used.
Write/Read Example:
If we write 0x0000002a at address 0x00008c04, with opcode_write 0xfc5d,
The resulting transaction is (btmon trace):
< HCI Command (0x3f|0x005d) plen 10 [hci0]
04 8c 00 00 02 04 2a 00 00 00
> HCI Event (0x0e) plen 4
Unknown (0x3f|0x005d) ncmd 1
00
Then, if we read the same register with opcode_read 0xfc5e:
< HCI Command (0x3f|0x005e) plen 6 [hci0]
04 8c 00 00 02 04
> HCI Event (0x0e) plen 12 [hci0]
Unknown (0x3f|0x005e) ncmd 1
00 04 8c 00 00 2a 00 00 00
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
btintel_load_ddc_config retrieves the ddc file and sends its content
via DDC commands (opcode 0xfc8b).
The ddc file should contain one or more DDC structures.
A DDC structure is composed of the folowing fields:
field: | DDC LEN | DDC ID | DDC VALUE |
size: | 1 byte | 2 bytes | DDC LEN - 2 |
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix compilation the following compilation warning, which happens when
CONFIG_BT_INTEL is not set:
drivers/bluetooth/btintel.h:98:13: warning: ‘btintel_version_info’
defined but not used [-Wunused-function]
static void btintel_version_info(struct hci_dev *hdev,
struct intel_version *ver)
^
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
|
|
|
|
|
|
|
|
| |
The Intel version information is shared between USB and UART drivers
and with that move it into a generic function of the Intel module.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
|
|
|
|
|
|
| |
The Intel Secure Send command is used the same in USB and UART drivers
and with that move a generic version into the Intel module.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
|
|
|
|
|
|
|
|
| |
The handling of hardware error has support for providing a vendor
specific callback to deal with the error. Move the Intel specific
function out of the USB driver into the generic module so that it
can also be utilized by the UART driver.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
|
|
|
|
|
|
|
|
| |
The Intel vendors events indicating firmware loading result and the
bootup of the operational firmware are currently hardcoded byte
comparisons. So intead of doing that, provide proper data structures
and actually use them.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
|
|
|
|
|
|
| |
Since the Intel Bluetooth support has its own header, it makes sense
to move all command structs into it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The majority of Intel Bluetooth vendor commands are shared between USB
and UART transports. This creates a separate module that eventually
will hold all Intel specific commands, but for now just start with the
commands to change the Bluetooth public address and check for the
default address.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|