[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20201029063138.1429760-7-badhri@google.com>
Date: Wed, 28 Oct 2020 23:31:34 -0700
From: Badhri Jagan Sridharan <badhri@...gle.com>
To: Guenter Roeck <linux@...ck-us.net>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Rob Herring <robh+dt@...nel.org>,
Lee Jones <lee.jones@...aro.org>,
Mark Brown <broonie@...nel.org>,
Maxime Ripard <mripard@...nel.org>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Thierry Reding <treding@...dia.com>,
Prashant Malani <pmalani@...omium.org>,
Badhri Jagan Sridharan <badhri@...gle.com>,
Dan Carpenter <dan.carpenter@...cle.com>
Cc: devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-usb@...r.kernel.org
Subject: [PATCH v12 06/10] usb: typec: tcpci_maxim: Fix vbus stuck on upon
diconnecting sink
Occasionally, POWER_STATUS.sourcing_vbus takes a while to clear after
writing to MAX_BUCK_BOOST_OP register. This causes vbus to turn back
on while disconnecting the sink. Overcome this issue by writing into
MAX_BUCK_BOOST_OP during frs while sourcing vbu, instead of always
into the register whenever POWER_STATUS.sourcing_vbus is set.
Signed-off-by: Badhri Jagan Sridharan <badhri@...gle.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
---
v9 is the first version of this patch. Added to fix
occasional bug of vbus turning back on when disconnecting the FRS accessory
after disconnect. No changes since v9.
Changes since v10:
Added Reviewed-by: Heikki Krogerus
Changes since v11:
none
---
drivers/usb/typec/tcpm/tcpci_maxim.c | 28 ++++++++++++++--------------
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpci_maxim.c b/drivers/usb/typec/tcpm/tcpci_maxim.c
index a5014c3b51d5..dd6171604362 100644
--- a/drivers/usb/typec/tcpm/tcpci_maxim.c
+++ b/drivers/usb/typec/tcpm/tcpci_maxim.c
@@ -238,23 +238,22 @@ static void process_power_status(struct max_tcpci_chip *chip)
if (ret < 0)
return;
- if (pwr_status == 0xff) {
+ if (pwr_status == 0xff)
max_tcpci_init_regs(chip);
- } else if (pwr_status & TCPC_POWER_STATUS_SOURCING_VBUS) {
+ else if (pwr_status & TCPC_POWER_STATUS_SOURCING_VBUS)
tcpm_sourcing_vbus(chip->port);
- /*
- * Alawys re-enable boost here.
- * In normal case, when say an headset is attached, TCPM would
- * have instructed to TCPC to enable boost, so the call is a
- * no-op.
- * But for Fast Role Swap case, Boost turns on autonomously without
- * AP intervention, but, needs AP to enable source mode explicitly
- * for AP to regain control.
- */
- max_tcpci_set_vbus(chip->tcpci, &chip->data, true, false);
- } else {
+ else
tcpm_vbus_change(chip->port);
- }
+}
+
+static void max_tcpci_frs_sourcing_vbus(struct tcpci *tcpci, struct tcpci_data *tdata)
+{
+ /*
+ * For Fast Role Swap case, Boost turns on autonomously without
+ * AP intervention, but, needs AP to enable source mode explicitly
+ * for AP to regain control.
+ */
+ max_tcpci_set_vbus(tcpci, tdata, true, false);
}
static void process_tx(struct max_tcpci_chip *chip, u16 status)
@@ -441,6 +440,7 @@ static int max_tcpci_probe(struct i2c_client *client, const struct i2c_device_id
chip->data.start_drp_toggling = max_tcpci_start_toggling;
chip->data.TX_BUF_BYTE_x_hidden = true;
chip->data.init = tcpci_init;
+ chip->data.frs_sourcing_vbus = max_tcpci_frs_sourcing_vbus;
max_tcpci_init_regs(chip);
chip->tcpci = tcpci_register_port(chip->dev, &chip->data);
--
2.29.1.341.ge80a0c044ae-goog
Powered by blists - more mailing lists