Hi Ajay, Dose this patch work for you? I tried several different values,and It seems that '8' work just fine. Cliff >-----Original Message----- >From: Mike Frysinger [mailto:vapier.adi@xxxxxxxxx] >Sent: Sunday, May 16, 2010 8:47 AM >To: Gupta, Ajay Kumar >Cc: linux-usb@xxxxxxxxxxxxxxx; Felipe Balbi; >uclinux-dist-devel@xxxxxxxxxxxxxxxxxxxx; Cai, Cliff >Subject: Re: [Uclinux-dist-devel] [PATCH] USB: musb: set NAK >limitation for control transfers > >On Fri, May 14, 2010 at 01:42, Gupta, Ajay Kumar wrote: >>> Some bad-behaved peripherals (like cheap USB storage devices) need >>> this in order to recover during configuration time. >>> >>> diff --git a/drivers/usb/musb/musb_host.c >>> b/drivers/usb/musb/musb_host.c index 877d20b..e2667dc 100644 >>> --- a/drivers/usb/musb/musb_host.c >>> +++ b/drivers/usb/musb/musb_host.c >>> @@ -1994,6 +1994,9 @@ static int musb_urb_enqueue( >>> /* ISO always uses logarithmic encoding */ >>> interval = min_t(u8, epd->bInterval, 16); >>> break; >>> + case USB_ENDPOINT_XFER_CONTROL: >>> + interval = 8; >> >> Why '8'? Device could be high speed or FS/LS so it comes out to, HS >> device: 2^7 uf = 128uf = 16 msec FS/LS device: 2^7 f = 128msec > >it's a value that seems to work in our tests. i'm pretty sure >we arent tied to a specific value, so if you want to increase >it, that's fine. Cliff can certainly correct me though. > >> Also, I have seen high speed bad behaved devices not responding to >> PING tokens in status phase of control transfers. Are you >also getting >> this issue ? > >yes, we had PING problems, and we've posted other patches in >the past for that, but this seems to be the most correct >version so far. > >search for like blackfin+ping+musb on some lists if you're >interested in the history. >-mike > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
