Hello.
Grant Grundler wrote:
Well, I don't have the PCI specification, but I have a device with the
Try googling for pdf21.pdf, pdf22.pdf if you need it. :-)
I think you meant pci21.pdf/pci22.pdf/pci23.pdf.
And if you find them, trust me when I say whoever is hosting those files
can expect a cease-and-desist letter in the mail shortly there after.
Better to just ask someone with proper access to lookup the parts
you need to know (i.e. ask here). Member companies are listed at:
http://www.pcisig.com/membership/about_us/membership_roster/
if you want to approach someone offlist.
That's not fun. :-)
following gem in its errata (name edited and changed to <Device>):
""The <Device> contains two PCI base registers to allow for both greater
flexibility in tightly constrained I/O space as well as the "on the fly"
option to access the <Device> registers from either I/O or memory space.
Both PCI base registers contained in the <Device> will accept the value
of "zero" as a valid and decodable address. This differs from the PCI 2.1
specification, where a zero value being written to the PCI base register
should disable the register space.
I haven't found such words in PCI 2.1 -- it only said that 0 is not a
valid address (those words are gone from 2.2).
AFAIK, zero is a valid address for IO Port space on several architectures.
But PCI generic code should never use it. See usage of PCIBIOS_MIN_IO
and PCIBIOS_MIN_MEM in the various asm-*/pci.h files.
That'd be all good if bootloaders also folllowed this rule... Not all of
them do, hence the thread. :-/
which makes me suspect that a base address of zero really should mean
unassigned and is a way to disable base registers on a region by region
basis.
AFAIR, there's never been a provision to enable/disable BARs on an
individual basis in PCI (except the expansion ROM BAR). The decoders are
only controlled via 2 command register bits for I/O and memory space.
One can "disable" a BAR by pointing it at an address that is NOT routed
by the upstream bridge. Ie CPU physical addresses that can never reach
that secondary bus. But I'm not aware of any code to do that currently
Yeah, that's the trick that Gabriel has already described...
and it certainly won't work with all "PCI-like" (think integrated south
bridges) devices.
Well, those are using subtractive decoders, so will only get the R/W
cycles that nobody else cared about. If using I/O ports higher than 0xffff the
trick will still work on x86 even in presence of ISA bridges...
hth,
grant
WBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
