Messages in this thread | | | Date | Fri, 10 Mar 2006 13:10:41 +0900 | From | Kenji Kaneshige <> | Subject | Re: [PATCH 0/4] PCI legacy I/O port free driver (take4) |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |