From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 3/3] PCI: ARM: add support for generic PCI host controller
Date: Wed, 19 Feb 2014 15:17:56 +0100 [thread overview]
Message-ID: <2724033.O0vxCdfViQ@wuerfel> (raw)
In-Reply-To: <20140219110718.GD28173@mudshark.cambridge.arm.com>
On Wednesday 19 February 2014 11:07:19 Will Deacon wrote:
> On Tue, Feb 18, 2014 at 07:10:23PM +0000, Will Deacon wrote:
> > On Tue, Feb 18, 2014 at 01:46:44PM +0000, Arnd Bergmann wrote:
> > > On Tuesday 18 February 2014 12:20:43 Will Deacon wrote:
> > > > + /* Register our I/O and Memory resources */
> > > > + res_valid = 0;
> > > > + list_for_each_entry(win, &pci->host.windows, list) {
> > > > + struct resource *parent;
> > > > +
> > > > + if (resource_type(win->res) == IORESOURCE_IO) {
> > > > + parent = &ioport_resource;
> > > > + err = pci_ioremap_io(win->offset, win->res->start);
> > >
> > > and consequently pass the pci_addr rather than the offset here. How about
> > > moving the pci_ioremap_io() call into gen_pci_alloc_io_offset()?
>
> I've probably just confused myself, but passing the pci_addr to
> pci_ioremap_io doesn't make sense to me.
I think the confusion is that there are two different things we call
offset here. The calculation of the offset you pass into
pci_ioremap_io() is correct AFAICT now, but it's not what you are
supposed to pass into pci_add_resource_offset() or what we normally
put into pci_host_bridge_window->offset.
> My understanding is that:
>
> cpu = bus + offset
Right. This would be the case for mem_offset.
> In the case of I/O, the offset is really:
>
> offset = (PCI_IO_VIRT_BASE - bus) + window
I can't seem to make sense of this calculation. PCI_IO_VIRT_BASE
is a pointer to the start of the virtual window. You can add offsets
to the pointer, but subtracting a number from it is not a well-defined
operation.
> where window is determined by the simple allocator I wrote.
And your allocator calls it offset, which is what confused me.
> Now, the __io macro takes care of PCI_IO_VIRT_BASE so we don't actually care
> about that when adding the PCI I/O resources, instead we'll just pass:
>
> offset = window - bus
Yes, this would be the io_offset that you pass into pci_add_resource_offset().
> and then pci_ioremap_io will just want the window offset, since that's added
> directly on to PCI_IO_VIRT_BASE for the ioremap_page_range.
Yes.
> If I call pci_ioremap_io(range->pci_addr, ...) then I'm going to trip a BUG_ON
> unless the pci_addr is within IO_SPACE_LIMIT.
range->pci_addr is what you call 'bus' above. Since you want 'window', you
have to pass 'bus'+'offset', or 'range->pci_addr + io_offset'. Normally, one
of the two would be zero, while the other is equal to 'window'.
Arnd
next prev parent reply other threads:[~2014-02-19 14:17 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-18 12:20 [PATCH v3 0/3] ARM: PCI: implement generic PCI host controller Will Deacon
2014-02-18 12:20 ` [PATCH v3 1/3] ARM: mach-virt: allow PCI support to be selected Will Deacon
2014-02-18 12:20 ` [PATCH v3 2/3] ARM: bios32: use pci_enable_resource to enable PCI resources Will Deacon
2014-02-18 15:41 ` Russell King - ARM Linux
2014-02-18 19:10 ` Will Deacon
2014-02-20 11:12 ` Will Deacon
2014-02-20 19:39 ` Bjorn Helgaas
2014-02-21 0:36 ` Jason Gunthorpe
2014-02-21 13:49 ` Will Deacon
2014-02-18 12:20 ` [PATCH v3 3/3] PCI: ARM: add support for generic PCI host controller Will Deacon
2014-02-18 13:46 ` Arnd Bergmann
2014-02-18 19:10 ` Will Deacon
2014-02-19 11:07 ` Will Deacon
2014-02-19 14:17 ` Arnd Bergmann [this message]
2014-02-19 15:25 ` Will Deacon
2014-02-18 18:21 ` Jason Gunthorpe
2014-02-18 18:44 ` Will Deacon
2014-02-18 18:47 ` Arnd Bergmann
2014-02-18 18:51 ` Will Deacon
2014-02-18 19:11 ` Arnd Bergmann
2014-02-18 19:16 ` Will Deacon
2014-02-18 18:59 ` Jason Gunthorpe
2014-02-18 19:09 ` Will Deacon
2014-02-18 19:32 ` Arnd Bergmann
2014-02-18 19:36 ` Will Deacon
2014-02-18 19:57 ` Will Deacon
2014-02-18 20:19 ` Arnd Bergmann
2014-02-19 10:57 ` Will Deacon
2014-02-18 20:15 ` Arnd Bergmann
2014-02-19 10:54 ` 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=2724033.O0vxCdfViQ@wuerfel \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.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