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
next prev 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).