public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, stern@rowland.harvard.edu
Subject: Re: [PATCH 2/2] usb: hub: Disable USB 3 device initiated lpm if exit latency is too high
Date: Thu, 15 Jul 2021 17:08:07 +0300	[thread overview]
Message-ID: <14c3a642-8166-d33d-bd83-40c7ee7c2c99@linux.intel.com> (raw)
In-Reply-To: <YPA1ots7vdRclUkE@kroah.com>

On 15.7.2021 16.18, Greg KH wrote:
> On Thu, Jul 15, 2021 at 04:15:44PM +0300, Mathias Nyman wrote:
>> The device initiated link power management U1/U2 states should not be
>> enabled in case the system exit latency plus one bus interval (125us) is
>> greater than the shortest service interval of any periodic endpoint.
>>
>> This is the case for both U1 and U2 sytstem exit latencies and link states.
>>
>> See USB 3.2 section 9.4.9 "Set Feature" for more details
>>
>> If host initiated lpm is enabled but device initiated is not due to exit
>> latency limitations then still set the udev->usb3_lpm_ux_enabled flag so
>> that sysfs users can see the link may go to U1/U2.
>>
>> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>> ---
>>  drivers/usb/core/hub.c | 68 ++++++++++++++++++++++++++++++++++--------
>>  1 file changed, 56 insertions(+), 12 deletions(-)
> 
> Do either of these need to go to older kernels?

Right, first patch should go, I'll figure out to what version.

Second one not so sure. It does a minor change in lpm logic.

Before second patch enabling lpm meant enabling both host and device initiated
lpm transitions. After this patch we might enable host initated lpm without device
lpm.

That could be stated clearer in the description as well..  

> 
>>
>> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
>> index a35d0bedafa3..63e150982da9 100644
>> --- a/drivers/usb/core/hub.c
>> +++ b/drivers/usb/core/hub.c
>> @@ -4116,6 +4116,47 @@ static int usb_set_lpm_timeout(struct usb_device *udev,
>>  	return 0;
>>  }
>>  
>> +/*
>> + * Don't allow device intiated U1/U2 if the system exit latency + one bus
>> + * interval is greater than the minimum service interval of any active
>> + * periodic endpoint. See USB 3.2 section 9.4.9
>> + */
>> +static bool usb_device_may_initiate_lpm(struct usb_device *udev,
>> +					enum usb3_link_state state)
>> +{
>> +	unsigned long long sel;		/* us */
> 
> Do you mean u64 here?  If so, you might want to use that :)

Ah, my mistake, no need for 64 bits.
Original sel value we store here is an unsigned int.
sel = DIV_ROUND_UP(udev->u1_params.sel, 1000);

Must have copied that from usb_req_set_sel() that uses unsigned long long for sel and pel
values for some odd reason.
I'll change it.

-Mathias 

      reply	other threads:[~2021-07-15 14:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-15 13:15 [PATCH 1/2] usb: hub: Fix link power management max exit latency (MEL) calculations Mathias Nyman
2021-07-15 13:15 ` [PATCH 2/2] usb: hub: Disable USB 3 device initiated lpm if exit latency is too high Mathias Nyman
2021-07-15 13:18   ` Greg KH
2021-07-15 14:08     ` Mathias Nyman [this message]

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=14c3a642-8166-d33d-bd83-40c7ee7c2c99@linux.intel.com \
    --to=mathias.nyman@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --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