From: Ville Tervo <ville.tervo@nokia.com>
To: ext Mike Tsai <Mike.Tsai@Atheros.com>
Cc: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: [RFC] Interface to set LE connection parameters
Date: Tue, 16 Nov 2010 10:56:47 +0200 [thread overview]
Message-ID: <20101116085647.GG16464@null> (raw)
In-Reply-To: <35B17FE5076C7040809188FBE7913F98406D465470@SC1EXMB-MBCL.global.atheros.com>
Hi Mike,
n Mon, Nov 15, 2010 at 07:15:44PM +0100, ext Mike Tsai wrote:
> Hi Ville,
>
> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Ville Tervo
> Sent: Monday, November 15, 2010 4:07 AM
> To: linux-bluetooth@vger.kernel.org
> Subject: [RFC] Interface to set LE connection parameters
>
> Hi,
>
> LE profiles have different requirements for connection parameters. Mainly
> trying to balance between power consumption and latencies. Probably more will
> factors will be in future.
>
> Currently I have plan to introduce new l2cap socket option which can be used
> before connection creation to set inital settings and also change settings
> while having a connection.
>
> Since there is no equivalents in EDR/BR connection I'm planning to make then
> apply only LE connection.
>
>
> Other question which parameters should be exposed to user space? Connection
> creation and connection update have these common parameters. Connection
> creation has in addition some other parameters also but they should be handled
> in some other way.
>
> __le16 conn_interval_min;
> __le16 conn_interval_max;
> __le16 conn_latency;
> __le16 supervision_timeout;
> __le16 min_ce_len;
> __le16 max_ce_len;
>
> So far I have had two ideas. The first is to simply expose all these fields
> with sock_opt. In that way profiles would be able to define their requirements
> also in future without any sock opt changes.
>
> Second is to define BT_LE_LOW_LAT for low latency connection requirements and
> BT_LE_LOW_POWER connection where the latency is not an issue. It would make
> usage of this sock opt interface simplier. OTOH the only user should be
> bluetoothd so it doesn't need to be as simple as possible.
>
>
> Comments please.
>
> [MTsai] - how about following parameters,
>
> Scan internal,
> Scan window,
> Peer address type,
These are connection creation parameters. Maybe BT_LE_LOW_LAT/BT_LE_LOW_POWER
could be used also for these values. But I think they should defined in some
other way.
--
Ville
prev parent reply other threads:[~2010-11-16 8:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-15 12:06 [RFC] Interface to set LE connection parameters Ville Tervo
2010-11-15 14:24 ` tim.howes
2010-11-15 15:17 ` Ville Tervo
2010-11-16 9:56 ` tim.howes
2010-11-18 15:15 ` Luiz Augusto von Dentz
2010-11-30 1:37 ` Gustavo F. Padovan
2010-11-15 18:15 ` Mike Tsai
2010-11-16 8:56 ` Ville Tervo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101116085647.GG16464@null \
--to=ville.tervo@nokia.com \
--cc=Mike.Tsai@Atheros.com \
--cc=linux-bluetooth@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.