All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Angus Ainslie <angus@akkea.ca>
Cc: Peter Chen <hzpeterchen@gmail.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>,
	peter.chen@nxp.com, jun.li@nxp.com
Subject: Re: [PATCH v3] usb: typec: get the vbus source and charge values from  the devicetree
Date: Thu, 13 Sep 2018 10:34:52 -0700	[thread overview]
Message-ID: <20180913173452.GA10115@roeck-us.net> (raw)
In-Reply-To: <aa08abf87b945dc5c8268fab3cb55cbb@www.akkea.ca>

On Thu, Sep 13, 2018 at 05:10:09AM -0600, Angus Ainslie wrote:
> >
> >staging: typec: don't do vbus source disable for dead battery
> >
> >In PTN5110 design, DisableSourceVBUS command also disables the sink
> >enable signal because the EN_SNK can be used to source higher voltage,
> >and, there is only one TCPC command to disable sourcing voltage without
> >telling whether to disable 5V or the high voltage, and to keep the
> >design simple they designed the PTN5110 to disable both. with this
> >fact, we use the flag drive_vbus to check if the source vbus enable was
> >issued, if yes we then do vbus source disable, in dead battery case,
> >we never did vbus source enable, so will not issue vbus source disable
> >command.
> >
> 
> Thanks Peter, this sounds like the missing piece of information and I think
> some form of the code below will fix that.
> 
> There is still the issue that my board will need some way of controlling the
> initial state of vbus-sink.
> 
> @Guenter: would my initial patch be acceptable to set the default state of
> vbus-source and vbus-sink. Would you like some code to sanity check that
> both were not enabled at the same time ?
> 
Seems to me this is indeed a chip specific problem. I don't think a fix belongs
into the tcpm code. As mentioned before, the current status (ie drive_vbus)
should be readable from the chip. I am not sure though if we should add a
PTN5110 specific quirk to the driver to handle the situation. I am concerned
that fixing this as suggested below for PTN5110 may cause trouble with other
chips. Maybe not, but I'd rather be cautious.

Thanks,
Guenter

