lkml.org 
[lkml]   [2020]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/3] usb: typec: Add QCOM PMIC typec detection driver
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@codeaurora.org>
> > ---
> > 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

\
 
 \ /
  Last update: 2020-06-10 21:39    [W:0.106 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site