[PATCH 0/4] ARM: bcm2835-rpi-zero-w: Enable Bluetooth support

[PATCH 0/4] ARM: bcm2835-rpi-zero-w: Enable Bluetooth support

[Stefan Wahren]

This small patch series enable the on-board Bluetooth support on the
Raspberry Pi Zero W.

I suggest that the hci_bcm patch (regression fix) goes into bluetooth-fixes.

Note: For Bluetooth support it necessary to have a firmware located at:

/lib/firmware/brcm/BCM43430A1.hcd

Stefan Wahren (4):
  Bluetooth: hci_bcm: Make shutdown and device wake GPIO optional
  ARM: dts: bcm283x: Apply pull settings to Zero W relevant groups
  ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave
  ARM: bcm2385_defconfig: Enable BT support for BCM43438

 arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
 arch/arm/boot/dts/bcm283x.dtsi           |  3 +++
 arch/arm/configs/bcm2835_defconfig       |  4 ++++
 drivers/bluetooth/hci_bcm.c              |  8 +++++---
 4 files changed, 25 insertions(+), 4 deletions(-)

-- 
2.7.4

[PATCH 0/4] ARM: bcm2835-rpi-zero-w: Enable Bluetooth support

[Stefan Wahren]

This small patch series enable the on-board Bluetooth support on the
Raspberry Pi Zero W.

I suggest that the hci_bcm patch (regression fix) goes into bluetooth-fixes.

Note: For Bluetooth support it necessary to have a firmware located at:

/lib/firmware/brcm/BCM43430A1.hcd

Stefan Wahren (4):
  Bluetooth: hci_bcm: Make shutdown and device wake GPIO optional
  ARM: dts: bcm283x: Apply pull settings to Zero W relevant groups
  ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave
  ARM: bcm2385_defconfig: Enable BT support for BCM43438

 arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
 arch/arm/boot/dts/bcm283x.dtsi           |  3 +++
 arch/arm/configs/bcm2835_defconfig       |  4 ++++
 drivers/bluetooth/hci_bcm.c              |  8 +++++---
 4 files changed, 25 insertions(+), 4 deletions(-)

-- 
2.7.4

[PATCH 0/4] ARM: bcm2835-rpi-zero-w: Enable Bluetooth support

[Stefan Wahren]

This small patch series enable the on-board Bluetooth support on the
Raspberry Pi Zero W.

I suggest that the hci_bcm patch (regression fix) goes into bluetooth-fixes.

Note: For Bluetooth support it necessary to have a firmware located at:

/lib/firmware/brcm/BCM43430A1.hcd

Stefan Wahren (4):
  Bluetooth: hci_bcm: Make shutdown and device wake GPIO optional
  ARM: dts: bcm283x: Apply pull settings to Zero W relevant groups
  ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave
  ARM: bcm2385_defconfig: Enable BT support for BCM43438

 arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
 arch/arm/boot/dts/bcm283x.dtsi           |  3 +++
 arch/arm/configs/bcm2835_defconfig       |  4 ++++
 drivers/bluetooth/hci_bcm.c              |  8 +++++---
 4 files changed, 25 insertions(+), 4 deletions(-)

-- 
2.7.4

[PATCH 1/4] Bluetooth: hci_bcm: Make shutdown and device wake GPIO optional

[Stefan Wahren]

According to the devicetree binding the shutdown and device wake
GPIOs are optional. Since commit 3e81a4ca51a1 ("Bluetooth: hci_bcm:
Mandate presence of shutdown and device wake GPIO") this driver
won't probe anymore on Raspberry Pi 3 and Zero W (no device wake GPIO
connected). So fix this regression by reverting this commit partially.

Cc: Lukas Wunner <lukas@wunner.de>
Fixes: 3e81a4ca51a1 ("Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIO")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 drivers/bluetooth/hci_bcm.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index 0438a64..f8728eb 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -922,12 +922,14 @@ static int bcm_get_resources(struct bcm_device *dev)
 
 	dev->clk = devm_clk_get(dev->dev, NULL);
 
-	dev->device_wakeup = devm_gpiod_get(dev->dev, "device-wakeup",
-					    GPIOD_OUT_LOW);
+	dev->device_wakeup = devm_gpiod_get_optional(dev->dev,
+						     "device-wakeup",
+						     GPIOD_OUT_LOW);
 	if (IS_ERR(dev->device_wakeup))
 		return PTR_ERR(dev->device_wakeup);
 
-	dev->shutdown = devm_gpiod_get(dev->dev, "shutdown", GPIOD_OUT_LOW);
+	dev->shutdown = devm_gpiod_get_optional(dev->dev, "shutdown",
+						GPIOD_OUT_LOW);
 	if (IS_ERR(dev->shutdown))
 		return PTR_ERR(dev->shutdown);
 
-- 
2.7.4

[PATCH 1/4] Bluetooth: hci_bcm: Make shutdown and device wake GPIO optional

[Stefan Wahren]

According to the devicetree binding the shutdown and device wake
GPIOs are optional. Since commit 3e81a4ca51a1 ("Bluetooth: hci_bcm:
Mandate presence of shutdown and device wake GPIO") this driver
won't probe anymore on Raspberry Pi 3 and Zero W (no device wake GPIO
connected). So fix this regression by reverting this commit partially.

Cc: Lukas Wunner <lukas@wunner.de>
Fixes: 3e81a4ca51a1 ("Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIO")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 drivers/bluetooth/hci_bcm.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index 0438a64..f8728eb 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -922,12 +922,14 @@ static int bcm_get_resources(struct bcm_device *dev)
 
 	dev->clk = devm_clk_get(dev->dev, NULL);
 
-	dev->device_wakeup = devm_gpiod_get(dev->dev, "device-wakeup",
-					    GPIOD_OUT_LOW);
+	dev->device_wakeup = devm_gpiod_get_optional(dev->dev,
+						     "device-wakeup",
+						     GPIOD_OUT_LOW);
 	if (IS_ERR(dev->device_wakeup))
 		return PTR_ERR(dev->device_wakeup);
 
-	dev->shutdown = devm_gpiod_get(dev->dev, "shutdown", GPIOD_OUT_LOW);
+	dev->shutdown = devm_gpiod_get_optional(dev->dev, "shutdown",
+						GPIOD_OUT_LOW);
 	if (IS_ERR(dev->shutdown))
 		return PTR_ERR(dev->shutdown);
 
-- 
2.7.4

[PATCH 1/4] Bluetooth: hci_bcm: Make shutdown and device wake GPIO optional

[Stefan Wahren]

According to the devicetree binding the shutdown and device wake
GPIOs are optional. Since commit 3e81a4ca51a1 ("Bluetooth: hci_bcm:
Mandate presence of shutdown and device wake GPIO") this driver
won't probe anymore on Raspberry Pi 3 and Zero W (no device wake GPIO
connected). So fix this regression by reverting this commit partially.

Cc: Lukas Wunner <lukas@wunner.de>
Fixes: 3e81a4ca51a1 ("Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIO")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 drivers/bluetooth/hci_bcm.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
index 0438a64..f8728eb 100644
--- a/drivers/bluetooth/hci_bcm.c
+++ b/drivers/bluetooth/hci_bcm.c
@@ -922,12 +922,14 @@ static int bcm_get_resources(struct bcm_device *dev)
 
 	dev->clk = devm_clk_get(dev->dev, NULL);
 
-	dev->device_wakeup = devm_gpiod_get(dev->dev, "device-wakeup",
-					    GPIOD_OUT_LOW);
+	dev->device_wakeup = devm_gpiod_get_optional(dev->dev,
+						     "device-wakeup",
+						     GPIOD_OUT_LOW);
 	if (IS_ERR(dev->device_wakeup))
 		return PTR_ERR(dev->device_wakeup);
 
-	dev->shutdown = devm_gpiod_get(dev->dev, "shutdown", GPIOD_OUT_LOW);
+	dev->shutdown = devm_gpiod_get_optional(dev->dev, "shutdown",
+						GPIOD_OUT_LOW);
 	if (IS_ERR(dev->shutdown))
 		return PTR_ERR(dev->shutdown);
 
-- 
2.7.4

[PATCH 2/4] ARM: dts: bcm283x: Apply pull settings to Zero W relevant groups

[Stefan Wahren]

Instead of keeping the firmware's pull settings, we better apply
them via the devicetree pin control. Start with the RPi Zero W relevant
first to keep the effort low.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm/boot/dts/bcm283x.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 8d9a0df..1a50b67 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -223,6 +223,7 @@
 			gpclk2_gpio43: gpclk2_gpio43 {
 				brcm,pins = <43>;
 				brcm,function = <BCM2835_FSEL_ALT0>;
+				brcm,pull = <BCM2835_PUD_OFF>;
 			};
 
 			i2c0_gpio0: i2c0_gpio0 {
@@ -335,10 +336,12 @@
 			uart0_ctsrts_gpio30: uart0_ctsrts_gpio30 {
 				brcm,pins = <30 31>;
 				brcm,function = <BCM2835_FSEL_ALT3>;
+				brcm,pull = <BCM2835_PUD_UP BCM2835_PUD_OFF>;
 			};
 			uart0_gpio32: uart0_gpio32 {
 				brcm,pins = <32 33>;
 				brcm,function = <BCM2835_FSEL_ALT3>;
+				brcm,pull = <BCM2835_PUD_OFF BCM2835_PUD_UP>;
 			};
 			uart0_gpio36: uart0_gpio36 {
 				brcm,pins = <36 37>;
-- 
2.7.4

[PATCH 2/4] ARM: dts: bcm283x: Apply pull settings to Zero W relevant groups

[Stefan Wahren]

Instead of keeping the firmware's pull settings, we better apply
them via the devicetree pin control. Start with the RPi Zero W relevant
first to keep the effort low.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm/boot/dts/bcm283x.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 8d9a0df..1a50b67 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -223,6 +223,7 @@
 			gpclk2_gpio43: gpclk2_gpio43 {
 				brcm,pins = <43>;
 				brcm,function = <BCM2835_FSEL_ALT0>;
+				brcm,pull = <BCM2835_PUD_OFF>;
 			};
 
 			i2c0_gpio0: i2c0_gpio0 {
@@ -335,10 +336,12 @@
 			uart0_ctsrts_gpio30: uart0_ctsrts_gpio30 {
 				brcm,pins = <30 31>;
 				brcm,function = <BCM2835_FSEL_ALT3>;
+				brcm,pull = <BCM2835_PUD_UP BCM2835_PUD_OFF>;
 			};
 			uart0_gpio32: uart0_gpio32 {
 				brcm,pins = <32 33>;
 				brcm,function = <BCM2835_FSEL_ALT3>;
+				brcm,pull = <BCM2835_PUD_OFF BCM2835_PUD_UP>;
 			};
 			uart0_gpio36: uart0_gpio36 {
 				brcm,pins = <36 37>;
-- 
2.7.4

[PATCH 2/4] ARM: dts: bcm283x: Apply pull settings to Zero W relevant groups

[Stefan Wahren]

Instead of keeping the firmware's pull settings, we better apply
them via the devicetree pin control. Start with the RPi Zero W relevant
first to keep the effort low.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm/boot/dts/bcm283x.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 8d9a0df..1a50b67 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -223,6 +223,7 @@
 			gpclk2_gpio43: gpclk2_gpio43 {
 				brcm,pins = <43>;
 				brcm,function = <BCM2835_FSEL_ALT0>;
+				brcm,pull = <BCM2835_PUD_OFF>;
 			};
 
 			i2c0_gpio0: i2c0_gpio0 {
@@ -335,10 +336,12 @@
 			uart0_ctsrts_gpio30: uart0_ctsrts_gpio30 {
 				brcm,pins = <30 31>;
 				brcm,function = <BCM2835_FSEL_ALT3>;
+				brcm,pull = <BCM2835_PUD_UP BCM2835_PUD_OFF>;
 			};
 			uart0_gpio32: uart0_gpio32 {
 				brcm,pins = <32 33>;
 				brcm,function = <BCM2835_FSEL_ALT3>;
+				brcm,pull = <BCM2835_PUD_OFF BCM2835_PUD_UP>;
 			};
 			uart0_gpio36: uart0_gpio36 {
 				brcm,pins = <36 37>;
-- 
2.7.4

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
This allows to automatically insert the bcm43438 to the bluetooth
subsystem instead of relying on patched userspace helpers (hciattach).

In order to keep a debug UART we need to switch to uart1.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
index cf53436..b7f79f1 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
@@ -131,6 +131,18 @@
 
 &uart0 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&uart0_gpio14>;
+	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
+	status = "okay";
+
+	bluetooth {
+		compatible = "brcm,bcm43438-bt";
+		max-speed = <2000000>;
+		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
+	};
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_gpio14>;
 	status = "okay";
 };
-- 
2.7.4

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
This allows to automatically insert the bcm43438 to the bluetooth
subsystem instead of relying on patched userspace helpers (hciattach).

In order to keep a debug UART we need to switch to uart1.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
index cf53436..b7f79f1 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
@@ -131,6 +131,18 @@
 
 &uart0 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&uart0_gpio14>;
+	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
+	status = "okay";
+
+	bluetooth {
+		compatible = "brcm,bcm43438-bt";
+		max-speed = <2000000>;
+		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
+	};
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_gpio14>;
 	status = "okay";
 };
-- 
2.7.4

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
This allows to automatically insert the bcm43438 to the bluetooth
subsystem instead of relying on patched userspace helpers (hciattach).

In order to keep a debug UART we need to switch to uart1.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
index cf53436..b7f79f1 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
@@ -131,6 +131,18 @@
 
 &uart0 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&uart0_gpio14>;
+	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
+	status = "okay";
+
+	bluetooth {
+		compatible = "brcm,bcm43438-bt";
+		max-speed = <2000000>;
+		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
+	};
+};
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_gpio14>;
 	status = "okay";
 };
-- 
2.7.4

[PATCH 4/4] ARM: bcm2385_defconfig: Enable BT support for BCM43438

[Stefan Wahren]

The Raspberry Pi Zero W has an onboard BT chip (BCM43438). So enable the
necessary HCI UART driver (requires serial device bus).

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm/configs/bcm2835_defconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 43dab48..8682b15 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -49,6 +49,9 @@ CONFIG_IP_PNP=y
 CONFIG_IP_PNP_DHCP=y
 CONFIG_NETWORK_SECMARK=y
 CONFIG_NETFILTER=y
+CONFIG_BT=y
+CONFIG_BT_HCIUART=m
+CONFIG_BT_HCIUART_BCM=y
 CONFIG_CFG80211=y
 CONFIG_MAC80211=y
 CONFIG_DEVTMPFS=y
@@ -74,6 +77,7 @@ CONFIG_SERIAL_8250_SHARE_IRQ=y
 CONFIG_SERIAL_8250_BCM2835AUX=y
 CONFIG_SERIAL_AMBA_PL011=y
 CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_SERIAL_DEV_BUS=y
 CONFIG_TTY_PRINTK=y
 CONFIG_I2C_CHARDEV=y
 CONFIG_I2C_BCM2835=y
-- 
2.7.4

[PATCH 4/4] ARM: bcm2385_defconfig: Enable BT support for BCM43438

[Stefan Wahren]

The Raspberry Pi Zero W has an onboard BT chip (BCM43438). So enable the
necessary HCI UART driver (requires serial device bus).

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm/configs/bcm2835_defconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 43dab48..8682b15 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -49,6 +49,9 @@ CONFIG_IP_PNP=y
 CONFIG_IP_PNP_DHCP=y
 CONFIG_NETWORK_SECMARK=y
 CONFIG_NETFILTER=y
+CONFIG_BT=y
+CONFIG_BT_HCIUART=m
+CONFIG_BT_HCIUART_BCM=y
 CONFIG_CFG80211=y
 CONFIG_MAC80211=y
 CONFIG_DEVTMPFS=y
@@ -74,6 +77,7 @@ CONFIG_SERIAL_8250_SHARE_IRQ=y
 CONFIG_SERIAL_8250_BCM2835AUX=y
 CONFIG_SERIAL_AMBA_PL011=y
 CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_SERIAL_DEV_BUS=y
 CONFIG_TTY_PRINTK=y
 CONFIG_I2C_CHARDEV=y
 CONFIG_I2C_BCM2835=y
-- 
2.7.4

[PATCH 4/4] ARM: bcm2385_defconfig: Enable BT support for BCM43438

[Stefan Wahren]

The Raspberry Pi Zero W has an onboard BT chip (BCM43438). So enable the
necessary HCI UART driver (requires serial device bus).

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm/configs/bcm2835_defconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 43dab48..8682b15 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -49,6 +49,9 @@ CONFIG_IP_PNP=y
 CONFIG_IP_PNP_DHCP=y
 CONFIG_NETWORK_SECMARK=y
 CONFIG_NETFILTER=y
+CONFIG_BT=y
+CONFIG_BT_HCIUART=m
+CONFIG_BT_HCIUART_BCM=y
 CONFIG_CFG80211=y
 CONFIG_MAC80211=y
 CONFIG_DEVTMPFS=y
@@ -74,6 +77,7 @@ CONFIG_SERIAL_8250_SHARE_IRQ=y
 CONFIG_SERIAL_8250_BCM2835AUX=y
 CONFIG_SERIAL_AMBA_PL011=y
 CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_SERIAL_DEV_BUS=y
 CONFIG_TTY_PRINTK=y
 CONFIG_I2C_CHARDEV=y
 CONFIG_I2C_BCM2835=y
-- 
2.7.4

Re: [PATCH 1/4] Bluetooth: hci_bcm: Make shutdown and device wake GPIO optional

[Lukas Wunner]

On Sun, Feb 25, 2018 at 03:10:52PM +0100, Stefan Wahren wrote:
> According to the devicetree binding the shutdown and device wake
> GPIOs are optional. Since commit 3e81a4ca51a1 ("Bluetooth: hci_bcm:
> Mandate presence of shutdown and device wake GPIO") this driver
> won't probe anymore on Raspberry Pi 3 and Zero W (no device wake GPIO
> connected). So fix this regression by reverting this commit partially.

Okay when submitting 3e81a4ca51a1 I missed that gpiod_set_value()
becomes a no-op if the gpio_desc is NULL, I thought it would oops.


> -	dev->device_wakeup = devm_gpiod_get(dev->dev, "device-wakeup",
> -					    GPIOD_OUT_LOW);
> +	dev->device_wakeup = devm_gpiod_get_optional(dev->dev,
> +						     "device-wakeup",
> +						     GPIOD_OUT_LOW);

The "device-wakeup" would still fit within 80 chars on the preceding line.
Otherwise this is

Reviewed-by: Lukas Wunner <lukas@wunner.de>

Thanks,

Lukas

>  	if (IS_ERR(dev->device_wakeup))
>  		return PTR_ERR(dev->device_wakeup);
>  
> -	dev->shutdown = devm_gpiod_get(dev->dev, "shutdown", GPIOD_OUT_LOW);
> +	dev->shutdown = devm_gpiod_get_optional(dev->dev, "shutdown",
> +						GPIOD_OUT_LOW);
>  	if (IS_ERR(dev->shutdown))
>  		return PTR_ERR(dev->shutdown);
>  

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> This allows to automatically insert the bcm43438 to the bluetooth
> subsystem instead of relying on patched userspace helpers (hciattach).
> 
> In order to keep a debug UART we need to switch to uart1.
> 
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> index cf53436..b7f79f1 100644
> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> @@ -131,6 +131,18 @@
> 
> &uart0 {
> 	pinctrl-names = "default";
> -	pinctrl-0 = <&uart0_gpio14>;
> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> +	status = "okay";
> +
> +	bluetooth {
> +		compatible = "brcm,bcm43438-bt";
> +		max-speed = <2000000>;
> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> +	};
> +};

is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine? Meaning we are getting back to the 115200 default baud rate on the UART? Or is this actually the device-wakeup GPIO?

Regards

Marcel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> This allows to automatically insert the bcm43438 to the bluetooth
> subsystem instead of relying on patched userspace helpers (hciattach).
> 
> In order to keep a debug UART we need to switch to uart1.
> 
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> index cf53436..b7f79f1 100644
> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> @@ -131,6 +131,18 @@
> 
> &uart0 {
> 	pinctrl-names = "default";
> -	pinctrl-0 = <&uart0_gpio14>;
> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> +	status = "okay";
> +
> +	bluetooth {
> +		compatible = "brcm,bcm43438-bt";
> +		max-speed = <2000000>;
> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> +	};
> +};

is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine? Meaning we are getting back to the 115200 default baud rate on the UART? Or is this actually the device-wakeup GPIO?

Regards

Marcel

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> This allows to automatically insert the bcm43438 to the bluetooth
> subsystem instead of relying on patched userspace helpers (hciattach).
> 
> In order to keep a debug UART we need to switch to uart1.
> 
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> index cf53436..b7f79f1 100644
> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> @@ -131,6 +131,18 @@
> 
> &uart0 {
> 	pinctrl-names = "default";
> -	pinctrl-0 = <&uart0_gpio14>;
> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> +	status = "okay";
> +
> +	bluetooth {
> +		compatible = "brcm,bcm43438-bt";
> +		max-speed = <2000000>;
> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> +	};
> +};

is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine? Meaning we are getting back to the 115200 default baud rate on the UART? Or is this actually the device-wakeup GPIO?

Regards

Marcel

Re: [PATCH 1/4] Bluetooth: hci_bcm: Make shutdown and device wake GPIO optional

[Marcel Holtmann]

Hi Stefan,

> According to the devicetree binding the shutdown and device wake
> GPIOs are optional. Since commit 3e81a4ca51a1 ("Bluetooth: hci_bcm:
> Mandate presence of shutdown and device wake GPIO") this driver
> won't probe anymore on Raspberry Pi 3 and Zero W (no device wake GPIO
> connected). So fix this regression by reverting this commit partially.
> 
> Cc: Lukas Wunner <lukas@wunner.de>
> Fixes: 3e81a4ca51a1 ("Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIO")
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
> drivers/bluetooth/hci_bcm.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)

patch has been applied to bluetooth-stable tree.

Regards

Marcel

Re: [PATCH 1/4] Bluetooth: hci_bcm: Make shutdown and device wake GPIO optional

[Marcel Holtmann]

Hi Stefan,

> According to the devicetree binding the shutdown and device wake
> GPIOs are optional. Since commit 3e81a4ca51a1 ("Bluetooth: hci_bcm:
> Mandate presence of shutdown and device wake GPIO") this driver
> won't probe anymore on Raspberry Pi 3 and Zero W (no device wake GPIO
> connected). So fix this regression by reverting this commit partially.
> 
> Cc: Lukas Wunner <lukas@wunner.de>
> Fixes: 3e81a4ca51a1 ("Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIO")
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
> drivers/bluetooth/hci_bcm.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)

patch has been applied to bluetooth-stable tree.

Regards

Marcel

[PATCH 1/4] Bluetooth: hci_bcm: Make shutdown and device wake GPIO optional

[Marcel Holtmann]

Hi Stefan,

> According to the devicetree binding the shutdown and device wake
> GPIOs are optional. Since commit 3e81a4ca51a1 ("Bluetooth: hci_bcm:
> Mandate presence of shutdown and device wake GPIO") this driver
> won't probe anymore on Raspberry Pi 3 and Zero W (no device wake GPIO
> connected). So fix this regression by reverting this commit partially.
> 
> Cc: Lukas Wunner <lukas@wunner.de>
> Fixes: 3e81a4ca51a1 ("Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIO")
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
> drivers/bluetooth/hci_bcm.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)

patch has been applied to bluetooth-stable tree.

Regards

Marcel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,

> Marcel Holtmann <marcel@holtmann.org> hat am 25. Februar 2018 um 21:17 geschrieben:
> 
> 
> Hi Stefan,
> 
> > Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> > This allows to automatically insert the bcm43438 to the bluetooth
> > subsystem instead of relying on patched userspace helpers (hciattach).
> > 
> > In order to keep a debug UART we need to switch to uart1.
> > 
> > Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> > ---
> > arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> > index cf53436..b7f79f1 100644
> > --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> > +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> > @@ -131,6 +131,18 @@
> > 
> > &uart0 {
> > 	pinctrl-names = "default";
> > -	pinctrl-0 = <&uart0_gpio14>;
> > +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> > +	status = "okay";
> > +
> > +	bluetooth {
> > +		compatible = "brcm,bcm43438-bt";
> > +		max-speed = <2000000>;
> > +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> > +	};
> > +};
> 
> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?

Yes, unload and reload works fine. 

> Meaning we are getting back to the 115200 default baud rate on the UART?

I assume that, because reload works as expected. 

> Or is this actually the device-wakeup GPIO?

The line is called BT_ON, so i don't expect this to be the device-wakeup. I don't have any schematics for the bluetooth part.

Regards
Stefan

> 
> Regards
> 
> Marcel
>

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,

> Marcel Holtmann <marcel@holtmann.org> hat am 25. Februar 2018 um 21:17 geschrieben:
> 
> 
> Hi Stefan,
> 
> > Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> > This allows to automatically insert the bcm43438 to the bluetooth
> > subsystem instead of relying on patched userspace helpers (hciattach).
> > 
> > In order to keep a debug UART we need to switch to uart1.
> > 
> > Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> > ---
> > arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> > index cf53436..b7f79f1 100644
> > --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> > +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> > @@ -131,6 +131,18 @@
> > 
> > &uart0 {
> > 	pinctrl-names = "default";
> > -	pinctrl-0 = <&uart0_gpio14>;
> > +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> > +	status = "okay";
> > +
> > +	bluetooth {
> > +		compatible = "brcm,bcm43438-bt";
> > +		max-speed = <2000000>;
> > +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> > +	};
> > +};
> 
> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?

Yes, unload and reload works fine. 

> Meaning we are getting back to the 115200 default baud rate on the UART?

I assume that, because reload works as expected. 

> Or is this actually the device-wakeup GPIO?

The line is called BT_ON, so i don't expect this to be the device-wakeup. I don't have any schematics for the bluetooth part.

Regards
Stefan

> 
> Regards
> 
> Marcel
>

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,

> Marcel Holtmann <marcel@holtmann.org> hat am 25. Februar 2018 um 21:17 geschrieben:
> 
> 
> Hi Stefan,
> 
> > Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> > This allows to automatically insert the bcm43438 to the bluetooth
> > subsystem instead of relying on patched userspace helpers (hciattach).
> > 
> > In order to keep a debug UART we need to switch to uart1.
> > 
> > Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> > ---
> > arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> > index cf53436..b7f79f1 100644
> > --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> > +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> > @@ -131,6 +131,18 @@
> > 
> > &uart0 {
> > 	pinctrl-names = "default";
> > -	pinctrl-0 = <&uart0_gpio14>;
> > +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> > +	status = "okay";
> > +
> > +	bluetooth {
> > +		compatible = "brcm,bcm43438-bt";
> > +		max-speed = <2000000>;
> > +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> > +	};
> > +};
> 
> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?

Yes, unload and reload works fine. 

> Meaning we are getting back to the 115200 default baud rate on the UART?

I assume that, because reload works as expected. 

> Or is this actually the device-wakeup GPIO?

The line is called BT_ON, so i don't expect this to be the device-wakeup. I don't have any schematics for the bluetooth part.

Regards
Stefan

> 
> Regards
> 
> Marcel
>

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>> This allows to automatically insert the bcm43438 to the bluetooth
>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>> 
>>> In order to keep a debug UART we need to switch to uart1.
>>> 
>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>> ---
>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>> index cf53436..b7f79f1 100644
>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>> @@ -131,6 +131,18 @@
>>> 
>>> &uart0 {
>>> 	pinctrl-names = "default";
>>> -	pinctrl-0 = <&uart0_gpio14>;
>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>> +	status = "okay";
>>> +
>>> +	bluetooth {
>>> +		compatible = "brcm,bcm43438-bt";
>>> +		max-speed = <2000000>;
>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>> +	};
>>> +};
>> 
>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> 
> Yes, unload and reload works fine. 
> 
>> Meaning we are getting back to the 115200 default baud rate on the UART?
> 
> I assume that, because reload works as expected. 

awesome. That is good news.

Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.

Regards

Marcel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>> This allows to automatically insert the bcm43438 to the bluetooth
>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>> 
>>> In order to keep a debug UART we need to switch to uart1.
>>> 
>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>> ---
>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>> index cf53436..b7f79f1 100644
>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>> @@ -131,6 +131,18 @@
>>> 
>>> &uart0 {
>>> 	pinctrl-names = "default";
>>> -	pinctrl-0 = <&uart0_gpio14>;
>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>> +	status = "okay";
>>> +
>>> +	bluetooth {
>>> +		compatible = "brcm,bcm43438-bt";
>>> +		max-speed = <2000000>;
>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>> +	};
>>> +};
>> 
>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> 
> Yes, unload and reload works fine. 
> 
>> Meaning we are getting back to the 115200 default baud rate on the UART?
> 
> I assume that, because reload works as expected. 

awesome. That is good news.

Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.

Regards

Marcel

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>> This allows to automatically insert the bcm43438 to the bluetooth
>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>> 
>>> In order to keep a debug UART we need to switch to uart1.
>>> 
>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>> ---
>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>> index cf53436..b7f79f1 100644
>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>> @@ -131,6 +131,18 @@
>>> 
>>> &uart0 {
>>> 	pinctrl-names = "default";
>>> -	pinctrl-0 = <&uart0_gpio14>;
>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>> +	status = "okay";
>>> +
>>> +	bluetooth {
>>> +		compatible = "brcm,bcm43438-bt";
>>> +		max-speed = <2000000>;
>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>> +	};
>>> +};
>> 
>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> 
> Yes, unload and reload works fine. 
> 
>> Meaning we are getting back to the 115200 default baud rate on the UART?
> 
> I assume that, because reload works as expected. 

awesome. That is good news.

Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.

Regards

Marcel

Re: [PATCH 4/4] ARM: bcm2385_defconfig: Enable BT support for BCM43438

[Eric Anholt]

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

Stefan Wahren <stefan.wahren@i2se.com> writes:

> The Raspberry Pi Zero W has an onboard BT chip (BCM43438). So enable the
> necessary HCI UART driver (requires serial device bus).
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>

Applied patches 2-4 to bcm2835-dt-next and bcm2835-defconfig-next.
Thanks!

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 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

Re: [PATCH 4/4] ARM: bcm2385_defconfig: Enable BT support for BCM43438

[Eric Anholt]

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

Stefan Wahren <stefan.wahren@i2se.com> writes:

> The Raspberry Pi Zero W has an onboard BT chip (BCM43438). So enable the
> necessary HCI UART driver (requires serial device bus).
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>

Applied patches 2-4 to bcm2835-dt-next and bcm2835-defconfig-next.
Thanks!

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

[PATCH 4/4] ARM: bcm2385_defconfig: Enable BT support for BCM43438

[Eric Anholt]

Stefan Wahren <stefan.wahren@i2se.com> writes:

> The Raspberry Pi Zero W has an onboard BT chip (BCM43438). So enable the
> necessary HCI UART driver (requires serial device bus).
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>

Applied patches 2-4 to bcm2835-dt-next and bcm2835-defconfig-next.
Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180226/d561a6d1/attachment.sig>

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,

> Marcel Holtmann <marcel@holtmann.org> hat am 25. Februar 2018 um 22:38 geschrieben:
> 
> 
> Hi Stefan,
> 
> >>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> >>> This allows to automatically insert the bcm43438 to the bluetooth
> >>> subsystem instead of relying on patched userspace helpers (hciattach).
> >>> 
> >>> In order to keep a debug UART we need to switch to uart1.
> >>> 
> >>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>> ---
> >>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>> 
> >>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> index cf53436..b7f79f1 100644
> >>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> @@ -131,6 +131,18 @@
> >>> 
> >>> &uart0 {
> >>> 	pinctrl-names = "default";
> >>> -	pinctrl-0 = <&uart0_gpio14>;
> >>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>> +	status = "okay";
> >>> +
> >>> +	bluetooth {
> >>> +		compatible = "brcm,bcm43438-bt";
> >>> +		max-speed = <2000000>;
> >>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>> +	};
> >>> +};
> >> 
> >> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> > 
> > Yes, unload and reload works fine. 
> > 
> >> Meaning we are getting back to the 115200 default baud rate on the UART?
> > 
> > I assume that, because reload works as expected. 
> 
> awesome. That is good news.
> 
> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well?

Currently not 

> If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.

Sure, but not before this weekend.

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

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,

> Marcel Holtmann <marcel@holtmann.org> hat am 25. Februar 2018 um 22:38 geschrieben:
> 
> 
> Hi Stefan,
> 
> >>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> >>> This allows to automatically insert the bcm43438 to the bluetooth
> >>> subsystem instead of relying on patched userspace helpers (hciattach).
> >>> 
> >>> In order to keep a debug UART we need to switch to uart1.
> >>> 
> >>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>> ---
> >>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>> 
> >>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> index cf53436..b7f79f1 100644
> >>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> @@ -131,6 +131,18 @@
> >>> 
> >>> &uart0 {
> >>> 	pinctrl-names = "default";
> >>> -	pinctrl-0 = <&uart0_gpio14>;
> >>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>> +	status = "okay";
> >>> +
> >>> +	bluetooth {
> >>> +		compatible = "brcm,bcm43438-bt";
> >>> +		max-speed = <2000000>;
> >>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>> +	};
> >>> +};
> >> 
> >> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> > 
> > Yes, unload and reload works fine. 
> > 
> >> Meaning we are getting back to the 115200 default baud rate on the UART?
> > 
> > I assume that, because reload works as expected. 
> 
> awesome. That is good news.
> 
> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well?

Currently not 

> If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.

Sure, but not before this weekend.

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

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,

> Marcel Holtmann <marcel@holtmann.org> hat am 25. Februar 2018 um 22:38 geschrieben:
> 
> 
> Hi Stefan,
> 
> >>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> >>> This allows to automatically insert the bcm43438 to the bluetooth
> >>> subsystem instead of relying on patched userspace helpers (hciattach).
> >>> 
> >>> In order to keep a debug UART we need to switch to uart1.
> >>> 
> >>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>> ---
> >>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>> 
> >>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> index cf53436..b7f79f1 100644
> >>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> @@ -131,6 +131,18 @@
> >>> 
> >>> &uart0 {
> >>> 	pinctrl-names = "default";
> >>> -	pinctrl-0 = <&uart0_gpio14>;
> >>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>> +	status = "okay";
> >>> +
> >>> +	bluetooth {
> >>> +		compatible = "brcm,bcm43438-bt";
> >>> +		max-speed = <2000000>;
> >>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>> +	};
> >>> +};
> >> 
> >> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> > 
> > Yes, unload and reload works fine. 
> > 
> >> Meaning we are getting back to the 115200 default baud rate on the UART?
> > 
> > I assume that, because reload works as expected. 
> 
> awesome. That is good news.
> 
> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well?

Currently not 

> If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.

Sure, but not before this weekend.

> 
> Regards
> 
> Marcel
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,

> Marcel Holtmann <marcel@holtmann.org> hat am 25. Februar 2018 um 22:38 geschrieben:
> 
> 
> Hi Stefan,
> 
> >>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> >>> This allows to automatically insert the bcm43438 to the bluetooth
> >>> subsystem instead of relying on patched userspace helpers (hciattach).
> >>> 
> >>> In order to keep a debug UART we need to switch to uart1.
> >>> 
> >>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>> ---
> >>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>> 
> >>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> index cf53436..b7f79f1 100644
> >>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> @@ -131,6 +131,18 @@
> >>> 
> >>> &uart0 {
> >>> 	pinctrl-names = "default";
> >>> -	pinctrl-0 = <&uart0_gpio14>;
> >>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>> +	status = "okay";
> >>> +
> >>> +	bluetooth {
> >>> +		compatible = "brcm,bcm43438-bt";
> >>> +		max-speed = <2000000>;
> >>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>> +	};
> >>> +};
> >> 
> >> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> > 
> > Yes, unload and reload works fine. 
> > 
> >> Meaning we are getting back to the 115200 default baud rate on the UART?
> > 
> > I assume that, because reload works as expected. 
> 
> awesome. That is good news.
> 
> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.

so here comes the bad news. hci_bcm uses gpiod_set_value() which is for interrupt context, but the gpio expander can sleep. So we will get this warning:

[    4.802447] ------------[ cut here ]------------
[    4.802485] WARNING: CPU: 3 PID: 91 at drivers/gpio/gpiolib.c:2986 gpiod_set_value+0x50/0x58
[    4.802489] Modules linked in: hci_uart ac97_bus btbcm snd_pcm_dmaengine bluetooth snd_pcm snd_timer ecdh_generic snd soundcore bcm2835_thermal crc32_arm_ce
[    4.802543] CPU: 3 PID: 91 Comm: kworker/u8:2 Not tainted 4.16.0-rc3-next-20180302-dirty #4
[    4.802547] Hardware name: BCM2835
[    4.802562] Workqueue: events_unbound async_run_entry_fn
[    4.802593] [<c03119a4>] (unwind_backtrace) from [<c030cc24>] (show_stack+0x10/0x14)
[    4.802612] [<c030cc24>] (show_stack) from [<c0d8e9dc>] (dump_stack+0x8c/0xa0)
[    4.802628] [<c0d8e9dc>] (dump_stack) from [<c0343a2c>] (__warn+0xe0/0xf8)
[    4.802640] [<c0343a2c>] (__warn) from [<c0343b5c>] (warn_slowpath_null+0x40/0x48)
[    4.802652] [<c0343b5c>] (warn_slowpath_null) from [<c06d0de0>] (gpiod_set_value+0x50/0x58)
[    4.802693] [<c06d0de0>] (gpiod_set_value) from [<bf0e2e90>] (bcm_gpio_set_shutdown+0xc/0x14 [hci_uart])
[    4.802757] [<bf0e2e90>] (bcm_gpio_set_shutdown [hci_uart]) from [<bf0e2a64>] (bcm_gpio_set_power+0x18/0x140 [hci_uart])
[    4.802806] [<bf0e2a64>] (bcm_gpio_set_power [hci_uart]) from [<bf0e2e4c>] (bcm_serdev_probe+0x64/0x9c [hci_uart])
[    4.802848] [<bf0e2e4c>] (bcm_serdev_probe [hci_uart]) from [<c08f2528>] (driver_probe_device+0x254/0x32c)
[    4.802863] [<c08f2528>] (driver_probe_device) from [<c08f26a4>] (__driver_attach+0xa4/0xa8)
[    4.802878] [<c08f26a4>] (__driver_attach) from [<c08f08b8>] (bus_for_each_dev+0x74/0xb4)
[    4.802895] [<c08f08b8>] (bus_for_each_dev) from [<c0366498>] (async_run_entry_fn+0x44/0x108)
[    4.802910] [<c0366498>] (async_run_entry_fn) from [<c035d594>] (process_one_work+0x200/0x4f8)
[    4.802923] [<c035d594>] (process_one_work) from [<c035e4a8>] (worker_thread+0x4c/0x5d4)
[    4.802938] [<c035e4a8>] (worker_thread) from [<c0363300>] (kthread+0x150/0x158)
[    4.802952] [<c0363300>] (kthread) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
[    4.802957] Exception stack(0xed959fb0 to 0xed959ff8)
[    4.802966] 9fa0:                                     00000000 00000000 00000000 00000000
[    4.802977] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    4.802986] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    4.802993] ---[ end trace b947f9d4c40fa261 ]---

Stefan

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

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,

> Marcel Holtmann <marcel@holtmann.org> hat am 25. Februar 2018 um 22:38 geschrieben:
> 
> 
> Hi Stefan,
> 
> >>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> >>> This allows to automatically insert the bcm43438 to the bluetooth
> >>> subsystem instead of relying on patched userspace helpers (hciattach).
> >>> 
> >>> In order to keep a debug UART we need to switch to uart1.
> >>> 
> >>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>> ---
> >>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>> 
> >>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> index cf53436..b7f79f1 100644
> >>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> @@ -131,6 +131,18 @@
> >>> 
> >>> &uart0 {
> >>> 	pinctrl-names = "default";
> >>> -	pinctrl-0 = <&uart0_gpio14>;
> >>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>> +	status = "okay";
> >>> +
> >>> +	bluetooth {
> >>> +		compatible = "brcm,bcm43438-bt";
> >>> +		max-speed = <2000000>;
> >>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>> +	};
> >>> +};
> >> 
> >> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> > 
> > Yes, unload and reload works fine. 
> > 
> >> Meaning we are getting back to the 115200 default baud rate on the UART?
> > 
> > I assume that, because reload works as expected. 
> 
> awesome. That is good news.
> 
> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.

so here comes the bad news. hci_bcm uses gpiod_set_value() which is for interrupt context, but the gpio expander can sleep. So we will get this warning:

[    4.802447] ------------[ cut here ]------------
[    4.802485] WARNING: CPU: 3 PID: 91 at drivers/gpio/gpiolib.c:2986 gpiod_set_value+0x50/0x58
[    4.802489] Modules linked in: hci_uart ac97_bus btbcm snd_pcm_dmaengine bluetooth snd_pcm snd_timer ecdh_generic snd soundcore bcm2835_thermal crc32_arm_ce
[    4.802543] CPU: 3 PID: 91 Comm: kworker/u8:2 Not tainted 4.16.0-rc3-next-20180302-dirty #4
[    4.802547] Hardware name: BCM2835
[    4.802562] Workqueue: events_unbound async_run_entry_fn
[    4.802593] [<c03119a4>] (unwind_backtrace) from [<c030cc24>] (show_stack+0x10/0x14)
[    4.802612] [<c030cc24>] (show_stack) from [<c0d8e9dc>] (dump_stack+0x8c/0xa0)
[    4.802628] [<c0d8e9dc>] (dump_stack) from [<c0343a2c>] (__warn+0xe0/0xf8)
[    4.802640] [<c0343a2c>] (__warn) from [<c0343b5c>] (warn_slowpath_null+0x40/0x48)
[    4.802652] [<c0343b5c>] (warn_slowpath_null) from [<c06d0de0>] (gpiod_set_value+0x50/0x58)
[    4.802693] [<c06d0de0>] (gpiod_set_value) from [<bf0e2e90>] (bcm_gpio_set_shutdown+0xc/0x14 [hci_uart])
[    4.802757] [<bf0e2e90>] (bcm_gpio_set_shutdown [hci_uart]) from [<bf0e2a64>] (bcm_gpio_set_power+0x18/0x140 [hci_uart])
[    4.802806] [<bf0e2a64>] (bcm_gpio_set_power [hci_uart]) from [<bf0e2e4c>] (bcm_serdev_probe+0x64/0x9c [hci_uart])
[    4.802848] [<bf0e2e4c>] (bcm_serdev_probe [hci_uart]) from [<c08f2528>] (driver_probe_device+0x254/0x32c)
[    4.802863] [<c08f2528>] (driver_probe_device) from [<c08f26a4>] (__driver_attach+0xa4/0xa8)
[    4.802878] [<c08f26a4>] (__driver_attach) from [<c08f08b8>] (bus_for_each_dev+0x74/0xb4)
[    4.802895] [<c08f08b8>] (bus_for_each_dev) from [<c0366498>] (async_run_entry_fn+0x44/0x108)
[    4.802910] [<c0366498>] (async_run_entry_fn) from [<c035d594>] (process_one_work+0x200/0x4f8)
[    4.802923] [<c035d594>] (process_one_work) from [<c035e4a8>] (worker_thread+0x4c/0x5d4)
[    4.802938] [<c035e4a8>] (worker_thread) from [<c0363300>] (kthread+0x150/0x158)
[    4.802952] [<c0363300>] (kthread) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
[    4.802957] Exception stack(0xed959fb0 to 0xed959ff8)
[    4.802966] 9fa0:                                     00000000 00000000 00000000 00000000
[    4.802977] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    4.802986] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    4.802993] ---[ end trace b947f9d4c40fa261 ]---

Stefan

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

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,

> Marcel Holtmann <marcel@holtmann.org> hat am 25. Februar 2018 um 22:38 geschrieben:
> 
> 
> Hi Stefan,
> 
> >>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> >>> This allows to automatically insert the bcm43438 to the bluetooth
> >>> subsystem instead of relying on patched userspace helpers (hciattach).
> >>> 
> >>> In order to keep a debug UART we need to switch to uart1.
> >>> 
> >>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>> ---
> >>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>> 
> >>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> index cf53436..b7f79f1 100644
> >>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> @@ -131,6 +131,18 @@
> >>> 
> >>> &uart0 {
> >>> 	pinctrl-names = "default";
> >>> -	pinctrl-0 = <&uart0_gpio14>;
> >>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>> +	status = "okay";
> >>> +
> >>> +	bluetooth {
> >>> +		compatible = "brcm,bcm43438-bt";
> >>> +		max-speed = <2000000>;
> >>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>> +	};
> >>> +};
> >> 
> >> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> > 
> > Yes, unload and reload works fine. 
> > 
> >> Meaning we are getting back to the 115200 default baud rate on the UART?
> > 
> > I assume that, because reload works as expected. 
> 
> awesome. That is good news.
> 
> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.

so here comes the bad news. hci_bcm uses gpiod_set_value() which is for interrupt context, but the gpio expander can sleep. So we will get this warning:

[    4.802447] ------------[ cut here ]------------
[    4.802485] WARNING: CPU: 3 PID: 91 at drivers/gpio/gpiolib.c:2986 gpiod_set_value+0x50/0x58
[    4.802489] Modules linked in: hci_uart ac97_bus btbcm snd_pcm_dmaengine bluetooth snd_pcm snd_timer ecdh_generic snd soundcore bcm2835_thermal crc32_arm_ce
[    4.802543] CPU: 3 PID: 91 Comm: kworker/u8:2 Not tainted 4.16.0-rc3-next-20180302-dirty #4
[    4.802547] Hardware name: BCM2835
[    4.802562] Workqueue: events_unbound async_run_entry_fn
[    4.802593] [<c03119a4>] (unwind_backtrace) from [<c030cc24>] (show_stack+0x10/0x14)
[    4.802612] [<c030cc24>] (show_stack) from [<c0d8e9dc>] (dump_stack+0x8c/0xa0)
[    4.802628] [<c0d8e9dc>] (dump_stack) from [<c0343a2c>] (__warn+0xe0/0xf8)
[    4.802640] [<c0343a2c>] (__warn) from [<c0343b5c>] (warn_slowpath_null+0x40/0x48)
[    4.802652] [<c0343b5c>] (warn_slowpath_null) from [<c06d0de0>] (gpiod_set_value+0x50/0x58)
[    4.802693] [<c06d0de0>] (gpiod_set_value) from [<bf0e2e90>] (bcm_gpio_set_shutdown+0xc/0x14 [hci_uart])
[    4.802757] [<bf0e2e90>] (bcm_gpio_set_shutdown [hci_uart]) from [<bf0e2a64>] (bcm_gpio_set_power+0x18/0x140 [hci_uart])
[    4.802806] [<bf0e2a64>] (bcm_gpio_set_power [hci_uart]) from [<bf0e2e4c>] (bcm_serdev_probe+0x64/0x9c [hci_uart])
[    4.802848] [<bf0e2e4c>] (bcm_serdev_probe [hci_uart]) from [<c08f2528>] (driver_probe_device+0x254/0x32c)
[    4.802863] [<c08f2528>] (driver_probe_device) from [<c08f26a4>] (__driver_attach+0xa4/0xa8)
[    4.802878] [<c08f26a4>] (__driver_attach) from [<c08f08b8>] (bus_for_each_dev+0x74/0xb4)
[    4.802895] [<c08f08b8>] (bus_for_each_dev) from [<c0366498>] (async_run_entry_fn+0x44/0x108)
[    4.802910] [<c0366498>] (async_run_entry_fn) from [<c035d594>] (process_one_work+0x200/0x4f8)
[    4.802923] [<c035d594>] (process_one_work) from [<c035e4a8>] (worker_thread+0x4c/0x5d4)
[    4.802938] [<c035e4a8>] (worker_thread) from [<c0363300>] (kthread+0x150/0x158)
[    4.802952] [<c0363300>] (kthread) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
[    4.802957] Exception stack(0xed959fb0 to 0xed959ff8)
[    4.802966] 9fa0:                                     00000000 00000000 00000000 00000000
[    4.802977] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    4.802986] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[    4.802993] ---[ end trace b947f9d4c40fa261 ]---

Stefan

> 
> Regards
> 
> Marcel
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>> 
>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>> 
>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>> ---
>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>> 
>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> index cf53436..b7f79f1 100644
>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> @@ -131,6 +131,18 @@
>>>>> 
>>>>> &uart0 {
>>>>> 	pinctrl-names = "default";
>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>> +	status = "okay";
>>>>> +
>>>>> +	bluetooth {
>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>> +		max-speed = <2000000>;
>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>> +	};
>>>>> +};
>>>> 
>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>> 
>>> Yes, unload and reload works fine. 
>>> 
>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>> 
>>> I assume that, because reload works as expected. 
>> 
>> awesome. That is good news.
>> 
>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
> 
> so here comes the bad news. hci_bcm uses gpiod_set_value() which is for interrupt context, but the gpio expander can sleep. So we will get this warning:
> 
> [    4.802447] ------------[ cut here ]------------
> [    4.802485] WARNING: CPU: 3 PID: 91 at drivers/gpio/gpiolib.c:2986 gpiod_set_value+0x50/0x58
> [    4.802489] Modules linked in: hci_uart ac97_bus btbcm snd_pcm_dmaengine bluetooth snd_pcm snd_timer ecdh_generic snd soundcore bcm2835_thermal crc32_arm_ce
> [    4.802543] CPU: 3 PID: 91 Comm: kworker/u8:2 Not tainted 4.16.0-rc3-next-20180302-dirty #4
> [    4.802547] Hardware name: BCM2835
> [    4.802562] Workqueue: events_unbound async_run_entry_fn
> [    4.802593] [<c03119a4>] (unwind_backtrace) from [<c030cc24>] (show_stack+0x10/0x14)
> [    4.802612] [<c030cc24>] (show_stack) from [<c0d8e9dc>] (dump_stack+0x8c/0xa0)
> [    4.802628] [<c0d8e9dc>] (dump_stack) from [<c0343a2c>] (__warn+0xe0/0xf8)
> [    4.802640] [<c0343a2c>] (__warn) from [<c0343b5c>] (warn_slowpath_null+0x40/0x48)
> [    4.802652] [<c0343b5c>] (warn_slowpath_null) from [<c06d0de0>] (gpiod_set_value+0x50/0x58)
> [    4.802693] [<c06d0de0>] (gpiod_set_value) from [<bf0e2e90>] (bcm_gpio_set_shutdown+0xc/0x14 [hci_uart])
> [    4.802757] [<bf0e2e90>] (bcm_gpio_set_shutdown [hci_uart]) from [<bf0e2a64>] (bcm_gpio_set_power+0x18/0x140 [hci_uart])
> [    4.802806] [<bf0e2a64>] (bcm_gpio_set_power [hci_uart]) from [<bf0e2e4c>] (bcm_serdev_probe+0x64/0x9c [hci_uart])
> [    4.802848] [<bf0e2e4c>] (bcm_serdev_probe [hci_uart]) from [<c08f2528>] (driver_probe_device+0x254/0x32c)
> [    4.802863] [<c08f2528>] (driver_probe_device) from [<c08f26a4>] (__driver_attach+0xa4/0xa8)
> [    4.802878] [<c08f26a4>] (__driver_attach) from [<c08f08b8>] (bus_for_each_dev+0x74/0xb4)
> [    4.802895] [<c08f08b8>] (bus_for_each_dev) from [<c0366498>] (async_run_entry_fn+0x44/0x108)
> [    4.802910] [<c0366498>] (async_run_entry_fn) from [<c035d594>] (process_one_work+0x200/0x4f8)
> [    4.802923] [<c035d594>] (process_one_work) from [<c035e4a8>] (worker_thread+0x4c/0x5d4)
> [    4.802938] [<c035e4a8>] (worker_thread) from [<c0363300>] (kthread+0x150/0x158)
> [    4.802952] [<c0363300>] (kthread) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
> [    4.802957] Exception stack(0xed959fb0 to 0xed959ff8)
> [    4.802966] 9fa0:                                     00000000 00000000 00000000 00000000
> [    4.802977] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [    4.802986] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [    4.802993] ---[ end trace b947f9d4c40fa261 ]—

