Timur Tabi wrote:
Benjamin Herrenschmidt wrote:
Well, there's a non-empty set of HW where polling as fast as you can
will effectively prevent it to make fwd progress...
Alan Cox mentioned this. He gave PCI and 10us as an example. I
suggested adding a third parameter that would be a udelay() inserted
into the loop. He countered with this:
spin_until_timeout(readb(foo) & 0x80, 30 * HZ) {
udelay(10);
/* Maybe do other stuff */
}
Hmm, the person objecting that it could lead to people using it for
excessive timeouts suggested a timeout of *30 seconds*?
But I don't know how to make that work *and* have it return a value
indicating timeout or success.
And it also doesn't allow using the udelay as part of the timeout mechanism.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
