Hi Matthias,

On 2020-08-19 21:43, Matthias Kaehlcke wrote:

On Wed, Aug 19, 2020 at 07:19:25PM +0530, skakit@codeaurora.org wrote:

quoted

On 2020-08-17 23:31, Matthias Kaehlcke wrote:

quoted

On Fri, Jul 24, 2020 at 09:28:01AM +0530, satya priya wrote:

quoted

Add sleep pin ctrl for BT uart, and also change the bias
configuration to match Bluetooth module.

Signed-off-by: satya priya <redacted>
---
Changes in V2:
 - This patch adds sleep state for BT UART. Newly added in V2.

 arch/arm64/boot/dts/qcom/sc7180-idp.dts | 42
++++++++++++++++++++++++++++-----
 1 file changed, 36 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts

b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
index 26cc491..bc919f2 100644

--- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts

@@ -469,20 +469,50 @@

 &qup_uart3_default {
 	pinconf-cts {
-		/*
-		 * Configure a pull-down on 38 (CTS) to match the pull of
-		 * the Bluetooth module.
-		 */
+		/* Configure no pull on 38 (CTS) to match Bluetooth module */

Has the pull from the Bluetooth module been removed or did the previous
config
incorrectly claim that the Bluetooth module has a pull-down?

The previous config was incorrect, so we corrected it to match the 
pull of
BT.

The pull config of the BT controller varies depending on its state, 
could
you clarify which state you intend to match?

Since this line is driven by BT SoC, they could change their 
pull(although it's less likely). Recently on cherokee we worked with BT 
team and came to an agreement to keep no-pull from our side in order to 
not conflict with their pull in any state.

quoted

quoted

quoted

 		pins = "gpio38";
+		bias-disable;
+	};
+
+	pinconf-rts {
+		/* We'll drive 39 (RTS), so configure pull-down */
+		pins = "gpio39";
+		drive-strength = <2>;
 		bias-pull-down;
+	};
+
+	pinconf-tx {
+		/* We'll drive 40 (TX), so no pull */

The rationales for RTS and TX contradict each other. According to the
comment
the reason to configure a pull-down on RTS is that it is driven by the
host.
Then for TX the reason to configure no pull is that it is driven by the
host.

Please make sure the comments *really* describe the rationale, otherwise
they
are just confusing.

The rationale for RTS is that we don't want it to be floating and want 
to
make sure that it is pulled down, to receive bytes. Will modify the 
comment
mentioning the same.

Could you clarify what you mean with "to receive bytes"?

When we keep no-pull(floating), sometimes it may be pulled high and UART 
flow will be turned off(RFR_NOT_READY), due to this BT SoC wont be able 
to send data even though host is ready.

Thanks

Matthias

Thanks,
Satya Priya