![]() | |||||||||||||
Messages in this thread |
Ingo Molnar wrote: > in this particular case there's only very simple (and non-IO) > instructions in that codepath (no loops either), except for > ata_bmdma_status() which does IO ops: so i agree with you that the most > likely candidate for the delay is the readb() or the inb() in > ata_bdma_status().> > I'm wondering which one of the two. inb()s are known to be horrible on > some systems - but i've never seen them take 16 milliseconds. If it's > the inb(), then that could also involve SMM mode and IO ata_bmdma_status() is just a single IO read, and even 1ms is highly improbable. I'd look elsewhere. There are a ton of udelay() calls in the legacy PCI IDE BMDMA code paths (sata_nv uses these), so I'm not surprised there is latency in general, in a libata+sata_nv configuration. Status checks for example (ata_busy_wait in libata.h) are basically while (ioreadX() != condition) udelay(10) That delay is mainly a "don't pound too hard on the hardware" delay. If the hardware is really slow completing a command after signalling completion, you'll potentially wait up to 1000*10 us in some cases. And there are other delays, such as the per-command ndelay() plus ioread(). Welcome to the wonderful world of IDE. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-03-15 23:25 [from the cache] ©2003-2008 | |||||||||||||