linux-toradex.git/include/net/bluetooth/l2cap.h, branch tegra-10.11.0 Linux kernel for Apalis and Colibri modules Bluetooth: Add BT_POWER L2CAP socket option. 2010-11-10T23:59:50+00:00 Jaikumar Ganesh jaikumar@google.com 2010-11-10T03:07:45+00:00 901204dc1797ec61c066ce9afecc56d6e874c187 Add BT_POWER socket option used to control the power characteristics of the underlying ACL link. When the remote end has put the link in sniff mode and the host stack wants to send data we need need to explicitly exit sniff mode to work well with certain devices (For example, A2DP on Plantronics Voyager 855). However, this causes problems with HID devices. Hence, moving into active mode when sending data, irrespective of who set the sniff mode has been made as a socket option. By default, we will move into active mode. HID devices can set the L2CAP socket option to prevent this from happening. Currently, this has been implemented for L2CAP sockets. This has been tested with incoming and outgoing L2CAP sockets for HID and A2DP. Based on discussions on linux-bluetooth and patches submitted by Andrei Emeltchenko. Signed-off-by: Jaikumar Ganesh <jaikumar@google.com> 
Add BT_POWER socket option used to control the power
characteristics of the underlying ACL link. When the remote end
has put the link in sniff mode and the host stack wants to send
data we need need to explicitly exit sniff mode to work well with
certain devices (For example, A2DP on Plantronics Voyager 855).
However, this causes problems with HID devices.

Hence, moving into active mode when sending data, irrespective
of who set the sniff mode has been made as a socket option. By
default, we will move into active mode. HID devices can set the
L2CAP socket option to prevent this from happening.

Currently, this has been implemented for L2CAP sockets. This has been
tested with incoming and outgoing L2CAP sockets for HID and A2DP.

Based on discussions on linux-bluetooth and patches submitted by
Andrei Emeltchenko.

Signed-off-by: Jaikumar Ganesh <jaikumar@google.com>
Bluetooth: Use non-flushable pb flag by default for ACL data on capable chipsets. 2010-09-30T00:49:30+00:00 Nick Pelly npelly@google.com 2009-12-09T03:42:21+00:00 e4772bff4ae12c54e835c5cbf06a0439853d9f57 With Bluetooth 2.1 ACL packets can be flushable or non-flushable. This commit makes ACL data packets non-flushable by default on compatible chipsets, and adds the L2CAP_LM_FLUSHABLE socket option to explicitly request flushable ACL data packets for a given L2CAP socket. This is useful for A2DP data which can be safely discarded if it can not be delivered within a short time (while other ACL data should not be discarded). Note that making ACL data flushable has no effect unless the automatic flush timeout for that ACL link is changed from its default of 0 (infinite). Change-Id: Ie3d4befdeaefb8c979de7ae603ff5ec462b3483c Signed-off-by: Nick Pelly <npelly@google.com> 
With Bluetooth 2.1 ACL packets can be flushable or non-flushable. This commit
makes ACL data packets non-flushable by default on compatible chipsets, and
adds the L2CAP_LM_FLUSHABLE socket option to explicitly request flushable ACL
data packets for a given L2CAP socket. This is useful for A2DP data which can
be safely discarded if it can not be delivered within a short time (while
other ACL data should not be discarded).

Note that making ACL data flushable has no effect unless the automatic flush
timeout for that ACL link is changed from its default of 0 (infinite).

Change-Id: Ie3d4befdeaefb8c979de7ae603ff5ec462b3483c
Signed-off-by: Nick Pelly <npelly@google.com>
Revert "Bluetooth: Introduce L2CAP_LM_FLUSHABLE to allow flushing of ACL packets." 2010-09-30T00:49:30+00:00 Nick Pelly npelly@google.com 2010-03-09T20:08:00+00:00 a573f82deb59d887f256beb482f224071fcf9a2e This reverts commit d7897fd1e9fb3a5df0740dc2dc45ec94ca0965f2. Change-Id: I3401550b6dc97b683104e9fdac30a617a2db8c8e Signed-off-by: Nick Pelly <npelly@google.com> 
This reverts commit d7897fd1e9fb3a5df0740dc2dc45ec94ca0965f2.

Change-Id: I3401550b6dc97b683104e9fdac30a617a2db8c8e
Signed-off-by: Nick Pelly <npelly@google.com>
Bluetooth: Introduce L2CAP_LM_FLUSHABLE to allow flushing of ACL packets. 2010-09-30T00:49:23+00:00 Nick Pelly npelly@google.com 2009-12-09T03:42:21+00:00 8401653065a6c0adbf7f54e94f7ee1a85467f01c With Bluetooth 2.1 ACL packets can be flushable or non-flushable. This changes makes the default ACL packet non-flushable, and allows selection of flushable packets on a per-L2CAP socket basis with L2CAP_LM_FLUSHABLE. Note the HCI Write Automatic Flush Timeout command also needs to be issued to set the flush timeout to non-zero. Need to featurize this change to Bluetooth 2.1 chipsets only before pushing upstream. Signed-off-by: Nick Pelly <npelly@google.com> 
With Bluetooth 2.1 ACL packets can be flushable or non-flushable. This changes
makes the default ACL packet non-flushable, and allows selection of flushable
packets on a per-L2CAP socket basis with L2CAP_LM_FLUSHABLE.

Note the HCI Write Automatic Flush Timeout command also needs to be issued
to set the flush timeout to non-zero.

Need to featurize this change to Bluetooth 2.1 chipsets only before pushing
upstream.

Signed-off-by: Nick Pelly <npelly@google.com>
Bluetooth: Use 3-DH5 payload size for default ERTM max PDU size 2010-08-10T11:59:11+00:00 Mat Martineau mathewm@codeaurora.org 2010-08-05T22:54:27+00:00 db12d647ccc971ed120199dc7ea5be2b5887d328 The previous value of 672 for L2CAP_DEFAULT_MAX_PDU_SIZE is based on the default L2CAP MTU. That default MTU is calculated from the size of two DH5 packets, minus ACL and L2CAP b-frame header overhead. ERTM is used with newer basebands that typically support larger 3-DH5 packets, and i-frames and s-frames have more header overhead. With clean RF conditions, basebands will typically attempt to use 1021-byte 3-DH5 packets for maximum throughput. Adjusting for 2 bytes of ACL headers plus 10 bytes of worst-case L2CAP headers yields 1009 bytes of payload. This PDU size imposes less overhead for header bytes and gives the baseband the option to choose 3-DH5 packets, but is small enough for ERTM traffic to interleave well with other L2CAP or SCO data. 672-byte payloads do not allow the most efficient over-the-air packet choice, and cannot achieve maximum throughput over BR/EDR. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
The previous value of 672 for L2CAP_DEFAULT_MAX_PDU_SIZE is based on
the default L2CAP MTU.  That default MTU is calculated from the size
of two DH5 packets, minus ACL and L2CAP b-frame header overhead.

ERTM is used with newer basebands that typically support larger 3-DH5
packets, and i-frames and s-frames have more header overhead.  With
clean RF conditions, basebands will typically attempt to use 1021-byte
3-DH5 packets for maximum throughput.  Adjusting for 2 bytes of ACL
headers plus 10 bytes of worst-case L2CAP headers yields 1009 bytes
of payload.

This PDU size imposes less overhead for header bytes and gives the
baseband the option to choose 3-DH5 packets, but is small enough for
ERTM traffic to interleave well with other L2CAP or SCO data.
672-byte payloads do not allow the most efficient over-the-air
packet choice, and cannot achieve maximum throughput over BR/EDR.

Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Change default L2CAP ERTM retransmit timeout 2010-08-10T11:59:11+00:00 Mat Martineau mathewm@codeaurora.org 2010-08-05T22:54:20+00:00 fa235562fbde8703aabeeedfa0772f08608d1542 The L2CAP specification requires that the ERTM retransmit timeout be at least 2 seconds for BR/EDR connections. Signed-off-by: Mat Martineau <mathewm@codeaurora.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
The L2CAP specification requires that the ERTM retransmit timeout be at
least 2 seconds for BR/EDR connections.

Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Use __packed annotation 2010-07-21T17:39:13+00:00 Gustavo F. Padovan padovan@profusion.mobi 2010-07-19T05:00:13+00:00 66c853cc21bd387a9a2109dcf3b3d53cc9ee9edf To make net/ and include/net/ code consistent use __packed instead of __attribute__ ((packed)). Bluetooth subsystem was one of the last net subsys still using __attribute__ ((packed)). Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
To make net/ and include/net/ code consistent use __packed instead of
__attribute__ ((packed)). Bluetooth subsystem was one of the last net
subsys still using __attribute__ ((packed)).

Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Add Google's copyright to L2CAP 2010-07-21T17:39:12+00:00 Gustavo F. Padovan padovan@profusion.mobi 2010-07-16T19:18:39+00:00 5d8868ff3d11e3fc5a5c07477f281a16c71714a3 Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Add Copyright notice to L2CAP 2010-07-21T17:39:11+00:00 Gustavo F. Padovan padovan@profusion.mobi 2010-07-13T14:57:11+00:00 ce5706bd69be6b25715ed6cd48a210b5080032bc Copyright for the time I worked on L2CAP during the Google Summer of Code program. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
Copyright for the time I worked on L2CAP during the Google Summer of Code
program.

Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Bluetooth: Remove the send_lock spinlock from ERTM 2010-07-21T17:39:09+00:00 Gustavo F. Padovan padovan@profusion.mobi 2010-06-21T21:50:49+00:00 e0f66218b3a7d0bcf37ca95186123c257fda0ba5 Using a lock to deal with the ERTM race condition - interruption with new data from the hci layer - is wrong. We should use the native skb backlog queue. Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> 
Using a lock to deal with the ERTM race condition - interruption with
new data from the hci layer - is wrong. We should use the native skb
backlog queue.

Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>