A new driver is implemented to actively manage the bluetooth module power. bluesleep also tries to manage the power of the transport used. Two signals (GPIOs) are used to manage the power events. BT_WAKE : signal from HOST to BT chip to intimate BT chip can sleep. HOST_WAKE: signal from BT chip to HOST to intimate HOST should wakeup/ activate the transport modules required for BT communication. Bug 680524, 691608 (cherry picked from commit 111f4ccd3c4cfde2fa52ae4c0c56a2288c3af3a8) Change-Id: I5edba2aa18c566f0ebfc4ecf9c54149ee3376666 Reviewed-on: http://git-master/r/6850 Reviewed-by: Udaykumar Rameshchan Raval <uraval@nvidia.com> Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com> Reviewed-by: Anantha Idapalapati <aidapalapati@nvidia.com> Tested-by: Anantha Idapalapati <aidapalapati@nvidia.com>
This avoids the S305 panic during incoming connection. S305 sends PSM 25 L2CAP connection request before the L2CAP info response. When we receive that info response we crash on null pointer here. Bug: 2127637 Change-Id: Ib637516251f46fa9a9c87ac015dc2f27df5a27fd 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>
This reverts commit d7897fd1e9fb3a5df0740dc2dc45ec94ca0965f2. Change-Id: I3401550b6dc97b683104e9fdac30a617a2db8c8e Signed-off-by: Nick Pelly <npelly@google.com>
__u16 sco_pkt_type is introduced to struct sockaddr_sco. It allows bitwise selection of SCO/eSCO packet types. Currently those bits are: 0x0001 HV1 may be used. 0x0002 HV2 may be used. 0x0004 HV3 may be used. 0x0008 EV3 may be used. 0x0010 EV4 may be used. 0x0020 EV5 may be used. 0x0040 2-EV3 may be used. 0x0080 3-EV3 may be used. 0x0100 2-EV5 may be used. 0x0200 3-EV5 may be used. This is similar to the Packet Type parameter in the HCI Setup Synchronous Connection Command, except that we are not reversing the logic on the EDR bits. This makes the use of sco_pkt_tpye forward portable for the use case of white-listing packet types, which we expect will be the primary use case. If sco_pkt_type is zero, or userspace uses the old struct sockaddr_sco, then the default behavior is to allow all packet types. Packet type selection is just a request made to the Bluetooth chipset, and it is up to the link manager on the chipset to negiotiate and decide on the actual packet types used. Furthermore, when a SCO/eSCO connection is eventually made there is no way for the host stack to determine which packet type was used (however it is possible to get the link type of SCO or eSCO). sco_pkt_type is ignored for incoming SCO connections. It is possible to add this in the future as a parameter to the Accept Synchronous Connection Command, however its a little trickier because the kernel does not currently preserve sockaddr_sco data between userspace calls to accept(). The most common use for sco_pkt_type will be to white-list only SCO packets, which can be done with the hci.h constant SCO_ESCO_MASK. This patch is motivated by broken Bluetooth carkits such as the Motorolo HF850 (it claims to support eSCO, but will actually reject eSCO connections after 5 seconds) and the 2007/2008 Infiniti G35/37 (fails to route audio if a 2-EV5 packet type is negiotiated). With this patch userspace can maintain a list of compatible packet types to workaround remote devices such as these. Based on a patch by Marcel Holtmann. Change-Id: I304d8fda5b4145254820a3003820163bf53de5a5 Signed-off-by: Nick Pelly <npelly@google.com>
This reverts commit 8bf4794174659b06d43cc5e290cd384757374613. Change-Id: Ieaeed6866996446e0392e387b77b446361f23d46 Signed-off-by: Nick Pelly <npelly@google.com>
This reverts commit e2139b32726e5dd184974c785ea3f62026590801. Change-Id: Id948d5860840aaf85eca7d8894a7bb3192f0bb47 Signed-off-by: Nick Pelly <npelly@google.com>
This reverts commit 9e726b17422bade75fba94e625cd35fd1353e682. Change-Id: I3bc2e4caa2a0e0c36b9c7de4a09b03276adae4e1 Signed-off-by: Nick Pelly <npelly@google.com>
power_save is a feature to allow HID devices to control the sniff mode. Unfortunately it also prevents us exiting sniff mode on some A2DP devices that do not explicitly exit sniff mode themselves, resulting in skipping audio. Marcel is trying to finalize a setsockopt() API to control whether power_save is enabled on a per socket basis. In the mean-time, turn off power_save for Android, since we do not have official HID support, and this is causing problems for A2DP which we do support. (Note the power_save logic is reversed, 0 is on, 1 is off). Change-Id: Ife4478055128b81669bf49308d2e2199e1aa11a1 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>