* [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.