Hello all,
Does anybody know if bluetooth 3.0 HS spec is supported in BlueZ?
Is AMP supported in BlueZ?
Thanks & Regards
Anurag
Hi Anurag,
* Anurag Gupta <[email protected]> [2011-04-19 23:06:57 +0530]:
> Hello all,
>
> Does anybody know if bluetooth 3.0 HS spec is supported in BlueZ?
> Is AMP supported in BlueZ?
There is two different implementations, one by Atheros and another by QuIC.
Both never reach upstream, if you look to the list logs you will find them.
--
Gustavo F. Padovan
http://profusion.mobi
Hi Mat,
On 5/20/2011 12:10 AM, Gustavo F. Padovan wrote:
> Hi Mat,
>
> * Mat Martineau<[email protected]> [2011-05-19 09:58:04 -0700]:
>
>>
>>
>> On Thu, 19 May 2011, Suraj Sumangala wrote:
>>
>>> Hi Mat,
>>>
>>> On 5/19/2011 2:28 AM, Mat Martineau wrote:
>>>>
>>>> Gustavo,
>>>>
>>>> On Mon, 9 May 2011, Gustavo F. Padovan wrote:
>>>>
>>
>> ... snip ...
>>
>>>>>
>>>>> Isn't Extended Flow Specification a required feature for AMP?
>>>>> I haven't seen
>>>>> it in your implementation.
>>>>
>>>> Extended Flowspec is needed to create an L2CAP channel directly on
>>>> AMP, but the implementation you're looking at does not implement the
>>>> "create channel" feature. Channels are created on BR/EDR and moved
>>>> to AMP, which does not require extended flowspec.
>>>>
>>>
>>> Why don't we have to use EFS for channels moved from BDR? Is it
>>> because we assume that the QoS provided by AMP will be better than
>>> BDR?
>>
>> Only "Best Effort" is supported by this implementation so QoS is
>> equivalent on either controller type. EFS is optional when creating
>> channels on BR/EDR, and the spec does not require EFS when moving to
>> a Best Effort AMP link. We've extensively interop'd AMP channel
>> moves without EFS.g
>
> Isn't EFS and Create Channel Command required to the qualification?
> In PTS when AMP Support and AMP Manager Channel are enabled tests
> for Create Channel and EFS are also enabled.
>
I also see test cases which require you to do L2CAP configure with EFS
and 'Best Effort' as the service type, Aren't they mandatory test cases?
But, I think what you said is correct. Here is what the spec say about it.
"Since the Identifier for an Extended Flow Specification with Service
Type Best Effort is fixed to 0x01 it is possible to generate a Best
Effort Extended Flow Specification for the remote device without
performing the Lockstep Configuration process"
Regards
Suraj
Hi Mat,
* Mat Martineau <[email protected]> [2011-05-19 09:58:04 -0700]:
>
>
> On Thu, 19 May 2011, Suraj Sumangala wrote:
>
> >Hi Mat,
> >
> >On 5/19/2011 2:28 AM, Mat Martineau wrote:
> >>
> >>Gustavo,
> >>
> >>On Mon, 9 May 2011, Gustavo F. Padovan wrote:
> >>
>
> ... snip ...
>
> >>>
> >>>Isn't Extended Flow Specification a required feature for AMP?
> >>>I haven't seen
> >>>it in your implementation.
> >>
> >>Extended Flowspec is needed to create an L2CAP channel directly on
> >>AMP, but the implementation you're looking at does not implement the
> >>"create channel" feature. Channels are created on BR/EDR and moved
> >>to AMP, which does not require extended flowspec.
> >>
> >
> >Why don't we have to use EFS for channels moved from BDR? Is it
> >because we assume that the QoS provided by AMP will be better than
> >BDR?
>
> Only "Best Effort" is supported by this implementation so QoS is
> equivalent on either controller type. EFS is optional when creating
> channels on BR/EDR, and the spec does not require EFS when moving to
> a Best Effort AMP link. We've extensively interop'd AMP channel
> moves without EFS.
Isn't EFS and Create Channel Command required to the qualification?
In PTS when AMP Support and AMP Manager Channel are enabled tests
for Create Channel and EFS are also enabled.
--
Gustavo F. Padovan
http://profusion.mobi
On Thu, 19 May 2011, Suraj Sumangala wrote:
> Hi Mat,
>
> On 5/19/2011 2:28 AM, Mat Martineau wrote:
>>
>> Gustavo,
>>
>> On Mon, 9 May 2011, Gustavo F. Padovan wrote:
>>
... snip ...
>>>
>>> Isn't Extended Flow Specification a required feature for AMP? I haven't
>>> seen
>>> it in your implementation.
>>
>> Extended Flowspec is needed to create an L2CAP channel directly on
>> AMP, but the implementation you're looking at does not implement the
>> "create channel" feature. Channels are created on BR/EDR and moved
>> to AMP, which does not require extended flowspec.
>>
>
> Why don't we have to use EFS for channels moved from BDR? Is it because we
> assume that the QoS provided by AMP will be better than BDR?
Only "Best Effort" is supported by this implementation so QoS is
equivalent on either controller type. EFS is optional when creating
channels on BR/EDR, and the spec does not require EFS when moving to a
Best Effort AMP link. We've extensively interop'd AMP channel moves
without EFS.
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
Hi Mat,
On 5/19/2011 2:28 AM, Mat Martineau wrote:
>
> Gustavo,
>
> On Mon, 9 May 2011, Gustavo F. Padovan wrote:
>
>> Hi Mat,
>>
>> * Mat Martineau<[email protected]> [2011-05-05 16:27:17 -0700]:
>>
>>>
>>> On Thu, 5 May 2011, Gustavo F. Padovan wrote:
>>>
>>>> Hi Arun,
>>>>
>>>> * Arun Kumar SINGH<[email protected]> [2011-05-05 09:26:58 +0200]:
>>>>
>>>>> Hi Gustavo,
>>>>>
>>>>>>> Does anybody know if
>>>>>> bluetooth 3.0 HS spec is
>>>>>> supported in BlueZ?
>>>>>>> Is AMP supported in BlueZ?
>>>>>>
>>>>>> There is two different
>>>>>> implementations, one by
>>>>>> Atheros and another by QuIC.
>>>>>> Both never reach upstream,
>>>>>> if you look to the list logs
>>>>>> you will find them.
>>>>>
>>>>>
>>>>> Any hopes of getting this unified version upstream anytime in near future? I guess this has been on the cards for some time now given that merge process started last august.
>>>>
>>>> I'm interested in have this on the stack but it doesn't depend on me.
>>>> Patches for this are not arriving to the mailing list. Actually we had no real
>>>> feedback for AMP since the meeting in Boston.
>>>
>>> Gustavo, Arun:
>>>
>>> We do still plan to upstream our Bluetooth 3.0 + HS implementation. I
>>> will start work on upstreaming later this month, but I need to merge
>>> in all of the recent L2CAP refactoring changes.
>>>
>>> Also note that Qualcomm and Atheros have announced a merger.
>>>
>>> You can find the kernel AMP implementation in the codeaurora.org
>>> Android git trees:
>>>
>>> git://codeaurora.org/kernel/msm.git
>>> https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=summary
>>>
>>> The android-msm-2.6.35 and msm-2.6.38 branches contain the AMP code.
>>>
>>>
>>> Please let me know if you have any other questions about AMP.
>>
>> Isn't Extended Flow Specification a required feature for AMP? I haven't seen
>> it in your implementation.
>
> Extended Flowspec is needed to create an L2CAP channel directly on
> AMP, but the implementation you're looking at does not implement the
> "create channel" feature. Channels are created on BR/EDR and moved
> to AMP, which does not require extended flowspec.
>
Why don't we have to use EFS for channels moved from BDR? Is it because
we assume that the QoS provided by AMP will be better than BDR?
Regards
Suraj
Gustavo,
On Mon, 9 May 2011, Gustavo F. Padovan wrote:
> Hi Mat,
>
> * Mat Martineau <[email protected]> [2011-05-05 16:27:17 -0700]:
>
>>
>> On Thu, 5 May 2011, Gustavo F. Padovan wrote:
>>
>>> Hi Arun,
>>>
>>> * Arun Kumar SINGH <[email protected]> [2011-05-05 09:26:58 +0200]:
>>>
>>>> Hi Gustavo,
>>>>
>>>>>> Does anybody know if
>>>>> bluetooth 3.0 HS spec is
>>>>> supported in BlueZ?
>>>>>> Is AMP supported in BlueZ?
>>>>>
>>>>> There is two different
>>>>> implementations, one by
>>>>> Atheros and another by QuIC.
>>>>> Both never reach upstream,
>>>>> if you look to the list logs
>>>>> you will find them.
>>>>
>>>>
>>>> Any hopes of getting this unified version upstream anytime in near future? I guess this has been on the cards for some time now given that merge process started last august.
>>>
>>> I'm interested in have this on the stack but it doesn't depend on me.
>>> Patches for this are not arriving to the mailing list. Actually we had no real
>>> feedback for AMP since the meeting in Boston.
>>
>> Gustavo, Arun:
>>
>> We do still plan to upstream our Bluetooth 3.0 + HS implementation. I
>> will start work on upstreaming later this month, but I need to merge
>> in all of the recent L2CAP refactoring changes.
>>
>> Also note that Qualcomm and Atheros have announced a merger.
>>
>> You can find the kernel AMP implementation in the codeaurora.org
>> Android git trees:
>>
>> git://codeaurora.org/kernel/msm.git
>> https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=summary
>>
>> The android-msm-2.6.35 and msm-2.6.38 branches contain the AMP code.
>>
>>
>> Please let me know if you have any other questions about AMP.
>
> Isn't Extended Flow Specification a required feature for AMP? I haven't seen
> it in your implementation.
Extended Flowspec is needed to create an L2CAP channel directly on
AMP, but the implementation you're looking at does not implement the
"create channel" feature. Channels are created on BR/EDR and moved
to AMP, which does not require extended flowspec.
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
Hi Mat,
* Mat Martineau <[email protected]> [2011-05-05 16:27:17 -0700]:
>
> On Thu, 5 May 2011, Gustavo F. Padovan wrote:
>
> > Hi Arun,
> >
> > * Arun Kumar SINGH <[email protected]> [2011-05-05 09:26:58 +0200]:
> >
> >> Hi Gustavo,
> >>
> >>>> Does anybody know if
> >>> bluetooth 3.0 HS spec is
> >>> supported in BlueZ?
> >>>> Is AMP supported in BlueZ?
> >>>
> >>> There is two different
> >>> implementations, one by
> >>> Atheros and another by QuIC.
> >>> Both never reach upstream,
> >>> if you look to the list logs
> >>> you will find them.
> >>
> >>
> >> Any hopes of getting this unified version upstream anytime in near future? I guess this has been on the cards for some time now given that merge process started last august.
> >
> > I'm interested in have this on the stack but it doesn't depend on me.
> > Patches for this are not arriving to the mailing list. Actually we had no real
> > feedback for AMP since the meeting in Boston.
>
> Gustavo, Arun:
>
> We do still plan to upstream our Bluetooth 3.0 + HS implementation. I
> will start work on upstreaming later this month, but I need to merge
> in all of the recent L2CAP refactoring changes.
>
> Also note that Qualcomm and Atheros have announced a merger.
>
> You can find the kernel AMP implementation in the codeaurora.org
> Android git trees:
>
> git://codeaurora.org/kernel/msm.git
> https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=summary
>
> The android-msm-2.6.35 and msm-2.6.38 branches contain the AMP code.
>
>
> Please let me know if you have any other questions about AMP.
Isn't Extended Flow Specification a required feature for AMP? I haven't seen
it in your implementation.
--
Gustavo F. Padovan
http://profusion.mobi
Hi Mat, Gustavo,
> Gustavo, Arun:
> We do still plan to upstream our Bluetooth 3.0 + HS implementation. I will
> start work on upstreaming later this month, but I need to merge in all of
> the recent L2CAP refactoring changes.
Good to know this. As I understand there have been quite some changes
and organisation in l2cap layer which may warrant subtle changes in
your AMP implementation. If its quite some work, may be we can come up
with a kind of TODO list and try to do a work split? Eitherways I will
come back with some thoughts after going thru existing below
implementation.
> Please let me know if you have any other questions about AMP.
Sure will come back in case stuck anywhere.
Thanks,
Arun
On Thu, 5 May 2011, Gustavo F. Padovan wrote:
> Hi Arun,
>
> * Arun Kumar SINGH <[email protected]> [2011-05-05 09:26:58 +0200]:
>
>> Hi Gustavo,
>>
>>>> Does anybody know if
>>> bluetooth 3.0 HS spec is
>>> supported in BlueZ?
>>>> Is AMP supported in BlueZ?
>>>
>>> There is two different
>>> implementations, one by
>>> Atheros and another by QuIC.
>>> Both never reach upstream,
>>> if you look to the list logs
>>> you will find them.
>>
>>
>> Any hopes of getting this unified version upstream anytime in near future? I guess this has been on the cards for some time now given that merge process started last august.
>
> I'm interested in have this on the stack but it doesn't depend on me.
> Patches for this are not arriving to the mailing list. Actually we had no real
> feedback for AMP since the meeting in Boston.
Gustavo, Arun:
We do still plan to upstream our Bluetooth 3.0 + HS implementation. I
will start work on upstreaming later this month, but I need to merge
in all of the recent L2CAP refactoring changes.
Also note that Qualcomm and Atheros have announced a merger.
You can find the kernel AMP implementation in the codeaurora.org
Android git trees:
git://codeaurora.org/kernel/msm.git
https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=summary
The android-msm-2.6.35 and msm-2.6.38 branches contain the AMP code.
Please let me know if you have any other questions about AMP.
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
Hi Arun,
* Arun Kumar SINGH <[email protected]> [2011-05-05 09:26:58 +0200]:
> Hi Gustavo,
>
> >> Does anybody know if
> >bluetooth 3.0 HS spec is
> >supported in BlueZ?
> >> Is AMP supported in BlueZ?
> >
> >There is two different
> >implementations, one by
> >Atheros and another by QuIC.
> >Both never reach upstream,
> >if you look to the list logs
> >you will find them.
>
>
> Any hopes of getting this unified version upstream anytime in near future? I guess this has been on the cards for some time now given that merge process started last august.
I'm interested in have this on the stack but it doesn't depend on me.
Patches for this are not arriving to the mailing list. Actually we had no real
feedback for AMP since the meeting in Boston.
--
Gustavo F. Padovan
http://profusion.mobi
Hi,
On Thu, May 5, 2011 at 10:26 AM, Arun Kumar SINGH
<[email protected]> wrote:
> Hi Gustavo,
>
>>> Does anybody know if
>>bluetooth 3.0 HS spec is
>>supported in BlueZ?
>>> Is AMP supported in BlueZ?
>>
>>There is two different
>>implementations, one by
>>Atheros and another by QuIC.
>>Both never reach upstream,
>>if you look to the list logs
>>you will find them.
>
>
> Any hopes of getting this unified version upstream anytime in near future? I guess this has been on the cards for some time now given that merge process started last august.
>
> I am trying to understand the options other folks may have, who may be interested in having 3.0 support in Bluez. Rewriting entire 3.0 support from scratch may be one thing that should be avoided as long as current upstreaming activity doesn't end up in a dead trail. ?Which I assume, it hadn't.
Well I would like to test something with obexd/obex-client to see how
we could indicate that high speed is necessary, so it would be very
welcoming if somebody step up and try to make a plan to integrate this
work upstream, otherwise we gonna have to either start from scratch or
pick one that seems to fit best in upstream.
--
Luiz Augusto von Dentz
Computer Engineer
Hi Gustavo,
>> Does anybody know if
>bluetooth 3.0 HS spec is
>supported in BlueZ?
>> Is AMP supported in BlueZ?
>
>There is two different
>implementations, one by
>Atheros and another by QuIC.
>Both never reach upstream,
>if you look to the list logs
>you will find them.
Any hopes of getting this unified version upstream anytime in near future? I guess this has been on the cards for some time now given that merge process started last august.
I am trying to understand the options other folks may have, who may be interested in having 3.0 support in Bluez. Rewriting entire 3.0 support from scratch may be one thing that should be avoided as long as current upstreaming activity doesn't end up in a dead trail. Which I assume, it hadn't.
Thanks,
Arun