that is weird since we should be either in a probe context or in hdev->open context and both can sleep as far as I know.

Regards

Marcel


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

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>> 
>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>> 
>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>> ---
>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>> 
>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> index cf53436..b7f79f1 100644
>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> @@ -131,6 +131,18 @@
>>>>> 
>>>>> &uart0 {
>>>>> 	pinctrl-names = "default";
>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>> +	status = "okay";
>>>>> +
>>>>> +	bluetooth {
>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>> +		max-speed = <2000000>;
>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>> +	};
>>>>> +};
>>>> 
>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>> 
>>> Yes, unload and reload works fine. 
>>> 
>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>> 
>>> I assume that, because reload works as expected. 
>> 
>> awesome. That is good news.
>> 
>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
> 
> so here comes the bad news. hci_bcm uses gpiod_set_value() which is for interrupt context, but the gpio expander can sleep. So we will get this warning:
> 
> [    4.802447] ------------[ cut here ]------------
> [    4.802485] WARNING: CPU: 3 PID: 91 at drivers/gpio/gpiolib.c:2986 gpiod_set_value+0x50/0x58
> [    4.802489] Modules linked in: hci_uart ac97_bus btbcm snd_pcm_dmaengine bluetooth snd_pcm snd_timer ecdh_generic snd soundcore bcm2835_thermal crc32_arm_ce
> [    4.802543] CPU: 3 PID: 91 Comm: kworker/u8:2 Not tainted 4.16.0-rc3-next-20180302-dirty #4
> [    4.802547] Hardware name: BCM2835
> [    4.802562] Workqueue: events_unbound async_run_entry_fn
> [    4.802593] [<c03119a4>] (unwind_backtrace) from [<c030cc24>] (show_stack+0x10/0x14)
> [    4.802612] [<c030cc24>] (show_stack) from [<c0d8e9dc>] (dump_stack+0x8c/0xa0)
> [    4.802628] [<c0d8e9dc>] (dump_stack) from [<c0343a2c>] (__warn+0xe0/0xf8)
> [    4.802640] [<c0343a2c>] (__warn) from [<c0343b5c>] (warn_slowpath_null+0x40/0x48)
> [    4.802652] [<c0343b5c>] (warn_slowpath_null) from [<c06d0de0>] (gpiod_set_value+0x50/0x58)
> [    4.802693] [<c06d0de0>] (gpiod_set_value) from [<bf0e2e90>] (bcm_gpio_set_shutdown+0xc/0x14 [hci_uart])
> [    4.802757] [<bf0e2e90>] (bcm_gpio_set_shutdown [hci_uart]) from [<bf0e2a64>] (bcm_gpio_set_power+0x18/0x140 [hci_uart])
> [    4.802806] [<bf0e2a64>] (bcm_gpio_set_power [hci_uart]) from [<bf0e2e4c>] (bcm_serdev_probe+0x64/0x9c [hci_uart])
> [    4.802848] [<bf0e2e4c>] (bcm_serdev_probe [hci_uart]) from [<c08f2528>] (driver_probe_device+0x254/0x32c)
> [    4.802863] [<c08f2528>] (driver_probe_device) from [<c08f26a4>] (__driver_attach+0xa4/0xa8)
> [    4.802878] [<c08f26a4>] (__driver_attach) from [<c08f08b8>] (bus_for_each_dev+0x74/0xb4)
> [    4.802895] [<c08f08b8>] (bus_for_each_dev) from [<c0366498>] (async_run_entry_fn+0x44/0x108)
> [    4.802910] [<c0366498>] (async_run_entry_fn) from [<c035d594>] (process_one_work+0x200/0x4f8)
> [    4.802923] [<c035d594>] (process_one_work) from [<c035e4a8>] (worker_thread+0x4c/0x5d4)
> [    4.802938] [<c035e4a8>] (worker_thread) from [<c0363300>] (kthread+0x150/0x158)
> [    4.802952] [<c0363300>] (kthread) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
> [    4.802957] Exception stack(0xed959fb0 to 0xed959ff8)
> [    4.802966] 9fa0:                                     00000000 00000000 00000000 00000000
> [    4.802977] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [    4.802986] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [    4.802993] ---[ end trace b947f9d4c40fa261 ]—

that is weird since we should be either in a probe context or in hdev->open context and both can sleep as far as I know.

Regards

Marcel

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>> 
>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>> 
>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>> ---
>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>> 
>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> index cf53436..b7f79f1 100644
>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> @@ -131,6 +131,18 @@
>>>>> 
>>>>> &uart0 {
>>>>> 	pinctrl-names = "default";
>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>> +	status = "okay";
>>>>> +
>>>>> +	bluetooth {
>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>> +		max-speed = <2000000>;
>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>> +	};
>>>>> +};
>>>> 
>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>> 
>>> Yes, unload and reload works fine. 
>>> 
>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>> 
>>> I assume that, because reload works as expected. 
>> 
>> awesome. That is good news.
>> 
>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
> 
> so here comes the bad news. hci_bcm uses gpiod_set_value() which is for interrupt context, but the gpio expander can sleep. So we will get this warning:
> 
> [    4.802447] ------------[ cut here ]------------
> [    4.802485] WARNING: CPU: 3 PID: 91 at drivers/gpio/gpiolib.c:2986 gpiod_set_value+0x50/0x58
> [    4.802489] Modules linked in: hci_uart ac97_bus btbcm snd_pcm_dmaengine bluetooth snd_pcm snd_timer ecdh_generic snd soundcore bcm2835_thermal crc32_arm_ce
> [    4.802543] CPU: 3 PID: 91 Comm: kworker/u8:2 Not tainted 4.16.0-rc3-next-20180302-dirty #4
> [    4.802547] Hardware name: BCM2835
> [    4.802562] Workqueue: events_unbound async_run_entry_fn
> [    4.802593] [<c03119a4>] (unwind_backtrace) from [<c030cc24>] (show_stack+0x10/0x14)
> [    4.802612] [<c030cc24>] (show_stack) from [<c0d8e9dc>] (dump_stack+0x8c/0xa0)
> [    4.802628] [<c0d8e9dc>] (dump_stack) from [<c0343a2c>] (__warn+0xe0/0xf8)
> [    4.802640] [<c0343a2c>] (__warn) from [<c0343b5c>] (warn_slowpath_null+0x40/0x48)
> [    4.802652] [<c0343b5c>] (warn_slowpath_null) from [<c06d0de0>] (gpiod_set_value+0x50/0x58)
> [    4.802693] [<c06d0de0>] (gpiod_set_value) from [<bf0e2e90>] (bcm_gpio_set_shutdown+0xc/0x14 [hci_uart])
> [    4.802757] [<bf0e2e90>] (bcm_gpio_set_shutdown [hci_uart]) from [<bf0e2a64>] (bcm_gpio_set_power+0x18/0x140 [hci_uart])
> [    4.802806] [<bf0e2a64>] (bcm_gpio_set_power [hci_uart]) from [<bf0e2e4c>] (bcm_serdev_probe+0x64/0x9c [hci_uart])
> [    4.802848] [<bf0e2e4c>] (bcm_serdev_probe [hci_uart]) from [<c08f2528>] (driver_probe_device+0x254/0x32c)
> [    4.802863] [<c08f2528>] (driver_probe_device) from [<c08f26a4>] (__driver_attach+0xa4/0xa8)
> [    4.802878] [<c08f26a4>] (__driver_attach) from [<c08f08b8>] (bus_for_each_dev+0x74/0xb4)
> [    4.802895] [<c08f08b8>] (bus_for_each_dev) from [<c0366498>] (async_run_entry_fn+0x44/0x108)
> [    4.802910] [<c0366498>] (async_run_entry_fn) from [<c035d594>] (process_one_work+0x200/0x4f8)
> [    4.802923] [<c035d594>] (process_one_work) from [<c035e4a8>] (worker_thread+0x4c/0x5d4)
> [    4.802938] [<c035e4a8>] (worker_thread) from [<c0363300>] (kthread+0x150/0x158)
> [    4.802952] [<c0363300>] (kthread) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
> [    4.802957] Exception stack(0xed959fb0 to 0xed959ff8)
> [    4.802966] 9fa0:                                     00000000 00000000 00000000 00000000
> [    4.802977] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [    4.802986] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> [    4.802993] ---[ end trace b947f9d4c40fa261 ]?

that is weird since we should be either in a probe context or in hdev->open context and both can sleep as far as I know.

Regards

Marcel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,

> Marcel Holtmann <marcel@holtmann.org> hat am 5. März 2018 um 06:19 geschrieben:
> 
> 
> Hi Stefan,
> 
> >>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> >>>>> This allows to automatically insert the bcm43438 to the bluetooth
> >>>>> subsystem instead of relying on patched userspace helpers (hciattach).
> >>>>> 
> >>>>> In order to keep a debug UART we need to switch to uart1.
> >>>>> 
> >>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>>>> ---
> >>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>>>> 
> >>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>> index cf53436..b7f79f1 100644
> >>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>> @@ -131,6 +131,18 @@
> >>>>> 
> >>>>> &uart0 {
> >>>>> 	pinctrl-names = "default";
> >>>>> -	pinctrl-0 = <&uart0_gpio14>;
> >>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>>>> +	status = "okay";
> >>>>> +
> >>>>> +	bluetooth {
> >>>>> +		compatible = "brcm,bcm43438-bt";
> >>>>> +		max-speed = <2000000>;
> >>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>>>> +	};
> >>>>> +};
> >>>> 
> >>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> >>> 
> >>> Yes, unload and reload works fine. 
> >>> 
> >>>> Meaning we are getting back to the 115200 default baud rate on the UART?
> >>> 
> >>> I assume that, because reload works as expected. 
> >> 
> >> awesome. That is good news.
> >> 
> >> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
> > 
> > so here comes the bad news. hci_bcm uses gpiod_set_value() which is for interrupt context, but the gpio expander can sleep. So we will get this warning:
> > 
> > [    4.802447] ------------[ cut here ]------------
> > [    4.802485] WARNING: CPU: 3 PID: 91 at drivers/gpio/gpiolib.c:2986 gpiod_set_value+0x50/0x58
> > [    4.802489] Modules linked in: hci_uart ac97_bus btbcm snd_pcm_dmaengine bluetooth snd_pcm snd_timer ecdh_generic snd soundcore bcm2835_thermal crc32_arm_ce
> > [    4.802543] CPU: 3 PID: 91 Comm: kworker/u8:2 Not tainted 4.16.0-rc3-next-20180302-dirty #4
> > [    4.802547] Hardware name: BCM2835
> > [    4.802562] Workqueue: events_unbound async_run_entry_fn
> > [    4.802593] [<c03119a4>] (unwind_backtrace) from [<c030cc24>] (show_stack+0x10/0x14)
> > [    4.802612] [<c030cc24>] (show_stack) from [<c0d8e9dc>] (dump_stack+0x8c/0xa0)
> > [    4.802628] [<c0d8e9dc>] (dump_stack) from [<c0343a2c>] (__warn+0xe0/0xf8)
> > [    4.802640] [<c0343a2c>] (__warn) from [<c0343b5c>] (warn_slowpath_null+0x40/0x48)
> > [    4.802652] [<c0343b5c>] (warn_slowpath_null) from [<c06d0de0>] (gpiod_set_value+0x50/0x58)
> > [    4.802693] [<c06d0de0>] (gpiod_set_value) from [<bf0e2e90>] (bcm_gpio_set_shutdown+0xc/0x14 [hci_uart])
> > [    4.802757] [<bf0e2e90>] (bcm_gpio_set_shutdown [hci_uart]) from [<bf0e2a64>] (bcm_gpio_set_power+0x18/0x140 [hci_uart])
> > [    4.802806] [<bf0e2a64>] (bcm_gpio_set_power [hci_uart]) from [<bf0e2e4c>] (bcm_serdev_probe+0x64/0x9c [hci_uart])
> > [    4.802848] [<bf0e2e4c>] (bcm_serdev_probe [hci_uart]) from [<c08f2528>] (driver_probe_device+0x254/0x32c)
> > [    4.802863] [<c08f2528>] (driver_probe_device) from [<c08f26a4>] (__driver_attach+0xa4/0xa8)
> > [    4.802878] [<c08f26a4>] (__driver_attach) from [<c08f08b8>] (bus_for_each_dev+0x74/0xb4)
> > [    4.802895] [<c08f08b8>] (bus_for_each_dev) from [<c0366498>] (async_run_entry_fn+0x44/0x108)
> > [    4.802910] [<c0366498>] (async_run_entry_fn) from [<c035d594>] (process_one_work+0x200/0x4f8)
> > [    4.802923] [<c035d594>] (process_one_work) from [<c035e4a8>] (worker_thread+0x4c/0x5d4)
> > [    4.802938] [<c035e4a8>] (worker_thread) from [<c0363300>] (kthread+0x150/0x158)
> > [    4.802952] [<c0363300>] (kthread) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
> > [    4.802957] Exception stack(0xed959fb0 to 0xed959ff8)
> > [    4.802966] 9fa0:                                     00000000 00000000 00000000 00000000
> > [    4.802977] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > [    4.802986] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> > [    4.802993] ---[ end trace b947f9d4c40fa261 ]—
> 
> that is weird since we should be either in a probe context or in hdev->open context and both can sleep as far as I know.

okay in this case we can replace gpiod_set_value with gpiod_set_value_cansleep.

Stefan

> 
> Regards
> 
> Marcel
>

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

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,

> Marcel Holtmann <marcel@holtmann.org> hat am 5. M=C3=A4rz 2018 um 06:19 g=
eschrieben:
>=20
>=20
> Hi Stefan,
>=20
> >>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/t=
tyAMA0).
> >>>>> This allows to automatically insert the bcm43438 to the bluetooth
> >>>>> subsystem instead of relying on patched userspace helpers (hciattac=
h).
> >>>>>=20
> >>>>> In order to keep a debug UART we need to switch to uart1.
> >>>>>=20
> >>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>>>> ---
> >>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>>>>=20
> >>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/bo=
ot/dts/bcm2835-rpi-zero-w.dts
> >>>>> index cf53436..b7f79f1 100644
> >>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>> @@ -131,6 +131,18 @@
> >>>>>=20
> >>>>> &uart0 {
> >>>>> =09pinctrl-names =3D "default";
> >>>>> -=09pinctrl-0 =3D <&uart0_gpio14>;
> >>>>> +=09pinctrl-0 =3D <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>>>> +=09status =3D "okay";
> >>>>> +
> >>>>> +=09bluetooth {
> >>>>> +=09=09compatible =3D "brcm,bcm43438-bt";
> >>>>> +=09=09max-speed =3D <2000000>;
> >>>>> +=09=09shutdown-gpios =3D <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>>>> +=09};
> >>>>> +};
> >>>>=20
> >>>> is the shutdown GPIO working as expected with this hardware. So even=
 module unload and reload works fine?
> >>>=20
> >>> Yes, unload and reload works fine.=20
> >>>=20
> >>>> Meaning we are getting back to the 115200 default baud rate on the U=
ART?
> >>>=20
> >>> I assume that, because reload works as expected.=20
> >>=20
> >> awesome. That is good news.
> >>=20
> >> Since you said that the GPIO expander driver for the RPi 3 has been ac=
cepted, did you test it there as well? If so, then it would be good to get =
a patch that also provides shutdown-gpios for RPi 3.
> >=20
> > so here comes the bad news. hci_bcm uses gpiod_set_value() which is for=
 interrupt context, but the gpio expander can sleep. So we will get this wa=
rning:
> >=20
> > [    4.802447] ------------[ cut here ]------------
> > [    4.802485] WARNING: CPU: 3 PID: 91 at drivers/gpio/gpiolib.c:2986 g=
piod_set_value+0x50/0x58
> > [    4.802489] Modules linked in: hci_uart ac97_bus btbcm snd_pcm_dmaen=
gine bluetooth snd_pcm snd_timer ecdh_generic snd soundcore bcm2835_thermal=
 crc32_arm_ce
> > [    4.802543] CPU: 3 PID: 91 Comm: kworker/u8:2 Not tainted 4.16.0-rc3=
-next-20180302-dirty #4
> > [    4.802547] Hardware name: BCM2835
> > [    4.802562] Workqueue: events_unbound async_run_entry_fn
> > [    4.802593] [<c03119a4>] (unwind_backtrace) from [<c030cc24>] (show_=
stack+0x10/0x14)
> > [    4.802612] [<c030cc24>] (show_stack) from [<c0d8e9dc>] (dump_stack+=
0x8c/0xa0)
> > [    4.802628] [<c0d8e9dc>] (dump_stack) from [<c0343a2c>] (__warn+0xe0=
/0xf8)
> > [    4.802640] [<c0343a2c>] (__warn) from [<c0343b5c>] (warn_slowpath_n=
ull+0x40/0x48)
> > [    4.802652] [<c0343b5c>] (warn_slowpath_null) from [<c06d0de0>] (gpi=
od_set_value+0x50/0x58)
> > [    4.802693] [<c06d0de0>] (gpiod_set_value) from [<bf0e2e90>] (bcm_gp=
io_set_shutdown+0xc/0x14 [hci_uart])
> > [    4.802757] [<bf0e2e90>] (bcm_gpio_set_shutdown [hci_uart]) from [<b=
f0e2a64>] (bcm_gpio_set_power+0x18/0x140 [hci_uart])
> > [    4.802806] [<bf0e2a64>] (bcm_gpio_set_power [hci_uart]) from [<bf0e=
2e4c>] (bcm_serdev_probe+0x64/0x9c [hci_uart])
> > [    4.802848] [<bf0e2e4c>] (bcm_serdev_probe [hci_uart]) from [<c08f25=
28>] (driver_probe_device+0x254/0x32c)
> > [    4.802863] [<c08f2528>] (driver_probe_device) from [<c08f26a4>] (__=
driver_attach+0xa4/0xa8)
> > [    4.802878] [<c08f26a4>] (__driver_attach) from [<c08f08b8>] (bus_fo=
r_each_dev+0x74/0xb4)
> > [    4.802895] [<c08f08b8>] (bus_for_each_dev) from [<c0366498>] (async=
_run_entry_fn+0x44/0x108)
> > [    4.802910] [<c0366498>] (async_run_entry_fn) from [<c035d594>] (pro=
cess_one_work+0x200/0x4f8)
> > [    4.802923] [<c035d594>] (process_one_work) from [<c035e4a8>] (worke=
r_thread+0x4c/0x5d4)
> > [    4.802938] [<c035e4a8>] (worker_thread) from [<c0363300>] (kthread+=
0x150/0x158)
> > [    4.802952] [<c0363300>] (kthread) from [<c03010e8>] (ret_from_fork+=
0x14/0x2c)
> > [    4.802957] Exception stack(0xed959fb0 to 0xed959ff8)
> > [    4.802966] 9fa0:                                     00000000 00000=
000 00000000 00000000
> > [    4.802977] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000=
000 00000000 00000000
> > [    4.802986] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000=
000
> > [    4.802993] ---[ end trace b947f9d4c40fa261 ]=E2=80=94
>=20
> that is weird since we should be either in a probe context or in hdev->op=
en context and both can sleep as far as I know.

okay in this case we can replace gpiod_set_value with gpiod_set_value_cansl=
eep.

Stefan

>=20
> Regards
>=20
> Marcel
>

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,

> Marcel Holtmann <marcel@holtmann.org> hat am 5. M?rz 2018 um 06:19 geschrieben:
> 
> 
> Hi Stefan,
> 
> >>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> >>>>> This allows to automatically insert the bcm43438 to the bluetooth
> >>>>> subsystem instead of relying on patched userspace helpers (hciattach).
> >>>>> 
> >>>>> In order to keep a debug UART we need to switch to uart1.
> >>>>> 
> >>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>>>> ---
> >>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>>>> 
> >>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>> index cf53436..b7f79f1 100644
> >>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>> @@ -131,6 +131,18 @@
> >>>>> 
> >>>>> &uart0 {
> >>>>> 	pinctrl-names = "default";
> >>>>> -	pinctrl-0 = <&uart0_gpio14>;
> >>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>>>> +	status = "okay";
> >>>>> +
> >>>>> +	bluetooth {
> >>>>> +		compatible = "brcm,bcm43438-bt";
> >>>>> +		max-speed = <2000000>;
> >>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>>>> +	};
> >>>>> +};
> >>>> 
> >>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> >>> 
> >>> Yes, unload and reload works fine. 
> >>> 
> >>>> Meaning we are getting back to the 115200 default baud rate on the UART?
> >>> 
> >>> I assume that, because reload works as expected. 
> >> 
> >> awesome. That is good news.
> >> 
> >> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
> > 
> > so here comes the bad news. hci_bcm uses gpiod_set_value() which is for interrupt context, but the gpio expander can sleep. So we will get this warning:
> > 
> > [    4.802447] ------------[ cut here ]------------
> > [    4.802485] WARNING: CPU: 3 PID: 91 at drivers/gpio/gpiolib.c:2986 gpiod_set_value+0x50/0x58
> > [    4.802489] Modules linked in: hci_uart ac97_bus btbcm snd_pcm_dmaengine bluetooth snd_pcm snd_timer ecdh_generic snd soundcore bcm2835_thermal crc32_arm_ce
> > [    4.802543] CPU: 3 PID: 91 Comm: kworker/u8:2 Not tainted 4.16.0-rc3-next-20180302-dirty #4
> > [    4.802547] Hardware name: BCM2835
> > [    4.802562] Workqueue: events_unbound async_run_entry_fn
> > [    4.802593] [<c03119a4>] (unwind_backtrace) from [<c030cc24>] (show_stack+0x10/0x14)
> > [    4.802612] [<c030cc24>] (show_stack) from [<c0d8e9dc>] (dump_stack+0x8c/0xa0)
> > [    4.802628] [<c0d8e9dc>] (dump_stack) from [<c0343a2c>] (__warn+0xe0/0xf8)
> > [    4.802640] [<c0343a2c>] (__warn) from [<c0343b5c>] (warn_slowpath_null+0x40/0x48)
> > [    4.802652] [<c0343b5c>] (warn_slowpath_null) from [<c06d0de0>] (gpiod_set_value+0x50/0x58)
> > [    4.802693] [<c06d0de0>] (gpiod_set_value) from [<bf0e2e90>] (bcm_gpio_set_shutdown+0xc/0x14 [hci_uart])
> > [    4.802757] [<bf0e2e90>] (bcm_gpio_set_shutdown [hci_uart]) from [<bf0e2a64>] (bcm_gpio_set_power+0x18/0x140 [hci_uart])
> > [    4.802806] [<bf0e2a64>] (bcm_gpio_set_power [hci_uart]) from [<bf0e2e4c>] (bcm_serdev_probe+0x64/0x9c [hci_uart])
> > [    4.802848] [<bf0e2e4c>] (bcm_serdev_probe [hci_uart]) from [<c08f2528>] (driver_probe_device+0x254/0x32c)
> > [    4.802863] [<c08f2528>] (driver_probe_device) from [<c08f26a4>] (__driver_attach+0xa4/0xa8)
> > [    4.802878] [<c08f26a4>] (__driver_attach) from [<c08f08b8>] (bus_for_each_dev+0x74/0xb4)
> > [    4.802895] [<c08f08b8>] (bus_for_each_dev) from [<c0366498>] (async_run_entry_fn+0x44/0x108)
> > [    4.802910] [<c0366498>] (async_run_entry_fn) from [<c035d594>] (process_one_work+0x200/0x4f8)
> > [    4.802923] [<c035d594>] (process_one_work) from [<c035e4a8>] (worker_thread+0x4c/0x5d4)
> > [    4.802938] [<c035e4a8>] (worker_thread) from [<c0363300>] (kthread+0x150/0x158)
> > [    4.802952] [<c0363300>] (kthread) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
> > [    4.802957] Exception stack(0xed959fb0 to 0xed959ff8)
> > [    4.802966] 9fa0:                                     00000000 00000000 00000000 00000000
> > [    4.802977] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > [    4.802986] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> > [    4.802993] ---[ end trace b947f9d4c40fa261 ]?
> 
> that is weird since we should be either in a probe context or in hdev->open context and both can sleep as far as I know.

