Subject: Re: Should Alpha PCI code manage latency timers?
To: List Mail User <>
From: Thor Lancelot Simon <>
List: tech-kern
Date: 01/24/2005 15:52:47
On Mon, Jan 24, 2005 at 08:05:50AM -0800, List Mail User wrote:
> 	This is from my *very* old PCI 1.0 and 1.1 drafts and specs, but...
> The latency timer, min and max grant and irq fields in the PCI config
> space are all reserved for either the BIOS or OS which does the initial
> resource allocation. It is/was strictly a violation of the (original)

Of course, the problem is that we run on lots of platforms where the
firmware does only partial or even no "initial resource allocation".

Even on many modern x86 PCs, it is not uncommon these days to find that
the BIOS has only done enough configuration work to find some small set
of what it considers to be plausible boot devices, e.g. interrupt,
memory, and latency settings for devices on the primary PCI bus and
nothing at all for devices behind bridges.

In such cases it's a little difficult to see what counts as "initial";
if it's the first time the latency timer has been written to since bus
reset, it seems to me what the isp driver is doing isn't, strictly
speaking, wrong (or, at least, no more wrong than it would be to
consistently set latency for all devices in the MD code for PCI buses
on this port).

Complicating matters further is that it seems that a warm reboot of
this machine doesn't reset the PCI bus -- since the user found that
after a reboot back to his original kernel (which didn't set the
latency timer for the IDE device) the latency value his test kernel
had set had "stuck".  How _can_ we do "the right thing" in such a

One thing I'm curious about: is a latency timer value of 0x00 legal?
If so, what does it mean?  In a similar vein, Reinoud's machine seems
to have a device in it which claims maximum latency 0x00 but which
powers up after bus reset with latency timer value 0xff (this seems
to violate the specification, to say the least).  How should we
handle such illegal cases, in your opinion?