* [PATCH v2] arm64: dts: qcom: msm8998: Fixup uart3 gpio config for bluetooth
@ 2019-10-21 16:19 Jeffrey Hugo
2019-10-21 19:58 ` Matthias Kaehlcke
0 siblings, 1 reply; 4+ messages in thread
From: Jeffrey Hugo @ 2019-10-21 16:19 UTC (permalink / raw)
To: agross, bjorn.andersson; +Cc: linux-arm-msm, linux-kernel, Jeffrey Hugo
It turns out that the wcn3990 can float the gpio lines during bootup, etc
which will result in the uart core thinking there is incoming data. This
results in the bluetooth stack getting garbage. By applying a bias to
match what wcn3990 would drive, the issue is corrected.
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
---
v2:
-split out pinctrl config by pin
.../boot/dts/qcom/msm8998-clamshell.dtsi | 22 ++++++++++++++++
arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi | 22 ++++++++++++++++
arch/arm64/boot/dts/qcom/msm8998-pins.dtsi | 25 ++++++++++++++++---
3 files changed, 65 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
index 38a1c2ba5e83..8c9a3e0f3843 100644
--- a/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
@@ -37,6 +37,28 @@
};
};
+&blsp1_uart3_on {
+ rx {
+ /delete-property/ bias-disable;
+ /*
+ * Configure a pull-up on 45 (RX). This is needed to
+ * avoid garbage data when the TX pin of the Bluetooth
+ * module is in tri-state (module powered off or not
+ * driving the signal yet).
+ */
+ bias-pull-up;
+ };
+
+ cts {
+ /delete-property/ bias-disable;
+ /*
+ * Configure a pull-down on 47 (CTS) to match the pull
+ * of the Bluetooth module.
+ */
+ bias-pull-down;
+ };
+};
+
&qusb2phy {
status = "okay";
diff --git a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
index 8adb4969baec..74c14f50b0f6 100644
--- a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
@@ -37,6 +37,28 @@
};
};
+&blsp1_uart3_on {
+ rx {
+ /delete-property/ bias-disable;
+ /*
+ * Configure a pull-up on 45 (RX). This is needed to
+ * avoid garbage data when the TX pin of the Bluetooth
+ * module is in tri-state (module powered off or not
+ * driving the signal yet).
+ */
+ bias-pull-up;
+ };
+
+ cts {
+ /delete-property/ bias-disable;
+ /*
+ * Configure a pull-down on 47 (CTS) to match the pull
+ * of the Bluetooth module.
+ */
+ bias-pull-down;
+ };
+};
+
&blsp2_uart1 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi
index e32d3ab395ea..7c222cbf19d9 100644
--- a/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi
@@ -77,13 +77,30 @@
};
blsp1_uart3_on: blsp1_uart3_on {
- mux {
- pins = "gpio45", "gpio46", "gpio47", "gpio48";
+ tx {
+ pins = "gpio45";
function = "blsp_uart3_a";
+ drive-strength = <2>;
+ bias-disable;
};
- config {
- pins = "gpio45", "gpio46", "gpio47", "gpio48";
+ rx {
+ pins = "gpio46";
+ function = "blsp_uart3_a";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cts {
+ pins = "gpio47";
+ function = "blsp_uart3_a";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ rfr {
+ pins = "gpio48";
+ function = "blsp_uart3_a";
drive-strength = <2>;
bias-disable;
};
--
2.17.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v2] arm64: dts: qcom: msm8998: Fixup uart3 gpio config for bluetooth
2019-10-21 16:19 [PATCH v2] arm64: dts: qcom: msm8998: Fixup uart3 gpio config for bluetooth Jeffrey Hugo
@ 2019-10-21 19:58 ` Matthias Kaehlcke
2019-10-21 20:28 ` Jeffrey Hugo
0 siblings, 1 reply; 4+ messages in thread
From: Matthias Kaehlcke @ 2019-10-21 19:58 UTC (permalink / raw)
To: Jeffrey Hugo; +Cc: agross, bjorn.andersson, linux-arm-msm, linux-kernel
On Mon, Oct 21, 2019 at 09:19:21AM -0700, Jeffrey Hugo wrote:
> It turns out that the wcn3990 can float the gpio lines during bootup, etc
> which will result in the uart core thinking there is incoming data. This
> results in the bluetooth stack getting garbage. By applying a bias to
> match what wcn3990 would drive, the issue is corrected.
>
> Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
> ---
>
> v2:
> -split out pinctrl config by pin
>
> .../boot/dts/qcom/msm8998-clamshell.dtsi | 22 ++++++++++++++++
> arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi | 22 ++++++++++++++++
> arch/arm64/boot/dts/qcom/msm8998-pins.dtsi | 25 ++++++++++++++++---
> 3 files changed, 65 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
> index 38a1c2ba5e83..8c9a3e0f3843 100644
> --- a/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
> @@ -37,6 +37,28 @@
> };
> };
>
> +&blsp1_uart3_on {
> + rx {
> + /delete-property/ bias-disable;
> + /*
> + * Configure a pull-up on 45 (RX). This is needed to
> + * avoid garbage data when the TX pin of the Bluetooth
> + * module is in tri-state (module powered off or not
> + * driving the signal yet).
> + */
> + bias-pull-up;
> + };
> +
> + cts {
> + /delete-property/ bias-disable;
> + /*
> + * Configure a pull-down on 47 (CTS) to match the pull
> + * of the Bluetooth module.
> + */
> + bias-pull-down;
> + };
> +};
> +
> &qusb2phy {
> status = "okay";
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
> index 8adb4969baec..74c14f50b0f6 100644
> --- a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
> @@ -37,6 +37,28 @@
> };
> };
>
> +&blsp1_uart3_on {
> + rx {
> + /delete-property/ bias-disable;
> + /*
> + * Configure a pull-up on 45 (RX). This is needed to
> + * avoid garbage data when the TX pin of the Bluetooth
> + * module is in tri-state (module powered off or not
> + * driving the signal yet).
> + */
> + bias-pull-up;
> + };
> +
> + cts {
> + /delete-property/ bias-disable;
> + /*
> + * Configure a pull-down on 47 (CTS) to match the pull
> + * of the Bluetooth module.
> + */
> + bias-pull-down;
> + };
> +};
> +
> &blsp2_uart1 {
> status = "okay";
> };
> diff --git a/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi
> index e32d3ab395ea..7c222cbf19d9 100644
> --- a/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi
> @@ -77,13 +77,30 @@
> };
>
> blsp1_uart3_on: blsp1_uart3_on {
> - mux {
> - pins = "gpio45", "gpio46", "gpio47", "gpio48";
> + tx {
> + pins = "gpio45";
> function = "blsp_uart3_a";
> + drive-strength = <2>;
Should the drive-strength really be configured in the .dtsi
of the SoC? I think of it as a board specific property, since it
depends on what is on the other end of the UART.
> + bias-disable;
This seems reasonable since the SoC drives the TX pin.
> };
>
> - config {
> - pins = "gpio45", "gpio46", "gpio47", "gpio48";
> + rx {
> + pins = "gpio46";
> + function = "blsp_uart3_a";
> + drive-strength = <2>;
'drive-strength' shouldn't be needed for an input pin
> + bias-disable;
In case of the input pins I'm not sure if this should/needs to be in
the .dtsi of the SoC. If it isn't really needed it would allow to
remove the '/delete-property/ bias-disable;' entries in the board
files.
> + };
> +
> + cts {
> + pins = "gpio47";
> + function = "blsp_uart3_a";
> + drive-strength = <2>;
'drive-strength' shouldn't be needed for an input pin
> + bias-disable;
> + };
> +
> + rfr {
> + pins = "gpio48";
> + function = "blsp_uart3_a";
> drive-strength = <2>;
> bias-disable;
> };
> --
> 2.17.1
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] arm64: dts: qcom: msm8998: Fixup uart3 gpio config for bluetooth
2019-10-21 19:58 ` Matthias Kaehlcke
@ 2019-10-21 20:28 ` Jeffrey Hugo
2019-10-21 20:51 ` Matthias Kaehlcke
0 siblings, 1 reply; 4+ messages in thread
From: Jeffrey Hugo @ 2019-10-21 20:28 UTC (permalink / raw)
To: Matthias Kaehlcke; +Cc: Andy Gross, Bjorn Andersson, MSM, lkml
On Mon, Oct 21, 2019 at 1:58 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> On Mon, Oct 21, 2019 at 09:19:21AM -0700, Jeffrey Hugo wrote:
> > It turns out that the wcn3990 can float the gpio lines during bootup, etc
> > which will result in the uart core thinking there is incoming data. This
> > results in the bluetooth stack getting garbage. By applying a bias to
> > match what wcn3990 would drive, the issue is corrected.
> >
> > Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
> > ---
> >
> > v2:
> > -split out pinctrl config by pin
> >
> > .../boot/dts/qcom/msm8998-clamshell.dtsi | 22 ++++++++++++++++
> > arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi | 22 ++++++++++++++++
> > arch/arm64/boot/dts/qcom/msm8998-pins.dtsi | 25 ++++++++++++++++---
> > 3 files changed, 65 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
> > index 38a1c2ba5e83..8c9a3e0f3843 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
> > @@ -37,6 +37,28 @@
> > };
> > };
> >
> > +&blsp1_uart3_on {
> > + rx {
> > + /delete-property/ bias-disable;
> > + /*
> > + * Configure a pull-up on 45 (RX). This is needed to
> > + * avoid garbage data when the TX pin of the Bluetooth
> > + * module is in tri-state (module powered off or not
> > + * driving the signal yet).
> > + */
> > + bias-pull-up;
> > + };
> > +
> > + cts {
> > + /delete-property/ bias-disable;
> > + /*
> > + * Configure a pull-down on 47 (CTS) to match the pull
> > + * of the Bluetooth module.
> > + */
> > + bias-pull-down;
> > + };
> > +};
> > +
> > &qusb2phy {
> > status = "okay";
> >
> > diff --git a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
> > index 8adb4969baec..74c14f50b0f6 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
> > @@ -37,6 +37,28 @@
> > };
> > };
> >
> > +&blsp1_uart3_on {
> > + rx {
> > + /delete-property/ bias-disable;
> > + /*
> > + * Configure a pull-up on 45 (RX). This is needed to
> > + * avoid garbage data when the TX pin of the Bluetooth
> > + * module is in tri-state (module powered off or not
> > + * driving the signal yet).
> > + */
> > + bias-pull-up;
> > + };
> > +
> > + cts {
> > + /delete-property/ bias-disable;
> > + /*
> > + * Configure a pull-down on 47 (CTS) to match the pull
> > + * of the Bluetooth module.
> > + */
> > + bias-pull-down;
> > + };
> > +};
> > +
> > &blsp2_uart1 {
> > status = "okay";
> > };
> > diff --git a/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi
> > index e32d3ab395ea..7c222cbf19d9 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi
> > @@ -77,13 +77,30 @@
> > };
> >
> > blsp1_uart3_on: blsp1_uart3_on {
> > - mux {
> > - pins = "gpio45", "gpio46", "gpio47", "gpio48";
> > + tx {
> > + pins = "gpio45";
> > function = "blsp_uart3_a";
> > + drive-strength = <2>;
>
> Should the drive-strength really be configured in the .dtsi
> of the SoC? I think of it as a board specific property, since it
> depends on what is on the other end of the UART.
I'm mostly waiting to see what Bjorn would like, but I see some value
in providing decent, sane defaults to work with to start. The
documentation I see indicates that the uart function isn't expected to
exceed a 2mA sink/source drive.
>
> > + bias-disable;
>
> This seems reasonable since the SoC drives the TX pin.
>
> > };
> >
> > - config {
> > - pins = "gpio45", "gpio46", "gpio47", "gpio48";
> > + rx {
> > + pins = "gpio46";
> > + function = "blsp_uart3_a";
> > + drive-strength = <2>;
>
> 'drive-strength' shouldn't be needed for an input pin
The hardware always configures a drive strength, its also indicates
how much the SoC is willing to sink.
>
> > + bias-disable;
>
> In case of the input pins I'm not sure if this should/needs to be in
> the .dtsi of the SoC. If it isn't really needed it would allow to
> remove the '/delete-property/ bias-disable;' entries in the board
> files.
>
> > + };
> > +
> > + cts {
> > + pins = "gpio47";
> > + function = "blsp_uart3_a";
> > + drive-strength = <2>;
>
> 'drive-strength' shouldn't be needed for an input pin
>
> > + bias-disable;
> > + };
> > +
> > + rfr {
> > + pins = "gpio48";
> > + function = "blsp_uart3_a";
> > drive-strength = <2>;
> > bias-disable;
> > };
> > --
> > 2.17.1
> >
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] arm64: dts: qcom: msm8998: Fixup uart3 gpio config for bluetooth
2019-10-21 20:28 ` Jeffrey Hugo
@ 2019-10-21 20:51 ` Matthias Kaehlcke
0 siblings, 0 replies; 4+ messages in thread
From: Matthias Kaehlcke @ 2019-10-21 20:51 UTC (permalink / raw)
To: Jeffrey Hugo; +Cc: Andy Gross, Bjorn Andersson, MSM, lkml
On Mon, Oct 21, 2019 at 02:28:46PM -0600, Jeffrey Hugo wrote:
> On Mon, Oct 21, 2019 at 1:58 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > On Mon, Oct 21, 2019 at 09:19:21AM -0700, Jeffrey Hugo wrote:
> > > It turns out that the wcn3990 can float the gpio lines during bootup, etc
> > > which will result in the uart core thinking there is incoming data. This
> > > results in the bluetooth stack getting garbage. By applying a bias to
> > > match what wcn3990 would drive, the issue is corrected.
> > >
> > > Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
> > > ---
> > >
> > > v2:
> > > -split out pinctrl config by pin
> > >
> > > .../boot/dts/qcom/msm8998-clamshell.dtsi | 22 ++++++++++++++++
> > > arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi | 22 ++++++++++++++++
> > > arch/arm64/boot/dts/qcom/msm8998-pins.dtsi | 25 ++++++++++++++++---
> > > 3 files changed, 65 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
> > > index 38a1c2ba5e83..8c9a3e0f3843 100644
> > > --- a/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi
> > > @@ -37,6 +37,28 @@
> > > };
> > > };
> > >
> > > +&blsp1_uart3_on {
> > > + rx {
> > > + /delete-property/ bias-disable;
> > > + /*
> > > + * Configure a pull-up on 45 (RX). This is needed to
> > > + * avoid garbage data when the TX pin of the Bluetooth
> > > + * module is in tri-state (module powered off or not
> > > + * driving the signal yet).
> > > + */
> > > + bias-pull-up;
> > > + };
> > > +
> > > + cts {
> > > + /delete-property/ bias-disable;
> > > + /*
> > > + * Configure a pull-down on 47 (CTS) to match the pull
> > > + * of the Bluetooth module.
> > > + */
> > > + bias-pull-down;
> > > + };
> > > +};
> > > +
> > > &qusb2phy {
> > > status = "okay";
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
> > > index 8adb4969baec..74c14f50b0f6 100644
> > > --- a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
> > > @@ -37,6 +37,28 @@
> > > };
> > > };
> > >
> > > +&blsp1_uart3_on {
> > > + rx {
> > > + /delete-property/ bias-disable;
> > > + /*
> > > + * Configure a pull-up on 45 (RX). This is needed to
> > > + * avoid garbage data when the TX pin of the Bluetooth
> > > + * module is in tri-state (module powered off or not
> > > + * driving the signal yet).
> > > + */
> > > + bias-pull-up;
> > > + };
> > > +
> > > + cts {
> > > + /delete-property/ bias-disable;
> > > + /*
> > > + * Configure a pull-down on 47 (CTS) to match the pull
> > > + * of the Bluetooth module.
> > > + */
> > > + bias-pull-down;
> > > + };
> > > +};
> > > +
> > > &blsp2_uart1 {
> > > status = "okay";
> > > };
> > > diff --git a/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi b/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi
> > > index e32d3ab395ea..7c222cbf19d9 100644
> > > --- a/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/msm8998-pins.dtsi
> > > @@ -77,13 +77,30 @@
> > > };
> > >
> > > blsp1_uart3_on: blsp1_uart3_on {
> > > - mux {
> > > - pins = "gpio45", "gpio46", "gpio47", "gpio48";
> > > + tx {
> > > + pins = "gpio45";
> > > function = "blsp_uart3_a";
> > > + drive-strength = <2>;
> >
> > Should the drive-strength really be configured in the .dtsi
> > of the SoC? I think of it as a board specific property, since it
> > depends on what is on the other end of the UART.
>
> I'm mostly waiting to see what Bjorn would like, but I see some value
> in providing decent, sane defaults to work with to start. The
> documentation I see indicates that the uart function isn't expected to
> exceed a 2mA sink/source drive.
Ok, if it's a requirement of the UART function it seems reasonable to
configure it as default.
> >
> > > + bias-disable;
> >
> > This seems reasonable since the SoC drives the TX pin.
> >
> > > };
> > >
> > > - config {
> > > - pins = "gpio45", "gpio46", "gpio47", "gpio48";
> > > + rx {
> > > + pins = "gpio46";
> > > + function = "blsp_uart3_a";
> > > + drive-strength = <2>;
> >
> > 'drive-strength' shouldn't be needed for an input pin
>
> The hardware always configures a drive strength, its also indicates
> how much the SoC is willing to sink.
Thanks, I wasn't aware that the drive-strength also applies to the sink.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-10-21 20:51 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-21 16:19 [PATCH v2] arm64: dts: qcom: msm8998: Fixup uart3 gpio config for bluetooth Jeffrey Hugo
2019-10-21 19:58 ` Matthias Kaehlcke
2019-10-21 20:28 ` Jeffrey Hugo
2019-10-21 20:51 ` Matthias Kaehlcke
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.