Use this short header style in all Kconfig files:
# <description>
# <copyright>
# <license>
...
Also change all <description>s from
# Kconfig[.extension] - Foo-related options
to just
# Foo-related options
It's clear enough that it's about Kconfig.
The <description> cleanup was done with this command, along with some
manual cleanup (big letter at the start, etc.)
git ls-files '*Kconfig*' | \
xargs sed -i -E '1 s/#\s*Kconfig[\w.-]*\s*-\s*/# /'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
In order to generalize the currently specialized nRF51 IC setup hook,
make the following changes:
- Generalize the hook to bt_ic_setup()
- Use a weak NOP version by default
- Move the currently existing one to the board folder
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Rename the BT_CONTROLLER prefix used in all of the Kconfig variables
related to the Bluetooth controller to BT_CTLR.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
It used to be that there was a fairly empty "Bluetooth Drivers" menu
entry in the drivers menu. This entry was present even though there
was no drivers/bluetooth code being compiled in.
With this patch "Bluetooth Drivers" will no longer be present when
BT_CONTROLLER is enabled.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
The CONFIG_BT_WAIT_NOP define is used only by
zephyr/subsys/bluetooth/host/hci_core.c.
It is also the only config in drivers/bluetooth that is in use when
BT_CONTROLLER is enabled. Moving it into the bluetooth subsystem
allows us to restructure the drivers/kconfig code such that the entire
Bluetooth driver menu option is omitted when the BT_CONTROLLER is
enabled.
Moving it will also mean that all configs in drivers/bluetooth will
now be related to configuring the source code in drivers/bluetooth.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
The API name space for Bluetooth is bt_* and BT_* so it makes sense to
align the Kconfig name space with this. The additional benefit is that
this also makes the names shorter. It is also in line with what Linux
uses for Bluetooth Kconfig entries.
Some Bluetooth-related Networking Kconfig defines are renamed as well
in order to be consistent, such as NET_L2_BLUETOOTH.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Replace the existing Apache 2.0 boilerplate header with an SPDX tag
throughout the zephyr code tree. This patch was generated via a
script run over the master branch.
Also updated doc/porting/application.rst that had a dependency on
line numbers in a literal include.
Manually updated subsys/logging/sys_log.c that had a malformed
header in the original file. Also cleanup several cases that already
had a SPDX tag and we either got a duplicate or missed updating.
Jira: ZEP-1457
Change-Id: I6131a1d4ee0e58f5b938300c2d2fc77d2e69572c
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Restructure the Bluetooth options more logically.
- Both host and controller are now behind the same high level
CONFIG_BLUETOOTH.
- Selecting controller support disables other HCI driver selection, so
the controller isn't in the same list as HCI drivers any more.
- Under the top-level there's a "Custom stack" option, which when
enabled opens up the option of choosing CONFIG_NBLE.
There are various other cleanups and simplifications in this patch as
well, since splitting these up would have been fairly tricky while
making sure all test cases still build.
Change-Id: I5bb715cb9d20201cb8b72fbd149c8a09a4b2d7d2
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Move controller code from drivers/controller to
subsys/bluetooth/controller.
Change-Id: I73f675188485aa3267507bad7647796e593a3da0
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
These options were only needed for a MyNewt-based nRF51 firmware on
these boards (the MyNewt BLE stack is called Nimble, hence the
prj_nimble.conf sample config files). With a Zephyr-based nRF51
firmware these options are no-longer needed, so it's not appropriate
to have them default to enabled. Instead, if they are needed, require
the app-specific configuration to enable them.
Change-Id: Iefbee4d97590af4e11bcedea05fe61f32a147b83
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The bt_driver API was created when Zephyr only had a Bluetooth host
stack, but no controller-side functionality. The only "driver" that
was needed for the host was the HCI driver, and hence "HCI" was
omitted from the name.
With support both for host and controller Zephyr will be getting more
Bluetooth driver types, in particular radio drivers. To prepare for
this, move all HCI drivers to drivers/bluetooth/hci/ and rename the
bt_driver API bt_hci_driver.
Change-Id: I82829da80aa61f26c2bb2005380f1e88d069ac7d
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The drivers/bluetooth/controller path adds a native BLE Link
Layer (controller and HCI) to the Bluetooth subsystem. This first
implementation adds support for the nRF5x series of devices
from Nordic Semiconductor. The hal/ folder inside the controller
contains all IC-specific code to interface with the radio and
baseband.
Jira: ZEP-702
Origin: Original
Change-Id: I4ed61d5f67af6b4735d746a38a5b55f054521075
Signed-off-by: Vinayak Chettimada <vinayak.kariappa.chettimada@nordicsemi.no>
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
HCI RAW channel API is intended to expose HCI interface to the remote
entity. The local Bluetooth controller gets owned by the remote entity
and host Bluetooth stack is not used. RAW API provides direct access
to packets which are sent and received by Bluetooth HCI drivers.
Change-Id: I4ba2b7ca2c2b0d6c5de6ef1f231d1c5b82125e09
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
This replaces the use of delayed fiber with delayed work which doesn't
require extra stacks.
Change-Id: I3db0c168baabea2503163e26020bf5e4971ce584
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Convert leading whitespace into tabs in Kconfig files. Also replaced
double spaces between config and <prompt>.
Change-Id: I341c718ecf4143529b477c239bbde88e18f37062
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Some controllers will emit an initial "NOP" Command Complete event
during initialization and expect the host to only send commands once
this event has been received. This patch adds a new Kconfig option to
be used in the case of such controllers and defaults this to true on
Arduino 101 with the H:4 driver where this behavior is currently
observed.
Change-Id: I440f14a7c07ac27545febf9f85ebcc343e2a4558
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
So far the assumption has been that the host stack manages all
incoming and outgoing buffers. For the incoming buffers (from the
controller) this has required hci_core.c to manage its own pools and
do the host flow control. This setup makes perfect sense for an
architecture where the controller resides remotely on a different CPU
& address space (i.e. the "traditional" HCI transport case).
When the stack runs on a system where the controller resides in the
same address space this setup doesn't work that well. In such a
scenario the incoming buffers are ideally created as low down in the
stack as possible (i.e. below HCI), which means that the current
hci_core.c cannot be responsible for managing their pools.
To allow for both types of architectures this patch introduces a new
BLUETOOTH_HOST_BUFFERS Kconfig option that can be selected to say that
host-side management is desired, or deselected to say that the
controller (residing in the same address space) takes care of managing
the incoming buffers.
So far the incoming buffer types were identified by hci_core.c by
looking at their "free pool" pointers, however as soon as the pools
are allowed to be somewhere else this doesn't work. To solve this we
now require a minimum user data size for all Bluetooth buffers and use
that to store the buffer type.
Change-Id: I14bc32007e3e3f17c654f71f79b520650028d7ce
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Clarify the name of the option and add a dependency to Arduino 101
which is the only known board that is currently known to need it.
Change-Id: Ibfb96cba202f34464b45b922da599da70c038d12
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The config option handles enabling, disabling and power management
operations with Nordic nRF51 BLE chip.
Change-Id: I816062a7fb17c9e57c234113a2cecdebceb407b6
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Move NBLE code to the place where other Bluetooth drivers code resides.
Change-Id: Ibcf9ffb016e9b842bed66a61dff5c101b1573aaa
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
There are two major issues with the kconfig:
() Some of the config options have incorrect dependencies inside help
under menuconfig. For example, CONFIG_GPIO depends on BOARD_GALILEO.
() Since the SoC and board specific kconfig files are parsed first,
the help screen would say, for example, CONFIG_SPI is defined at
arch/arm/soc/fsl_frdm_k64f/Kconfig. This is incorrect because
the actual config is defined in drivers/spi/Kconfig.
These cause great confusion to users of menuconfig/xconfig.
To fix these, the SoC and board defaults are now to be parsed last.
Note that the position swapping of defaults in this patch is due to
the fact the the default parsed last will be used.
And, spi_test is broken due to the fact that it requires
CONFIG_SPI_INTEL_PORT_1, but never enables it anywhere. This is
bypassed for now.
Origin: refactored and edited from existing files
Change-Id: I2a4b1ae5be4d27e68c960aa47d91ef350f2d500f
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This moves both the Bluetooth HCI and NBLE drivers under
"Bluetooth Drivers" category. This also adds a selection for
choosing Bluetooth stacks as the bulk of both HCI and NBLE stacks
cannot be compiled together.
Note that this does not move the source files. That should be
done in a separate change.
Change-Id: I32fa7097ada0fdc52bcc745adb78c7273f4023c6
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The peripherals utilizing UART were required to register their own
ISR rountines. This means that all those peripherals drivers need
to know which IRQ line is attached to a UART controller, and all
the other config values required to register a ISR. This causes
scalibility issue as every board and peripherals have to define
those values.
Another reason for this patch is to support virtual serial ports.
Virtual serial ports do not have physical interrupt lines to
attach, and thus would not work.
This patch adds a simple callback mechanism, which calls a function
when UART interrupts are triggered. The low level plumbing still needs
to be done by the peripheral drivers, as these drivers may need to
access low level capability of UART to function correctly. This simply
moves the interrupt setup into the UART drivers themselves. By doing
this, the peripheral drivers do not need to know all the config values
to properly setup the interrupts and attaching the ISR. One drawback
is that this adds to the interrupt latency.
Note that this patch breaks backward compatibility in terms of
setting up interrupt for UART controller. How to use UART is still
the same.
This also addresses the following issues:
() UART driver for Atmel SAM3 currently does not support interrupts.
So remove the code from vector table. This will be updated when
there is interrupt support for the driver.
() Corrected some config options for Stellaris UART driver.
This was tested with samples/shell on Arduino 101, and on QEMU
(Cortex-M3 and x86).
Origin: original code
Change-Id: Ib4593d8ccd711f4e97d388c7293205d213be1aec
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Add initial code for three-wire (H5) Bluetooth uart driver.
At the moment the driver is EXPERIMENTAL. To test use following
method with qemu:
Run btproxy with three-wire emulation patches:
$ sudo tools/btproxy -d --pty -3
Opening pseudoterminal
New pts created: /dev/pts/21
Opening user channel for hci0
Notice that new device created: /dev/pts/21, use it with qemu -serial
parameter.
Run qemu target with following parameters:
$ make qemu 'QEMU_EXTRA_FLAGS=-serial /dev/pts/21'
Change-Id: I51579ffd8088583df9106689a03b2a0b4aa9e4cb
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Needed headroom depends on type of the UART driver, change it
accordingly.
Change-Id: Ic9bf5f08a49be6823fce5eff8139d5f949b313ca
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
We'll in the future also have a three-wire UART (H:5) HCI driver, so
the current H:4 driver cannot have a generic name.
Change-Id: Id326ae63d6f4d273d0d0c6120143e2f8d62968d1
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Use device name to find the UART device for Bluetooth usage,
instead of relying on an arbitrary index.
The default device names being used are derived from the original
board.h for each platform. Some of them point to the same device
as UART console. Since this is a Kconfig option, the default
can be overridden so this is not a serious issue.
Change-Id: Ibe82f3968e72ba60f9c033aa3dfcb2fb3c41dc75
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
We can remove the need for the extra 1-byte headroom by simply
directly writing the H:4 header with uart_poll_out(). Also the
separate uart_out() function can be removed by taking advantage of the
counters already present in the net_buf.
Change-Id: I54bd852e28f416b3de250cd9f8a126269cccfc14
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
We know the needed values at build-time, so there's no point in having
a runtime mechanism of accessing them in the code. Having the values
as defines makes it e.g. possible to use them as input for defining
the size of buffer pools.
Change-Id: Ib7556644719bfb631e638fa5bf29f3d1747a5072
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Change all the Intel and Wind River code license from BSD-3 to Apache 2.
Change-Id: Id8be2c1c161a06ea8a0b9f38e17660e11dbb384b
Signed-off-by: Javier B Perez Hernandez <javier.b.perez.hernandez@linux.intel.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Benjamin Walsh <benjamin.walsh@windriver.com>
The BLUETOOTH_DEBUG_UART config option should depend on BLUETOOTH_UART
and also be sorted after it in the hierarchy.
Change-Id: I3e049e52c2e353cd0c6f1a99ca8934a289e0cce8
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This commit add license headers to Kconfig files.
Change-Id: I79e60263b8c7b696463ecc84b8ad411af5415117
Signed-off-by: Juan Manuel Cruz <juan.m.cruz.alcaraz@linux.intel.com>
This commit organizes the bluetooth Ksymbols in:
- Driver symbols at drivers/bluetooth/Kconfig
- Stack symbols at net/bluetooth/Kconfig
Change-Id: I8ebadeb8ac7f8a769d7620e4e44077a05915dc86
Signed-off-by: Juan Manuel Cruz <juan.m.cruz.alcaraz@linux.intel.com>
This commit adds the Makefile and Kconfig files
to support the bluetooth driver in the Kbuild system.
Signed-off-by: Juan Manuel Cruz <juan.m.cruz.alcaraz@linux.intel.com>
Change-Id: I1f72b13aca8fb098eece04c4f0e1b680639b520f
Ulf Magnusson