On Monday, March 07, 2011 18:09:25 Graeme Russ wrote:
On Tue, Mar 8, 2011 at 9:10 AM, Mike Frysinger vapier@gentoo.org wrote:
On Monday, March 07, 2011 16:56:31 Moffett, Kyle D wrote:
On Mar 07, 2011, at 16:40, Mike Frysinger wrote:
On Monday, March 07, 2011 12:37:22 Kyle Moffett wrote:
- udelay(50000);
this doesnt sit well with me. i dont see why this matters ... we dont have any delays today, and i dont think we should introduce any.
Actually, several architectures had a printf()+udelay() already. (i386 and ARM, IIRC). Since I was moving the printf() to common code I figured I'd better move the udelay() as well.
I believe they had comments to the effect of "This udelay() prevents garbage on the serial console while rebooting", I would guess because it gives the FIFO time to finish flushing.
Blackfin specifically does not do this. personally, a half baked uart char is preferable to a (imo) useless hardcoded delay. i wonder if they picked a number that seems to work, or actually calculated it based on the slowest baud times the deepest fifo times the extra bits (parity/stop/etc...). i'd suspect the former which means this is even dumber.
I can move it back to the individual architectures if you'd like.
if we cant agree to simply punt it, then yes, please do. or make it a config option so board porters can opt out, and default it to on for only the existing arches.
Is there any way we could detect that the UART FIFO is empty and wait on that condition (with a timeout in case the FIFO is never emptied)?
that would require extending the serial API to add a new func, have each serial driver implement (i'm pretty sure most serial devices out there expose a bit to poll such status), and then having the code call it. i'm not saying it cant be done, just outlining the requirements.
although i vaguely recall that Wolfgang is against this sort of thing since it kind of goes against the KISS principle ... -mike