All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Angus Ainslie <angus@akkea.ca>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [v3] usb: typec: get the vbus source and charge values from the devicetree
Date: Wed, 12 Sep 2018 09:32:59 -0700	[thread overview]
Message-ID: <20180912163259.GC3300@roeck-us.net> (raw)

On Wed, Sep 12, 2018 at 10:08:58AM -0600, Angus Ainslie wrote:
> On 2018-09-11 09:33, Guenter Roeck wrote:
> >I cant put my finger on it but this seems wrong. As i said both src
> >and sink should never be true at the same time. I also din’t
> >understand why turning off src should power off your board. Ultimately
> >my concern is that we may be just painting over the real problem, and
> >that would be really bad to do with dt properties.
> >
> 
> I agree that this doesn't seem like the correct way of solving the problem.
> On this HW (Emcraft iMX8M BSB) I think the PTN5110 chip has been connected
> correctly so I'm assuming that it is some quirk of the PTN5110.
> 
> I didn't design the HW or the chip. This is a workaround for "quirky"
> hardware and there may be others that don't behave exactly as expected.
> 

I wouldn't be that sure about that. It may as well be that the tcpc driver
and/or the tcpm driver are doing something wrong when initializing.

I didn't really understand the logs you sent out earlier. It looked like
the system would loose power if the TCPC_CMD_DISABLE_SRC_VBUS command is
sent.  That doesn't really make sense to me since it indicates that the
chip sources power to the remote, and turning that off should not result
in a local loss of power.

Note that the chip is supposed to be able to report if it is sourcing vbus
and if VBUS is present, in the POWER_STATUS register. Another question is
the content of the ROLE_CONTROL register when the system boots, and the
DEVICE_CAPABILITIES settings.

Overall I suspect that we don't handle startup for your system correctly
in the tcpc driver. The ideal solution would be to find a solution which
does not require any devicetree properties, but to do that we'll need
to get a better understanding about your system's requirements.

Guenter

WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux@roeck-us.net>
To: Angus Ainslie <angus@akkea.ca>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] usb: typec: get the vbus source and charge values from  the devicetree
Date: Wed, 12 Sep 2018 09:32:59 -0700	[thread overview]
Message-ID: <20180912163259.GC3300@roeck-us.net> (raw)
In-Reply-To: <9d7431e51aa069f288dd4bf39e9db9f1@www.akkea.ca>

On Wed, Sep 12, 2018 at 10:08:58AM -0600, Angus Ainslie wrote:
> On 2018-09-11 09:33, Guenter Roeck wrote:
> >I cant put my finger on it but this seems wrong. As i said both src
> >and sink should never be true at the same time. I also din’t
> >understand why turning off src should power off your board. Ultimately
> >my concern is that we may be just painting over the real problem, and
> >that would be really bad to do with dt properties.
> >
> 
> I agree that this doesn't seem like the correct way of solving the problem.
> On this HW (Emcraft iMX8M BSB) I think the PTN5110 chip has been connected
> correctly so I'm assuming that it is some quirk of the PTN5110.
> 
> I didn't design the HW or the chip. This is a workaround for "quirky"
> hardware and there may be others that don't behave exactly as expected.
> 

I wouldn't be that sure about that. It may as well be that the tcpc driver
and/or the tcpm driver are doing something wrong when initializing.

I didn't really understand the logs you sent out earlier. It looked like
the system would loose power if the TCPC_CMD_DISABLE_SRC_VBUS command is
sent.  That doesn't really make sense to me since it indicates that the
chip sources power to the remote, and turning that off should not result
in a local loss of power.

Note that the chip is supposed to be able to report if it is sourcing vbus
and if VBUS is present, in the POWER_STATUS register. Another question is
the content of the ROLE_CONTROL register when the system boots, and the
DEVICE_CAPABILITIES settings.

Overall I suspect that we don't handle startup for your system correctly
in the tcpc driver. The ideal solution would be to find a solution which
does not require any devicetree properties, but to do that we'll need
to get a better understanding about your system's requirements.

Guenter

             reply	other threads:[~2018-09-12 16:32 UTC|newest]

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

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=20180912163259.GC3300@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=angus@akkea.ca \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /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.