Message ID | 1423630997-25464-3-git-send-email-chris@rorvick.com (mailing list archive) |
---|---|
State | Accepted |
Commit | e64e94df9916a1db6c85a3677e20926c99a1d0b3 |
Headers | show |
At Tue, 10 Feb 2015 23:03:13 -0600, Chris Rorvick wrote: > > The device indicates the result of a read/write operation by making the > status available on a subsequent request from the driver. This is not > ready immediately, though, so the driver is currently slamming the > device with hundreds of pointless requests before getting the expected > response. Add a two millisecond delay before each attempt. This is > approximately the behavior observed with version 4.2.7.1 of the Windows > driver. > > Signed-off-by: Chris Rorvick <chris@rorvick.com> Applied, thanks. Takashi > --- > sound/usb/line6/driver.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c > index aac1e35..222c14f 100644 > --- a/sound/usb/line6/driver.c > +++ b/sound/usb/line6/driver.c > @@ -296,6 +296,8 @@ static void line6_data_received(struct urb *urb) > line6_start_listen(line6); > } > > +#define LINE6_READ_WRITE_STATUS_DELAY 2 /* milliseconds */ > + > /* > Read data from device. > */ > @@ -319,6 +321,8 @@ int line6_read_data(struct usb_line6 *line6, u16 address, void *data, > > /* Wait for data length. We'll get 0xff until length arrives. */ > do { > + mdelay(LINE6_READ_WRITE_STATUS_DELAY); > + > ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), 0x67, > USB_TYPE_VENDOR | USB_RECIP_DEVICE | > USB_DIR_IN, > @@ -376,6 +380,8 @@ int line6_write_data(struct usb_line6 *line6, u16 address, void *data, > } > > do { > + mdelay(LINE6_READ_WRITE_STATUS_DELAY); > + > ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), > 0x67, > USB_TYPE_VENDOR | USB_RECIP_DEVICE | > -- > 2.1.0 >
diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c index aac1e35..222c14f 100644 --- a/sound/usb/line6/driver.c +++ b/sound/usb/line6/driver.c @@ -296,6 +296,8 @@ static void line6_data_received(struct urb *urb) line6_start_listen(line6); } +#define LINE6_READ_WRITE_STATUS_DELAY 2 /* milliseconds */ + /* Read data from device. */ @@ -319,6 +321,8 @@ int line6_read_data(struct usb_line6 *line6, u16 address, void *data, /* Wait for data length. We'll get 0xff until length arrives. */ do { + mdelay(LINE6_READ_WRITE_STATUS_DELAY); + ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), 0x67, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN, @@ -376,6 +380,8 @@ int line6_write_data(struct usb_line6 *line6, u16 address, void *data, } do { + mdelay(LINE6_READ_WRITE_STATUS_DELAY); + ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), 0x67, USB_TYPE_VENDOR | USB_RECIP_DEVICE |
The device indicates the result of a read/write operation by making the status available on a subsequent request from the driver. This is not ready immediately, though, so the driver is currently slamming the device with hundreds of pointless requests before getting the expected response. Add a two millisecond delay before each attempt. This is approximately the behavior observed with version 4.2.7.1 of the Windows driver. Signed-off-by: Chris Rorvick <chris@rorvick.com> --- sound/usb/line6/driver.c | 6 ++++++ 1 file changed, 6 insertions(+)