okay in this case we can replace gpiod_set_value with gpiod_set_value_cansleep.

Stefan

> 
> Regards
> 
> Marcel
>

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>> 
>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>> 
>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>> 
>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> index cf53436..b7f79f1 100644
>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> @@ -131,6 +131,18 @@
>>>>>>> 
>>>>>>> &uart0 {
>>>>>>> 	pinctrl-names = "default";
>>>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>> +	status = "okay";
>>>>>>> +
>>>>>>> +	bluetooth {
>>>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>>>> +		max-speed = <2000000>;
>>>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>> +	};
>>>>>>> +};
>>>>>> 
>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>> 
>>>>> Yes, unload and reload works fine. 
>>>>> 
>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>> 
>>>>> I assume that, because reload works as expected. 
>>>> 
>>>> awesome. That is good news.
>>>> 
>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>> 
>>> so here comes the bad news. hci_bcm uses gpiod_set_value() which is for interrupt context, but the gpio expander can sleep. So we will get this warning:
>>> 
>>> [    4.802447] ------------[ cut here ]------------
>>> [    4.802485] WARNING: CPU: 3 PID: 91 at drivers/gpio/gpiolib.c:2986 gpiod_set_value+0x50/0x58
>>> [    4.802489] Modules linked in: hci_uart ac97_bus btbcm snd_pcm_dmaengine bluetooth snd_pcm snd_timer ecdh_generic snd soundcore bcm2835_thermal crc32_arm_ce
>>> [    4.802543] CPU: 3 PID: 91 Comm: kworker/u8:2 Not tainted 4.16.0-rc3-next-20180302-dirty #4
>>> [    4.802547] Hardware name: BCM2835
>>> [    4.802562] Workqueue: events_unbound async_run_entry_fn
>>> [    4.802593] [<c03119a4>] (unwind_backtrace) from [<c030cc24>] (show_stack+0x10/0x14)
>>> [    4.802612] [<c030cc24>] (show_stack) from [<c0d8e9dc>] (dump_stack+0x8c/0xa0)
>>> [    4.802628] [<c0d8e9dc>] (dump_stack) from [<c0343a2c>] (__warn+0xe0/0xf8)
>>> [    4.802640] [<c0343a2c>] (__warn) from [<c0343b5c>] (warn_slowpath_null+0x40/0x48)
>>> [    4.802652] [<c0343b5c>] (warn_slowpath_null) from [<c06d0de0>] (gpiod_set_value+0x50/0x58)
>>> [    4.802693] [<c06d0de0>] (gpiod_set_value) from [<bf0e2e90>] (bcm_gpio_set_shutdown+0xc/0x14 [hci_uart])
>>> [    4.802757] [<bf0e2e90>] (bcm_gpio_set_shutdown [hci_uart]) from [<bf0e2a64>] (bcm_gpio_set_power+0x18/0x140 [hci_uart])
>>> [    4.802806] [<bf0e2a64>] (bcm_gpio_set_power [hci_uart]) from [<bf0e2e4c>] (bcm_serdev_probe+0x64/0x9c [hci_uart])
>>> [    4.802848] [<bf0e2e4c>] (bcm_serdev_probe [hci_uart]) from [<c08f2528>] (driver_probe_device+0x254/0x32c)
>>> [    4.802863] [<c08f2528>] (driver_probe_device) from [<c08f26a4>] (__driver_attach+0xa4/0xa8)
>>> [    4.802878] [<c08f26a4>] (__driver_attach) from [<c08f08b8>] (bus_for_each_dev+0x74/0xb4)
>>> [    4.802895] [<c08f08b8>] (bus_for_each_dev) from [<c0366498>] (async_run_entry_fn+0x44/0x108)
>>> [    4.802910] [<c0366498>] (async_run_entry_fn) from [<c035d594>] (process_one_work+0x200/0x4f8)
>>> [    4.802923] [<c035d594>] (process_one_work) from [<c035e4a8>] (worker_thread+0x4c/0x5d4)
>>> [    4.802938] [<c035e4a8>] (worker_thread) from [<c0363300>] (kthread+0x150/0x158)
>>> [    4.802952] [<c0363300>] (kthread) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
>>> [    4.802957] Exception stack(0xed959fb0 to 0xed959ff8)
>>> [    4.802966] 9fa0:                                     00000000 00000000 00000000 00000000
>>> [    4.802977] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>>> [    4.802986] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
>>> [    4.802993] ---[ end trace b947f9d4c40fa261 ]—
>> 
>> that is weird since we should be either in a probe context or in hdev->open context and both can sleep as far as I know.
> 
> okay in this case we can replace gpiod_set_value with gpiod_set_value_cansleep.

if you do that, does it work for you on both the RPi 3 and Zero W?

Regards

Marcel


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

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>> 
>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>> 
>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>> 
>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> index cf53436..b7f79f1 100644
>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> @@ -131,6 +131,18 @@
>>>>>>> 
>>>>>>> &uart0 {
>>>>>>> 	pinctrl-names = "default";
>>>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>> +	status = "okay";
>>>>>>> +
>>>>>>> +	bluetooth {
>>>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>>>> +		max-speed = <2000000>;
>>>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>> +	};
>>>>>>> +};
>>>>>> 
>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>> 
>>>>> Yes, unload and reload works fine. 
>>>>> 
>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>> 
>>>>> I assume that, because reload works as expected. 
>>>> 
>>>> awesome. That is good news.
>>>> 
>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>> 
>>> so here comes the bad news. hci_bcm uses gpiod_set_value() which is for interrupt context, but the gpio expander can sleep. So we will get this warning:
>>> 
>>> [    4.802447] ------------[ cut here ]------------
>>> [    4.802485] WARNING: CPU: 3 PID: 91 at drivers/gpio/gpiolib.c:2986 gpiod_set_value+0x50/0x58
>>> [    4.802489] Modules linked in: hci_uart ac97_bus btbcm snd_pcm_dmaengine bluetooth snd_pcm snd_timer ecdh_generic snd soundcore bcm2835_thermal crc32_arm_ce
>>> [    4.802543] CPU: 3 PID: 91 Comm: kworker/u8:2 Not tainted 4.16.0-rc3-next-20180302-dirty #4
>>> [    4.802547] Hardware name: BCM2835
>>> [    4.802562] Workqueue: events_unbound async_run_entry_fn
>>> [    4.802593] [<c03119a4>] (unwind_backtrace) from [<c030cc24>] (show_stack+0x10/0x14)
>>> [    4.802612] [<c030cc24>] (show_stack) from [<c0d8e9dc>] (dump_stack+0x8c/0xa0)
>>> [    4.802628] [<c0d8e9dc>] (dump_stack) from [<c0343a2c>] (__warn+0xe0/0xf8)
>>> [    4.802640] [<c0343a2c>] (__warn) from [<c0343b5c>] (warn_slowpath_null+0x40/0x48)
>>> [    4.802652] [<c0343b5c>] (warn_slowpath_null) from [<c06d0de0>] (gpiod_set_value+0x50/0x58)
>>> [    4.802693] [<c06d0de0>] (gpiod_set_value) from [<bf0e2e90>] (bcm_gpio_set_shutdown+0xc/0x14 [hci_uart])
>>> [    4.802757] [<bf0e2e90>] (bcm_gpio_set_shutdown [hci_uart]) from [<bf0e2a64>] (bcm_gpio_set_power+0x18/0x140 [hci_uart])
>>> [    4.802806] [<bf0e2a64>] (bcm_gpio_set_power [hci_uart]) from [<bf0e2e4c>] (bcm_serdev_probe+0x64/0x9c [hci_uart])
>>> [    4.802848] [<bf0e2e4c>] (bcm_serdev_probe [hci_uart]) from [<c08f2528>] (driver_probe_device+0x254/0x32c)
>>> [    4.802863] [<c08f2528>] (driver_probe_device) from [<c08f26a4>] (__driver_attach+0xa4/0xa8)
>>> [    4.802878] [<c08f26a4>] (__driver_attach) from [<c08f08b8>] (bus_for_each_dev+0x74/0xb4)
>>> [    4.802895] [<c08f08b8>] (bus_for_each_dev) from [<c0366498>] (async_run_entry_fn+0x44/0x108)
>>> [    4.802910] [<c0366498>] (async_run_entry_fn) from [<c035d594>] (process_one_work+0x200/0x4f8)
>>> [    4.802923] [<c035d594>] (process_one_work) from [<c035e4a8>] (worker_thread+0x4c/0x5d4)
>>> [    4.802938] [<c035e4a8>] (worker_thread) from [<c0363300>] (kthread+0x150/0x158)
>>> [    4.802952] [<c0363300>] (kthread) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
>>> [    4.802957] Exception stack(0xed959fb0 to 0xed959ff8)
>>> [    4.802966] 9fa0:                                     00000000 00000000 00000000 00000000
>>> [    4.802977] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>>> [    4.802986] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
>>> [    4.802993] ---[ end trace b947f9d4c40fa261 ]—
>> 
>> that is weird since we should be either in a probe context or in hdev->open context and both can sleep as far as I know.
> 
> okay in this case we can replace gpiod_set_value with gpiod_set_value_cansleep.

if you do that, does it work for you on both the RPi 3 and Zero W?

Regards

Marcel

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>> 
>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>> 
>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>> 
>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> index cf53436..b7f79f1 100644
>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> @@ -131,6 +131,18 @@
>>>>>>> 
>>>>>>> &uart0 {
>>>>>>> 	pinctrl-names = "default";
>>>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>> +	status = "okay";
>>>>>>> +
>>>>>>> +	bluetooth {
>>>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>>>> +		max-speed = <2000000>;
>>>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>> +	};
>>>>>>> +};
>>>>>> 
>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>> 
>>>>> Yes, unload and reload works fine. 
>>>>> 
>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>> 
>>>>> I assume that, because reload works as expected. 
>>>> 
>>>> awesome. That is good news.
>>>> 
>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>> 
>>> so here comes the bad news. hci_bcm uses gpiod_set_value() which is for interrupt context, but the gpio expander can sleep. So we will get this warning:
>>> 
>>> [    4.802447] ------------[ cut here ]------------
>>> [    4.802485] WARNING: CPU: 3 PID: 91 at drivers/gpio/gpiolib.c:2986 gpiod_set_value+0x50/0x58
>>> [    4.802489] Modules linked in: hci_uart ac97_bus btbcm snd_pcm_dmaengine bluetooth snd_pcm snd_timer ecdh_generic snd soundcore bcm2835_thermal crc32_arm_ce
>>> [    4.802543] CPU: 3 PID: 91 Comm: kworker/u8:2 Not tainted 4.16.0-rc3-next-20180302-dirty #4
>>> [    4.802547] Hardware name: BCM2835
>>> [    4.802562] Workqueue: events_unbound async_run_entry_fn
>>> [    4.802593] [<c03119a4>] (unwind_backtrace) from [<c030cc24>] (show_stack+0x10/0x14)
>>> [    4.802612] [<c030cc24>] (show_stack) from [<c0d8e9dc>] (dump_stack+0x8c/0xa0)
>>> [    4.802628] [<c0d8e9dc>] (dump_stack) from [<c0343a2c>] (__warn+0xe0/0xf8)
>>> [    4.802640] [<c0343a2c>] (__warn) from [<c0343b5c>] (warn_slowpath_null+0x40/0x48)
>>> [    4.802652] [<c0343b5c>] (warn_slowpath_null) from [<c06d0de0>] (gpiod_set_value+0x50/0x58)
>>> [    4.802693] [<c06d0de0>] (gpiod_set_value) from [<bf0e2e90>] (bcm_gpio_set_shutdown+0xc/0x14 [hci_uart])
>>> [    4.802757] [<bf0e2e90>] (bcm_gpio_set_shutdown [hci_uart]) from [<bf0e2a64>] (bcm_gpio_set_power+0x18/0x140 [hci_uart])
>>> [    4.802806] [<bf0e2a64>] (bcm_gpio_set_power [hci_uart]) from [<bf0e2e4c>] (bcm_serdev_probe+0x64/0x9c [hci_uart])
>>> [    4.802848] [<bf0e2e4c>] (bcm_serdev_probe [hci_uart]) from [<c08f2528>] (driver_probe_device+0x254/0x32c)
>>> [    4.802863] [<c08f2528>] (driver_probe_device) from [<c08f26a4>] (__driver_attach+0xa4/0xa8)
>>> [    4.802878] [<c08f26a4>] (__driver_attach) from [<c08f08b8>] (bus_for_each_dev+0x74/0xb4)
>>> [    4.802895] [<c08f08b8>] (bus_for_each_dev) from [<c0366498>] (async_run_entry_fn+0x44/0x108)
>>> [    4.802910] [<c0366498>] (async_run_entry_fn) from [<c035d594>] (process_one_work+0x200/0x4f8)
>>> [    4.802923] [<c035d594>] (process_one_work) from [<c035e4a8>] (worker_thread+0x4c/0x5d4)
>>> [    4.802938] [<c035e4a8>] (worker_thread) from [<c0363300>] (kthread+0x150/0x158)
>>> [    4.802952] [<c0363300>] (kthread) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
>>> [    4.802957] Exception stack(0xed959fb0 to 0xed959ff8)
>>> [    4.802966] 9fa0:                                     00000000 00000000 00000000 00000000
>>> [    4.802977] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>>> [    4.802986] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
>>> [    4.802993] ---[ end trace b947f9d4c40fa261 ]?
>> 
>> that is weird since we should be either in a probe context or in hdev->open context and both can sleep as far as I know.
> 
> okay in this case we can replace gpiod_set_value with gpiod_set_value_cansleep.

if you do that, does it work for you on both the RPi 3 and Zero W?

Regards

Marcel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Loic Poulain]

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

> >>
> >> that is weird since we should be either in a probe context or in
hdev->open context and both can sleep as far as I know.

Yes but this is an explicit warning in gpiolib based on gpio controller
capabilities,
not on current context (WARN_ON(desc->gdev->chip->can_sleep)).

So, since we are always in process/thread context here, it seems safe to
use the _cansleep version.

Regards,
Loic

