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: pci_ioremap_set_mem_type(), pci_remap_iospace()
Date: Thu, 28 Apr 2016 18:23:57 +0200	[thread overview]
Message-ID: <4332620.Jdkz6hNRbl@wuerfel> (raw)
In-Reply-To: <20160428164734.0b3837be@free-electrons.com>

On Thursday 28 April 2016 16:47:34 Thomas Petazzoni wrote:

> > > We don't know at the moment of
> > > scanning the DT, what will be the address and size of the different MEM
> > > and IO mappings.
> > 
> > True, but you have bounds on the sizes of each region given the way you
> > encode the address translation. Trying to decode what the example above is
> > telling me:
> >   - each port has 0x80000_00000000 possible IO space allocated based on
> >     the MBUS_ID split of address space
> >   - same for MEM space.
> > 
> > And IMO you *should* have address and sizes for the MEM and IO mappings, as
> > they act as *upper* boundaries. No one says you need to reserve the whole
> > space, you are just describing how the hardware translates addresses between
> > the busses.
> 
> Hm, not sure what would be the benefit of changing the Device Tree with
> this, but I'm probably missing something.

Everything's fine here: we correctly describe how for each MEM and IO
window, the hardware has a 4GB address space within the MBUS.

Part of the debate back then was whether we should also fix a mapping
between the PCIs MBUS windows and the host CPU address space as we
do for all other MBUS slaves, but we decided in the end to use dynamic
allocation of MBUS windows to give us more flexibility: there are cases
where we don't know in advance how much address space to give to
each port, or whether there are enough MBUS windows to map all I/O
spaces.

> > Just for my own clarification, is the reason why the ranges are declared like
> > this due to the fact that each port is a separate entity and multiple ports
> > cannot be served by the same MBus window? What stops you from having one
> > MBus window assigned to all IO space and the other window(s) assigned to MEM
> > for individual ports?
> 
> Each port needs its own MBus window for the PCI memory space and PCI
> I/O space that is accessed by this port. The MBUS_ID(x, y) thing is
> here to encode the information that are needed to create such windows,
> which as you can see are different for each port.
> 
> So we cannot have a single MBus window for all the IO space, we need
> one per PCI port.

Right.

	Arnd

  reply	other threads:[~2016-04-28 16:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-27 22:58 pci_ioremap_set_mem_type(), pci_remap_iospace() Bjorn Helgaas
2016-04-28  7:21 ` Thomas Petazzoni
2016-04-28 12:06 ` Liviu Dudau
2016-04-28 12:13   ` Thomas Petazzoni
2016-04-28 13:02     ` Liviu Dudau
2016-04-28 13:12       ` Thomas Petazzoni
2016-04-28 14:41         ` Liviu Dudau
2016-04-28 14:47           ` Thomas Petazzoni
2016-04-28 16:23             ` Arnd Bergmann [this message]
2016-04-28 14:19 ` Bjorn Helgaas
2016-04-28 14:36   ` Thomas Petazzoni
2016-04-28 16:03     ` Bjorn Helgaas
2016-04-28 14:33 ` Bjorn Helgaas
2016-04-28 14:38   ` Thomas Petazzoni

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=4332620.Jdkz6hNRbl@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