From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Liviu Dudau <Liviu.Dudau@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Tanmay Inamdar <tinamdar@apm.com>,
"galak@codeaurora.org" <galak@codeaurora.org>,
Prabhakar Kushwaha <prabhakar@freescale.com>
Subject: Re: [PATCH] arm64: PCI(e) arch support
Date: Fri, 4 Jul 2014 11:00:28 -0600 [thread overview]
Message-ID: <20140704170028.GB1736@obsidianresearch.com> (raw)
In-Reply-To: <4342569.JSAyWBcJn2@wuerfel>
On Fri, Jul 04, 2014 at 12:21:00PM +0200, Arnd Bergmann wrote:
> However, what do we do about PCI hosts that can be used with different
> kinds of systems? Do we assume that they all do PCI resource allocation?
> Can we decide this on a per host driver basis, or do we need to introduce
> an extension to the PCI DT binding to make that decision?
If the firmware sets everything up, and standard ECAM/CAM config space
is provided, then Will's simple generic driver should be selected. The
kernel shouldn't even be using code to manipulate the host
bridge. This is the x86 model.
If it is more embedded focused and firmware doesn't do much, then a
different compatible string and different driver can be used that does
have any special setup code..
The HW needs to be designed to support this, so it actually has to
imeplement configuration access properly, it can't split the config
space for the bridge with config space for the downstream, for
instance. It must implement something sensible for root port bridge
windows, and a few other common sense things.
Things are going to need to work like this anyhow on any HW that
expects to suport ACPI...
It is OK for the kernel to reconfigure the BARs and other things as it
likes, so long as the configuration access mechanism is working
properly according to the spec. IIRC it does a bit of a hybrid on x86
where it tries to leave things alone that are OK, and fix up things
that are not OK.
Jason
next prev parent reply other threads:[~2014-07-04 17:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-03 21:27 [PATCH] arm64: PCI(e) arch support Tanmay Inamdar
2014-07-04 0:40 ` Prabhakar Kushwaha
2014-07-04 9:44 ` Liviu Dudau
2014-07-04 10:21 ` Arnd Bergmann
2014-07-04 11:02 ` Liviu Dudau
2014-07-04 11:28 ` Arnd Bergmann
2014-07-04 11:40 ` Liviu Dudau
2014-07-04 17:00 ` Jason Gunthorpe [this message]
2014-07-07 18:26 ` Tanmay Inamdar
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=20140704170028.GB1736@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=Liviu.Dudau@arm.com \
--cc=arnd@arndb.de \
--cc=galak@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=prabhakar@freescale.com \
--cc=tinamdar@apm.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).