| Age | Commit message (Collapse) | Author |
|---|
|
This header file is not intended for applications, rather than for
drivers, so move it to the appropriate place.
Change-Id: I7ff8158418e7e839b538c6cccbb32f3af43c12c6
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>
|
|
$srctree for the application might not be set to be $ZEPHYR_BASE, use
$ZEPHYR_BASE instead to be more explicit in the build.
Change-Id: Iefa5ff59f246b584949329044f7a6531adc6ed62
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
|
|
Change-Id: I10a7cab9a7f911b9f64e17bf24ddce82c2f08c40
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
By calling the microkernel entry point 'main' there's no need to have
extra hacks to share the same c-file with both nano and micro
configurations.
Change-Id: I6623855a87ef8624b2bddb75b95079521e0eab8b
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
This is more of a convenience to let the driver identify itself in
debug logs and the monitor protocol.
Change-Id: I73351477e98d45d6344c180b8088bde29df6f7d9
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
The bus that we notify over the monitor protocol is really driver
specific, so let each driver specify their bus type.
Change-Id: Ic3a086fcc06352dbf051e52cef5bf6b8696349ae
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>
|
|
Use common config for tests and use testcase.ini for defining micro
and nano kernel variants.
Change-Id: I47453cd49696dd496cc728cc1eb2eba9cf7f1c6c
Signed-off-by: Szymon Janc <ext.szymon.janc@tieto.com>
|