> >Acked-by: Peter Chen <peter.chen@nxp.com>
> >Signed-off-by: Li Jun <jun.li@nxp.com>
> >---
> > drivers/staging/typec/tcpci.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> >index 2d4fbb8aac5e..7352207224b5 100644
> >--- a/drivers/staging/typec/tcpci.c
> >+++ b/drivers/staging/typec/tcpci.c
> >@@ -381,9 +381,8 @@ static int tcpci_set_vbus(struct tcpc_dev *tcpc,
> >bool source, bool sink)
> >  struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
> >  int ret;
> >
> >- /* Disable both source and sink first before enabling anything */
> >-
> >- if (!source) {
> >+ /* Only disable source if it was enabled */
> >+ if (!source && tcpci->drive_vbus) {
> >  ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
> >     TCPC_CMD_DISABLE_SRC_VBUS);
> >  if (ret < 0)
> 
> The version of struct tcpci doesn't have a drive_vbus. Where should
> drive_vbus get set and cleared ?
> 
> Is this a more complete version of what you intended ?
> 
> diff --git a/drivers/usb/typec/tcpci.c b/drivers/usb/typec/tcpci.c
> index ac6b418b15f1..d6168163df7b 100644
> --- a/drivers/usb/typec/tcpci.c
> +++ b/drivers/usb/typec/tcpci.c
> @@ -28,6 +28,7 @@ struct tcpci {
>         struct regmap *regmap;
> 
>         bool controls_vbus;
> +       bool drive_vbus;
> 
>         struct tcpc_dev tcpc;
>         struct tcpci_data *data;
> @@ -277,7 +278,9 @@ static int tcpci_set_vbus(struct tcpc_dev *tcpc, bool
> source, bool sink)
> 
>         /* Disable both source and sink first before enabling anything */
> 
> -       if (!source) {
> +       if (!source && tcpci->drive_vbus) {
> +               tcpci->drive_vbus = false;
> +
>                 ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
>                                    TCPC_CMD_DISABLE_SRC_VBUS);
>                 if (ret < 0)
> @@ -292,6 +295,8 @@ static int tcpci_set_vbus(struct tcpc_dev *tcpc, bool
> source, bool sink)
>         }
> 
>         if (source) {
> +               tcpci->drive_vbus = true;
> +
>                 ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
>                                    TCPC_CMD_SRC_VBUS_DEFAULT);
>                 if (ret < 0)
> @@ -503,6 +508,7 @@ struct tcpci *tcpci_register_port(struct device *dev,
> struct tcpci_data *data)
>         tcpci->dev = dev;
>         tcpci->data = data;
>         tcpci->regmap = data->regmap;
> +       tcpci->drive_vbus = false;
> 
>         tcpci->tcpc.init = tcpci_init;
>         tcpci->tcpc.get_vbus = tcpci_get_vbus;
> 
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux@roeck-us.net>
To: Angus Ainslie <angus@akkea.ca>
Cc: Peter Chen <hzpeterchen@gmail.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>,
	peter.chen@nxp.com, jun.li@nxp.com
Subject: [v3] usb: typec: get the vbus source and charge values from the devicetree
Date: Thu, 13 Sep 2018 10:34:52 -0700	[thread overview]
Message-ID: <20180913173452.GA10115@roeck-us.net> (raw)

On Thu, Sep 13, 2018 at 05:10:09AM -0600, Angus Ainslie wrote:
> >
> >staging: typec: don't do vbus source disable for dead battery
> >
> >In PTN5110 design, DisableSourceVBUS command also disables the sink
> >enable signal because the EN_SNK can be used to source higher voltage,
> >and, there is only one TCPC command to disable sourcing voltage without
> >telling whether to disable 5V or the high voltage, and to keep the
> >design simple they designed the PTN5110 to disable both. with this
> >fact, we use the flag drive_vbus to check if the source vbus enable was
> >issued, if yes we then do vbus source disable, in dead battery case,
> >we never did vbus source enable, so will not issue vbus source disable
> >command.
> >
> 
> Thanks Peter, this sounds like the missing piece of information and I think
> some form of the code below will fix that.
> 
> There is still the issue that my board will need some way of controlling the
> initial state of vbus-sink.
> 
> @Guenter: would my initial patch be acceptable to set the default state of
> vbus-source and vbus-sink. Would you like some code to sanity check that
> both were not enabled at the same time ?
> 
Seems to me this is indeed a chip specific problem. I don't think a fix belongs
into the tcpm code. As mentioned before, the current status (ie drive_vbus)
should be readable from the chip. I am not sure though if we should add a
PTN5110 specific quirk to the driver to handle the situation. I am concerned
that fixing this as suggested below for PTN5110 may cause trouble with other
chips. Maybe not, but I'd rather be cautious.

Thanks,
Guenter

> >Acked-by: Peter Chen <peter.chen@nxp.com>
> >Signed-off-by: Li Jun <jun.li@nxp.com>
> >---
> > drivers/staging/typec/tcpci.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> >index 2d4fbb8aac5e..7352207224b5 100644
> >--- a/drivers/staging/typec/tcpci.c
> >+++ b/drivers/staging/typec/tcpci.c
> >@@ -381,9 +381,8 @@ static int tcpci_set_vbus(struct tcpc_dev *tcpc,
> >bool source, bool sink)
> >  struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
> >  int ret;
> >
> >- /* Disable both source and sink first before enabling anything */
> >-
> >- if (!source) {
> >+ /* Only disable source if it was enabled */
> >+ if (!source && tcpci->drive_vbus) {
> >  ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
> >     TCPC_CMD_DISABLE_SRC_VBUS);
> >  if (ret < 0)
> 
> The version of struct tcpci doesn't have a drive_vbus. Where should
> drive_vbus get set and cleared ?
> 
> Is this a more complete version of what you intended ?
> 
> diff --git a/drivers/usb/typec/tcpci.c b/drivers/usb/typec/tcpci.c
> index ac6b418b15f1..d6168163df7b 100644
> --- a/drivers/usb/typec/tcpci.c
> +++ b/drivers/usb/typec/tcpci.c
> @@ -28,6 +28,7 @@ struct tcpci {
>         struct regmap *regmap;
> 
>         bool controls_vbus;
> +       bool drive_vbus;
> 
>         struct tcpc_dev tcpc;
>         struct tcpci_data *data;
> @@ -277,7 +278,9 @@ static int tcpci_set_vbus(struct tcpc_dev *tcpc, bool
> source, bool sink)
> 
>         /* Disable both source and sink first before enabling anything */
> 
> -       if (!source) {
> +       if (!source && tcpci->drive_vbus) {
> +               tcpci->drive_vbus = false;
> +
>                 ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
>                                    TCPC_CMD_DISABLE_SRC_VBUS);
>                 if (ret < 0)
> @@ -292,6 +295,8 @@ static int tcpci_set_vbus(struct tcpc_dev *tcpc, bool
> source, bool sink)
>         }
> 
>         if (source) {
> +               tcpci->drive_vbus = true;
> +
>                 ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
>                                    TCPC_CMD_SRC_VBUS_DEFAULT);
>                 if (ret < 0)
> @@ -503,6 +508,7 @@ struct tcpci *tcpci_register_port(struct device *dev,
> struct tcpci_data *data)
>         tcpci->dev = dev;
>         tcpci->data = data;
>         tcpci->regmap = data->regmap;
> +       tcpci->drive_vbus = false;
> 
>         tcpci->tcpc.init = tcpci_init;
>         tcpci->tcpc.get_vbus = tcpci_get_vbus;
> 
> 
>

  reply	other threads:[~2018-09-13 17:35 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-06 19:26 [PATCH] usb: typec: don't disable sink or source on initialization Angus Ainslie (Purism)
2018-09-06 19:26 ` Angus Ainslie
2018-09-07  9:39 ` [PATCH] " Sergei Shtylyov
2018-09-07  9:39   ` Sergei Shtylyov
2018-09-07 10:34 ` [PATCH] " Heikki Krogerus
2018-09-07 10:34   ` Heikki Krogerus
2018-09-07 12:55   ` [PATCH] " Guenter Roeck
2018-09-07 12:55     ` Guenter Roeck
2018-09-09 14:08     ` [PATCH] " Angus Ainslie
2018-09-09 14:08       ` Angus Ainslie
2018-09-09 14:20       ` [PATCH] " Guenter Roeck
2018-09-09 14:20         ` Guenter Roeck
2018-09-09 14:36         ` [PATCH] " Angus Ainslie
2018-09-09 14:36           ` Angus Ainslie
2018-09-09 14:43           ` [PATCH] " Guenter Roeck
2018-09-09 14:43             ` Guenter Roeck
2018-09-09 18:05 ` [PATCH v2] usb: typec: get the vbus source and charge values from the devicetree Angus Ainslie (Purism)
2018-09-09 18:05   ` [v2] " Angus Ainslie
2018-09-09 19:52   ` [PATCH v2] " Guenter Roeck
2018-09-09 19:52     ` [v2] " Guenter Roeck
2018-09-09 20:09   ` [PATCH v2] " Angus Ainslie
2018-09-09 20:09     ` [v2] " Angus Ainslie
2018-09-10  7:35   ` [PATCH v2] " Heikki Krogerus
2018-09-10  7:35     ` [v2] " Heikki Krogerus
2018-09-10 13:11     ` [PATCH v2] " Angus Ainslie
2018-09-10 13:11       ` [v2] " Angus Ainslie
2018-09-10 13:43       ` [PATCH v2] " Guenter Roeck
2018-09-10 13:43         ` [v2] " Guenter Roeck
2018-09-10 14:32         ` [PATCH v2] " Angus Ainslie
2018-09-10 14:32           ` [v2] " Angus Ainslie
2018-09-10 13:49       ` [PATCH v2] " Heikki Krogerus
2018-09-10 13:49         ` [v2] " Heikki Krogerus
2018-09-11 14:59 ` [PATCH v3] " Angus Ainslie (Purism)
2018-09-11 14:59   ` [v3] " Angus Ainslie
2018-09-11 15:33   ` [PATCH v3] " Guenter Roeck
2018-09-11 15:33     ` [v3] " Guenter Roeck
2018-09-12 16:08     ` [PATCH v3] " Angus Ainslie
2018-09-12 16:08       ` [v3] " Angus Ainslie
2018-09-12 16:32       ` [PATCH v3] " Guenter Roeck
2018-09-12 16:32         ` [v3] " Guenter Roeck
2018-09-13  7:27         ` [PATCH v3] " Peter Chen
2018-09-13  7:27           ` [v3] " Peter Chen
2018-09-13 11:10           ` [PATCH v3] " Angus Ainslie
2018-09-13 11:10             ` [v3] " Angus Ainslie
2018-09-13 17:34             ` Guenter Roeck [this message]
2018-09-13 17:34               ` Guenter Roeck
2018-09-14  0:38               ` [PATCH v3] " Jun Li
2018-09-14  0:38                 ` [v3] " Jun Li
2018-09-14  0:25             ` [PATCH v3] " Jun Li
2018-09-14  0:25               ` [v3] " Jun Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180913173452.GA10115@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=angus@akkea.ca \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=hzpeterchen@gmail.com \
    --cc=jun.li@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=peter.chen@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.