Alan,
> I'm not sure about that. The delay occurs with a spinlock held and
interrupts
> disabled, and 250 us is a pretty long time to wait with interrupts
turned off.
> Some people might get annoyed.
> There are other ways of accomplishing the same thing, but they are
more
> difficult. Do you have any suggestions for an easy way to approach
it?
> Or can you switch to a different controller? :-)
The hardware is already shipping, so we can't switch controllers. I
haven't examined the code thouroughly enough to fully understand it yet.
Was there something wrong with the way the code worked in earlier
kernels?
I suppose the way I might try to approach this would be to wait (within
some reasonable amount of time) for the PEC and CSC bits after clearing
PORT_RESET.
Possibly something like this:
for(i=0; i<25; i++) {
udelay(10);
if (inw(port_addr) & (USBPORTSC_PEC|USBPORTSC_CSC))
break;
}
CLR_RH_PORTSTAT(USBPORTSC_PEC|USBPORTSC_CSC);
So, normal controllers will wait 10us. Our slower controller will wait
up to 250us. I'm not sure if the root-hub ports are ever reset when
there's no attached device, so it might be best to wrap the above inside
of an "if (this_port_has_a_device) { ... }"
What do you think?
Regards,
--Chris
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
