lkml.org 
[lkml]   [2016]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface
On Wed, Feb 10, 2016 at 12:30:42PM +0200, Heikki Krogerus wrote:
> On Tue, Feb 09, 2016 at 10:21:55AM -0800, Greg KH wrote:
> > On Tue, Feb 09, 2016 at 07:01:22PM +0200, Heikki Krogerus wrote:
> > > USB Type-C Connector System Software Interface (UCSI) is a
> > > specification that defines registers and data structures
> > > used to interface with the USB Type-C connectors on a system.
> > >
> > > The specification is public and available at:
> > > http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
> > >
> >
> > What does this driver / code actually do? Why is it needed? What
> > interface to the rest of the kernel / userspace does it provide?
>
> I will fix this describe these things in the commit message. I'll just
> but some UCSI background in case somebody is interested. So UCSI is in
> practice a standard for USB Type-C controllers..
>

Does this UCSI spec has some similar things with USB Type-C Port
Controller Interface Spec at usb.org? If not, how to co-work
together in future?

Peter

> UCSI is the control interface for USB Type-C connectors (regardless
> was USB PD supported or not) in MS Windows, so most likely all new HW
> platforms designed to work also with Windows that are equipped with
> USB Type-C will have UCSI device for controlling the USB Type-C ports.
> In some cases the hardware for Type-C will be just a PHY like fusb30x
> on these platforms (it's cheaper then USB PD or complete USB Type-C
> controller), but in those cases the PHY is probable attached to an EC
> or is completely controlled by system FW like BIOS together with any
> USB PD communication in cases where USB PD is supported, and is in any
> case not visible to the OS. Instead UCSI device is exposed to the OS
> to give it means to apply its policies to the USB Type-C port.
>
> > Why would we care about this?
>
> I'll try to explain why it's important to export the control of USB
> Type-C ports to the user space in my answer to your comments to the
> first patch of this series, the one introducing the class.
>
> But surely everybody agrees that decision about the policies regarding
> USB Type-C ports, like which data role to use, do we charge or are we
> letting the other end charge, etc., belongs to the user? If you plug
> your phone to your desktop, I would imagine that you want to see the
> phone primarily as the USB device and the desktop as host, and to
> achieve the device role, you don't want to be forced to unplug/replug
> your phone from the desktop until you achieve device role, right?
>
> > You need to describe this a lot better than you did...
>
> Sure thing. I'm sorry about the poor description. I send these out too
> hastily.
>
>
> Thanks,
>
> --
> heikki
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

--

Best Regards,
Peter Chen

\
 
 \ /
  Last update: 2016-02-18 10:41    [W:0.183 / U:17.800 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site