diff options
| author | Orgad Shaneh <orgads@gmail.com> | 2026-09-01 19:30:29 +0000 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2026-09-10 17:07:55 +0200 |
| commit | aebbc7d63407f843a1c74806041792db65d69a51 (patch) | |
| tree | bc7cfbc46d907e46b304e9f4678d2189e9aca783 /tools/lib/python/kdoc/python_version.py | |
| parent | 22bce6d2b3fd9e845d71e0037b6929913301462d (diff) | |
| download | linux-next-aebbc7d63407f843a1c74806041792db65d69a51.tar.gz linux-next-aebbc7d63407f843a1c74806041792db65d69a51.zip | |
usb: octeon-hcd: sleep on an hrtimer for far-off periodic transfers
cvmx_usb_schedule() enables the SOF interrupt whenever any pipe has
next_tx_frame in the future, and leaves it enabled until the transfer
is due. An interrupt endpoint keeps such a deadline pending
permanently, so a single attached hub (status pipe polled every 256ms)
costs an interrupt on every SOF - 8000/s in high-speed mode, forever.
On a 300MHz CN5020 that is measurably ~20% of one core spent counting
frames.
The frame counter is resynchronized from HFNUM at the top of every
poll, so the driver does not actually need to see every SOF to know
when a deadline arrives. Sleep on an hrtimer when the nearest deadline
is more than a few frames away (one high-speed frame is 125us) and
keep SOF interrupts only for deadlines that are imminent - or far
enough away to risk the 16383-frame HFNUM wrap, where the interrupt
path still tracks the counter extension.
Measured on a CN5020 board with one 4-port hub attached and idle:
8200 -> 4 USB interrupts/s, with no change in enumeration or transfer
behavior.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Orgad Shaneh <orgads@gmail.com>
Link: https://patch.msgid.link/20260901193100.1352110-3-orgads@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'tools/lib/python/kdoc/python_version.py')
0 files changed, 0 insertions, 0 deletions