Perhaps what was meant is that ISA-tuned timings make little sense on devices that are part of the chipset or on the PCI or PCI-X buses? On the other hand, since we don't know in many cases whether the "_p" was supposed to mean "the time it takes to execute an "out al,80h" on whatever bus structure happens to be on whatever machine, the problem is unsolvable. Ranting about whether ISA/LPC is on what machines seems to be of little value in contributing to a constructive solution. It seems to me that in the long term, driver writers would do well to think more clearly about the timings their devices require, when that is possible. They are probably implementation dependent - depending on the clock speed of the particular clock that is driving the particular i/o device. Then there's the social problem of a community development project - which is to get people to tune their code but preserve its ability to run on older and variant machines. Alan Cox wrote:--
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| David Newall | Re: Slow DOWN, please!!! |
| Peter Zijlstra | [PATCH 00/23] per device dirty throttling -v8 |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Natalie Protasevich | [BUG] New Kernel Bugs |
git: | |
