From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Oliver Neukum <oneukum@suse.com>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Rajaram R <rajaram.officemail@gmail.com>,
Felipe Balbi <felipe.balbi@linux.intel.com>,
Mathias Nyman <mathias.nyman@linux.intel.com>,
Greg KH <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class
Date: Fri, 3 Jun 2016 16:21:40 +0300 [thread overview]
Message-ID: <20160603132140.GB6305@kuha.fi.intel.com> (raw)
In-Reply-To: <20160602161219.GA24772@roeck-us.net>
Hi,
On Thu, Jun 02, 2016 at 09:12:19AM -0700, Guenter Roeck wrote:
> On Thu, Jun 02, 2016 at 01:18:53PM +0300, Heikki Krogerus wrote:
> > On Wed, Jun 01, 2016 at 04:29:26PM -0700, Guenter Roeck wrote:
> > > On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver Neukum wrote:
> > > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote:
> > > > > Just noticed that the "active" file is for now read only, but it needs
> > > > > to be changed to writable. That file will of course provide means for
> > > > > the userspace to Exit and Enter modes. But please note that the
> > > > > responsibility of the dependencies between the modes, say, if a plug
> > > > > needs to be in one mode or the other in order for the partner to enter
> > > > > some specific mode, will fall on the Alternate Mode specific drivers
> > > > > once we have the altmode bus. I remember there were concerns about
> > > > > this in the original thread.
> > > >
> > > > There's one thing we haven't touched upon yet. And I cannot really find
> > > > an answer in the spec.
> > > >
> > > > What do we do if we return from S4 or S3? I think we need to restore
> > > > the ALternate Mode because our display may be running over that
> > > > Alternate Mode.
> > > > If we want to support USB persist we also need to restore data role
> > > > after S4.
> > > >
> > > I don't have an answer ... but another interesting question.
> > >
> > > How do we distinguish between alternate modes supported by a host vs.
> > > alternate modes supported by a sink ? typec_capability includes a pointer
> > > to alternate modes supportedf by the connector, but it is not clear if
> > > those are alternate modes supported as host, or alternate modes supported
> > > as device, or alternate modes supported by both.
> > >
> > > This doesn't matter much if only a fixed role is supported, but it does matter
> > > for dual role ports. A laptop will typically only support DisplayPort as host,
> > > for example.
> >
> > The DP alternate mode spec actually separates the display role from
> > Type-C role. A laptop most likely would only support the modes for
> > display host roles, but if the port was DRP port then it would still
> > do so in both Type-C roles.
> >
> > So basically, even if the display was Type-C host, it would still work
> > as a display when attached to the laptop.
> >
> > > Any idea ?
> >
> > I'm actually not sure this is a problem.
> >
> Yes, this was a bad example, since the DisplayPort mode vdo includes a flag
> indicating if the port supports source, sink, or both.
I meant that in case of DP alternate mode, there should not be a
problem.
> Let's use a different example:
> Google devices (such as power adapters) have mode '1' for firmware upgrades.
> Obviously hosts will support that, but what should the host advertise if it
> is configured as sink ?
>
> Maybe this is just my personal confusion, and there is no real problem.
> It might as well be that the Google mode VDO _should_ include a flag
> indicating if the port supports updating the partner, and/or if it supports
> being updated. For now I'll just assume that this is the case.
Well, do you think we can rely on always being able to get this detail
from VDO?
> Something else, which goes back into the symlink question. If I create the
> alternate mode devices before calling typec_register_port(), the devices won't
> have a parent and don't show up in the class directory. You previously solved
> that with the symlink. I am trying to solve it in my current code by calling
> typec_register_altmodes() from typec_register_port() - primarily because I
> don't really want to duplicate all the device creation code in my driver.
>
> In my test case, this gives me
> /sys/class/type-c/usbc0/
> usbc0.svid:18d1
> usbc0.svid:18d1/mode0
> usbc0.svid:18d1/mode0/vdo
> usbc0.svid:18d1/mode0/description
> usbc0.svid:18d1/mode0/active
> ...
> usbc0.svid:ff01
> usbc0.svid:ff01/mode0/vdo
> usbc0.svid:ff01/mode0/description
> usbc0.svid:ff01/mode0/active
>
> in addition to
> /sys/class/type-c/usbc0/
> usbc0-partner/usbc0-partner.svid:05ac
> usbc0-partner/usbc0-partner.svid:05ac/mode0
> usbc0-partner/usbc0-partner.svid:05ac/mode0/vdo
> usbc0-partner/usbc0-partner.svid:05ac/mode0/description
> usbc0-partner/usbc0-partner.svid:05ac/mode0/active
> usbc0-partner/usbc0-partner.svid:05ac/mode1
> usbc0-partner/usbc0-partner.svid:05ac/mode1/vdo
> usbc0-partner/usbc0-partner.svid:05ac/mode1/description
> usbc0-partner/usbc0-partner.svid:05ac/mode1/active
> ...
> usbc0-partner/usbc0-partner.svid:ff01
> usbc0-partner/usbc0-partner.svid:ff01/mode0
> usbc0-partner/usbc0-partner.svid:ff01/mode0/vdo
> usbc0-partner/usbc0-partner.svid:ff01/mode0/description
> usbc0-partner/usbc0-partner.svid:ff01/mode0/active
>
> (when connecting the Apple adapter), which is exactly what I would expect to see.
>
> Is this sensible ? Do we have a reason for expecting the alternate mode
> _devices_ to be created (without parent) when calling typec_register_port() ?
So if you would prefer that the class code takes care of creating the
alternate modes when typec_register_port() is called, I'm fine with
that too. Let's make it so.
Thanks,
--
heikki
next prev parent reply other threads:[~2016-06-03 13:21 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-19 12:44 [RFC PATCHv2] usb: USB Type-C Connector Class Heikki Krogerus
2016-05-19 14:47 ` Oliver Neukum
2016-05-20 11:24 ` Heikki Krogerus
2016-05-20 13:37 ` Oliver Neukum
2016-05-21 5:51 ` Guenter Roeck
2016-05-21 6:43 ` Oliver Neukum
2016-05-22 15:54 ` Guenter Roeck
2016-05-23 5:34 ` Oliver Neukum
2016-05-23 13:27 ` Guenter Roeck
2016-05-23 13:58 ` Oliver Neukum
2016-05-23 14:43 ` Guenter Roeck
2016-05-23 15:55 ` Oliver Neukum
2016-05-23 16:52 ` Guenter Roeck
2016-05-24 10:08 ` Heikki Krogerus
2016-05-24 10:18 ` Oliver Neukum
2016-05-24 11:04 ` Heikki Krogerus
2016-05-19 14:48 ` Oliver Neukum
2016-05-19 15:43 ` Greg KH
2016-05-20 10:58 ` Heikki Krogerus
2016-05-19 17:53 ` Guenter Roeck
2016-05-20 10:47 ` Heikki Krogerus
2016-05-20 17:02 ` Guenter Roeck
2016-05-23 9:23 ` Heikki Krogerus
2016-05-20 14:19 ` Oliver Neukum
2016-05-23 9:57 ` Heikki Krogerus
2016-05-23 11:25 ` Oliver Neukum
2016-05-23 17:09 ` Guenter Roeck
2016-05-24 9:06 ` Oliver Neukum
2016-05-24 9:32 ` Heikki Krogerus
2016-05-24 12:51 ` Oliver Neukum
2016-05-25 11:28 ` Heikki Krogerus
2016-05-25 15:19 ` Guenter Roeck
2016-05-27 7:30 ` Heikki Krogerus
2016-05-24 13:42 ` Guenter Roeck
2016-05-25 11:30 ` Heikki Krogerus
2016-05-25 13:12 ` Guenter Roeck
2016-05-24 19:28 ` Guenter Roeck
2016-05-25 11:51 ` Heikki Krogerus
2016-05-25 13:21 ` Guenter Roeck
2016-05-25 14:04 ` Heikki Krogerus
2016-05-25 14:20 ` Oliver Neukum
2016-05-25 14:59 ` Guenter Roeck
2016-05-27 7:29 ` Heikki Krogerus
2016-05-25 18:35 ` [RFC PATCH] usb: typec: Various API updates and fixes Guenter Roeck
2016-05-27 7:55 ` Heikki Krogerus
2016-05-27 14:06 ` Guenter Roeck
2016-05-30 12:48 ` Heikki Krogerus
2016-05-30 13:19 ` [RFC PATCHv2] usb: USB Type-C Connector Class Heikki Krogerus
2016-05-30 13:59 ` Oliver Neukum
2016-05-31 8:31 ` Heikki Krogerus
2016-05-31 8:48 ` Oliver Neukum
2016-05-31 12:09 ` Heikki Krogerus
2016-05-31 12:43 ` Heikki Krogerus
2016-05-31 17:20 ` Guenter Roeck
2016-06-01 8:23 ` Heikki Krogerus
2016-06-01 8:31 ` Oliver Neukum
2016-06-01 9:04 ` Oliver Neukum
2016-06-01 13:34 ` Guenter Roeck
2016-06-02 6:24 ` Oliver Neukum
2016-06-02 6:37 ` Guenter Roeck
2016-06-02 7:43 ` Oliver Neukum
2016-05-31 17:14 ` Guenter Roeck
2016-06-01 9:26 ` Oliver Neukum
2016-06-01 23:29 ` Guenter Roeck
2016-06-02 6:30 ` Oliver Neukum
2016-06-02 8:27 ` Heikki Krogerus
2016-06-02 10:18 ` Heikki Krogerus
2016-06-02 16:12 ` Guenter Roeck
2016-06-03 13:21 ` Heikki Krogerus [this message]
2016-06-03 13:51 ` Guenter Roeck
2016-06-03 15:17 ` Heikki Krogerus
2016-06-03 18:39 ` Guenter Roeck
2016-06-06 13:28 ` Heikki Krogerus
2016-06-06 13:35 ` Oliver Neukum
2016-06-07 8:23 ` Heikki Krogerus
2016-06-07 16:57 ` Guenter Roeck
2016-06-02 8:02 ` Heikki Krogerus
2016-06-03 20:20 ` Pavel Machek
2016-06-06 13:45 ` Heikki Krogerus
2016-06-06 14:41 ` Greg KH
2016-06-07 8:25 ` Heikki Krogerus
2016-06-06 16:02 ` Guenter Roeck
2016-06-10 14:34 ` [RFC PATCHv3] " Heikki Krogerus
2016-06-11 7:05 ` Oliver Neukum
2016-06-11 18:03 ` Guenter Roeck
2016-06-13 7:49 ` Heikki Krogerus
2016-06-13 7:48 ` Heikki Krogerus
2016-06-21 13:08 ` [RFC PATCHv2] " Oliver Neukum
2016-06-21 13:24 ` Guenter Roeck
2016-06-21 19:43 ` Oliver Neukum
2016-06-21 21:37 ` Guenter Roeck
2016-06-21 13:58 ` Heikki Krogerus
2016-06-21 20:43 ` Oliver Neukum
2016-06-22 9:31 ` Heikki Krogerus
2016-06-22 10:08 ` Oliver Neukum
2016-06-22 11:19 ` Heikki Krogerus
2016-08-07 21:37 ` Pavel Machek
2016-08-08 8:52 ` Oliver Neukum
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=20160603132140.GB6305@kuha.fi.intel.com \
--to=heikki.krogerus@linux.intel.com \
--cc=andy.shevchenko@gmail.com \
--cc=felipe.balbi@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mathias.nyman@linux.intel.com \
--cc=oneukum@suse.com \
--cc=rajaram.officemail@gmail.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).