Re: [PATCH 0/4] PCI legacy I/O port free driver (take4)

[Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>]

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/