From: mathias.nyman@linux.intel.com (Mathias Nyman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] usb: xhci: add relaxed timing quirk bit
Date: Thu, 23 Nov 2017 12:59:45 +0200 [thread overview]
Message-ID: <c46e19a2-4b37-473c-a563-6fddf0c62070@linux.intel.com> (raw)
In-Reply-To: <3c44d4d0-e10c-bacc-8e7f-df04bed5dc21@codeaurora.org>
On 23.11.2017 01:32, Adam Wallis wrote:
> On 11/22/2017 10:24 AM, Mathias Nyman wrote:
> [..]
>>
>> We know have at least two hosts/platforms that need custom interrupt moderation
>> values
>>
>> How about adding a u32 device property for xhci with the interrupt moderation
>> interval in
>> nanoseconds?? And also add a u32 imod_interval variable to struct xhci_hcd?
>>
>> imod_interval can be set to the current default 40000ns (160*250ns) and
>> overwritten if
>> device_property_read_u32() returns something else.
>>
>
> Isn't the 160 value quite aggressive anyway? Section 5.5.2.2 of the xHCI spec
> says that maximum observable interrupt rate should never exceed 8000
> interrupts/second. I believe the IMOD value in the most aggressive case would
> then be 500 by this statement [ 1 / (250e-9 * 500) = 8000 irqs/second ]
>
> Perhaps I am misreading the spec or just doing the math wrong? With the default
> value of 160, we are interrupting 25,000 irq/second...which is over 3 times the
> maximum stated value (again, assuming I did the math right)
>
> Anyway, my preference would be to set the IMOD default val to 4000 (~1ms) per
> the recommended value in Table 49 of the spec and allow platforms to adjust as
> necessary from that point.
>
> Thoughts on this?
>
I think current 40us is still reasonable, it's about ~3 times per
usb microframe (125us) .8000 interrupts per second just covers the microframe rate,
which is the shortest interval a interrupt transfer can require service.
1ms interrupt interval is too long. In the worst case ~8 microframes could pass
before the driver is aware of a error it needs to take care of.
USB 3.1 devices can transfer 6 burst of 16 max sized packets (6 x 16 x 2014) bytes
per microframe.
closer to 125us could probably work as well, but unless we are fixing some issue or
getting some other bigger benefit out of it I don't think it's worth changing it
just to see if it breaks stuff.
Thanks
-Mathias
next prev parent reply other threads:[~2017-11-23 10:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-21 17:18 [PATCH 0/2] usb: xhci: addition of timing quirk Adam Wallis
2017-11-21 17:18 ` [PATCH 1/2] usb: xhci: add relaxed timing quirk bit Adam Wallis
2017-11-21 19:11 ` Rob Herring
2017-11-21 19:49 ` Adam Wallis
2017-11-21 20:06 ` Rob Herring
2017-11-22 0:07 ` Adam Wallis
2017-11-22 15:24 ` Mathias Nyman
2017-11-22 19:56 ` Adam Wallis
2017-11-22 23:32 ` Adam Wallis
2017-11-23 10:59 ` Mathias Nyman [this message]
2017-11-23 14:35 ` Adam Wallis
2017-11-21 17:18 ` [PATCH 2/2] usb: host: xhci-plat: check " Adam Wallis
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=c46e19a2-4b37-473c-a563-6fddf0c62070@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).