linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bhelgaas@google.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Liviu Dudau <liviu@dudau.co.uk>,
	linux-arm-kernel@lists.infradead.org,
	Will Deacon <will.deacon@arm.com>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Kumar Gala <galak@codeaurora.org>,
	Russell King <rmk@arm.linux.org.uk>
Subject: Re: [PATCH v2 3/3] PCI: ARM: add support for generic PCI host controller
Date: Tue, 18 Feb 2014 17:28:14 -0700	[thread overview]
Message-ID: <20140219002814.GD8786@google.com> (raw)
In-Reply-To: <2312919.pM61KLBcYY@wuerfel>

On Sat, Feb 15, 2014 at 02:03:26PM +0100, Arnd Bergmann wrote:
> On Friday 14 February 2014 22:00:47 Liviu Dudau wrote:
> > 
> > What I'm going to suggest in my v2 patch (hope to send it before Monday)
> > is a new API in the generic PCI code that will allow you to create a
> > host bridge in a new domain or in the existing domain, with the management
> > of the domain number being done in the generic code.
> > 
> > Something like:
> > 
> >   int create_hostbridge_in_new_domain(....);
> >   int create_hostbridge(....);
> > 
> > with the functions being wrappers around the pci_hostbridge_of_init function
> > that I'm introducing.
> > 
> > What do you think?
> 
> Not sure. It would still keep the decision about whether to use a
> new domain or not in the host bridge driver, but that doesn't seem
> like the right place. The same driver might be used in different
> ways based on what is around it.
> 
> I've also had a look at the MIPS implementation now, which has its
> own way of dealing with this, see arch/mips/pci/pci.c.
> 
> There was also an interesting comment in the MIPS header file:
> 
>         /* For compatibility with current (as of July 2003) pciutils
>            and XFree86. Eventually will be removed. */
>         unsigned int need_domain_info;
> 
> This is over ten years old, so I wonder if we can start assuming that
> domains work out of the box now. All references to problems from 
> PCI domains are about old code (ca. pre-2007) that doesn't understand
> nonzero domains and that has since been fixed. I am pretty sure we
> don't need to ever worry about stuffing multiple host bridges into
> a domain other than the first one, and I also doubt we have to worry
> about the problem at all on arm64 as we won't run old binaries on it
> (or arm32 compat mode binaries that need to manage PCI devices).
> 
> Can anyone with more experience on the subject than me (Bjorn,
> Russell, Jason, ...) think of a reason why we would not want to
> just use a new domain for every host bridge we find?

With ACPI on x86 and ia64, we currently use _SEG directly as the Linux
PCI domain.  Are you proposing that we make the Linux PCI domain
independent of _SEG?

It will look sort of funny to have things like this:

  ACPI: PCI Root Bridge [L000] (_SEG 0 domain 0000 [bus 00-1b])
  ACPI: PCI Root Bridge [L001] (_SEG 0 domain 0001 [bus 1c-37])
  ACPI: PCI Root Bridge [L002] (_SEG 0 domain 0002 [bus 38-53])

where the firmware had _SEG==0 for all the bridges and assigned
non-overlapping bus number ranges, but since nothing in PCI really
depends on the domain, I guess it should work.

Bjorn

  parent reply	other threads:[~2014-02-19  0:28 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-12 20:16 [PATCH v2 0/3] ARM: PCI: implement generic PCI host controller Will Deacon
2014-02-12 20:16 ` [PATCH v2 1/3] ARM: mach-virt: allow PCI support to be selected Will Deacon
2014-02-12 20:16 ` [PATCH v2 2/3] ARM: bios32: use pci_enable_resource to enable PCI resources Will Deacon
2014-02-12 22:28   ` Jason Gunthorpe
2014-02-13 10:06     ` Will Deacon
2014-02-13 12:22   ` Jingoo Han
2014-02-12 20:16 ` [PATCH v2 3/3] PCI: ARM: add support for generic PCI host controller Will Deacon
2014-02-12 20:59   ` Arnd Bergmann
2014-02-13 11:04     ` Will Deacon
2014-02-13 11:47       ` Arnd Bergmann
2014-02-13 12:00         ` Will Deacon
2014-02-13 12:21           ` Arnd Bergmann
2014-02-12 21:51   ` Kumar Gala
2014-02-13 11:07     ` Will Deacon
2014-02-13 16:22       ` Kumar Gala
2014-02-13 16:25         ` Will Deacon
2014-02-13 16:28         ` Arnd Bergmann
2014-02-13 18:11           ` Mark Rutland
2014-02-13 18:26           ` Jason Gunthorpe
2014-02-13 19:53             ` Will Deacon
2014-02-13 20:20               ` Jason Gunthorpe
2014-02-14  9:59               ` Arnd Bergmann
2014-02-14 22:00                 ` Liviu Dudau
2014-02-15 13:03                   ` Arnd Bergmann
2014-02-18 17:41                     ` Jason Gunthorpe
2014-02-18 18:25                       ` Arnd Bergmann
2014-02-18 18:45                         ` Jason Gunthorpe
2014-02-18 19:13                           ` Arnd Bergmann
2014-02-19  2:44                       ` Liviu Dudau
2014-02-19  6:48                         ` Jason Gunthorpe
2014-02-19 10:24                         ` Arnd Bergmann
2014-02-19 11:37                           ` Liviu Dudau
2014-02-19 13:26                             ` Arnd Bergmann
2014-02-19 15:30                               ` Liviu Dudau
2014-02-19 19:47                                 ` Arnd Bergmann
2014-02-19  0:28                     ` Bjorn Helgaas [this message]
2014-02-19  9:58                       ` Arnd Bergmann
2014-02-19 18:20                         ` Bjorn Helgaas
2014-02-19 19:06                           ` Arnd Bergmann
2014-02-19 20:18                             ` Bjorn Helgaas
2014-02-19 20:48                               ` Arnd Bergmann
2014-02-19 21:10                                 ` Jason Gunthorpe
2014-02-19 21:33                                 ` Bjorn Helgaas
2014-02-19 22:12                                   ` Arnd Bergmann
2014-02-19 22:18                                     ` Bjorn Helgaas
2014-02-13 19:52         ` Rob Herring
2014-02-13 18:06       ` Jason Gunthorpe
2014-02-13 19:51         ` Will Deacon
2014-02-13 18:26 ` [PATCH v2 0/3] ARM: PCI: implement " Jason Gunthorpe
2014-02-14 11:05   ` Arnd Bergmann
2014-02-18 18:00     ` Jason Gunthorpe
2014-02-18 18:40       ` Arnd Bergmann

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=20140219002814.GD8786@google.com \
    --to=bhelgaas@google.com \
    --cc=arnd@arndb.de \
    --cc=galak@codeaurora.org \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=liviu@dudau.co.uk \
    --cc=rmk@arm.linux.org.uk \
    --cc=will.deacon@arm.com \
    /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).