Adam Belay wrote:
On Thu, Mar 02, 2006 at 07:34:41PM +0000, Russell King wrote:
On Thu, Mar 02, 2006 at 10:24:36AM -0700, Grant Grundler wrote:
On Thu, Mar 02, 2006 at 03:50:57PM +0000, Russell King wrote:
I've been wondering whether this "no_ioport" flag is the correct approach,
or whether it's adding to complexity when it isn't really required.
I think it's the simplest solution to allowing a driver
to indicate which resources it wants to use. It solves
the problem of I/O Port resource allocation sufficiently
well.
I have another question (brought up by someone working on a series of
ARM machines which make heavy use of MMIO.)
Why isn't pci_enable_device_bars() sufficient - why do we have to
have another interface to say "we don't want BARs XXX" ?
Let's say that we have a device driver which does this sequence (with,
of course, error checking):
pci_enable_device_bars(dev, 1<<1);
pci_request_regions(dev);
(a) should PCI remember that only BAR 1 has been requested to be enabled,
and as such shouldn't pci_request_regions() ignore BAR 0?
(b) should the PCI driver pass into pci_request_regions() (or even
pci_request_regions_bars()) a bitmask of the BARs it wants to have
requested, and similarly for pci_release_regions().
Basically, if BAR0 hasn't been enabled, has pci_request_regions() got
any business requesting it from the resource tree?
I understand the point you're making, but I think this misrepresents what
is actually happening. From my understanding of the spec, it's not possible
to disable individual bars (with the exception of the expansion ROM). Rather
there is one bit for IO enable and one bit for IOMMU enable. Therefore, we
can enable or disable all I/O ports, but there's really no in between. If
the device uses even one I/O port, it's still a huge loss because of the
potential bridge window dependency. Also, if a device has several I/O ports
but the driver only wants to use one, all of the others must still be
assigned.
I see. I think you are right.
In addition to the fact that there is one bit for IO enable and one
bit for MMIO enable, I think we should not enable I/O port (or MMIO)
of the device if not all the I/O port (or MMIO) regions are assigned
to the device because we must build a consistent address mapping
before enabling it.
It seems that using pci_enable_device_bars() is not a good idea.
If there is no objection, I'll design and implement take6 again.
Any comments?
Thanks,
Kenji Kaneshige
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
