Re: [PATCH v2] arm64: dts: qcom: msm8998: Fixup uart3 gpio config for bluetooth

[Matthias Kaehlcke]

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@xxxxxxxxx>
> ---
> 
> 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
>