Hi All,
I have a stlc2500c which is a Bluetooth 1.2 chip. When debuging
function 'hci_connect', i found the hci link type of the arguments was
SCO_LINK, because i enabled 'lmp_esco_capable' in my kernel, it call
'hci_setup_sync' to setup eSCO link.
struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t
*dst, __u8 auth_type)
{
.....
if (lmp_esco_capable(hdev))
{
hci_setup_sync(sco, acl->handle);
}
else
{
hci_add_sco(sco, acl->handle);
}
}
Hi All,
2009/3/31 Nick Pelly <[email protected]>:
> 2009/3/30 ???? <[email protected]>:
>> Hi All,
>> I made a mistake when writing the email, I have not complete my question.
>>
>> 2009/3/31 ???? <[email protected]>:
>>> Hi All,
>>> I have a stlc2500c which is a Bluetooth 1.2 chip. When debuging
>>> function 'hci_connect', i found the hci link type of the arguments was
>>> SCO_LINK, because i enabled 'lmp_esco_capable' in my kernel, it call
>>> 'hci_setup_sync' to setup eSCO link.
>>
>> But when i check connection by 'hcitool con', the hcitool show it was
>> a SCO link. So, is it a SCO link or eSCO link? Thanks.
>
> hcitool con will report eSCO if it is eSCO, so you have a SCO link.
>
> hci_setup_sync can be used for both SCO and eSCO, and the chipset
> and/or the host stack will fall back to SCO if eSCO parameters can not
> be negotiated. An LMP log will show why.
Maybe the function 'hci_sync_conn_complete_evt' matches what you said.
static inline void hci_sync_conn_complete_evt(struct hci_dev *hdev,
struct sk_buff *skb)
{
...
printk("hci_sync_conn_complete_evt, ev->link_type=%d\n",
ev->link_type); ------> ev->link_type=0
conn = hci_conn_hash_lookup_ba(hdev, ev->link_type, &ev->bdaddr);
printk("hci_sync_conn_complete_evt, conn=%p\n",
conn);-------------------------------> conn=00000000
if (!conn) {
if (ev->link_type == ESCO_LINK)
goto unlock;
conn = hci_conn_hash_lookup_ba(hdev, ESCO_LINK, &ev->bdaddr);
if (!conn)
goto unlock;
conn->type = SCO_LINK;----------------------------------------------------------------------->
fall back to SCO?
}
...
}
>
> Nick
>
LeiBian
BR
2009/3/30 ???? <[email protected]>:
> Hi All,
> I made a mistake when writing the email, I have not complete my question.
>
> 2009/3/31 ???? <[email protected]>:
>> Hi All,
>> I have a stlc2500c which is a Bluetooth 1.2 chip. When debuging
>> function 'hci_connect', i found the hci link type of the arguments was
>> SCO_LINK, because i enabled 'lmp_esco_capable' in my kernel, it call
>> 'hci_setup_sync' to setup eSCO link.
>
> But when i check connection by 'hcitool con', the hcitool show it was
> a SCO link. So, is it a SCO link or eSCO link? Thanks.
hcitool con will report eSCO if it is eSCO, so you have a SCO link.
hci_setup_sync can be used for both SCO and eSCO, and the chipset
and/or the host stack will fall back to SCO if eSCO parameters can not
be negotiated. An LMP log will show why.
Nick
Hi All,
I made a mistake when writing the email, I have not complete my question.
2009/3/31 ???? <[email protected]>:
> Hi All,
> I have a stlc2500c which is a Bluetooth 1.2 chip. When debuging
> function 'hci_connect', i found the hci link type of the arguments was
> SCO_LINK, because i enabled 'lmp_esco_capable' in my kernel, it call
> 'hci_setup_sync' to setup eSCO link.
But when i check connection by 'hcitool con', the hcitool show it was
a SCO link. So, is it a SCO link or eSCO link? Thanks.
> struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t
> *dst, __u8 auth_type)
> {
> .....
> if (lmp_esco_capable(hdev))
> {
> hci_setup_sync(sco, acl->handle);
> }
> else
> {
> hci_add_sco(sco, acl->handle);
> }
>
> }
>