Subject: Re: Should Alpha PCI code manage latency timers?
To: None <email@example.com>
From: List Mail User <track@Plectere.com>
Date: 01/25/2005 04:38:50
>From firstname.lastname@example.org Mon Jan 24 19:33:04 2005
>Date: Tue, 25 Jan 2005 04:32:10 +0100
>From: Jachym Holecek <email@example.com>
>To: List Mail User <track@Plectere.com>
>Subject: Re: Should Alpha PCI code manage latency timers?
>Reply-To: Jachym Holecek <firstname.lastname@example.org>
>I had a look at PCI rev 3 and found the following. I'm no PCI expert and
>may pretty well be confused, though.
>> >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?
>> A latency timer value of zero is indeed legal, it means the device has
>> no particular requirements of its own - still it needs to be updated to
>> account for the other devices on the bus (actually, if the device doesn't
>> have any bus-master capabilities, it likely just ignores any value anyway).
>> On the other hand, I believe that the original specs had a maximum
>> allowed value of 0xC0 (or some other value less than 0xFF), and a device which
>> reads 0xFF likely doesn't implement the register as required by the specs (a
>> simple test would be to try to write a different value and check what you get
>> when reading back afterwards). The register is always supposed to be both
>> read/write, but can only be written at an early point during initialization
>"Latency timer", in units of PCI clock cycles:
> o Must be implemented read/write by any bus-master that can burst
> more then two data phases.
> o May be implemented read-only for devices that burst two or less
> data phases, in which case the hardwired value has to be 16 or less.
> o Must be initialized to 0 upon RST, if programmable.
> o Implementation is free to limit granularity by hardwiring N bottom
> bits to zero (specifically, PCI-to-PCI bridges are allowed to
> limit granularity to 8 -- from ppb12).
> o No maximum value is explicitely stated.
>> Individual devices are supposed to initialize the register
>> to reflect their own particular requirements at power on and system software
>> (i.e. BIOS or OS) is supposed to update every device to the maximum value that
>> any particular device requires (exactly to avoid contention issues and allow
>> devices to dynamically determine buffer size needs).
>Now, "Maximum Latency" and "Minimum Grant" are read-only and represent
>device's maximum performance settings, in unit of 1/4 microsecond. Values
>of 0 mean device has no special requirements.
>I'm available to look up further information, upon request.
> -- Jachym Holecek
Great, someone with the current specs.
This explains a few things which showed up earlier in this thread.
a) Why some devices on a particular Alpha showed 0xFF and others 0xF8.
b) My memory of the 2 cycle "special case"
c) Indeed a device which powers up at 0xFF is mis-implemented.
d) Why some devices appear to have a value of 16 (or less) when all others
are at a higher value.
e) Indeed, non-busmasters are exempt.
f) Why a "soft" reset leaves the value alone (i.e. no bus "RST" is issued).
During early implementations, often the PCI bus could be run at speeds
lower than 33MHz (i.e. 30MHz for 90MHz Pentiums and 25MHz for 75MHz Pentiums),
so system software had to translate the "MaxLat" field in time specification to
a "Latency" in cycles by `knowing' the effective bus speed.
Just an interesting side note: The implementers of Intel motherboards
with the 430NX (Neptune) chipset misinterpreted the recommended value of 32
(i.e. 0x20 hex) and actually defaulted to 50 (i.e. 0x32 hex) -- Just some (very
old) history. More OT: Also the chipset (just the 430NX, not the later FX or
TX flavors) itself, would also would freeze if a "lock" was asserted during
certain transactions (in the errata somewhere), in particular during the
standard install of MS Windows 95 - MS provided another installer in another
directory of the "golden" release CD to work around this; Anyone with a W95 CD
can find that alternate installer, but no explanation is given for its purpose;
It differs in only a single instruction by dropping the x86 "lock" prefix from
a particular VGA register access -- It was needed for Rendition and some (I
think) Sis graphics cards.
Jachym, do you also have (or can get) the BIOS Implementor's Guide?
It contains (or did) the recommended sequence for determining and initializing
the system specific fields. Also, are you checking for PCI 2.1 or 2.2 (the
common cases) or 2.3 (which I have yet to see an implementation of) or *really*
PCI 3.0 (which includes PCI-Express, hot plug and a host of other `new' things?
Note, most of the old Alphas are probably either version 1.1 or 1.2.