[Bug 218544] not enough bandwidth, synaptics hi-res audio duplex audio

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=218544

--- Comment #10 from Ian Malone (ibmalone@gmail.com) ---
Created attachment 305965
  --> https://bugzilla.kernel.org/attachment.cgi?id=305965&action=edit
/sys/kernel/debug/usb/devices other devices and hid disabled

You are of course right, the patch can't be easily adapted to apply against the
current driver and there are too many incompatibilities with memory management
and the rest of the USB system for it to be trivial to drop in the whole 2.6.18
host controller. I'm not sure it was ever really submitted, which is a pity as
it looks like it implemented FSTN handling that never otherwise got added. I
might fiddle with it a bit more to see if it can be built just to see if it
would have helped.

Meanwhile, I've tried disabling the HID as well, /sys/kernel/debug/usb/devices
attached. This still doesn't work (same "cannot submit urb 0, error -28: not
enough bandwidth"). It does puzzle me a bit, we're now down to a single FS
device on the hub, while I can understand the scheduling for LS/FS onto HS is
complicated I'd have thought this issue would have popped up frequently enough
when these laptops were common that it would have been addressed back then. Is
there any other information I can extract to find out what's going on with the
scheduler? The following are the FS/LS portion of
/sys/kernel/debug/usb/ehci/0000:00:1a.0/bandwidth for a good device in out, in
and duplex and the problematic device:

good device out
TT 2-1 port 0  FS/LS bandwidth allocation (us per frame)
    482  482  482  482  482  482  482  482
FS/LS budget (us per microframe)
 0:   24   0 125 125 125  83   0   0
 8:   24   0 125 125 125  83   0   0
16:   24   0 125 125 125  83   0   0
24:   24   0 125 125 125  83   0   0
32:   24   0 125 125 125  83   0   0
40:   24   0 125 125 125  83   0   0
48:   24   0 125 125 125  83   0   0
56:   24   0 125 125 125  83   0   0
2-1.1 ep 82:    24 @  0.0+1 mask 1c01
2-1.1 ep 01:   458 @  0.2+1 mask 003c

good device in good
TT 2-1 port 0  FS/LS bandwidth allocation (us per frame)
    109  109  109  109  109  109  109  109
FS/LS budget (us per microframe)
 0:   24   0   0  85   0   0   0   0
 8:   24   0   0  85   0   0   0   0
16:   24   0   0  85   0   0   0   0
24:   24   0   0  85   0   0   0   0
32:   24   0   0  85   0   0   0   0
40:   24   0   0  85   0   0   0   0
48:   24   0   0  85   0   0   0   0
56:   24   0   0  85   0   0   0   0
2-1.1 ep 82:    24 @  0.0+1 mask 1c01
2-1.1 ep 81:    85 @  0.3+1 mask e008

good device duplex
TT 2-1 port 0  FS/LS bandwidth allocation (us per frame)
    567  567  567  567  567  567  567  567
FS/LS budget (us per microframe)
 0:   24  85 125 125 125  83   0   0
 8:   24  85 125 125 125  83   0   0
16:   24  85 125 125 125  83   0   0
24:   24  85 125 125 125  83   0   0
32:   24  85 125 125 125  83   0   0
40:   24  85 125 125 125  83   0   0
48:   24  85 125 125 125  83   0   0
56:   24  85 125 125 125  83   0   0
2-1.1 ep 82:    24 @  0.0+1 mask 1c01
2-1.1 ep 01:   458 @  0.2+1 mask 003c
2-1.1 ep 81:    85 @  0.1+1 mask 3802

bad device in
TT 2-1 port 0  FS/LS bandwidth allocation (us per frame)
    273  273  273  273  273  273  273  273
FS/LS budget (us per microframe)
 0:   39   0 125 109   0   0   0   0
 8:   39   0 125 109   0   0   0   0
16:   39   0 125 109   0   0   0   0
24:   39   0 125 109   0   0   0   0
32:   39   0 125 109   0   0   0   0
40:   39   0 125 109   0   0   0   0
48:   39   0 125 109   0   0   0   0
56:   39   0 125 109   0   0   0   0
2-1.1 ep 84:    39 @  0.0+1 mask 1c01
2-1.1 ep 81:   234 @  0.2+1 mask f004

bad device out
TT 2-1 port 0  FS/LS bandwidth allocation (us per frame)
    497  497  497  497  497  497  497  497
FS/LS budget (us per microframe)
 0:   39   0 125 125 125  83   0   0
 8:   39   0 125 125 125  83   0   0
16:   39   0 125 125 125  83   0   0
24:   39   0 125 125 125  83   0   0
32:   39   0 125 125 125  83   0   0
40:   39   0 125 125 125  83   0   0
48:   39   0 125 125 125  83   0   0
56:   39   0 125 125 125  83   0   0
2-1.1 ep 84:    39 @  0.0+1 mask 1c01
2-1.1 ep 01:   458 @  0.2+1 mask 003c

bad device duplex
TT 2-1 port 0  FS/LS bandwidth allocation (us per frame)
    497  497  497  497  497  497  497  497
FS/LS budget (us per microframe)
 0:   39   0 125 125 125  83   0   0
 8:   39   0 125 125 125  83   0   0
16:   39   0 125 125 125  83   0   0
24:   39   0 125 125 125  83   0   0
32:   39   0 125 125 125  83   0   0
40:   39   0 125 125 125  83   0   0
48:   39   0 125 125 125  83   0   0
56:   39   0 125 125 125  83   0   0
2-1.1 ep 84:    39 @  0.0+1 mask 1c01
2-1.1 ep 01:   458 @  0.2+1 mask 003c

It looks like there's an extra 234us to accommodate for input to work, I'm
guessing there are restrictions on where that can go. Is it plausible that if a
lower bandwidth mode is requested from the device it would work? That's
essentially what I was wondering about with respect to the snd-usb-audio module
before this was moved over to usb.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.