linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ville Tervo <ville.tervo@nokia.com>
To: "ext tim.howes@accenture.com" <tim.howes@accenture.com>
Cc: "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: [RFC] Interface to set LE connection parameters
Date: Mon, 15 Nov 2010 17:17:39 +0200	[thread overview]
Message-ID: <20101115151739.GD16464@null> (raw)
In-Reply-To: <1AFE20D16950C745A2A83986B72E8748011F571E6CE6@EMEXM3131.dir.svc.accenture.com>

Hi Tim,

Please stop top posting on this ml.

On Mon, Nov 15, 2010 at 03:24:29PM +0100, ext tim.howes@accenture.com wrote:
> Hi Ville,
> 
> As you note the different profiles would likely have different connection parameters.  The different profiles may be running on the same LE link (indeed the same L2CAP [fixed] channel).
> 

I guess the latency should override power requirements. Low power profile can
operate on low latency link but low latency profile fails on high latency. Of
course this gets much more complicated if there are more requirements.

Are these (latency and power) the only characteristics we need to deal with.
There might be some also. I'm not too familiar with profile drafts.

> Do you have a view on how the different profiles - on the same link - would have different requests arbitrated, and where that arbitration would be done?  I'd imagine that the API towards the profiles should be of the abstract form - such as you mention (eg BT_LE_LOW_LAT).  This would make it easier to arbitrate the different requests, as compared to if the profiles see an API of the "numerical" form (eg interval = N ms).  I guess the arbitration could happen in user or kernel space; as long as there is something with singleton-like semantics to do it.
> 

I think I need to get more details from profile specs and try to find out the
requirements from them.

Right now I'm trying to find out what would be the right interface from kernel
to user space. 

> Also - a quick observation: yes, the connection parameters are only for LE links; however they have some semantic similarity with sniff mode in BR. Especially in the abstract form ("Low Latency" verus "Low Power").  Does BlueZ present an API like this already for BR (I'm new to BlueZ...I was more of a Symbian guy ;)?  If not it might be worth having one API for both BR/Sniff and LE/Connection Parameters - and do the appropriate mapping "under the hood".  

Actually this has been discussed earlier and we need also some api to change
sniff behaviour. Reason for this is broken devices which does not turn on
normal mode when low latency is needed. I guess Jaikumar had some patches
regarding this?

-- 
Ville

  reply	other threads:[~2010-11-15 15:17 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 [this message]
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

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=20101115151739.GD16464@null \
    --to=ville.tervo@nokia.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=tim.howes@accenture.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).