On Fri, 20 Jan 2006, Frantz, Chris wrote:
> 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?
There was no spinlock protection, leaving the possibility that two
different processors on an SMP system (or two different tasks on a UP
system with preempt enabled) could simultaneously perform incompatible
actions.
> 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.
That's a good idea. But on my controller, if the port was enabled before
the reset then PEC gets turned on as soon as the reset begins. Is that
true on your controller? And even if it is not true, do you know that
your controller turns on PEC and CSC at the same time (so you don't end
the loop too early)? And will 25 iterations be enough?
> 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) { ... }"
It's better than waiting 250 us!
Alan Stern
-------------------------------------------------------
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&kid=103432&bid=230486&dat=121642
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
