-
Notifications
You must be signed in to change notification settings - Fork 33
SPP: add credits control for recv data #451
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
||
| spp_conn_unlock(); | ||
|
|
||
| bt_rfcomm_dlc_update_credits(&spp_conn->rfcomm_dlc); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When the underlying RFCOMM layer receives a message (rfcomm_recv), it has already updated the credit. Why is it necessary to update the credit again at the SAL layer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SPP's data flow control is handled in the Bluetooth service, while the HFP module's rfcomm maintains protocol stack flow control.
e92d430 to
a6a94dd
Compare
a6a94dd to
6b694a7
Compare
6b694a7 to
f017ad0
Compare
bug: v/85608 rootcause: Adding SPP process handling to the bluetooth service resolves the issue of non-flow control data piling up in the protocol stack. Signed-off-by: Kai Cheng <chengkai@xiaomi.com>
bug: v/85788 rootcause: enable spp rx credits mode control, in order to fix HFP/AG not auto credits Signed-off-by: Kai Cheng <chengkai@xiaomi.com>
f017ad0 to
6ff3d52
Compare
bug: v/85608
rootcause: Adding SPP process handling to the bluetooth service resolves the issue of non-flow control data piling up in the protocol stack.
Summary
Adding SPP process handling to the bluetooth service resolves the issue of non-flow control data piling up in the protocol stack.
Impact
spp rx data
Testing
test spp rx pass