Hi Marcel,
On Wed, Jun 29, 2011 at 3:58 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
> Hi Antti,
>
>> Add command to management interface for enabling/disabling the
>> fast connectable mode.
>>
>> Signed-off-by: Antti Julku <antti.julku@xxxxxxxxx>
>> ---
>> include/net/bluetooth/hci.h | 10 +++++++
>> include/net/bluetooth/mgmt.h | 5 +++
>> net/bluetooth/mgmt.c | 60 ++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 75 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
>> index 65345cd..d7b9600 100644
>> --- a/include/net/bluetooth/hci.h
>> +++ b/include/net/bluetooth/hci.h
>> @@ -698,6 +698,16 @@ struct hci_rp_read_bd_addr {
>> bdaddr_t bdaddr;
>> } __packed;
>>
>> +#define HCI_OP_WRITE_PAGE_SCAN_ACTIVITY 0x0c1c
>> +struct hci_cp_write_page_scan_activity {
>> + __le16 interval;
>> + __le16 window;
>> +} __packed;
>> +
>> +#define HCI_OP_WRITE_PAGE_SCAN_TYPE 0x0c47
>> + #define PAGE_SCAN_TYPE_STANDARD 0x00
>> + #define PAGE_SCAN_TYPE_INTERLACED 0x01
>> +
>> #define HCI_OP_LE_SET_EVENT_MASK 0x2001
>> struct hci_cp_le_set_event_mask {
>> __u8 mask[8];
>> diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.h
>> index 45bea25..7196d04 100644
>> --- a/include/net/bluetooth/mgmt.h
>> +++ b/include/net/bluetooth/mgmt.h
>> @@ -209,6 +209,11 @@ struct mgmt_cp_unblock_device {
>> bdaddr_t bdaddr;
>> } __packed;
>>
>> +#define MGMT_OP_SET_FAST_CONNECTABLE 0x001F
>> +struct mgmt_cp_set_fast_connectable {
>> + __u8 enable;
>> +} __packed;
>> +
>
> so I am not 100% sure that doing it this way is the best way.
>
> What is the down side of just enabling interlaced page scan all the
> time? And then maybe allow tuning of the timeout via debugfs for testing
> purposes.
This mode changes two parameters: page scan type and page scan
interval. There two downsides to have those changed all the time:
1) power consumption
2) re-transmissions on eSCO channel (see BT Core v4.0, Vol. 2, p. 159)
In this configuration page scanning happening during all dedicated
slots and much more frequently. This is why probably it is not very
good idea to have it enabled all the time, but only during short time
interval when there are benefits out of such changes.
> If we really wanna differentiate between connectable and fast
> connectable, then we need to fix up also the controller information to
> export this kind of detail. That will get pretty messy right now. So I
> would really just prefer to go with interlaced page scan by default and
> see what downside this gives us.
This is the way how fast connectable implementation is done currently
for hci_ops. It is disabled by default and default values for page
scan type and page scan interval are used. If one wishes to enable it,
audio.conf is used for that purpose. In that case, fast connectable
configuration is enabled during incoming/outgoing call alerting only.
In this case, connection initiated from headset side can be performed
much faster during that specific time interval.
Hope this clarifies the questions. What do you think? Could you
elaborate more on 'then we need to fix up also the controller
information to export this kind of detail.'? Why that is needed?
BR,
Dmitriy
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
