On Wed, Feb 3, 2010 at 12:20 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
> Hi Nick,
>
>> >> >> If I understand correctly, conn->power_save prevents the host stack
>> >> >> from requesting active mode if it was not the host stack that
>> >> >> requested sniff mode.
>> >> >>
>> >> >> I don't understand the motivation for this. If we have ACL data to
>> >> >> send, then it seems like a good idea for the host stack to explicitly
>> >> >> request active mode, regardless of the reason that we entered sniff
>> >> >> mode.
>> >> >>
>> >> >> We want to enter active mode more aggressively when setting up SCO
>> >> >> connections, to avoid a 5 second delay with certain sniff modes. But
>> >> >> the conn->power_save code is getting in the way and doesn't appear to
>> >> >> be useful in the first place.
>> >> >
>> >> > we have discussed this a few times. And if you lock through the code
>> >> > history then you see that initially we just took devices out of sniff
>> >> > mode if we had to send data. However with HID devices this falls flat on
>> >> > its face. They need to stay in control of sniff mode if they initiated
>> >> > it. Some of them crash and others just drain the battery. With sniff
>> >> > mode you can send small amounts of data even while in sniff and for HID
>> >> > that is sometimes used. So the remote side better not interfere.
>> >> >
>> >> > What we really need is a socket option where we can control this on a
>> >> > per socket basis if we take devices out of sniff mode. And one extra
>> >> > case might be when we try to establish a SCO channel, because then it is
>> >> > clearly not an HID device. However even A2DP has this sort of problems
>> >> > sometimes where the stream setup takes time.
>> >>
>> >> Makes sense. Thanks for the explanation.
>> >
>> > this means you will be working on a patch for this :)
>> >
>> >> > Not sure if we have to make SCO setup special. The only reason would be
>> >> > if there is a case where we don't get an AT command before SCO needs to
>> >> > be established.
>> >>
>> >> If you are in-call, and transfer audio from handset to BT headset,
>> >> then there is SCO setup without any AT command.
>> >
>> > Fair enough.
>> >
>> >> I think for the SCO setup case we would always want to enter active
>> >> mode. I could modify enter_active_mode() to take a parameter like 'int
>> >> force' that would force us to enter active mode regardless of the
>> >> state of power_save, and use this when setting up SCO. What do you
>> >> think?
>> >
>> > Actually when you leave sniff mode, then all bets for the power_save
>> > value are off again. So you better set power_save and just call
>> > enter_active_mode. Something like this:
>> >
>> > diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
>> > index a975098..e4591e0 100644
>> > --- a/net/bluetooth/hci_conn.c
>> > +++ b/net/bluetooth/hci_conn.c
>> > @@ -376,6 +376,9 @@ struct hci_conn *hci_connect(struct hci_dev *hdev, int type,
>> >
>> > if (acl->state == BT_CONNECTED &&
>> > (sco->state == BT_OPEN || sco->state == BT_CLOSED)) {
>> > + acl->power_save = 1;
>> > + hci_conn_enter_active_mode(acl);
>> > +
>> > if (lmp_esco_capable(hdev))
>> > hci_setup_sync(sco, acl->handle);
>> > else
>> >
>> > Alternatively we could create hci_conn_force_active_mode() or just
>> > implement a proper per socket sniff/active policy.
>> >
>>
>> Patch submitted to Android tree as:
>>
>> http://android.git.kernel.org/?p=kernel/common.git;a=commit;h=201ac2f225a31dffcb05f1db4d609c467c9c694c
>
> can you please send a version to the mailing list so I can easily apply
> it and also have it here for reference in the archives.
Patch attached.
Nick
Attachment:
0001-Bluetooth-Enter-active-mode-before-establishing-a-SC.patch
Description: Binary data
