Linux USB
 help / color / mirror / Atom feed
From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>,
	Alan Stern <stern@rowland.harvard.edu>
Cc: Mathias Nyman <mathias.nyman@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"open list:USB XHCI DRIVER" <linux-usb@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] xhci: Suspend ports to U3 directly from U1 or U2
Date: Wed, 10 Jun 2020 18:58:41 +0300	[thread overview]
Message-ID: <9d7842de-9813-becd-80a0-a422e59c1e94@linux.intel.com> (raw)
In-Reply-To: <591D2A1F-9645-4B0B-896C-99544F06DFAA@canonical.com>

On 10.6.2020 18.43, Kai-Heng Feng wrote:
> 
> 
>> On Jun 10, 2020, at 22:32, Alan Stern <stern@rowland.harvard.edu> wrote:
>>
>> On Wed, Jun 10, 2020 at 02:42:30PM +0800, Kai-Heng Feng wrote:
>>> xHCI spec "4.15.1 Port Suspend" states that port can be put to U3 as long
>>> as Enabled bit is set and from U0, U1 or U2 state.
>>>
>>> Currently only USB_PORT_FEAT_LINK_STATE puts port to U3 directly, let's
>>> do the same for USB_PORT_FEAT_SUSPEND and bus suspend case.
>>>
>>> This is particularly useful for USB2 devices, which may take a very long
>>> time to switch USB2 LPM on and off.
>>
>> Have these two patches been tested with a variety of USB-2.0 and USB-2.1 
>> devices?
> 
> I tested some laptops around and they work fine.
> Only internally connected USB devices like USB Bluetooth and USB Camera have USB2 LPM enabled, so this patch won't affect external connected devices.
> 

Took a fresh look at the USB2 side and it's not as clear as the USB3 case, where
we know the hub must support transition to U3 from any other state. [1]

Supporting link state transition to U3 (USB2 L2) from any other U state for USB2 seems
to be xHCI specific feature. xHC hardware will make sure it goes via the U0 state.

I have no clue about other hosts (or hubs), USB2 LPM ECN just shows that link
state transitions to L1 or L2 should always goes via L0.
It's possible this has to be done in software by disabling USB2 LPM before suspending the device.

So I guess the original suggestion to wait for link state to reach U0 before
is a better solution. Sorry about my hasty suggestion.

Kai-Heng, does it help if you fist manually set the link to U0 before disabling
USB2 LPM (set PLS to 0 before clearing the HLE bit). Does it transition to U0
any faster, or get rid of the extra port event with PLC:U0?

-Mathias

 
[1]
    USB3.1 spec (10.16.2.10) Set Port feature:   
   "If the value is 3, then host software wants to selectively suspend the
    device connected to this port. The hub shall transition the link to U3
    from any of the other U states using allowed link state transitions.
    If the port is not already in the U0 state, then it shall transition the
    port to the U0 state and then initiate the transition to U3.

  reply	other threads:[~2020-06-10 15:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-10  6:42 [PATCH 1/2] xhci: Suspend ports to U3 directly from U1 or U2 Kai-Heng Feng
2020-06-10  6:42 ` [PATCH 2/2] USB: hub: Suspend and resume port with LPM enabled Kai-Heng Feng
2020-06-10  9:21   ` Sergei Shtylyov
2020-06-10 14:32 ` [PATCH 1/2] xhci: Suspend ports to U3 directly from U1 or U2 Alan Stern
2020-06-10 15:43   ` Kai-Heng Feng
2020-06-10 15:58     ` Mathias Nyman [this message]
2020-06-11  7:41       ` Kai-Heng Feng

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=9d7842de-9813-becd-80a0-a422e59c1e94@linux.intel.com \
    --to=mathias.nyman@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kai.heng.feng@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=stern@rowland.harvard.edu \
    /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