From: Guenter Roeck <groeck@chromium.org>
To: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Chandra Sekhar Anagani <chandra.sekhar.anagani@intel.com>,
Bruce Ashfield <bruce.ashfield@windriver.com>,
Bin Gao <bin.gao@intel.com>,
Pranav Tipnis <pranav.tipnis@intel.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
Guenter Roeck <groeck@chromium.org>
Subject: [RFC PATCH v3 0/2] Type-C Port Manager
Date: Tue, 23 Aug 2016 14:10:49 -0700 [thread overview]
Message-ID: <1471986651-51139-1-git-send-email-groeck@chromium.org> (raw)
The following series of patches implements a USB Type-C Port Manager
using the pending USB Type-C class code as basis. The code is still WIP,
but I think it is important to get feedback from the community at this point.
There are two patches in the series. The first patch implements the Type-C
Port Manager state machine. The forth patch is an interface between the
Type-C Port Manager and a TCPCI (Type-C Port Controller Interface) compliant
USB Type-C Port Controller.
Patch 2/2 (the interface to a TCPCI compliant chip) is currently untested
since I don't have the necessary hardware available. The port manager code
was tested connecting to an Embedded Controller on a Chromebook, bypassing
the Port Manager implementation in the EC.
Both Source and Sink operation was tested with various Type-C chargers, docks,
and connectors. Alternate mode support is partially implemented (Alternate mode
support is requested from the partner), but alternate modes are not actually
selected. Implementing this will require more thought, since the actual
alternate mode support has to be implemented elsewhere, such as in a dedicated
Phy driver. It should be possible to implement the interface between phy driver
and Type-C Port Controller driver using extcon, but I have not further explored
the possibilities, and other options might be possible and/or better.
v3:
- Improve TCPM state machine resiliency if there are spurious CC line changes
while the state machine is in a transient change (waiting for a timeout)
- Update current limit after CC voltage level changes on a port which is not
PD capable.
- Applies to v6 of "USB Type-C Connector class" patch series.
v2:
- Class code no longer uses locking, so the patch to remove it is no longer
necessary.
- tcpm: Only update polarity if setting it was successful
If setting the CC line polarity in the driver was not successful,
don't update the internal polarity state.
- tcpm: All PD messages are little endian; convert to and from CPU endianness.
- tcpm: Avoid comparisons against NULL.
- tcpm: Use u8/u16/u32 instead of uint8_t/uint16_t/uint32_t consistently.
- tcpm/tcpc: Callbacks into tcpm need to be lockless to avoid timing problems
in low level drivers.
- tcpm/tcpc: Simplify callbacks; tcpm can request the current state of cc/vbus
when it is ready to use it.
- Applies to v5 of "USB Type-C Connector class" patch series.
next reply other threads:[~2016-08-23 21:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-23 21:10 Guenter Roeck [this message]
2016-08-23 21:10 ` [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm) Guenter Roeck
2016-09-10 0:26 ` Jun Li
2016-09-10 2:23 ` Guenter Roeck
2016-09-12 2:16 ` Jun Li
2016-09-12 2:23 ` Guenter Roeck
2016-09-12 2:41 ` Jun Li
2016-09-29 14:35 ` Jun Li
2016-09-29 16:36 ` Guenter Roeck
2016-09-30 6:41 ` Jun Li
2016-09-30 15:46 ` Guenter Roeck
2016-09-30 6:37 ` Jun Li
2016-09-30 19:06 ` Guenter Roeck
2016-09-30 19:41 ` Joe Perches
2016-09-30 20:57 ` Guenter Roeck
2016-09-30 21:02 ` Joe Perches
2016-10-03 14:04 ` Heikki Krogerus
2016-08-23 21:10 ` [RFC PATCH v3 2/2] usb: typec: Type-C Port Controller Interface driver (tcpci) Guenter Roeck
2016-09-30 6:24 ` Jun Li
2016-09-30 18:45 ` Guenter Roeck
2016-10-01 0:12 ` Jun Li
2016-10-01 16:27 ` Guenter Roeck
2016-08-24 12:52 ` [RFC PATCH v3 0/2] Type-C Port Manager Heikki Krogerus
2016-08-24 17:56 ` Guenter Roeck
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=1471986651-51139-1-git-send-email-groeck@chromium.org \
--to=groeck@chromium.org \
--cc=bin.gao@intel.com \
--cc=bruce.ashfield@windriver.com \
--cc=chandra.sekhar.anagani@intel.com \
--cc=felipe.balbi@linux.intel.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=pranav.tipnis@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).