[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <600aa8db-6cfd-0e62-7936-e14c4a8c70ed@quicinc.com>
Date: Thu, 9 Jun 2022 16:47:36 +0800
From: quic_zijuhu <quic_zijuhu@...cinc.com>
To: Paul Menzel <pmenzel@...gen.mpg.de>
CC: <marcel@...tmann.org>, <johan.hedberg@...il.com>,
<luiz.dentz@...il.com>, <davem@...emloft.net>,
<edumazet@...gle.com>, <kuba@...nel.org>, <pabeni@...hat.com>,
<linux-kernel@...r.kernel.org>, <linux-bluetooth@...r.kernel.org>,
<linux-arm-msm@...r.kernel.org>
Subject: Re: [PATCH v1] Bluetooth: hci_sync: Fix setup CVSD SCO failure
On 6/9/2022 4:15 PM, Paul Menzel wrote:
> Dear Zijun,
>
>
> Thank you for your patch.
>
> Am 09.06.22 um 10:10 schrieb Zijun Hu:
>
> Maybe for the summary:
>
> Bluetooth: Fix CVSD SCO setup failure
>
>> It will setup SCO after all CVSD eSCO attempts failure, but
>
will correct it within v2 patch
> The verb is spelled with a space: set up
>
>> still fails to setup SCO finally due to wrong D1/D0 @retrans_effort
>
> Ditto.
>
see above reply
>> within @esco_param_cvsd, so change it from 0x1 to 0xff to avoid
>> Invalid HCI Command Parameters error.
>>
>> < HCI Command: Setup Synchrono.. (0x01|0x0028) plen 17 #3427
>> Handle: 3
>> Transmit bandwidth: 8000
>> Receive bandwidth: 8000
>> Max latency: 65535
>> Setting: 0x0060
>> Input Coding: Linear
>> Input Data Format: 2's complement
>> Input Sample Size: 16-bit
>> # of bits padding at MSB: 0
>> Air Coding Format: CVSD
>> Retransmission effort: Optimize for power consumption (0x01)
>> Packet type: 0x03c4
>> HV3 may be used
>> 2-EV3 may not be used
>> 3-EV3 may not be used
>> 2-EV5 may not be used
>> 3-EV5 may not be used
>>> HCI Event: Command Status (0x0f) plen 4 #3428
>> Setup Synchronous Connection (0x01|0x0028) ncmd 1
>> Status: Success (0x00)
>>> HCI Event: Synchronous Connect Comp.. (0x2c) plen 17 #3429
>> Status: Invalid HCI Command Parameters (0x12)
>> Handle: 0
>> Address: 14:3F:A6:47:56:15 (OUI 14-3F-A6)
>> Link type: SCO (0x00)
>> Transmission interval: 0x00
>> Retransmission window: 0x00
>> RX packet length: 0
>> TX packet length: 0
>> Air mode: u-law log (0x00)
>
> What is your test setup to reproduce it?
>
this issue is reported by our tester.
this issue only happens with some kinds of headsets which says it support eSCO but seems no actually.
it can be reproduced by UBUNTU BT settings UI
D1/D0 @retrans_effort within @esco_param_cvsd are wrong compared with present below definition:
static const struct sco_param sco_param_cvsd[] = {
{ EDR_ESCO_MASK | ESCO_HV3, 0xffff, 0xff }, /* D1 */
{ EDR_ESCO_MASK | ESCO_HV1, 0xffff, 0xff }, /* D0 */
};
additionally, based on BT core spec:
0x00 No retransmissions (SCO or eSCO connection allowed)
0x01 At least one retransmission, optimize for power consumption (eSCO connection required).
0x02 At least one retransmission, optimize for link quality (eSCO connection
required)
0xFF Don’t care (SCO or eSCO connection allowed)
All other values Reserved for future use
for SCO, @retrans_effort is 0x00 or 0xff, must not be 0x01.
thanks
>> Signed-off-by: Zijun Hu <quic_zijuhu@...cinc.com>
>> ---
>> net/bluetooth/hci_conn.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
>> index 7829433d54c1..2627d5ac15d6 100644
>> --- a/net/bluetooth/hci_conn.c
>> +++ b/net/bluetooth/hci_conn.c
>> @@ -45,8 +45,8 @@ static const struct sco_param esco_param_cvsd[] = {
>> { EDR_ESCO_MASK & ~ESCO_2EV3, 0x000a, 0x01 }, /* S3 */
>> { EDR_ESCO_MASK & ~ESCO_2EV3, 0x0007, 0x01 }, /* S2 */
>> { EDR_ESCO_MASK | ESCO_EV3, 0x0007, 0x01 }, /* S1 */
>> - { EDR_ESCO_MASK | ESCO_HV3, 0xffff, 0x01 }, /* D1 */
>> - { EDR_ESCO_MASK | ESCO_HV1, 0xffff, 0x01 }, /* D0 */
>> + { EDR_ESCO_MASK | ESCO_HV3, 0xffff, 0xff }, /* D1 */
>> + { EDR_ESCO_MASK | ESCO_HV1, 0xffff, 0xff }, /* D0 */
>> };
>> static const struct sco_param sco_param_cvsd[] = {
>
>
> Kind regards,
>
> Paul
Powered by blists - more mailing lists