On Fri, 15 Sep 2000, [ISO-8859-1] Gérard Roudier wrote:
>
>
> On Fri, 15 Sep 2000, Linus Torvalds wrote:
>
> > On Fri, 15 Sep 2000, Gérard Roudier wrote:
> > >
[Snipped a lot...]
> > Call "pci_enable_device()".
> >
> > What's so hard about that?
>
> This function delegates too much as a whole to the PCI generic layer, IMO.
> Imagine that for sanity I want to allocate all the device resources, but
> only _enable_ part of device features (for example only memory
> transactions). Imagine some special handling to be necessary due to some
> chip bug.
>
It's not just 'maybe'. The Tundra Universe chip for interface to the
VXI bus (PCI interface to VXI) allows that either/or/both I/O and
memory 'windows' can be enabled.
VXI bus space is duplicated in both so it's possible to do everything
memory-mapped or even (if you really wanted to) from I/O space.
> > You don't seem to realize, but it's entirely possible to have a setup
> > where some device CANNOT be allocated it's IO region. The BIOS may have
> > left the device disabled on purpose, simply because there wasn't enough
> > free space in the memory map to enable the device anywhere.
>
> PCI specs said corresponding BAR must be set to ZERO, here.
>
Correct. If there are no resources, you clear all address bits.
> > You can't just have the device driver enable such a device. It _has_ to
> > ask the PCI layer to do it for it - because the PCI layer is the only one
> > that can figure out that "Oh, damn, this machine has 3GB of memory, and 4
> > video cards that want a 256MB aperture each, and we don't have any place
> > to map this card any more".
>
> I want to say the generic layer "What to do" in some more fine-grained way
> than just a single verb, at least. I may accept to delegate it some "How
> to do it".
>
> > No ifs, why's or buts. A driver that just enables the IO windows is a
> > buggy driver.
>
> In PCI, you donnot enable windows, but you enable/disable devices to
> generate and/or respond to transactions.
Well really? From the programmers point-of-view, you have just enabled
some windows into address space. The word "transaction" has gotten way
too much visibility. The fact that some hardware mechanism has gotten
involved reading from and writing to a device means nothing except
that a write (if enabled) is posted. We don't bother thinking about
"transactions" when we write to SDRAM do we? To the programmer, we
write to it and it sticks. The fact that there was a hardware transaction
involving a read/modify/write of (usually) much more than our byte
isn't a concern.
As previously stated (under flames), there are only two kinds of
"transactions" you need to be concerned about, the first is, or should
be, never used anymore (special cycles), and the second is a configuration
transaction. These are important in that a current read/write cycle
is aborted for such a transaction. Therefore, you don't want to access
configuration space dynamically (like for turning ON/OFF device
interrupts). PCI configuration space should only be accessed as required
during device startup.
OTOH, if you look at all the bits
> in the COMMAND register, you will see that some other features are also to
> be addressed by the enabling/disabling kernel interface.
>
I think the idea of accessing the PCI bus as a logical object, where
the OS 'knows' the best way to do it is a good thing. However, the
driver is going to have to pass much more information to the procedure
than a simple pci_enable_device(dev).
This has particular importance in PPC and other Motorola-type machines
where there isn't any I/O space, but hardware emulates it as a memory
access.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
