| Message ID | 20191021161921.31825-1-jeffrey.l.hugo@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] arm64: dts: qcom: msm8998: Fixup uart3 gpio config for bluetooth | expand |
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 >
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 > >
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.
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; };
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(-)