> The initialisation of PCI devices has nothing to do with theory. This job=
> must be done prior to attaching drivers to PCI devices. If the BIOS didn't=
> do the work, the right place for doing the work is certainly _not_ PCI
> device drivers.
Only the drivers know about some of the issues. Worse yet we have to deal
with other horrible problems when we do set it because the drivers don't know
about the motherboard/chipset bugs.
> trade-off that takes into account the MIN_GNT and MAX_LAT of all PCI
> devices. The Linux kernel design is _quite_ fine for implementing the
> right thing in the right place regarding PCI devices initialisation.=20
They are only part of the value. Some chipsets have latency constraints that
are imposed. for example the SIS5598 which cannot handle high latency settings.
I'd prefer to see it in drivers/pci as well.
> latency timer.. The system software that deals with latency timer values
> must choose some compromise between desires of _all_ PCI device drivers
and all non PCI devices, and bugs, and ISA interactions. Then add devices
that misreport their needs. So yes it does want to be in drivers/pci
> Therefore, tampering latency timers from PCI device drivers can only be a
> _wrong_ approach, unless it is intended to fix some hardware bug that
> addresses this device in particular.
Anything which isn't a paticular device quirk should be in drivers/pci. Im not
sure that is true with 2.2.x even if it is becoming so with 2.3.x.
If you had people hitting the latency 0 problem then the patch for 2.2.x needs
to both remove it from the driver and put it where it belongs in drivers/pci.
It could also do with DaveM and Rth checking that isnt needed on sparc/alpha
although I would hope there is ifdef(__sparc__) around such cases.
The last two were the points I was trying to make. The rest definitely belongs
elsewhere. If you stick a 3c590 into a SIS5598 board and run X11 right now
you get display flicker because the 3c590 doesnt know that the latency fix
it does is worse than the disease in this case.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
