On Tue 09 Jun 18:20 PDT 2020, Jack Pham wrote: > Hi Wesley, > > On Tue, Jun 09, 2020 at 01:58:49PM -0700, Wesley Cheng wrote: > > The QCOM SPMI typec driver handles the role and orientation detection, and > > notifies client drivers using the USB role switch framework. It registers > > as a typec port, so orientation can be communicated using the typec switch > > APIs. The driver also registers the VBUS output regulator, so client > > Doesn't look like it.. As we discussed in earlier revisions we decided > to drop the regulator. > > > drivers can enable the VBUS source when acting as a source/host. > > > > Signed-off-by: Wesley Cheng <wcheng@xxxxxxxxxxxxxx> > > --- > > drivers/usb/typec/Kconfig | 11 ++ > > drivers/usb/typec/Makefile | 1 + > > drivers/usb/typec/qcom-pmic-typec.c | 278 ++++++++++++++++++++++++++++++++++++ > > 3 files changed, 290 insertions(+) > > create mode 100644 drivers/usb/typec/qcom-pmic-typec.c > > > > diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig > > index 559dd06..8de2520 100644 > > --- a/drivers/usb/typec/Kconfig > > +++ b/drivers/usb/typec/Kconfig > > @@ -73,6 +73,17 @@ config TYPEC_TPS6598X > > If you choose to build this driver as a dynamically linked module, the > > module will be called tps6598x.ko. > > > > +config TYPEC_QCOM_PMIC > > + tristate "Qualcomm PMIC USB typec driver" > > + depends on ARCH_QCOM > > + help > > + Driver for supporting role switch over the Qualcomm PMIC. This will > > + handle the type C role and orientation detection reported by the QCOM > > + PMIC if the PMIC has the capability to handle type C detection. > > + > > + It will also enable the VBUS output to connected devices when a > > + DFP connection is made. > > + > > source "drivers/usb/typec/mux/Kconfig" > > > > source "drivers/usb/typec/altmodes/Kconfig" > > diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile > > index 7753a5c3..cceffd9 100644 > > --- a/drivers/usb/typec/Makefile > > +++ b/drivers/usb/typec/Makefile > > @@ -6,4 +6,5 @@ obj-$(CONFIG_TYPEC_TCPM) += tcpm/ > > obj-$(CONFIG_TYPEC_UCSI) += ucsi/ > > obj-$(CONFIG_TYPEC_HD3SS3220) += hd3ss3220.o > > obj-$(CONFIG_TYPEC_TPS6598X) += tps6598x.o > > +obj-$(CONFIG_TYPEC_QCOM_PMIC) += qcom-pmic-typec.o > > obj-$(CONFIG_TYPEC) += mux/ > > diff --git a/drivers/usb/typec/qcom-pmic-typec.c b/drivers/usb/typec/qcom-pmic-typec.c > > new file mode 100644 > > index 0000000..ce6319c > > --- /dev/null > > +++ b/drivers/usb/typec/qcom-pmic-typec.c > > @@ -0,0 +1,278 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (c) 2020, The Linux Foundation. All rights reserved. > > + */ > > + > > +#include <linux/err.h> > > +#include <linux/regmap.h> > > +#include <linux/kernel.h> > > +#include <linux/module.h> > > +#include <linux/slab.h> > > +#include <linux/interrupt.h> > > +#include <linux/of_irq.h> > > +#include <linux/platform_device.h> > > +#include <linux/of_device.h> > > +#include <linux/usb/role.h> > > +#include <linux/usb/typec_mux.h> > > +#include <linux/workqueue.h> > > +#include <linux/regulator/consumer.h> > > +#include <linux/regulator/driver.h> > > +#include <linux/regulator/machine.h> > > + > > +#define DCDC_BASE 0x1100 > > along with USB_BASE @ 0x1300, is it ok to allow this driver to access > registers outside of its 'reg' base (0x1500 according to the DT > bindings)? > Depending on how entangled a future driver for the charger blocks would be one could either just upstream a dcdc regulator driver to control vbus today, or a "lite version" of a charging driver exposing just the vbus regulator. Either way I would prefer this over poking the register directly from this driver, as it will make it tricky to migrate to a proper charger driver later. Regards, Bjorn
