Skip to contentSkip to conversation

power: sequencing: qcom-wcn: don't request BT enable GPIOs for wcn7850

PATCH In review Bartosz Golaszewski 2 participants 4 messages Jul 2, 2024 Power sequencing

lore
Share & tools
lore

Bartosz Golaszewski

author
#0 lore raw

PATCH 1/1 power: sequencing: qcom-wcn: don't request BT enable GPIOs for wcn7850

From: Bartosz Golaszewski <[email protected]>

Due to having many existing users of wcn7850 in the kernel, conversion of the hci_qca driver to using pwrseq exclusively must be done carefully. Right now, the Bluetooth driver requests and controls the BT enable GPIO and so the PMU pwrseq driver must not do it or we will run into problems depending on the probe ordering.

Add a flag that tells the driver not to request the BT-enable GPIO. We will remove it once the conversion of the Bluetooth driver is complete.

Signed-off-by Bartosz Golaszewski <[email protected]>
---
 drivers/power/sequencing/pwrseq-qcom-wcn.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)
drivers/power/sequencing/pwrseq-qcom-wcn.c +13 -4
index 42dacfda745e..68bcd6ec4269 100644
@@ -22,6 +22,7 @@ struct pwrseq_qcom_wcn_pdata {
 	size_t num_vregs;
 	unsigned int pwup_delay_ms;
 	unsigned int gpio_enable_delay_ms;
+	bool no_bt_gpio;
 };
 
 struct pwrseq_qcom_wcn_ctx {

@@ -212,6 +213,11 @@ static const struct pwrseq_qcom_wcn_pdata pwrseq_wcn7850_of_data = {
 	.vregs = pwrseq_wcn7850_vregs,
 	.num_vregs = ARRAY_SIZE(pwrseq_wcn7850_vregs),
 	.pwup_delay_ms = 50,
+	/*
+	 * FIXME: Remove it once the entire hci_qca driver is converted to
+	 * using the power sequencer.
+	 */
+	.no_bt_gpio = true,
 };
 
 static int pwrseq_qcom_wcn_match(struct pwrseq_device *pwrseq,

@@ -277,10 +283,13 @@ static int pwrseq_qcom_wcn_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, ret,
 				     "Failed to get all regulators\n");
 
-	ctx->bt_gpio = devm_gpiod_get_optional(dev, "bt-enable", GPIOD_OUT_LOW);
-	if (IS_ERR(ctx->bt_gpio))
-		return dev_err_probe(dev, PTR_ERR(ctx->bt_gpio),
-				     "Failed to get the Bluetooth enable GPIO\n");
+	if (!ctx->pdata->no_bt_gpio) {
+		ctx->bt_gpio = devm_gpiod_get_optional(dev, "bt-enable",
+						       GPIOD_OUT_LOW);
+		if (IS_ERR(ctx->bt_gpio))
+			return dev_err_probe(dev, PTR_ERR(ctx->bt_gpio),
+					     "Failed to get the Bluetooth enable GPIO\n");
+	}
 
 	ctx->wlan_gpio = devm_gpiod_get_optional(dev, "wlan-enable",
 						 GPIOD_OUT_LOW);
Signature · 1 line
2.43.0
#1 lore raw
Quoted 11 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

Due to having many existing users of wcn7850 in the kernel, conversion of the hci_qca driver to using pwrseq exclusively must be done carefully. Right now, the Bluetooth driver requests and controls the BT enable GPIO and so the PMU pwrseq driver must not do it or we will run into problems depending on the probe ordering.

Add a flag that tells the driver not to request the BT-enable GPIO. We will remove it once the conversion of the Bluetooth driver is complete.

This will not prevent the pinctrl conflict if both PMU and BT devices declare pinctrl for the BT_EN pin.

Quoted 6 lines
Signed-off-by Bartosz Golaszewski <[email protected]>
---
 drivers/power/sequencing/pwrseq-qcom-wcn.c | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)
Signature · 2 lines
With best wishes
Dmitry
author
#2 lore raw
Quoted 11 lines · Dmitry Baryshkov
Quoted 9 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

Due to having many existing users of wcn7850 in the kernel, conversion of the hci_qca driver to using pwrseq exclusively must be done carefully. Right now, the Bluetooth driver requests and controls the BT enable GPIO and so the PMU pwrseq driver must not do it or we will run into problems depending on the probe ordering.

Quoted 6 lines
Quoted 2 lines

Add a flag that tells the driver not to request the BT-enable GPIO. We will remove it once the conversion of the Bluetooth driver is complete.

This will not prevent the pinctrl conflict if both PMU and BT devices declare pinctrl for the BT_EN pin.

Hmm... So maybe we'll need to modify the BT driver after all. Should we see if we have the enable-gpios property in hci_qca and - if not - try to use the power sequencer? Or prioritize the sequencer first and if it doesn't match, then fall-back to the current mode of operation?

Bart

#3 lore raw
Quoted 17 lines · Bartosz Golaszewski
Quoted 14 lines · Dmitry Baryshkov
Quoted 11 lines · Bartosz Golaszewski

From: Bartosz Golaszewski <[email protected]>

Due to having many existing users of wcn7850 in the kernel, conversion of the hci_qca driver to using pwrseq exclusively must be done carefully. Right now, the Bluetooth driver requests and controls the BT enable GPIO and so the PMU pwrseq driver must not do it or we will run into problems depending on the probe ordering.

Add a flag that tells the driver not to request the BT-enable GPIO. We will remove it once the conversion of the Bluetooth driver is complete.

Quoted 8 lines
Quoted 3 lines

This will not prevent the pinctrl conflict if both PMU and BT devices declare pinctrl for the BT_EN pin.

Hmm... So maybe we'll need to modify the BT driver after all. Should we see if we have the enable-gpios property in hci_qca and - if not - try to use the power sequencer? Or prioritize the sequencer first and if it doesn't match, then fall-back to the current mode of operation?

I'd say, try powerseq first, then fallback to enable-gpio.

Signature · 2 lines
With best wishes
Dmitry