linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Liviu Dudau <liviu@dudau.co.uk>
Cc: linux-arm-kernel@lists.infradead.org,
	Will Deacon <will.deacon@arm.com>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	"bhelgaas@google.com" <bhelgaas@google.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: Sat, 15 Feb 2014 14:03:26 +0100	[thread overview]
Message-ID: <2312919.pM61KLBcYY@wuerfel> (raw)
In-Reply-To: <20140214220047.GA5394@bart.dudau.co.uk>

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?

If we do need to stuff multiple buses into one domain, how about
using this approach in pci_hostbridge_of_init():

  The first time we add a host bridge, scan the entire DT for
  devices setting device_type="pci". If there is actually more
  than one host bridge, check all "bus-range" properties to
  see if they overlap. If there is no overlap or only one
  bridge, don't use domains.
  If there is any overlap at all, or there are multiple host
  bridge and one of them does not have a bus-range property,
  use a separate domain per host bridge.
  Remember the function was called before so it doesn't
  have to scan the DT again, and count the domain locally.

Does this make sense?

	Arnd

  reply	other threads:[~2014-02-15 13:04 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 [this message]
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
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=2312919.pM61KLBcYY@wuerfel \
    --to=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --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).