[-- Attachment #2: Type: text/html, Size: 480 bytes --]

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Loic,

> > >>
> > >> that is weird since we should be either in a probe context or in hdev->open context and both can sleep as far as I know.
> 
> Yes but this is an explicit warning in gpiolib based on gpio controller capabilities,
> not on current context (WARN_ON(desc->gdev->chip->can_sleep)).
> 
> So, since we are always in process/thread context here, it seems safe to use the _cansleep version.

can someone whip up a patch for it and quickly test it.

Regards

Marcel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Loic,

> > >>
> > >> that is weird since we should be either in a probe context or in hdev->open context and both can sleep as far as I know.
> 
> Yes but this is an explicit warning in gpiolib based on gpio controller capabilities,
> not on current context (WARN_ON(desc->gdev->chip->can_sleep)).
> 
> So, since we are always in process/thread context here, it seems safe to use the _cansleep version.

can someone whip up a patch for it and quickly test it.

Regards

Marcel

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Loic,

> > >>
> > >> that is weird since we should be either in a probe context or in hdev->open context and both can sleep as far as I know.
> 
> Yes but this is an explicit warning in gpiolib based on gpio controller capabilities,
> not on current context (WARN_ON(desc->gdev->chip->can_sleep)).
> 
> So, since we are always in process/thread context here, it seems safe to use the _cansleep version.

can someone whip up a patch for it and quickly test it.

Regards

Marcel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,

> Marcel Holtmann <marcel@holtmann.org> hat am 25. Februar 2018 um 22:38 geschrieben:
> 
> 
> Hi Stefan,
> 
> >>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> >>> This allows to automatically insert the bcm43438 to the bluetooth
> >>> subsystem instead of relying on patched userspace helpers (hciattach).
> >>> 
> >>> In order to keep a debug UART we need to switch to uart1.
> >>> 
> >>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>> ---
> >>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>> 
> >>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> index cf53436..b7f79f1 100644
> >>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> @@ -131,6 +131,18 @@
> >>> 
> >>> &uart0 {
> >>> 	pinctrl-names = "default";
> >>> -	pinctrl-0 = <&uart0_gpio14>;
> >>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>> +	status = "okay";
> >>> +
> >>> +	bluetooth {
> >>> +		compatible = "brcm,bcm43438-bt";
> >>> +		max-speed = <2000000>;
> >>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>> +	};
> >>> +};
> >> 
> >> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> > 
> > Yes, unload and reload works fine. 
> > 
> >> Meaning we are getting back to the 115200 default baud rate on the UART?
> > 
> > I assume that, because reload works as expected. 
> 
> awesome. That is good news.
> 
> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.

after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:

[    4.873246] Bluetooth: HCI UART driver ver 2.3
[    4.873260] Bluetooth: HCI UART protocol H4 registered
[    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
[    4.873751] Bluetooth: HCI UART protocol Broadcom registered
[    4.877279] uart-pl011 3f201000.serial: no DMA platform data
[    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
[   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
[   15.192312] Bluetooth: hci0: Failed to set baudrate
[   15.316415] Bluetooth: hci0: BCM: chip id 94
[   15.318567] Bluetooth: hci0: BCM: features 0x2e
[   15.341538] Bluetooth: hci0: BCM43430A1
[   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
[   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
[  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
[  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
[  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)

I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].

Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.

Sorry in case this patch gets corrupted by my webmailer.

Stefan

[1] - https://gist.github.com/pelwell/c8230c48ea24698527cd

diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
index 0b31d99..3e87ed0 100644
--- a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
+++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
@@ -20,9 +20,14 @@
 
 	leds {
 		act {
-			gpios = <&gpio 47 GPIO_ACTIVE_HIGH>;
+			gpios = <&expgpio 2 GPIO_ACTIVE_HIGH>;
 		};
 	};
+
+	wifi_pwrseq: wifi-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		reset-gpios = <&expgpio 1 GPIO_ACTIVE_HIGH>;
+	};
 };
 
 &firmware {
@@ -42,6 +47,10 @@
 	};
 };
 
+&hdmi {
+	hpd-gpios = <&expgpio 4 GPIO_ACTIVE_LOW>;
+};
+
 /* uart0 communicates with the BT module */
 &uart0 {
 	pinctrl-names = "default";
@@ -51,6 +60,7 @@
 	bluetooth {
 		compatible = "brcm,bcm43438-bt";
 		max-speed = <2000000>;
+		shutdown-gpios = <&expgpio 0 GPIO_ACTIVE_HIGH>;
 	};
 };
 
@@ -63,11 +73,19 @@
 
 /* SDHCI is used to control the SDIO for wireless */
 &sdhci {
+	#address-cells = <1>;
+	#size-cells = <0>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&emmc_gpio34>;
 	status = "okay";
 	bus-width = <4>;
 	non-removable;
+	mmc-pwrseq = <&wifi_pwrseq>;
+
+	brcmf: wifi@1 {
+		reg = <1>;
+		compatible = "brcm,bcm4329-fmac";
+	};
 };
 
 /* SDHOST is used to drive the SD card */

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

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,

> Marcel Holtmann <marcel@holtmann.org> hat am 25. Februar 2018 um 22:38 geschrieben:
> 
> 
> Hi Stefan,
> 
> >>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> >>> This allows to automatically insert the bcm43438 to the bluetooth
> >>> subsystem instead of relying on patched userspace helpers (hciattach).
> >>> 
> >>> In order to keep a debug UART we need to switch to uart1.
> >>> 
> >>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>> ---
> >>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>> 
> >>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> index cf53436..b7f79f1 100644
> >>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> @@ -131,6 +131,18 @@
> >>> 
> >>> &uart0 {
> >>> 	pinctrl-names = "default";
> >>> -	pinctrl-0 = <&uart0_gpio14>;
> >>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>> +	status = "okay";
> >>> +
> >>> +	bluetooth {
> >>> +		compatible = "brcm,bcm43438-bt";
> >>> +		max-speed = <2000000>;
> >>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>> +	};
> >>> +};
> >> 
> >> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> > 
> > Yes, unload and reload works fine. 
> > 
> >> Meaning we are getting back to the 115200 default baud rate on the UART?
> > 
> > I assume that, because reload works as expected. 
> 
> awesome. That is good news.
> 
> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.

after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:

[    4.873246] Bluetooth: HCI UART driver ver 2.3
[    4.873260] Bluetooth: HCI UART protocol H4 registered
[    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
[    4.873751] Bluetooth: HCI UART protocol Broadcom registered
[    4.877279] uart-pl011 3f201000.serial: no DMA platform data
[    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
[   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
[   15.192312] Bluetooth: hci0: Failed to set baudrate
[   15.316415] Bluetooth: hci0: BCM: chip id 94
[   15.318567] Bluetooth: hci0: BCM: features 0x2e
[   15.341538] Bluetooth: hci0: BCM43430A1
[   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
[   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
[  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
[  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
[  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)

I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].

Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.

Sorry in case this patch gets corrupted by my webmailer.

Stefan

[1] - https://gist.github.com/pelwell/c8230c48ea24698527cd

diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
index 0b31d99..3e87ed0 100644
--- a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
+++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
@@ -20,9 +20,14 @@
 
 	leds {
 		act {
-			gpios = <&gpio 47 GPIO_ACTIVE_HIGH>;
+			gpios = <&expgpio 2 GPIO_ACTIVE_HIGH>;
 		};
 	};
+
+	wifi_pwrseq: wifi-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		reset-gpios = <&expgpio 1 GPIO_ACTIVE_HIGH>;
+	};
 };
 
 &firmware {
@@ -42,6 +47,10 @@
 	};
 };
 
+&hdmi {
+	hpd-gpios = <&expgpio 4 GPIO_ACTIVE_LOW>;
+};
+
 /* uart0 communicates with the BT module */
 &uart0 {
 	pinctrl-names = "default";
@@ -51,6 +60,7 @@
 	bluetooth {
 		compatible = "brcm,bcm43438-bt";
 		max-speed = <2000000>;
+		shutdown-gpios = <&expgpio 0 GPIO_ACTIVE_HIGH>;
 	};
 };
 
@@ -63,11 +73,19 @@
 
 /* SDHCI is used to control the SDIO for wireless */
 &sdhci {
+	#address-cells = <1>;
+	#size-cells = <0>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&emmc_gpio34>;
 	status = "okay";
 	bus-width = <4>;
 	non-removable;
+	mmc-pwrseq = <&wifi_pwrseq>;
+
+	brcmf: wifi@1 {
+		reg = <1>;
+		compatible = "brcm,bcm4329-fmac";
+	};
 };
 
 /* SDHOST is used to drive the SD card */

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

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,

> Marcel Holtmann <marcel@holtmann.org> hat am 25. Februar 2018 um 22:38 geschrieben:
> 
> 
> Hi Stefan,
> 
> >>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> >>> This allows to automatically insert the bcm43438 to the bluetooth
> >>> subsystem instead of relying on patched userspace helpers (hciattach).
> >>> 
> >>> In order to keep a debug UART we need to switch to uart1.
> >>> 
> >>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>> ---
> >>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>> 
> >>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> index cf53436..b7f79f1 100644
> >>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>> @@ -131,6 +131,18 @@
> >>> 
> >>> &uart0 {
> >>> 	pinctrl-names = "default";
> >>> -	pinctrl-0 = <&uart0_gpio14>;
> >>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>> +	status = "okay";
> >>> +
> >>> +	bluetooth {
> >>> +		compatible = "brcm,bcm43438-bt";
> >>> +		max-speed = <2000000>;
> >>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>> +	};
> >>> +};
> >> 
> >> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> > 
> > Yes, unload and reload works fine. 
> > 
> >> Meaning we are getting back to the 115200 default baud rate on the UART?
> > 
> > I assume that, because reload works as expected. 
> 
> awesome. That is good news.
> 
> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.

after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:

[    4.873246] Bluetooth: HCI UART driver ver 2.3
[    4.873260] Bluetooth: HCI UART protocol H4 registered
[    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
[    4.873751] Bluetooth: HCI UART protocol Broadcom registered
[    4.877279] uart-pl011 3f201000.serial: no DMA platform data
[    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
[   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
[   15.192312] Bluetooth: hci0: Failed to set baudrate
[   15.316415] Bluetooth: hci0: BCM: chip id 94
[   15.318567] Bluetooth: hci0: BCM: features 0x2e
[   15.341538] Bluetooth: hci0: BCM43430A1
[   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
[   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
[  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
[  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
[  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)

I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].

Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.

Sorry in case this patch gets corrupted by my webmailer.

Stefan

[1] - https://gist.github.com/pelwell/c8230c48ea24698527cd

diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
index 0b31d99..3e87ed0 100644
--- a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
+++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
@@ -20,9 +20,14 @@
 
 	leds {
 		act {
-			gpios = <&gpio 47 GPIO_ACTIVE_HIGH>;
+			gpios = <&expgpio 2 GPIO_ACTIVE_HIGH>;
 		};
 	};
+
+	wifi_pwrseq: wifi-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		reset-gpios = <&expgpio 1 GPIO_ACTIVE_HIGH>;
+	};
 };
 
 &firmware {
@@ -42,6 +47,10 @@
 	};
 };
 
+&hdmi {
+	hpd-gpios = <&expgpio 4 GPIO_ACTIVE_LOW>;
+};
+
 /* uart0 communicates with the BT module */
 &uart0 {
 	pinctrl-names = "default";
@@ -51,6 +60,7 @@
 	bluetooth {
 		compatible = "brcm,bcm43438-bt";
 		max-speed = <2000000>;
+		shutdown-gpios = <&expgpio 0 GPIO_ACTIVE_HIGH>;
 	};
 };
 
@@ -63,11 +73,19 @@
 
 /* SDHCI is used to control the SDIO for wireless */
 &sdhci {
+	#address-cells = <1>;
+	#size-cells = <0>;
 	pinctrl-names = "default";
 	pinctrl-0 = <&emmc_gpio34>;
 	status = "okay";
 	bus-width = <4>;
 	non-removable;
+	mmc-pwrseq = <&wifi_pwrseq>;
+
+	brcmf: wifi at 1 {
+		reg = <1>;
+		compatible = "brcm,bcm4329-fmac";
+	};
 };
 
 /* SDHOST is used to drive the SD card */

> 
> Regards
> 
> Marcel
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Loic Poulain]

Hi Stefan,

> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>
> [    4.873246] Bluetooth: HCI UART driver ver 2.3
> [    4.873260] Bluetooth: HCI UART protocol H4 registered
> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
> [   15.192312] Bluetooth: hci0: Failed to set baudrate
> [   15.316415] Bluetooth: hci0: BCM: chip id 94
> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
> [   15.341538] Bluetooth: hci0: BCM43430A1
> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>
> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>
> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>
> Sorry in case this patch gets corrupted by my webmailer.

I assume the controller requests a certain time to be ready, so the
controller probably misses the first command (update baudrate).
And yes the reason it's not reproducible on RPi Zero W is seems
related to hardware flow control, the device most likely asserts RTS
only when ready.

Could you try adding a msleep in the bcm_gpio_set_power method after
toggling the shutdown gpio, I don't know about the BCM controller boot
time but 50ms should be enough.

I'm not sure why it's related to my patch, maybe just a timing question.

Regards,
Loic

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Loic Poulain]

Hi Stefan,

> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>
> [    4.873246] Bluetooth: HCI UART driver ver 2.3
> [    4.873260] Bluetooth: HCI UART protocol H4 registered
> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
> [   15.192312] Bluetooth: hci0: Failed to set baudrate
> [   15.316415] Bluetooth: hci0: BCM: chip id 94
> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
> [   15.341538] Bluetooth: hci0: BCM43430A1
> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>
> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>
> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>
> Sorry in case this patch gets corrupted by my webmailer.

I assume the controller requests a certain time to be ready, so the
controller probably misses the first command (update baudrate).
And yes the reason it's not reproducible on RPi Zero W is seems
related to hardware flow control, the device most likely asserts RTS
only when ready.

Could you try adding a msleep in the bcm_gpio_set_power method after
toggling the shutdown gpio, I don't know about the BCM controller boot
time but 50ms should be enough.

I'm not sure why it's related to my patch, maybe just a timing question.

Regards,
Loic

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Loic Poulain]

Hi Stefan,

> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>
> [    4.873246] Bluetooth: HCI UART driver ver 2.3
> [    4.873260] Bluetooth: HCI UART protocol H4 registered
> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
> [   15.192312] Bluetooth: hci0: Failed to set baudrate
> [   15.316415] Bluetooth: hci0: BCM: chip id 94
> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
> [   15.341538] Bluetooth: hci0: BCM43430A1
> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>
> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>
> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>
> Sorry in case this patch gets corrupted by my webmailer.

I assume the controller requests a certain time to be ready, so the
controller probably misses the first command (update baudrate).
And yes the reason it's not reproducible on RPi Zero W is seems
related to hardware flow control, the device most likely asserts RTS
only when ready.

Could you try adding a msleep in the bcm_gpio_set_power method after
toggling the shutdown gpio, I don't know about the BCM controller boot
time but 50ms should be enough.

I'm not sure why it's related to my patch, maybe just a timing question.

Regards,
Loic

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>> 
>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>> 
>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>> ---
>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>> 
>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> index cf53436..b7f79f1 100644
>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> @@ -131,6 +131,18 @@
>>>>> 
>>>>> &uart0 {
>>>>> 	pinctrl-names = "default";
>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>> +	status = "okay";
>>>>> +
>>>>> +	bluetooth {
>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>> +		max-speed = <2000000>;
>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>> +	};
>>>>> +};
>>>> 
>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>> 
>>> Yes, unload and reload works fine. 
>>> 
>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>> 
>>> I assume that, because reload works as expected. 
>> 
>> awesome. That is good news.
>> 
>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
> 
> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
> 
> [    4.873246] Bluetooth: HCI UART driver ver 2.3
> [    4.873260] Bluetooth: HCI UART protocol H4 registered
> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
> [   15.192312] Bluetooth: hci0: Failed to set baudrate
> [   15.316415] Bluetooth: hci0: BCM: chip id 94
> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
> [   15.341538] Bluetooth: hci0: BCM43430A1
> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
> 
> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
> 
> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.

maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?

Can you also dump where the Frame reassembly fails. Or correlate that with the btmon trace of which packets make its through. The 0x0c14 is Read Local Name and maybe we actually have bit errors here.

In theory we could also run this hardware in 3-wire protocol mode. I just do not know how to get that one started, but maybe that would be an option if there is some sort of packet loss. However maybe this is really just some timing issue for the hardware to settle its baud rate. However I assume that the firmware loading itself succeeds here.

Regards

Marcel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>> 
>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>> 
>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>> ---
>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>> 
>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> index cf53436..b7f79f1 100644
>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> @@ -131,6 +131,18 @@
>>>>> 
>>>>> &uart0 {
>>>>> 	pinctrl-names = "default";
>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>> +	status = "okay";
>>>>> +
>>>>> +	bluetooth {
>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>> +		max-speed = <2000000>;
>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>> +	};
>>>>> +};
>>>> 
>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>> 
>>> Yes, unload and reload works fine. 
>>> 
>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>> 
>>> I assume that, because reload works as expected. 
>> 
>> awesome. That is good news.
>> 
>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
> 
> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
> 
> [    4.873246] Bluetooth: HCI UART driver ver 2.3
> [    4.873260] Bluetooth: HCI UART protocol H4 registered
> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
> [   15.192312] Bluetooth: hci0: Failed to set baudrate
> [   15.316415] Bluetooth: hci0: BCM: chip id 94
> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
> [   15.341538] Bluetooth: hci0: BCM43430A1
> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
> 
> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
> 
> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.

maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?

Can you also dump where the Frame reassembly fails. Or correlate that with the btmon trace of which packets make its through. The 0x0c14 is Read Local Name and maybe we actually have bit errors here.

In theory we could also run this hardware in 3-wire protocol mode. I just do not know how to get that one started, but maybe that would be an option if there is some sort of packet loss. However maybe this is really just some timing issue for the hardware to settle its baud rate. However I assume that the firmware loading itself succeeds here.

Regards

Marcel

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>> 
>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>> 
>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>> ---
>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>> 
>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> index cf53436..b7f79f1 100644
>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>> @@ -131,6 +131,18 @@
>>>>> 
>>>>> &uart0 {
>>>>> 	pinctrl-names = "default";
>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>> +	status = "okay";
>>>>> +
>>>>> +	bluetooth {
>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>> +		max-speed = <2000000>;
>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>> +	};
>>>>> +};
>>>> 
>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>> 
>>> Yes, unload and reload works fine. 
>>> 
>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>> 
>>> I assume that, because reload works as expected. 
>> 
>> awesome. That is good news.
>> 
>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
> 
> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
> 
> [    4.873246] Bluetooth: HCI UART driver ver 2.3
> [    4.873260] Bluetooth: HCI UART protocol H4 registered
> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
> [   15.192312] Bluetooth: hci0: Failed to set baudrate
> [   15.316415] Bluetooth: hci0: BCM: chip id 94
> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
> [   15.341538] Bluetooth: hci0: BCM43430A1
> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
> 
> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
> 
> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.

maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?

Can you also dump where the Frame reassembly fails. Or correlate that with the btmon trace of which packets make its through. The 0x0c14 is Read Local Name and maybe we actually have bit errors here.

In theory we could also run this hardware in 3-wire protocol mode. I just do not know how to get that one started, but maybe that would be an option if there is some sort of packet loss. However maybe this is really just some timing issue for the hardware to settle its baud rate. However I assume that the firmware loading itself succeeds here.

Regards

Marcel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,
hi Loic,

> Marcel Holtmann <marcel@holtmann.org> hat am 7. März 2018 um 13:12 geschrieben:
> 
> 
> Hi Stefan,
> 
> >>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> >>>>> This allows to automatically insert the bcm43438 to the bluetooth
> >>>>> subsystem instead of relying on patched userspace helpers (hciattach).
> >>>>> 
> >>>>> In order to keep a debug UART we need to switch to uart1.
> >>>>> 
> >>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>>>> ---
> >>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>>>> 
> >>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>> index cf53436..b7f79f1 100644
> >>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>> @@ -131,6 +131,18 @@
> >>>>> 
> >>>>> &uart0 {
> >>>>> 	pinctrl-names = "default";
> >>>>> -	pinctrl-0 = <&uart0_gpio14>;
> >>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>>>> +	status = "okay";
> >>>>> +
> >>>>> +	bluetooth {
> >>>>> +		compatible = "brcm,bcm43438-bt";
> >>>>> +		max-speed = <2000000>;
> >>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>>>> +	};
> >>>>> +};
> >>>> 
> >>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> >>> 
> >>> Yes, unload and reload works fine. 
> >>> 
> >>>> Meaning we are getting back to the 115200 default baud rate on the UART?
> >>> 
> >>> I assume that, because reload works as expected. 
> >> 
> >> awesome. That is good news.
> >> 
> >> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
> > 
> > after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
> > 
> > [    4.873246] Bluetooth: HCI UART driver ver 2.3
> > [    4.873260] Bluetooth: HCI UART protocol H4 registered
> > [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
> > [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
> > [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
> > [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
> > [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
> > [   15.192312] Bluetooth: hci0: Failed to set baudrate
> > [   15.316415] Bluetooth: hci0: BCM: chip id 94
> > [   15.318567] Bluetooth: hci0: BCM: features 0x2e
> > [   15.341538] Bluetooth: hci0: BCM43430A1
> > [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
> > [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
> > [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
> > [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
> > [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
> > 
> > I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
> > 
> > Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
> 
> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?

I will try, but this could also be an "issue" of the gpio expander driver. AFAIK the expander is connected via I2C to the GPU. In case the mailbox reply come before the I2C command has been handled by the GPIO expander, we are running out of sync.

> 
> Can you also dump where the Frame reassembly fails. Or correlate that with the btmon trace of which packets make its through. The 0x0c14 is Read Local Name and maybe we actually have bit errors here.
> 
> In theory we could also run this hardware in 3-wire protocol mode. I just do not know how to get that one started, but maybe that would be an option if there is some sort of packet loss. However maybe this is really just some timing issue for the hardware to settle its baud rate. However I assume that the firmware loading itself succeeds here.

According to the link from my last email, the RPi 3 is using 3-wire protocol mode. Maybe we should detect the presence of "uart-has-rtscts" in the master node? In absence we better use 3-wire.

Stefan

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

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

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,
hi Loic,

> Marcel Holtmann <marcel@holtmann.org> hat am 7. M=C3=A4rz 2018 um 13:12 g=
eschrieben:
>=20
>=20
> Hi Stefan,
>=20
> >>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/t=
tyAMA0).
> >>>>> This allows to automatically insert the bcm43438 to the bluetooth
> >>>>> subsystem instead of relying on patched userspace helpers (hciattac=
h).
> >>>>>=20
> >>>>> In order to keep a debug UART we need to switch to uart1.
> >>>>>=20
> >>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>>>> ---
> >>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>>>>=20
> >>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/bo=
ot/dts/bcm2835-rpi-zero-w.dts
> >>>>> index cf53436..b7f79f1 100644
> >>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>> @@ -131,6 +131,18 @@
> >>>>>=20
> >>>>> &uart0 {
> >>>>> =09pinctrl-names =3D "default";
> >>>>> -=09pinctrl-0 =3D <&uart0_gpio14>;
> >>>>> +=09pinctrl-0 =3D <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>>>> +=09status =3D "okay";
> >>>>> +
> >>>>> +=09bluetooth {
> >>>>> +=09=09compatible =3D "brcm,bcm43438-bt";
> >>>>> +=09=09max-speed =3D <2000000>;
> >>>>> +=09=09shutdown-gpios =3D <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>>>> +=09};
> >>>>> +};
> >>>>=20
> >>>> is the shutdown GPIO working as expected with this hardware. So even=
 module unload and reload works fine?
> >>>=20
> >>> Yes, unload and reload works fine.=20
> >>>=20
> >>>> Meaning we are getting back to the 115200 default baud rate on the U=
ART?
> >>>=20
> >>> I assume that, because reload works as expected.=20
> >>=20
> >> awesome. That is good news.
> >>=20
> >> Since you said that the GPIO expander driver for the RPi 3 has been ac=
cepted, did you test it there as well? If so, then it would be good to get =
a patch that also provides shutdown-gpios for RPi 3.
> >=20
> > after applying Loic's patch and the necessary patch for the RPi 3 dts f=
ile (see below), i will get this output:
> >=20
> > [    4.873246] Bluetooth: HCI UART driver ver 2.3
> > [    4.873260] Bluetooth: HCI UART protocol H4 registered
> > [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
> > [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
> > [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
> > [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
> > [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-=
110)
> > [   15.192312] Bluetooth: hci0: Failed to set baudrate
> > [   15.316415] Bluetooth: hci0: BCM: chip id 94
> > [   15.318567] Bluetooth: hci0: BCM: features 0x2e
> > [   15.341538] Bluetooth: hci0: BCM43430A1
> > [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
> > [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
> > [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
> > [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
> > [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
> >=20
> > I don't see these errors on RPi Zero W. Maybe the reason for this is th=
e lack of hardware flowcontrol on RPi 3. Or some of the downstream patches =
on BlueZ must be adapted for the kernel [1].
> >=20
> > Btw the bcm43438 is detected even after unloading and reloading the dri=
ver. But the timeout occurs also on driver reload. Reducing the baudrate to=
 115200 doesn't help here.
>=20
> maybe it needs some time after switching the hardware on. Have you tried =
to sleep for a bit at the end of bcm_gpio_set_power?

I will try, but this could also be an "issue" of the gpio expander driver. =
AFAIK the expander is connected via I2C to the GPU. In case the mailbox rep=
ly come before the I2C command has been handled by the GPIO expander, we ar=
e running out of sync.

>=20
> Can you also dump where the Frame reassembly fails. Or correlate that wit=
h the btmon trace of which packets make its through. The 0x0c14 is Read Loc=
al Name and maybe we actually have bit errors here.
>=20
> In theory we could also run this hardware in 3-wire protocol mode. I just=
 do not know how to get that one started, but maybe that would be an option=
 if there is some sort of packet loss. However maybe this is really just so=
me timing issue for the hardware to settle its baud rate. However I assume =
that the firmware loading itself succeeds here.

According to the link from my last email, the RPi 3 is using 3-wire protoco=
l mode. Maybe we should detect the presence of "uart-has-rtscts" in the mas=
ter node? In absence we better use 3-wire.

Stefan

>=20
> Regards
>=20
> Marcel
>=20
>=20
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi Marcel,
hi Loic,

> Marcel Holtmann <marcel@holtmann.org> hat am 7. M?rz 2018 um 13:12 geschrieben:
> 
> 
> Hi Stefan,
> 
> >>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> >>>>> This allows to automatically insert the bcm43438 to the bluetooth
> >>>>> subsystem instead of relying on patched userspace helpers (hciattach).
> >>>>> 
> >>>>> In order to keep a debug UART we need to switch to uart1.
> >>>>> 
> >>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>>>> ---
> >>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>>>> 
> >>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>> index cf53436..b7f79f1 100644
> >>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>> @@ -131,6 +131,18 @@
> >>>>> 
> >>>>> &uart0 {
> >>>>> 	pinctrl-names = "default";
> >>>>> -	pinctrl-0 = <&uart0_gpio14>;
> >>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>>>> +	status = "okay";
> >>>>> +
> >>>>> +	bluetooth {
> >>>>> +		compatible = "brcm,bcm43438-bt";
> >>>>> +		max-speed = <2000000>;
> >>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>>>> +	};
> >>>>> +};
> >>>> 
> >>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> >>> 
> >>> Yes, unload and reload works fine. 
> >>> 
> >>>> Meaning we are getting back to the 115200 default baud rate on the UART?
> >>> 
> >>> I assume that, because reload works as expected. 
> >> 
> >> awesome. That is good news.
> >> 
> >> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
> > 
> > after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
> > 
> > [    4.873246] Bluetooth: HCI UART driver ver 2.3
> > [    4.873260] Bluetooth: HCI UART protocol H4 registered
> > [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
> > [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
> > [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
> > [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
> > [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
> > [   15.192312] Bluetooth: hci0: Failed to set baudrate
> > [   15.316415] Bluetooth: hci0: BCM: chip id 94
> > [   15.318567] Bluetooth: hci0: BCM: features 0x2e
> > [   15.341538] Bluetooth: hci0: BCM43430A1
> > [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
> > [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
> > [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
> > [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
> > [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
> > 
> > I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
> > 
> > Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
> 
> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?

I will try, but this could also be an "issue" of the gpio expander driver. AFAIK the expander is connected via I2C to the GPU. In case the mailbox reply come before the I2C command has been handled by the GPIO expander, we are running out of sync.

> 
> Can you also dump where the Frame reassembly fails. Or correlate that with the btmon trace of which packets make its through. The 0x0c14 is Read Local Name and maybe we actually have bit errors here.
> 
> In theory we could also run this hardware in 3-wire protocol mode. I just do not know how to get that one started, but maybe that would be an option if there is some sort of packet loss. However maybe this is really just some timing issue for the hardware to settle its baud rate. However I assume that the firmware loading itself succeeds here.

According to the link from my last email, the RPi 3 is using 3-wire protocol mode. Maybe we should detect the presence of "uart-has-rtscts" in the master node? In absence we better use 3-wire.

Stefan

> 
> Regards
> 
> Marcel
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>> 
>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>> 
>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>> 
>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> index cf53436..b7f79f1 100644
>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> @@ -131,6 +131,18 @@
>>>>>>> 
>>>>>>> &uart0 {
>>>>>>> 	pinctrl-names = "default";
>>>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>> +	status = "okay";
>>>>>>> +
>>>>>>> +	bluetooth {
>>>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>>>> +		max-speed = <2000000>;
>>>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>> +	};
>>>>>>> +};
>>>>>> 
>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>> 
>>>>> Yes, unload and reload works fine. 
>>>>> 
>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>> 
>>>>> I assume that, because reload works as expected. 
>>>> 
>>>> awesome. That is good news.
>>>> 
>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>> 
>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>>> 
>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 
>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>>> 
>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>> 
>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
> 
> I will try, but this could also be an "issue" of the gpio expander driver. AFAIK the expander is connected via I2C to the GPU. In case the mailbox reply come before the I2C command has been handled by the GPIO expander, we are running out of sync.
> 
>> 
>> Can you also dump where the Frame reassembly fails. Or correlate that with the btmon trace of which packets make its through. The 0x0c14 is Read Local Name and maybe we actually have bit errors here.
>> 
>> In theory we could also run this hardware in 3-wire protocol mode. I just do not know how to get that one started, but maybe that would be an option if there is some sort of packet loss. However maybe this is really just some timing issue for the hardware to settle its baud rate. However I assume that the firmware loading itself succeeds here.
> 
> According to the link from my last email, the RPi 3 is using 3-wire protocol mode. Maybe we should detect the presence of "uart-has-rtscts" in the master node? In absence we better use 3-wire.

currently we are using it in H:4 protocol mode. Using it in H:5 protocol mode (aka 3-wire) would require a lot of extra work. There is some work ongoing for the Realtek hardware that is actually always 3-wire.

Maybe the Broadcom hardware auto-detects H:4 vs H:5 protocol and switches accordingly. You could try to work with the Realtek patches and see if we can get that going with the Broadcom chips as well.

On the other hand, when not using the shutdown GPIO entry in the DT, does everything work fine for you?

Regards

Marcel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>> 
>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>> 
>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>> 
>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> index cf53436..b7f79f1 100644
>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> @@ -131,6 +131,18 @@
>>>>>>> 
>>>>>>> &uart0 {
>>>>>>> 	pinctrl-names = "default";
>>>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>> +	status = "okay";
>>>>>>> +
>>>>>>> +	bluetooth {
>>>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>>>> +		max-speed = <2000000>;
>>>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>> +	};
>>>>>>> +};
>>>>>> 
>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>> 
>>>>> Yes, unload and reload works fine. 
>>>>> 
>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>> 
>>>>> I assume that, because reload works as expected. 
>>>> 
>>>> awesome. That is good news.
>>>> 
>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>> 
>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>>> 
>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 
>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>>> 
>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>> 
>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
> 
> I will try, but this could also be an "issue" of the gpio expander driver. AFAIK the expander is connected via I2C to the GPU. In case the mailbox reply come before the I2C command has been handled by the GPIO expander, we are running out of sync.
> 
>> 
>> Can you also dump where the Frame reassembly fails. Or correlate that with the btmon trace of which packets make its through. The 0x0c14 is Read Local Name and maybe we actually have bit errors here.
>> 
>> In theory we could also run this hardware in 3-wire protocol mode. I just do not know how to get that one started, but maybe that would be an option if there is some sort of packet loss. However maybe this is really just some timing issue for the hardware to settle its baud rate. However I assume that the firmware loading itself succeeds here.
> 
> According to the link from my last email, the RPi 3 is using 3-wire protocol mode. Maybe we should detect the presence of "uart-has-rtscts" in the master node? In absence we better use 3-wire.

currently we are using it in H:4 protocol mode. Using it in H:5 protocol mode (aka 3-wire) would require a lot of extra work. There is some work ongoing for the Realtek hardware that is actually always 3-wire.

Maybe the Broadcom hardware auto-detects H:4 vs H:5 protocol and switches accordingly. You could try to work with the Realtek patches and see if we can get that going with the Broadcom chips as well.

On the other hand, when not using the shutdown GPIO entry in the DT, does everything work fine for you?

Regards

Marcel

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>> 
>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>> 
>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>> ---
>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>> 
>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> index cf53436..b7f79f1 100644
>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>> @@ -131,6 +131,18 @@
>>>>>>> 
>>>>>>> &uart0 {
>>>>>>> 	pinctrl-names = "default";
>>>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>> +	status = "okay";
>>>>>>> +
>>>>>>> +	bluetooth {
>>>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>>>> +		max-speed = <2000000>;
>>>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>> +	};
>>>>>>> +};
>>>>>> 
>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>> 
>>>>> Yes, unload and reload works fine. 
>>>>> 
>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>> 
>>>>> I assume that, because reload works as expected. 
>>>> 
>>>> awesome. That is good news.
>>>> 
>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>> 
>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>>> 
>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>> 
>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>>> 
>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>> 
>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
> 
> I will try, but this could also be an "issue" of the gpio expander driver. AFAIK the expander is connected via I2C to the GPU. In case the mailbox reply come before the I2C command has been handled by the GPIO expander, we are running out of sync.
> 
>> 
>> Can you also dump where the Frame reassembly fails. Or correlate that with the btmon trace of which packets make its through. The 0x0c14 is Read Local Name and maybe we actually have bit errors here.
>> 
>> In theory we could also run this hardware in 3-wire protocol mode. I just do not know how to get that one started, but maybe that would be an option if there is some sort of packet loss. However maybe this is really just some timing issue for the hardware to settle its baud rate. However I assume that the firmware loading itself succeeds here.
> 
> According to the link from my last email, the RPi 3 is using 3-wire protocol mode. Maybe we should detect the presence of "uart-has-rtscts" in the master node? In absence we better use 3-wire.

currently we are using it in H:4 protocol mode. Using it in H:5 protocol mode (aka 3-wire) would require a lot of extra work. There is some work ongoing for the Realtek hardware that is actually always 3-wire.

Maybe the Broadcom hardware auto-detects H:4 vs H:5 protocol and switches accordingly. You could try to work with the Realtek patches and see if we can get that going with the Broadcom chips as well.

On the other hand, when not using the shutdown GPIO entry in the DT, does everything work fine for you?

Regards

Marcel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Eric Anholt]

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

Stefan Wahren <stefan.wahren@i2se.com> writes:

> Hi Marcel,
> hi Loic,
>
>> Marcel Holtmann <marcel@holtmann.org> hat am 7. März 2018 um 13:12 geschrieben:
>> 
>> 
>> Hi Stefan,
>> 
>> >>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>> >>>>> This allows to automatically insert the bcm43438 to the bluetooth
>> >>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>> >>>>> 
>> >>>>> In order to keep a debug UART we need to switch to uart1.
>> >>>>> 
>> >>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>> >>>>> ---
>> >>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>> >>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>> >>>>> 
>> >>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>> index cf53436..b7f79f1 100644
>> >>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>> @@ -131,6 +131,18 @@
>> >>>>> 
>> >>>>> &uart0 {
>> >>>>> 	pinctrl-names = "default";
>> >>>>> -	pinctrl-0 = <&uart0_gpio14>;
>> >>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>> >>>>> +	status = "okay";
>> >>>>> +
>> >>>>> +	bluetooth {
>> >>>>> +		compatible = "brcm,bcm43438-bt";
>> >>>>> +		max-speed = <2000000>;
>> >>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>> >>>>> +	};
>> >>>>> +};
>> >>>> 
>> >>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>> >>> 
>> >>> Yes, unload and reload works fine. 
>> >>> 
>> >>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>> >>> 
>> >>> I assume that, because reload works as expected. 
>> >> 
>> >> awesome. That is good news.
>> >> 
>> >> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>> > 
>> > after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>> > 
>> > [    4.873246] Bluetooth: HCI UART driver ver 2.3
>> > [    4.873260] Bluetooth: HCI UART protocol H4 registered
>> > [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>> > [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>> > [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>> > [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>> > [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>> > [   15.192312] Bluetooth: hci0: Failed to set baudrate
>> > [   15.316415] Bluetooth: hci0: BCM: chip id 94
>> > [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>> > [   15.341538] Bluetooth: hci0: BCM43430A1
>> > [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>> > [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>> > [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>> > [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>> > [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>> > 
>> > I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>> > 
>> > Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>> 
>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
>
> I will try, but this could also be an "issue" of the gpio expander
> driver. AFAIK the expander is connected via I2C to the GPU. In case
> the mailbox reply come before the I2C command has been handled by the
> GPIO expander, we are running out of sync.

The mailbox command for setting GPIO state is synchronous in terms of
sending the i2c command to the GPIO expander HW.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 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

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Eric Anholt]

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

Stefan Wahren <stefan.wahren@i2se.com> writes:

> Hi Marcel,
> hi Loic,
>
>> Marcel Holtmann <marcel@holtmann.org> hat am 7. März 2018 um 13:12 geschrieben:
>> 
>> 
>> Hi Stefan,
>> 
>> >>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>> >>>>> This allows to automatically insert the bcm43438 to the bluetooth
>> >>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>> >>>>> 
>> >>>>> In order to keep a debug UART we need to switch to uart1.
>> >>>>> 
>> >>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>> >>>>> ---
>> >>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>> >>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>> >>>>> 
>> >>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>> index cf53436..b7f79f1 100644
>> >>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>> @@ -131,6 +131,18 @@
>> >>>>> 
>> >>>>> &uart0 {
>> >>>>> 	pinctrl-names = "default";
>> >>>>> -	pinctrl-0 = <&uart0_gpio14>;
>> >>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>> >>>>> +	status = "okay";
>> >>>>> +
>> >>>>> +	bluetooth {
>> >>>>> +		compatible = "brcm,bcm43438-bt";
>> >>>>> +		max-speed = <2000000>;
>> >>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>> >>>>> +	};
>> >>>>> +};
>> >>>> 
>> >>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>> >>> 
>> >>> Yes, unload and reload works fine. 
>> >>> 
>> >>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>> >>> 
>> >>> I assume that, because reload works as expected. 
>> >> 
>> >> awesome. That is good news.
>> >> 
>> >> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>> > 
>> > after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>> > 
>> > [    4.873246] Bluetooth: HCI UART driver ver 2.3
>> > [    4.873260] Bluetooth: HCI UART protocol H4 registered
>> > [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>> > [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>> > [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>> > [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>> > [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>> > [   15.192312] Bluetooth: hci0: Failed to set baudrate
>> > [   15.316415] Bluetooth: hci0: BCM: chip id 94
>> > [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>> > [   15.341538] Bluetooth: hci0: BCM43430A1
>> > [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>> > [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>> > [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>> > [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>> > [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>> > 
>> > I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>> > 
>> > Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>> 
>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
>
> I will try, but this could also be an "issue" of the gpio expander
> driver. AFAIK the expander is connected via I2C to the GPU. In case
> the mailbox reply come before the I2C command has been handled by the
> GPIO expander, we are running out of sync.

The mailbox command for setting GPIO state is synchronous in terms of
sending the i2c command to the GPIO expander HW.

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

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Eric Anholt]

Stefan Wahren <stefan.wahren@i2se.com> writes:

> Hi Marcel,
> hi Loic,
>
>> Marcel Holtmann <marcel@holtmann.org> hat am 7. M?rz 2018 um 13:12 geschrieben:
>> 
>> 
>> Hi Stefan,
>> 
>> >>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>> >>>>> This allows to automatically insert the bcm43438 to the bluetooth
>> >>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>> >>>>> 
>> >>>>> In order to keep a debug UART we need to switch to uart1.
>> >>>>> 
>> >>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>> >>>>> ---
>> >>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>> >>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>> >>>>> 
>> >>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>> index cf53436..b7f79f1 100644
>> >>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>> @@ -131,6 +131,18 @@
>> >>>>> 
>> >>>>> &uart0 {
>> >>>>> 	pinctrl-names = "default";
>> >>>>> -	pinctrl-0 = <&uart0_gpio14>;
>> >>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>> >>>>> +	status = "okay";
>> >>>>> +
>> >>>>> +	bluetooth {
>> >>>>> +		compatible = "brcm,bcm43438-bt";
>> >>>>> +		max-speed = <2000000>;
>> >>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>> >>>>> +	};
>> >>>>> +};
>> >>>> 
>> >>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>> >>> 
>> >>> Yes, unload and reload works fine. 
>> >>> 
>> >>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>> >>> 
>> >>> I assume that, because reload works as expected. 
>> >> 
>> >> awesome. That is good news.
>> >> 
>> >> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>> > 
>> > after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>> > 
>> > [    4.873246] Bluetooth: HCI UART driver ver 2.3
>> > [    4.873260] Bluetooth: HCI UART protocol H4 registered
>> > [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>> > [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>> > [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>> > [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>> > [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>> > [   15.192312] Bluetooth: hci0: Failed to set baudrate
>> > [   15.316415] Bluetooth: hci0: BCM: chip id 94
>> > [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>> > [   15.341538] Bluetooth: hci0: BCM43430A1
>> > [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>> > [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>> > [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>> > [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>> > [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>> > 
>> > I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>> > 
>> > Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>> 
>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
>
> I will try, but this could also be an "issue" of the gpio expander
> driver. AFAIK the expander is connected via I2C to the GPU. In case
> the mailbox reply come before the I2C command has been handled by the
> GPIO expander, we are running out of sync.

The mailbox command for setting GPIO state is synchronous in terms of
sending the i2c command to the GPIO expander HW.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180307/5b776062/attachment-0001.sig>

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Eric,

>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>>> 
>>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>>> 
>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>>> ---
>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>>> 
>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>> index cf53436..b7f79f1 100644
>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>> @@ -131,6 +131,18 @@
>>>>>>>> 
>>>>>>>> &uart0 {
>>>>>>>> 	pinctrl-names = "default";
>>>>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>>> +	status = "okay";
>>>>>>>> +
>>>>>>>> +	bluetooth {
>>>>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>>>>> +		max-speed = <2000000>;
>>>>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>>> +	};
>>>>>>>> +};
>>>>>>> 
>>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>>> 
>>>>>> Yes, unload and reload works fine. 
>>>>>> 
>>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>>> 
>>>>>> I assume that, because reload works as expected. 
>>>>> 
>>>>> awesome. That is good news.
>>>>> 
>>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>>> 
>>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>>>> 
>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>> 
>>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>>>> 
>>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>>> 
>>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
>> 
>> I will try, but this could also be an "issue" of the gpio expander
>> driver. AFAIK the expander is connected via I2C to the GPU. In case
>> the mailbox reply come before the I2C command has been handled by the
>> GPIO expander, we are running out of sync.
> 
> The mailbox command for setting GPIO state is synchronous in terms of
> sending the i2c command to the GPIO expander HW.

does that mean the driver does this correctly and really waits for the completion. Or does the GPIO expander might return to quickly and returns a false sense of GPIO state. I think it would be good a sleep of 50ms after the GPIO makes a difference. Maybe the GPIO expander driver needs to take this into account.

Reality is that once the Bluetooth driver toggled the GPIO, it goes onto initializing the chip. One other reason might be that no device wakeup GPIO is wired here, that the chip actually needs some time before it is all good to go.

Regards

Marcel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Eric,

>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>>> 
>>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>>> 
>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>>> ---
>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>>> 
>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>> index cf53436..b7f79f1 100644
>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>> @@ -131,6 +131,18 @@
>>>>>>>> 
>>>>>>>> &uart0 {
>>>>>>>> 	pinctrl-names = "default";
>>>>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>>> +	status = "okay";
>>>>>>>> +
>>>>>>>> +	bluetooth {
>>>>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>>>>> +		max-speed = <2000000>;
>>>>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>>> +	};
>>>>>>>> +};
>>>>>>> 
>>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>>> 
>>>>>> Yes, unload and reload works fine. 
>>>>>> 
>>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>>> 
>>>>>> I assume that, because reload works as expected. 
>>>>> 
>>>>> awesome. That is good news.
>>>>> 
>>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>>> 
>>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>>>> 
>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>> 
>>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>>>> 
>>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>>> 
>>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
>> 
>> I will try, but this could also be an "issue" of the gpio expander
>> driver. AFAIK the expander is connected via I2C to the GPU. In case
>> the mailbox reply come before the I2C command has been handled by the
>> GPIO expander, we are running out of sync.
> 
> The mailbox command for setting GPIO state is synchronous in terms of
> sending the i2c command to the GPIO expander HW.

does that mean the driver does this correctly and really waits for the completion. Or does the GPIO expander might return to quickly and returns a false sense of GPIO state. I think it would be good a sleep of 50ms after the GPIO makes a difference. Maybe the GPIO expander driver needs to take this into account.

Reality is that once the Bluetooth driver toggled the GPIO, it goes onto initializing the chip. One other reason might be that no device wakeup GPIO is wired here, that the chip actually needs some time before it is all good to go.

Regards

Marcel

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Eric,

>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>>> 
>>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>>> 
>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>>> ---
>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>>> 
>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>> index cf53436..b7f79f1 100644
>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>> @@ -131,6 +131,18 @@
>>>>>>>> 
>>>>>>>> &uart0 {
>>>>>>>> 	pinctrl-names = "default";
>>>>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>>> +	status = "okay";
>>>>>>>> +
>>>>>>>> +	bluetooth {
>>>>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>>>>> +		max-speed = <2000000>;
>>>>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>>> +	};
>>>>>>>> +};
>>>>>>> 
>>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>>> 
>>>>>> Yes, unload and reload works fine. 
>>>>>> 
>>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>>> 
>>>>>> I assume that, because reload works as expected. 
>>>>> 
>>>>> awesome. That is good news.
>>>>> 
>>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>>> 
>>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>>>> 
>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>> 
>>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>>>> 
>>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>>> 
>>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
>> 
>> I will try, but this could also be an "issue" of the gpio expander
>> driver. AFAIK the expander is connected via I2C to the GPU. In case
>> the mailbox reply come before the I2C command has been handled by the
>> GPIO expander, we are running out of sync.
> 
> The mailbox command for setting GPIO state is synchronous in terms of
> sending the i2c command to the GPIO expander HW.

does that mean the driver does this correctly and really waits for the completion. Or does the GPIO expander might return to quickly and returns a false sense of GPIO state. I think it would be good a sleep of 50ms after the GPIO makes a difference. Maybe the GPIO expander driver needs to take this into account.

Reality is that once the Bluetooth driver toggled the GPIO, it goes onto initializing the chip. One other reason might be that no device wakeup GPIO is wired here, that the chip actually needs some time before it is all good to go.

Regards

Marcel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Eric Anholt]

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

Marcel Holtmann <marcel@holtmann.org> writes:

> Hi Eric,
>
>>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>>>> 
>>>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>>>> 
>>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>>>> ---
>>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>>>> 
>>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>> index cf53436..b7f79f1 100644
>>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>> @@ -131,6 +131,18 @@
>>>>>>>>> 
>>>>>>>>> &uart0 {
>>>>>>>>> 	pinctrl-names = "default";
>>>>>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>>>> +	status = "okay";
>>>>>>>>> +
>>>>>>>>> +	bluetooth {
>>>>>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>>>>>> +		max-speed = <2000000>;
>>>>>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>>>> +	};
>>>>>>>>> +};
>>>>>>>> 
>>>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>>>> 
>>>>>>> Yes, unload and reload works fine. 
>>>>>>> 
>>>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>>>> 
>>>>>>> I assume that, because reload works as expected. 
>>>>>> 
>>>>>> awesome. That is good news.
>>>>>> 
>>>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>>>> 
>>>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>>>>> 
>>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>> 
>>>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>>>>> 
>>>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>>>> 
>>>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
>>> 
>>> I will try, but this could also be an "issue" of the gpio expander
>>> driver. AFAIK the expander is connected via I2C to the GPU. In case
>>> the mailbox reply come before the I2C command has been handled by the
>>> GPIO expander, we are running out of sync.
>> 
>> The mailbox command for setting GPIO state is synchronous in terms of
>> sending the i2c command to the GPIO expander HW.
>
> does that mean the driver does this correctly and really waits for the
> completion. Or does the GPIO expander might return to quickly and
> returns a false sense of GPIO state. I think it would be good a sleep
> of 50ms after the GPIO makes a difference. Maybe the GPIO expander
> driver needs to take this into account.

It seems unlikely that you can get to I2C stop before the GPIO expander
HW has changed the state of the output.

> Reality is that once the Bluetooth driver toggled the GPIO, it goes
> onto initializing the chip. One other reason might be that no device
> wakeup GPIO is wired here, that the chip actually needs some time
> before it is all good to go.

This seems much more likely to me.  The spec for bcm43438 is easily
googleable and has a power-on timing diagram.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 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

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Eric Anholt]

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

Marcel Holtmann <marcel@holtmann.org> writes:

> Hi Eric,
>
>>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>>>> 
>>>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>>>> 
>>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>>>> ---
>>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>>>> 
>>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>> index cf53436..b7f79f1 100644
>>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>> @@ -131,6 +131,18 @@
>>>>>>>>> 
>>>>>>>>> &uart0 {
>>>>>>>>> 	pinctrl-names = "default";
>>>>>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>>>> +	status = "okay";
>>>>>>>>> +
>>>>>>>>> +	bluetooth {
>>>>>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>>>>>> +		max-speed = <2000000>;
>>>>>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>>>> +	};
>>>>>>>>> +};
>>>>>>>> 
>>>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>>>> 
>>>>>>> Yes, unload and reload works fine. 
>>>>>>> 
>>>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>>>> 
>>>>>>> I assume that, because reload works as expected. 
>>>>>> 
>>>>>> awesome. That is good news.
>>>>>> 
>>>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>>>> 
>>>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>>>>> 
>>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>> 
>>>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>>>>> 
>>>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>>>> 
>>>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
>>> 
>>> I will try, but this could also be an "issue" of the gpio expander
>>> driver. AFAIK the expander is connected via I2C to the GPU. In case
>>> the mailbox reply come before the I2C command has been handled by the
>>> GPIO expander, we are running out of sync.
>> 
>> The mailbox command for setting GPIO state is synchronous in terms of
>> sending the i2c command to the GPIO expander HW.
>
> does that mean the driver does this correctly and really waits for the
> completion. Or does the GPIO expander might return to quickly and
> returns a false sense of GPIO state. I think it would be good a sleep
> of 50ms after the GPIO makes a difference. Maybe the GPIO expander
> driver needs to take this into account.

It seems unlikely that you can get to I2C stop before the GPIO expander
HW has changed the state of the output.

> Reality is that once the Bluetooth driver toggled the GPIO, it goes
> onto initializing the chip. One other reason might be that no device
> wakeup GPIO is wired here, that the chip actually needs some time
> before it is all good to go.

This seems much more likely to me.  The spec for bcm43438 is easily
googleable and has a power-on timing diagram.

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

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Eric Anholt]

Marcel Holtmann <marcel@holtmann.org> writes:

> Hi Eric,
>
>>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>>>> 
>>>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>>>> 
>>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>>>> ---
>>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>>>> 
>>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>> index cf53436..b7f79f1 100644
>>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>> @@ -131,6 +131,18 @@
>>>>>>>>> 
>>>>>>>>> &uart0 {
>>>>>>>>> 	pinctrl-names = "default";
>>>>>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>>>> +	status = "okay";
>>>>>>>>> +
>>>>>>>>> +	bluetooth {
>>>>>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>>>>>> +		max-speed = <2000000>;
>>>>>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>>>> +	};
>>>>>>>>> +};
>>>>>>>> 
>>>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>>>> 
>>>>>>> Yes, unload and reload works fine. 
>>>>>>> 
>>>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>>>> 
>>>>>>> I assume that, because reload works as expected. 
>>>>>> 
>>>>>> awesome. That is good news.
>>>>>> 
>>>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>>>> 
>>>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>>>>> 
>>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>> 
>>>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>>>>> 
>>>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>>>> 
>>>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
>>> 
>>> I will try, but this could also be an "issue" of the gpio expander
>>> driver. AFAIK the expander is connected via I2C to the GPU. In case
>>> the mailbox reply come before the I2C command has been handled by the
>>> GPIO expander, we are running out of sync.
>> 
>> The mailbox command for setting GPIO state is synchronous in terms of
>> sending the i2c command to the GPIO expander HW.
>
> does that mean the driver does this correctly and really waits for the
> completion. Or does the GPIO expander might return to quickly and
> returns a false sense of GPIO state. I think it would be good a sleep
> of 50ms after the GPIO makes a difference. Maybe the GPIO expander
> driver needs to take this into account.

It seems unlikely that you can get to I2C stop before the GPIO expander
HW has changed the state of the output.

> Reality is that once the Bluetooth driver toggled the GPIO, it goes
> onto initializing the chip. One other reason might be that no device
> wakeup GPIO is wired here, that the chip actually needs some time
> before it is all good to go.

This seems much more likely to me.  The spec for bcm43438 is easily
googleable and has a power-on timing diagram.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180307/0d7ba4a4/attachment.sig>

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi,

> Eric Anholt <eric@anholt.net> hat am 7. März 2018 um 23:36 geschrieben:
> 
> 
> Marcel Holtmann <marcel@holtmann.org> writes:
> 
> > Hi Eric,
> >
> >>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> >>>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
> >>>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
> >>>>>>>>> 
> >>>>>>>>> In order to keep a debug UART we need to switch to uart1.
> >>>>>>>>> 
> >>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>>>>>>>> ---
> >>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>>>>>>>> 
> >>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>>>>>> index cf53436..b7f79f1 100644
> >>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>>>>>> @@ -131,6 +131,18 @@
> >>>>>>>>> 
> >>>>>>>>> &uart0 {
> >>>>>>>>> 	pinctrl-names = "default";
> >>>>>>>>> -	pinctrl-0 = <&uart0_gpio14>;
> >>>>>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>>>>>>>> +	status = "okay";
> >>>>>>>>> +
> >>>>>>>>> +	bluetooth {
> >>>>>>>>> +		compatible = "brcm,bcm43438-bt";
> >>>>>>>>> +		max-speed = <2000000>;
> >>>>>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>>>>>>>> +	};
> >>>>>>>>> +};
> >>>>>>>> 
> >>>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> >>>>>>> 
> >>>>>>> Yes, unload and reload works fine. 
> >>>>>>> 
> >>>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
> >>>>>>> 
> >>>>>>> I assume that, because reload works as expected. 
> >>>>>> 
> >>>>>> awesome. That is good news.
> >>>>>> 
> >>>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
> >>>>> 
> >>>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
> >>>>> 
> >>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
> >>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
> >>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
> >>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
> >>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
> >>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
> >>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
> >>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
> >>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
> >>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
> >>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
> >>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
> >>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
> >>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
> >>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
> >>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
> >>>>> 
> >>>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
> >>>>> 
> >>>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
> >>>> 
> >>>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
> >>> 
> >>> I will try, but this could also be an "issue" of the gpio expander
> >>> driver. AFAIK the expander is connected via I2C to the GPU. In case
> >>> the mailbox reply come before the I2C command has been handled by the
> >>> GPIO expander, we are running out of sync.
> >> 
> >> The mailbox command for setting GPIO state is synchronous in terms of
> >> sending the i2c command to the GPIO expander HW.
> >
> > does that mean the driver does this correctly and really waits for the
> > completion. Or does the GPIO expander might return to quickly and
> > returns a false sense of GPIO state. I think it would be good a sleep
> > of 50ms after the GPIO makes a difference. Maybe the GPIO expander
> > driver needs to take this into account.
> 
> It seems unlikely that you can get to I2C stop before the GPIO expander
> HW has changed the state of the output.
> 
> > Reality is that once the Bluetooth driver toggled the GPIO, it goes
> > onto initializing the chip. One other reason might be that no device
> > wakeup GPIO is wired here, that the chip actually needs some time
> > before it is all good to go.
> 
> This seems much more likely to me.  The spec for bcm43438 is easily
> googleable and has a power-on timing diagram.

after applying this patch [1] the RPi 3 specific probing errors disappear.

But this is only a quick hack. The proper solution would be to extend hci_h5 in order to support the BCM43438.

[1] - https://github.com/lategoodbye/rpi-zero/commit/ed5900296dfb7aec7f467477440751e7367a1881

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

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

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi,

> Eric Anholt <eric@anholt.net> hat am 7. M=C3=A4rz 2018 um 23:36 geschrieb=
en:
>=20
>=20
> Marcel Holtmann <marcel@holtmann.org> writes:
>=20
> > Hi Eric,
> >
> >>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl0=
11/ttyAMA0).
> >>>>>>>>> This allows to automatically insert the bcm43438 to the bluetoo=
th
> >>>>>>>>> subsystem instead of relying on patched userspace helpers (hcia=
ttach).
> >>>>>>>>>=20
> >>>>>>>>> In order to keep a debug UART we need to switch to uart1.
> >>>>>>>>>=20
> >>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>>>>>>>> ---
> >>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>>>>>>>>=20
> >>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/ar=
m/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>>>>>> index cf53436..b7f79f1 100644
> >>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>>>>>> @@ -131,6 +131,18 @@
> >>>>>>>>>=20
> >>>>>>>>> &uart0 {
> >>>>>>>>> =09pinctrl-names =3D "default";
> >>>>>>>>> -=09pinctrl-0 =3D <&uart0_gpio14>;
> >>>>>>>>> +=09pinctrl-0 =3D <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>>>>>>>> +=09status =3D "okay";
> >>>>>>>>> +
> >>>>>>>>> +=09bluetooth {
> >>>>>>>>> +=09=09compatible =3D "brcm,bcm43438-bt";
> >>>>>>>>> +=09=09max-speed =3D <2000000>;
> >>>>>>>>> +=09=09shutdown-gpios =3D <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>>>>>>>> +=09};
> >>>>>>>>> +};
> >>>>>>>>=20
> >>>>>>>> is the shutdown GPIO working as expected with this hardware. So =
even module unload and reload works fine?
> >>>>>>>=20
> >>>>>>> Yes, unload and reload works fine.=20
> >>>>>>>=20
> >>>>>>>> Meaning we are getting back to the 115200 default baud rate on t=
he UART?
> >>>>>>>=20
> >>>>>>> I assume that, because reload works as expected.=20
> >>>>>>=20
> >>>>>> awesome. That is good news.
> >>>>>>=20
> >>>>>> Since you said that the GPIO expander driver for the RPi 3 has bee=
n accepted, did you test it there as well? If so, then it would be good to =
get a patch that also provides shutdown-gpios for RPi 3.
> >>>>>=20
> >>>>> after applying Loic's patch and the necessary patch for the RPi 3 d=
ts file (see below), i will get this output:
> >>>>>=20
> >>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
> >>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
> >>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registe=
red
> >>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
> >>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
> >>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
> >>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrat=
e (-110)
> >>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
> >>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
> >>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
> >>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
> >>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
> >>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
> >>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
> >>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
> >>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0=
f)
> >>>>>=20
> >>>>> I don't see these errors on RPi Zero W. Maybe the reason for this i=
s the lack of hardware flowcontrol on RPi 3. Or some of the downstream patc=
hes on BlueZ must be adapted for the kernel [1].
> >>>>>=20
> >>>>> Btw the bcm43438 is detected even after unloading and reloading the=
 driver. But the timeout occurs also on driver reload. Reducing the baudrat=
e to 115200 doesn't help here.
> >>>>=20
> >>>> maybe it needs some time after switching the hardware on. Have you t=
ried to sleep for a bit at the end of bcm_gpio_set_power?
> >>>=20
> >>> I will try, but this could also be an "issue" of the gpio expander
> >>> driver. AFAIK the expander is connected via I2C to the GPU. In case
> >>> the mailbox reply come before the I2C command has been handled by the
> >>> GPIO expander, we are running out of sync.
> >>=20
> >> The mailbox command for setting GPIO state is synchronous in terms of
> >> sending the i2c command to the GPIO expander HW.
> >
> > does that mean the driver does this correctly and really waits for the
> > completion. Or does the GPIO expander might return to quickly and
> > returns a false sense of GPIO state. I think it would be good a sleep
> > of 50ms after the GPIO makes a difference. Maybe the GPIO expander
> > driver needs to take this into account.
>=20
> It seems unlikely that you can get to I2C stop before the GPIO expander
> HW has changed the state of the output.
>=20
> > Reality is that once the Bluetooth driver toggled the GPIO, it goes
> > onto initializing the chip. One other reason might be that no device
> > wakeup GPIO is wired here, that the chip actually needs some time
> > before it is all good to go.
>=20
> This seems much more likely to me.  The spec for bcm43438 is easily
> googleable and has a power-on timing diagram.

after applying this patch [1] the RPi 3 specific probing errors disappear.

But this is only a quick hack. The proper solution would be to extend hci_h=
5 in order to support the BCM43438.

[1] - https://github.com/lategoodbye/rpi-zero/commit/ed5900296dfb7aec7f4674=
77440751e7367a1881

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

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Stefan Wahren]

Hi,

> Eric Anholt <eric@anholt.net> hat am 7. M?rz 2018 um 23:36 geschrieben:
> 
> 
> Marcel Holtmann <marcel@holtmann.org> writes:
> 
> > Hi Eric,
> >
> >>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
> >>>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
> >>>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
> >>>>>>>>> 
> >>>>>>>>> In order to keep a debug UART we need to switch to uart1.
> >>>>>>>>> 
> >>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> >>>>>>>>> ---
> >>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
> >>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
> >>>>>>>>> 
> >>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>>>>>> index cf53436..b7f79f1 100644
> >>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
> >>>>>>>>> @@ -131,6 +131,18 @@
> >>>>>>>>> 
> >>>>>>>>> &uart0 {
> >>>>>>>>> 	pinctrl-names = "default";
> >>>>>>>>> -	pinctrl-0 = <&uart0_gpio14>;
> >>>>>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
> >>>>>>>>> +	status = "okay";
> >>>>>>>>> +
> >>>>>>>>> +	bluetooth {
> >>>>>>>>> +		compatible = "brcm,bcm43438-bt";
> >>>>>>>>> +		max-speed = <2000000>;
> >>>>>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
> >>>>>>>>> +	};
> >>>>>>>>> +};
> >>>>>>>> 
> >>>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
> >>>>>>> 
> >>>>>>> Yes, unload and reload works fine. 
> >>>>>>> 
> >>>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
> >>>>>>> 
> >>>>>>> I assume that, because reload works as expected. 
> >>>>>> 
> >>>>>> awesome. That is good news.
> >>>>>> 
> >>>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
> >>>>> 
> >>>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
> >>>>> 
> >>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
> >>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
> >>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
> >>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
> >>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
> >>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
> >>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
> >>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
> >>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
> >>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
> >>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
> >>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
> >>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
> >>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
> >>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
> >>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
> >>>>> 
> >>>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
> >>>>> 
> >>>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
> >>>> 
> >>>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
> >>> 
> >>> I will try, but this could also be an "issue" of the gpio expander
> >>> driver. AFAIK the expander is connected via I2C to the GPU. In case
> >>> the mailbox reply come before the I2C command has been handled by the
> >>> GPIO expander, we are running out of sync.
> >> 
> >> The mailbox command for setting GPIO state is synchronous in terms of
> >> sending the i2c command to the GPIO expander HW.
> >
> > does that mean the driver does this correctly and really waits for the
> > completion. Or does the GPIO expander might return to quickly and
> > returns a false sense of GPIO state. I think it would be good a sleep
> > of 50ms after the GPIO makes a difference. Maybe the GPIO expander
> > driver needs to take this into account.
> 
> It seems unlikely that you can get to I2C stop before the GPIO expander
> HW has changed the state of the output.
> 
> > Reality is that once the Bluetooth driver toggled the GPIO, it goes
> > onto initializing the chip. One other reason might be that no device
> > wakeup GPIO is wired here, that the chip actually needs some time
> > before it is all good to go.
> 
> This seems much more likely to me.  The spec for bcm43438 is easily
> googleable and has a power-on timing diagram.

after applying this patch [1] the RPi 3 specific probing errors disappear.

But this is only a quick hack. The proper solution would be to extend hci_h5 in order to support the BCM43438.

[1] - https://github.com/lategoodbye/rpi-zero/commit/ed5900296dfb7aec7f467477440751e7367a1881

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

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Loic Poulain]

Hi Stefan,

On 8 March 2018 at 01:02, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Hi,
>
>> Eric Anholt <eric@anholt.net> hat am 7. März 2018 um 23:36 geschrieben:
>>
>>
>> Marcel Holtmann <marcel@holtmann.org> writes:
>>
>> > Hi Eric,
>> >
>> >>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>> >>>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>> >>>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>> >>>>>>>>>
>> >>>>>>>>> In order to keep a debug UART we need to switch to uart1.
>> >>>>>>>>>
>> >>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>> >>>>>>>>> ---
>> >>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>> >>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>> >>>>>>>>>
>> >>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>>>>>> index cf53436..b7f79f1 100644
>> >>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>>>>>> @@ -131,6 +131,18 @@
>> >>>>>>>>>
>> >>>>>>>>> &uart0 {
>> >>>>>>>>>     pinctrl-names = "default";
>> >>>>>>>>> -   pinctrl-0 = <&uart0_gpio14>;
>> >>>>>>>>> +   pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>> >>>>>>>>> +   status = "okay";
>> >>>>>>>>> +
>> >>>>>>>>> +   bluetooth {
>> >>>>>>>>> +           compatible = "brcm,bcm43438-bt";
>> >>>>>>>>> +           max-speed = <2000000>;
>> >>>>>>>>> +           shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>> >>>>>>>>> +   };
>> >>>>>>>>> +};
>> >>>>>>>>
>> >>>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>> >>>>>>>
>> >>>>>>> Yes, unload and reload works fine.
>> >>>>>>>
>> >>>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>> >>>>>>>
>> >>>>>>> I assume that, because reload works as expected.
>> >>>>>>
>> >>>>>> awesome. That is good news.
>> >>>>>>
>> >>>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>> >>>>>
>> >>>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>> >>>>>
>> >>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>> >>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>> >>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>> >>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>> >>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>> >>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>> >>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>> >>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>> >>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>> >>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>> >>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>> >>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>> >>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>> >>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>> >>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>> >>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>> >>>>>
>> >>>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>> >>>>>
>> >>>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>> >>>>
>> >>>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
>> >>>
>> >>> I will try, but this could also be an "issue" of the gpio expander
>> >>> driver. AFAIK the expander is connected via I2C to the GPU. In case
>> >>> the mailbox reply come before the I2C command has been handled by the
>> >>> GPIO expander, we are running out of sync.
>> >>
>> >> The mailbox command for setting GPIO state is synchronous in terms of
>> >> sending the i2c command to the GPIO expander HW.
>> >
>> > does that mean the driver does this correctly and really waits for the
>> > completion. Or does the GPIO expander might return to quickly and
>> > returns a false sense of GPIO state. I think it would be good a sleep
>> > of 50ms after the GPIO makes a difference. Maybe the GPIO expander
>> > driver needs to take this into account.
>>
>> It seems unlikely that you can get to I2C stop before the GPIO expander
>> HW has changed the state of the output.
>>
>> > Reality is that once the Bluetooth driver toggled the GPIO, it goes
>> > onto initializing the chip. One other reason might be that no device
>> > wakeup GPIO is wired here, that the chip actually needs some time
>> > before it is all good to go.
>>
>> This seems much more likely to me.  The spec for bcm43438 is easily
>> googleable and has a power-on timing diagram.
>
> after applying this patch [1] the RPi 3 specific probing errors disappear.
>
> But this is only a quick hack. The proper solution would be to extend hci_h5 in order to support the BCM43438.
>
> [1] - https://github.com/lategoodbye/rpi-zero/commit/ed5900296dfb7aec7f467477440751e7367a1881

I think this patch is perfectly acceptable, this is an hardware timing
the driver has to handle. For sure H5 would improve robustness...

Regards,
Loic

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

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Loic Poulain]

Hi Stefan,

On 8 March 2018 at 01:02, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Hi,
>
>> Eric Anholt <eric@anholt.net> hat am 7. M=C3=A4rz 2018 um 23:36 geschrie=
ben:
>>
>>
>> Marcel Holtmann <marcel@holtmann.org> writes:
>>
>> > Hi Eric,
>> >
>> >>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl=
011/ttyAMA0).
>> >>>>>>>>> This allows to automatically insert the bcm43438 to the blueto=
oth
>> >>>>>>>>> subsystem instead of relying on patched userspace helpers (hci=
attach).
>> >>>>>>>>>
>> >>>>>>>>> In order to keep a debug UART we need to switch to uart1.
>> >>>>>>>>>
>> >>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>> >>>>>>>>> ---
>> >>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>> >>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>> >>>>>>>>>
>> >>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/a=
rm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>>>>>> index cf53436..b7f79f1 100644
>> >>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>>>>>> @@ -131,6 +131,18 @@
>> >>>>>>>>>
>> >>>>>>>>> &uart0 {
>> >>>>>>>>>     pinctrl-names =3D "default";
>> >>>>>>>>> -   pinctrl-0 =3D <&uart0_gpio14>;
>> >>>>>>>>> +   pinctrl-0 =3D <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>> >>>>>>>>> +   status =3D "okay";
>> >>>>>>>>> +
>> >>>>>>>>> +   bluetooth {
>> >>>>>>>>> +           compatible =3D "brcm,bcm43438-bt";
>> >>>>>>>>> +           max-speed =3D <2000000>;
>> >>>>>>>>> +           shutdown-gpios =3D <&gpio 45 GPIO_ACTIVE_HIGH>;
>> >>>>>>>>> +   };
>> >>>>>>>>> +};
>> >>>>>>>>
>> >>>>>>>> is the shutdown GPIO working as expected with this hardware. So=
 even module unload and reload works fine?
>> >>>>>>>
>> >>>>>>> Yes, unload and reload works fine.
>> >>>>>>>
>> >>>>>>>> Meaning we are getting back to the 115200 default baud rate on =
the UART?
>> >>>>>>>
>> >>>>>>> I assume that, because reload works as expected.
>> >>>>>>
>> >>>>>> awesome. That is good news.
>> >>>>>>
>> >>>>>> Since you said that the GPIO expander driver for the RPi 3 has be=
en accepted, did you test it there as well? If so, then it would be good to=
 get a patch that also provides shutdown-gpios for RPi 3.
>> >>>>>
>> >>>>> after applying Loic's patch and the necessary patch for the RPi 3 =
dts file (see below), i will get this output:
>> >>>>>
>> >>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>> >>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>> >>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) regist=
ered
>> >>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>> >>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>> >>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>> >>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudra=
te (-110)
>> >>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>> >>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>> >>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>> >>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>> >>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 000=
0
>> >>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>> >>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>> >>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>> >>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x=
0f)
>> >>>>>
>> >>>>> I don't see these errors on RPi Zero W. Maybe the reason for this =
is the lack of hardware flowcontrol on RPi 3. Or some of the downstream pat=
ches on BlueZ must be adapted for the kernel [1].
>> >>>>>
>> >>>>> Btw the bcm43438 is detected even after unloading and reloading th=
e driver. But the timeout occurs also on driver reload. Reducing the baudra=
te to 115200 doesn't help here.
>> >>>>
>> >>>> maybe it needs some time after switching the hardware on. Have you =
tried to sleep for a bit at the end of bcm_gpio_set_power?
>> >>>
>> >>> I will try, but this could also be an "issue" of the gpio expander
>> >>> driver. AFAIK the expander is connected via I2C to the GPU. In case
>> >>> the mailbox reply come before the I2C command has been handled by th=
e
>> >>> GPIO expander, we are running out of sync.
>> >>
>> >> The mailbox command for setting GPIO state is synchronous in terms of
>> >> sending the i2c command to the GPIO expander HW.
>> >
>> > does that mean the driver does this correctly and really waits for the
>> > completion. Or does the GPIO expander might return to quickly and
>> > returns a false sense of GPIO state. I think it would be good a sleep
>> > of 50ms after the GPIO makes a difference. Maybe the GPIO expander
>> > driver needs to take this into account.
>>
>> It seems unlikely that you can get to I2C stop before the GPIO expander
>> HW has changed the state of the output.
>>
>> > Reality is that once the Bluetooth driver toggled the GPIO, it goes
>> > onto initializing the chip. One other reason might be that no device
>> > wakeup GPIO is wired here, that the chip actually needs some time
>> > before it is all good to go.
>>
>> This seems much more likely to me.  The spec for bcm43438 is easily
>> googleable and has a power-on timing diagram.
>
> after applying this patch [1] the RPi 3 specific probing errors disappear=
.
>
> But this is only a quick hack. The proper solution would be to extend hci=
_h5 in order to support the BCM43438.
>
> [1] - https://github.com/lategoodbye/rpi-zero/commit/ed5900296dfb7aec7f46=
7477440751e7367a1881

I think this patch is perfectly acceptable, this is an hardware timing
the driver has to handle. For sure H5 would improve robustness...

Regards,
Loic

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Loic Poulain]

Hi Stefan,

On 8 March 2018 at 01:02, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Hi,
>
>> Eric Anholt <eric@anholt.net> hat am 7. M?rz 2018 um 23:36 geschrieben:
>>
>>
>> Marcel Holtmann <marcel@holtmann.org> writes:
>>
>> > Hi Eric,
>> >
>> >>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>> >>>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>> >>>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>> >>>>>>>>>
>> >>>>>>>>> In order to keep a debug UART we need to switch to uart1.
>> >>>>>>>>>
>> >>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>> >>>>>>>>> ---
>> >>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>> >>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>> >>>>>>>>>
>> >>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>>>>>> index cf53436..b7f79f1 100644
>> >>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>> >>>>>>>>> @@ -131,6 +131,18 @@
>> >>>>>>>>>
>> >>>>>>>>> &uart0 {
>> >>>>>>>>>     pinctrl-names = "default";
>> >>>>>>>>> -   pinctrl-0 = <&uart0_gpio14>;
>> >>>>>>>>> +   pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>> >>>>>>>>> +   status = "okay";
>> >>>>>>>>> +
>> >>>>>>>>> +   bluetooth {
>> >>>>>>>>> +           compatible = "brcm,bcm43438-bt";
>> >>>>>>>>> +           max-speed = <2000000>;
>> >>>>>>>>> +           shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>> >>>>>>>>> +   };
>> >>>>>>>>> +};
>> >>>>>>>>
>> >>>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>> >>>>>>>
>> >>>>>>> Yes, unload and reload works fine.
>> >>>>>>>
>> >>>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>> >>>>>>>
>> >>>>>>> I assume that, because reload works as expected.
>> >>>>>>
>> >>>>>> awesome. That is good news.
>> >>>>>>
>> >>>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>> >>>>>
>> >>>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>> >>>>>
>> >>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>> >>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>> >>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>> >>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>> >>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>> >>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>> >>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>> >>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>> >>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>> >>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>> >>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>> >>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>> >>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>> >>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>> >>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>> >>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>> >>>>>
>> >>>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>> >>>>>
>> >>>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>> >>>>
>> >>>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
>> >>>
>> >>> I will try, but this could also be an "issue" of the gpio expander
>> >>> driver. AFAIK the expander is connected via I2C to the GPU. In case
>> >>> the mailbox reply come before the I2C command has been handled by the
>> >>> GPIO expander, we are running out of sync.
>> >>
>> >> The mailbox command for setting GPIO state is synchronous in terms of
>> >> sending the i2c command to the GPIO expander HW.
>> >
>> > does that mean the driver does this correctly and really waits for the
>> > completion. Or does the GPIO expander might return to quickly and
>> > returns a false sense of GPIO state. I think it would be good a sleep
>> > of 50ms after the GPIO makes a difference. Maybe the GPIO expander
>> > driver needs to take this into account.
>>
>> It seems unlikely that you can get to I2C stop before the GPIO expander
>> HW has changed the state of the output.
>>
>> > Reality is that once the Bluetooth driver toggled the GPIO, it goes
>> > onto initializing the chip. One other reason might be that no device
>> > wakeup GPIO is wired here, that the chip actually needs some time
>> > before it is all good to go.
>>
>> This seems much more likely to me.  The spec for bcm43438 is easily
>> googleable and has a power-on timing diagram.
>
> after applying this patch [1] the RPi 3 specific probing errors disappear.
>
> But this is only a quick hack. The proper solution would be to extend hci_h5 in order to support the BCM43438.
>
> [1] - https://github.com/lategoodbye/rpi-zero/commit/ed5900296dfb7aec7f467477440751e7367a1881

I think this patch is perfectly acceptable, this is an hardware timing
the driver has to handle. For sure H5 would improve robustness...

Regards,
Loic

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Loic,

>>>>>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>>>>>>> 
>>>>>>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>>>>>>> 
>>>>>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>>>>>>> 
>>>>>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>>> index cf53436..b7f79f1 100644
>>>>>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>>> @@ -131,6 +131,18 @@
>>>>>>>>>>>> 
>>>>>>>>>>>> &uart0 {
>>>>>>>>>>>>    pinctrl-names = "default";
>>>>>>>>>>>> -   pinctrl-0 = <&uart0_gpio14>;
>>>>>>>>>>>> +   pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>>>>>>> +   status = "okay";
>>>>>>>>>>>> +
>>>>>>>>>>>> +   bluetooth {
>>>>>>>>>>>> +           compatible = "brcm,bcm43438-bt";
>>>>>>>>>>>> +           max-speed = <2000000>;
>>>>>>>>>>>> +           shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>>>>>>> +   };
>>>>>>>>>>>> +};
>>>>>>>>>>> 
>>>>>>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>>>>>>> 
>>>>>>>>>> Yes, unload and reload works fine.
>>>>>>>>>> 
>>>>>>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>>>>>>> 
>>>>>>>>>> I assume that, because reload works as expected.
>>>>>>>>> 
>>>>>>>>> awesome. That is good news.
>>>>>>>>> 
>>>>>>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>>>>>>> 
>>>>>>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>>>>>>>> 
>>>>>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>>>>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>>>>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>>>>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>>>>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>>>>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>>>>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>>>>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>>>>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>>>>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>>>>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>>>>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>>>>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>>>>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>>>>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>>>>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>>>> 
>>>>>>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>>>>>>>> 
>>>>>>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>>>>>>> 
>>>>>>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
>>>>>> 
>>>>>> I will try, but this could also be an "issue" of the gpio expander
>>>>>> driver. AFAIK the expander is connected via I2C to the GPU. In case
>>>>>> the mailbox reply come before the I2C command has been handled by the
>>>>>> GPIO expander, we are running out of sync.
>>>>> 
>>>>> The mailbox command for setting GPIO state is synchronous in terms of
>>>>> sending the i2c command to the GPIO expander HW.
>>>> 
>>>> does that mean the driver does this correctly and really waits for the
>>>> completion. Or does the GPIO expander might return to quickly and
>>>> returns a false sense of GPIO state. I think it would be good a sleep
>>>> of 50ms after the GPIO makes a difference. Maybe the GPIO expander
>>>> driver needs to take this into account.
>>> 
>>> It seems unlikely that you can get to I2C stop before the GPIO expander
>>> HW has changed the state of the output.
>>> 
>>>> Reality is that once the Bluetooth driver toggled the GPIO, it goes
>>>> onto initializing the chip. One other reason might be that no device
>>>> wakeup GPIO is wired here, that the chip actually needs some time
>>>> before it is all good to go.
>>> 
>>> This seems much more likely to me.  The spec for bcm43438 is easily
>>> googleable and has a power-on timing diagram.
>> 
>> after applying this patch [1] the RPi 3 specific probing errors disappear.
>> 
>> But this is only a quick hack. The proper solution would be to extend hci_h5 in order to support the BCM43438.
>> 
>> [1] - https://github.com/lategoodbye/rpi-zero/commit/ed5900296dfb7aec7f467477440751e7367a1881
> 
> I think this patch is perfectly acceptable, this is an hardware timing
> the driver has to handle. For sure H5 would improve robustness…

don’t we have a helper function like wait for 15 msec or CTS ?

I know it is not much time that we spend sleeping here, but other hardware does not need it and thus we most likely shouldn’t force a delay on them because of one hardware without hardware flow control.

Regards

Marcel


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

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Loic,

>>>>>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>>>>>>> 
>>>>>>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>>>>>>> 
>>>>>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>>>>>>> 
>>>>>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>>> index cf53436..b7f79f1 100644
>>>>>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>>> @@ -131,6 +131,18 @@
>>>>>>>>>>>> 
>>>>>>>>>>>> &uart0 {
>>>>>>>>>>>>    pinctrl-names = "default";
>>>>>>>>>>>> -   pinctrl-0 = <&uart0_gpio14>;
>>>>>>>>>>>> +   pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>>>>>>> +   status = "okay";
>>>>>>>>>>>> +
>>>>>>>>>>>> +   bluetooth {
>>>>>>>>>>>> +           compatible = "brcm,bcm43438-bt";
>>>>>>>>>>>> +           max-speed = <2000000>;
>>>>>>>>>>>> +           shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>>>>>>> +   };
>>>>>>>>>>>> +};
>>>>>>>>>>> 
>>>>>>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>>>>>>> 
>>>>>>>>>> Yes, unload and reload works fine.
>>>>>>>>>> 
>>>>>>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>>>>>>> 
>>>>>>>>>> I assume that, because reload works as expected.
>>>>>>>>> 
>>>>>>>>> awesome. That is good news.
>>>>>>>>> 
>>>>>>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>>>>>>> 
>>>>>>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>>>>>>>> 
>>>>>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>>>>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>>>>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>>>>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>>>>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>>>>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>>>>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>>>>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>>>>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>>>>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>>>>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>>>>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>>>>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>>>>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>>>>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>>>>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>>>> 
>>>>>>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>>>>>>>> 
>>>>>>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>>>>>>> 
>>>>>>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
>>>>>> 
>>>>>> I will try, but this could also be an "issue" of the gpio expander
>>>>>> driver. AFAIK the expander is connected via I2C to the GPU. In case
>>>>>> the mailbox reply come before the I2C command has been handled by the
>>>>>> GPIO expander, we are running out of sync.
>>>>> 
>>>>> The mailbox command for setting GPIO state is synchronous in terms of
>>>>> sending the i2c command to the GPIO expander HW.
>>>> 
>>>> does that mean the driver does this correctly and really waits for the
>>>> completion. Or does the GPIO expander might return to quickly and
>>>> returns a false sense of GPIO state. I think it would be good a sleep
>>>> of 50ms after the GPIO makes a difference. Maybe the GPIO expander
>>>> driver needs to take this into account.
>>> 
>>> It seems unlikely that you can get to I2C stop before the GPIO expander
>>> HW has changed the state of the output.
>>> 
>>>> Reality is that once the Bluetooth driver toggled the GPIO, it goes
>>>> onto initializing the chip. One other reason might be that no device
>>>> wakeup GPIO is wired here, that the chip actually needs some time
>>>> before it is all good to go.
>>> 
>>> This seems much more likely to me.  The spec for bcm43438 is easily
>>> googleable and has a power-on timing diagram.
>> 
>> after applying this patch [1] the RPi 3 specific probing errors disappear.
>> 
>> But this is only a quick hack. The proper solution would be to extend hci_h5 in order to support the BCM43438.
>> 
>> [1] - https://github.com/lategoodbye/rpi-zero/commit/ed5900296dfb7aec7f467477440751e7367a1881
> 
> I think this patch is perfectly acceptable, this is an hardware timing
> the driver has to handle. For sure H5 would improve robustness…

don’t we have a helper function like wait for 15 msec or CTS ?

I know it is not much time that we spend sleeping here, but other hardware does not need it and thus we most likely shouldn’t force a delay on them because of one hardware without hardware flow control.

Regards

Marcel

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Loic,

>>>>>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>>>>>>> 
>>>>>>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>>>>>>> 
>>>>>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>>>>>>> 
>>>>>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>>> index cf53436..b7f79f1 100644
>>>>>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>>> @@ -131,6 +131,18 @@
>>>>>>>>>>>> 
>>>>>>>>>>>> &uart0 {
>>>>>>>>>>>>    pinctrl-names = "default";
>>>>>>>>>>>> -   pinctrl-0 = <&uart0_gpio14>;
>>>>>>>>>>>> +   pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>>>>>>> +   status = "okay";
>>>>>>>>>>>> +
>>>>>>>>>>>> +   bluetooth {
>>>>>>>>>>>> +           compatible = "brcm,bcm43438-bt";
>>>>>>>>>>>> +           max-speed = <2000000>;
>>>>>>>>>>>> +           shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>>>>>>> +   };
>>>>>>>>>>>> +};
>>>>>>>>>>> 
>>>>>>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>>>>>>> 
>>>>>>>>>> Yes, unload and reload works fine.
>>>>>>>>>> 
>>>>>>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>>>>>>> 
>>>>>>>>>> I assume that, because reload works as expected.
>>>>>>>>> 
>>>>>>>>> awesome. That is good news.
>>>>>>>>> 
>>>>>>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>>>>>>> 
>>>>>>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>>>>>>>> 
>>>>>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>>>>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>>>>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>>>>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>>>>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>>>>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>>>>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>>>>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>>>>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>>>>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>>>>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>>>>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>>>>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>>>>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>>>>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>>>>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>>>> 
>>>>>>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>>>>>>>> 
>>>>>>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>>>>>>> 
>>>>>>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
>>>>>> 
>>>>>> I will try, but this could also be an "issue" of the gpio expander
>>>>>> driver. AFAIK the expander is connected via I2C to the GPU. In case
>>>>>> the mailbox reply come before the I2C command has been handled by the
>>>>>> GPIO expander, we are running out of sync.
>>>>> 
>>>>> The mailbox command for setting GPIO state is synchronous in terms of
>>>>> sending the i2c command to the GPIO expander HW.
>>>> 
>>>> does that mean the driver does this correctly and really waits for the
>>>> completion. Or does the GPIO expander might return to quickly and
>>>> returns a false sense of GPIO state. I think it would be good a sleep
>>>> of 50ms after the GPIO makes a difference. Maybe the GPIO expander
>>>> driver needs to take this into account.
>>> 
>>> It seems unlikely that you can get to I2C stop before the GPIO expander
>>> HW has changed the state of the output.
>>> 
>>>> Reality is that once the Bluetooth driver toggled the GPIO, it goes
>>>> onto initializing the chip. One other reason might be that no device
>>>> wakeup GPIO is wired here, that the chip actually needs some time
>>>> before it is all good to go.
>>> 
>>> This seems much more likely to me.  The spec for bcm43438 is easily
>>> googleable and has a power-on timing diagram.
>> 
>> after applying this patch [1] the RPi 3 specific probing errors disappear.
>> 
>> But this is only a quick hack. The proper solution would be to extend hci_h5 in order to support the BCM43438.
>> 
>> [1] - https://github.com/lategoodbye/rpi-zero/commit/ed5900296dfb7aec7f467477440751e7367a1881
> 
> I think this patch is perfectly acceptable, this is an hardware timing
> the driver has to handle. For sure H5 would improve robustness?

don?t we have a helper function like wait for 15 msec or CTS ?

I know it is not much time that we spend sleeping here, but other hardware does not need it and thus we most likely shouldn?t force a delay on them because of one hardware without hardware flow control.

Regards

Marcel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Lukas Wunner]

On Thu, Mar 08, 2018 at 01:02:38AM +0100, Stefan Wahren wrote:
> > >>>>> after applying Loic's patch and the necessary patch for the
> > >>>>> RPi 3 dts file (see below), i will get this output:
> > >>>>> 
> > >>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
> > >>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
> > >>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
> > >>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
> > >>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
> > >>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
> > >>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
> > >>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
> > >>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
> > >>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
> > >>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
> > >>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
> > >>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
> > >>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
> > >>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
> > >>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
> > >>>>> 
> > >>>>> I don't see these errors on RPi Zero W. Maybe the reason for
> > >>>>> this is the lack of hardware flowcontrol on RPi 3.
> > >>>> 
> > >>>> maybe it needs some time after switching the hardware on. Have
> > >>>> you tried to sleep for a bit at the end of bcm_gpio_set_power?
>  
> after applying this patch [1] the RPi 3 specific probing errors disappear.
> 
> But this is only a quick hack. The proper solution would be to extend
> hci_h5 in order to support the BCM43438.
> 
> [1] - https://github.com/lategoodbye/rpi-zero/commit/ed5900296dfb7aec7f467477440751e7367a1881

Users of the MacBookPro13,1 and MacBookPro14,1 are reporting similar
timeouts when the Bluetooth controller is reset on ->setup.

These are the models without touchbar.  The models with touchbar
(MBP13,2, MBP13,3, MBP14,2, MBP14,3) as well as the 12" MacBooks
(MB8,1, MB9,1, MB10,1) do not suffer from this issue.

Christoph Gysin (+cc) reports that applying your patch on 4.16-rc4 gets
Bluetooth working on his MBP13,1:
https://github.com/Dunedan/mbp-2016-linux/issues/29#issuecomment-371434970

For some reason, not toggling the device_wake pin in bcm_gpio_set_power()
also fixed the issue for those users.  They did complain about stuttering
audio though.

Users of the touchbar models reported that stuttering audio only occurs
when the GNOME Bluetooth control panel is open. Closing it made the
stuttering audio go away.  But apparently on the non-touchbar models,
the stuttering persisted regardless.  Both the stuttering audio as well as
the timeouts on ->setup might be explained by a lack of hardware flow
control on those models.  The chipset (and thus the UART) is identical
on the touchbar versus non-touchbar models.  It would seem odd if Apple
did not wire CTS consistently on all models.

Thanks,

Lukas

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>>>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>>>>>> 
>>>>>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>>>>>> 
>>>>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>>>>>> ---
>>>>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>>>>>> 
>>>>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>> index cf53436..b7f79f1 100644
>>>>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>> @@ -131,6 +131,18 @@
>>>>>>>>>>> 
>>>>>>>>>>> &uart0 {
>>>>>>>>>>> 	pinctrl-names = "default";
>>>>>>>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>>>>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>>>>>> +	status = "okay";
>>>>>>>>>>> +
>>>>>>>>>>> +	bluetooth {
>>>>>>>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>>>>>>>> +		max-speed = <2000000>;
>>>>>>>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>>>>>> +	};
>>>>>>>>>>> +};
>>>>>>>>>> 
>>>>>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>>>>>> 
>>>>>>>>> Yes, unload and reload works fine. 
>>>>>>>>> 
>>>>>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>>>>>> 
>>>>>>>>> I assume that, because reload works as expected. 
>>>>>>>> 
>>>>>>>> awesome. That is good news.
>>>>>>>> 
>>>>>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>>>>>> 
>>>>>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>>>>>>> 
>>>>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>>>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>>>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>>>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>>>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>>>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>>>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>>>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>>>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>>>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>>>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>>>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>>>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>>>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>>>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>>>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>>> 
>>>>>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>>>>>>> 
>>>>>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>>>>>> 
>>>>>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
>>>>> 
>>>>> I will try, but this could also be an "issue" of the gpio expander
>>>>> driver. AFAIK the expander is connected via I2C to the GPU. In case
>>>>> the mailbox reply come before the I2C command has been handled by the
>>>>> GPIO expander, we are running out of sync.
>>>> 
>>>> The mailbox command for setting GPIO state is synchronous in terms of
>>>> sending the i2c command to the GPIO expander HW.
>>> 
>>> does that mean the driver does this correctly and really waits for the
>>> completion. Or does the GPIO expander might return to quickly and
>>> returns a false sense of GPIO state. I think it would be good a sleep
>>> of 50ms after the GPIO makes a difference. Maybe the GPIO expander
>>> driver needs to take this into account.
>> 
>> It seems unlikely that you can get to I2C stop before the GPIO expander
>> HW has changed the state of the output.
>> 
>>> Reality is that once the Bluetooth driver toggled the GPIO, it goes
>>> onto initializing the chip. One other reason might be that no device
>>> wakeup GPIO is wired here, that the chip actually needs some time
>>> before it is all good to go.
>> 
>> This seems much more likely to me.  The spec for bcm43438 is easily
>> googleable and has a power-on timing diagram.
> 
> after applying this patch [1] the RPi 3 specific probing errors disappear.
> 
> But this is only a quick hack. The proper solution would be to extend hci_h5 in order to support the BCM43438.

a lot of people are running everything in H:4 since it is a lot simpler. And since it is all wired so closely, you normally do not have bit error even on high speeds. However at the end of the day it is still an UART and running it without flow control is a bit funky.

I looked a little bit in hci_h5.c and I don’t think it is worth trying to hack serdev support into it. It looks easy on the front, but it feels so hackish. I need to check what it takes to write a plain serdev 3-Wire UART driver that can drive serdev based Broadcom devices directly. Then we might be able to easily extend it with vendor support similar to how we do it in btusb.c.

Regards

Marcel


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

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>>>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>>>>>> 
>>>>>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>>>>>> 
>>>>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>>>>>> ---
>>>>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>>>>>> 
>>>>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>> index cf53436..b7f79f1 100644
>>>>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>> @@ -131,6 +131,18 @@
>>>>>>>>>>> 
>>>>>>>>>>> &uart0 {
>>>>>>>>>>> 	pinctrl-names = "default";
>>>>>>>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>>>>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>>>>>> +	status = "okay";
>>>>>>>>>>> +
>>>>>>>>>>> +	bluetooth {
>>>>>>>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>>>>>>>> +		max-speed = <2000000>;
>>>>>>>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>>>>>> +	};
>>>>>>>>>>> +};
>>>>>>>>>> 
>>>>>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>>>>>> 
>>>>>>>>> Yes, unload and reload works fine. 
>>>>>>>>> 
>>>>>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>>>>>> 
>>>>>>>>> I assume that, because reload works as expected. 
>>>>>>>> 
>>>>>>>> awesome. That is good news.
>>>>>>>> 
>>>>>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>>>>>> 
>>>>>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>>>>>>> 
>>>>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>>>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>>>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>>>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>>>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>>>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>>>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>>>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>>>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>>>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>>>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>>>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>>>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>>>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>>>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>>>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>>> 
>>>>>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>>>>>>> 
>>>>>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>>>>>> 
>>>>>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
>>>>> 
>>>>> I will try, but this could also be an "issue" of the gpio expander
>>>>> driver. AFAIK the expander is connected via I2C to the GPU. In case
>>>>> the mailbox reply come before the I2C command has been handled by the
>>>>> GPIO expander, we are running out of sync.
>>>> 
>>>> The mailbox command for setting GPIO state is synchronous in terms of
>>>> sending the i2c command to the GPIO expander HW.
>>> 
>>> does that mean the driver does this correctly and really waits for the
>>> completion. Or does the GPIO expander might return to quickly and
>>> returns a false sense of GPIO state. I think it would be good a sleep
>>> of 50ms after the GPIO makes a difference. Maybe the GPIO expander
>>> driver needs to take this into account.
>> 
>> It seems unlikely that you can get to I2C stop before the GPIO expander
>> HW has changed the state of the output.
>> 
>>> Reality is that once the Bluetooth driver toggled the GPIO, it goes
>>> onto initializing the chip. One other reason might be that no device
>>> wakeup GPIO is wired here, that the chip actually needs some time
>>> before it is all good to go.
>> 
>> This seems much more likely to me.  The spec for bcm43438 is easily
>> googleable and has a power-on timing diagram.
> 
> after applying this patch [1] the RPi 3 specific probing errors disappear.
> 
> But this is only a quick hack. The proper solution would be to extend hci_h5 in order to support the BCM43438.

a lot of people are running everything in H:4 since it is a lot simpler. And since it is all wired so closely, you normally do not have bit error even on high speeds. However at the end of the day it is still an UART and running it without flow control is a bit funky.

I looked a little bit in hci_h5.c and I don’t think it is worth trying to hack serdev support into it. It looks easy on the front, but it feels so hackish. I need to check what it takes to write a plain serdev 3-Wire UART driver that can drive serdev based Broadcom devices directly. Then we might be able to easily extend it with vendor support similar to how we do it in btusb.c.

Regards

Marcel

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Stefan,

>>>>>>>>>>> Add BCM43438 (bluetooth) as a serdev slave device of uart0 (pl011/ttyAMA0).
>>>>>>>>>>> This allows to automatically insert the bcm43438 to the bluetooth
>>>>>>>>>>> subsystem instead of relying on patched userspace helpers (hciattach).
>>>>>>>>>>> 
>>>>>>>>>>> In order to keep a debug UART we need to switch to uart1.
>>>>>>>>>>> 
>>>>>>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>>>>>>>> ---
>>>>>>>>>>> arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 +++++++++++++-
>>>>>>>>>>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>>>>>>>>>> 
>>>>>>>>>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>> index cf53436..b7f79f1 100644
>>>>>>>>>>> --- a/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
>>>>>>>>>>> @@ -131,6 +131,18 @@
>>>>>>>>>>> 
>>>>>>>>>>> &uart0 {
>>>>>>>>>>> 	pinctrl-names = "default";
>>>>>>>>>>> -	pinctrl-0 = <&uart0_gpio14>;
>>>>>>>>>>> +	pinctrl-0 = <&uart0_gpio32 &uart0_ctsrts_gpio30>;
>>>>>>>>>>> +	status = "okay";
>>>>>>>>>>> +
>>>>>>>>>>> +	bluetooth {
>>>>>>>>>>> +		compatible = "brcm,bcm43438-bt";
>>>>>>>>>>> +		max-speed = <2000000>;
>>>>>>>>>>> +		shutdown-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
>>>>>>>>>>> +	};
>>>>>>>>>>> +};
>>>>>>>>>> 
>>>>>>>>>> is the shutdown GPIO working as expected with this hardware. So even module unload and reload works fine?
>>>>>>>>> 
>>>>>>>>> Yes, unload and reload works fine. 
>>>>>>>>> 
>>>>>>>>>> Meaning we are getting back to the 115200 default baud rate on the UART?
>>>>>>>>> 
>>>>>>>>> I assume that, because reload works as expected. 
>>>>>>>> 
>>>>>>>> awesome. That is good news.
>>>>>>>> 
>>>>>>>> Since you said that the GPIO expander driver for the RPi 3 has been accepted, did you test it there as well? If so, then it would be good to get a patch that also provides shutdown-gpios for RPi 3.
>>>>>>> 
>>>>>>> after applying Loic's patch and the necessary patch for the RPi 3 dts file (see below), i will get this output:
>>>>>>> 
>>>>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>>>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>>>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>>>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>>>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>>>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>>>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>>>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>>>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>>>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>>>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>>>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>>>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>>>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>>>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>>>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>>> 
>>>>>>> I don't see these errors on RPi Zero W. Maybe the reason for this is the lack of hardware flowcontrol on RPi 3. Or some of the downstream patches on BlueZ must be adapted for the kernel [1].
>>>>>>> 
>>>>>>> Btw the bcm43438 is detected even after unloading and reloading the driver. But the timeout occurs also on driver reload. Reducing the baudrate to 115200 doesn't help here.
>>>>>> 
>>>>>> maybe it needs some time after switching the hardware on. Have you tried to sleep for a bit at the end of bcm_gpio_set_power?
>>>>> 
>>>>> I will try, but this could also be an "issue" of the gpio expander
>>>>> driver. AFAIK the expander is connected via I2C to the GPU. In case
>>>>> the mailbox reply come before the I2C command has been handled by the
>>>>> GPIO expander, we are running out of sync.
>>>> 
>>>> The mailbox command for setting GPIO state is synchronous in terms of
>>>> sending the i2c command to the GPIO expander HW.
>>> 
>>> does that mean the driver does this correctly and really waits for the
>>> completion. Or does the GPIO expander might return to quickly and
>>> returns a false sense of GPIO state. I think it would be good a sleep
>>> of 50ms after the GPIO makes a difference. Maybe the GPIO expander
>>> driver needs to take this into account.
>> 
>> It seems unlikely that you can get to I2C stop before the GPIO expander
>> HW has changed the state of the output.
>> 
>>> Reality is that once the Bluetooth driver toggled the GPIO, it goes
>>> onto initializing the chip. One other reason might be that no device
>>> wakeup GPIO is wired here, that the chip actually needs some time
>>> before it is all good to go.
>> 
>> This seems much more likely to me.  The spec for bcm43438 is easily
>> googleable and has a power-on timing diagram.
> 
> after applying this patch [1] the RPi 3 specific probing errors disappear.
> 
> But this is only a quick hack. The proper solution would be to extend hci_h5 in order to support the BCM43438.

a lot of people are running everything in H:4 since it is a lot simpler. And since it is all wired so closely, you normally do not have bit error even on high speeds. However at the end of the day it is still an UART and running it without flow control is a bit funky.

I looked a little bit in hci_h5.c and I don?t think it is worth trying to hack serdev support into it. It looks easy on the front, but it feels so hackish. I need to check what it takes to write a plain serdev 3-Wire UART driver that can drive serdev based Broadcom devices directly. Then we might be able to easily extend it with vendor support similar to how we do it in btusb.c.

Regards

Marcel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Lukas,

>>>>>>>> after applying Loic's patch and the necessary patch for the
>>>>>>>> RPi 3 dts file (see below), i will get this output:
>>>>>>>> 
>>>>>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>>>>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>>>>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>>>>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>>>>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>>>>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>>>>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>>>>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>>>>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>>>>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>>>>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>>>>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>>>>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>>>>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>>>>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>>>>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>>>> 
>>>>>>>> I don't see these errors on RPi Zero W. Maybe the reason for
>>>>>>>> this is the lack of hardware flowcontrol on RPi 3.
>>>>>>> 
>>>>>>> maybe it needs some time after switching the hardware on. Have
>>>>>>> you tried to sleep for a bit at the end of bcm_gpio_set_power?
>> 
>> after applying this patch [1] the RPi 3 specific probing errors disappear.
>> 
>> But this is only a quick hack. The proper solution would be to extend
>> hci_h5 in order to support the BCM43438.
>> 
>> [1] - https://github.com/lategoodbye/rpi-zero/commit/ed5900296dfb7aec7f467477440751e7367a1881
> 
> Users of the MacBookPro13,1 and MacBookPro14,1 are reporting similar
> timeouts when the Bluetooth controller is reset on ->setup.
> 
> These are the models without touchbar.  The models with touchbar
> (MBP13,2, MBP13,3, MBP14,2, MBP14,3) as well as the 12" MacBooks
> (MB8,1, MB9,1, MB10,1) do not suffer from this issue.
> 
> Christoph Gysin (+cc) reports that applying your patch on 4.16-rc4 gets
> Bluetooth working on his MBP13,1:
> https://github.com/Dunedan/mbp-2016-linux/issues/29#issuecomment-371434970
> 
> For some reason, not toggling the device_wake pin in bcm_gpio_set_power()
> also fixed the issue for those users.  They did complain about stuttering
> audio though.
> 
> Users of the touchbar models reported that stuttering audio only occurs
> when the GNOME Bluetooth control panel is open. Closing it made the
> stuttering audio go away.  But apparently on the non-touchbar models,
> the stuttering persisted regardless.  Both the stuttering audio as well as
> the timeouts on ->setup might be explained by a lack of hardware flow
> control on those models.  The chipset (and thus the UART) is identical
> on the touchbar versus non-touchbar models.  It would seem odd if Apple
> did not wire CTS consistently on all models.

do you know if Apple is actually running H:4 or if they run H:5 (3-Wire) within macOS. I think the Broadcom chips will auto-detect the transport protocol. At least on the RPi3 it seems like that.

Regards

Marcel

Re: [PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Lukas,

>>>>>>>> after applying Loic's patch and the necessary patch for the
>>>>>>>> RPi 3 dts file (see below), i will get this output:
>>>>>>>> 
>>>>>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>>>>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>>>>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>>>>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>>>>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>>>>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>>>>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>>>>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>>>>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>>>>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>>>>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>>>>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>>>>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>>>>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>>>>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>>>>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>>>> 
>>>>>>>> I don't see these errors on RPi Zero W. Maybe the reason for
>>>>>>>> this is the lack of hardware flowcontrol on RPi 3.
>>>>>>> 
>>>>>>> maybe it needs some time after switching the hardware on. Have
>>>>>>> you tried to sleep for a bit at the end of bcm_gpio_set_power?
>> 
>> after applying this patch [1] the RPi 3 specific probing errors disappear.
>> 
>> But this is only a quick hack. The proper solution would be to extend
>> hci_h5 in order to support the BCM43438.
>> 
>> [1] - https://github.com/lategoodbye/rpi-zero/commit/ed5900296dfb7aec7f467477440751e7367a1881
> 
> Users of the MacBookPro13,1 and MacBookPro14,1 are reporting similar
> timeouts when the Bluetooth controller is reset on ->setup.
> 
> These are the models without touchbar.  The models with touchbar
> (MBP13,2, MBP13,3, MBP14,2, MBP14,3) as well as the 12" MacBooks
> (MB8,1, MB9,1, MB10,1) do not suffer from this issue.
> 
> Christoph Gysin (+cc) reports that applying your patch on 4.16-rc4 gets
> Bluetooth working on his MBP13,1:
> https://github.com/Dunedan/mbp-2016-linux/issues/29#issuecomment-371434970
> 
> For some reason, not toggling the device_wake pin in bcm_gpio_set_power()
> also fixed the issue for those users.  They did complain about stuttering
> audio though.
> 
> Users of the touchbar models reported that stuttering audio only occurs
> when the GNOME Bluetooth control panel is open. Closing it made the
> stuttering audio go away.  But apparently on the non-touchbar models,
> the stuttering persisted regardless.  Both the stuttering audio as well as
> the timeouts on ->setup might be explained by a lack of hardware flow
> control on those models.  The chipset (and thus the UART) is identical
> on the touchbar versus non-touchbar models.  It would seem odd if Apple
> did not wire CTS consistently on all models.

do you know if Apple is actually running H:4 or if they run H:5 (3-Wire) within macOS. I think the Broadcom chips will auto-detect the transport protocol. At least on the RPi3 it seems like that.

Regards

Marcel

[PATCH 3/4] ARM: dts: bcm2835-rpi-zero-w: Add bcm43438 serial slave

[Marcel Holtmann]

Hi Lukas,

>>>>>>>> after applying Loic's patch and the necessary patch for the
>>>>>>>> RPi 3 dts file (see below), i will get this output:
>>>>>>>> 
>>>>>>>> [    4.873246] Bluetooth: HCI UART driver ver 2.3
>>>>>>>> [    4.873260] Bluetooth: HCI UART protocol H4 registered
>>>>>>>> [    4.873265] Bluetooth: HCI UART protocol Three-wire (H5) registered
>>>>>>>> [    4.873751] Bluetooth: HCI UART protocol Broadcom registered
>>>>>>>> [    4.877279] uart-pl011 3f201000.serial: no DMA platform data
>>>>>>>> [    6.952382] Bluetooth: hci0: command 0xfc18 tx timeout
>>>>>>>> [   15.192298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
>>>>>>>> [   15.192312] Bluetooth: hci0: Failed to set baudrate
>>>>>>>> [   15.316415] Bluetooth: hci0: BCM: chip id 94
>>>>>>>> [   15.318567] Bluetooth: hci0: BCM: features 0x2e
>>>>>>>> [   15.341538] Bluetooth: hci0: BCM43430A1
>>>>>>>> [   15.341560] Bluetooth: hci0: BCM43430A1 (001.002.009) build 0000
>>>>>>>> [   19.112670] Bluetooth: hci0: BCM (001.002.009) build 0360
>>>>>>>> [  274.713732] Bluetooth: hci0: command 0x0c14 tx timeout
>>>>>>>> [  274.714085] Bluetooth: hci0: Frame reassembly failed (-84)
>>>>>>>> [  317.275941] Bluetooth: hci0: last event is not cmd complete (0x0f)
>>>>>>>> 
>>>>>>>> I don't see these errors on RPi Zero W. Maybe the reason for
>>>>>>>> this is the lack of hardware flowcontrol on RPi 3.
>>>>>>> 
>>>>>>> maybe it needs some time after switching the hardware on. Have
>>>>>>> you tried to sleep for a bit at the end of bcm_gpio_set_power?
>> 
>> after applying this patch [1] the RPi 3 specific probing errors disappear.
>> 
>> But this is only a quick hack. The proper solution would be to extend
>> hci_h5 in order to support the BCM43438.
>> 
>> [1] - https://github.com/lategoodbye/rpi-zero/commit/ed5900296dfb7aec7f467477440751e7367a1881
> 
> Users of the MacBookPro13,1 and MacBookPro14,1 are reporting similar
> timeouts when the Bluetooth controller is reset on ->setup.
> 
> These are the models without touchbar.  The models with touchbar
> (MBP13,2, MBP13,3, MBP14,2, MBP14,3) as well as the 12" MacBooks
> (MB8,1, MB9,1, MB10,1) do not suffer from this issue.
> 
> Christoph Gysin (+cc) reports that applying your patch on 4.16-rc4 gets
> Bluetooth working on his MBP13,1:
> https://github.com/Dunedan/mbp-2016-linux/issues/29#issuecomment-371434970
> 
> For some reason, not toggling the device_wake pin in bcm_gpio_set_power()
> also fixed the issue for those users.  They did complain about stuttering
> audio though.
> 
> Users of the touchbar models reported that stuttering audio only occurs
> when the GNOME Bluetooth control panel is open. Closing it made the
> stuttering audio go away.  But apparently on the non-touchbar models,
> the stuttering persisted regardless.  Both the stuttering audio as well as
> the timeouts on ->setup might be explained by a lack of hardware flow
> control on those models.  The chipset (and thus the UART) is identical
> on the touchbar versus non-touchbar models.  It would seem odd if Apple
> did not wire CTS consistently on all models.

do you know if Apple is actually running H:4 or if they run H:5 (3-Wire) within macOS. I think the Broadcom chips will auto-detect the transport protocol. At least on the RPi3 it seems like that.

Regards

Marcel