public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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

  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