Re: [PATCH RFC 06/12] usb: typec: qcom: Add gen1 Type-C port support
From: David Heidelberg
Date: Sat Sep 26 2026 - 10:45:57 EST
On 26/09/2026 16:41, Bryan O'Donoghue wrote:
On 26/09/2026 15:32, David Heidelberg wrote:
On 26/09/2026 16:22, Bryan O'Donoghue wrote:
On 26/09/2026 13:40, David Heidelberg via B4 Relay wrote:
From: David Heidelberg <david@xxxxxxx>
Add a port backend for the first generation of the Qualcomm PMIC Type-C
block, found on PM660 and PMI8998.
On gen1 the Type-C CC logic is part of the charger's USBIN peripheral
(base 0x1300) instead of the standalone Type-C peripheral used by
PM8150B and later PMICs. All Type-C events (CC state change,
tCCDebounce done, VBUS change and error) are signalled through a single
aggregate "type-c-change" interrupt, the handler re-reads TYPEC_STATUS_4
to find out what changed. The PD PHY is register compatible with PM8150B
and is reused as is.
Differences to the PM8150B backend:
- get_cc() returns -EBUSY until the hardware reports tCCDebounce done,
instead of using a software debounce.
- As a source, only the default and 1.5A Rp can be advertised, 3.0A
requests are advertised as 1.5A.
- The PBS workaround of the downstream SMB2 driver (TM_IO_DTEST4_SEL)
is applied on every power role change.
VBUS sourcing is optional and only used when the connector provides
a vbus-supply, as the charger doesn't expose a VBUS regulator yet.
Assisted-by: LLM
Co-developed-by: Alexey Minnekhanov <alexeymin@xxxxxxxxxx>
Signed-off-by: Alexey Minnekhanov <alexeymin@xxxxxxxxxx>
Signed-off-by: David Heidelberg <david@xxxxxxx>
---
drivers/usb/typec/tcpm/qcom/Makefile | 1 +
drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c | 9 +
.../typec/tcpm/qcom/qcom_pmic_typec_port_gen1.c | 605 ++++++++++ ++++++ +++++
.../typec/tcpm/qcom/qcom_pmic_typec_port_gen1.h | 15 +
4 files changed, 630 insertions(+)
[...]
+/*
+ * Failure of this workaround write is non-fatal and
+ * we can continue with the role transition.
+ */
+static void gen1_typec_pbs_wa(struct gen1_typec_port *port, bool sink)
+{
+ unsigned int val = sink ? 0 : PBS_CRUDE_SENSOR_ENABLE;
+ int ret;
+
+ ret = regmap_write(port->regmap, port->base +
+ MISC_BASE_OFFSET + TM_IO_DTEST4_SEL, val);
+ if (!ret)
+ return;
Why would the write fail and why wouldn't that be a critical case if the write did fail ?
Heya Bryan,
thanks a lot for reviewing the series. For the rest notes, I'll incorporate that and/or think about it later. Here to quickly answer to this note,
this one quirk is definitely NOT REQUIRED. Originally, I was testing the driver without it on sdm845 devices, and everything worked without it just fine. I ASSUME in some situation or with some devices combination it may come handy, thus likely if it fails, not much usually happens (and clanker was suggesting to port this one from downstream, so I did).
David
[...]
I ran this code though an LLM and it is babbling about the "shape" of things to hand you LoL.
Anyway the pattern matching part flagged this:
"Write outside the node's reg. base + MISC_BASE_OFFSET + TM_IO_DTEST4_SEL is 0x16e9, the MISC peripheral. 03 declares reg = <USBIN>, <PDPHY> only."
Worth also verifying.
Yup, I explicitly split the addr into MISC_BASE_OFFSET, as it's pretty much outside of this block range (same reason why I haven't sent the vbus patches for qcom smbx charger).
Maybe Konrad with more insight can tell more about it. In the Type-C submission I can pretty much confidently drop it (if it'll need separate driver) and still assure users get expected functionality.
David
---
bod