From: David Vrabel <david.vrabel@csr.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: tmonahan@codeaurora.org, Inga Stotland <ingas@codeaurora.org>,
linux-bluetooth@vger.kernel.org, rshaffer@codeaurora.org,
johan.hedberg@gmail.com
Subject: Re: Enhancements to allow l2cap channel to use either AMP or BR/EDR
Date: Tue, 03 Aug 2010 13:59:10 +0100 [thread overview]
Message-ID: <4C58129E.3080306@csr.com> (raw)
In-Reply-To: <1280775200.12579.30.camel@localhost.localdomain>
Marcel Holtmann wrote:
>
> That said, nothing stops us from allowing to make our AMP polices
> dynamic and allow the application to change it threshold during
> lifetime. For example it starts out as BR/EDR only and then during the
> usage of the link it decides that now AMP preferred would make sense. In
> that sense you would have manual switching to some level.
If the policy is dynamic throughout the lifetime of the connection then
that's okay for best effort links.
I think applications (especially those that stream real-time data at
high rates) will need to know the currently available bandwidth. This
will be useful for even simple file transfer profiles -- if that file
transfer is going to take 100x as long the user probably want to know
about this so they can (for example) turn HS mode on the other device.
This information could be conveyed in some sort of "channel move
complete" event or a more generic "available bandwidth changed" event.
Applications requiring guaranteed links will need some way of supplying
extended flow specifications.
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
next prev parent reply other threads:[~2010-08-03 12:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-02 16:55 Enhancements to allow l2cap channel to use either AMP or BR/EDR tmonahan
2010-08-02 18:53 ` Marcel Holtmann
2010-08-02 22:41 ` Kevin Hayes
2010-08-02 22:58 ` Marcel Holtmann
2010-08-03 0:51 ` Kevin Hayes
[not found] ` <B7132A25476D334D9130FE7532F2A56310A0B08A61@SC1EXMB-MBCL.global.athero s.com>
2010-08-03 1:30 ` Peter Krystad
2010-08-03 1:59 ` Marcel Holtmann
2010-08-03 8:07 ` Gustavo F. Padovan
2010-08-03 13:40 ` Tim Monahan-Mitchell
2010-08-03 1:59 ` Marcel Holtmann
2010-08-03 4:47 ` Kevin Hayes
2010-08-03 12:59 ` David Vrabel [this message]
2010-08-03 16:14 ` Marcel Holtmann
-- strict thread matches above, loose matches on Subject: below --
2010-07-30 18:30 Inga Stotland
2010-08-02 12:04 ` David Vrabel
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=4C58129E.3080306@csr.com \
--to=david.vrabel@csr.com \
--cc=ingas@codeaurora.org \
--cc=johan.hedberg@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=rshaffer@codeaurora.org \
--cc=tmonahan@codeaurora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox