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.
Thanks,
Adam
-
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]
