* Re: [PATCH v2 2/6] Add Find By Type Value Response encoding/decoding functions
From: Johan Hedberg @ 2010-11-18 20:01 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1290102524-26493-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Thu, Nov 18, 2010, Claudio Takahasi wrote:
> Find by type operation is used by Discover Primary Service by Service
> UUID. Find By Type Value Response shall contain one or more group handles.
> ---
> attrib/att.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
> attrib/att.h | 7 +++++++
> 2 files changed, 53 insertions(+), 0 deletions(-)
Thanks for the update. This and the rest of your patches have been
pushed upstream.
Johan
^ permalink raw reply
* Re: Apple Wireless Keyboard connection issue
From: Andre Kuehne @ 2010-11-18 18:56 UTC (permalink / raw)
To: Gustavo F. Padovan, linux-bluetooth
In-Reply-To: <20101118084449.GA29790@jh-x301>
On 11/18/2010 09:44 AM, Johan Hedberg wrote:
> I was now able to get hold of a Bluetooth keyboard and fixed the issue.
> The problem was indeed in the commit that Gustavo originally pointed
> out. It's just that my original patch for it was incomplete and so
> didn't properly fix the issue. Anyway, a proper fix has now been pushed
> to git. Please test with that.
Thank you Johan and Gustavo, current git works fine for me.
Andre
^ permalink raw reply
* [PATCH v2 6/6] Implement Discover Primary Service by Service UUID in the gatttool
From: Claudio Takahasi @ 2010-11-18 18:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1290017386-23969-6-git-send-email-claudio.takahasi@openbossa.org>
Implement only the first interaction of the discovery procedure. If the
response doesn't fit in the MTU, "start" and "end" options can be used
to discover the handles ranges of the remaining primary service instances.
UUID16 and UUID128 are supported in the uuid option.
Usage example:
$gatttool -i hcix -b xx:xx:xx:xx:xx:xx --uuid=1801 --primary
---
Makefile.am | 3 +-
attrib/gatttool.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++----
2 files changed, 62 insertions(+), 6 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 03a9bf2..5f96975 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -178,7 +178,8 @@ if ATTRIBPLUGIN
bin_PROGRAMS += attrib/gatttool
attrib_gatttool_SOURCES = attrib/gatttool.c attrib/att.c attrib/gatt.c \
- attrib/gattrib.c btio/btio.c
+ attrib/gattrib.c btio/btio.c \
+ src/glib-helper.h src/glib-helper.c
attrib_gatttool_LDADD = lib/libbluetooth.la @GLIB_LIBS@
builtin_modules += attrib
diff --git a/attrib/gatttool.c b/attrib/gatttool.c
index 1a74edd..e961431 100644
--- a/attrib/gatttool.c
+++ b/attrib/gatttool.c
@@ -41,6 +41,7 @@
#include "att.h"
#include "btio.h"
#include "gattrib.h"
+#include "glib-helper.h"
#include "gatt.h"
/* Minimum MTU for L2CAP connections over BR/EDR */
@@ -50,6 +51,7 @@ static gchar *opt_src = NULL;
static gchar *opt_dst = NULL;
static gchar *opt_value = NULL;
static gchar *opt_sec_level = "low";
+static uuid_t *opt_uuid = NULL;
static int opt_start = 0x0001;
static int opt_end = 0xffff;
static int opt_handle = -1;
@@ -144,7 +146,7 @@ static GIOChannel *do_connect(gboolean le)
return chan;
}
-static void primary_cb(guint8 status, const guint8 *pdu, guint16 plen,
+static void primary_all_cb(guint8 status, const guint8 *pdu, guint16 plen,
gpointer user_data)
{
GAttrib *attrib = user_data;
@@ -200,9 +202,9 @@ static void primary_cb(guint8 status, const guint8 *pdu, guint16 plen,
* Read by Group Type Request until Error Response is received and
* the Error Code is set to Attribute Not Found.
*/
- gatt_discover_primary(attrib, end + 1, opt_end, NULL, primary_cb,
- attrib);
+ gatt_discover_primary(attrib, end + 1, opt_end, NULL, primary_all_cb,
+ attrib);
return;
done:
@@ -210,6 +212,36 @@ done:
g_main_loop_quit(event_loop);
}
+static void primary_by_uuid_cb(guint8 status, const guint8 *pdu, guint16 plen,
+ gpointer user_data)
+{
+ GSList *ranges, *l;
+
+ if (status != 0) {
+ g_printerr("Discover primary services by UUID failed: %s\n",
+ att_ecode2str(status));
+ goto done;
+ }
+
+ ranges = dec_find_by_type_resp(pdu, plen);
+ if (ranges == NULL) {
+ g_printerr("Protocol error!\n");
+ goto done;
+ }
+
+ for (l = ranges; l; l = l->next) {
+ struct att_range *range = l->data;
+ g_print("Starting handle: %04x Ending handle: %04x\n",
+ range->start, range->end);
+ }
+
+ g_slist_foreach(ranges, (GFunc) g_free, NULL);
+ g_slist_free(ranges);
+
+done:
+ g_main_loop_quit(event_loop);
+}
+
static void events_handler(const uint8_t *pdu, uint16_t len, gpointer user_data)
{
GAttrib *attrib = user_data;
@@ -260,8 +292,12 @@ static gboolean primary(gpointer user_data)
{
GAttrib *attrib = user_data;
- gatt_discover_primary(attrib, opt_start, opt_end, NULL, primary_cb,
- attrib);
+ if (opt_uuid)
+ gatt_discover_primary(attrib, opt_start, opt_end, opt_uuid,
+ primary_by_uuid_cb, attrib);
+ else
+ gatt_discover_primary(attrib, opt_start, opt_end, NULL,
+ primary_all_cb, attrib);
return FALSE;
}
@@ -486,11 +522,29 @@ static gboolean characteristics_desc(gpointer user_data)
return FALSE;
}
+static gboolean parse_uuid(const char *key, const char *value,
+ gpointer user_data, GError **error)
+{
+ if (!value)
+ return FALSE;
+
+ opt_uuid = g_try_malloc(sizeof(uuid_t));
+ if (opt_uuid == NULL)
+ return FALSE;
+
+ if (bt_string2uuid(opt_uuid, value) < 0)
+ return FALSE;
+
+ return TRUE;
+}
+
static GOptionEntry primary_char_options[] = {
{ "start", 's' , 0, G_OPTION_ARG_INT, &opt_start,
"Starting handle(optional)", "0x0001" },
{ "end", 'e' , 0, G_OPTION_ARG_INT, &opt_end,
"Ending handle(optional)", "0xffff" },
+ { "uuid", 'u', G_OPTION_FLAG_OPTIONAL_ARG, G_OPTION_ARG_CALLBACK,
+ parse_uuid, "UUID16 or UUID128(optional)", "0x1801"},
{ NULL },
};
@@ -621,6 +675,7 @@ done:
g_option_context_free(context);
g_free(opt_src);
g_free(opt_dst);
+ g_free(opt_uuid);
if (got_error)
exit(EXIT_FAILURE);
--
1.7.3.2
^ permalink raw reply related
* [PATCH v2 3/6] Implement Find by Type Value Request in the atttribute server
From: Claudio Takahasi @ 2010-11-18 18:02 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1290017386-23969-3-git-send-email-claudio.takahasi@openbossa.org>
GATT Discover Primary Service by Service UUID sub-procedure is based
on ATT Find By Type Value Request/Response.
Implement an extra verification for broken requests: "Ending Handle"
different than 0xFFFF. The Group End Handle may be greater than the
"Ending Handle" in the Find By Type Value Request. Forces the "Ending
Handle" in the response to 0xFFFF to avoid another request from the
clients. 0xFFFF means that the sub-procedure is complete.
---
src/attrib-server.c | 80 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 80 insertions(+), 0 deletions(-)
diff --git a/src/attrib-server.c b/src/attrib-server.c
index 375b731..41c0ffc 100644
--- a/src/attrib-server.c
+++ b/src/attrib-server.c
@@ -383,6 +383,76 @@ static int find_info(uint16_t start, uint16_t end, uint8_t *pdu, int len)
return length;
}
+static int find_by_type(uint16_t start, uint16_t end, uuid_t *uuid,
+ const uint8_t *value, int vlen, uint8_t *opdu, int mtu)
+{
+ struct attribute *a;
+ struct att_range *range;
+ GSList *l, *matches;
+ int len;
+
+ if (start > end || start == 0x0000)
+ return enc_error_resp(ATT_OP_FIND_BY_TYPE_REQ, start,
+ ATT_ECODE_INVALID_HANDLE, opdu, mtu);
+
+ /* Searching first requested handle number */
+ for (l = database, matches = NULL, range = NULL; l; l = l->next) {
+ a = l->data;
+
+ if (a->handle < start)
+ continue;
+
+ if (a->handle > end)
+ break;
+
+ /* Primary service? Attribute value matches? */
+ if ((sdp_uuid_cmp(&a->uuid, uuid) == 0) && (a->len == vlen) &&
+ (memcmp(a->data, value, vlen) == 0)) {
+
+ range = g_new0(struct att_range, 1);
+ range->start = a->handle;
+
+ matches = g_slist_append(matches, range);
+ } else if (range) {
+ /*
+ * Update the last found handle or reset the pointer
+ * to track that a new group started: Primary or
+ * Secondary service.
+ */
+ if (sdp_uuid_cmp(&a->uuid, &prim_uuid) == 0 ||
+ sdp_uuid_cmp(&a->uuid, &snd_uuid) == 0)
+ range = NULL;
+ else
+ range->end = a->handle;
+ }
+ }
+
+ if (range) {
+ if (l == NULL) {
+ /* Avoids another iteration */
+ range->end = 0xFFFF;
+ } else if (range->end == 0) {
+ /*
+ * Broken requests: requested End Handle is not 0xFFFF.
+ * Given handle is in the middle of a service definition.
+ */
+ matches = g_slist_remove(matches, range);
+ g_free(range);
+ }
+ }
+
+ if (matches == NULL)
+ return enc_error_resp(ATT_OP_FIND_BY_TYPE_REQ, start,
+ ATT_ECODE_ATTR_NOT_FOUND, opdu, mtu);
+
+ len = enc_find_by_type_resp(matches, opdu, mtu);
+
+ g_slist_foreach(matches, (GFunc) g_free, NULL);
+ g_slist_free(matches);
+
+ return len;
+}
+
static int handle_cmp(gconstpointer a, gconstpointer b)
{
const struct attribute *attrib = a;
@@ -522,6 +592,16 @@ static void channel_handler(const uint8_t *ipdu, uint16_t len,
write_value(start, value, vlen);
return;
case ATT_OP_FIND_BY_TYPE_REQ:
+ length = dec_find_by_type_req(ipdu, len, &start, &end,
+ &uuid, value, &vlen);
+ if (length == 0) {
+ status = ATT_ECODE_INVALID_PDU;
+ goto done;
+ }
+
+ length = find_by_type(start, end, &uuid, value, vlen,
+ opdu, channel->mtu);
+ break;
case ATT_OP_READ_BLOB_REQ:
case ATT_OP_READ_MULTI_REQ:
case ATT_OP_PREP_WRITE_REQ:
--
1.7.3.2
^ permalink raw reply related
* [PATCH v2 2/6] Add Find By Type Value Response encoding/decoding functions
From: Claudio Takahasi @ 2010-11-18 17:48 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <AANLkTikKFkhyjCQi4PzWbn4Y6kt3kqhNgvyUv4zNKxAQ@mail.gmail.com>
Find by type operation is used by Discover Primary Service by Service
UUID. Find By Type Value Response shall contain one or more group handles.
---
attrib/att.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
attrib/att.h | 7 +++++++
2 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/attrib/att.c b/attrib/att.c
index 6c889f2..8655e5e 100644
--- a/attrib/att.c
+++ b/attrib/att.c
@@ -30,6 +30,8 @@
#include <bluetooth/sdp.h>
#include <bluetooth/sdp_lib.h>
+#include <glib.h>
+
#include "att.h"
const char *att_ecode2str(uint8_t status)
@@ -271,6 +273,50 @@ uint16_t dec_find_by_type_req(const uint8_t *pdu, int len, uint16_t *start,
return len;
}
+uint16_t enc_find_by_type_resp(GSList *matches, uint8_t *pdu, int len)
+{
+ GSList *l;
+ uint16_t offset;
+
+ if (pdu == NULL || len < 5)
+ return 0;
+
+ pdu[0] = ATT_OP_FIND_BY_TYPE_RESP;
+
+ for (l = matches, offset = 1; l && len >= (offset + 4);
+ l = l->next, offset += 4) {
+ struct att_range *range = l->data;
+
+ att_put_u16(range->start, &pdu[offset]);
+ att_put_u16(range->end, &pdu[offset + 2]);
+ }
+
+ return offset;
+}
+
+GSList *dec_find_by_type_resp(const uint8_t *pdu, int len)
+{
+ struct att_range *range;
+ GSList *matches;
+ int offset;
+
+ if (pdu == NULL || len < 5)
+ return NULL;
+
+ if (pdu[0] != ATT_OP_FIND_BY_TYPE_RESP)
+ return NULL;
+
+ for (offset = 1, matches = NULL; len >= (offset + 4); offset += 4) {
+ range = malloc(sizeof(struct att_range));
+ range->start = att_get_u16(&pdu[offset]);
+ range->end = att_get_u16(&pdu[offset + 2]);
+
+ matches = g_slist_append(matches, range);
+ }
+
+ return matches;
+}
+
uint16_t enc_read_by_type_req(uint16_t start, uint16_t end, uuid_t *uuid,
uint8_t *pdu, int len)
{
diff --git a/attrib/att.h b/attrib/att.h
index 9de338d..7c98b4a 100644
--- a/attrib/att.h
+++ b/attrib/att.h
@@ -122,6 +122,11 @@ struct att_data_list {
uint8_t **data;
};
+struct att_range {
+ uint16_t start;
+ uint16_t end;
+};
+
/* These functions do byte conversion */
static inline uint8_t att_get_u8(const void *ptr)
{
@@ -168,6 +173,8 @@ uint16_t enc_find_by_type_req(uint16_t start, uint16_t end, uuid_t *uuid,
const uint8_t *value, int vlen, uint8_t *pdu, int len);
uint16_t dec_find_by_type_req(const uint8_t *pdu, int len, uint16_t *start,
uint16_t *end, uuid_t *uuid, uint8_t *value, int *vlen);
+uint16_t enc_find_by_type_resp(GSList *ranges, uint8_t *pdu, int len);
+GSList *dec_find_by_type_resp(const uint8_t *pdu, int len);
struct att_data_list *dec_read_by_grp_resp(const uint8_t *pdu, int len);
uint16_t enc_read_by_type_req(uint16_t start, uint16_t end, uuid_t *uuid,
uint8_t *pdu, int len);
--
1.7.3.2
^ permalink raw reply related
* Re: [PATCH] Add iwmmxt optimization for sbc for pxa series cpu
From: Johan Hedberg @ 2010-11-18 16:53 UTC (permalink / raw)
To: Keith Mok; +Cc: Siarhei Siamashka, linux-bluetooth
In-Reply-To: <AANLkTi=rSK1zmW4kcPh7qopdZKN7mefX2RYWiBQZSacF@mail.gmail.com>
Hi Keith,
On Thu, Nov 18, 2010, Keith Mok wrote:
> Add iwmmxt optimization for sbc for pxa series cpu.
>
> Benchmarked on ARM PXA platform:
> === Before (4 bands) ====
> $ time ./sbcenc_orig -s 4 long.au > /dev/null
> real 0m 2.44s
> user 0m 2.39s
> sys 0m 0.05s
> === After (4 bands) ====
> $ time ./sbcenc -s 4 long.au > /dev/null
> real 0m 1.59s
> user 0m 1.49s
> sys 0m 0.10s
>
> === Before (8 bands) ====
> $ time ./sbcenc_orig -s 8 long.au > /dev/null
> real 0m 4.05s
> user 0m 3.98s
> sys 0m 0.07s
> === After (8 bands) ====
> $ time ./sbcenc -s 8 long.au > /dev/null
> real 0m 1.48s
> user 0m 1.41s
> sys 0m 0.06s
>
> === Before (a2dp usage) ====
> $ time ./sbcenc_orig -b53 -s8 -j long.au > /dev/null
> real 0m 4.51s
> user 0m 4.41s
> sys 0m 0.10s
> === After (a2dp usage) ====
> $ time ./sbcenc -b53 -s8 -j long.au > /dev/null
> real 0m 2.05s
> user 0m 1.99s
> sys 0m 0.06s
>
> ---
> Makefile.am | 1 +
> sbc/sbc_primitives.c | 4 +
> sbc/sbc_primitives_iwmmxt.c | 304 +++++++++++++++++++++++++++++++++++++++++++
> sbc/sbc_primitives_iwmmxt.h | 42 ++++++
> 4 files changed, 351 insertions(+), 0 deletions(-)
> create mode 100644 sbc/sbc_primitives_iwmmxt.c
> create mode 100644 sbc/sbc_primitives_iwmmxt.h
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Fix queries for contact with only one affiliation
From: Johan Hedberg @ 2010-11-18 16:48 UTC (permalink / raw)
To: Bartosz Szatkowski; +Cc: linux-bluetooth
In-Reply-To: <1290092503-10324-1-git-send-email-bulislaw@linux.com>
Hi Bartosz,
On Thu, Nov 18, 2010, Bartosz Szatkowski wrote:
> Previously some fields may be omitted for contacts with only one affiliation,
> when querying for call history.
> ---
> plugins/phonebook-tracker.c | 83 ++++++++++++++++++++++++++++---------------
> 1 files changed, 54 insertions(+), 29 deletions(-)
Pushed upstream, but I had to fix the commit message width first. Please
keep it at max 72 characters so that it's properly viewable with git log
on a 80 column wide terminal.
Johan
^ permalink raw reply
* RE: [PATCH] Remove doc/bluez-docs.xml.
From: Waldemar.Rymarkiewicz @ 2010-11-18 16:03 UTC (permalink / raw)
To: hadess, johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <1290095820.1435.12.camel@novo.hadess.net>
[-- Attachment #1: Type: text/plain, Size: 835 bytes --]
Hi,
>On Thu, 2010-11-18 at 17:53 +0200, Waldemar.Rymarkiewicz@tieto.com
>wrote:
>> Hi Johan,
>>
>> >-----Original Message-----
>> >From: Rymarkiewicz Waldemar
>> >Sent: Wednesday, November 03, 2010 4:55 PM
>> >To: linux-bluetooth@vger.kernel.org
>> >Cc: Johan Hedberg; Marcel Holtmann; Rymarkiewicz Waldemar
>> >Subject: [PATCH] Remove doc/bluez-docs.xml.
>> >
>> >doc/bluez-docs.xml seems to be obsolate and not used anymore.
>> >---
>> > doc/bluez-docs.xml | 97
>> >----------------------------------------------------
>> > 1 files changed, 0 insertions(+), 97 deletions(-) delete mode
>> >100644 doc/bluez-docs.xml
>> >
>>
>> Can you put some comment on that patch.
>
>You didn't spell "obsolete" correctly.
>
Hrrr.. right. Has been fixed now :) See attached patch.
Thansk,
/Waldek
[-- Attachment #2: 0001-Remove-doc-bluez-docs.xml.patch --]
[-- Type: application/octet-stream, Size: 3383 bytes --]
From 63a9402b672beb3b4399d67bbcc0c86ef1392a1a Mon Sep 17 00:00:00 2001
From: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Date: Wed, 3 Nov 2010 16:51:50 +0100
Subject: [PATCH] Remove doc/bluez-docs.xml.
doc/bluez-docs.xml seems to be obsolete and not used anymore.
---
doc/bluez-docs.xml | 97 ----------------------------------------------------
1 files changed, 0 insertions(+), 97 deletions(-)
delete mode 100644 doc/bluez-docs.xml
diff --git a/doc/bluez-docs.xml b/doc/bluez-docs.xml
deleted file mode 100644
index 74a8bd1..0000000
--- a/doc/bluez-docs.xml
+++ /dev/null
@@ -1,97 +0,0 @@
-<?xml version="1.0"?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
- "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [
-<!ENTITY version SYSTEM "version.xml">
-]>
-<book id="index" xmlns:xi="http://www.w3.org/2003/XInclude">
- <bookinfo>
- <title>BlueZ Reference Manual</title>
- <releaseinfo>Version &version;</releaseinfo>
- <authorgroup>
- <author>
- <firstname>Marcel</firstname>
- <surname>Holtmann</surname>
- <affiliation>
- <address>
- <email>marcel@holtmann.org</email>
- </address>
- </affiliation>
- </author>
- </authorgroup>
-
- <copyright>
- <year>2002-2008</year>
- <holder>Marcel Holtmann</holder>
- </copyright>
-
- <legalnotice>
- <para>
- Permission is granted to copy, distribute and/or modify this
- document under the terms of the <citetitle>GNU Free
- Documentation License</citetitle>, Version 1.1 or any later
- version published by the Free Software Foundation with no
- Invariant Sections, no Front-Cover Texts, and no Back-Cover
- Texts. You may obtain a copy of the <citetitle>GNU Free
- Documentation License</citetitle> from the Free Software
- Foundation by visiting <ulink type="http"
- url="http://www.fsf.org">their Web site</ulink> or by writing
- to:
-
- <address>
- The Free Software Foundation, Inc.,
- <street>59 Temple Place</street> - Suite 330,
- <city>Boston</city>, <state>MA</state> <postcode>02111-1307</postcode>,
- <country>USA</country>
- </address>
- </para>
- </legalnotice>
- </bookinfo>
-
- <reference id="manager">
- <title>Manager interface</title>
- <para>
-<programlisting><xi:include href="manager-api.txt" parse="text" /></programlisting>
- </para>
- </reference>
-
- <reference id="adapter">
- <title>Adapter interface</title>
- <para>
-<programlisting><xi:include href="adapter-api.txt" parse="text" /></programlisting>
- </para>
- </reference>
-
- <reference id="device">
- <title>Device interface</title>
- <para>
-<programlisting><xi:include href="device-api.txt" parse="text" /></programlisting>
- </para>
- </reference>
-
- <reference id="agent">
- <title>Agent interface</title>
- <para>
-<programlisting><xi:include href="agent-api.txt" parse="text" /></programlisting>
- </para>
- </reference>
-
- <reference id="reference">
- <title>API Reference</title>
- <partintro>
- <para>
- This part presents the function reference for BlueZ.
- </para>
- </partintro>
- </reference>
-
- <appendix id="license">
- <title>License</title>
- <para>
-<programlisting><xi:include href="../COPYING" parse="text" /></programlisting>
- </para>
- </appendix>
-
- <index>
- <title>Index</title>
- </index>
-</book>
--
1.7.0.4
^ permalink raw reply related
* RE: [PATCH] Remove doc/bluez-docs.xml.
From: Bastien Nocera @ 2010-11-18 15:56 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz; +Cc: johan.hedberg, linux-bluetooth
In-Reply-To: <99B09243E1A5DA4898CDD8B7001114480BD8F99A44@EXMB04.eu.tieto.com>
On Thu, 2010-11-18 at 17:53 +0200, Waldemar.Rymarkiewicz@tieto.com
wrote:
> Hi Johan,
>
> >-----Original Message-----
> >From: Rymarkiewicz Waldemar
> >Sent: Wednesday, November 03, 2010 4:55 PM
> >To: linux-bluetooth@vger.kernel.org
> >Cc: Johan Hedberg; Marcel Holtmann; Rymarkiewicz Waldemar
> >Subject: [PATCH] Remove doc/bluez-docs.xml.
> >
> >doc/bluez-docs.xml seems to be obsolate and not used anymore.
> >---
> > doc/bluez-docs.xml | 97
> >----------------------------------------------------
> > 1 files changed, 0 insertions(+), 97 deletions(-) delete
> >mode 100644 doc/bluez-docs.xml
> >
>
> Can you put some comment on that patch.
You didn't spell "obsolete" correctly.
^ permalink raw reply
* RE: [PATCH] Remove doc/bluez-docs.xml.
From: Waldemar.Rymarkiewicz @ 2010-11-18 15:53 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <1288799702-17309-1-git-send-email-waldemar.rymarkiewicz@tieto.com>
Hi Johan,
>-----Original Message-----
>From: Rymarkiewicz Waldemar
>Sent: Wednesday, November 03, 2010 4:55 PM
>To: linux-bluetooth@vger.kernel.org
>Cc: Johan Hedberg; Marcel Holtmann; Rymarkiewicz Waldemar
>Subject: [PATCH] Remove doc/bluez-docs.xml.
>
>doc/bluez-docs.xml seems to be obsolate and not used anymore.
>---
> doc/bluez-docs.xml | 97
>----------------------------------------------------
> 1 files changed, 0 insertions(+), 97 deletions(-) delete
>mode 100644 doc/bluez-docs.xml
>
Can you put some comment on that patch.
/Waldek
^ permalink raw reply
* Re: [PATCH 2/6] Add Find By Type Value Response encoding/decoding functions
From: Claudio Takahasi @ 2010-11-18 15:25 UTC (permalink / raw)
To: Claudio Takahasi, linux-bluetooth
In-Reply-To: <20101118144710.GD7811@jh-x301>
Hi Johan,
On Thu, Nov 18, 2010 at 12:47 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Claudio,
>
> On Wed, Nov 17, 2010, Claudio Takahasi wrote:
>> --- a/attrib/att.h
>> +++ b/attrib/att.h
>> @@ -122,6 +122,11 @@ struct att_data_list {
>> uint8_t **data;
>> };
>>
>> +struct range {
>> + uint16_t start;
>> + uint16_t end;
>> +};
>> +
>
> Since this is in the public header file it should be prefixed with att_,
> right? (which should also apply for all public symbols here). However,
> it seems like you're only using the struct internally in att.c so
> probably it doesn't even need to be in the public header file?
>
> Johan
>
It will be used in the gatttool, attribute server and attribute client.
I gonna add the prefix att_ and resend the patches.
Claudio.
^ permalink raw reply
* Re: [RFC] Interface to set LE connection parameters
From: Luiz Augusto von Dentz @ 2010-11-18 15:15 UTC (permalink / raw)
To: tim.howes; +Cc: ville.tervo, linux-bluetooth
In-Reply-To: <1AFE20D16950C745A2A83986B72E8748011F571E6F06@EMEXM3131.dir.svc.accenture.com>
Hi,
On Tue, Nov 16, 2010 at 11:56 AM, <tim.howes@accenture.com> wrote:
> 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.
>
> Agreed.
>
>>
>> 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.
>
> I think these are the main issues; however I wonder whether link supervision timeout may conflict for different use cases. Even if it is not the link supervision the lifetime of the physical link may differ between profiles (some may want the link up for a long time but send no data). Slightly off-topic; but still it raises issues around the type of API and the arbitration of different profile requirements on the same link.
>> > 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.
>
> As an aside, it's not just the application profiles. If you have a link to a device with high latency and need to do more service search using GATT then you might want to lower the latency temporarily. This may impact the type of API control you give GATT applications versus any in-built GATT service discovery.
Well maybe we could have some sort of QoS API for l2cap sockets, for
instance using link supervision timeout would be very nice to detect
link loss on audio profiles where 20 sec. is way too big, and the
timeout to enter sniff mode could be dynamically adjusted. Normally we
don't export those for userspace but I guess for LE this has to be
done anyway and iirc l2cap sockets require privileges so basically
only root will be able to play with this so e.g. would be able
bluetoothd to adjust the parameter depending on the profile.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: Pull request git://gitorious.org/bluez-mcap-hdp/mcap-hdp.git for_upstream
From: Johan Hedberg @ 2010-11-18 15:03 UTC (permalink / raw)
To: Santiago Carot-Nemesio; +Cc: linux-bluetooth
In-Reply-To: <1290092014-32574-1-git-send-email-sancane@gmail.com>
Hi,
On Thu, Nov 18, 2010, Santiago Carot-Nemesio wrote:
> Fix typos in adapter documentation (2010-11-16 13:39:43 +0000)
>
> are available in the git repository at:
> git://gitorious.org/bluez-mcap-hdp/mcap-hdp.git for_upstream
>
> José Antonio Santos Cadenas (9):
> Add reference counter to hdp_application
> Add reference counter to hdp_channel
> Notify a channel deleted when remote side has already deleted it
> Fix typos in mcap
> Set reference counter for mcls to gint
> Fix message error
> Remove magic number to check ECHO MDEPs in HDP
> Fixes to echo
> Check if the mcl insiede the device is correctly set before use it
>
> Santiago Carot-Nemesio (10):
> Add reference counter to hdp_device
> Remove MCL's before removing the application
> Add missed unrefs for hdp_tmp_dc_data
> Add reference counter to mcap_instances
> Add reference counter to mcap_mdl
> Remove old reference to mcap session in the name of variables
> Code refactorization in MCAP
> Fix dereference to NULL pointers during data channels creation
> Return proper response code if there is an error creating echo channel
> Check if MCAP Instance is already released when a callbacks comes back.
>
> health/hdp.c | 266 ++++++++++++++++++++++++++++++++----------------
> health/hdp_types.h | 4 +
> health/hdp_util.c | 55 ++++++++++-
> health/hdp_util.h | 8 ++
> health/mcap.c | 242 +++++++++++++++++++++++++------------------
> health/mcap_internal.h | 9 +-
> health/mcap_lib.h | 13 ++-
> health/mcap_sync.c | 22 ++--
> 8 files changed, 407 insertions(+), 212 deletions(-)
In general, please try to avoid such big sets of patches and send them
in smaller bits (as they get created) to linux-bluetooth. That makes
things easier for me and I am able to do a more thorough review.
However, I did a quick skim through of the patches and only found one
coding style issue (C++ style comment) which I fixed my self. So the
patches have now all been pushed upstream.
Johan
^ permalink raw reply
* [PATCH] Fix queries for contact with only one affiliation
From: Bartosz Szatkowski @ 2010-11-18 15:01 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Bartosz Szatkowski
Previously some fields may be omitted for contacts with only one affiliation,
when querying for call history.
---
plugins/phonebook-tracker.c | 83 ++++++++++++++++++++++++++++---------------
1 files changed, 54 insertions(+), 29 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 6d8915e..2cf8ba2 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -183,7 +183,7 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "nco:title(?a) nco:phoneNumber(?t) nco:pobox(?po) " \
+ "?title nco:phoneNumber(?t) nco:pobox(?po) " \
"nco:extendedAddress(?po) nco:streetAddress(?po) " \
"nco:locality(?po) nco:region(?po) nco:postalcode(?po) " \
"nco:country(?po) nco:emailAddress(?eo) ?vc " \
@@ -211,6 +211,7 @@
"?a rdfs:label \"Work\" . " \
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
+ "OPTIONAL { ?a nco:title ?title } " \
"}" \
"OPTIONAL { " \
"?a rdfs:label \"Home\" . " \
@@ -235,12 +236,13 @@
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
+ "OPTIONAL { ?a nco:title ?title } " \
"{ " \
"SELECT ?p ?e ?c WHERE { " \
"?c nco:hasAffiliation ?b . " \
- "?b rdfs:label \"Home\" . " \
+ "OPTIONAL {?b rdfs:label \"Home\" . " \
"OPTIONAL {?b nco:hasEmailAddress ?e . } " \
- "OPTIONAL {?b nco:hasPostalAddress ?p . }} " \
+ "OPTIONAL {?b nco:hasPostalAddress ?p . }}} " \
"} " \
"}" \
"OPTIONAL { " \
@@ -250,13 +252,16 @@
"OPTIONAL { ?a nco:hasPostalAddress ?p . } " \
"OPTIONAL { ?a nco:org ?o . } " \
"{ " \
- "SELECT ?pw ?ew ?c WHERE { " \
+ "SELECT ?pw ?ew ?title ?c WHERE { " \
"?c nco:hasAffiliation ?b . " \
- "?b rdfs:label \"Work\" . " \
+ "OPTIONAL {?b rdfs:label \"Work\" . " \
"OPTIONAL {?b nco:hasEmailAddress ?ew . } " \
- "OPTIONAL {?b nco:hasPostalAddress ?pw . }} " \
+ "OPTIONAL {?b nco:title ?title } " \
+ "OPTIONAL {?b nco:hasPostalAddress ?pw . }}} " \
"} " \
"}" \
+ "OPTIONAL { ?c nco:hasPostalAddress ?po . } " \
+ "OPTIONAL { ?c nco:hasEmailAddress ?eo . } " \
"} UNION { " \
"?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?t . " \
@@ -322,7 +327,7 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "nco:title(?a) nco:phoneNumber(?t) nco:pobox(?po) " \
+ "?title nco:phoneNumber(?t) nco:pobox(?po) " \
"nco:extendedAddress(?po) nco:streetAddress(?po) " \
"nco:locality(?po) nco:region(?po) nco:postalcode(?po) " \
"nco:country(?po) nco:emailAddress(?eo) ?vc " \
@@ -348,6 +353,7 @@
"?c nco:hasAffiliation ?a . " \
"OPTIONAL { " \
"?a rdfs:label \"Work\" . " \
+ "OPTIONAL { ?a nco:title ?title } " \
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"}" \
@@ -374,12 +380,13 @@
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
+ "OPTIONAL { ?a nco:title ?title } " \
"{ " \
"SELECT ?p ?e ?c WHERE { " \
"?c nco:hasAffiliation ?b . " \
- "?b rdfs:label \"Home\" . " \
+ "OPTIONAL {?b rdfs:label \"Home\" . " \
"OPTIONAL {?b nco:hasEmailAddress ?e . } " \
- "OPTIONAL {?b nco:hasPostalAddress ?p . }} " \
+ "OPTIONAL {?b nco:hasPostalAddress ?p . }}} " \
"} " \
"}" \
"OPTIONAL { " \
@@ -389,13 +396,16 @@
"OPTIONAL { ?a nco:hasPostalAddress ?p . } " \
"OPTIONAL { ?a nco:org ?o . } " \
"{ " \
- "SELECT ?pw ?ew ?c WHERE { " \
+ "SELECT ?pw ?ew ?title ?c WHERE { " \
"?c nco:hasAffiliation ?b . " \
- "?b rdfs:label \"Work\" . " \
+ "OPTIONAL {?b rdfs:label \"Work\" . " \
"OPTIONAL {?b nco:hasEmailAddress ?ew . } " \
- "OPTIONAL {?b nco:hasPostalAddress ?pw . }} " \
+ "OPTIONAL {?b nco:title ?title } " \
+ "OPTIONAL {?b nco:hasPostalAddress ?pw . }}} " \
"} " \
"}" \
+ "OPTIONAL { ?c nco:hasPostalAddress ?po . } " \
+ "OPTIONAL { ?c nco:hasEmailAddress ?eo . } " \
"} UNION { " \
"?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?t . " \
@@ -460,7 +470,7 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "nco:title(?a) nco:phoneNumber(?t) nco:pobox(?po) " \
+ "?title nco:phoneNumber(?t) nco:pobox(?po) " \
"nco:extendedAddress(?po) nco:streetAddress(?po) " \
"nco:locality(?po) nco:region(?po) nco:postalcode(?po) " \
"nco:country(?po) nco:emailAddress(?eo) ?vc " \
@@ -487,6 +497,7 @@
"?a rdfs:label \"Work\" . " \
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
+ "OPTIONAL { ?a nco:title ?title } " \
"}" \
"OPTIONAL { " \
"?a rdfs:label \"Home\" . " \
@@ -510,12 +521,13 @@
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
+ "OPTIONAL { ?a nco:title ?title } " \
"{ " \
"SELECT ?p ?e ?c WHERE { " \
"?c nco:hasAffiliation ?b . " \
- "?b rdfs:label \"Home\" . " \
+ "OPTIONAL {?b rdfs:label \"Home\" . " \
"OPTIONAL {?b nco:hasEmailAddress ?e . } " \
- "OPTIONAL {?b nco:hasPostalAddress ?p . }} " \
+ "OPTIONAL {?b nco:hasPostalAddress ?p . }}} " \
"} " \
"}" \
"OPTIONAL { " \
@@ -525,13 +537,16 @@
"OPTIONAL { ?a nco:hasPostalAddress ?p . } " \
"OPTIONAL { ?a nco:org ?o . } " \
"{ " \
- "SELECT ?pw ?ew ?c WHERE { " \
+ "SELECT ?pw ?ew ?title ?c WHERE { " \
"?c nco:hasAffiliation ?b . " \
- "?b rdfs:label \"Work\" . " \
+ "OPTIONAL {?b rdfs:label \"Work\" . " \
"OPTIONAL {?b nco:hasEmailAddress ?ew . } " \
- "OPTIONAL {?b nco:hasPostalAddress ?pw . }} " \
+ "OPTIONAL { ?a nco:title ?title } " \
+ "OPTIONAL {?b nco:hasPostalAddress ?pw . }}} " \
"} " \
"}" \
+ "OPTIONAL { ?c nco:hasPostalAddress ?po . } " \
+ "OPTIONAL { ?c nco:hasEmailAddress ?eo . } " \
"} UNION { " \
"?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?t . " \
@@ -592,7 +607,7 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "nco:title(?a) nco:phoneNumber(?t) nco:pobox(?po) " \
+ "?title nco:phoneNumber(?t) nco:pobox(?po) " \
"nco:extendedAddress(?po) nco:streetAddress(?po) " \
"nco:locality(?po) nco:region(?po) nco:postalcode(?po) " \
"nco:country(?po) nco:emailAddress(?eo) ?vc " \
@@ -619,6 +634,7 @@
"?a rdfs:label \"Work\" . " \
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
+ "OPTIONAL { ?a nco:title ?title } " \
"}" \
"OPTIONAL { " \
"?a rdfs:label \"Home\" . " \
@@ -642,12 +658,13 @@
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
+ "OPTIONAL { ?a nco:title ?title } " \
"{ " \
"SELECT ?p ?e ?c WHERE { " \
"?c nco:hasAffiliation ?b . " \
- "?b rdfs:label \"Home\" . " \
+ "OPTIONAL {?b rdfs:label \"Home\" . " \
"OPTIONAL {?b nco:hasEmailAddress ?e . } " \
- "OPTIONAL {?b nco:hasPostalAddress ?p . }} " \
+ "OPTIONAL {?b nco:hasPostalAddress ?p . }}} " \
"} " \
"}" \
"OPTIONAL { " \
@@ -657,13 +674,16 @@
"OPTIONAL { ?a nco:hasPostalAddress ?p . } " \
"OPTIONAL { ?a nco:org ?o . } " \
"{ " \
- "SELECT ?pw ?ew ?c WHERE { " \
+ "SELECT ?pw ?ew ?title ?c WHERE { " \
"?c nco:hasAffiliation ?b . " \
- "?b rdfs:label \"Work\" . " \
+ "OPTIONAL {?b rdfs:label \"Work\" . " \
"OPTIONAL {?b nco:hasEmailAddress ?ew . } " \
- "OPTIONAL {?b nco:hasPostalAddress ?pw . }} " \
+ "OPTIONAL {?b nco:title ?title } " \
+ "OPTIONAL {?b nco:hasPostalAddress ?pw . }}} " \
"} " \
"}" \
+ "OPTIONAL { ?c nco:hasPostalAddress ?po . } " \
+ "OPTIONAL { ?c nco:hasEmailAddress ?eo . } " \
"} UNION { " \
"?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?t . " \
@@ -696,6 +716,7 @@
"?a rdfs:label \"Work\" . " \
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
+ "OPTIONAL { ?a nco:title ?title } " \
"}" \
"OPTIONAL { " \
"?a rdfs:label \"Home\" . " \
@@ -719,12 +740,13 @@
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
"OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
+ "OPTIONAL { ?a nco:title ?title } " \
"{ " \
"SELECT ?p ?e ?c WHERE { " \
"?c nco:hasAffiliation ?b . " \
- "?b rdfs:label \"Home\" . " \
+ "OPTIONAL {?b rdfs:label \"Home\" . " \
"OPTIONAL {?b nco:hasEmailAddress ?e . } " \
- "OPTIONAL {?b nco:hasPostalAddress ?p . }} " \
+ "OPTIONAL {?b nco:hasPostalAddress ?p . }}} " \
"} " \
"}" \
"OPTIONAL { " \
@@ -734,13 +756,16 @@
"OPTIONAL { ?a nco:hasPostalAddress ?p . } " \
"OPTIONAL { ?a nco:org ?o . } " \
"{ " \
- "SELECT ?pw ?ew ?c WHERE { " \
+ "SELECT ?pw ?ew ?title ?c WHERE { " \
"?c nco:hasAffiliation ?b . " \
- "?b rdfs:label \"Work\" . " \
+ "OPTIONAL {?b rdfs:label \"Work\" . " \
"OPTIONAL {?b nco:hasEmailAddress ?ew . } " \
- "OPTIONAL {?b nco:hasPostalAddress ?pw . }} " \
+ "OPTIONAL {?b nco:title ?title } " \
+ "OPTIONAL {?b nco:hasPostalAddress ?pw . }}} " \
"} " \
"}" \
+ "OPTIONAL { ?c nco:hasPostalAddress ?po . } " \
+ "OPTIONAL { ?c nco:hasEmailAddress ?eo . } " \
"} UNION { " \
"?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?t . " \
--
1.7.0.4
^ permalink raw reply related
* Pull request git://gitorious.org/bluez-mcap-hdp/mcap-hdp.git for_upstream
From: Santiago Carot-Nemesio @ 2010-11-18 14:53 UTC (permalink / raw)
To: linux-bluetooth
Fix typos in adapter documentation (2010-11-16 13:39:43 +0000)
are available in the git repository at:
git://gitorious.org/bluez-mcap-hdp/mcap-hdp.git for_upstream
José Antonio Santos Cadenas (9):
Add reference counter to hdp_application
Add reference counter to hdp_channel
Notify a channel deleted when remote side has already deleted it
Fix typos in mcap
Set reference counter for mcls to gint
Fix message error
Remove magic number to check ECHO MDEPs in HDP
Fixes to echo
Check if the mcl insiede the device is correctly set before use it
Santiago Carot-Nemesio (10):
Add reference counter to hdp_device
Remove MCL's before removing the application
Add missed unrefs for hdp_tmp_dc_data
Add reference counter to mcap_instances
Add reference counter to mcap_mdl
Remove old reference to mcap session in the name of variables
Code refactorization in MCAP
Fix dereference to NULL pointers during data channels creation
Return proper response code if there is an error creating echo channel
Check if MCAP Instance is already released when a callbacks comes back.
health/hdp.c | 266 ++++++++++++++++++++++++++++++++----------------
health/hdp_types.h | 4 +
health/hdp_util.c | 55 ++++++++++-
health/hdp_util.h | 8 ++
health/mcap.c | 242 +++++++++++++++++++++++++------------------
health/mcap_internal.h | 9 +-
health/mcap_lib.h | 13 ++-
health/mcap_sync.c | 22 ++--
8 files changed, 407 insertions(+), 212 deletions(-)
^ permalink raw reply
* Re: [PATCH 2/6] Add Find By Type Value Response encoding/decoding functions
From: Johan Hedberg @ 2010-11-18 14:47 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1290017386-23969-2-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Wed, Nov 17, 2010, Claudio Takahasi wrote:
> --- a/attrib/att.h
> +++ b/attrib/att.h
> @@ -122,6 +122,11 @@ struct att_data_list {
> uint8_t **data;
> };
>
> +struct range {
> + uint16_t start;
> + uint16_t end;
> +};
> +
Since this is in the public header file it should be prefixed with att_,
right? (which should also apply for all public symbols here). However,
it seems like you're only using the struct internally in att.c so
probably it doesn't even need to be in the public header file?
Johan
^ permalink raw reply
* Re: [PATCH 1/6] Implement Find by Type request encode/decoding
From: Johan Hedberg @ 2010-11-18 14:45 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth, Bruna Moreira
In-Reply-To: <1290017386-23969-1-git-send-email-claudio.takahasi@openbossa.org>
Hi,
On Wed, Nov 17, 2010, Claudio Takahasi wrote:
> From: Bruna Moreira <bruna.moreira@openbossa.org>
>
> ---
> attrib/att.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> attrib/att.h | 4 ++-
> 2 files changed, 73 insertions(+), 3 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 3/3] Emit "DeviceFound" signal for LE devices
From: Johan Hedberg @ 2010-11-18 14:44 UTC (permalink / raw)
To: Bruna Moreira; +Cc: linux-bluetooth
In-Reply-To: <1290009593-13658-3-git-send-email-bruna.moreira@openbossa.org>
Hi Bruna,
On Wed, Nov 17, 2010, Bruna Moreira wrote:
> The adapter_emit_device_found() function was modified to emit
> DeviceFound signal for LE devices as well.
> ---
> src/adapter.c | 30 +++++++++++++++++++++++++-----
> 1 files changed, 25 insertions(+), 5 deletions(-)
This patch has also been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 2/3] Extract service UUIDs from advertising data
From: Johan Hedberg @ 2010-11-18 14:42 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: Bruna Moreira, linux-bluetooth
In-Reply-To: <AANLkTi=xBthrmGDV0pUK_Tbw-Lob4gT9RmTgPrPAYj7M@mail.gmail.com>
Hi Anderson,
On Thu, Nov 18, 2010, Anderson Lizardo wrote:
> > What's the reason that the get_eir_uuids API is designed so that it can
> > handle a list which already contains elements before calling the
> > function? Since you free the list right after creating the uuids array
> > it seems like this shouldn't happen. Or am I missing something?
>
> The list is destroyed here just to keep the old semantics for BR/EDR,
> which ignores service UUIDs from previous EIR data.
>
> For LE devices (as you can see on the following 3/3 patch) we do not
> destroy the previous list when new advertising data is parsed.
> Instead, we "merge" the UUIDs list.
Fair enough. I've pushed the patch upstream now.
> Do you think we can unify semantics of BR/EDR and LE and always merge
> the service UUIDs for both EIR and advertising data?
Yeah, I think that could make sense. Feel free to send a patch for it.
> On the current code, the UUIDs array is always created on each EIR
> data (inside get_eir_uuids()) and destroyed right after the
> DeviceFound signal is emitted. For simplicity, we kept this same
> behavior.
>
> I agree we can make some optimization here and avoid heap
> allocations/deallocations when UUIDs do not change. One idea might be
> to keep the uuids char* array as well as the GSList on the
> remote_dev_info struct, and only recreate this array if any new UUIDs
> were added to the GSList (this can be identified if the uuidcount has
> changed, because we never delete UUIDs). What do you think?
Yes, that sounds like a good optimization.
Johan
^ permalink raw reply
* Re: [PATCH 2/3] Extract service UUIDs from advertising data
From: Anderson Lizardo @ 2010-11-18 14:03 UTC (permalink / raw)
To: Bruna Moreira, linux-bluetooth
In-Reply-To: <20101118124320.GA4918@jh-x301>
On Thu, Nov 18, 2010 at 8:43 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Bruna,
>
> On Wed, Nov 17, 2010, Bruna Moreira wrote:
>> + /* Extract UUIDs from extended inquiry response if any */
>> + dev->services = get_eir_uuids(eir_data, eir_length, dev->services);
>> + uuid_count = g_slist_length(dev->services);
>> +
>> + if (dev->services) {
>> + uuids = strlist2array(dev->services);
>> + g_slist_foreach(dev->services, (GFunc) g_free, NULL);
>> + g_slist_free(dev->services);
>> + dev->services = NULL;
>> + }
>
> What's the reason that the get_eir_uuids API is designed so that it can
> handle a list which already contains elements before calling the
> function? Since you free the list right after creating the uuids array
> it seems like this shouldn't happen. Or am I missing something?
The list is destroyed here just to keep the old semantics for BR/EDR,
which ignores service UUIDs from previous EIR data.
For LE devices (as you can see on the following 3/3 patch) we do not
destroy the previous list when new advertising data is parsed.
Instead, we "merge" the UUIDs list.
Do you think we can unify semantics of BR/EDR and LE and always merge
the service UUIDs for both EIR and advertising data?
> Btw, is there something that could be optimized here since it seems like
> you're regenerating the uuids array before every signal even though the
> set of service might not have changed since the previous one. Maybe you
> should track this and only regenerate the array if there has been a
> changed from the previous signal. What do you think?
On the current code, the UUIDs array is always created on each EIR
data (inside get_eir_uuids()) and destroyed right after the
DeviceFound signal is emitted. For simplicity, we kept this same
behavior.
I agree we can make some optimization here and avoid heap
allocations/deallocations when UUIDs do not change. One idea might be
to keep the uuids char* array as well as the GSList on the
remote_dev_info struct, and only recreate this array if any new UUIDs
were added to the GSList (this can be identified if the uuidcount has
changed, because we never delete UUIDs). What do you think?
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCHv3 3/7] Add DBus OOB API documentation.
From: Johan Hedberg @ 2010-11-18 13:45 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <201011181151.48796.szymon.janc@tieto.com>
Hi Szymon,
On Thu, Nov 18, 2010, Szymon Janc wrote:
> OOB hierarchy
> =================
>
> Service unique name
> Interface org.bluez.OOB
I suppose this should be called org.bluez.OobProvider, OobAgent or
something similar?
> Methods array{byte} hash, array{byte} randomizer
> RequestRemoteOobData(object device)
>
> This method gets called when the service daemon needs to
> get device's hash and randomizer for an OOB
> authentication. Each array should be 16 bytes long.
>
> Possible errors: org.bluez.Error.NoData
>
> void Release()
>
> This method gets called when D-Bus plug-in for OOB was
> deactivated. There is no need to unregister provider,
> because when this method gets called it has already been
> unregistered.
>
> --------------------------------------------------------------------------------
>
> Service org.bluez
> Interface org.bluez.OOB
Interface definitions are supposed to be unique. You can't reuse the
same interface name for a different set of methods and signals.
> Object path /
Regarding this, as you said the healt stuff is using /org/bluez. I'd
like to have someone who knows comment on the reasons why /org/bluez was
chosen instead of /. It seems inconsistent to me since the manager
interface uses /.
> --------------------------------------------------------------------------------
>
> Service org.bluez
> Interface org.bluez.Adapter
> Object path [variable prefix]/{hci0,hci1,...}
>
> array{byte} hash, array{byte} randomizer ReadLocalOobData()
I agree that this is good to have in the Adapter path, but we can still
discuss about whether it should be on it's own interface or not. Maybe
reusing the adapter path is fine since we're only dealing with one
method in it.
> Service unique name
> Interface org.bluez.Agent
> Object path freely definable
>
> Methods void RequestPairingApproval(object device)
I still like RequestPairing better (it's shorter). Marcel, do you have
any opinion or new suggestions for this? It would be reused for incoming
just-works pairing too (though only for 5.x).
Johan
^ permalink raw reply
* [PATCH] Add iwmmxt optimization for sbc for pxa series cpu
From: Keith Mok @ 2010-11-18 13:33 UTC (permalink / raw)
To: Siarhei Siamashka; +Cc: linux-bluetooth
In-Reply-To: <201011181505.29428.siarhei.siamashka@gmail.com>
Add iwmmxt optimization for sbc for pxa series cpu.
Benchmarked on ARM PXA platform:
=== Before (4 bands) ====
$ time ./sbcenc_orig -s 4 long.au > /dev/null
real 0m 2.44s
user 0m 2.39s
sys 0m 0.05s
=== After (4 bands) ====
$ time ./sbcenc -s 4 long.au > /dev/null
real 0m 1.59s
user 0m 1.49s
sys 0m 0.10s
=== Before (8 bands) ====
$ time ./sbcenc_orig -s 8 long.au > /dev/null
real 0m 4.05s
user 0m 3.98s
sys 0m 0.07s
=== After (8 bands) ====
$ time ./sbcenc -s 8 long.au > /dev/null
real 0m 1.48s
user 0m 1.41s
sys 0m 0.06s
=== Before (a2dp usage) ====
$ time ./sbcenc_orig -b53 -s8 -j long.au > /dev/null
real 0m 4.51s
user 0m 4.41s
sys 0m 0.10s
=== After (a2dp usage) ====
$ time ./sbcenc -b53 -s8 -j long.au > /dev/null
real 0m 2.05s
user 0m 1.99s
sys 0m 0.06s
---
Makefile.am | 1 +
sbc/sbc_primitives.c | 4 +
sbc/sbc_primitives_iwmmxt.c | 304 +++++++++++++++++++++++++++++++++++++++++++
sbc/sbc_primitives_iwmmxt.h | 42 ++++++
4 files changed, 351 insertions(+), 0 deletions(-)
create mode 100644 sbc/sbc_primitives_iwmmxt.c
create mode 100644 sbc/sbc_primitives_iwmmxt.h
diff --git a/Makefile.am b/Makefile.am
index da308a7..03a9bf2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -65,6 +65,7 @@ noinst_LTLIBRARIES += sbc/libsbc.la
sbc_libsbc_la_SOURCES = sbc/sbc.h sbc/sbc.c sbc/sbc_math.h sbc/sbc_tables.h \
sbc/sbc_primitives.h sbc/sbc_primitives.c \
sbc/sbc_primitives_mmx.h sbc/sbc_primitives_mmx.c \
+ sbc/sbc_primitives_iwmmxt.h sbc/sbc_primitives_iwmmxt.c \
sbc/sbc_primitives_neon.h sbc/sbc_primitives_neon.c \
sbc/sbc_primitives_armv6.h sbc/sbc_primitives_armv6.c
diff --git a/sbc/sbc_primitives.c b/sbc/sbc_primitives.c
index f87fb5a..ad780d0 100644
--- a/sbc/sbc_primitives.c
+++ b/sbc/sbc_primitives.c
@@ -33,6 +33,7 @@
#include "sbc_primitives.h"
#include "sbc_primitives_mmx.h"
+#include "sbc_primitives_iwmmxt.h"
#include "sbc_primitives_neon.h"
#include "sbc_primitives_armv6.h"
@@ -544,6 +545,9 @@ void sbc_init_primitives(struct sbc_encoder_state *state)
#ifdef SBC_BUILD_WITH_ARMV6_SUPPORT
sbc_init_primitives_armv6(state);
#endif
+#ifdef SBC_BUILD_WITH_IWMMXT_SUPPORT
+ sbc_init_primitives_iwmmxt(state);
+#endif
#ifdef SBC_BUILD_WITH_NEON_SUPPORT
sbc_init_primitives_neon(state);
#endif
diff --git a/sbc/sbc_primitives_iwmmxt.c b/sbc/sbc_primitives_iwmmxt.c
new file mode 100644
index 0000000..213967e
--- /dev/null
+++ b/sbc/sbc_primitives_iwmmxt.c
@@ -0,0 +1,304 @@
+/*
+ *
+ * Bluetooth low-complexity, subband codec (SBC) library
+ *
+ * Copyright (C) 2010 Keith Mok <ek9852@gmail.com>
+ * Copyright (C) 2008-2010 Nokia Corporation
+ * Copyright (C) 2004-2010 Marcel Holtmann <marcel@holtmann.org>
+ * Copyright (C) 2004-2005 Henryk Ploetz <henryk@ploetzli.ch>
+ * Copyright (C) 2005-2006 Brad Midgley <bmidgley@xmission.com>
+ *
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#include <stdint.h>
+#include <limits.h>
+#include "sbc.h"
+#include "sbc_math.h"
+#include "sbc_tables.h"
+
+#include "sbc_primitives_iwmmxt.h"
+
+/*
+ * IWMMXT optimizations
+ */
+
+#ifdef SBC_BUILD_WITH_IWMMXT_SUPPORT
+
+static inline void sbc_analyze_four_iwmmxt(const int16_t *in, int32_t *out,
+ const FIXED_T *consts)
+{
+ asm volatile (
+ "wldrd wr0, [%0]\n"
+ "tbcstw wr4, %2\n"
+ "wldrd wr2, [%1]\n"
+ "wldrd wr1, [%0, #8]\n"
+ "wldrd wr3, [%1, #8]\n"
+ "wmadds wr0, wr2, wr0\n"
+ " wldrd wr6, [%0, #16]\n"
+ "wmadds wr1, wr3, wr1\n"
+ " wldrd wr7, [%0, #24]\n"
+ "waddwss wr0, wr0, wr4\n"
+ " wldrd wr8, [%1, #16]\n"
+ "waddwss wr1, wr1, wr4\n"
+ " wldrd wr9, [%1, #24]\n"
+ " wmadds wr6, wr8, wr6\n"
+ " wldrd wr2, [%0, #32]\n"
+ " wmadds wr7, wr9, wr7\n"
+ " wldrd wr3, [%0, #40]\n"
+ " waddwss wr0, wr6, wr0\n"
+ " wldrd wr4, [%1, #32]\n"
+ " waddwss wr1, wr7, wr1\n"
+ " wldrd wr5, [%1, #40]\n"
+ " wmadds wr2, wr4, wr2\n"
+ "wldrd wr6, [%0, #48]\n"
+ " wmadds wr3, wr5, wr3\n"
+ "wldrd wr7, [%0, #56]\n"
+ " waddwss wr0, wr2, wr0\n"
+ "wldrd wr8, [%1, #48]\n"
+ " waddwss wr1, wr3, wr1\n"
+ "wldrd wr9, [%1, #56]\n"
+ "wmadds wr6, wr8, wr6\n"
+ " wldrd wr2, [%0, #64]\n"
+ "wmadds wr7, wr9, wr7\n"
+ " wldrd wr3, [%0, #72]\n"
+ "waddwss wr0, wr6, wr0\n"
+ " wldrd wr4, [%1, #64]\n"
+ "waddwss wr1, wr7, wr1\n"
+ " wldrd wr5, [%1, #72]\n"
+ " wmadds wr2, wr4, wr2\n"
+ "tmcr wcgr0, %4\n"
+ " wmadds wr3, wr5, wr3\n"
+ " waddwss wr0, wr2, wr0\n"
+ " waddwss wr1, wr3, wr1\n"
+ "\n"
+ "wsrawg wr0, wr0, wcgr0\n"
+ " wldrd wr4, [%1, #80]\n"
+ "wsrawg wr1, wr1, wcgr0\n"
+ " wldrd wr5, [%1, #88]\n"
+ "wpackwss wr0, wr0, wr0\n"
+ " wldrd wr6, [%1, #96]\n"
+ "wpackwss wr1, wr1, wr1\n"
+ "wmadds wr2, wr5, wr0\n"
+ " wldrd wr7, [%1, #104]\n"
+ "wmadds wr0, wr4, wr0\n"
+ "\n"
+ " wmadds wr3, wr7, wr1\n"
+ " wmadds wr1, wr6, wr1\n"
+ " waddwss wr2, wr3, wr2\n"
+ " waddwss wr0, wr1, wr0\n"
+ "\n"
+ "wstrd wr0, [%3]\n"
+ "wstrd wr2, [%3, #8]\n"
+ :
+ : "r" (in), "r" (consts),
+ "r" (1 << (SBC_PROTO_FIXED4_SCALE - 1)), "r" (out),
+ "r" (SBC_PROTO_FIXED4_SCALE)
+ : "wr0", "wr1", "wr2", "wr3", "wr4", "wr5", "wr6", "wr7",
+ "wr8", "wr9", "wcgr0", "memory");
+}
+
+static inline void sbc_analyze_eight_iwmmxt(const int16_t *in, int32_t *out,
+ const FIXED_T *consts)
+{
+ asm volatile (
+ "wldrd wr0, [%0]\n"
+ "tbcstw wr15, %2\n"
+ "wldrd wr1, [%0, #8]\n"
+ "wldrd wr2, [%0, #16]\n"
+ "wldrd wr3, [%0, #24]\n"
+ "wldrd wr4, [%1]\n"
+ "wldrd wr5, [%1, #8]\n"
+ "wldrd wr6, [%1, #16]\n"
+ "wldrd wr7, [%1, #24]\n"
+ "wmadds wr0, wr0, wr4\n"
+ " wldrd wr8, [%1, #32]\n"
+ "wmadds wr1, wr1, wr5\n"
+ " wldrd wr9, [%1, #40]\n"
+ "wmadds wr2, wr2, wr6\n"
+ " wldrd wr10, [%1, #48]\n"
+ "wmadds wr3, wr3, wr7\n"
+ " wldrd wr11, [%1, #56]\n"
+ "waddwss wr0, wr0, wr15\n"
+ " wldrd wr4, [%0, #32]\n"
+ "waddwss wr1, wr1, wr15\n"
+ " wldrd wr5, [%0, #40]\n"
+ "waddwss wr2, wr2, wr15\n"
+ " wldrd wr6, [%0, #48]\n"
+ "waddwss wr3, wr3, wr15\n"
+ " wldrd wr7, [%0, #56]\n"
+ " wmadds wr4, wr4, wr8\n"
+ " wldrd wr12, [%0, #64]\n"
+ " wmadds wr5, wr5, wr9\n"
+ " wldrd wr13, [%0, #72]\n"
+ " wmadds wr6, wr6, wr10\n"
+ " wldrd wr14, [%0, #80]\n"
+ " wmadds wr7, wr7, wr11\n"
+ " wldrd wr15, [%0, #88]\n"
+ " waddwss wr0, wr4, wr0\n"
+ " wldrd wr8, [%1, #64]\n"
+ " waddwss wr1, wr5, wr1\n"
+ " wldrd wr9, [%1, #72]\n"
+ " waddwss wr2, wr6, wr2\n"
+ " wldrd wr10, [%1, #80]\n"
+ " waddwss wr3, wr7, wr3\n"
+ " wldrd wr11, [%1, #88]\n"
+ " wmadds wr12, wr12, wr8\n"
+ "wldrd wr4, [%0, #96]\n"
+ " wmadds wr13, wr13, wr9\n"
+ "wldrd wr5, [%0, #104]\n"
+ " wmadds wr14, wr14, wr10\n"
+ "wldrd wr6, [%0, #112]\n"
+ " wmadds wr15, wr15, wr11\n"
+ "wldrd wr7, [%0, #120]\n"
+ " waddwss wr0, wr12, wr0\n"
+ "wldrd wr8, [%1, #96]\n"
+ " waddwss wr1, wr13, wr1\n"
+ "wldrd wr9, [%1, #104]\n"
+ " waddwss wr2, wr14, wr2\n"
+ "wldrd wr10, [%1, #112]\n"
+ " waddwss wr3, wr15, wr3\n"
+ "wldrd wr11, [%1, #120]\n"
+ "wmadds wr4, wr4, wr8\n"
+ " wldrd wr12, [%0, #128]\n"
+ "wmadds wr5, wr5, wr9\n"
+ " wldrd wr13, [%0, #136]\n"
+ "wmadds wr6, wr6, wr10\n"
+ " wldrd wr14, [%0, #144]\n"
+ "wmadds wr7, wr7, wr11\n"
+ " wldrd wr15, [%0, #152]\n"
+ "waddwss wr0, wr4, wr0\n"
+ " wldrd wr8, [%1, #128]\n"
+ "waddwss wr1, wr5, wr1\n"
+ " wldrd wr9, [%1, #136]\n"
+ "waddwss wr2, wr6, wr2\n"
+ " wldrd wr10, [%1, #144]\n"
+ " waddwss wr3, wr7, wr3\n"
+ " wldrd wr11, [%1, #152]\n"
+ " wmadds wr12, wr12, wr8\n"
+ "tmcr wcgr0, %4\n"
+ " wmadds wr13, wr13, wr9\n"
+ " wmadds wr14, wr14, wr10\n"
+ " wmadds wr15, wr15, wr11\n"
+ " waddwss wr0, wr12, wr0\n"
+ " waddwss wr1, wr13, wr1\n"
+ " waddwss wr2, wr14, wr2\n"
+ " waddwss wr3, wr15, wr3\n"
+ "\n"
+ "wsrawg wr0, wr0, wcgr0\n"
+ "wsrawg wr1, wr1, wcgr0\n"
+ "wsrawg wr2, wr2, wcgr0\n"
+ "wsrawg wr3, wr3, wcgr0\n"
+ "\n"
+ "wpackwss wr0, wr0, wr0\n"
+ "wpackwss wr1, wr1, wr1\n"
+ " wldrd wr4, [%1, #160]\n"
+ "wpackwss wr2, wr2, wr2\n"
+ " wldrd wr5, [%1, #168]\n"
+ "wpackwss wr3, wr3, wr3\n"
+ " wldrd wr6, [%1, #192]\n"
+ " wmadds wr4, wr4, wr0\n"
+ " wldrd wr7, [%1, #200]\n"
+ " wmadds wr5, wr5, wr0\n"
+ " wldrd wr8, [%1, #224]\n"
+ " wmadds wr6, wr6, wr1\n"
+ " wldrd wr9, [%1, #232]\n"
+ " wmadds wr7, wr7, wr1\n"
+ " waddwss wr4, wr6, wr4\n"
+ " waddwss wr5, wr7, wr5\n"
+ " wmadds wr8, wr8, wr2\n"
+ "wldrd wr6, [%1, #256]\n"
+ " wmadds wr9, wr9, wr2\n"
+ "wldrd wr7, [%1, #264]\n"
+ "waddwss wr4, wr8, wr4\n"
+ " waddwss wr5, wr9, wr5\n"
+ "wmadds wr6, wr6, wr3\n"
+ "wmadds wr7, wr7, wr3\n"
+ "waddwss wr4, wr6, wr4\n"
+ "waddwss wr5, wr7, wr5\n"
+ "\n"
+ "wstrd wr4, [%3]\n"
+ "wstrd wr5, [%3, #8]\n"
+ "\n"
+ "wldrd wr6, [%1, #176]\n"
+ "wldrd wr5, [%1, #184]\n"
+ "wmadds wr5, wr5, wr0\n"
+ "wldrd wr8, [%1, #208]\n"
+ "wmadds wr0, wr6, wr0\n"
+ "wldrd wr9, [%1, #216]\n"
+ "wmadds wr9, wr9, wr1\n"
+ "wldrd wr6, [%1, #240]\n"
+ "wmadds wr1, wr8, wr1\n"
+ "wldrd wr7, [%1, #248]\n"
+ "waddwss wr0, wr1, wr0\n"
+ "waddwss wr5, wr9, wr5\n"
+ "wmadds wr7, wr7, wr2\n"
+ "wldrd wr8, [%1, #272]\n"
+ "wmadds wr2, wr6, wr2\n"
+ "wldrd wr9, [%1, #280]\n"
+ "waddwss wr0, wr2, wr0\n"
+ "waddwss wr5, wr7, wr5\n"
+ "wmadds wr9, wr9, wr3\n"
+ "wmadds wr3, wr8, wr3\n"
+ "waddwss wr0, wr3, wr0\n"
+ "waddwss wr5, wr9, wr5\n"
+ "\n"
+ "wstrd wr0, [%3, #16]\n"
+ "wstrd wr5, [%3, #24]\n"
+ :
+ : "r" (in), "r" (consts),
+ "r" (1 << (SBC_PROTO_FIXED8_SCALE - 1)), "r" (out),
+ "r" (SBC_PROTO_FIXED8_SCALE)
+ : "wr0", "wr1", "wr2", "wr3", "wr4", "wr5", "wr6", "wr7",
+ "wr8", "wr9", "wr10", "wr11", "wr12", "wr13", "wr14", "wr15",
+ "wcgr0", "memory");
+}
+
+static inline void sbc_analyze_4b_4s_iwmmxt(int16_t *x, int32_t *out,
+ int out_stride)
+{
+ /* Analyze blocks */
+ sbc_analyze_four_iwmmxt(x + 12, out, analysis_consts_fixed4_simd_odd);
+ out += out_stride;
+ sbc_analyze_four_iwmmxt(x + 8, out, analysis_consts_fixed4_simd_even);
+ out += out_stride;
+ sbc_analyze_four_iwmmxt(x + 4, out, analysis_consts_fixed4_simd_odd);
+ out += out_stride;
+ sbc_analyze_four_iwmmxt(x + 0, out, analysis_consts_fixed4_simd_even);
+}
+
+static inline void sbc_analyze_4b_8s_iwmmxt(int16_t *x, int32_t *out,
+ int out_stride)
+{
+ /* Analyze blocks */
+ sbc_analyze_eight_iwmmxt(x + 24, out, analysis_consts_fixed8_simd_odd);
+ out += out_stride;
+ sbc_analyze_eight_iwmmxt(x + 16, out, analysis_consts_fixed8_simd_even);
+ out += out_stride;
+ sbc_analyze_eight_iwmmxt(x + 8, out, analysis_consts_fixed8_simd_odd);
+ out += out_stride;
+ sbc_analyze_eight_iwmmxt(x + 0, out, analysis_consts_fixed8_simd_even);
+}
+
+void sbc_init_primitives_iwmmxt(struct sbc_encoder_state *state)
+{
+ state->sbc_analyze_4b_4s = sbc_analyze_4b_4s_iwmmxt;
+ state->sbc_analyze_4b_8s = sbc_analyze_4b_8s_iwmmxt;
+ state->implementation_info = "IWMMXT";
+}
+
+#endif
diff --git a/sbc/sbc_primitives_iwmmxt.h b/sbc/sbc_primitives_iwmmxt.h
new file mode 100644
index 0000000..b535e68
--- /dev/null
+++ b/sbc/sbc_primitives_iwmmxt.h
@@ -0,0 +1,42 @@
+/*
+ *
+ * Bluetooth low-complexity, subband codec (SBC) library
+ *
+ * Copyright (C) 2010 Keith Mok <ek9852@gmail.com>
+ * Copyright (C) 2008-2010 Nokia Corporation
+ * Copyright (C) 2004-2010 Marcel Holtmann <marcel@holtmann.org>
+ * Copyright (C) 2004-2005 Henryk Ploetz <henryk@ploetzli.ch>
+ * Copyright (C) 2005-2006 Brad Midgley <bmidgley@xmission.com>
+ *
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifndef __SBC_PRIMITIVES_IWMMXT_H
+#define __SBC_PRIMITIVES_IWMMXT_H
+
+#include "sbc_primitives.h"
+
+#if defined(__GNUC__) && defined(__IWMMXT__) && \
+ !defined(SBC_HIGH_PRECISION) && (SCALE_OUT_BITS == 15)
+
+#define SBC_BUILD_WITH_IWMMXT_SUPPORT
+
+void sbc_init_primitives_iwmmxt(struct sbc_encoder_state *encoder_state);
+
+#endif
+
+#endif
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH v3] Add iwmmxt optimization for sbc for pxa series cpu
From: Johan Hedberg @ 2010-11-18 13:31 UTC (permalink / raw)
To: Siarhei Siamashka; +Cc: Keith Mok, linux-bluetooth
In-Reply-To: <201011181505.29428.siarhei.siamashka@gmail.com>
Hi Siarhei,
On Thu, Nov 18, 2010, Siarhei Siamashka wrote:
> 1. Make a final patch in such a form that can be pushed to git repository
> without any modifications, it means that you need a clean commit message and
> not just some text intermixed with the parts and quotations of discussion from
> this mailing list.
> 2. "Signed-off-by" header is not needed for the userspace parts of bluez.
> 3. All files must have copyright notices, even a small one like
> 'sbc_primitives_iwmmxt.h'. And probably you should just replicate all the
> copyright notices from the source files with sbc mmx optimizations and add your
> own copyright on top.
>
> Hopefully that should be enough to get your optimizations applied. Thanks.
Yep, those things would be needed before pushing upstream. Thanks for
reminding me about this patch. I had actually forgotten about it.
Johan
^ permalink raw reply
* Re: [PATCH 1/3] Advertising data: extract local name
From: Anderson Lizardo @ 2010-11-18 13:29 UTC (permalink / raw)
To: Bruna Moreira, linux-bluetooth
In-Reply-To: <20101118123310.GA4101@jh-x301>
Hi Johan,
On Thu, Nov 18, 2010 at 8:33 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Variables should be always declared in the smallest possible scope, so
> your new type variable is in the wrong place (it should be declared
> inside the if-statement. Since this was the only issue I found with this
> patch I fixed it myself and pushed it upstream. Btw, is it really safe
> to ignore the type here? What if it's EIR_NAME_SHORT? Wouldn't you then
> want to perform full name discovery using e.g. the GAP GATT service
> later?
The idea is to populate dev->name with some temporary information
available on the advertising data, and later when GATT service
discovery happens (as part of device creation), we get the definitive
name. At the moment, the GATT service discovery is not happening
automatically (but Claudio's patches are a beginning of that, IIRC),
so the advertising information is the only name source for LE devices,
currently.
Of course, we need to make sure that once name resolution through GATT
service discovery is done, any future names in advertising data would
be ignored, but we have not implemented this yet.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCH v3] Add iwmmxt optimization for sbc for pxa series cpu
From: Siarhei Siamashka @ 2010-11-18 13:05 UTC (permalink / raw)
To: Keith Mok; +Cc: linux-bluetooth
In-Reply-To: <201011151308.31972.siarhei.siamashka@gmail.com>
On Monday 15 November 2010 13:08:19 Siarhei Siamashka wrote:
> On Monday 15 November 2010 04:46:25 Keith Mok wrote:
> > > I sometimes use different indentation levels in such cases in order to
> > > improve readability after instructions reordering, so that each
> > > logically independent block of code has its own indentation level and
> > > it is still easily visible
> >
> > > after instructions reordering. For example, with the original code:
> > Thanks for the hints. I rearranged the code.
>
> Thanks, now the assembly code looks ok to me. I also discovered that qemu
> supports iwmmxt1 emulation just fine and also tried to test your
> optimizations for correctness myself (with a script which tries different
> encoding paramaters for different audio samples and checks md5 checksums),
> no problems detected.
>
> So if somebody else could check whether the other things are right
> (copyright notices for example), then we are done with it.
As nobody else has stepped in, I guess it's still my responsibility to provide
some further guidance even though I'm a very infrequent contributor myself.
Hopefully somebody will correct me if I'm wrong.
So please
1. Make a final patch in such a form that can be pushed to git repository
without any modifications, it means that you need a clean commit message and
not just some text intermixed with the parts and quotations of discussion from
this mailing list.
2. "Signed-off-by" header is not needed for the userspace parts of bluez.
3. All files must have copyright notices, even a small one like
'sbc_primitives_iwmmxt.h'. And probably you should just replicate all the
copyright notices from the source files with sbc mmx optimizations and add your
own copyright on top.
Hopefully that should be enough to get your optimizations applied. Thanks.
--
Best regards,
Siarhei Siamashka
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox