From: Will Deacon <will.deacon@arm.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"bhelgaas@google.com" <bhelgaas@google.com>
Subject: Re: [RESEND PATCH 2/3] PCI: ARM: add support for generic PCI host controller
Date: Tue, 6 May 2014 17:05:05 +0100 [thread overview]
Message-ID: <20140506160504.GM30234@arm.com> (raw)
In-Reply-To: <20140502190318.GE3179@obsidianresearch.com>
On Fri, May 02, 2014 at 08:03:18PM +0100, Jason Gunthorpe wrote:
> On Fri, May 02, 2014 at 07:44:21PM +0100, Will Deacon wrote:
> > > > > + bus_range = &pci->cfg.bus_range;
> > > > > + for (busn = bus_range->start; busn <= bus_range->end; ++busn) {
> > > > > + u32 idx = busn - bus_range->start;
> > > > > + u32 sz = 1 << pci->cfg.ops->bus_shift;
> > > > > +
> > > > > + pci->cfg.win[idx] = devm_ioremap(dev,
> > > > > + pci->cfg.res.start + busn * sz,
> > > > > + sz);
> > > >
> > > > Why map each bus individually? Both CAM and ECAM define consecutive
> > > > busses consecutively in the address space, and I though ioremap was OK
> > > > with unaligned stuff?
> > >
> > > One optimization we discussed before was to do this ioremap on the first
> > > access to any config space register in one bus, so we don't actually have
> > > to map all of them but only the ones that are in use.
> >
> > Right, and this optimisation is because we don't have a lot of virtual
> > address space on 32-bit ARM, so blowing away 256M on ECAM isn't viable.
>
> But why not just
>
> devm_ioremap(dev, pci->cfg.res.start + bus_range->start * sz,
> resource_size(&bus_range) * sz);
>
> ?
I was just trying to avoid the need for a single, virtually contiguous range
where it's not actually required. If the driver is loaded as a module, we
could already have a bunch of fragmentation in the vmalloc space.
> > > Setup is called from probe, through pci_common_init_dev(), so that shouldn't
> > > make a difference.
> >
> > Given that the idea was to separate setup() and probe(), I didn't want to
> > make the assumption that I was called in probe context.
>
> IMHO, we need to have clear purposes for setup() and probe().
>
> Probe is well defined already, it requests resources, claims the
> device, puts it in reset and then does some subsystem specific thing.
> The interaction with probe and devm is also already well specified.
>
> It doesn't matter for this driver, but look at mvebu, you cannot move
> the interrupt, gpio and clock acquisitions from probe() to setup(), as
> they could all trigger a defered probe. Better to be consistent,
> especially if this is the golden reference driver we want everyone to
> follow (sorry Will)
Groan!
> To me setup() is more like netdev open(), so it should just do that
> final step to enable the links and bring up the PCI network and be
> ready to run PCI discovery. Consider, someday we might have an
> unsetup() for power mangement reasons, just like we have a close() in
> netdev.
That's what I did originally! Anyway, this is just refactoring so shouldn't
be too much work. After reading Arnd's reply, I'll move the bulk into
->probe().
> If the long term plan is to keep probe() then I don't think it makes
> sense to move probe() duties into setup(). That just restricts what we
> can do with the setup() call if setup() is now required to always
> handle defered probe and so forth.
>
> Will, don't forget this q:
Sorry, that got chopped off somehow...
> ------
> > +out_release_res:
> > + release_child_resources(&iomem_resource);
> > + release_child_resources(&ioport_resource);
>
> This looks really off to me, doesn't this free all resources in the
> system?
... yes, I suppose that would cause problems if we have multiple instances
of the driver. I could probably just release_resource(win->res) instead
of freeing the resources and use devm_request_mem_region for configuration
space.
Will
next prev parent reply other threads:[~2014-05-06 16:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-02 16:41 [RESEND PATCH 0/3] Support for Generic PCI Host Controller Will Deacon
2014-05-02 16:41 ` [RESEND PATCH 1/3] ARM: mach-virt: allow PCI support to be selected Will Deacon
2014-05-02 18:11 ` Arnd Bergmann
2014-05-02 18:21 ` Will Deacon
2014-05-02 16:41 ` [RESEND PATCH 2/3] PCI: ARM: add support for generic PCI host controller Will Deacon
2014-05-02 17:23 ` Jason Gunthorpe
2014-05-02 18:25 ` Arnd Bergmann
2014-05-02 18:44 ` Will Deacon
2014-05-02 19:03 ` Jason Gunthorpe
2014-05-02 19:29 ` Arnd Bergmann
2014-05-06 18:38 ` Will Deacon
2014-05-06 19:11 ` Arnd Bergmann
2014-05-07 9:18 ` Will Deacon
2014-05-06 16:05 ` Will Deacon [this message]
2014-05-02 16:41 ` [RESEND PATCH 3/3] MAINTAINERS: add entry for generic PCI host controller driver Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140506160504.GM30234@arm.com \
--to=will.deacon@arm.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).