All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/4] TI Bluetooth serdev support
@ 2017-04-05 18:30 ` Rob Herring
  0 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
  To: Marcel Holtmann, linux-bluetooth
  Cc: linux-arm-kernel, Gustavo Padovan, Johan Hedberg, Mark Rutland,
	Wei Xu, Eyal Reizer, Satish Patel, netdev, devicetree

This series adds serdev support to the HCI LL protocol used on TI BT
modules and enables support on HiKey board with with the WL1835 module.
With this the custom TI UIM daemon and btattach are no longer needed.

The series is available on this git branch[1]. Patch 2 is just clean-up
and can be applied independently. Patch 3 is dependent on the series
"Nokia H4+ support". I'd suggest both series are merged thru the BT tree.

Rob

[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git ti-bluetooth

Rob Herring (4):
  dt-bindings: net: Add TI WiLink shared transport binding
  bluetooth: hci_uart: remove unused hci_uart_init_tty
  bluetooth: hci_uart: add LL protocol serdev driver support
  arm64: dts: hikey: add WL1835 Bluetooth device node

 .../devicetree/bindings/net/ti,wilink-st.txt       |  35 +++
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts     |   5 +
 drivers/bluetooth/hci_ldisc.c                      |  19 --
 drivers/bluetooth/hci_ll.c                         | 261 ++++++++++++++++++++-
 drivers/bluetooth/hci_uart.h                       |   1 -
 5 files changed, 300 insertions(+), 21 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt

^ permalink raw reply	[flat|nested] 51+ messages in thread
* [PATCH 0/4] TI Bluetooth serdev support
@ 2017-04-05 18:30 ` Rob Herring
  0 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
  To: Marcel Holtmann, linux-bluetooth
  Cc: linux-arm-kernel, Gustavo Padovan, Johan Hedberg, Mark Rutland,
	Wei Xu, Eyal Reizer, Satish Patel, netdev, devicetree

This series adds serdev support to the HCI LL protocol used on TI BT
modules and enables support on HiKey board with with the WL1835 module.
With this the custom TI UIM daemon and btattach are no longer needed.

The series is available on this git branch[1]. Patch 2 is just clean-up
and can be applied independently. Patch 3 is dependent on the series
"Nokia H4+ support". I'd suggest both series are merged thru the BT tree.

Rob

[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git ti-bluetooth

Rob Herring (4):
  dt-bindings: net: Add TI WiLink shared transport binding
  bluetooth: hci_uart: remove unused hci_uart_init_tty
  bluetooth: hci_uart: add LL protocol serdev driver support
  arm64: dts: hikey: add WL1835 Bluetooth device node

 .../devicetree/bindings/net/ti,wilink-st.txt       |  35 +++
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts     |   5 +
 drivers/bluetooth/hci_ldisc.c                      |  19 --
 drivers/bluetooth/hci_ll.c                         | 261 ++++++++++++++++++++-
 drivers/bluetooth/hci_uart.h                       |   1 -
 5 files changed, 300 insertions(+), 21 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt

--
2.10.1

^ permalink raw reply	[flat|nested] 51+ messages in thread
* [PATCH 0/4] TI Bluetooth serdev support
@ 2017-04-05 18:30 ` Rob Herring
  0 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
  To: linux-arm-kernel

This series adds serdev support to the HCI LL protocol used on TI BT
modules and enables support on HiKey board with with the WL1835 module.
With this the custom TI UIM daemon and btattach are no longer needed.

The series is available on this git branch[1]. Patch 2 is just clean-up
and can be applied independently. Patch 3 is dependent on the series
"Nokia H4+ support". I'd suggest both series are merged thru the BT tree.

Rob

[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git ti-bluetooth

Rob Herring (4):
  dt-bindings: net: Add TI WiLink shared transport binding
  bluetooth: hci_uart: remove unused hci_uart_init_tty
  bluetooth: hci_uart: add LL protocol serdev driver support
  arm64: dts: hikey: add WL1835 Bluetooth device node

 .../devicetree/bindings/net/ti,wilink-st.txt       |  35 +++
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts     |   5 +
 drivers/bluetooth/hci_ldisc.c                      |  19 --
 drivers/bluetooth/hci_ll.c                         | 261 ++++++++++++++++++++-
 drivers/bluetooth/hci_uart.h                       |   1 -
 5 files changed, 300 insertions(+), 21 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt

--
2.10.1

^ permalink raw reply	[flat|nested] 51+ messages in thread
* [PATCH 1/4] dt-bindings: net: Add TI WiLink shared transport binding
  2017-04-05 18:30 ` Rob Herring
@ 2017-04-05 18:30   ` Rob Herring
  -1 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
  To: Marcel Holtmann, linux-bluetooth
  Cc: linux-arm-kernel, Gustavo Padovan, Johan Hedberg, Mark Rutland,
	Wei Xu, Eyal Reizer, Satish Patel, netdev, devicetree

Add serial slave device binding for the TI WiLink series of Bluetooth/FM/GPS
devices.

Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: netdev@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
 .../devicetree/bindings/net/ti,wilink-st.txt       | 35 ++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt

diff --git a/Documentation/devicetree/bindings/net/ti,wilink-st.txt b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
new file mode 100644
index 000000000000..cbad73a84ac4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
@@ -0,0 +1,35 @@
+TI WiLink 7/8 (wl12xx/wl18xx) Shared Transport BT/FM/GPS devices
+
+TI WiLink devices have a UART interface for providing Bluetooth, FM radio,
+and GPS over what's called "shared transport". The shared transport is
+standard BT HCI protocol with additional channels for the other functions.
+
+These devices also have a separate WiFi interface as described in
+wireless/ti,wlcore.txt.
+
+This bindings follows the UART slave device binding in
+../serial/slave-device.txt.
+
+Required properties:
+ - compatible: should be one of the following:
+    "ti,wl1271-st"
+    "ti,wl1273-st"
+    "ti,wl1831-st"
+    "ti,wl1835-st"
+    "ti,wl1837-st"
+
+Optional properties:
+ - enable-gpios : GPIO signal controlling enabling of BT. Active high.
+ - vio-supply : Vio input supply (1.8V)
+ - vbat-supply : Vbat input supply (2.9-4.8V)
+
+Example:
+
+&serial0 {
+	compatible = "ns16550a";
+	...
+	bluetooth {
+		compatible = "ti,wl1835-st";
+		enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+	};
+};
-- 
2.10.1

^ permalink raw reply related	[flat|nested] 51+ messages in thread
* [PATCH 1/4] dt-bindings: net: Add TI WiLink shared transport binding
@ 2017-04-05 18:30   ` Rob Herring
  0 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
  To: linux-arm-kernel

Add serial slave device binding for the TI WiLink series of Bluetooth/FM/GPS
devices.

Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: netdev at vger.kernel.org
Cc: devicetree at vger.kernel.org
---
 .../devicetree/bindings/net/ti,wilink-st.txt       | 35 ++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt

diff --git a/Documentation/devicetree/bindings/net/ti,wilink-st.txt b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
new file mode 100644
index 000000000000..cbad73a84ac4
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ti,wilink-st.txt
@@ -0,0 +1,35 @@
+TI WiLink 7/8 (wl12xx/wl18xx) Shared Transport BT/FM/GPS devices
+
+TI WiLink devices have a UART interface for providing Bluetooth, FM radio,
+and GPS over what's called "shared transport". The shared transport is
+standard BT HCI protocol with additional channels for the other functions.
+
+These devices also have a separate WiFi interface as described in
+wireless/ti,wlcore.txt.
+
+This bindings follows the UART slave device binding in
+../serial/slave-device.txt.
+
+Required properties:
+ - compatible: should be one of the following:
+    "ti,wl1271-st"
+    "ti,wl1273-st"
+    "ti,wl1831-st"
+    "ti,wl1835-st"
+    "ti,wl1837-st"
+
+Optional properties:
+ - enable-gpios : GPIO signal controlling enabling of BT. Active high.
+ - vio-supply : Vio input supply (1.8V)
+ - vbat-supply : Vbat input supply (2.9-4.8V)
+
+Example:
+
+&serial0 {
+	compatible = "ns16550a";
+	...
+	bluetooth {
+		compatible = "ti,wl1835-st";
+		enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+	};
+};
-- 
2.10.1

^ permalink raw reply related	[flat|nested] 51+ messages in thread
* [PATCH 2/4] bluetooth: hci_uart: remove unused hci_uart_init_tty
  2017-04-05 18:30 ` Rob Herring
  (?)
@ 2017-04-05 18:30     ` Rob Herring
  -1 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
  To: Marcel Holtmann, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Gustavo Padovan, Johan Hedberg, Mark Rutland, Wei Xu,
	Eyal Reizer, Satish Patel, netdev-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA

There are no users of hci_uart_init_tty, so remove it.

Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
Cc: Gustavo Padovan <gustavo-THi1TnShQwVAfugRpC6u6w@public.gmane.org>
Cc: Johan Hedberg <johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
 drivers/bluetooth/hci_ldisc.c | 19 -------------------
 drivers/bluetooth/hci_uart.h  |  1 -
 2 files changed, 20 deletions(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 17bcbc13623f..cec4438ede01 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -319,25 +319,6 @@ void hci_uart_set_speeds(struct hci_uart *hu, unsigned int init_speed,
 	hu->oper_speed = oper_speed;
 }
 
-void hci_uart_init_tty(struct hci_uart *hu)
-{
-	struct tty_struct *tty = hu->tty;
-	struct ktermios ktermios;
-
-	/* Bring the UART into a known 8 bits no parity hw fc state */
-	ktermios = tty->termios;
-	ktermios.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP |
-			      INLCR | IGNCR | ICRNL | IXON);
-	ktermios.c_oflag &= ~OPOST;
-	ktermios.c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN);
-	ktermios.c_cflag &= ~(CSIZE | PARENB);
-	ktermios.c_cflag |= CS8;
-	ktermios.c_cflag |= CRTSCTS;
-
-	/* tty_set_termios() return not checked as it is always 0 */
-	tty_set_termios(tty, &ktermios);
-}
-
 void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed)
 {
 	struct tty_struct *tty = hu->tty;
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 1b41c661bbb8..2b05e557fad0 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -114,7 +114,6 @@ int hci_uart_register_device(struct hci_uart *hu, const struct hci_uart_proto *p
 
 int hci_uart_tx_wakeup(struct hci_uart *hu);
 int hci_uart_init_ready(struct hci_uart *hu);
-void hci_uart_init_tty(struct hci_uart *hu);
 void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed);
 void hci_uart_set_flow_control(struct hci_uart *hu, bool enable);
 void hci_uart_set_speeds(struct hci_uart *hu, unsigned int init_speed,
-- 
2.10.1

^ permalink raw reply related	[flat|nested] 51+ messages in thread
* [PATCH 2/4] bluetooth: hci_uart: remove unused hci_uart_init_tty
@ 2017-04-05 18:30     ` Rob Herring
  0 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
  To: Marcel Holtmann, linux-bluetooth
  Cc: linux-arm-kernel, Gustavo Padovan, Johan Hedberg, Mark Rutland,
	Wei Xu, Eyal Reizer, Satish Patel, netdev, devicetree

There are no users of hci_uart_init_tty, so remove it.

Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
---
 drivers/bluetooth/hci_ldisc.c | 19 -------------------
 drivers/bluetooth/hci_uart.h  |  1 -
 2 files changed, 20 deletions(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 17bcbc13623f..cec4438ede01 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -319,25 +319,6 @@ void hci_uart_set_speeds(struct hci_uart *hu, unsigned int init_speed,
 	hu->oper_speed = oper_speed;
 }
 
-void hci_uart_init_tty(struct hci_uart *hu)
-{
-	struct tty_struct *tty = hu->tty;
-	struct ktermios ktermios;
-
-	/* Bring the UART into a known 8 bits no parity hw fc state */
-	ktermios = tty->termios;
-	ktermios.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP |
-			      INLCR | IGNCR | ICRNL | IXON);
-	ktermios.c_oflag &= ~OPOST;
-	ktermios.c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN);
-	ktermios.c_cflag &= ~(CSIZE | PARENB);
-	ktermios.c_cflag |= CS8;
-	ktermios.c_cflag |= CRTSCTS;
-
-	/* tty_set_termios() return not checked as it is always 0 */
-	tty_set_termios(tty, &ktermios);
-}
-
 void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed)
 {
 	struct tty_struct *tty = hu->tty;
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 1b41c661bbb8..2b05e557fad0 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -114,7 +114,6 @@ int hci_uart_register_device(struct hci_uart *hu, const struct hci_uart_proto *p
 
 int hci_uart_tx_wakeup(struct hci_uart *hu);
 int hci_uart_init_ready(struct hci_uart *hu);
-void hci_uart_init_tty(struct hci_uart *hu);
 void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed);
 void hci_uart_set_flow_control(struct hci_uart *hu, bool enable);
 void hci_uart_set_speeds(struct hci_uart *hu, unsigned int init_speed,
-- 
2.10.1

^ permalink raw reply related	[flat|nested] 51+ messages in thread
* [PATCH 2/4] bluetooth: hci_uart: remove unused hci_uart_init_tty
@ 2017-04-05 18:30     ` Rob Herring
  0 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
  To: linux-arm-kernel

There are no users of hci_uart_init_tty, so remove it.

Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: linux-bluetooth at vger.kernel.org
---
 drivers/bluetooth/hci_ldisc.c | 19 -------------------
 drivers/bluetooth/hci_uart.h  |  1 -
 2 files changed, 20 deletions(-)

diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 17bcbc13623f..cec4438ede01 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -319,25 +319,6 @@ void hci_uart_set_speeds(struct hci_uart *hu, unsigned int init_speed,
 	hu->oper_speed = oper_speed;
 }
 
-void hci_uart_init_tty(struct hci_uart *hu)
-{
-	struct tty_struct *tty = hu->tty;
-	struct ktermios ktermios;
-
-	/* Bring the UART into a known 8 bits no parity hw fc state */
-	ktermios = tty->termios;
-	ktermios.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP |
-			      INLCR | IGNCR | ICRNL | IXON);
-	ktermios.c_oflag &= ~OPOST;
-	ktermios.c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN);
-	ktermios.c_cflag &= ~(CSIZE | PARENB);
-	ktermios.c_cflag |= CS8;
-	ktermios.c_cflag |= CRTSCTS;
-
-	/* tty_set_termios() return not checked as it is always 0 */
-	tty_set_termios(tty, &ktermios);
-}
-
 void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed)
 {
 	struct tty_struct *tty = hu->tty;
diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h
index 1b41c661bbb8..2b05e557fad0 100644
--- a/drivers/bluetooth/hci_uart.h
+++ b/drivers/bluetooth/hci_uart.h
@@ -114,7 +114,6 @@ int hci_uart_register_device(struct hci_uart *hu, const struct hci_uart_proto *p
 
 int hci_uart_tx_wakeup(struct hci_uart *hu);
 int hci_uart_init_ready(struct hci_uart *hu);
-void hci_uart_init_tty(struct hci_uart *hu);
 void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed);
 void hci_uart_set_flow_control(struct hci_uart *hu, bool enable);
 void hci_uart_set_speeds(struct hci_uart *hu, unsigned int init_speed,
-- 
2.10.1

^ permalink raw reply related	[flat|nested] 51+ messages in thread
* [PATCH 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
  2017-04-05 18:30 ` Rob Herring
  (?)
@ 2017-04-05 18:30     ` Rob Herring
  -1 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
  To: Marcel Holtmann, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Gustavo Padovan, Johan Hedberg, Mark Rutland, Wei Xu,
	Eyal Reizer, Satish Patel, netdev-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA

Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
The TI-ST adds firmware loading, GPIO control, and shared access for
NFC, FM radio, etc. For now, we're only implementing what is needed for
BT. This mirrors other drivers like BCM and Intel, but uses the new
serdev bus.

The firmware loading is greatly simplified by using existing
infrastructure to send commands. It may be a bit slower than the
original code using synchronous functions, but the real bottleneck is
likely doing firmware load at 115.2kbps.

Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
Cc: Gustavo Padovan <gustavo-THi1TnShQwVAfugRpC6u6w@public.gmane.org>
Cc: Johan Hedberg <johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
 drivers/bluetooth/hci_ll.c | 261 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 260 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
index 02692fe30279..9b2054f5502d 100644
--- a/drivers/bluetooth/hci_ll.c
+++ b/drivers/bluetooth/hci_ll.c
@@ -34,20 +34,23 @@
 #include <linux/sched.h>
 #include <linux/types.h>
 #include <linux/fcntl.h>
+#include <linux/firmware.h>
 #include <linux/interrupt.h>
 #include <linux/ptrace.h>
 #include <linux/poll.h>
 
 #include <linux/slab.h>
-#include <linux/tty.h>
 #include <linux/errno.h>
 #include <linux/string.h>
 #include <linux/signal.h>
 #include <linux/ioctl.h>
+#include <linux/serdev.h>
 #include <linux/skbuff.h>
+#include <linux/ti_wilink_st.h>
 
 #include <net/bluetooth/bluetooth.h>
 #include <net/bluetooth/hci_core.h>
+#include <linux/gpio/consumer.h>
 
 #include "hci_uart.h"
 
@@ -76,6 +79,12 @@ struct hcill_cmd {
 	u8 cmd;
 } __packed;
 
+struct ll_device {
+	struct hci_uart hu;
+	struct serdev_device *serdev;
+	struct gpio_desc *enable_gpio;
+};
+
 struct ll_struct {
 	unsigned long rx_state;
 	unsigned long rx_count;
@@ -136,6 +145,9 @@ static int ll_open(struct hci_uart *hu)
 
 	hu->priv = ll;
 
+	if (hu->serdev)
+		serdev_device_open(hu->serdev);
+
 	return 0;
 }
 
@@ -164,6 +176,13 @@ static int ll_close(struct hci_uart *hu)
 
 	kfree_skb(ll->rx_skb);
 
+	if (hu->serdev) {
+		struct ll_device *lldev = serdev_device_get_drvdata(hu->serdev);
+		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+
+		serdev_device_close(hu->serdev);
+	}
+
 	hu->priv = NULL;
 
 	kfree(ll);
@@ -505,9 +524,245 @@ static struct sk_buff *ll_dequeue(struct hci_uart *hu)
 	return skb_dequeue(&ll->txq);
 }
 
+#ifdef CONFIG_SERIAL_DEV_BUS
+static int read_local_version(struct hci_dev *hdev)
+{
+	int err = 0;
+	unsigned short version = 0;
+	struct sk_buff *skb;
+	struct hci_rp_read_local_version *ver;
+
+	skb = __hci_cmd_sync(hdev, HCI_OP_READ_LOCAL_VERSION, 0, NULL, HCI_INIT_TIMEOUT);
+	if (IS_ERR(skb)) {
+		bt_dev_err(hdev, "Reading TI version information failed (%ld)",
+			   PTR_ERR(skb));
+		err = PTR_ERR(skb);
+		goto out;
+	}
+	if (skb->len != sizeof(*ver)) {
+		err = -EILSEQ;
+		goto out;
+	}
+
+	ver = (struct hci_rp_read_local_version *)skb->data;
+	if (le16_to_cpu(ver->manufacturer) != 13) {
+		err = -ENODEV;
+		goto out;
+	}
+
+	version = le16_to_cpu(ver->lmp_subver);
+
+out:
+	if (err) bt_dev_err(hdev, "Failed to read TI version info: %d", err);
+	kfree_skb(skb);
+	return err ? err : version;
+}
+
+/**
+ * download_firmware -
+ *	internal function which parses through the .bts firmware
+ *	script file intreprets SEND, DELAY actions only as of now
+ */
+static int download_firmware(struct ll_device *lldev)
+{
+	unsigned short chip, min_ver, maj_ver;
+	int version, err, len;
+	unsigned char *ptr, *action_ptr;
+	unsigned char bts_scr_name[40];	/* 40 char long bts scr name? */
+	const struct firmware *fw;
+	struct sk_buff *skb;
+	struct hci_command *cmd;
+
+	version = read_local_version(lldev->hu.hdev);
+	if (version < 0)
+		return version;
+
+	chip = (version & 0x7C00) >> 10;
+	min_ver = (version & 0x007F);
+	maj_ver = (version & 0x0380) >> 7;
+	if (version & 0x8000)
+		maj_ver |= 0x0008;
+
+	snprintf(bts_scr_name, sizeof(bts_scr_name),
+		 "ti-connectivity/TIInit_%d.%d.%d.bts",
+		 chip, maj_ver, min_ver);
+
+	err = request_firmware(&fw, bts_scr_name, &lldev->serdev->dev);
+	if (err || !fw->data || !fw->size) {
+		bt_dev_err(lldev->hu.hdev, "request_firmware failed(errno %d) for %s",
+			   err, bts_scr_name);
+		return -EINVAL;
+	}
+	ptr = (void *)fw->data;
+	len = fw->size;
+	/* bts_header to remove out magic number and
+	 * version
+	 */
+	ptr += sizeof(struct bts_header);
+	len -= sizeof(struct bts_header);
+
+	while (len > 0 && ptr) {
+		bt_dev_dbg(lldev->hu.hdev, " action size %d, type %d ",
+			   ((struct bts_action *)ptr)->size,
+			   ((struct bts_action *)ptr)->type);
+
+		action_ptr = &(((struct bts_action *)ptr)->data[0]);
+
+		switch (((struct bts_action *)ptr)->type) {
+		case ACTION_SEND_COMMAND:	/* action send */
+			bt_dev_dbg(lldev->hu.hdev, "S");
+			cmd = (struct hci_command *)action_ptr;
+			if (cmd->opcode == 0xff36) {
+				/* ignore remote change
+				 * baud rate HCI VS command */
+				bt_dev_warn(lldev->hu.hdev, "change remote baud rate command in firmware");
+				break;
+			}
+			if (cmd->prefix != 1)
+				bt_dev_dbg(lldev->hu.hdev, "command type %d\n", cmd->prefix);
+
+			skb = __hci_cmd_sync(lldev->hu.hdev, cmd->opcode, cmd->plen, &cmd->speed, HCI_INIT_TIMEOUT);
+			if (IS_ERR(skb)) {
+				bt_dev_err(lldev->hu.hdev, "send command failed\n");
+				goto out_rel_fw;
+			}
+			kfree_skb(skb);
+			break;
+		case ACTION_WAIT_EVENT:  /* wait */
+			/* no need to wait as command was synchronous */
+			bt_dev_dbg(lldev->hu.hdev, "W");
+			break;
+		case ACTION_DELAY:	/* sleep */
+			bt_dev_info(lldev->hu.hdev, "sleep command in scr");
+			mdelay(((struct bts_action_delay *)action_ptr)->msec);
+			break;
+		}
+		len -= (sizeof(struct bts_action) +
+			((struct bts_action *)ptr)->size);
+		ptr += sizeof(struct bts_action) +
+			((struct bts_action *)ptr)->size;
+	}
+
+out_rel_fw:
+	/* fw download complete */
+	release_firmware(fw);
+	return err;
+}
+
+static int ll_setup(struct hci_uart *hu)
+{
+	int err, retry = 3;
+	struct ll_device *lldev;
+	struct serdev_device *serdev = hu->serdev;
+	u32 speed;
+
+	if (!serdev)
+		return 0;
+
+	lldev = serdev_device_get_drvdata(serdev);
+
+	serdev_device_set_flow_control(serdev, true);
+
+	do {
+		/* Configure BT_EN to HIGH state */
+		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+		msleep(5);
+		gpiod_set_value_cansleep(lldev->enable_gpio, 1);
+		msleep(100);
+
+		err = download_firmware(lldev);
+		if (!err)
+			break;
+
+		/* Toggle BT_EN and retry */
+		bt_dev_err(hu->hdev, "download firmware failed, retrying...");
+	} while (retry--);
+
+	if (err)
+		return err;
+
+	/* Operational speed if any */
+	if (hu->oper_speed)
+		speed = hu->oper_speed;
+	else if (hu->proto->oper_speed)
+		speed = hu->proto->oper_speed;
+	else
+		speed = 0;
+
+	if (speed) {
+		struct sk_buff *skb = __hci_cmd_sync(hu->hdev, 0xff36, sizeof(speed), &speed, HCI_INIT_TIMEOUT);
+		if (!IS_ERR(skb)) {
+			kfree_skb(skb);
+			serdev_device_set_baudrate(serdev, speed);
+		}
+	}
+
+	return 0;
+}
+
+static const struct hci_uart_proto llp;
+
+static int hci_ti_probe(struct serdev_device *serdev)
+{
+	struct hci_uart *hu;
+	struct ll_device *lldev;
+	u32 max_speed = 3000000;
+
+	lldev = devm_kzalloc(&serdev->dev, sizeof(struct ll_device), GFP_KERNEL);
+	if (!lldev)
+		return -ENOMEM;
+	hu = &lldev->hu;
+
+	serdev_device_set_drvdata(serdev, lldev);
+	lldev->serdev = hu->serdev = serdev;
+
+	lldev->enable_gpio = devm_gpiod_get_optional(&serdev->dev, "enable", GPIOD_OUT_LOW);
+	if (IS_ERR(lldev->enable_gpio))
+		return PTR_ERR(lldev->enable_gpio);
+
+	of_property_read_u32(serdev->dev.of_node, "max-speed", &max_speed);
+	hci_uart_set_speeds(hu, 115200, max_speed);
+
+	return hci_uart_register_device(hu, &llp);
+}
+
+static void hci_ti_remove(struct serdev_device *serdev)
+{
+	struct ll_device *lldev = serdev_device_get_drvdata(serdev);
+	struct hci_uart *hu = &lldev->hu;
+	struct hci_dev *hdev = hu->hdev;
+
+	cancel_work_sync(&hu->write_work);
+
+	hci_unregister_dev(hdev);
+	hci_free_dev(hdev);
+	hu->proto->close(hu);
+}
+
+static const struct of_device_id hci_ti_of_match[] = {
+	{ .compatible = "ti,wl1831-st" },
+	{ .compatible = "ti,wl1835-st" },
+	{ .compatible = "ti,wl1837-st" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, hci_ti_of_match);
+
+static struct serdev_device_driver hci_ti_drv = {
+	.driver		= {
+		.name	= "hci-ti",
+		.of_match_table = of_match_ptr(hci_ti_of_match),
+	},
+	.probe	= hci_ti_probe,
+	.remove	= hci_ti_remove,
+};
+#else
+#define ll_setup NULL
+#endif
+
 static const struct hci_uart_proto llp = {
 	.id		= HCI_UART_LL,
 	.name		= "LL",
+	.setup		= ll_setup,
 	.open		= ll_open,
 	.close		= ll_close,
 	.recv		= ll_recv,
@@ -518,10 +773,14 @@ static const struct hci_uart_proto llp = {
 
 int __init ll_init(void)
 {
+	serdev_device_driver_register(&hci_ti_drv);
+
 	return hci_uart_register_proto(&llp);
 }
 
 int __exit ll_deinit(void)
 {
+	serdev_device_driver_unregister(&hci_ti_drv);
+
 	return hci_uart_unregister_proto(&llp);
 }
-- 
2.10.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 51+ messages in thread
* [PATCH 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
@ 2017-04-05 18:30     ` Rob Herring
  0 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
  To: Marcel Holtmann, linux-bluetooth
  Cc: linux-arm-kernel, Gustavo Padovan, Johan Hedberg, Mark Rutland,
	Wei Xu, Eyal Reizer, Satish Patel, netdev, devicetree

Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
The TI-ST adds firmware loading, GPIO control, and shared access for
NFC, FM radio, etc. For now, we're only implementing what is needed for
BT. This mirrors other drivers like BCM and Intel, but uses the new
serdev bus.

The firmware loading is greatly simplified by using existing
infrastructure to send commands. It may be a bit slower than the
original code using synchronous functions, but the real bottleneck is
likely doing firmware load at 115.2kbps.

Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
---
 drivers/bluetooth/hci_ll.c | 261 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 260 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
index 02692fe30279..9b2054f5502d 100644
--- a/drivers/bluetooth/hci_ll.c
+++ b/drivers/bluetooth/hci_ll.c
@@ -34,20 +34,23 @@
 #include <linux/sched.h>
 #include <linux/types.h>
 #include <linux/fcntl.h>
+#include <linux/firmware.h>
 #include <linux/interrupt.h>
 #include <linux/ptrace.h>
 #include <linux/poll.h>
 
 #include <linux/slab.h>
-#include <linux/tty.h>
 #include <linux/errno.h>
 #include <linux/string.h>
 #include <linux/signal.h>
 #include <linux/ioctl.h>
+#include <linux/serdev.h>
 #include <linux/skbuff.h>
+#include <linux/ti_wilink_st.h>
 
 #include <net/bluetooth/bluetooth.h>
 #include <net/bluetooth/hci_core.h>
+#include <linux/gpio/consumer.h>
 
 #include "hci_uart.h"
 
@@ -76,6 +79,12 @@ struct hcill_cmd {
 	u8 cmd;
 } __packed;
 
+struct ll_device {
+	struct hci_uart hu;
+	struct serdev_device *serdev;
+	struct gpio_desc *enable_gpio;
+};
+
 struct ll_struct {
 	unsigned long rx_state;
 	unsigned long rx_count;
@@ -136,6 +145,9 @@ static int ll_open(struct hci_uart *hu)
 
 	hu->priv = ll;
 
+	if (hu->serdev)
+		serdev_device_open(hu->serdev);
+
 	return 0;
 }
 
@@ -164,6 +176,13 @@ static int ll_close(struct hci_uart *hu)
 
 	kfree_skb(ll->rx_skb);
 
+	if (hu->serdev) {
+		struct ll_device *lldev = serdev_device_get_drvdata(hu->serdev);
+		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+
+		serdev_device_close(hu->serdev);
+	}
+
 	hu->priv = NULL;
 
 	kfree(ll);
@@ -505,9 +524,245 @@ static struct sk_buff *ll_dequeue(struct hci_uart *hu)
 	return skb_dequeue(&ll->txq);
 }
 
+#ifdef CONFIG_SERIAL_DEV_BUS
+static int read_local_version(struct hci_dev *hdev)
+{
+	int err = 0;
+	unsigned short version = 0;
+	struct sk_buff *skb;
+	struct hci_rp_read_local_version *ver;
+
+	skb = __hci_cmd_sync(hdev, HCI_OP_READ_LOCAL_VERSION, 0, NULL, HCI_INIT_TIMEOUT);
+	if (IS_ERR(skb)) {
+		bt_dev_err(hdev, "Reading TI version information failed (%ld)",
+			   PTR_ERR(skb));
+		err = PTR_ERR(skb);
+		goto out;
+	}
+	if (skb->len != sizeof(*ver)) {
+		err = -EILSEQ;
+		goto out;
+	}
+
+	ver = (struct hci_rp_read_local_version *)skb->data;
+	if (le16_to_cpu(ver->manufacturer) != 13) {
+		err = -ENODEV;
+		goto out;
+	}
+
+	version = le16_to_cpu(ver->lmp_subver);
+
+out:
+	if (err) bt_dev_err(hdev, "Failed to read TI version info: %d", err);
+	kfree_skb(skb);
+	return err ? err : version;
+}
+
+/**
+ * download_firmware -
+ *	internal function which parses through the .bts firmware
+ *	script file intreprets SEND, DELAY actions only as of now
+ */
+static int download_firmware(struct ll_device *lldev)
+{
+	unsigned short chip, min_ver, maj_ver;
+	int version, err, len;
+	unsigned char *ptr, *action_ptr;
+	unsigned char bts_scr_name[40];	/* 40 char long bts scr name? */
+	const struct firmware *fw;
+	struct sk_buff *skb;
+	struct hci_command *cmd;
+
+	version = read_local_version(lldev->hu.hdev);
+	if (version < 0)
+		return version;
+
+	chip = (version & 0x7C00) >> 10;
+	min_ver = (version & 0x007F);
+	maj_ver = (version & 0x0380) >> 7;
+	if (version & 0x8000)
+		maj_ver |= 0x0008;
+
+	snprintf(bts_scr_name, sizeof(bts_scr_name),
+		 "ti-connectivity/TIInit_%d.%d.%d.bts",
+		 chip, maj_ver, min_ver);
+
+	err = request_firmware(&fw, bts_scr_name, &lldev->serdev->dev);
+	if (err || !fw->data || !fw->size) {
+		bt_dev_err(lldev->hu.hdev, "request_firmware failed(errno %d) for %s",
+			   err, bts_scr_name);
+		return -EINVAL;
+	}
+	ptr = (void *)fw->data;
+	len = fw->size;
+	/* bts_header to remove out magic number and
+	 * version
+	 */
+	ptr += sizeof(struct bts_header);
+	len -= sizeof(struct bts_header);
+
+	while (len > 0 && ptr) {
+		bt_dev_dbg(lldev->hu.hdev, " action size %d, type %d ",
+			   ((struct bts_action *)ptr)->size,
+			   ((struct bts_action *)ptr)->type);
+
+		action_ptr = &(((struct bts_action *)ptr)->data[0]);
+
+		switch (((struct bts_action *)ptr)->type) {
+		case ACTION_SEND_COMMAND:	/* action send */
+			bt_dev_dbg(lldev->hu.hdev, "S");
+			cmd = (struct hci_command *)action_ptr;
+			if (cmd->opcode == 0xff36) {
+				/* ignore remote change
+				 * baud rate HCI VS command */
+				bt_dev_warn(lldev->hu.hdev, "change remote baud rate command in firmware");
+				break;
+			}
+			if (cmd->prefix != 1)
+				bt_dev_dbg(lldev->hu.hdev, "command type %d\n", cmd->prefix);
+
+			skb = __hci_cmd_sync(lldev->hu.hdev, cmd->opcode, cmd->plen, &cmd->speed, HCI_INIT_TIMEOUT);
+			if (IS_ERR(skb)) {
+				bt_dev_err(lldev->hu.hdev, "send command failed\n");
+				goto out_rel_fw;
+			}
+			kfree_skb(skb);
+			break;
+		case ACTION_WAIT_EVENT:  /* wait */
+			/* no need to wait as command was synchronous */
+			bt_dev_dbg(lldev->hu.hdev, "W");
+			break;
+		case ACTION_DELAY:	/* sleep */
+			bt_dev_info(lldev->hu.hdev, "sleep command in scr");
+			mdelay(((struct bts_action_delay *)action_ptr)->msec);
+			break;
+		}
+		len -= (sizeof(struct bts_action) +
+			((struct bts_action *)ptr)->size);
+		ptr += sizeof(struct bts_action) +
+			((struct bts_action *)ptr)->size;
+	}
+
+out_rel_fw:
+	/* fw download complete */
+	release_firmware(fw);
+	return err;
+}
+
+static int ll_setup(struct hci_uart *hu)
+{
+	int err, retry = 3;
+	struct ll_device *lldev;
+	struct serdev_device *serdev = hu->serdev;
+	u32 speed;
+
+	if (!serdev)
+		return 0;
+
+	lldev = serdev_device_get_drvdata(serdev);
+
+	serdev_device_set_flow_control(serdev, true);
+
+	do {
+		/* Configure BT_EN to HIGH state */
+		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+		msleep(5);
+		gpiod_set_value_cansleep(lldev->enable_gpio, 1);
+		msleep(100);
+
+		err = download_firmware(lldev);
+		if (!err)
+			break;
+
+		/* Toggle BT_EN and retry */
+		bt_dev_err(hu->hdev, "download firmware failed, retrying...");
+	} while (retry--);
+
+	if (err)
+		return err;
+
+	/* Operational speed if any */
+	if (hu->oper_speed)
+		speed = hu->oper_speed;
+	else if (hu->proto->oper_speed)
+		speed = hu->proto->oper_speed;
+	else
+		speed = 0;
+
+	if (speed) {
+		struct sk_buff *skb = __hci_cmd_sync(hu->hdev, 0xff36, sizeof(speed), &speed, HCI_INIT_TIMEOUT);
+		if (!IS_ERR(skb)) {
+			kfree_skb(skb);
+			serdev_device_set_baudrate(serdev, speed);
+		}
+	}
+
+	return 0;
+}
+
+static const struct hci_uart_proto llp;
+
+static int hci_ti_probe(struct serdev_device *serdev)
+{
+	struct hci_uart *hu;
+	struct ll_device *lldev;
+	u32 max_speed = 3000000;
+
+	lldev = devm_kzalloc(&serdev->dev, sizeof(struct ll_device), GFP_KERNEL);
+	if (!lldev)
+		return -ENOMEM;
+	hu = &lldev->hu;
+
+	serdev_device_set_drvdata(serdev, lldev);
+	lldev->serdev = hu->serdev = serdev;
+
+	lldev->enable_gpio = devm_gpiod_get_optional(&serdev->dev, "enable", GPIOD_OUT_LOW);
+	if (IS_ERR(lldev->enable_gpio))
+		return PTR_ERR(lldev->enable_gpio);
+
+	of_property_read_u32(serdev->dev.of_node, "max-speed", &max_speed);
+	hci_uart_set_speeds(hu, 115200, max_speed);
+
+	return hci_uart_register_device(hu, &llp);
+}
+
+static void hci_ti_remove(struct serdev_device *serdev)
+{
+	struct ll_device *lldev = serdev_device_get_drvdata(serdev);
+	struct hci_uart *hu = &lldev->hu;
+	struct hci_dev *hdev = hu->hdev;
+
+	cancel_work_sync(&hu->write_work);
+
+	hci_unregister_dev(hdev);
+	hci_free_dev(hdev);
+	hu->proto->close(hu);
+}
+
+static const struct of_device_id hci_ti_of_match[] = {
+	{ .compatible = "ti,wl1831-st" },
+	{ .compatible = "ti,wl1835-st" },
+	{ .compatible = "ti,wl1837-st" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, hci_ti_of_match);
+
+static struct serdev_device_driver hci_ti_drv = {
+	.driver		= {
+		.name	= "hci-ti",
+		.of_match_table = of_match_ptr(hci_ti_of_match),
+	},
+	.probe	= hci_ti_probe,
+	.remove	= hci_ti_remove,
+};
+#else
+#define ll_setup NULL
+#endif
+
 static const struct hci_uart_proto llp = {
 	.id		= HCI_UART_LL,
 	.name		= "LL",
+	.setup		= ll_setup,
 	.open		= ll_open,
 	.close		= ll_close,
 	.recv		= ll_recv,
@@ -518,10 +773,14 @@ static const struct hci_uart_proto llp = {
 
 int __init ll_init(void)
 {
+	serdev_device_driver_register(&hci_ti_drv);
+
 	return hci_uart_register_proto(&llp);
 }
 
 int __exit ll_deinit(void)
 {
+	serdev_device_driver_unregister(&hci_ti_drv);
+
 	return hci_uart_unregister_proto(&llp);
 }
-- 
2.10.1

^ permalink raw reply related	[flat|nested] 51+ messages in thread
* [PATCH 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
@ 2017-04-05 18:30     ` Rob Herring
  0 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
  To: linux-arm-kernel

Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
The TI-ST adds firmware loading, GPIO control, and shared access for
NFC, FM radio, etc. For now, we're only implementing what is needed for
BT. This mirrors other drivers like BCM and Intel, but uses the new
serdev bus.

The firmware loading is greatly simplified by using existing
infrastructure to send commands. It may be a bit slower than the
original code using synchronous functions, but the real bottleneck is
likely doing firmware load at 115.2kbps.

Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: linux-bluetooth at vger.kernel.org
---
 drivers/bluetooth/hci_ll.c | 261 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 260 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
index 02692fe30279..9b2054f5502d 100644
--- a/drivers/bluetooth/hci_ll.c
+++ b/drivers/bluetooth/hci_ll.c
@@ -34,20 +34,23 @@
 #include <linux/sched.h>
 #include <linux/types.h>
 #include <linux/fcntl.h>
+#include <linux/firmware.h>
 #include <linux/interrupt.h>
 #include <linux/ptrace.h>
 #include <linux/poll.h>
 
 #include <linux/slab.h>
-#include <linux/tty.h>
 #include <linux/errno.h>
 #include <linux/string.h>
 #include <linux/signal.h>
 #include <linux/ioctl.h>
+#include <linux/serdev.h>
 #include <linux/skbuff.h>
+#include <linux/ti_wilink_st.h>
 
 #include <net/bluetooth/bluetooth.h>
 #include <net/bluetooth/hci_core.h>
+#include <linux/gpio/consumer.h>
 
 #include "hci_uart.h"
 
@@ -76,6 +79,12 @@ struct hcill_cmd {
 	u8 cmd;
 } __packed;
 
+struct ll_device {
+	struct hci_uart hu;
+	struct serdev_device *serdev;
+	struct gpio_desc *enable_gpio;
+};
+
 struct ll_struct {
 	unsigned long rx_state;
 	unsigned long rx_count;
@@ -136,6 +145,9 @@ static int ll_open(struct hci_uart *hu)
 
 	hu->priv = ll;
 
+	if (hu->serdev)
+		serdev_device_open(hu->serdev);
+
 	return 0;
 }
 
@@ -164,6 +176,13 @@ static int ll_close(struct hci_uart *hu)
 
 	kfree_skb(ll->rx_skb);
 
+	if (hu->serdev) {
+		struct ll_device *lldev = serdev_device_get_drvdata(hu->serdev);
+		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+
+		serdev_device_close(hu->serdev);
+	}
+
 	hu->priv = NULL;
 
 	kfree(ll);
@@ -505,9 +524,245 @@ static struct sk_buff *ll_dequeue(struct hci_uart *hu)
 	return skb_dequeue(&ll->txq);
 }
 
+#ifdef CONFIG_SERIAL_DEV_BUS
+static int read_local_version(struct hci_dev *hdev)
+{
+	int err = 0;
+	unsigned short version = 0;
+	struct sk_buff *skb;
+	struct hci_rp_read_local_version *ver;
+
+	skb = __hci_cmd_sync(hdev, HCI_OP_READ_LOCAL_VERSION, 0, NULL, HCI_INIT_TIMEOUT);
+	if (IS_ERR(skb)) {
+		bt_dev_err(hdev, "Reading TI version information failed (%ld)",
+			   PTR_ERR(skb));
+		err = PTR_ERR(skb);
+		goto out;
+	}
+	if (skb->len != sizeof(*ver)) {
+		err = -EILSEQ;
+		goto out;
+	}
+
+	ver = (struct hci_rp_read_local_version *)skb->data;
+	if (le16_to_cpu(ver->manufacturer) != 13) {
+		err = -ENODEV;
+		goto out;
+	}
+
+	version = le16_to_cpu(ver->lmp_subver);
+
+out:
+	if (err) bt_dev_err(hdev, "Failed to read TI version info: %d", err);
+	kfree_skb(skb);
+	return err ? err : version;
+}
+
+/**
+ * download_firmware -
+ *	internal function which parses through the .bts firmware
+ *	script file intreprets SEND, DELAY actions only as of now
+ */
+static int download_firmware(struct ll_device *lldev)
+{
+	unsigned short chip, min_ver, maj_ver;
+	int version, err, len;
+	unsigned char *ptr, *action_ptr;
+	unsigned char bts_scr_name[40];	/* 40 char long bts scr name? */
+	const struct firmware *fw;
+	struct sk_buff *skb;
+	struct hci_command *cmd;
+
+	version = read_local_version(lldev->hu.hdev);
+	if (version < 0)
+		return version;
+
+	chip = (version & 0x7C00) >> 10;
+	min_ver = (version & 0x007F);
+	maj_ver = (version & 0x0380) >> 7;
+	if (version & 0x8000)
+		maj_ver |= 0x0008;
+
+	snprintf(bts_scr_name, sizeof(bts_scr_name),
+		 "ti-connectivity/TIInit_%d.%d.%d.bts",
+		 chip, maj_ver, min_ver);
+
+	err = request_firmware(&fw, bts_scr_name, &lldev->serdev->dev);
+	if (err || !fw->data || !fw->size) {
+		bt_dev_err(lldev->hu.hdev, "request_firmware failed(errno %d) for %s",
+			   err, bts_scr_name);
+		return -EINVAL;
+	}
+	ptr = (void *)fw->data;
+	len = fw->size;
+	/* bts_header to remove out magic number and
+	 * version
+	 */
+	ptr += sizeof(struct bts_header);
+	len -= sizeof(struct bts_header);
+
+	while (len > 0 && ptr) {
+		bt_dev_dbg(lldev->hu.hdev, " action size %d, type %d ",
+			   ((struct bts_action *)ptr)->size,
+			   ((struct bts_action *)ptr)->type);
+
+		action_ptr = &(((struct bts_action *)ptr)->data[0]);
+
+		switch (((struct bts_action *)ptr)->type) {
+		case ACTION_SEND_COMMAND:	/* action send */
+			bt_dev_dbg(lldev->hu.hdev, "S");
+			cmd = (struct hci_command *)action_ptr;
+			if (cmd->opcode == 0xff36) {
+				/* ignore remote change
+				 * baud rate HCI VS command */
+				bt_dev_warn(lldev->hu.hdev, "change remote baud rate command in firmware");
+				break;
+			}
+			if (cmd->prefix != 1)
+				bt_dev_dbg(lldev->hu.hdev, "command type %d\n", cmd->prefix);
+
+			skb = __hci_cmd_sync(lldev->hu.hdev, cmd->opcode, cmd->plen, &cmd->speed, HCI_INIT_TIMEOUT);
+			if (IS_ERR(skb)) {
+				bt_dev_err(lldev->hu.hdev, "send command failed\n");
+				goto out_rel_fw;
+			}
+			kfree_skb(skb);
+			break;
+		case ACTION_WAIT_EVENT:  /* wait */
+			/* no need to wait as command was synchronous */
+			bt_dev_dbg(lldev->hu.hdev, "W");
+			break;
+		case ACTION_DELAY:	/* sleep */
+			bt_dev_info(lldev->hu.hdev, "sleep command in scr");
+			mdelay(((struct bts_action_delay *)action_ptr)->msec);
+			break;
+		}
+		len -= (sizeof(struct bts_action) +
+			((struct bts_action *)ptr)->size);
+		ptr += sizeof(struct bts_action) +
+			((struct bts_action *)ptr)->size;
+	}
+
+out_rel_fw:
+	/* fw download complete */
+	release_firmware(fw);
+	return err;
+}
+
+static int ll_setup(struct hci_uart *hu)
+{
+	int err, retry = 3;
+	struct ll_device *lldev;
+	struct serdev_device *serdev = hu->serdev;
+	u32 speed;
+
+	if (!serdev)
+		return 0;
+
+	lldev = serdev_device_get_drvdata(serdev);
+
+	serdev_device_set_flow_control(serdev, true);
+
+	do {
+		/* Configure BT_EN to HIGH state */
+		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+		msleep(5);
+		gpiod_set_value_cansleep(lldev->enable_gpio, 1);
+		msleep(100);
+
+		err = download_firmware(lldev);
+		if (!err)
+			break;
+
+		/* Toggle BT_EN and retry */
+		bt_dev_err(hu->hdev, "download firmware failed, retrying...");
+	} while (retry--);
+
+	if (err)
+		return err;
+
+	/* Operational speed if any */
+	if (hu->oper_speed)
+		speed = hu->oper_speed;
+	else if (hu->proto->oper_speed)
+		speed = hu->proto->oper_speed;
+	else
+		speed = 0;
+
+	if (speed) {
+		struct sk_buff *skb = __hci_cmd_sync(hu->hdev, 0xff36, sizeof(speed), &speed, HCI_INIT_TIMEOUT);
+		if (!IS_ERR(skb)) {
+			kfree_skb(skb);
+			serdev_device_set_baudrate(serdev, speed);
+		}
+	}
+
+	return 0;
+}
+
+static const struct hci_uart_proto llp;
+
+static int hci_ti_probe(struct serdev_device *serdev)
+{
+	struct hci_uart *hu;
+	struct ll_device *lldev;
+	u32 max_speed = 3000000;
+
+	lldev = devm_kzalloc(&serdev->dev, sizeof(struct ll_device), GFP_KERNEL);
+	if (!lldev)
+		return -ENOMEM;
+	hu = &lldev->hu;
+
+	serdev_device_set_drvdata(serdev, lldev);
+	lldev->serdev = hu->serdev = serdev;
+
+	lldev->enable_gpio = devm_gpiod_get_optional(&serdev->dev, "enable", GPIOD_OUT_LOW);
+	if (IS_ERR(lldev->enable_gpio))
+		return PTR_ERR(lldev->enable_gpio);
+
+	of_property_read_u32(serdev->dev.of_node, "max-speed", &max_speed);
+	hci_uart_set_speeds(hu, 115200, max_speed);
+
+	return hci_uart_register_device(hu, &llp);
+}
+
+static void hci_ti_remove(struct serdev_device *serdev)
+{
+	struct ll_device *lldev = serdev_device_get_drvdata(serdev);
+	struct hci_uart *hu = &lldev->hu;
+	struct hci_dev *hdev = hu->hdev;
+
+	cancel_work_sync(&hu->write_work);
+
+	hci_unregister_dev(hdev);
+	hci_free_dev(hdev);
+	hu->proto->close(hu);
+}
+
+static const struct of_device_id hci_ti_of_match[] = {
+	{ .compatible = "ti,wl1831-st" },
+	{ .compatible = "ti,wl1835-st" },
+	{ .compatible = "ti,wl1837-st" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, hci_ti_of_match);
+
+static struct serdev_device_driver hci_ti_drv = {
+	.driver		= {
+		.name	= "hci-ti",
+		.of_match_table = of_match_ptr(hci_ti_of_match),
+	},
+	.probe	= hci_ti_probe,
+	.remove	= hci_ti_remove,
+};
+#else
+#define ll_setup NULL
+#endif
+
 static const struct hci_uart_proto llp = {
 	.id		= HCI_UART_LL,
 	.name		= "LL",
+	.setup		= ll_setup,
 	.open		= ll_open,
 	.close		= ll_close,
 	.recv		= ll_recv,
@@ -518,10 +773,14 @@ static const struct hci_uart_proto llp = {
 
 int __init ll_init(void)
 {
+	serdev_device_driver_register(&hci_ti_drv);
+
 	return hci_uart_register_proto(&llp);
 }
 
 int __exit ll_deinit(void)
 {
+	serdev_device_driver_unregister(&hci_ti_drv);
+
 	return hci_uart_unregister_proto(&llp);
 }
-- 
2.10.1

^ permalink raw reply related	[flat|nested] 51+ messages in thread
* [PATCH 4/4] arm64: dts: hikey: add WL1835 Bluetooth device node
  2017-04-05 18:30 ` Rob Herring
  (?)
@ 2017-04-05 18:30     ` Rob Herring
  -1 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
  To: Marcel Holtmann, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Gustavo Padovan, Johan Hedberg, Mark Rutland, Wei Xu,
	Eyal Reizer, Satish Patel, netdev-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA

This adds the serial slave device for the WL1835 Bluetooth interface.

Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Wei Xu <xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index dba3c131c62c..9b4ba7169210 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -98,6 +98,11 @@
 			assigned-clocks = <&sys_ctrl HI6220_UART1_SRC>;
 			assigned-clock-rates = <150000000>;
 			status = "ok";
+
+			bluetooth {
+				compatible = "ti,wl1835-st";
+				enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+			};
 		};
 
 		uart2: uart@f7112000 {
-- 
2.10.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 51+ messages in thread
* [PATCH 4/4] arm64: dts: hikey: add WL1835 Bluetooth device node
@ 2017-04-05 18:30     ` Rob Herring
  0 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
  To: Marcel Holtmann, linux-bluetooth
  Cc: linux-arm-kernel, Gustavo Padovan, Johan Hedberg, Mark Rutland,
	Wei Xu, Eyal Reizer, Satish Patel, netdev, devicetree

This adds the serial slave device for the WL1835 Bluetooth interface.

Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Wei Xu <xuwei5@hisilicon.com>
Cc: Mark Rutland <mark.rutland@arm.com>
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index dba3c131c62c..9b4ba7169210 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -98,6 +98,11 @@
 			assigned-clocks = <&sys_ctrl HI6220_UART1_SRC>;
 			assigned-clock-rates = <150000000>;
 			status = "ok";
+
+			bluetooth {
+				compatible = "ti,wl1835-st";
+				enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+			};
 		};
 
 		uart2: uart@f7112000 {
-- 
2.10.1

^ permalink raw reply related	[flat|nested] 51+ messages in thread
* [PATCH 4/4] arm64: dts: hikey: add WL1835 Bluetooth device node
@ 2017-04-05 18:30     ` Rob Herring
  0 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-05 18:30 UTC (permalink / raw)
  To: linux-arm-kernel

This adds the serial slave device for the WL1835 Bluetooth interface.

Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Wei Xu <xuwei5@hisilicon.com>
Cc: Mark Rutland <mark.rutland@arm.com>
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index dba3c131c62c..9b4ba7169210 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -98,6 +98,11 @@
 			assigned-clocks = <&sys_ctrl HI6220_UART1_SRC>;
 			assigned-clock-rates = <150000000>;
 			status = "ok";
+
+			bluetooth {
+				compatible = "ti,wl1835-st";
+				enable-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+			};
 		};
 
 		uart2: uart at f7112000 {
-- 
2.10.1

^ permalink raw reply related	[flat|nested] 51+ messages in thread
* [PATCH v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
  2017-04-05 18:30     ` Rob Herring
  (?)
@ 2017-04-07 14:35         ` Rob Herring
  -1 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-07 14:35 UTC (permalink / raw)
  To: Marcel Holtmann, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA
  Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Gustavo Padovan, Johan Hedberg, Mark Rutland, Wei Xu,
	Eyal Reizer, Satish Patel, netdev-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA

Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
The TI-ST adds firmware loading, GPIO control, and shared access for
NFC, FM radio, etc. For now, we're only implementing what is needed for
BT. This mirrors other drivers like BCM and Intel, but uses the new
serdev bus.

The firmware loading is greatly simplified by using existing
infrastructure to send commands. It may be a bit slower than the
original code using synchronous functions, but the real bottleneck is
likely doing firmware load at 115.2kbps.

Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Marcel Holtmann <marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>
Cc: Gustavo Padovan <gustavo-THi1TnShQwVAfugRpC6u6w@public.gmane.org>
Cc: Johan Hedberg <johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
v2:
- Use IS_ENABLED() to fix module build

 drivers/bluetooth/hci_ll.c | 261 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 260 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
index 02692fe30279..77648adfd5c9 100644
--- a/drivers/bluetooth/hci_ll.c
+++ b/drivers/bluetooth/hci_ll.c
@@ -34,20 +34,23 @@
 #include <linux/sched.h>
 #include <linux/types.h>
 #include <linux/fcntl.h>
+#include <linux/firmware.h>
 #include <linux/interrupt.h>
 #include <linux/ptrace.h>
 #include <linux/poll.h>
 
 #include <linux/slab.h>
-#include <linux/tty.h>
 #include <linux/errno.h>
 #include <linux/string.h>
 #include <linux/signal.h>
 #include <linux/ioctl.h>
+#include <linux/serdev.h>
 #include <linux/skbuff.h>
+#include <linux/ti_wilink_st.h>
 
 #include <net/bluetooth/bluetooth.h>
 #include <net/bluetooth/hci_core.h>
+#include <linux/gpio/consumer.h>
 
 #include "hci_uart.h"
 
@@ -76,6 +79,12 @@ struct hcill_cmd {
 	u8 cmd;
 } __packed;
 
+struct ll_device {
+	struct hci_uart hu;
+	struct serdev_device *serdev;
+	struct gpio_desc *enable_gpio;
+};
+
 struct ll_struct {
 	unsigned long rx_state;
 	unsigned long rx_count;
@@ -136,6 +145,9 @@ static int ll_open(struct hci_uart *hu)
 
 	hu->priv = ll;
 
+	if (hu->serdev)
+		serdev_device_open(hu->serdev);
+
 	return 0;
 }
 
@@ -164,6 +176,13 @@ static int ll_close(struct hci_uart *hu)
 
 	kfree_skb(ll->rx_skb);
 
+	if (hu->serdev) {
+		struct ll_device *lldev = serdev_device_get_drvdata(hu->serdev);
+		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+
+		serdev_device_close(hu->serdev);
+	}
+
 	hu->priv = NULL;
 
 	kfree(ll);
@@ -505,9 +524,245 @@ static struct sk_buff *ll_dequeue(struct hci_uart *hu)
 	return skb_dequeue(&ll->txq);
 }
 
+#if IS_ENABLED(CONFIG_SERIAL_DEV_BUS)
+static int read_local_version(struct hci_dev *hdev)
+{
+	int err = 0;
+	unsigned short version = 0;
+	struct sk_buff *skb;
+	struct hci_rp_read_local_version *ver;
+
+	skb = __hci_cmd_sync(hdev, HCI_OP_READ_LOCAL_VERSION, 0, NULL, HCI_INIT_TIMEOUT);
+	if (IS_ERR(skb)) {
+		bt_dev_err(hdev, "Reading TI version information failed (%ld)",
+			   PTR_ERR(skb));
+		err = PTR_ERR(skb);
+		goto out;
+	}
+	if (skb->len != sizeof(*ver)) {
+		err = -EILSEQ;
+		goto out;
+	}
+
+	ver = (struct hci_rp_read_local_version *)skb->data;
+	if (le16_to_cpu(ver->manufacturer) != 13) {
+		err = -ENODEV;
+		goto out;
+	}
+
+	version = le16_to_cpu(ver->lmp_subver);
+
+out:
+	if (err) bt_dev_err(hdev, "Failed to read TI version info: %d", err);
+	kfree_skb(skb);
+	return err ? err : version;
+}
+
+/**
+ * download_firmware -
+ *	internal function which parses through the .bts firmware
+ *	script file intreprets SEND, DELAY actions only as of now
+ */
+static int download_firmware(struct ll_device *lldev)
+{
+	unsigned short chip, min_ver, maj_ver;
+	int version, err, len;
+	unsigned char *ptr, *action_ptr;
+	unsigned char bts_scr_name[40];	/* 40 char long bts scr name? */
+	const struct firmware *fw;
+	struct sk_buff *skb;
+	struct hci_command *cmd;
+
+	version = read_local_version(lldev->hu.hdev);
+	if (version < 0)
+		return version;
+
+	chip = (version & 0x7C00) >> 10;
+	min_ver = (version & 0x007F);
+	maj_ver = (version & 0x0380) >> 7;
+	if (version & 0x8000)
+		maj_ver |= 0x0008;
+
+	snprintf(bts_scr_name, sizeof(bts_scr_name),
+		 "ti-connectivity/TIInit_%d.%d.%d.bts",
+		 chip, maj_ver, min_ver);
+
+	err = request_firmware(&fw, bts_scr_name, &lldev->serdev->dev);
+	if (err || !fw->data || !fw->size) {
+		bt_dev_err(lldev->hu.hdev, "request_firmware failed(errno %d) for %s",
+			   err, bts_scr_name);
+		return -EINVAL;
+	}
+	ptr = (void *)fw->data;
+	len = fw->size;
+	/* bts_header to remove out magic number and
+	 * version
+	 */
+	ptr += sizeof(struct bts_header);
+	len -= sizeof(struct bts_header);
+
+	while (len > 0 && ptr) {
+		bt_dev_dbg(lldev->hu.hdev, " action size %d, type %d ",
+			   ((struct bts_action *)ptr)->size,
+			   ((struct bts_action *)ptr)->type);
+
+		action_ptr = &(((struct bts_action *)ptr)->data[0]);
+
+		switch (((struct bts_action *)ptr)->type) {
+		case ACTION_SEND_COMMAND:	/* action send */
+			bt_dev_dbg(lldev->hu.hdev, "S");
+			cmd = (struct hci_command *)action_ptr;
+			if (cmd->opcode == 0xff36) {
+				/* ignore remote change
+				 * baud rate HCI VS command */
+				bt_dev_warn(lldev->hu.hdev, "change remote baud rate command in firmware");
+				break;
+			}
+			if (cmd->prefix != 1)
+				bt_dev_dbg(lldev->hu.hdev, "command type %d\n", cmd->prefix);
+
+			skb = __hci_cmd_sync(lldev->hu.hdev, cmd->opcode, cmd->plen, &cmd->speed, HCI_INIT_TIMEOUT);
+			if (IS_ERR(skb)) {
+				bt_dev_err(lldev->hu.hdev, "send command failed\n");
+				goto out_rel_fw;
+			}
+			kfree_skb(skb);
+			break;
+		case ACTION_WAIT_EVENT:  /* wait */
+			/* no need to wait as command was synchronous */
+			bt_dev_dbg(lldev->hu.hdev, "W");
+			break;
+		case ACTION_DELAY:	/* sleep */
+			bt_dev_info(lldev->hu.hdev, "sleep command in scr");
+			mdelay(((struct bts_action_delay *)action_ptr)->msec);
+			break;
+		}
+		len -= (sizeof(struct bts_action) +
+			((struct bts_action *)ptr)->size);
+		ptr += sizeof(struct bts_action) +
+			((struct bts_action *)ptr)->size;
+	}
+
+out_rel_fw:
+	/* fw download complete */
+	release_firmware(fw);
+	return err;
+}
+
+static int ll_setup(struct hci_uart *hu)
+{
+	int err, retry = 3;
+	struct ll_device *lldev;
+	struct serdev_device *serdev = hu->serdev;
+	u32 speed;
+
+	if (!serdev)
+		return 0;
+
+	lldev = serdev_device_get_drvdata(serdev);
+
+	serdev_device_set_flow_control(serdev, true);
+
+	do {
+		/* Configure BT_EN to HIGH state */
+		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+		msleep(5);
+		gpiod_set_value_cansleep(lldev->enable_gpio, 1);
+		msleep(100);
+
+		err = download_firmware(lldev);
+		if (!err)
+			break;
+
+		/* Toggle BT_EN and retry */
+		bt_dev_err(hu->hdev, "download firmware failed, retrying...");
+	} while (retry--);
+
+	if (err)
+		return err;
+
+	/* Operational speed if any */
+	if (hu->oper_speed)
+		speed = hu->oper_speed;
+	else if (hu->proto->oper_speed)
+		speed = hu->proto->oper_speed;
+	else
+		speed = 0;
+
+	if (speed) {
+		struct sk_buff *skb = __hci_cmd_sync(hu->hdev, 0xff36, sizeof(speed), &speed, HCI_INIT_TIMEOUT);
+		if (!IS_ERR(skb)) {
+			kfree_skb(skb);
+			serdev_device_set_baudrate(serdev, speed);
+		}
+	}
+
+	return 0;
+}
+
+static const struct hci_uart_proto llp;
+
+static int hci_ti_probe(struct serdev_device *serdev)
+{
+	struct hci_uart *hu;
+	struct ll_device *lldev;
+	u32 max_speed = 3000000;
+
+	lldev = devm_kzalloc(&serdev->dev, sizeof(struct ll_device), GFP_KERNEL);
+	if (!lldev)
+		return -ENOMEM;
+	hu = &lldev->hu;
+
+	serdev_device_set_drvdata(serdev, lldev);
+	lldev->serdev = hu->serdev = serdev;
+
+	lldev->enable_gpio = devm_gpiod_get_optional(&serdev->dev, "enable", GPIOD_OUT_LOW);
+	if (IS_ERR(lldev->enable_gpio))
+		return PTR_ERR(lldev->enable_gpio);
+
+	of_property_read_u32(serdev->dev.of_node, "max-speed", &max_speed);
+	hci_uart_set_speeds(hu, 115200, max_speed);
+
+	return hci_uart_register_device(hu, &llp);
+}
+
+static void hci_ti_remove(struct serdev_device *serdev)
+{
+	struct ll_device *lldev = serdev_device_get_drvdata(serdev);
+	struct hci_uart *hu = &lldev->hu;
+	struct hci_dev *hdev = hu->hdev;
+
+	cancel_work_sync(&hu->write_work);
+
+	hci_unregister_dev(hdev);
+	hci_free_dev(hdev);
+	hu->proto->close(hu);
+}
+
+static const struct of_device_id hci_ti_of_match[] = {
+	{ .compatible = "ti,wl1831-st" },
+	{ .compatible = "ti,wl1835-st" },
+	{ .compatible = "ti,wl1837-st" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, hci_ti_of_match);
+
+static struct serdev_device_driver hci_ti_drv = {
+	.driver		= {
+		.name	= "hci-ti",
+		.of_match_table = of_match_ptr(hci_ti_of_match),
+	},
+	.probe	= hci_ti_probe,
+	.remove	= hci_ti_remove,
+};
+#else
+#define ll_setup NULL
+#endif
+
 static const struct hci_uart_proto llp = {
 	.id		= HCI_UART_LL,
 	.name		= "LL",
+	.setup		= ll_setup,
 	.open		= ll_open,
 	.close		= ll_close,
 	.recv		= ll_recv,
@@ -518,10 +773,14 @@ static const struct hci_uart_proto llp = {
 
 int __init ll_init(void)
 {
+	serdev_device_driver_register(&hci_ti_drv);
+
 	return hci_uart_register_proto(&llp);
 }
 
 int __exit ll_deinit(void)
 {
+	serdev_device_driver_unregister(&hci_ti_drv);
+
 	return hci_uart_unregister_proto(&llp);
 }
-- 
2.10.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 51+ messages in thread
* [PATCH v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
@ 2017-04-07 14:35         ` Rob Herring
  0 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-07 14:35 UTC (permalink / raw)
  To: Marcel Holtmann, linux-bluetooth
  Cc: linux-arm-kernel, Gustavo Padovan, Johan Hedberg, Mark Rutland,
	Wei Xu, Eyal Reizer, Satish Patel, netdev, devicetree

Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
The TI-ST adds firmware loading, GPIO control, and shared access for
NFC, FM radio, etc. For now, we're only implementing what is needed for
BT. This mirrors other drivers like BCM and Intel, but uses the new
serdev bus.

The firmware loading is greatly simplified by using existing
infrastructure to send commands. It may be a bit slower than the
original code using synchronous functions, but the real bottleneck is
likely doing firmware load at 115.2kbps.

Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
---
v2:
- Use IS_ENABLED() to fix module build

 drivers/bluetooth/hci_ll.c | 261 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 260 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
index 02692fe30279..77648adfd5c9 100644
--- a/drivers/bluetooth/hci_ll.c
+++ b/drivers/bluetooth/hci_ll.c
@@ -34,20 +34,23 @@
 #include <linux/sched.h>
 #include <linux/types.h>
 #include <linux/fcntl.h>
+#include <linux/firmware.h>
 #include <linux/interrupt.h>
 #include <linux/ptrace.h>
 #include <linux/poll.h>
 
 #include <linux/slab.h>
-#include <linux/tty.h>
 #include <linux/errno.h>
 #include <linux/string.h>
 #include <linux/signal.h>
 #include <linux/ioctl.h>
+#include <linux/serdev.h>
 #include <linux/skbuff.h>
+#include <linux/ti_wilink_st.h>
 
 #include <net/bluetooth/bluetooth.h>
 #include <net/bluetooth/hci_core.h>
+#include <linux/gpio/consumer.h>
 
 #include "hci_uart.h"
 
@@ -76,6 +79,12 @@ struct hcill_cmd {
 	u8 cmd;
 } __packed;
 
+struct ll_device {
+	struct hci_uart hu;
+	struct serdev_device *serdev;
+	struct gpio_desc *enable_gpio;
+};
+
 struct ll_struct {
 	unsigned long rx_state;
 	unsigned long rx_count;
@@ -136,6 +145,9 @@ static int ll_open(struct hci_uart *hu)
 
 	hu->priv = ll;
 
+	if (hu->serdev)
+		serdev_device_open(hu->serdev);
+
 	return 0;
 }
 
@@ -164,6 +176,13 @@ static int ll_close(struct hci_uart *hu)
 
 	kfree_skb(ll->rx_skb);
 
+	if (hu->serdev) {
+		struct ll_device *lldev = serdev_device_get_drvdata(hu->serdev);
+		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+
+		serdev_device_close(hu->serdev);
+	}
+
 	hu->priv = NULL;
 
 	kfree(ll);
@@ -505,9 +524,245 @@ static struct sk_buff *ll_dequeue(struct hci_uart *hu)
 	return skb_dequeue(&ll->txq);
 }
 
+#if IS_ENABLED(CONFIG_SERIAL_DEV_BUS)
+static int read_local_version(struct hci_dev *hdev)
+{
+	int err = 0;
+	unsigned short version = 0;
+	struct sk_buff *skb;
+	struct hci_rp_read_local_version *ver;
+
+	skb = __hci_cmd_sync(hdev, HCI_OP_READ_LOCAL_VERSION, 0, NULL, HCI_INIT_TIMEOUT);
+	if (IS_ERR(skb)) {
+		bt_dev_err(hdev, "Reading TI version information failed (%ld)",
+			   PTR_ERR(skb));
+		err = PTR_ERR(skb);
+		goto out;
+	}
+	if (skb->len != sizeof(*ver)) {
+		err = -EILSEQ;
+		goto out;
+	}
+
+	ver = (struct hci_rp_read_local_version *)skb->data;
+	if (le16_to_cpu(ver->manufacturer) != 13) {
+		err = -ENODEV;
+		goto out;
+	}
+
+	version = le16_to_cpu(ver->lmp_subver);
+
+out:
+	if (err) bt_dev_err(hdev, "Failed to read TI version info: %d", err);
+	kfree_skb(skb);
+	return err ? err : version;
+}
+
+/**
+ * download_firmware -
+ *	internal function which parses through the .bts firmware
+ *	script file intreprets SEND, DELAY actions only as of now
+ */
+static int download_firmware(struct ll_device *lldev)
+{
+	unsigned short chip, min_ver, maj_ver;
+	int version, err, len;
+	unsigned char *ptr, *action_ptr;
+	unsigned char bts_scr_name[40];	/* 40 char long bts scr name? */
+	const struct firmware *fw;
+	struct sk_buff *skb;
+	struct hci_command *cmd;
+
+	version = read_local_version(lldev->hu.hdev);
+	if (version < 0)
+		return version;
+
+	chip = (version & 0x7C00) >> 10;
+	min_ver = (version & 0x007F);
+	maj_ver = (version & 0x0380) >> 7;
+	if (version & 0x8000)
+		maj_ver |= 0x0008;
+
+	snprintf(bts_scr_name, sizeof(bts_scr_name),
+		 "ti-connectivity/TIInit_%d.%d.%d.bts",
+		 chip, maj_ver, min_ver);
+
+	err = request_firmware(&fw, bts_scr_name, &lldev->serdev->dev);
+	if (err || !fw->data || !fw->size) {
+		bt_dev_err(lldev->hu.hdev, "request_firmware failed(errno %d) for %s",
+			   err, bts_scr_name);
+		return -EINVAL;
+	}
+	ptr = (void *)fw->data;
+	len = fw->size;
+	/* bts_header to remove out magic number and
+	 * version
+	 */
+	ptr += sizeof(struct bts_header);
+	len -= sizeof(struct bts_header);
+
+	while (len > 0 && ptr) {
+		bt_dev_dbg(lldev->hu.hdev, " action size %d, type %d ",
+			   ((struct bts_action *)ptr)->size,
+			   ((struct bts_action *)ptr)->type);
+
+		action_ptr = &(((struct bts_action *)ptr)->data[0]);
+
+		switch (((struct bts_action *)ptr)->type) {
+		case ACTION_SEND_COMMAND:	/* action send */
+			bt_dev_dbg(lldev->hu.hdev, "S");
+			cmd = (struct hci_command *)action_ptr;
+			if (cmd->opcode == 0xff36) {
+				/* ignore remote change
+				 * baud rate HCI VS command */
+				bt_dev_warn(lldev->hu.hdev, "change remote baud rate command in firmware");
+				break;
+			}
+			if (cmd->prefix != 1)
+				bt_dev_dbg(lldev->hu.hdev, "command type %d\n", cmd->prefix);
+
+			skb = __hci_cmd_sync(lldev->hu.hdev, cmd->opcode, cmd->plen, &cmd->speed, HCI_INIT_TIMEOUT);
+			if (IS_ERR(skb)) {
+				bt_dev_err(lldev->hu.hdev, "send command failed\n");
+				goto out_rel_fw;
+			}
+			kfree_skb(skb);
+			break;
+		case ACTION_WAIT_EVENT:  /* wait */
+			/* no need to wait as command was synchronous */
+			bt_dev_dbg(lldev->hu.hdev, "W");
+			break;
+		case ACTION_DELAY:	/* sleep */
+			bt_dev_info(lldev->hu.hdev, "sleep command in scr");
+			mdelay(((struct bts_action_delay *)action_ptr)->msec);
+			break;
+		}
+		len -= (sizeof(struct bts_action) +
+			((struct bts_action *)ptr)->size);
+		ptr += sizeof(struct bts_action) +
+			((struct bts_action *)ptr)->size;
+	}
+
+out_rel_fw:
+	/* fw download complete */
+	release_firmware(fw);
+	return err;
+}
+
+static int ll_setup(struct hci_uart *hu)
+{
+	int err, retry = 3;
+	struct ll_device *lldev;
+	struct serdev_device *serdev = hu->serdev;
+	u32 speed;
+
+	if (!serdev)
+		return 0;
+
+	lldev = serdev_device_get_drvdata(serdev);
+
+	serdev_device_set_flow_control(serdev, true);
+
+	do {
+		/* Configure BT_EN to HIGH state */
+		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+		msleep(5);
+		gpiod_set_value_cansleep(lldev->enable_gpio, 1);
+		msleep(100);
+
+		err = download_firmware(lldev);
+		if (!err)
+			break;
+
+		/* Toggle BT_EN and retry */
+		bt_dev_err(hu->hdev, "download firmware failed, retrying...");
+	} while (retry--);
+
+	if (err)
+		return err;
+
+	/* Operational speed if any */
+	if (hu->oper_speed)
+		speed = hu->oper_speed;
+	else if (hu->proto->oper_speed)
+		speed = hu->proto->oper_speed;
+	else
+		speed = 0;
+
+	if (speed) {
+		struct sk_buff *skb = __hci_cmd_sync(hu->hdev, 0xff36, sizeof(speed), &speed, HCI_INIT_TIMEOUT);
+		if (!IS_ERR(skb)) {
+			kfree_skb(skb);
+			serdev_device_set_baudrate(serdev, speed);
+		}
+	}
+
+	return 0;
+}
+
+static const struct hci_uart_proto llp;
+
+static int hci_ti_probe(struct serdev_device *serdev)
+{
+	struct hci_uart *hu;
+	struct ll_device *lldev;
+	u32 max_speed = 3000000;
+
+	lldev = devm_kzalloc(&serdev->dev, sizeof(struct ll_device), GFP_KERNEL);
+	if (!lldev)
+		return -ENOMEM;
+	hu = &lldev->hu;
+
+	serdev_device_set_drvdata(serdev, lldev);
+	lldev->serdev = hu->serdev = serdev;
+
+	lldev->enable_gpio = devm_gpiod_get_optional(&serdev->dev, "enable", GPIOD_OUT_LOW);
+	if (IS_ERR(lldev->enable_gpio))
+		return PTR_ERR(lldev->enable_gpio);
+
+	of_property_read_u32(serdev->dev.of_node, "max-speed", &max_speed);
+	hci_uart_set_speeds(hu, 115200, max_speed);
+
+	return hci_uart_register_device(hu, &llp);
+}
+
+static void hci_ti_remove(struct serdev_device *serdev)
+{
+	struct ll_device *lldev = serdev_device_get_drvdata(serdev);
+	struct hci_uart *hu = &lldev->hu;
+	struct hci_dev *hdev = hu->hdev;
+
+	cancel_work_sync(&hu->write_work);
+
+	hci_unregister_dev(hdev);
+	hci_free_dev(hdev);
+	hu->proto->close(hu);
+}
+
+static const struct of_device_id hci_ti_of_match[] = {
+	{ .compatible = "ti,wl1831-st" },
+	{ .compatible = "ti,wl1835-st" },
+	{ .compatible = "ti,wl1837-st" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, hci_ti_of_match);
+
+static struct serdev_device_driver hci_ti_drv = {
+	.driver		= {
+		.name	= "hci-ti",
+		.of_match_table = of_match_ptr(hci_ti_of_match),
+	},
+	.probe	= hci_ti_probe,
+	.remove	= hci_ti_remove,
+};
+#else
+#define ll_setup NULL
+#endif
+
 static const struct hci_uart_proto llp = {
 	.id		= HCI_UART_LL,
 	.name		= "LL",
+	.setup		= ll_setup,
 	.open		= ll_open,
 	.close		= ll_close,
 	.recv		= ll_recv,
@@ -518,10 +773,14 @@ static const struct hci_uart_proto llp = {
 
 int __init ll_init(void)
 {
+	serdev_device_driver_register(&hci_ti_drv);
+
 	return hci_uart_register_proto(&llp);
 }
 
 int __exit ll_deinit(void)
 {
+	serdev_device_driver_unregister(&hci_ti_drv);
+
 	return hci_uart_unregister_proto(&llp);
 }
-- 
2.10.1

^ permalink raw reply related	[flat|nested] 51+ messages in thread
* [PATCH v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
@ 2017-04-07 14:35         ` Rob Herring
  0 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-07 14:35 UTC (permalink / raw)
  To: linux-arm-kernel

Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
The TI-ST adds firmware loading, GPIO control, and shared access for
NFC, FM radio, etc. For now, we're only implementing what is needed for
BT. This mirrors other drivers like BCM and Intel, but uses the new
serdev bus.

The firmware loading is greatly simplified by using existing
infrastructure to send commands. It may be a bit slower than the
original code using synchronous functions, but the real bottleneck is
likely doing firmware load at 115.2kbps.

Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Cc: linux-bluetooth at vger.kernel.org
---
v2:
- Use IS_ENABLED() to fix module build

 drivers/bluetooth/hci_ll.c | 261 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 260 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
index 02692fe30279..77648adfd5c9 100644
--- a/drivers/bluetooth/hci_ll.c
+++ b/drivers/bluetooth/hci_ll.c
@@ -34,20 +34,23 @@
 #include <linux/sched.h>
 #include <linux/types.h>
 #include <linux/fcntl.h>
+#include <linux/firmware.h>
 #include <linux/interrupt.h>
 #include <linux/ptrace.h>
 #include <linux/poll.h>
 
 #include <linux/slab.h>
-#include <linux/tty.h>
 #include <linux/errno.h>
 #include <linux/string.h>
 #include <linux/signal.h>
 #include <linux/ioctl.h>
+#include <linux/serdev.h>
 #include <linux/skbuff.h>
+#include <linux/ti_wilink_st.h>
 
 #include <net/bluetooth/bluetooth.h>
 #include <net/bluetooth/hci_core.h>
+#include <linux/gpio/consumer.h>
 
 #include "hci_uart.h"
 
@@ -76,6 +79,12 @@ struct hcill_cmd {
 	u8 cmd;
 } __packed;
 
+struct ll_device {
+	struct hci_uart hu;
+	struct serdev_device *serdev;
+	struct gpio_desc *enable_gpio;
+};
+
 struct ll_struct {
 	unsigned long rx_state;
 	unsigned long rx_count;
@@ -136,6 +145,9 @@ static int ll_open(struct hci_uart *hu)
 
 	hu->priv = ll;
 
+	if (hu->serdev)
+		serdev_device_open(hu->serdev);
+
 	return 0;
 }
 
@@ -164,6 +176,13 @@ static int ll_close(struct hci_uart *hu)
 
 	kfree_skb(ll->rx_skb);
 
+	if (hu->serdev) {
+		struct ll_device *lldev = serdev_device_get_drvdata(hu->serdev);
+		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+
+		serdev_device_close(hu->serdev);
+	}
+
 	hu->priv = NULL;
 
 	kfree(ll);
@@ -505,9 +524,245 @@ static struct sk_buff *ll_dequeue(struct hci_uart *hu)
 	return skb_dequeue(&ll->txq);
 }
 
+#if IS_ENABLED(CONFIG_SERIAL_DEV_BUS)
+static int read_local_version(struct hci_dev *hdev)
+{
+	int err = 0;
+	unsigned short version = 0;
+	struct sk_buff *skb;
+	struct hci_rp_read_local_version *ver;
+
+	skb = __hci_cmd_sync(hdev, HCI_OP_READ_LOCAL_VERSION, 0, NULL, HCI_INIT_TIMEOUT);
+	if (IS_ERR(skb)) {
+		bt_dev_err(hdev, "Reading TI version information failed (%ld)",
+			   PTR_ERR(skb));
+		err = PTR_ERR(skb);
+		goto out;
+	}
+	if (skb->len != sizeof(*ver)) {
+		err = -EILSEQ;
+		goto out;
+	}
+
+	ver = (struct hci_rp_read_local_version *)skb->data;
+	if (le16_to_cpu(ver->manufacturer) != 13) {
+		err = -ENODEV;
+		goto out;
+	}
+
+	version = le16_to_cpu(ver->lmp_subver);
+
+out:
+	if (err) bt_dev_err(hdev, "Failed to read TI version info: %d", err);
+	kfree_skb(skb);
+	return err ? err : version;
+}
+
+/**
+ * download_firmware -
+ *	internal function which parses through the .bts firmware
+ *	script file intreprets SEND, DELAY actions only as of now
+ */
+static int download_firmware(struct ll_device *lldev)
+{
+	unsigned short chip, min_ver, maj_ver;
+	int version, err, len;
+	unsigned char *ptr, *action_ptr;
+	unsigned char bts_scr_name[40];	/* 40 char long bts scr name? */
+	const struct firmware *fw;
+	struct sk_buff *skb;
+	struct hci_command *cmd;
+
+	version = read_local_version(lldev->hu.hdev);
+	if (version < 0)
+		return version;
+
+	chip = (version & 0x7C00) >> 10;
+	min_ver = (version & 0x007F);
+	maj_ver = (version & 0x0380) >> 7;
+	if (version & 0x8000)
+		maj_ver |= 0x0008;
+
+	snprintf(bts_scr_name, sizeof(bts_scr_name),
+		 "ti-connectivity/TIInit_%d.%d.%d.bts",
+		 chip, maj_ver, min_ver);
+
+	err = request_firmware(&fw, bts_scr_name, &lldev->serdev->dev);
+	if (err || !fw->data || !fw->size) {
+		bt_dev_err(lldev->hu.hdev, "request_firmware failed(errno %d) for %s",
+			   err, bts_scr_name);
+		return -EINVAL;
+	}
+	ptr = (void *)fw->data;
+	len = fw->size;
+	/* bts_header to remove out magic number and
+	 * version
+	 */
+	ptr += sizeof(struct bts_header);
+	len -= sizeof(struct bts_header);
+
+	while (len > 0 && ptr) {
+		bt_dev_dbg(lldev->hu.hdev, " action size %d, type %d ",
+			   ((struct bts_action *)ptr)->size,
+			   ((struct bts_action *)ptr)->type);
+
+		action_ptr = &(((struct bts_action *)ptr)->data[0]);
+
+		switch (((struct bts_action *)ptr)->type) {
+		case ACTION_SEND_COMMAND:	/* action send */
+			bt_dev_dbg(lldev->hu.hdev, "S");
+			cmd = (struct hci_command *)action_ptr;
+			if (cmd->opcode == 0xff36) {
+				/* ignore remote change
+				 * baud rate HCI VS command */
+				bt_dev_warn(lldev->hu.hdev, "change remote baud rate command in firmware");
+				break;
+			}
+			if (cmd->prefix != 1)
+				bt_dev_dbg(lldev->hu.hdev, "command type %d\n", cmd->prefix);
+
+			skb = __hci_cmd_sync(lldev->hu.hdev, cmd->opcode, cmd->plen, &cmd->speed, HCI_INIT_TIMEOUT);
+			if (IS_ERR(skb)) {
+				bt_dev_err(lldev->hu.hdev, "send command failed\n");
+				goto out_rel_fw;
+			}
+			kfree_skb(skb);
+			break;
+		case ACTION_WAIT_EVENT:  /* wait */
+			/* no need to wait as command was synchronous */
+			bt_dev_dbg(lldev->hu.hdev, "W");
+			break;
+		case ACTION_DELAY:	/* sleep */
+			bt_dev_info(lldev->hu.hdev, "sleep command in scr");
+			mdelay(((struct bts_action_delay *)action_ptr)->msec);
+			break;
+		}
+		len -= (sizeof(struct bts_action) +
+			((struct bts_action *)ptr)->size);
+		ptr += sizeof(struct bts_action) +
+			((struct bts_action *)ptr)->size;
+	}
+
+out_rel_fw:
+	/* fw download complete */
+	release_firmware(fw);
+	return err;
+}
+
+static int ll_setup(struct hci_uart *hu)
+{
+	int err, retry = 3;
+	struct ll_device *lldev;
+	struct serdev_device *serdev = hu->serdev;
+	u32 speed;
+
+	if (!serdev)
+		return 0;
+
+	lldev = serdev_device_get_drvdata(serdev);
+
+	serdev_device_set_flow_control(serdev, true);
+
+	do {
+		/* Configure BT_EN to HIGH state */
+		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
+		msleep(5);
+		gpiod_set_value_cansleep(lldev->enable_gpio, 1);
+		msleep(100);
+
+		err = download_firmware(lldev);
+		if (!err)
+			break;
+
+		/* Toggle BT_EN and retry */
+		bt_dev_err(hu->hdev, "download firmware failed, retrying...");
+	} while (retry--);
+
+	if (err)
+		return err;
+
+	/* Operational speed if any */
+	if (hu->oper_speed)
+		speed = hu->oper_speed;
+	else if (hu->proto->oper_speed)
+		speed = hu->proto->oper_speed;
+	else
+		speed = 0;
+
+	if (speed) {
+		struct sk_buff *skb = __hci_cmd_sync(hu->hdev, 0xff36, sizeof(speed), &speed, HCI_INIT_TIMEOUT);
+		if (!IS_ERR(skb)) {
+			kfree_skb(skb);
+			serdev_device_set_baudrate(serdev, speed);
+		}
+	}
+
+	return 0;
+}
+
+static const struct hci_uart_proto llp;
+
+static int hci_ti_probe(struct serdev_device *serdev)
+{
+	struct hci_uart *hu;
+	struct ll_device *lldev;
+	u32 max_speed = 3000000;
+
+	lldev = devm_kzalloc(&serdev->dev, sizeof(struct ll_device), GFP_KERNEL);
+	if (!lldev)
+		return -ENOMEM;
+	hu = &lldev->hu;
+
+	serdev_device_set_drvdata(serdev, lldev);
+	lldev->serdev = hu->serdev = serdev;
+
+	lldev->enable_gpio = devm_gpiod_get_optional(&serdev->dev, "enable", GPIOD_OUT_LOW);
+	if (IS_ERR(lldev->enable_gpio))
+		return PTR_ERR(lldev->enable_gpio);
+
+	of_property_read_u32(serdev->dev.of_node, "max-speed", &max_speed);
+	hci_uart_set_speeds(hu, 115200, max_speed);
+
+	return hci_uart_register_device(hu, &llp);
+}
+
+static void hci_ti_remove(struct serdev_device *serdev)
+{
+	struct ll_device *lldev = serdev_device_get_drvdata(serdev);
+	struct hci_uart *hu = &lldev->hu;
+	struct hci_dev *hdev = hu->hdev;
+
+	cancel_work_sync(&hu->write_work);
+
+	hci_unregister_dev(hdev);
+	hci_free_dev(hdev);
+	hu->proto->close(hu);
+}
+
+static const struct of_device_id hci_ti_of_match[] = {
+	{ .compatible = "ti,wl1831-st" },
+	{ .compatible = "ti,wl1835-st" },
+	{ .compatible = "ti,wl1837-st" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, hci_ti_of_match);
+
+static struct serdev_device_driver hci_ti_drv = {
+	.driver		= {
+		.name	= "hci-ti",
+		.of_match_table = of_match_ptr(hci_ti_of_match),
+	},
+	.probe	= hci_ti_probe,
+	.remove	= hci_ti_remove,
+};
+#else
+#define ll_setup NULL
+#endif
+
 static const struct hci_uart_proto llp = {
 	.id		= HCI_UART_LL,
 	.name		= "LL",
+	.setup		= ll_setup,
 	.open		= ll_open,
 	.close		= ll_close,
 	.recv		= ll_recv,
@@ -518,10 +773,14 @@ static const struct hci_uart_proto llp = {
 
 int __init ll_init(void)
 {
+	serdev_device_driver_register(&hci_ti_drv);
+
 	return hci_uart_register_proto(&llp);
 }
 
 int __exit ll_deinit(void)
 {
+	serdev_device_driver_unregister(&hci_ti_drv);
+
 	return hci_uart_unregister_proto(&llp);
 }
-- 
2.10.1

^ permalink raw reply related	[flat|nested] 51+ messages in thread
* Re: [PATCH v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
  2017-04-07 14:35         ` Rob Herring
  (?)
@ 2017-04-07 17:09           ` Dan Williams
  -1 siblings, 0 replies; 51+ messages in thread
From: Dan Williams @ 2017-04-07 17:09 UTC (permalink / raw)
  To: Rob Herring, Marcel Holtmann, linux-bluetooth
  Cc: linux-arm-kernel, Gustavo Padovan, Johan Hedberg, Mark Rutland,
	Wei Xu, Eyal Reizer, Satish Patel, netdev, devicetree

On Fri, 2017-04-07 at 09:35 -0500, Rob Herring wrote:
> Turns out that the LL protocol and the TI-ST are the same thing
> AFAICT.
> The TI-ST adds firmware loading, GPIO control, and shared access for
> NFC, FM radio, etc. For now, we're only implementing what is needed
> for
> BT. This mirrors other drivers like BCM and Intel, but uses the new
> serdev bus.
> 
> The firmware loading is greatly simplified by using existing
> infrastructure to send commands. It may be a bit slower than the
> original code using synchronous functions, but the real bottleneck is
> likely doing firmware load at 115.2kbps.

Is there no way to put the TI-specific stuff into a TI UART module
rather than building it into the generic one?

Dan

> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Marcel Holtmann <marcel@holtmann.org>
> Cc: Gustavo Padovan <gustavo@padovan.org>
> Cc: Johan Hedberg <johan.hedberg@gmail.com>
> Cc: linux-bluetooth@vger.kernel.org
> ---
> v2:
> - Use IS_ENABLED() to fix module build
> 
>  drivers/bluetooth/hci_ll.c | 261
> ++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 260 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
> index 02692fe30279..77648adfd5c9 100644
> --- a/drivers/bluetooth/hci_ll.c
> +++ b/drivers/bluetooth/hci_ll.c
> @@ -34,20 +34,23 @@
>  #include <linux/sched.h>
>  #include <linux/types.h>
>  #include <linux/fcntl.h>
> +#include <linux/firmware.h>
>  #include <linux/interrupt.h>
>  #include <linux/ptrace.h>
>  #include <linux/poll.h>
>  
>  #include <linux/slab.h>
> -#include <linux/tty.h>
>  #include <linux/errno.h>
>  #include <linux/string.h>
>  #include <linux/signal.h>
>  #include <linux/ioctl.h>
> +#include <linux/serdev.h>
>  #include <linux/skbuff.h>
> +#include <linux/ti_wilink_st.h>
>  
>  #include <net/bluetooth/bluetooth.h>
>  #include <net/bluetooth/hci_core.h>
> +#include <linux/gpio/consumer.h>
>  
>  #include "hci_uart.h"
>  
> @@ -76,6 +79,12 @@ struct hcill_cmd {
>  	u8 cmd;
>  } __packed;
>  
> +struct ll_device {
> +	struct hci_uart hu;
> +	struct serdev_device *serdev;
> +	struct gpio_desc *enable_gpio;
> +};
> +
>  struct ll_struct {
>  	unsigned long rx_state;
>  	unsigned long rx_count;
> @@ -136,6 +145,9 @@ static int ll_open(struct hci_uart *hu)
>  
>  	hu->priv = ll;
>  
> +	if (hu->serdev)
> +		serdev_device_open(hu->serdev);
> +
>  	return 0;
>  }
>  
> @@ -164,6 +176,13 @@ static int ll_close(struct hci_uart *hu)
>  
>  	kfree_skb(ll->rx_skb);
>  
> +	if (hu->serdev) {
> +		struct ll_device *lldev =
> serdev_device_get_drvdata(hu->serdev);
> +		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
> +
> +		serdev_device_close(hu->serdev);
> +	}
> +
>  	hu->priv = NULL;
>  
>  	kfree(ll);
> @@ -505,9 +524,245 @@ static struct sk_buff *ll_dequeue(struct
> hci_uart *hu)
>  	return skb_dequeue(&ll->txq);
>  }
>  
> +#if IS_ENABLED(CONFIG_SERIAL_DEV_BUS)
> +static int read_local_version(struct hci_dev *hdev)
> +{
> +	int err = 0;
> +	unsigned short version = 0;
> +	struct sk_buff *skb;
> +	struct hci_rp_read_local_version *ver;
> +
> +	skb = __hci_cmd_sync(hdev, HCI_OP_READ_LOCAL_VERSION, 0,
> NULL, HCI_INIT_TIMEOUT);
> +	if (IS_ERR(skb)) {
> +		bt_dev_err(hdev, "Reading TI version information
> failed (%ld)",
> +			   PTR_ERR(skb));
> +		err = PTR_ERR(skb);
> +		goto out;
> +	}
> +	if (skb->len != sizeof(*ver)) {
> +		err = -EILSEQ;
> +		goto out;
> +	}
> +
> +	ver = (struct hci_rp_read_local_version *)skb->data;
> +	if (le16_to_cpu(ver->manufacturer) != 13) {
> +		err = -ENODEV;
> +		goto out;
> +	}
> +
> +	version = le16_to_cpu(ver->lmp_subver);
> +
> +out:
> +	if (err) bt_dev_err(hdev, "Failed to read TI version info:
> %d", err);
> +	kfree_skb(skb);
> +	return err ? err : version;
> +}
> +
> +/**
> + * download_firmware -
> + *	internal function which parses through the .bts firmware
> + *	script file intreprets SEND, DELAY actions only as of now
> + */
> +static int download_firmware(struct ll_device *lldev)
> +{
> +	unsigned short chip, min_ver, maj_ver;
> +	int version, err, len;
> +	unsigned char *ptr, *action_ptr;
> +	unsigned char bts_scr_name[40];	/* 40 char long bts
> scr name? */
> +	const struct firmware *fw;
> +	struct sk_buff *skb;
> +	struct hci_command *cmd;
> +
> +	version = read_local_version(lldev->hu.hdev);
> +	if (version < 0)
> +		return version;
> +
> +	chip = (version & 0x7C00) >> 10;
> +	min_ver = (version & 0x007F);
> +	maj_ver = (version & 0x0380) >> 7;
> +	if (version & 0x8000)
> +		maj_ver |= 0x0008;
> +
> +	snprintf(bts_scr_name, sizeof(bts_scr_name),
> +		 "ti-connectivity/TIInit_%d.%d.%d.bts",
> +		 chip, maj_ver, min_ver);
> +
> +	err = request_firmware(&fw, bts_scr_name, &lldev->serdev-
> >dev);
> +	if (err || !fw->data || !fw->size) {
> +		bt_dev_err(lldev->hu.hdev, "request_firmware
> failed(errno %d) for %s",
> +			   err, bts_scr_name);
> +		return -EINVAL;
> +	}
> +	ptr = (void *)fw->data;
> +	len = fw->size;
> +	/* bts_header to remove out magic number and
> +	 * version
> +	 */
> +	ptr += sizeof(struct bts_header);
> +	len -= sizeof(struct bts_header);
> +
> +	while (len > 0 && ptr) {
> +		bt_dev_dbg(lldev->hu.hdev, " action size %d, type %d
> ",
> +			   ((struct bts_action *)ptr)->size,
> +			   ((struct bts_action *)ptr)->type);
> +
> +		action_ptr = &(((struct bts_action *)ptr)->data[0]);
> +
> +		switch (((struct bts_action *)ptr)->type) {
> +		case ACTION_SEND_COMMAND:	/* action send */
> +			bt_dev_dbg(lldev->hu.hdev, "S");
> +			cmd = (struct hci_command *)action_ptr;
> +			if (cmd->opcode == 0xff36) {
> +				/* ignore remote change
> +				 * baud rate HCI VS command */
> +				bt_dev_warn(lldev->hu.hdev, "change
> remote baud rate command in firmware");
> +				break;
> +			}
> +			if (cmd->prefix != 1)
> +				bt_dev_dbg(lldev->hu.hdev, "command
> type %d\n", cmd->prefix);
> +
> +			skb = __hci_cmd_sync(lldev->hu.hdev, cmd-
> >opcode, cmd->plen, &cmd->speed, HCI_INIT_TIMEOUT);
> +			if (IS_ERR(skb)) {
> +				bt_dev_err(lldev->hu.hdev, "send
> command failed\n");
> +				goto out_rel_fw;
> +			}
> +			kfree_skb(skb);
> +			break;
> +		case ACTION_WAIT_EVENT:  /* wait */
> +			/* no need to wait as command was
> synchronous */
> +			bt_dev_dbg(lldev->hu.hdev, "W");
> +			break;
> +		case ACTION_DELAY:	/* sleep */
> +			bt_dev_info(lldev->hu.hdev, "sleep command
> in scr");
> +			mdelay(((struct bts_action_delay
> *)action_ptr)->msec);
> +			break;
> +		}
> +		len -= (sizeof(struct bts_action) +
> +			((struct bts_action *)ptr)->size);
> +		ptr += sizeof(struct bts_action) +
> +			((struct bts_action *)ptr)->size;
> +	}
> +
> +out_rel_fw:
> +	/* fw download complete */
> +	release_firmware(fw);
> +	return err;
> +}
> +
> +static int ll_setup(struct hci_uart *hu)
> +{
> +	int err, retry = 3;
> +	struct ll_device *lldev;
> +	struct serdev_device *serdev = hu->serdev;
> +	u32 speed;
> +
> +	if (!serdev)
> +		return 0;
> +
> +	lldev = serdev_device_get_drvdata(serdev);
> +
> +	serdev_device_set_flow_control(serdev, true);
> +
> +	do {
> +		/* Configure BT_EN to HIGH state */
> +		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
> +		msleep(5);
> +		gpiod_set_value_cansleep(lldev->enable_gpio, 1);
> +		msleep(100);
> +
> +		err = download_firmware(lldev);
> +		if (!err)
> +			break;
> +
> +		/* Toggle BT_EN and retry */
> +		bt_dev_err(hu->hdev, "download firmware failed,
> retrying...");
> +	} while (retry--);
> +
> +	if (err)
> +		return err;
> +
> +	/* Operational speed if any */
> +	if (hu->oper_speed)
> +		speed = hu->oper_speed;
> +	else if (hu->proto->oper_speed)
> +		speed = hu->proto->oper_speed;
> +	else
> +		speed = 0;
> +
> +	if (speed) {
> +		struct sk_buff *skb = __hci_cmd_sync(hu->hdev,
> 0xff36, sizeof(speed), &speed, HCI_INIT_TIMEOUT);
> +		if (!IS_ERR(skb)) {
> +			kfree_skb(skb);
> +			serdev_device_set_baudrate(serdev, speed);
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct hci_uart_proto llp;
> +
> +static int hci_ti_probe(struct serdev_device *serdev)
> +{
> +	struct hci_uart *hu;
> +	struct ll_device *lldev;
> +	u32 max_speed = 3000000;
> +
> +	lldev = devm_kzalloc(&serdev->dev, sizeof(struct ll_device),
> GFP_KERNEL);
> +	if (!lldev)
> +		return -ENOMEM;
> +	hu = &lldev->hu;
> +
> +	serdev_device_set_drvdata(serdev, lldev);
> +	lldev->serdev = hu->serdev = serdev;
> +
> +	lldev->enable_gpio = devm_gpiod_get_optional(&serdev->dev,
> "enable", GPIOD_OUT_LOW);
> +	if (IS_ERR(lldev->enable_gpio))
> +		return PTR_ERR(lldev->enable_gpio);
> +
> +	of_property_read_u32(serdev->dev.of_node, "max-speed",
> &max_speed);
> +	hci_uart_set_speeds(hu, 115200, max_speed);
> +
> +	return hci_uart_register_device(hu, &llp);
> +}
> +
> +static void hci_ti_remove(struct serdev_device *serdev)
> +{
> +	struct ll_device *lldev = serdev_device_get_drvdata(serdev);
> +	struct hci_uart *hu = &lldev->hu;
> +	struct hci_dev *hdev = hu->hdev;
> +
> +	cancel_work_sync(&hu->write_work);
> +
> +	hci_unregister_dev(hdev);
> +	hci_free_dev(hdev);
> +	hu->proto->close(hu);
> +}
> +
> +static const struct of_device_id hci_ti_of_match[] = {
> +	{ .compatible = "ti,wl1831-st" },
> +	{ .compatible = "ti,wl1835-st" },
> +	{ .compatible = "ti,wl1837-st" },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, hci_ti_of_match);
> +
> +static struct serdev_device_driver hci_ti_drv = {
> +	.driver		= {
> +		.name	= "hci-ti",
> +		.of_match_table = of_match_ptr(hci_ti_of_match),
> +	},
> +	.probe	= hci_ti_probe,
> +	.remove	= hci_ti_remove,
> +};
> +#else
> +#define ll_setup NULL
> +#endif
> +
>  static const struct hci_uart_proto llp = {
>  	.id		= HCI_UART_LL,
>  	.name		= "LL",
> +	.setup		= ll_setup,
>  	.open		= ll_open,
>  	.close		= ll_close,
>  	.recv		= ll_recv,
> @@ -518,10 +773,14 @@ static const struct hci_uart_proto llp = {
>  
>  int __init ll_init(void)
>  {
> +	serdev_device_driver_register(&hci_ti_drv);
> +
>  	return hci_uart_register_proto(&llp);
>  }
>  
>  int __exit ll_deinit(void)
>  {
> +	serdev_device_driver_unregister(&hci_ti_drv);
> +
>  	return hci_uart_unregister_proto(&llp);
>  }

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
@ 2017-04-07 17:09           ` Dan Williams
  0 siblings, 0 replies; 51+ messages in thread
From: Dan Williams @ 2017-04-07 17:09 UTC (permalink / raw)
  To: Rob Herring, Marcel Holtmann, linux-bluetooth
  Cc: linux-arm-kernel, Gustavo Padovan, Johan Hedberg, Mark Rutland,
	Wei Xu, Eyal Reizer, Satish Patel, netdev, devicetree

On Fri, 2017-04-07 at 09:35 -0500, Rob Herring wrote:
> Turns out that the LL protocol and the TI-ST are the same thing
> AFAICT.
> The TI-ST adds firmware loading, GPIO control, and shared access for
> NFC, FM radio, etc. For now, we're only implementing what is needed
> for
> BT. This mirrors other drivers like BCM and Intel, but uses the new
> serdev bus.
> 
> The firmware loading is greatly simplified by using existing
> infrastructure to send commands. It may be a bit slower than the
> original code using synchronous functions, but the real bottleneck is
> likely doing firmware load at 115.2kbps.

Is there no way to put the TI-specific stuff into a TI UART module
rather than building it into the generic one?

Dan

> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Marcel Holtmann <marcel@holtmann.org>
> Cc: Gustavo Padovan <gustavo@padovan.org>
> Cc: Johan Hedberg <johan.hedberg@gmail.com>
> Cc: linux-bluetooth@vger.kernel.org
> ---
> v2:
> - Use IS_ENABLED() to fix module build
> 
>  drivers/bluetooth/hci_ll.c | 261
> ++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 260 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
> index 02692fe30279..77648adfd5c9 100644
> --- a/drivers/bluetooth/hci_ll.c
> +++ b/drivers/bluetooth/hci_ll.c
> @@ -34,20 +34,23 @@
>  #include <linux/sched.h>
>  #include <linux/types.h>
>  #include <linux/fcntl.h>
> +#include <linux/firmware.h>
>  #include <linux/interrupt.h>
>  #include <linux/ptrace.h>
>  #include <linux/poll.h>
>  
>  #include <linux/slab.h>
> -#include <linux/tty.h>
>  #include <linux/errno.h>
>  #include <linux/string.h>
>  #include <linux/signal.h>
>  #include <linux/ioctl.h>
> +#include <linux/serdev.h>
>  #include <linux/skbuff.h>
> +#include <linux/ti_wilink_st.h>
>  
>  #include <net/bluetooth/bluetooth.h>
>  #include <net/bluetooth/hci_core.h>
> +#include <linux/gpio/consumer.h>
>  
>  #include "hci_uart.h"
>  
> @@ -76,6 +79,12 @@ struct hcill_cmd {
>  	u8 cmd;
>  } __packed;
>  
> +struct ll_device {
> +	struct hci_uart hu;
> +	struct serdev_device *serdev;
> +	struct gpio_desc *enable_gpio;
> +};
> +
>  struct ll_struct {
>  	unsigned long rx_state;
>  	unsigned long rx_count;
> @@ -136,6 +145,9 @@ static int ll_open(struct hci_uart *hu)
>  
>  	hu->priv = ll;
>  
> +	if (hu->serdev)
> +		serdev_device_open(hu->serdev);
> +
>  	return 0;
>  }
>  
> @@ -164,6 +176,13 @@ static int ll_close(struct hci_uart *hu)
>  
>  	kfree_skb(ll->rx_skb);
>  
> +	if (hu->serdev) {
> +		struct ll_device *lldev =
> serdev_device_get_drvdata(hu->serdev);
> +		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
> +
> +		serdev_device_close(hu->serdev);
> +	}
> +
>  	hu->priv = NULL;
>  
>  	kfree(ll);
> @@ -505,9 +524,245 @@ static struct sk_buff *ll_dequeue(struct
> hci_uart *hu)
>  	return skb_dequeue(&ll->txq);
>  }
>  
> +#if IS_ENABLED(CONFIG_SERIAL_DEV_BUS)
> +static int read_local_version(struct hci_dev *hdev)
> +{
> +	int err = 0;
> +	unsigned short version = 0;
> +	struct sk_buff *skb;
> +	struct hci_rp_read_local_version *ver;
> +
> +	skb = __hci_cmd_sync(hdev, HCI_OP_READ_LOCAL_VERSION, 0,
> NULL, HCI_INIT_TIMEOUT);
> +	if (IS_ERR(skb)) {
> +		bt_dev_err(hdev, "Reading TI version information
> failed (%ld)",
> +			   PTR_ERR(skb));
> +		err = PTR_ERR(skb);
> +		goto out;
> +	}
> +	if (skb->len != sizeof(*ver)) {
> +		err = -EILSEQ;
> +		goto out;
> +	}
> +
> +	ver = (struct hci_rp_read_local_version *)skb->data;
> +	if (le16_to_cpu(ver->manufacturer) != 13) {
> +		err = -ENODEV;
> +		goto out;
> +	}
> +
> +	version = le16_to_cpu(ver->lmp_subver);
> +
> +out:
> +	if (err) bt_dev_err(hdev, "Failed to read TI version info:
> %d", err);
> +	kfree_skb(skb);
> +	return err ? err : version;
> +}
> +
> +/**
> + * download_firmware -
> + *	internal function which parses through the .bts firmware
> + *	script file intreprets SEND, DELAY actions only as of now
> + */
> +static int download_firmware(struct ll_device *lldev)
> +{
> +	unsigned short chip, min_ver, maj_ver;
> +	int version, err, len;
> +	unsigned char *ptr, *action_ptr;
> +	unsigned char bts_scr_name[40];	/* 40 char long bts
> scr name? */
> +	const struct firmware *fw;
> +	struct sk_buff *skb;
> +	struct hci_command *cmd;
> +
> +	version = read_local_version(lldev->hu.hdev);
> +	if (version < 0)
> +		return version;
> +
> +	chip = (version & 0x7C00) >> 10;
> +	min_ver = (version & 0x007F);
> +	maj_ver = (version & 0x0380) >> 7;
> +	if (version & 0x8000)
> +		maj_ver |= 0x0008;
> +
> +	snprintf(bts_scr_name, sizeof(bts_scr_name),
> +		 "ti-connectivity/TIInit_%d.%d.%d.bts",
> +		 chip, maj_ver, min_ver);
> +
> +	err = request_firmware(&fw, bts_scr_name, &lldev->serdev-
> >dev);
> +	if (err || !fw->data || !fw->size) {
> +		bt_dev_err(lldev->hu.hdev, "request_firmware
> failed(errno %d) for %s",
> +			   err, bts_scr_name);
> +		return -EINVAL;
> +	}
> +	ptr = (void *)fw->data;
> +	len = fw->size;
> +	/* bts_header to remove out magic number and
> +	 * version
> +	 */
> +	ptr += sizeof(struct bts_header);
> +	len -= sizeof(struct bts_header);
> +
> +	while (len > 0 && ptr) {
> +		bt_dev_dbg(lldev->hu.hdev, " action size %d, type %d
> ",
> +			   ((struct bts_action *)ptr)->size,
> +			   ((struct bts_action *)ptr)->type);
> +
> +		action_ptr = &(((struct bts_action *)ptr)->data[0]);
> +
> +		switch (((struct bts_action *)ptr)->type) {
> +		case ACTION_SEND_COMMAND:	/* action send */
> +			bt_dev_dbg(lldev->hu.hdev, "S");
> +			cmd = (struct hci_command *)action_ptr;
> +			if (cmd->opcode == 0xff36) {
> +				/* ignore remote change
> +				 * baud rate HCI VS command */
> +				bt_dev_warn(lldev->hu.hdev, "change
> remote baud rate command in firmware");
> +				break;
> +			}
> +			if (cmd->prefix != 1)
> +				bt_dev_dbg(lldev->hu.hdev, "command
> type %d\n", cmd->prefix);
> +
> +			skb = __hci_cmd_sync(lldev->hu.hdev, cmd-
> >opcode, cmd->plen, &cmd->speed, HCI_INIT_TIMEOUT);
> +			if (IS_ERR(skb)) {
> +				bt_dev_err(lldev->hu.hdev, "send
> command failed\n");
> +				goto out_rel_fw;
> +			}
> +			kfree_skb(skb);
> +			break;
> +		case ACTION_WAIT_EVENT:  /* wait */
> +			/* no need to wait as command was
> synchronous */
> +			bt_dev_dbg(lldev->hu.hdev, "W");
> +			break;
> +		case ACTION_DELAY:	/* sleep */
> +			bt_dev_info(lldev->hu.hdev, "sleep command
> in scr");
> +			mdelay(((struct bts_action_delay
> *)action_ptr)->msec);
> +			break;
> +		}
> +		len -= (sizeof(struct bts_action) +
> +			((struct bts_action *)ptr)->size);
> +		ptr += sizeof(struct bts_action) +
> +			((struct bts_action *)ptr)->size;
> +	}
> +
> +out_rel_fw:
> +	/* fw download complete */
> +	release_firmware(fw);
> +	return err;
> +}
> +
> +static int ll_setup(struct hci_uart *hu)
> +{
> +	int err, retry = 3;
> +	struct ll_device *lldev;
> +	struct serdev_device *serdev = hu->serdev;
> +	u32 speed;
> +
> +	if (!serdev)
> +		return 0;
> +
> +	lldev = serdev_device_get_drvdata(serdev);
> +
> +	serdev_device_set_flow_control(serdev, true);
> +
> +	do {
> +		/* Configure BT_EN to HIGH state */
> +		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
> +		msleep(5);
> +		gpiod_set_value_cansleep(lldev->enable_gpio, 1);
> +		msleep(100);
> +
> +		err = download_firmware(lldev);
> +		if (!err)
> +			break;
> +
> +		/* Toggle BT_EN and retry */
> +		bt_dev_err(hu->hdev, "download firmware failed,
> retrying...");
> +	} while (retry--);
> +
> +	if (err)
> +		return err;
> +
> +	/* Operational speed if any */
> +	if (hu->oper_speed)
> +		speed = hu->oper_speed;
> +	else if (hu->proto->oper_speed)
> +		speed = hu->proto->oper_speed;
> +	else
> +		speed = 0;
> +
> +	if (speed) {
> +		struct sk_buff *skb = __hci_cmd_sync(hu->hdev,
> 0xff36, sizeof(speed), &speed, HCI_INIT_TIMEOUT);
> +		if (!IS_ERR(skb)) {
> +			kfree_skb(skb);
> +			serdev_device_set_baudrate(serdev, speed);
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct hci_uart_proto llp;
> +
> +static int hci_ti_probe(struct serdev_device *serdev)
> +{
> +	struct hci_uart *hu;
> +	struct ll_device *lldev;
> +	u32 max_speed = 3000000;
> +
> +	lldev = devm_kzalloc(&serdev->dev, sizeof(struct ll_device),
> GFP_KERNEL);
> +	if (!lldev)
> +		return -ENOMEM;
> +	hu = &lldev->hu;
> +
> +	serdev_device_set_drvdata(serdev, lldev);
> +	lldev->serdev = hu->serdev = serdev;
> +
> +	lldev->enable_gpio = devm_gpiod_get_optional(&serdev->dev,
> "enable", GPIOD_OUT_LOW);
> +	if (IS_ERR(lldev->enable_gpio))
> +		return PTR_ERR(lldev->enable_gpio);
> +
> +	of_property_read_u32(serdev->dev.of_node, "max-speed",
> &max_speed);
> +	hci_uart_set_speeds(hu, 115200, max_speed);
> +
> +	return hci_uart_register_device(hu, &llp);
> +}
> +
> +static void hci_ti_remove(struct serdev_device *serdev)
> +{
> +	struct ll_device *lldev = serdev_device_get_drvdata(serdev);
> +	struct hci_uart *hu = &lldev->hu;
> +	struct hci_dev *hdev = hu->hdev;
> +
> +	cancel_work_sync(&hu->write_work);
> +
> +	hci_unregister_dev(hdev);
> +	hci_free_dev(hdev);
> +	hu->proto->close(hu);
> +}
> +
> +static const struct of_device_id hci_ti_of_match[] = {
> +	{ .compatible = "ti,wl1831-st" },
> +	{ .compatible = "ti,wl1835-st" },
> +	{ .compatible = "ti,wl1837-st" },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, hci_ti_of_match);
> +
> +static struct serdev_device_driver hci_ti_drv = {
> +	.driver		= {
> +		.name	= "hci-ti",
> +		.of_match_table = of_match_ptr(hci_ti_of_match),
> +	},
> +	.probe	= hci_ti_probe,
> +	.remove	= hci_ti_remove,
> +};
> +#else
> +#define ll_setup NULL
> +#endif
> +
>  static const struct hci_uart_proto llp = {
>  	.id		= HCI_UART_LL,
>  	.name		= "LL",
> +	.setup		= ll_setup,
>  	.open		= ll_open,
>  	.close		= ll_close,
>  	.recv		= ll_recv,
> @@ -518,10 +773,14 @@ static const struct hci_uart_proto llp = {
>  
>  int __init ll_init(void)
>  {
> +	serdev_device_driver_register(&hci_ti_drv);
> +
>  	return hci_uart_register_proto(&llp);
>  }
>  
>  int __exit ll_deinit(void)
>  {
> +	serdev_device_driver_unregister(&hci_ti_drv);
> +
>  	return hci_uart_unregister_proto(&llp);
>  }

^ permalink raw reply	[flat|nested] 51+ messages in thread
* [PATCH v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
@ 2017-04-07 17:09           ` Dan Williams
  0 siblings, 0 replies; 51+ messages in thread
From: Dan Williams @ 2017-04-07 17:09 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, 2017-04-07 at 09:35 -0500, Rob Herring wrote:
> Turns out that the LL protocol and the TI-ST are the same thing
> AFAICT.
> The TI-ST adds firmware loading, GPIO control, and shared access for
> NFC, FM radio, etc. For now, we're only implementing what is needed
> for
> BT. This mirrors other drivers like BCM and Intel, but uses the new
> serdev bus.
> 
> The firmware loading is greatly simplified by using existing
> infrastructure to send commands. It may be a bit slower than the
> original code using synchronous functions, but the real bottleneck is
> likely doing firmware load at 115.2kbps.

Is there no way to put the TI-specific stuff into a TI UART module
rather than building it into the generic one?

Dan

> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Marcel Holtmann <marcel@holtmann.org>
> Cc: Gustavo Padovan <gustavo@padovan.org>
> Cc: Johan Hedberg <johan.hedberg@gmail.com>
> Cc: linux-bluetooth at vger.kernel.org
> ---
> v2:
> - Use IS_ENABLED() to fix module build
> 
> ?drivers/bluetooth/hci_ll.c | 261
> ++++++++++++++++++++++++++++++++++++++++++++-
> ?1 file changed, 260 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/bluetooth/hci_ll.c b/drivers/bluetooth/hci_ll.c
> index 02692fe30279..77648adfd5c9 100644
> --- a/drivers/bluetooth/hci_ll.c
> +++ b/drivers/bluetooth/hci_ll.c
> @@ -34,20 +34,23 @@
> ?#include <linux/sched.h>
> ?#include <linux/types.h>
> ?#include <linux/fcntl.h>
> +#include <linux/firmware.h>
> ?#include <linux/interrupt.h>
> ?#include <linux/ptrace.h>
> ?#include <linux/poll.h>
> ?
> ?#include <linux/slab.h>
> -#include <linux/tty.h>
> ?#include <linux/errno.h>
> ?#include <linux/string.h>
> ?#include <linux/signal.h>
> ?#include <linux/ioctl.h>
> +#include <linux/serdev.h>
> ?#include <linux/skbuff.h>
> +#include <linux/ti_wilink_st.h>
> ?
> ?#include <net/bluetooth/bluetooth.h>
> ?#include <net/bluetooth/hci_core.h>
> +#include <linux/gpio/consumer.h>
> ?
> ?#include "hci_uart.h"
> ?
> @@ -76,6 +79,12 @@ struct hcill_cmd {
> ?	u8 cmd;
> ?} __packed;
> ?
> +struct ll_device {
> +	struct hci_uart hu;
> +	struct serdev_device *serdev;
> +	struct gpio_desc *enable_gpio;
> +};
> +
> ?struct ll_struct {
> ?	unsigned long rx_state;
> ?	unsigned long rx_count;
> @@ -136,6 +145,9 @@ static int ll_open(struct hci_uart *hu)
> ?
> ?	hu->priv = ll;
> ?
> +	if (hu->serdev)
> +		serdev_device_open(hu->serdev);
> +
> ?	return 0;
> ?}
> ?
> @@ -164,6 +176,13 @@ static int ll_close(struct hci_uart *hu)
> ?
> ?	kfree_skb(ll->rx_skb);
> ?
> +	if (hu->serdev) {
> +		struct ll_device *lldev =
> serdev_device_get_drvdata(hu->serdev);
> +		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
> +
> +		serdev_device_close(hu->serdev);
> +	}
> +
> ?	hu->priv = NULL;
> ?
> ?	kfree(ll);
> @@ -505,9 +524,245 @@ static struct sk_buff *ll_dequeue(struct
> hci_uart *hu)
> ?	return skb_dequeue(&ll->txq);
> ?}
> ?
> +#if IS_ENABLED(CONFIG_SERIAL_DEV_BUS)
> +static int read_local_version(struct hci_dev *hdev)
> +{
> +	int err = 0;
> +	unsigned short version = 0;
> +	struct sk_buff *skb;
> +	struct hci_rp_read_local_version *ver;
> +
> +	skb = __hci_cmd_sync(hdev, HCI_OP_READ_LOCAL_VERSION, 0,
> NULL, HCI_INIT_TIMEOUT);
> +	if (IS_ERR(skb)) {
> +		bt_dev_err(hdev, "Reading TI version information
> failed (%ld)",
> +			???PTR_ERR(skb));
> +		err = PTR_ERR(skb);
> +		goto out;
> +	}
> +	if (skb->len != sizeof(*ver)) {
> +		err = -EILSEQ;
> +		goto out;
> +	}
> +
> +	ver = (struct hci_rp_read_local_version *)skb->data;
> +	if (le16_to_cpu(ver->manufacturer) != 13) {
> +		err = -ENODEV;
> +		goto out;
> +	}
> +
> +	version = le16_to_cpu(ver->lmp_subver);
> +
> +out:
> +	if (err) bt_dev_err(hdev, "Failed to read TI version info:
> %d", err);
> +	kfree_skb(skb);
> +	return err ? err : version;
> +}
> +
> +/**
> + * download_firmware -
> + *	internal function which parses through the .bts firmware
> + *	script file intreprets SEND, DELAY actions only as of now
> + */
> +static int download_firmware(struct ll_device *lldev)
> +{
> +	unsigned short chip, min_ver, maj_ver;
> +	int version, err, len;
> +	unsigned char *ptr, *action_ptr;
> +	unsigned char bts_scr_name[40];	/* 40 char long bts
> scr name? */
> +	const struct firmware *fw;
> +	struct sk_buff *skb;
> +	struct hci_command *cmd;
> +
> +	version = read_local_version(lldev->hu.hdev);
> +	if (version < 0)
> +		return version;
> +
> +	chip = (version & 0x7C00) >> 10;
> +	min_ver = (version & 0x007F);
> +	maj_ver = (version & 0x0380) >> 7;
> +	if (version & 0x8000)
> +		maj_ver |= 0x0008;
> +
> +	snprintf(bts_scr_name, sizeof(bts_scr_name),
> +		?"ti-connectivity/TIInit_%d.%d.%d.bts",
> +		?chip, maj_ver, min_ver);
> +
> +	err = request_firmware(&fw, bts_scr_name, &lldev->serdev-
> >dev);
> +	if (err || !fw->data || !fw->size) {
> +		bt_dev_err(lldev->hu.hdev, "request_firmware
> failed(errno %d) for %s",
> +			???err, bts_scr_name);
> +		return -EINVAL;
> +	}
> +	ptr = (void *)fw->data;
> +	len = fw->size;
> +	/* bts_header to remove out magic number and
> +	?* version
> +	?*/
> +	ptr += sizeof(struct bts_header);
> +	len -= sizeof(struct bts_header);
> +
> +	while (len > 0 && ptr) {
> +		bt_dev_dbg(lldev->hu.hdev, " action size %d, type %d
> ",
> +			???((struct bts_action *)ptr)->size,
> +			???((struct bts_action *)ptr)->type);
> +
> +		action_ptr = &(((struct bts_action *)ptr)->data[0]);
> +
> +		switch (((struct bts_action *)ptr)->type) {
> +		case ACTION_SEND_COMMAND:	/* action send */
> +			bt_dev_dbg(lldev->hu.hdev, "S");
> +			cmd = (struct hci_command *)action_ptr;
> +			if (cmd->opcode == 0xff36) {
> +				/* ignore remote change
> +				?* baud rate HCI VS command */
> +				bt_dev_warn(lldev->hu.hdev, "change
> remote baud rate command in firmware");
> +				break;
> +			}
> +			if (cmd->prefix != 1)
> +				bt_dev_dbg(lldev->hu.hdev, "command
> type %d\n", cmd->prefix);
> +
> +			skb = __hci_cmd_sync(lldev->hu.hdev, cmd-
> >opcode, cmd->plen, &cmd->speed, HCI_INIT_TIMEOUT);
> +			if (IS_ERR(skb)) {
> +				bt_dev_err(lldev->hu.hdev, "send
> command failed\n");
> +				goto out_rel_fw;
> +			}
> +			kfree_skb(skb);
> +			break;
> +		case ACTION_WAIT_EVENT:??/* wait */
> +			/* no need to wait as command was
> synchronous */
> +			bt_dev_dbg(lldev->hu.hdev, "W");
> +			break;
> +		case ACTION_DELAY:	/* sleep */
> +			bt_dev_info(lldev->hu.hdev, "sleep command
> in scr");
> +			mdelay(((struct bts_action_delay
> *)action_ptr)->msec);
> +			break;
> +		}
> +		len -= (sizeof(struct bts_action) +
> +			((struct bts_action *)ptr)->size);
> +		ptr += sizeof(struct bts_action) +
> +			((struct bts_action *)ptr)->size;
> +	}
> +
> +out_rel_fw:
> +	/* fw download complete */
> +	release_firmware(fw);
> +	return err;
> +}
> +
> +static int ll_setup(struct hci_uart *hu)
> +{
> +	int err, retry = 3;
> +	struct ll_device *lldev;
> +	struct serdev_device *serdev = hu->serdev;
> +	u32 speed;
> +
> +	if (!serdev)
> +		return 0;
> +
> +	lldev = serdev_device_get_drvdata(serdev);
> +
> +	serdev_device_set_flow_control(serdev, true);
> +
> +	do {
> +		/* Configure BT_EN to HIGH state */
> +		gpiod_set_value_cansleep(lldev->enable_gpio, 0);
> +		msleep(5);
> +		gpiod_set_value_cansleep(lldev->enable_gpio, 1);
> +		msleep(100);
> +
> +		err = download_firmware(lldev);
> +		if (!err)
> +			break;
> +
> +		/* Toggle BT_EN and retry */
> +		bt_dev_err(hu->hdev, "download firmware failed,
> retrying...");
> +	} while (retry--);
> +
> +	if (err)
> +		return err;
> +
> +	/* Operational speed if any */
> +	if (hu->oper_speed)
> +		speed = hu->oper_speed;
> +	else if (hu->proto->oper_speed)
> +		speed = hu->proto->oper_speed;
> +	else
> +		speed = 0;
> +
> +	if (speed) {
> +		struct sk_buff *skb = __hci_cmd_sync(hu->hdev,
> 0xff36, sizeof(speed), &speed, HCI_INIT_TIMEOUT);
> +		if (!IS_ERR(skb)) {
> +			kfree_skb(skb);
> +			serdev_device_set_baudrate(serdev, speed);
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static const struct hci_uart_proto llp;
> +
> +static int hci_ti_probe(struct serdev_device *serdev)
> +{
> +	struct hci_uart *hu;
> +	struct ll_device *lldev;
> +	u32 max_speed = 3000000;
> +
> +	lldev = devm_kzalloc(&serdev->dev, sizeof(struct ll_device),
> GFP_KERNEL);
> +	if (!lldev)
> +		return -ENOMEM;
> +	hu = &lldev->hu;
> +
> +	serdev_device_set_drvdata(serdev, lldev);
> +	lldev->serdev = hu->serdev = serdev;
> +
> +	lldev->enable_gpio = devm_gpiod_get_optional(&serdev->dev,
> "enable", GPIOD_OUT_LOW);
> +	if (IS_ERR(lldev->enable_gpio))
> +		return PTR_ERR(lldev->enable_gpio);
> +
> +	of_property_read_u32(serdev->dev.of_node, "max-speed",
> &max_speed);
> +	hci_uart_set_speeds(hu, 115200, max_speed);
> +
> +	return hci_uart_register_device(hu, &llp);
> +}
> +
> +static void hci_ti_remove(struct serdev_device *serdev)
> +{
> +	struct ll_device *lldev = serdev_device_get_drvdata(serdev);
> +	struct hci_uart *hu = &lldev->hu;
> +	struct hci_dev *hdev = hu->hdev;
> +
> +	cancel_work_sync(&hu->write_work);
> +
> +	hci_unregister_dev(hdev);
> +	hci_free_dev(hdev);
> +	hu->proto->close(hu);
> +}
> +
> +static const struct of_device_id hci_ti_of_match[] = {
> +	{ .compatible = "ti,wl1831-st" },
> +	{ .compatible = "ti,wl1835-st" },
> +	{ .compatible = "ti,wl1837-st" },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, hci_ti_of_match);
> +
> +static struct serdev_device_driver hci_ti_drv = {
> +	.driver		= {
> +		.name	= "hci-ti",
> +		.of_match_table = of_match_ptr(hci_ti_of_match),
> +	},
> +	.probe	= hci_ti_probe,
> +	.remove	= hci_ti_remove,
> +};
> +#else
> +#define ll_setup NULL
> +#endif
> +
> ?static const struct hci_uart_proto llp = {
> ?	.id		= HCI_UART_LL,
> ?	.name		= "LL",
> +	.setup		= ll_setup,
> ?	.open		= ll_open,
> ?	.close		= ll_close,
> ?	.recv		= ll_recv,
> @@ -518,10 +773,14 @@ static const struct hci_uart_proto llp = {
> ?
> ?int __init ll_init(void)
> ?{
> +	serdev_device_driver_register(&hci_ti_drv);
> +
> ?	return hci_uart_register_proto(&llp);
> ?}
> ?
> ?int __exit ll_deinit(void)
> ?{
> +	serdev_device_driver_unregister(&hci_ti_drv);
> +
> ?	return hci_uart_unregister_proto(&llp);
> ?}

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
  2017-04-07 17:09           ` Dan Williams
@ 2017-04-07 18:48             ` Rob Herring
  -1 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-07 18:48 UTC (permalink / raw)
  To: Dan Williams
  Cc: Marcel Holtmann, open list:BLUETOOTH DRIVERS, linux-arm-kernel,
	Gustavo Padovan, Johan Hedberg, Mark Rutland, Wei Xu,
	Eyal Reizer, Satish Patel, netdev, devicetree

On Fri, Apr 7, 2017 at 12:09 PM, Dan Williams <dcbw@redhat.com> wrote:
> On Fri, 2017-04-07 at 09:35 -0500, Rob Herring wrote:
>> Turns out that the LL protocol and the TI-ST are the same thing
>> AFAICT.
>> The TI-ST adds firmware loading, GPIO control, and shared access for
>> NFC, FM radio, etc. For now, we're only implementing what is needed
>> for
>> BT. This mirrors other drivers like BCM and Intel, but uses the new
>> serdev bus.
>>
>> The firmware loading is greatly simplified by using existing
>> infrastructure to send commands. It may be a bit slower than the
>> original code using synchronous functions, but the real bottleneck is
>> likely doing firmware load at 115.2kbps.
>
> Is there no way to put the TI-specific stuff into a TI UART module
> rather than building it into the generic one?

In case it's not clear, all of HCI_LL is the TI specific part, not
just what I'm adding. So you are talking about putting each UART BT
protocol into a separate module. I'd assume that is doable, but seems
orthogonal to this patch set. I'd also assume there was some reason
that was not done already.

Rob

^ permalink raw reply	[flat|nested] 51+ messages in thread
* [PATCH v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
@ 2017-04-07 18:48             ` Rob Herring
  0 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-04-07 18:48 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Apr 7, 2017 at 12:09 PM, Dan Williams <dcbw@redhat.com> wrote:
> On Fri, 2017-04-07 at 09:35 -0500, Rob Herring wrote:
>> Turns out that the LL protocol and the TI-ST are the same thing
>> AFAICT.
>> The TI-ST adds firmware loading, GPIO control, and shared access for
>> NFC, FM radio, etc. For now, we're only implementing what is needed
>> for
>> BT. This mirrors other drivers like BCM and Intel, but uses the new
>> serdev bus.
>>
>> The firmware loading is greatly simplified by using existing
>> infrastructure to send commands. It may be a bit slower than the
>> original code using synchronous functions, but the real bottleneck is
>> likely doing firmware load at 115.2kbps.
>
> Is there no way to put the TI-specific stuff into a TI UART module
> rather than building it into the generic one?

In case it's not clear, all of HCI_LL is the TI specific part, not
just what I'm adding. So you are talking about putting each UART BT
protocol into a separate module. I'd assume that is doable, but seems
orthogonal to this patch set. I'd also assume there was some reason
that was not done already.

Rob

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
  2017-04-07 18:48             ` Rob Herring
  (?)
@ 2017-04-07 20:09                 ` Dan Williams
  -1 siblings, 0 replies; 51+ messages in thread
From: Dan Williams @ 2017-04-07 20:09 UTC (permalink / raw)
  To: Rob Herring
  Cc: Marcel Holtmann, open list:BLUETOOTH DRIVERS,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	Gustavo Padovan, Johan Hedberg, Mark Rutland, Wei Xu,
	Eyal Reizer, Satish Patel, netdev,
	devicetree-u79uwXL29TY76Z2rM5mHXA

On Fri, 2017-04-07 at 13:48 -0500, Rob Herring wrote:
> On Fri, Apr 7, 2017 at 12:09 PM, Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> wrote:
> > On Fri, 2017-04-07 at 09:35 -0500, Rob Herring wrote:
> > > Turns out that the LL protocol and the TI-ST are the same thing
> > > AFAICT.
> > > The TI-ST adds firmware loading, GPIO control, and shared access
> > > for
> > > NFC, FM radio, etc. For now, we're only implementing what is
> > > needed
> > > for
> > > BT. This mirrors other drivers like BCM and Intel, but uses the
> > > new
> > > serdev bus.
> > > 
> > > The firmware loading is greatly simplified by using existing
> > > infrastructure to send commands. It may be a bit slower than the
> > > original code using synchronous functions, but the real
> > > bottleneck is
> > > likely doing firmware load at 115.2kbps.
> > 
> > Is there no way to put the TI-specific stuff into a TI UART module
> > rather than building it into the generic one?
> 
> In case it's not clear, all of HCI_LL is the TI specific part, not
> just what I'm adding. So you are talking about putting each UART BT
> protocol into a separate module. I'd assume that is doable, but seems
> orthogonal to this patch set. I'd also assume there was some reason
> that was not done already.

Ok, thanks for the explanation.  Wasn't clear at all from the file
paths in the source tree; it looked generic.

Dan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
@ 2017-04-07 20:09                 ` Dan Williams
  0 siblings, 0 replies; 51+ messages in thread
From: Dan Williams @ 2017-04-07 20:09 UTC (permalink / raw)
  To: Rob Herring
  Cc: Marcel Holtmann, open list:BLUETOOTH DRIVERS, linux-arm-kernel,
	Gustavo Padovan, Johan Hedberg, Mark Rutland, Wei Xu,
	Eyal Reizer, Satish Patel, netdev, devicetree

On Fri, 2017-04-07 at 13:48 -0500, Rob Herring wrote:
> On Fri, Apr 7, 2017 at 12:09 PM, Dan Williams <dcbw@redhat.com>
> wrote:
> > On Fri, 2017-04-07 at 09:35 -0500, Rob Herring wrote:
> > > Turns out that the LL protocol and the TI-ST are the same thing
> > > AFAICT.
> > > The TI-ST adds firmware loading, GPIO control, and shared access
> > > for
> > > NFC, FM radio, etc. For now, we're only implementing what is
> > > needed
> > > for
> > > BT. This mirrors other drivers like BCM and Intel, but uses the
> > > new
> > > serdev bus.
> > > 
> > > The firmware loading is greatly simplified by using existing
> > > infrastructure to send commands. It may be a bit slower than the
> > > original code using synchronous functions, but the real
> > > bottleneck is
> > > likely doing firmware load at 115.2kbps.
> > 
> > Is there no way to put the TI-specific stuff into a TI UART module
> > rather than building it into the generic one?
> 
> In case it's not clear, all of HCI_LL is the TI specific part, not
> just what I'm adding. So you are talking about putting each UART BT
> protocol into a separate module. I'd assume that is doable, but seems
> orthogonal to this patch set. I'd also assume there was some reason
> that was not done already.

Ok, thanks for the explanation.  Wasn't clear at all from the file
paths in the source tree; it looked generic.

Dan

^ permalink raw reply	[flat|nested] 51+ messages in thread
* [PATCH v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
@ 2017-04-07 20:09                 ` Dan Williams
  0 siblings, 0 replies; 51+ messages in thread
From: Dan Williams @ 2017-04-07 20:09 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, 2017-04-07 at 13:48 -0500, Rob Herring wrote:
> On Fri, Apr 7, 2017 at 12:09 PM, Dan Williams <dcbw@redhat.com>
> wrote:
> > On Fri, 2017-04-07 at 09:35 -0500, Rob Herring wrote:
> > > Turns out that the LL protocol and the TI-ST are the same thing
> > > AFAICT.
> > > The TI-ST adds firmware loading, GPIO control, and shared access
> > > for
> > > NFC, FM radio, etc. For now, we're only implementing what is
> > > needed
> > > for
> > > BT. This mirrors other drivers like BCM and Intel, but uses the
> > > new
> > > serdev bus.
> > > 
> > > The firmware loading is greatly simplified by using existing
> > > infrastructure to send commands. It may be a bit slower than the
> > > original code using synchronous functions, but the real
> > > bottleneck is
> > > likely doing firmware load at 115.2kbps.
> > 
> > Is there no way to put the TI-specific stuff into a TI UART module
> > rather than building it into the generic one?
> 
> In case it's not clear, all of HCI_LL is the TI specific part, not
> just what I'm adding. So you are talking about putting each UART BT
> protocol into a separate module. I'd assume that is doable, but seems
> orthogonal to this patch set. I'd also assume there was some reason
> that was not done already.

Ok, thanks for the explanation.  Wasn't clear at all from the file
paths in the source tree; it looked generic.

Dan

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
  2017-04-07 14:35         ` Rob Herring
@ 2017-04-12 20:20           ` Marcel Holtmann
  -1 siblings, 0 replies; 51+ messages in thread
From: Marcel Holtmann @ 2017-04-12 20:20 UTC (permalink / raw)
  To: Rob Herring
  Cc: linux-bluetooth, linux-arm-kernel, Gustavo F. Padovan,
	Johan Hedberg, Mark Rutland, Wei Xu, Eyal Reizer, Satish Patel,
	netdev, devicetree

Hi Rob,

> Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
> The TI-ST adds firmware loading, GPIO control, and shared access for
> NFC, FM radio, etc. For now, we're only implementing what is needed for
> BT. This mirrors other drivers like BCM and Intel, but uses the new
> serdev bus.
> 
> The firmware loading is greatly simplified by using existing
> infrastructure to send commands. It may be a bit slower than the
> original code using synchronous functions, but the real bottleneck is
> likely doing firmware load at 115.2kbps.
> 
> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Marcel Holtmann <marcel@holtmann.org>
> Cc: Gustavo Padovan <gustavo@padovan.org>
> Cc: Johan Hedberg <johan.hedberg@gmail.com>
> Cc: linux-bluetooth@vger.kernel.org
> ---
> v2:
> - Use IS_ENABLED() to fix module build
> 
> drivers/bluetooth/hci_ll.c | 261 ++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 260 insertions(+), 1 deletion(-)

can you re-send any missing patch on top of today's bluetooth-next tree.

Regards

Marcel

^ permalink raw reply	[flat|nested] 51+ messages in thread
* [PATCH v2 3/4] bluetooth: hci_uart: add LL protocol serdev driver support
@ 2017-04-12 20:20           ` Marcel Holtmann
  0 siblings, 0 replies; 51+ messages in thread
From: Marcel Holtmann @ 2017-04-12 20:20 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Rob,

> Turns out that the LL protocol and the TI-ST are the same thing AFAICT.
> The TI-ST adds firmware loading, GPIO control, and shared access for
> NFC, FM radio, etc. For now, we're only implementing what is needed for
> BT. This mirrors other drivers like BCM and Intel, but uses the new
> serdev bus.
> 
> The firmware loading is greatly simplified by using existing
> infrastructure to send commands. It may be a bit slower than the
> original code using synchronous functions, but the real bottleneck is
> likely doing firmware load at 115.2kbps.
> 
> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Marcel Holtmann <marcel@holtmann.org>
> Cc: Gustavo Padovan <gustavo@padovan.org>
> Cc: Johan Hedberg <johan.hedberg@gmail.com>
> Cc: linux-bluetooth at vger.kernel.org
> ---
> v2:
> - Use IS_ENABLED() to fix module build
> 
> drivers/bluetooth/hci_ll.c | 261 ++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 260 insertions(+), 1 deletion(-)

can you re-send any missing patch on top of today's bluetooth-next tree.

Regards

Marcel

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH 0/4] TI Bluetooth serdev support
  2017-04-05 18:30 ` Rob Herring
  (?)
@ 2017-04-30 15:14     ` Adam Ford
  -1 siblings, 0 replies; 51+ messages in thread
From: Adam Ford @ 2017-04-30 15:14 UTC (permalink / raw)
  To: Rob Herring
  Cc: Marcel Holtmann, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
	Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Johan Hedberg,
	Gustavo Padovan, Satish Patel, Wei Xu, Eyal Reizer,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> This series adds serdev support to the HCI LL protocol used on TI BT
> modules and enables support on HiKey board with with the WL1835 module.
> With this the custom TI UIM daemon and btattach are no longer needed.

Without UIM daemon, what instruction do you use to load the BT firmware?

I was thinking 'hciattach' but I was having trouble.  I was hoping you
might have some insight.

 hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
returns a timeout.

I modified my i.MX6 device tree per the binding documentation and
setup the regulators and enable GPIO pins.

adam
>
> The series is available on this git branch[1]. Patch 2 is just clean-up
> and can be applied independently. Patch 3 is dependent on the series
> "Nokia H4+ support". I'd suggest both series are merged thru the BT tree.
>
> Rob
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git ti-bluetooth
>
> Rob Herring (4):
>   dt-bindings: net: Add TI WiLink shared transport binding
>   bluetooth: hci_uart: remove unused hci_uart_init_tty
>   bluetooth: hci_uart: add LL protocol serdev driver support
>   arm64: dts: hikey: add WL1835 Bluetooth device node
>
>  .../devicetree/bindings/net/ti,wilink-st.txt       |  35 +++
>  arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts     |   5 +
>  drivers/bluetooth/hci_ldisc.c                      |  19 --
>  drivers/bluetooth/hci_ll.c                         | 261 ++++++++++++++++++++-
>  drivers/bluetooth/hci_uart.h                       |   1 -
>  5 files changed, 300 insertions(+), 21 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt
>
> --
> 2.10.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH 0/4] TI Bluetooth serdev support
@ 2017-04-30 15:14     ` Adam Ford
  0 siblings, 0 replies; 51+ messages in thread
From: Adam Ford @ 2017-04-30 15:14 UTC (permalink / raw)
  To: Rob Herring
  Cc: Marcel Holtmann, linux-bluetooth, Mark Rutland, devicetree,
	Johan Hedberg, Gustavo Padovan, Satish Patel, Wei Xu,
	Eyal Reizer, netdev, linux-arm-kernel

On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
> This series adds serdev support to the HCI LL protocol used on TI BT
> modules and enables support on HiKey board with with the WL1835 module.
> With this the custom TI UIM daemon and btattach are no longer needed.

Without UIM daemon, what instruction do you use to load the BT firmware?

I was thinking 'hciattach' but I was having trouble.  I was hoping you
might have some insight.

 hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
returns a timeout.

I modified my i.MX6 device tree per the binding documentation and
setup the regulators and enable GPIO pins.

adam
>
> The series is available on this git branch[1]. Patch 2 is just clean-up
> and can be applied independently. Patch 3 is dependent on the series
> "Nokia H4+ support". I'd suggest both series are merged thru the BT tree.
>
> Rob
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git ti-bluetooth
>
> Rob Herring (4):
>   dt-bindings: net: Add TI WiLink shared transport binding
>   bluetooth: hci_uart: remove unused hci_uart_init_tty
>   bluetooth: hci_uart: add LL protocol serdev driver support
>   arm64: dts: hikey: add WL1835 Bluetooth device node
>
>  .../devicetree/bindings/net/ti,wilink-st.txt       |  35 +++
>  arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts     |   5 +
>  drivers/bluetooth/hci_ldisc.c                      |  19 --
>  drivers/bluetooth/hci_ll.c                         | 261 ++++++++++++++++++++-
>  drivers/bluetooth/hci_uart.h                       |   1 -
>  5 files changed, 300 insertions(+), 21 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt
>
> --
> 2.10.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 51+ messages in thread
* [PATCH 0/4] TI Bluetooth serdev support
@ 2017-04-30 15:14     ` Adam Ford
  0 siblings, 0 replies; 51+ messages in thread
From: Adam Ford @ 2017-04-30 15:14 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
> This series adds serdev support to the HCI LL protocol used on TI BT
> modules and enables support on HiKey board with with the WL1835 module.
> With this the custom TI UIM daemon and btattach are no longer needed.

Without UIM daemon, what instruction do you use to load the BT firmware?

I was thinking 'hciattach' but I was having trouble.  I was hoping you
might have some insight.

 hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
returns a timeout.

I modified my i.MX6 device tree per the binding documentation and
setup the regulators and enable GPIO pins.

adam
>
> The series is available on this git branch[1]. Patch 2 is just clean-up
> and can be applied independently. Patch 3 is dependent on the series
> "Nokia H4+ support". I'd suggest both series are merged thru the BT tree.
>
> Rob
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git ti-bluetooth
>
> Rob Herring (4):
>   dt-bindings: net: Add TI WiLink shared transport binding
>   bluetooth: hci_uart: remove unused hci_uart_init_tty
>   bluetooth: hci_uart: add LL protocol serdev driver support
>   arm64: dts: hikey: add WL1835 Bluetooth device node
>
>  .../devicetree/bindings/net/ti,wilink-st.txt       |  35 +++
>  arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts     |   5 +
>  drivers/bluetooth/hci_ldisc.c                      |  19 --
>  drivers/bluetooth/hci_ll.c                         | 261 ++++++++++++++++++++-
>  drivers/bluetooth/hci_uart.h                       |   1 -
>  5 files changed, 300 insertions(+), 21 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/net/ti,wilink-st.txt
>
> --
> 2.10.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH 0/4] TI Bluetooth serdev support
  2017-04-30 15:14     ` Adam Ford
  (?)
@ 2017-04-30 16:04       ` Sebastian Reichel
  -1 siblings, 0 replies; 51+ messages in thread
From: Sebastian Reichel @ 2017-04-30 16:04 UTC (permalink / raw)
  To: Adam Ford
  Cc: Mark Rutland, Rob Herring, Johan Hedberg, devicetree,
	Gustavo Padovan, Marcel Holtmann, Wei Xu, linux-bluetooth,
	Eyal Reizer, netdev, Satish Patel, linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 1160 bytes --]

Hi,

On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
> > This series adds serdev support to the HCI LL protocol used on TI BT
> > modules and enables support on HiKey board with with the WL1835 module.
> > With this the custom TI UIM daemon and btattach are no longer needed.
> 
> Without UIM daemon, what instruction do you use to load the BT firmware?
> 
> I was thinking 'hciattach' but I was having trouble.  I was hoping you
> might have some insight.
> 
>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
> returns a timeout.
> 
> I modified my i.MX6 device tree per the binding documentation and
> setup the regulators and enable GPIO pins.

If you configured everything correctly no userspace interaction is
required. The driver should request the firmware automatically once
you power up the bluetooth device.

Apart from DT changes make sure, that the following options are
enabled and check dmesg for any hints.

CONFIG_SERIAL_DEV_BUS
CONFIG_SERIAL_DEV_CTRL_TTYPORT
CONFIG_BT_HCIUART
CONFIG_BT_HCIUART_LL

-- Sebastian

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH 0/4] TI Bluetooth serdev support
@ 2017-04-30 16:04       ` Sebastian Reichel
  0 siblings, 0 replies; 51+ messages in thread
From: Sebastian Reichel @ 2017-04-30 16:04 UTC (permalink / raw)
  To: Adam Ford
  Cc: Rob Herring, Marcel Holtmann, linux-bluetooth, Mark Rutland,
	devicetree, Johan Hedberg, Gustavo Padovan, Satish Patel, Wei Xu,
	Eyal Reizer, netdev, linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

Hi,

On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
> > This series adds serdev support to the HCI LL protocol used on TI BT
> > modules and enables support on HiKey board with with the WL1835 module.
> > With this the custom TI UIM daemon and btattach are no longer needed.
> 
> Without UIM daemon, what instruction do you use to load the BT firmware?
> 
> I was thinking 'hciattach' but I was having trouble.  I was hoping you
> might have some insight.
> 
>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
> returns a timeout.
> 
> I modified my i.MX6 device tree per the binding documentation and
> setup the regulators and enable GPIO pins.

If you configured everything correctly no userspace interaction is
required. The driver should request the firmware automatically once
you power up the bluetooth device.

Apart from DT changes make sure, that the following options are
enabled and check dmesg for any hints.

CONFIG_SERIAL_DEV_BUS
CONFIG_SERIAL_DEV_CTRL_TTYPORT
CONFIG_BT_HCIUART
CONFIG_BT_HCIUART_LL

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 51+ messages in thread
* [PATCH 0/4] TI Bluetooth serdev support
@ 2017-04-30 16:04       ` Sebastian Reichel
  0 siblings, 0 replies; 51+ messages in thread
From: Sebastian Reichel @ 2017-04-30 16:04 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
> > This series adds serdev support to the HCI LL protocol used on TI BT
> > modules and enables support on HiKey board with with the WL1835 module.
> > With this the custom TI UIM daemon and btattach are no longer needed.
> 
> Without UIM daemon, what instruction do you use to load the BT firmware?
> 
> I was thinking 'hciattach' but I was having trouble.  I was hoping you
> might have some insight.
> 
>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
> returns a timeout.
> 
> I modified my i.MX6 device tree per the binding documentation and
> setup the regulators and enable GPIO pins.

If you configured everything correctly no userspace interaction is
required. The driver should request the firmware automatically once
you power up the bluetooth device.

Apart from DT changes make sure, that the following options are
enabled and check dmesg for any hints.

CONFIG_SERIAL_DEV_BUS
CONFIG_SERIAL_DEV_CTRL_TTYPORT
CONFIG_BT_HCIUART
CONFIG_BT_HCIUART_LL

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170430/f8f82e8d/attachment.sig>

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH 0/4] TI Bluetooth serdev support
  2017-04-30 16:04       ` Sebastian Reichel
  (?)
@ 2017-05-05 14:51         ` Adam Ford
  -1 siblings, 0 replies; 51+ messages in thread
From: Adam Ford @ 2017-05-05 14:51 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Rob Herring, Marcel Holtmann,
	linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Johan Hedberg,
	Gustavo Padovan, Satish Patel, Wei Xu, Eyal Reizer,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Hi,
>
> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> > This series adds serdev support to the HCI LL protocol used on TI BT
>> > modules and enables support on HiKey board with with the WL1835 module.
>> > With this the custom TI UIM daemon and btattach are no longer needed.
>>
>> Without UIM daemon, what instruction do you use to load the BT firmware?
>>
>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
>> might have some insight.
>>
>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
>> returns a timeout.
>>
>> I modified my i.MX6 device tree per the binding documentation and
>> setup the regulators and enable GPIO pins.
>
> If you configured everything correctly no userspace interaction is
> required. The driver should request the firmware automatically once
> you power up the bluetooth device.
>
> Apart from DT changes make sure, that the following options are
> enabled and check dmesg for any hints.
>
> CONFIG_SERIAL_DEV_BUS
> CONFIG_SERIAL_DEV_CTRL_TTYPORT
> CONFIG_BT_HCIUART
> CONFIG_BT_HCIUART_LL
>


I have enabled those flags, and I have updated my device tree.
I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
getting a lot of timeout errors.  I tested this against the original
implemention I had in pdata-quirks.c using the ti-st driver, uim & and
the btwilink driver.

I pulled in some of the newer patches to enable the wl1283-st, but I
am obviously missing something.

I   58.717651] Bluetooth: hci0: Reading TI version information failed
(-110)
[   58.724853] Bluetooth: hci0: download firmware failed, retrying...
[   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
[   68.957641] Bluetooth: hci0: Reading TI version information failed
(-110)
[   68.964843] Bluetooth: hci0: download firmware failed, retrying...
[   69.132171] Bluetooth: Unknown HCI packet type 06
[   69.138244] Bluetooth: Unknown HCI packet type 0c
[   69.143249] Bluetooth: Unknown HCI packet type 40
[   69.148498] Bluetooth: Unknown HCI packet type 20
[   69.153533] Bluetooth: Data length is too large
[   69.158569] Bluetooth: Unknown HCI packet type a0
[   69.163574] Bluetooth: Unknown HCI packet type 00
[   69.168731] Bluetooth: Unknown HCI packet type 00
[   69.173736] Bluetooth: Unknown HCI packet type 34
[   69.178924] Bluetooth: Unknown HCI packet type 91
[   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
[   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)

Since the pdata-quirks and original ti-st drivers work together, I
know the hardware is fine.  The only change to the device tree is the
addition of the Bluetooth container:

bluetooth {
  compatible = "ti,wl1283-st";
  enable-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;
};

Any thoughts or suggestions to try?  I get similar behavior on an
i.MX6 board with a wl1837-st module as well.

adam
> -- Sebastian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH 0/4] TI Bluetooth serdev support
@ 2017-05-05 14:51         ` Adam Ford
  0 siblings, 0 replies; 51+ messages in thread
From: Adam Ford @ 2017-05-05 14:51 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Rob Herring, Marcel Holtmann, linux-bluetooth, Mark Rutland,
	devicetree, Johan Hedberg, Gustavo Padovan, Satish Patel, Wei Xu,
	Eyal Reizer, netdev, linux-arm-kernel

On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@kernel.org> wrote:
> Hi,
>
> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
>> > This series adds serdev support to the HCI LL protocol used on TI BT
>> > modules and enables support on HiKey board with with the WL1835 module.
>> > With this the custom TI UIM daemon and btattach are no longer needed.
>>
>> Without UIM daemon, what instruction do you use to load the BT firmware?
>>
>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
>> might have some insight.
>>
>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
>> returns a timeout.
>>
>> I modified my i.MX6 device tree per the binding documentation and
>> setup the regulators and enable GPIO pins.
>
> If you configured everything correctly no userspace interaction is
> required. The driver should request the firmware automatically once
> you power up the bluetooth device.
>
> Apart from DT changes make sure, that the following options are
> enabled and check dmesg for any hints.
>
> CONFIG_SERIAL_DEV_BUS
> CONFIG_SERIAL_DEV_CTRL_TTYPORT
> CONFIG_BT_HCIUART
> CONFIG_BT_HCIUART_LL
>


I have enabled those flags, and I have updated my device tree.
I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
getting a lot of timeout errors.  I tested this against the original
implemention I had in pdata-quirks.c using the ti-st driver, uim & and
the btwilink driver.

I pulled in some of the newer patches to enable the wl1283-st, but I
am obviously missing something.

I   58.717651] Bluetooth: hci0: Reading TI version information failed
(-110)
[   58.724853] Bluetooth: hci0: download firmware failed, retrying...
[   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
[   68.957641] Bluetooth: hci0: Reading TI version information failed
(-110)
[   68.964843] Bluetooth: hci0: download firmware failed, retrying...
[   69.132171] Bluetooth: Unknown HCI packet type 06
[   69.138244] Bluetooth: Unknown HCI packet type 0c
[   69.143249] Bluetooth: Unknown HCI packet type 40
[   69.148498] Bluetooth: Unknown HCI packet type 20
[   69.153533] Bluetooth: Data length is too large
[   69.158569] Bluetooth: Unknown HCI packet type a0
[   69.163574] Bluetooth: Unknown HCI packet type 00
[   69.168731] Bluetooth: Unknown HCI packet type 00
[   69.173736] Bluetooth: Unknown HCI packet type 34
[   69.178924] Bluetooth: Unknown HCI packet type 91
[   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
[   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)

Since the pdata-quirks and original ti-st drivers work together, I
know the hardware is fine.  The only change to the device tree is the
addition of the Bluetooth container:

bluetooth {
  compatible = "ti,wl1283-st";
  enable-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;
};

Any thoughts or suggestions to try?  I get similar behavior on an
i.MX6 board with a wl1837-st module as well.

adam
> -- Sebastian

^ permalink raw reply	[flat|nested] 51+ messages in thread
* [PATCH 0/4] TI Bluetooth serdev support
@ 2017-05-05 14:51         ` Adam Ford
  0 siblings, 0 replies; 51+ messages in thread
From: Adam Ford @ 2017-05-05 14:51 UTC (permalink / raw)
  To: linux-arm-kernel

On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@kernel.org> wrote:
> Hi,
>
> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
>> > This series adds serdev support to the HCI LL protocol used on TI BT
>> > modules and enables support on HiKey board with with the WL1835 module.
>> > With this the custom TI UIM daemon and btattach are no longer needed.
>>
>> Without UIM daemon, what instruction do you use to load the BT firmware?
>>
>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
>> might have some insight.
>>
>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
>> returns a timeout.
>>
>> I modified my i.MX6 device tree per the binding documentation and
>> setup the regulators and enable GPIO pins.
>
> If you configured everything correctly no userspace interaction is
> required. The driver should request the firmware automatically once
> you power up the bluetooth device.
>
> Apart from DT changes make sure, that the following options are
> enabled and check dmesg for any hints.
>
> CONFIG_SERIAL_DEV_BUS
> CONFIG_SERIAL_DEV_CTRL_TTYPORT
> CONFIG_BT_HCIUART
> CONFIG_BT_HCIUART_LL
>


I have enabled those flags, and I have updated my device tree.
I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
getting a lot of timeout errors.  I tested this against the original
implemention I had in pdata-quirks.c using the ti-st driver, uim & and
the btwilink driver.

I pulled in some of the newer patches to enable the wl1283-st, but I
am obviously missing something.

I   58.717651] Bluetooth: hci0: Reading TI version information failed
(-110)
[   58.724853] Bluetooth: hci0: download firmware failed, retrying...
[   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
[   68.957641] Bluetooth: hci0: Reading TI version information failed
(-110)
[   68.964843] Bluetooth: hci0: download firmware failed, retrying...
[   69.132171] Bluetooth: Unknown HCI packet type 06
[   69.138244] Bluetooth: Unknown HCI packet type 0c
[   69.143249] Bluetooth: Unknown HCI packet type 40
[   69.148498] Bluetooth: Unknown HCI packet type 20
[   69.153533] Bluetooth: Data length is too large
[   69.158569] Bluetooth: Unknown HCI packet type a0
[   69.163574] Bluetooth: Unknown HCI packet type 00
[   69.168731] Bluetooth: Unknown HCI packet type 00
[   69.173736] Bluetooth: Unknown HCI packet type 34
[   69.178924] Bluetooth: Unknown HCI packet type 91
[   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
[   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)

Since the pdata-quirks and original ti-st drivers work together, I
know the hardware is fine.  The only change to the device tree is the
addition of the Bluetooth container:

bluetooth {
  compatible = "ti,wl1283-st";
  enable-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;
};

Any thoughts or suggestions to try?  I get similar behavior on an
i.MX6 board with a wl1837-st module as well.

adam
> -- Sebastian

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH 0/4] TI Bluetooth serdev support
  2017-05-05 14:51         ` Adam Ford
@ 2017-05-08 19:07           ` Sebastian Reichel
  -1 siblings, 0 replies; 51+ messages in thread
From: Sebastian Reichel @ 2017-05-08 19:07 UTC (permalink / raw)
  To: Adam Ford
  Cc: Rob Herring, Marcel Holtmann, linux-bluetooth, Mark Rutland,
	devicetree, Johan Hedberg, Gustavo Padovan, Satish Patel, Wei Xu,
	Eyal Reizer, netdev, linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 3458 bytes --]

Hi,

On Fri, May 05, 2017 at 09:51:33AM -0500, Adam Ford wrote:
> On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@kernel.org> wrote:
> > On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
> >> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
> >> > This series adds serdev support to the HCI LL protocol used on TI BT
> >> > modules and enables support on HiKey board with with the WL1835 module.
> >> > With this the custom TI UIM daemon and btattach are no longer needed.
> >>
> >> Without UIM daemon, what instruction do you use to load the BT firmware?
> >>
> >> I was thinking 'hciattach' but I was having trouble.  I was hoping you
> >> might have some insight.
> >>
> >>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
> >> returns a timeout.
> >>
> >> I modified my i.MX6 device tree per the binding documentation and
> >> setup the regulators and enable GPIO pins.
> >
> > If you configured everything correctly no userspace interaction is
> > required. The driver should request the firmware automatically once
> > you power up the bluetooth device.
> >
> > Apart from DT changes make sure, that the following options are
> > enabled and check dmesg for any hints.
> >
> > CONFIG_SERIAL_DEV_BUS
> > CONFIG_SERIAL_DEV_CTRL_TTYPORT
> > CONFIG_BT_HCIUART
> > CONFIG_BT_HCIUART_LL
> 
> I have enabled those flags, and I have updated my device tree.
> I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
> getting a lot of timeout errors.  I tested this against the original
> implemention I had in pdata-quirks.c using the ti-st driver, uim & and
> the btwilink driver.
> 
> I pulled in some of the newer patches to enable the wl1283-st, but I
> am obviously missing something.
> 
> I   58.717651] Bluetooth: hci0: Reading TI version information failed
> (-110)
> [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
> [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
> [   68.957641] Bluetooth: hci0: Reading TI version information failed
> (-110)
> [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
> [   69.132171] Bluetooth: Unknown HCI packet type 06
> [   69.138244] Bluetooth: Unknown HCI packet type 0c
> [   69.143249] Bluetooth: Unknown HCI packet type 40
> [   69.148498] Bluetooth: Unknown HCI packet type 20
> [   69.153533] Bluetooth: Data length is too large
> [   69.158569] Bluetooth: Unknown HCI packet type a0
> [   69.163574] Bluetooth: Unknown HCI packet type 00
> [   69.168731] Bluetooth: Unknown HCI packet type 00
> [   69.173736] Bluetooth: Unknown HCI packet type 34
> [   69.178924] Bluetooth: Unknown HCI packet type 91
> [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
> [   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)
>
> Since the pdata-quirks and original ti-st drivers work together, I
> know the hardware is fine.  The only change to the device tree is the
> addition of the Bluetooth container:
> 
> bluetooth {
>   compatible = "ti,wl1283-st";
>   enable-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;
> };
> 
> Any thoughts or suggestions to try? I get similar behavior on an
> i.MX6 board with a wl1837-st module as well.

Looks like its loosing bytes. I suggest to have a look at
pinmuxing (esp. for cts & rts) and maybe add some debug
prints to see where it starts failing.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 51+ messages in thread
* [PATCH 0/4] TI Bluetooth serdev support
@ 2017-05-08 19:07           ` Sebastian Reichel
  0 siblings, 0 replies; 51+ messages in thread
From: Sebastian Reichel @ 2017-05-08 19:07 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Fri, May 05, 2017 at 09:51:33AM -0500, Adam Ford wrote:
> On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@kernel.org> wrote:
> > On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
> >> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
> >> > This series adds serdev support to the HCI LL protocol used on TI BT
> >> > modules and enables support on HiKey board with with the WL1835 module.
> >> > With this the custom TI UIM daemon and btattach are no longer needed.
> >>
> >> Without UIM daemon, what instruction do you use to load the BT firmware?
> >>
> >> I was thinking 'hciattach' but I was having trouble.  I was hoping you
> >> might have some insight.
> >>
> >>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
> >> returns a timeout.
> >>
> >> I modified my i.MX6 device tree per the binding documentation and
> >> setup the regulators and enable GPIO pins.
> >
> > If you configured everything correctly no userspace interaction is
> > required. The driver should request the firmware automatically once
> > you power up the bluetooth device.
> >
> > Apart from DT changes make sure, that the following options are
> > enabled and check dmesg for any hints.
> >
> > CONFIG_SERIAL_DEV_BUS
> > CONFIG_SERIAL_DEV_CTRL_TTYPORT
> > CONFIG_BT_HCIUART
> > CONFIG_BT_HCIUART_LL
> 
> I have enabled those flags, and I have updated my device tree.
> I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
> getting a lot of timeout errors.  I tested this against the original
> implemention I had in pdata-quirks.c using the ti-st driver, uim & and
> the btwilink driver.
> 
> I pulled in some of the newer patches to enable the wl1283-st, but I
> am obviously missing something.
> 
> I   58.717651] Bluetooth: hci0: Reading TI version information failed
> (-110)
> [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
> [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
> [   68.957641] Bluetooth: hci0: Reading TI version information failed
> (-110)
> [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
> [   69.132171] Bluetooth: Unknown HCI packet type 06
> [   69.138244] Bluetooth: Unknown HCI packet type 0c
> [   69.143249] Bluetooth: Unknown HCI packet type 40
> [   69.148498] Bluetooth: Unknown HCI packet type 20
> [   69.153533] Bluetooth: Data length is too large
> [   69.158569] Bluetooth: Unknown HCI packet type a0
> [   69.163574] Bluetooth: Unknown HCI packet type 00
> [   69.168731] Bluetooth: Unknown HCI packet type 00
> [   69.173736] Bluetooth: Unknown HCI packet type 34
> [   69.178924] Bluetooth: Unknown HCI packet type 91
> [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
> [   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)
>
> Since the pdata-quirks and original ti-st drivers work together, I
> know the hardware is fine.  The only change to the device tree is the
> addition of the Bluetooth container:
> 
> bluetooth {
>   compatible = "ti,wl1283-st";
>   enable-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;
> };
> 
> Any thoughts or suggestions to try? I get similar behavior on an
> i.MX6 board with a wl1837-st module as well.

Looks like its loosing bytes. I suggest to have a look at
pinmuxing (esp. for cts & rts) and maybe add some debug
prints to see where it starts failing.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170508/cadc0608/attachment.sig>

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH 0/4] TI Bluetooth serdev support
  2017-05-05 14:51         ` Adam Ford
  (?)
@ 2017-05-08 21:12             ` Rob Herring
  -1 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-05-08 21:12 UTC (permalink / raw)
  To: Adam Ford
  Cc: Sebastian Reichel, Marcel Holtmann, open list:BLUETOOTH DRIVERS,
	Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Johan Hedberg,
	Gustavo Padovan, Satish Patel, Wei Xu, Eyal Reizer, netdev,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Fri, May 5, 2017 at 9:51 AM, Adam Ford <aford173-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> Hi,
>>
>> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>> > This series adds serdev support to the HCI LL protocol used on TI BT
>>> > modules and enables support on HiKey board with with the WL1835 module.
>>> > With this the custom TI UIM daemon and btattach are no longer needed.
>>>
>>> Without UIM daemon, what instruction do you use to load the BT firmware?
>>>
>>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
>>> might have some insight.
>>>
>>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
>>> returns a timeout.
>>>
>>> I modified my i.MX6 device tree per the binding documentation and
>>> setup the regulators and enable GPIO pins.
>>
>> If you configured everything correctly no userspace interaction is
>> required. The driver should request the firmware automatically once
>> you power up the bluetooth device.
>>
>> Apart from DT changes make sure, that the following options are
>> enabled and check dmesg for any hints.
>>
>> CONFIG_SERIAL_DEV_BUS
>> CONFIG_SERIAL_DEV_CTRL_TTYPORT
>> CONFIG_BT_HCIUART
>> CONFIG_BT_HCIUART_LL
>>
>
>
> I have enabled those flags, and I have updated my device tree.
> I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
> getting a lot of timeout errors.  I tested this against the original
> implemention I had in pdata-quirks.c using the ti-st driver, uim & and
> the btwilink driver.
>
> I pulled in some of the newer patches to enable the wl1283-st, but I
> am obviously missing something.
>
> I   58.717651] Bluetooth: hci0: Reading TI version information failed
> (-110)
> [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
> [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
> [   68.957641] Bluetooth: hci0: Reading TI version information failed
> (-110)
> [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
> [   69.132171] Bluetooth: Unknown HCI packet type 06
> [   69.138244] Bluetooth: Unknown HCI packet type 0c
> [   69.143249] Bluetooth: Unknown HCI packet type 40
> [   69.148498] Bluetooth: Unknown HCI packet type 20
> [   69.153533] Bluetooth: Data length is too large
> [   69.158569] Bluetooth: Unknown HCI packet type a0
> [   69.163574] Bluetooth: Unknown HCI packet type 00
> [   69.168731] Bluetooth: Unknown HCI packet type 00
> [   69.173736] Bluetooth: Unknown HCI packet type 34
> [   69.178924] Bluetooth: Unknown HCI packet type 91
> [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
> [   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)

There's a bug in serdev_device_write(), so if you have that function
you need either the fix I sent or the patch to make
serdev_device_writebuf atomic again. Both are on the linux-serial
list, but not in any tree yet.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH 0/4] TI Bluetooth serdev support
@ 2017-05-08 21:12             ` Rob Herring
  0 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-05-08 21:12 UTC (permalink / raw)
  To: Adam Ford
  Cc: Sebastian Reichel, Marcel Holtmann, open list:BLUETOOTH DRIVERS,
	Mark Rutland, devicetree, Johan Hedberg, Gustavo Padovan,
	Satish Patel, Wei Xu, Eyal Reizer, netdev, linux-arm-kernel

On Fri, May 5, 2017 at 9:51 AM, Adam Ford <aford173@gmail.com> wrote:
> On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@kernel.org> wrote:
>> Hi,
>>
>> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
>>> > This series adds serdev support to the HCI LL protocol used on TI BT
>>> > modules and enables support on HiKey board with with the WL1835 module.
>>> > With this the custom TI UIM daemon and btattach are no longer needed.
>>>
>>> Without UIM daemon, what instruction do you use to load the BT firmware?
>>>
>>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
>>> might have some insight.
>>>
>>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
>>> returns a timeout.
>>>
>>> I modified my i.MX6 device tree per the binding documentation and
>>> setup the regulators and enable GPIO pins.
>>
>> If you configured everything correctly no userspace interaction is
>> required. The driver should request the firmware automatically once
>> you power up the bluetooth device.
>>
>> Apart from DT changes make sure, that the following options are
>> enabled and check dmesg for any hints.
>>
>> CONFIG_SERIAL_DEV_BUS
>> CONFIG_SERIAL_DEV_CTRL_TTYPORT
>> CONFIG_BT_HCIUART
>> CONFIG_BT_HCIUART_LL
>>
>
>
> I have enabled those flags, and I have updated my device tree.
> I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
> getting a lot of timeout errors.  I tested this against the original
> implemention I had in pdata-quirks.c using the ti-st driver, uim & and
> the btwilink driver.
>
> I pulled in some of the newer patches to enable the wl1283-st, but I
> am obviously missing something.
>
> I   58.717651] Bluetooth: hci0: Reading TI version information failed
> (-110)
> [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
> [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
> [   68.957641] Bluetooth: hci0: Reading TI version information failed
> (-110)
> [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
> [   69.132171] Bluetooth: Unknown HCI packet type 06
> [   69.138244] Bluetooth: Unknown HCI packet type 0c
> [   69.143249] Bluetooth: Unknown HCI packet type 40
> [   69.148498] Bluetooth: Unknown HCI packet type 20
> [   69.153533] Bluetooth: Data length is too large
> [   69.158569] Bluetooth: Unknown HCI packet type a0
> [   69.163574] Bluetooth: Unknown HCI packet type 00
> [   69.168731] Bluetooth: Unknown HCI packet type 00
> [   69.173736] Bluetooth: Unknown HCI packet type 34
> [   69.178924] Bluetooth: Unknown HCI packet type 91
> [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
> [   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)

There's a bug in serdev_device_write(), so if you have that function
you need either the fix I sent or the patch to make
serdev_device_writebuf atomic again. Both are on the linux-serial
list, but not in any tree yet.

Rob

^ permalink raw reply	[flat|nested] 51+ messages in thread
* [PATCH 0/4] TI Bluetooth serdev support
@ 2017-05-08 21:12             ` Rob Herring
  0 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-05-08 21:12 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, May 5, 2017 at 9:51 AM, Adam Ford <aford173@gmail.com> wrote:
> On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@kernel.org> wrote:
>> Hi,
>>
>> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
>>> > This series adds serdev support to the HCI LL protocol used on TI BT
>>> > modules and enables support on HiKey board with with the WL1835 module.
>>> > With this the custom TI UIM daemon and btattach are no longer needed.
>>>
>>> Without UIM daemon, what instruction do you use to load the BT firmware?
>>>
>>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
>>> might have some insight.
>>>
>>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
>>> returns a timeout.
>>>
>>> I modified my i.MX6 device tree per the binding documentation and
>>> setup the regulators and enable GPIO pins.
>>
>> If you configured everything correctly no userspace interaction is
>> required. The driver should request the firmware automatically once
>> you power up the bluetooth device.
>>
>> Apart from DT changes make sure, that the following options are
>> enabled and check dmesg for any hints.
>>
>> CONFIG_SERIAL_DEV_BUS
>> CONFIG_SERIAL_DEV_CTRL_TTYPORT
>> CONFIG_BT_HCIUART
>> CONFIG_BT_HCIUART_LL
>>
>
>
> I have enabled those flags, and I have updated my device tree.
> I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
> getting a lot of timeout errors.  I tested this against the original
> implemention I had in pdata-quirks.c using the ti-st driver, uim & and
> the btwilink driver.
>
> I pulled in some of the newer patches to enable the wl1283-st, but I
> am obviously missing something.
>
> I   58.717651] Bluetooth: hci0: Reading TI version information failed
> (-110)
> [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
> [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
> [   68.957641] Bluetooth: hci0: Reading TI version information failed
> (-110)
> [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
> [   69.132171] Bluetooth: Unknown HCI packet type 06
> [   69.138244] Bluetooth: Unknown HCI packet type 0c
> [   69.143249] Bluetooth: Unknown HCI packet type 40
> [   69.148498] Bluetooth: Unknown HCI packet type 20
> [   69.153533] Bluetooth: Data length is too large
> [   69.158569] Bluetooth: Unknown HCI packet type a0
> [   69.163574] Bluetooth: Unknown HCI packet type 00
> [   69.168731] Bluetooth: Unknown HCI packet type 00
> [   69.173736] Bluetooth: Unknown HCI packet type 34
> [   69.178924] Bluetooth: Unknown HCI packet type 91
> [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
> [   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)

There's a bug in serdev_device_write(), so if you have that function
you need either the fix I sent or the patch to make
serdev_device_writebuf atomic again. Both are on the linux-serial
list, but not in any tree yet.

Rob

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH 0/4] TI Bluetooth serdev support
  2017-05-08 21:12             ` Rob Herring
  (?)
@ 2017-05-09  4:48                 ` Baruch Siach
  -1 siblings, 0 replies; 51+ messages in thread
From: Baruch Siach @ 2017-05-09  4:48 UTC (permalink / raw)
  To: Rob Herring
  Cc: Adam Ford, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
	Johan Hedberg, Gustavo Padovan, Marcel Holtmann,
	Sebastian Reichel, Wei Xu, open list:BLUETOOTH DRIVERS,
	Eyal Reizer, netdev, Satish Patel,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

Hi Rob,

On Mon, May 08, 2017 at 04:12:16PM -0500, Rob Herring wrote:
> On Fri, May 5, 2017 at 9:51 AM, Adam Ford <aford173-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> >> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
> >>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> >>> > This series adds serdev support to the HCI LL protocol used on TI BT
> >>> > modules and enables support on HiKey board with with the WL1835 module.
> >>> > With this the custom TI UIM daemon and btattach are no longer needed.
> >>>
> >>> Without UIM daemon, what instruction do you use to load the BT firmware?
> >>>
> >>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
> >>> might have some insight.
> >>>
> >>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
> >>> returns a timeout.
> >>>
> >>> I modified my i.MX6 device tree per the binding documentation and
> >>> setup the regulators and enable GPIO pins.
> >>
> >> If you configured everything correctly no userspace interaction is
> >> required. The driver should request the firmware automatically once
> >> you power up the bluetooth device.
> >>
> >> Apart from DT changes make sure, that the following options are
> >> enabled and check dmesg for any hints.
> >>
> >> CONFIG_SERIAL_DEV_BUS
> >> CONFIG_SERIAL_DEV_CTRL_TTYPORT
> >> CONFIG_BT_HCIUART
> >> CONFIG_BT_HCIUART_LL
> >
> > I have enabled those flags, and I have updated my device tree.
> > I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
> > getting a lot of timeout errors.  I tested this against the original
> > implemention I had in pdata-quirks.c using the ti-st driver, uim & and
> > the btwilink driver.
> >
> > I pulled in some of the newer patches to enable the wl1283-st, but I
> > am obviously missing something.
> >
> > I   58.717651] Bluetooth: hci0: Reading TI version information failed
> > (-110)
> > [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
> > [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
> > [   68.957641] Bluetooth: hci0: Reading TI version information failed
> > (-110)
> > [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
> > [   69.132171] Bluetooth: Unknown HCI packet type 06
> > [   69.138244] Bluetooth: Unknown HCI packet type 0c
> > [   69.143249] Bluetooth: Unknown HCI packet type 40
> > [   69.148498] Bluetooth: Unknown HCI packet type 20
> > [   69.153533] Bluetooth: Data length is too large
> > [   69.158569] Bluetooth: Unknown HCI packet type a0
> > [   69.163574] Bluetooth: Unknown HCI packet type 00
> > [   69.168731] Bluetooth: Unknown HCI packet type 00
> > [   69.173736] Bluetooth: Unknown HCI packet type 34
> > [   69.178924] Bluetooth: Unknown HCI packet type 91
> > [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
> > [   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)
> 
> There's a bug in serdev_device_write(), so if you have that function
> you need either the fix I sent or the patch to make
> serdev_device_writebuf atomic again. Both are on the linux-serial
> list, but not in any tree yet.

You refer to the patches below, right?

  [PATCH] tty: serdev: fix serdev_device_write return value, 
  http://www.spinics.net/lists/linux-serial/msg26117.html

  [PATCH] serdev: Restore serdev_device_write_buf for atomic context,
  http://www.spinics.net/lists/linux-serial/msg26113.html

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH 0/4] TI Bluetooth serdev support
@ 2017-05-09  4:48                 ` Baruch Siach
  0 siblings, 0 replies; 51+ messages in thread
From: Baruch Siach @ 2017-05-09  4:48 UTC (permalink / raw)
  To: Rob Herring
  Cc: Adam Ford, Mark Rutland, devicetree, Johan Hedberg,
	Gustavo Padovan, Marcel Holtmann, Sebastian Reichel, Wei Xu,
	open list:BLUETOOTH DRIVERS, Eyal Reizer, netdev, Satish Patel,
	linux-arm-kernel

Hi Rob,

On Mon, May 08, 2017 at 04:12:16PM -0500, Rob Herring wrote:
> On Fri, May 5, 2017 at 9:51 AM, Adam Ford <aford173@gmail.com> wrote:
> > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@kernel.org> wrote:
> >> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
> >>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
> >>> > This series adds serdev support to the HCI LL protocol used on TI BT
> >>> > modules and enables support on HiKey board with with the WL1835 module.
> >>> > With this the custom TI UIM daemon and btattach are no longer needed.
> >>>
> >>> Without UIM daemon, what instruction do you use to load the BT firmware?
> >>>
> >>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
> >>> might have some insight.
> >>>
> >>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
> >>> returns a timeout.
> >>>
> >>> I modified my i.MX6 device tree per the binding documentation and
> >>> setup the regulators and enable GPIO pins.
> >>
> >> If you configured everything correctly no userspace interaction is
> >> required. The driver should request the firmware automatically once
> >> you power up the bluetooth device.
> >>
> >> Apart from DT changes make sure, that the following options are
> >> enabled and check dmesg for any hints.
> >>
> >> CONFIG_SERIAL_DEV_BUS
> >> CONFIG_SERIAL_DEV_CTRL_TTYPORT
> >> CONFIG_BT_HCIUART
> >> CONFIG_BT_HCIUART_LL
> >
> > I have enabled those flags, and I have updated my device tree.
> > I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
> > getting a lot of timeout errors.  I tested this against the original
> > implemention I had in pdata-quirks.c using the ti-st driver, uim & and
> > the btwilink driver.
> >
> > I pulled in some of the newer patches to enable the wl1283-st, but I
> > am obviously missing something.
> >
> > I   58.717651] Bluetooth: hci0: Reading TI version information failed
> > (-110)
> > [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
> > [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
> > [   68.957641] Bluetooth: hci0: Reading TI version information failed
> > (-110)
> > [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
> > [   69.132171] Bluetooth: Unknown HCI packet type 06
> > [   69.138244] Bluetooth: Unknown HCI packet type 0c
> > [   69.143249] Bluetooth: Unknown HCI packet type 40
> > [   69.148498] Bluetooth: Unknown HCI packet type 20
> > [   69.153533] Bluetooth: Data length is too large
> > [   69.158569] Bluetooth: Unknown HCI packet type a0
> > [   69.163574] Bluetooth: Unknown HCI packet type 00
> > [   69.168731] Bluetooth: Unknown HCI packet type 00
> > [   69.173736] Bluetooth: Unknown HCI packet type 34
> > [   69.178924] Bluetooth: Unknown HCI packet type 91
> > [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
> > [   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)
> 
> There's a bug in serdev_device_write(), so if you have that function
> you need either the fix I sent or the patch to make
> serdev_device_writebuf atomic again. Both are on the linux-serial
> list, but not in any tree yet.

You refer to the patches below, right?

  [PATCH] tty: serdev: fix serdev_device_write return value, 
  http://www.spinics.net/lists/linux-serial/msg26117.html

  [PATCH] serdev: Restore serdev_device_write_buf for atomic context,
  http://www.spinics.net/lists/linux-serial/msg26113.html

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

^ permalink raw reply	[flat|nested] 51+ messages in thread
* [PATCH 0/4] TI Bluetooth serdev support
@ 2017-05-09  4:48                 ` Baruch Siach
  0 siblings, 0 replies; 51+ messages in thread
From: Baruch Siach @ 2017-05-09  4:48 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Rob,

On Mon, May 08, 2017 at 04:12:16PM -0500, Rob Herring wrote:
> On Fri, May 5, 2017 at 9:51 AM, Adam Ford <aford173@gmail.com> wrote:
> > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@kernel.org> wrote:
> >> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
> >>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
> >>> > This series adds serdev support to the HCI LL protocol used on TI BT
> >>> > modules and enables support on HiKey board with with the WL1835 module.
> >>> > With this the custom TI UIM daemon and btattach are no longer needed.
> >>>
> >>> Without UIM daemon, what instruction do you use to load the BT firmware?
> >>>
> >>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
> >>> might have some insight.
> >>>
> >>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
> >>> returns a timeout.
> >>>
> >>> I modified my i.MX6 device tree per the binding documentation and
> >>> setup the regulators and enable GPIO pins.
> >>
> >> If you configured everything correctly no userspace interaction is
> >> required. The driver should request the firmware automatically once
> >> you power up the bluetooth device.
> >>
> >> Apart from DT changes make sure, that the following options are
> >> enabled and check dmesg for any hints.
> >>
> >> CONFIG_SERIAL_DEV_BUS
> >> CONFIG_SERIAL_DEV_CTRL_TTYPORT
> >> CONFIG_BT_HCIUART
> >> CONFIG_BT_HCIUART_LL
> >
> > I have enabled those flags, and I have updated my device tree.
> > I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
> > getting a lot of timeout errors.  I tested this against the original
> > implemention I had in pdata-quirks.c using the ti-st driver, uim & and
> > the btwilink driver.
> >
> > I pulled in some of the newer patches to enable the wl1283-st, but I
> > am obviously missing something.
> >
> > I   58.717651] Bluetooth: hci0: Reading TI version information failed
> > (-110)
> > [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
> > [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
> > [   68.957641] Bluetooth: hci0: Reading TI version information failed
> > (-110)
> > [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
> > [   69.132171] Bluetooth: Unknown HCI packet type 06
> > [   69.138244] Bluetooth: Unknown HCI packet type 0c
> > [   69.143249] Bluetooth: Unknown HCI packet type 40
> > [   69.148498] Bluetooth: Unknown HCI packet type 20
> > [   69.153533] Bluetooth: Data length is too large
> > [   69.158569] Bluetooth: Unknown HCI packet type a0
> > [   69.163574] Bluetooth: Unknown HCI packet type 00
> > [   69.168731] Bluetooth: Unknown HCI packet type 00
> > [   69.173736] Bluetooth: Unknown HCI packet type 34
> > [   69.178924] Bluetooth: Unknown HCI packet type 91
> > [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
> > [   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)
> 
> There's a bug in serdev_device_write(), so if you have that function
> you need either the fix I sent or the patch to make
> serdev_device_writebuf atomic again. Both are on the linux-serial
> list, but not in any tree yet.

You refer to the patches below, right?

  [PATCH] tty: serdev: fix serdev_device_write return value, 
  http://www.spinics.net/lists/linux-serial/msg26117.html

  [PATCH] serdev: Restore serdev_device_write_buf for atomic context,
  http://www.spinics.net/lists/linux-serial/msg26113.html

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH 0/4] TI Bluetooth serdev support
  2017-05-09  4:48                 ` Baruch Siach
  (?)
@ 2017-05-09 14:14                     ` Rob Herring
  -1 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-05-09 14:14 UTC (permalink / raw)
  To: Baruch Siach
  Cc: Adam Ford, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
	Johan Hedberg, Gustavo Padovan, Marcel Holtmann,
	Sebastian Reichel, Wei Xu, open list:BLUETOOTH DRIVERS,
	Eyal Reizer, netdev, Satish Patel,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Mon, May 8, 2017 at 11:48 PM, Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
> Hi Rob,
>
> On Mon, May 08, 2017 at 04:12:16PM -0500, Rob Herring wrote:
>> On Fri, May 5, 2017 at 9:51 AM, Adam Ford <aford173-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> >> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>> >>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> >>> > This series adds serdev support to the HCI LL protocol used on TI BT
>> >>> > modules and enables support on HiKey board with with the WL1835 module.
>> >>> > With this the custom TI UIM daemon and btattach are no longer needed.
>> >>>
>> >>> Without UIM daemon, what instruction do you use to load the BT firmware?
>> >>>
>> >>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
>> >>> might have some insight.
>> >>>
>> >>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
>> >>> returns a timeout.
>> >>>
>> >>> I modified my i.MX6 device tree per the binding documentation and
>> >>> setup the regulators and enable GPIO pins.
>> >>
>> >> If you configured everything correctly no userspace interaction is
>> >> required. The driver should request the firmware automatically once
>> >> you power up the bluetooth device.
>> >>
>> >> Apart from DT changes make sure, that the following options are
>> >> enabled and check dmesg for any hints.
>> >>
>> >> CONFIG_SERIAL_DEV_BUS
>> >> CONFIG_SERIAL_DEV_CTRL_TTYPORT
>> >> CONFIG_BT_HCIUART
>> >> CONFIG_BT_HCIUART_LL
>> >
>> > I have enabled those flags, and I have updated my device tree.
>> > I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
>> > getting a lot of timeout errors.  I tested this against the original
>> > implemention I had in pdata-quirks.c using the ti-st driver, uim & and
>> > the btwilink driver.
>> >
>> > I pulled in some of the newer patches to enable the wl1283-st, but I
>> > am obviously missing something.
>> >
>> > I   58.717651] Bluetooth: hci0: Reading TI version information failed
>> > (-110)
>> > [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
>> > [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
>> > [   68.957641] Bluetooth: hci0: Reading TI version information failed
>> > (-110)
>> > [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
>> > [   69.132171] Bluetooth: Unknown HCI packet type 06
>> > [   69.138244] Bluetooth: Unknown HCI packet type 0c
>> > [   69.143249] Bluetooth: Unknown HCI packet type 40
>> > [   69.148498] Bluetooth: Unknown HCI packet type 20
>> > [   69.153533] Bluetooth: Data length is too large
>> > [   69.158569] Bluetooth: Unknown HCI packet type a0
>> > [   69.163574] Bluetooth: Unknown HCI packet type 00
>> > [   69.168731] Bluetooth: Unknown HCI packet type 00
>> > [   69.173736] Bluetooth: Unknown HCI packet type 34
>> > [   69.178924] Bluetooth: Unknown HCI packet type 91
>> > [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
>> > [   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)
>>
>> There's a bug in serdev_device_write(), so if you have that function
>> you need either the fix I sent or the patch to make
>> serdev_device_writebuf atomic again. Both are on the linux-serial
>> list, but not in any tree yet.
>
> You refer to the patches below, right?
>
>   [PATCH] tty: serdev: fix serdev_device_write return value,
>   http://www.spinics.net/lists/linux-serial/msg26117.html
>
>   [PATCH] serdev: Restore serdev_device_write_buf for atomic context,
>   http://www.spinics.net/lists/linux-serial/msg26113.html

Yes, either one will fix the issue.

Rob

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH 0/4] TI Bluetooth serdev support
@ 2017-05-09 14:14                     ` Rob Herring
  0 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-05-09 14:14 UTC (permalink / raw)
  To: Baruch Siach
  Cc: Adam Ford, Mark Rutland, devicetree, Johan Hedberg,
	Gustavo Padovan, Marcel Holtmann, Sebastian Reichel, Wei Xu,
	open list:BLUETOOTH DRIVERS, Eyal Reizer, netdev, Satish Patel,
	linux-arm-kernel

On Mon, May 8, 2017 at 11:48 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Rob,
>
> On Mon, May 08, 2017 at 04:12:16PM -0500, Rob Herring wrote:
>> On Fri, May 5, 2017 at 9:51 AM, Adam Ford <aford173@gmail.com> wrote:
>> > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@kernel.org> wrote:
>> >> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>> >>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
>> >>> > This series adds serdev support to the HCI LL protocol used on TI BT
>> >>> > modules and enables support on HiKey board with with the WL1835 module.
>> >>> > With this the custom TI UIM daemon and btattach are no longer needed.
>> >>>
>> >>> Without UIM daemon, what instruction do you use to load the BT firmware?
>> >>>
>> >>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
>> >>> might have some insight.
>> >>>
>> >>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
>> >>> returns a timeout.
>> >>>
>> >>> I modified my i.MX6 device tree per the binding documentation and
>> >>> setup the regulators and enable GPIO pins.
>> >>
>> >> If you configured everything correctly no userspace interaction is
>> >> required. The driver should request the firmware automatically once
>> >> you power up the bluetooth device.
>> >>
>> >> Apart from DT changes make sure, that the following options are
>> >> enabled and check dmesg for any hints.
>> >>
>> >> CONFIG_SERIAL_DEV_BUS
>> >> CONFIG_SERIAL_DEV_CTRL_TTYPORT
>> >> CONFIG_BT_HCIUART
>> >> CONFIG_BT_HCIUART_LL
>> >
>> > I have enabled those flags, and I have updated my device tree.
>> > I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
>> > getting a lot of timeout errors.  I tested this against the original
>> > implemention I had in pdata-quirks.c using the ti-st driver, uim & and
>> > the btwilink driver.
>> >
>> > I pulled in some of the newer patches to enable the wl1283-st, but I
>> > am obviously missing something.
>> >
>> > I   58.717651] Bluetooth: hci0: Reading TI version information failed
>> > (-110)
>> > [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
>> > [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
>> > [   68.957641] Bluetooth: hci0: Reading TI version information failed
>> > (-110)
>> > [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
>> > [   69.132171] Bluetooth: Unknown HCI packet type 06
>> > [   69.138244] Bluetooth: Unknown HCI packet type 0c
>> > [   69.143249] Bluetooth: Unknown HCI packet type 40
>> > [   69.148498] Bluetooth: Unknown HCI packet type 20
>> > [   69.153533] Bluetooth: Data length is too large
>> > [   69.158569] Bluetooth: Unknown HCI packet type a0
>> > [   69.163574] Bluetooth: Unknown HCI packet type 00
>> > [   69.168731] Bluetooth: Unknown HCI packet type 00
>> > [   69.173736] Bluetooth: Unknown HCI packet type 34
>> > [   69.178924] Bluetooth: Unknown HCI packet type 91
>> > [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
>> > [   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)
>>
>> There's a bug in serdev_device_write(), so if you have that function
>> you need either the fix I sent or the patch to make
>> serdev_device_writebuf atomic again. Both are on the linux-serial
>> list, but not in any tree yet.
>
> You refer to the patches below, right?
>
>   [PATCH] tty: serdev: fix serdev_device_write return value,
>   http://www.spinics.net/lists/linux-serial/msg26117.html
>
>   [PATCH] serdev: Restore serdev_device_write_buf for atomic context,
>   http://www.spinics.net/lists/linux-serial/msg26113.html

Yes, either one will fix the issue.

Rob

^ permalink raw reply	[flat|nested] 51+ messages in thread
* [PATCH 0/4] TI Bluetooth serdev support
@ 2017-05-09 14:14                     ` Rob Herring
  0 siblings, 0 replies; 51+ messages in thread
From: Rob Herring @ 2017-05-09 14:14 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, May 8, 2017 at 11:48 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Rob,
>
> On Mon, May 08, 2017 at 04:12:16PM -0500, Rob Herring wrote:
>> On Fri, May 5, 2017 at 9:51 AM, Adam Ford <aford173@gmail.com> wrote:
>> > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@kernel.org> wrote:
>> >> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>> >>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
>> >>> > This series adds serdev support to the HCI LL protocol used on TI BT
>> >>> > modules and enables support on HiKey board with with the WL1835 module.
>> >>> > With this the custom TI UIM daemon and btattach are no longer needed.
>> >>>
>> >>> Without UIM daemon, what instruction do you use to load the BT firmware?
>> >>>
>> >>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
>> >>> might have some insight.
>> >>>
>> >>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
>> >>> returns a timeout.
>> >>>
>> >>> I modified my i.MX6 device tree per the binding documentation and
>> >>> setup the regulators and enable GPIO pins.
>> >>
>> >> If you configured everything correctly no userspace interaction is
>> >> required. The driver should request the firmware automatically once
>> >> you power up the bluetooth device.
>> >>
>> >> Apart from DT changes make sure, that the following options are
>> >> enabled and check dmesg for any hints.
>> >>
>> >> CONFIG_SERIAL_DEV_BUS
>> >> CONFIG_SERIAL_DEV_CTRL_TTYPORT
>> >> CONFIG_BT_HCIUART
>> >> CONFIG_BT_HCIUART_LL
>> >
>> > I have enabled those flags, and I have updated my device tree.
>> > I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
>> > getting a lot of timeout errors.  I tested this against the original
>> > implemention I had in pdata-quirks.c using the ti-st driver, uim & and
>> > the btwilink driver.
>> >
>> > I pulled in some of the newer patches to enable the wl1283-st, but I
>> > am obviously missing something.
>> >
>> > I   58.717651] Bluetooth: hci0: Reading TI version information failed
>> > (-110)
>> > [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
>> > [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
>> > [   68.957641] Bluetooth: hci0: Reading TI version information failed
>> > (-110)
>> > [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
>> > [   69.132171] Bluetooth: Unknown HCI packet type 06
>> > [   69.138244] Bluetooth: Unknown HCI packet type 0c
>> > [   69.143249] Bluetooth: Unknown HCI packet type 40
>> > [   69.148498] Bluetooth: Unknown HCI packet type 20
>> > [   69.153533] Bluetooth: Data length is too large
>> > [   69.158569] Bluetooth: Unknown HCI packet type a0
>> > [   69.163574] Bluetooth: Unknown HCI packet type 00
>> > [   69.168731] Bluetooth: Unknown HCI packet type 00
>> > [   69.173736] Bluetooth: Unknown HCI packet type 34
>> > [   69.178924] Bluetooth: Unknown HCI packet type 91
>> > [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
>> > [   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)
>>
>> There's a bug in serdev_device_write(), so if you have that function
>> you need either the fix I sent or the patch to make
>> serdev_device_writebuf atomic again. Both are on the linux-serial
>> list, but not in any tree yet.
>
> You refer to the patches below, right?
>
>   [PATCH] tty: serdev: fix serdev_device_write return value,
>   http://www.spinics.net/lists/linux-serial/msg26117.html
>
>   [PATCH] serdev: Restore serdev_device_write_buf for atomic context,
>   http://www.spinics.net/lists/linux-serial/msg26113.html

Yes, either one will fix the issue.

Rob

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH 0/4] TI Bluetooth serdev support
  2017-05-09 14:14                     ` Rob Herring
@ 2017-10-27 10:55                       ` Adam Ford
  -1 siblings, 0 replies; 51+ messages in thread
From: Adam Ford @ 2017-10-27 10:55 UTC (permalink / raw)
  To: Rob Herring
  Cc: Baruch Siach, Mark Rutland, devicetree, Johan Hedberg,
	Gustavo Padovan, Marcel Holtmann, Sebastian Reichel, Wei Xu,
	open list:BLUETOOTH DRIVERS, Eyal Reizer, netdev, Satish Patel,
	linux-arm-kernel

On Tue, May 9, 2017 at 9:14 AM, Rob Herring <robh@kernel.org> wrote:
> On Mon, May 8, 2017 at 11:48 PM, Baruch Siach <baruch@tkos.co.il> wrote:
>> Hi Rob,
>>
>> On Mon, May 08, 2017 at 04:12:16PM -0500, Rob Herring wrote:
>>> On Fri, May 5, 2017 at 9:51 AM, Adam Ford <aford173@gmail.com> wrote:
>>> > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@kernel.org> wrote:
>>> >> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>>> >>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
>>> >>> > This series adds serdev support to the HCI LL protocol used on TI BT
>>> >>> > modules and enables support on HiKey board with with the WL1835 module.
>>> >>> > With this the custom TI UIM daemon and btattach are no longer needed.
>>> >>>
>>> >>> Without UIM daemon, what instruction do you use to load the BT firmware?
>>> >>>
>>> >>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
>>> >>> might have some insight.
>>> >>>
>>> >>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
>>> >>> returns a timeout.
>>> >>>
>>> >>> I modified my i.MX6 device tree per the binding documentation and
>>> >>> setup the regulators and enable GPIO pins.
>>> >>
>>> >> If you configured everything correctly no userspace interaction is
>>> >> required. The driver should request the firmware automatically once
>>> >> you power up the bluetooth device.
>>> >>
>>> >> Apart from DT changes make sure, that the following options are
>>> >> enabled and check dmesg for any hints.
>>> >>
>>> >> CONFIG_SERIAL_DEV_BUS
>>> >> CONFIG_SERIAL_DEV_CTRL_TTYPORT
>>> >> CONFIG_BT_HCIUART
>>> >> CONFIG_BT_HCIUART_LL
>>> >
>>> > I have enabled those flags, and I have updated my device tree.
>>> > I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
>>> > getting a lot of timeout errors.  I tested this against the original
>>> > implemention I had in pdata-quirks.c using the ti-st driver, uim & and
>>> > the btwilink driver.
>>> >
>>> > I pulled in some of the newer patches to enable the wl1283-st, but I
>>> > am obviously missing something.
>>> >
>>> > I   58.717651] Bluetooth: hci0: Reading TI version information failed
>>> > (-110)
>>> > [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
>>> > [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
>>> > [   68.957641] Bluetooth: hci0: Reading TI version information failed
>>> > (-110)
>>> > [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
>>> > [   69.132171] Bluetooth: Unknown HCI packet type 06
>>> > [   69.138244] Bluetooth: Unknown HCI packet type 0c
>>> > [   69.143249] Bluetooth: Unknown HCI packet type 40
>>> > [   69.148498] Bluetooth: Unknown HCI packet type 20
>>> > [   69.153533] Bluetooth: Data length is too large
>>> > [   69.158569] Bluetooth: Unknown HCI packet type a0
>>> > [   69.163574] Bluetooth: Unknown HCI packet type 00
>>> > [   69.168731] Bluetooth: Unknown HCI packet type 00
>>> > [   69.173736] Bluetooth: Unknown HCI packet type 34
>>> > [   69.178924] Bluetooth: Unknown HCI packet type 91
>>> > [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
>>> > [   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)
>>>
>>> There's a bug in serdev_device_write(), so if you have that function
>>> you need either the fix I sent or the patch to make
>>> serdev_device_writebuf atomic again. Both are on the linux-serial
>>> list, but not in any tree yet.
>>
>> You refer to the patches below, right?
>>
>>   [PATCH] tty: serdev: fix serdev_device_write return value,
>>   http://www.spinics.net/lists/linux-serial/msg26117.html
>>
>>   [PATCH] serdev: Restore serdev_device_write_buf for atomic context,
>>   http://www.spinics.net/lists/linux-serial/msg26113.html
>
> Yes, either one will fix the issue.

I am finally getting back to testing these on my DM3730 board, since
it appears most of the patches appear upstream.  I am having trouble
remembering how to load this.

# modprobe hci_uart
[   31.639892] Bluetooth: Core ver 2.22
[   31.643890] NET: Registered protocol family 31
[   31.648559] Bluetooth: HCI device and connection manager initialized
[   31.655975] Bluetooth: HCI socket layer initialized
[   31.661315] Bluetooth: L2CAP socket layer initialized
[   31.667175] Bluetooth: SCO socket layer initialized
[   31.700408] Bluetooth: HCI UART driver ver 2.3
[   31.705108] Bluetooth: HCI UART protocol H4 registered
[   31.710632] Bluetooth: HCI UART protocol BCSP registered
[   31.716217] Bluetooth: HCI UART protocol Three-wire (H5) registered
#

Unfortunately, any attempt to access the HCI device (ie hciconfig up
hci0) fail.

I have those configs enabled:
CONFIG_SERIAL_DEV_BUS
CONFIG_SERIAL_DEV_CTRL_TTYPORT
CONFIG_BT_HCIUART
CONFIG_BT_HCIUART_LL

I can see that sysfs shows new files appear:

/sys/class/bluetooth
/sys/firmware/devicetree/base/ocp@68000000/serial@4806c000/bluetooth
/sys/firmware/devicetree/base/ocp@68000000/serial@4806c000/bluetooth/compatible
/sys/firmware/devicetree/base/ocp@68000000/serial@4806c000/bluetooth/enable-gpios
/sys/firmware/devicetree/base/ocp@68000000/serial@4806c000/bluetooth/name

(and more)
So it appears to me like it has loaded, and I don't see any errors during load.

Since this worked under pdata quirks and the older shared transport
driver and UIM, I'm sure it's software and not hardware.  I just can't
figure out what I am missing.

thanks

adam
>
> Rob

^ permalink raw reply	[flat|nested] 51+ messages in thread
* [PATCH 0/4] TI Bluetooth serdev support
@ 2017-10-27 10:55                       ` Adam Ford
  0 siblings, 0 replies; 51+ messages in thread
From: Adam Ford @ 2017-10-27 10:55 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, May 9, 2017 at 9:14 AM, Rob Herring <robh@kernel.org> wrote:
> On Mon, May 8, 2017 at 11:48 PM, Baruch Siach <baruch@tkos.co.il> wrote:
>> Hi Rob,
>>
>> On Mon, May 08, 2017 at 04:12:16PM -0500, Rob Herring wrote:
>>> On Fri, May 5, 2017 at 9:51 AM, Adam Ford <aford173@gmail.com> wrote:
>>> > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@kernel.org> wrote:
>>> >> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>>> >>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
>>> >>> > This series adds serdev support to the HCI LL protocol used on TI BT
>>> >>> > modules and enables support on HiKey board with with the WL1835 module.
>>> >>> > With this the custom TI UIM daemon and btattach are no longer needed.
>>> >>>
>>> >>> Without UIM daemon, what instruction do you use to load the BT firmware?
>>> >>>
>>> >>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
>>> >>> might have some insight.
>>> >>>
>>> >>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
>>> >>> returns a timeout.
>>> >>>
>>> >>> I modified my i.MX6 device tree per the binding documentation and
>>> >>> setup the regulators and enable GPIO pins.
>>> >>
>>> >> If you configured everything correctly no userspace interaction is
>>> >> required. The driver should request the firmware automatically once
>>> >> you power up the bluetooth device.
>>> >>
>>> >> Apart from DT changes make sure, that the following options are
>>> >> enabled and check dmesg for any hints.
>>> >>
>>> >> CONFIG_SERIAL_DEV_BUS
>>> >> CONFIG_SERIAL_DEV_CTRL_TTYPORT
>>> >> CONFIG_BT_HCIUART
>>> >> CONFIG_BT_HCIUART_LL
>>> >
>>> > I have enabled those flags, and I have updated my device tree.
>>> > I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
>>> > getting a lot of timeout errors.  I tested this against the original
>>> > implemention I had in pdata-quirks.c using the ti-st driver, uim & and
>>> > the btwilink driver.
>>> >
>>> > I pulled in some of the newer patches to enable the wl1283-st, but I
>>> > am obviously missing something.
>>> >
>>> > I   58.717651] Bluetooth: hci0: Reading TI version information failed
>>> > (-110)
>>> > [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
>>> > [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
>>> > [   68.957641] Bluetooth: hci0: Reading TI version information failed
>>> > (-110)
>>> > [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
>>> > [   69.132171] Bluetooth: Unknown HCI packet type 06
>>> > [   69.138244] Bluetooth: Unknown HCI packet type 0c
>>> > [   69.143249] Bluetooth: Unknown HCI packet type 40
>>> > [   69.148498] Bluetooth: Unknown HCI packet type 20
>>> > [   69.153533] Bluetooth: Data length is too large
>>> > [   69.158569] Bluetooth: Unknown HCI packet type a0
>>> > [   69.163574] Bluetooth: Unknown HCI packet type 00
>>> > [   69.168731] Bluetooth: Unknown HCI packet type 00
>>> > [   69.173736] Bluetooth: Unknown HCI packet type 34
>>> > [   69.178924] Bluetooth: Unknown HCI packet type 91
>>> > [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
>>> > [   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)
>>>
>>> There's a bug in serdev_device_write(), so if you have that function
>>> you need either the fix I sent or the patch to make
>>> serdev_device_writebuf atomic again. Both are on the linux-serial
>>> list, but not in any tree yet.
>>
>> You refer to the patches below, right?
>>
>>   [PATCH] tty: serdev: fix serdev_device_write return value,
>>   http://www.spinics.net/lists/linux-serial/msg26117.html
>>
>>   [PATCH] serdev: Restore serdev_device_write_buf for atomic context,
>>   http://www.spinics.net/lists/linux-serial/msg26113.html
>
> Yes, either one will fix the issue.

I am finally getting back to testing these on my DM3730 board, since
it appears most of the patches appear upstream.  I am having trouble
remembering how to load this.

# modprobe hci_uart
[   31.639892] Bluetooth: Core ver 2.22
[   31.643890] NET: Registered protocol family 31
[   31.648559] Bluetooth: HCI device and connection manager initialized
[   31.655975] Bluetooth: HCI socket layer initialized
[   31.661315] Bluetooth: L2CAP socket layer initialized
[   31.667175] Bluetooth: SCO socket layer initialized
[   31.700408] Bluetooth: HCI UART driver ver 2.3
[   31.705108] Bluetooth: HCI UART protocol H4 registered
[   31.710632] Bluetooth: HCI UART protocol BCSP registered
[   31.716217] Bluetooth: HCI UART protocol Three-wire (H5) registered
#

Unfortunately, any attempt to access the HCI device (ie hciconfig up
hci0) fail.

I have those configs enabled:
CONFIG_SERIAL_DEV_BUS
CONFIG_SERIAL_DEV_CTRL_TTYPORT
CONFIG_BT_HCIUART
CONFIG_BT_HCIUART_LL

I can see that sysfs shows new files appear:

/sys/class/bluetooth
/sys/firmware/devicetree/base/ocp at 68000000/serial at 4806c000/bluetooth
/sys/firmware/devicetree/base/ocp at 68000000/serial at 4806c000/bluetooth/compatible
/sys/firmware/devicetree/base/ocp at 68000000/serial at 4806c000/bluetooth/enable-gpios
/sys/firmware/devicetree/base/ocp at 68000000/serial at 4806c000/bluetooth/name

(and more)
So it appears to me like it has loaded, and I don't see any errors during load.

Since this worked under pdata quirks and the older shared transport
driver and UIM, I'm sure it's software and not hardware.  I just can't
figure out what I am missing.

thanks

adam
>
> Rob

^ permalink raw reply	[flat|nested] 51+ messages in thread
* Re: [PATCH 0/4] TI Bluetooth serdev support
  2017-10-27 10:55                       ` Adam Ford
@ 2017-10-28 11:33                         ` Adam Ford
  -1 siblings, 0 replies; 51+ messages in thread
From: Adam Ford @ 2017-10-28 11:33 UTC (permalink / raw)
  To: Rob Herring
  Cc: Baruch Siach, Mark Rutland, devicetree, Johan Hedberg,
	Gustavo Padovan, Marcel Holtmann, Sebastian Reichel, Wei Xu,
	open list:BLUETOOTH DRIVERS, Eyal Reizer, netdev, Satish Patel,
	linux-arm-kernel

On Fri, Oct 27, 2017 at 5:55 AM, Adam Ford <aford173@gmail.com> wrote:
> On Tue, May 9, 2017 at 9:14 AM, Rob Herring <robh@kernel.org> wrote:
>> On Mon, May 8, 2017 at 11:48 PM, Baruch Siach <baruch@tkos.co.il> wrote:
>>> Hi Rob,
>>>
>>> On Mon, May 08, 2017 at 04:12:16PM -0500, Rob Herring wrote:
>>>> On Fri, May 5, 2017 at 9:51 AM, Adam Ford <aford173@gmail.com> wrote:
>>>> > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@kernel.org> wrote:
>>>> >> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>>>> >>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
>>>> >>> > This series adds serdev support to the HCI LL protocol used on TI BT
>>>> >>> > modules and enables support on HiKey board with with the WL1835 module.
>>>> >>> > With this the custom TI UIM daemon and btattach are no longer needed.
>>>> >>>
>>>> >>> Without UIM daemon, what instruction do you use to load the BT firmware?
>>>> >>>
>>>> >>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
>>>> >>> might have some insight.
>>>> >>>
>>>> >>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
>>>> >>> returns a timeout.
>>>> >>>
>>>> >>> I modified my i.MX6 device tree per the binding documentation and
>>>> >>> setup the regulators and enable GPIO pins.
>>>> >>
>>>> >> If you configured everything correctly no userspace interaction is
>>>> >> required. The driver should request the firmware automatically once
>>>> >> you power up the bluetooth device.
>>>> >>
>>>> >> Apart from DT changes make sure, that the following options are
>>>> >> enabled and check dmesg for any hints.
>>>> >>
>>>> >> CONFIG_SERIAL_DEV_BUS
>>>> >> CONFIG_SERIAL_DEV_CTRL_TTYPORT
>>>> >> CONFIG_BT_HCIUART
>>>> >> CONFIG_BT_HCIUART_LL
>>>> >
>>>> > I have enabled those flags, and I have updated my device tree.
>>>> > I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
>>>> > getting a lot of timeout errors.  I tested this against the original
>>>> > implemention I had in pdata-quirks.c using the ti-st driver, uim & and
>>>> > the btwilink driver.
>>>> >
>>>> > I pulled in some of the newer patches to enable the wl1283-st, but I
>>>> > am obviously missing something.
>>>> >
>>>> > I   58.717651] Bluetooth: hci0: Reading TI version information failed
>>>> > (-110)
>>>> > [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
>>>> > [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
>>>> > [   68.957641] Bluetooth: hci0: Reading TI version information failed
>>>> > (-110)
>>>> > [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
>>>> > [   69.132171] Bluetooth: Unknown HCI packet type 06
>>>> > [   69.138244] Bluetooth: Unknown HCI packet type 0c
>>>> > [   69.143249] Bluetooth: Unknown HCI packet type 40
>>>> > [   69.148498] Bluetooth: Unknown HCI packet type 20
>>>> > [   69.153533] Bluetooth: Data length is too large
>>>> > [   69.158569] Bluetooth: Unknown HCI packet type a0
>>>> > [   69.163574] Bluetooth: Unknown HCI packet type 00
>>>> > [   69.168731] Bluetooth: Unknown HCI packet type 00
>>>> > [   69.173736] Bluetooth: Unknown HCI packet type 34
>>>> > [   69.178924] Bluetooth: Unknown HCI packet type 91
>>>> > [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
>>>> > [   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)
>>>>
>>>> There's a bug in serdev_device_write(), so if you have that function
>>>> you need either the fix I sent or the patch to make
>>>> serdev_device_writebuf atomic again. Both are on the linux-serial
>>>> list, but not in any tree yet.
>>>
>>> You refer to the patches below, right?
>>>
>>>   [PATCH] tty: serdev: fix serdev_device_write return value,
>>>   http://www.spinics.net/lists/linux-serial/msg26117.html
>>>
>>>   [PATCH] serdev: Restore serdev_device_write_buf for atomic context,
>>>   http://www.spinics.net/lists/linux-serial/msg26113.html
>>
>> Yes, either one will fix the issue.
>
> I am finally getting back to testing these on my DM3730 board, since
> it appears most of the patches appear upstream.  I am having trouble
> remembering how to load this.
>
> # modprobe hci_uart
> [   31.639892] Bluetooth: Core ver 2.22
> [   31.643890] NET: Registered protocol family 31
> [   31.648559] Bluetooth: HCI device and connection manager initialized
> [   31.655975] Bluetooth: HCI socket layer initialized
> [   31.661315] Bluetooth: L2CAP socket layer initialized
> [   31.667175] Bluetooth: SCO socket layer initialized
> [   31.700408] Bluetooth: HCI UART driver ver 2.3
> [   31.705108] Bluetooth: HCI UART protocol H4 registered
> [   31.710632] Bluetooth: HCI UART protocol BCSP registered
> [   31.716217] Bluetooth: HCI UART protocol Three-wire (H5) registered
> #
>
> Unfortunately, any attempt to access the HCI device (ie hciconfig up
> hci0) fail.
>
> I have those configs enabled:
> CONFIG_SERIAL_DEV_BUS
> CONFIG_SERIAL_DEV_CTRL_TTYPORT
> CONFIG_BT_HCIUART
> CONFIG_BT_HCIUART_LL
>
> I can see that sysfs shows new files appear:
>
> /sys/class/bluetooth
> /sys/firmware/devicetree/base/ocp@68000000/serial@4806c000/bluetooth
> /sys/firmware/devicetree/base/ocp@68000000/serial@4806c000/bluetooth/compatible
> /sys/firmware/devicetree/base/ocp@68000000/serial@4806c000/bluetooth/enable-gpios
> /sys/firmware/devicetree/base/ocp@68000000/serial@4806c000/bluetooth/name
>
> (and more)
> So it appears to me like it has loaded, and I don't see any errors during load.
>
> Since this worked under pdata quirks and the older shared transport
> driver and UIM, I'm sure it's software and not hardware.  I just can't
> figure out what I am missing.
>

Nevermind. Sorry for the noise, I got past this part.  I had a typo in
my device tree.


> thanks
>
> adam
>>
>> Rob

^ permalink raw reply	[flat|nested] 51+ messages in thread
* [PATCH 0/4] TI Bluetooth serdev support
@ 2017-10-28 11:33                         ` Adam Ford
  0 siblings, 0 replies; 51+ messages in thread
From: Adam Ford @ 2017-10-28 11:33 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Oct 27, 2017 at 5:55 AM, Adam Ford <aford173@gmail.com> wrote:
> On Tue, May 9, 2017 at 9:14 AM, Rob Herring <robh@kernel.org> wrote:
>> On Mon, May 8, 2017 at 11:48 PM, Baruch Siach <baruch@tkos.co.il> wrote:
>>> Hi Rob,
>>>
>>> On Mon, May 08, 2017 at 04:12:16PM -0500, Rob Herring wrote:
>>>> On Fri, May 5, 2017 at 9:51 AM, Adam Ford <aford173@gmail.com> wrote:
>>>> > On Sun, Apr 30, 2017 at 11:04 AM, Sebastian Reichel <sre@kernel.org> wrote:
>>>> >> On Sun, Apr 30, 2017 at 10:14:20AM -0500, Adam Ford wrote:
>>>> >>> On Wed, Apr 5, 2017 at 1:30 PM, Rob Herring <robh@kernel.org> wrote:
>>>> >>> > This series adds serdev support to the HCI LL protocol used on TI BT
>>>> >>> > modules and enables support on HiKey board with with the WL1835 module.
>>>> >>> > With this the custom TI UIM daemon and btattach are no longer needed.
>>>> >>>
>>>> >>> Without UIM daemon, what instruction do you use to load the BT firmware?
>>>> >>>
>>>> >>> I was thinking 'hciattach' but I was having trouble.  I was hoping you
>>>> >>> might have some insight.
>>>> >>>
>>>> >>>  hciattach -t 30 -s 115200 /dev/ttymxc1 texas 3000000 flow  Just
>>>> >>> returns a timeout.
>>>> >>>
>>>> >>> I modified my i.MX6 device tree per the binding documentation and
>>>> >>> setup the regulators and enable GPIO pins.
>>>> >>
>>>> >> If you configured everything correctly no userspace interaction is
>>>> >> required. The driver should request the firmware automatically once
>>>> >> you power up the bluetooth device.
>>>> >>
>>>> >> Apart from DT changes make sure, that the following options are
>>>> >> enabled and check dmesg for any hints.
>>>> >>
>>>> >> CONFIG_SERIAL_DEV_BUS
>>>> >> CONFIG_SERIAL_DEV_CTRL_TTYPORT
>>>> >> CONFIG_BT_HCIUART
>>>> >> CONFIG_BT_HCIUART_LL
>>>> >
>>>> > I have enabled those flags, and I have updated my device tree.
>>>> > I am testing this on an OMAP3630 (DM3730) board with a WL1283.  I am
>>>> > getting a lot of timeout errors.  I tested this against the original
>>>> > implemention I had in pdata-quirks.c using the ti-st driver, uim & and
>>>> > the btwilink driver.
>>>> >
>>>> > I pulled in some of the newer patches to enable the wl1283-st, but I
>>>> > am obviously missing something.
>>>> >
>>>> > I   58.717651] Bluetooth: hci0: Reading TI version information failed
>>>> > (-110)
>>>> > [   58.724853] Bluetooth: hci0: download firmware failed, retrying...
>>>> > [   60.957641] Bluetooth: hci0 command 0x1001 tx timeout
>>>> > [   68.957641] Bluetooth: hci0: Reading TI version information failed
>>>> > (-110)
>>>> > [   68.964843] Bluetooth: hci0: download firmware failed, retrying...
>>>> > [   69.132171] Bluetooth: Unknown HCI packet type 06
>>>> > [   69.138244] Bluetooth: Unknown HCI packet type 0c
>>>> > [   69.143249] Bluetooth: Unknown HCI packet type 40
>>>> > [   69.148498] Bluetooth: Unknown HCI packet type 20
>>>> > [   69.153533] Bluetooth: Data length is too large
>>>> > [   69.158569] Bluetooth: Unknown HCI packet type a0
>>>> > [   69.163574] Bluetooth: Unknown HCI packet type 00
>>>> > [   69.168731] Bluetooth: Unknown HCI packet type 00
>>>> > [   69.173736] Bluetooth: Unknown HCI packet type 34
>>>> > [   69.178924] Bluetooth: Unknown HCI packet type 91
>>>> > [   71.197631] Bluetooth: hci0 command 0x1001 tx timeout
>>>> > [   79.197662] Bluetooth: hci0: Reading TI version information failed (-110)
>>>>
>>>> There's a bug in serdev_device_write(), so if you have that function
>>>> you need either the fix I sent or the patch to make
>>>> serdev_device_writebuf atomic again. Both are on the linux-serial
>>>> list, but not in any tree yet.
>>>
>>> You refer to the patches below, right?
>>>
>>>   [PATCH] tty: serdev: fix serdev_device_write return value,
>>>   http://www.spinics.net/lists/linux-serial/msg26117.html
>>>
>>>   [PATCH] serdev: Restore serdev_device_write_buf for atomic context,
>>>   http://www.spinics.net/lists/linux-serial/msg26113.html
>>
>> Yes, either one will fix the issue.
>
> I am finally getting back to testing these on my DM3730 board, since
> it appears most of the patches appear upstream.  I am having trouble
> remembering how to load this.
>
> # modprobe hci_uart
> [   31.639892] Bluetooth: Core ver 2.22
> [   31.643890] NET: Registered protocol family 31
> [   31.648559] Bluetooth: HCI device and connection manager initialized
> [   31.655975] Bluetooth: HCI socket layer initialized
> [   31.661315] Bluetooth: L2CAP socket layer initialized
> [   31.667175] Bluetooth: SCO socket layer initialized
> [   31.700408] Bluetooth: HCI UART driver ver 2.3
> [   31.705108] Bluetooth: HCI UART protocol H4 registered
> [   31.710632] Bluetooth: HCI UART protocol BCSP registered
> [   31.716217] Bluetooth: HCI UART protocol Three-wire (H5) registered
> #
>
> Unfortunately, any attempt to access the HCI device (ie hciconfig up
> hci0) fail.
>
> I have those configs enabled:
> CONFIG_SERIAL_DEV_BUS
> CONFIG_SERIAL_DEV_CTRL_TTYPORT
> CONFIG_BT_HCIUART
> CONFIG_BT_HCIUART_LL
>
> I can see that sysfs shows new files appear:
>
> /sys/class/bluetooth
> /sys/firmware/devicetree/base/ocp at 68000000/serial at 4806c000/bluetooth
> /sys/firmware/devicetree/base/ocp at 68000000/serial at 4806c000/bluetooth/compatible
> /sys/firmware/devicetree/base/ocp at 68000000/serial at 4806c000/bluetooth/enable-gpios
> /sys/firmware/devicetree/base/ocp at 68000000/serial at 4806c000/bluetooth/name
>
> (and more)
> So it appears to me like it has loaded, and I don't see any errors during load.
>
> Since this worked under pdata quirks and the older shared transport
> driver and UIM, I'm sure it's software and not hardware.  I just can't
> figure out what I am missing.
>

Nevermind. Sorry for the noise, I got past this part.  I had a typo in
my device tree.


> thanks
>
> adam
>>
>> Rob

^ permalink raw reply	[flat|nested] 51+ messages in thread
end of thread, other threads:[~2017-10-28 11:34 UTC | newest]

Thread overview: 51+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-05 18:30 [PATCH 0/4] TI Bluetooth serdev support Rob Herring
2017-04-05 18:30 ` Rob Herring
2017-04-05 18:30 ` Rob Herring
2017-04-05 18:30 ` [PATCH 1/4] dt-bindings: net: Add TI WiLink shared transport binding Rob Herring
2017-04-05 18:30   ` Rob Herring
     [not found] ` <20170405183005.20570-1-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2017-04-05 18:30   ` [PATCH 2/4] bluetooth: hci_uart: remove unused hci_uart_init_tty Rob Herring
2017-04-05 18:30     ` Rob Herring
2017-04-05 18:30     ` Rob Herring
2017-04-05 18:30   ` [PATCH 3/4] bluetooth: hci_uart: add LL protocol serdev driver support Rob Herring
2017-04-05 18:30     ` Rob Herring
2017-04-05 18:30     ` Rob Herring
     [not found]     ` <20170405183005.20570-4-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2017-04-07 14:35       ` [PATCH v2 " Rob Herring
2017-04-07 14:35         ` Rob Herring
2017-04-07 14:35         ` Rob Herring
2017-04-07 17:09         ` Dan Williams
2017-04-07 17:09           ` Dan Williams
2017-04-07 17:09           ` Dan Williams
2017-04-07 18:48           ` Rob Herring
2017-04-07 18:48             ` Rob Herring
     [not found]             ` <CAL_Jsq+aM+xxbu=3v8_w9Ce+=t_pXmVWuisnckA8_8LOS-ftVA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-07 20:09               ` Dan Williams
2017-04-07 20:09                 ` Dan Williams
2017-04-07 20:09                 ` Dan Williams
2017-04-12 20:20         ` Marcel Holtmann
2017-04-12 20:20           ` Marcel Holtmann
2017-04-05 18:30   ` [PATCH 4/4] arm64: dts: hikey: add WL1835 Bluetooth device node Rob Herring
2017-04-05 18:30     ` Rob Herring
2017-04-05 18:30     ` Rob Herring
2017-04-30 15:14   ` [PATCH 0/4] TI Bluetooth serdev support Adam Ford
2017-04-30 15:14     ` Adam Ford
2017-04-30 15:14     ` Adam Ford
2017-04-30 16:04     ` Sebastian Reichel
2017-04-30 16:04       ` Sebastian Reichel
2017-04-30 16:04       ` Sebastian Reichel
2017-05-05 14:51       ` Adam Ford
2017-05-05 14:51         ` Adam Ford
2017-05-05 14:51         ` Adam Ford
2017-05-08 19:07         ` Sebastian Reichel
2017-05-08 19:07           ` Sebastian Reichel
     [not found]         ` <CAHCN7x+Mq=b6RN-ezU0400W=H=D7DR+Es1FHtT4GyozpVd8ALA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-08 21:12           ` Rob Herring
2017-05-08 21:12             ` Rob Herring
2017-05-08 21:12             ` Rob Herring
     [not found]             ` <CAL_JsqKBAPUPRtn+pEtz8B8pCrA=45RkEq6X_0i_HYoWsVmtyw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-09  4:48               ` Baruch Siach
2017-05-09  4:48                 ` Baruch Siach
2017-05-09  4:48                 ` Baruch Siach
     [not found]                 ` <20170509044837.oje2tfodytyuuuur-MwjkAAnuF3khR1HGirfZ1z4kX+cae0hd@public.gmane.org>
2017-05-09 14:14                   ` Rob Herring
2017-05-09 14:14                     ` Rob Herring
2017-05-09 14:14                     ` Rob Herring
2017-10-27 10:55                     ` Adam Ford
2017-10-27 10:55                       ` Adam Ford
2017-10-28 11:33                       ` Adam Ford
2017-10-28 11:33                         ` Adam Ford

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.