From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
linux-pci <linux-pci@vger.kernel.org>,
Liviu Dudau <Liviu.Dudau@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
LAKML <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] arm64: Add architecture support for PCI
Date: Tue, 4 Feb 2014 11:15:14 -0700 [thread overview]
Message-ID: <20140204181514.GA25695@obsidianresearch.com> (raw)
In-Reply-To: <13031998.NR888KZWhk@wuerfel>
On Tue, Feb 04, 2014 at 10:44:52AM +0100, Arnd Bergmann wrote:
> Now I want to integrate the EHCI into my SoC and not waste one
> of my precious PCIe root ports, so I have to create another PCI
> domain with its own ECAM compliant config space to put it into.
> Fortunately SBSA lets me add an arbitrary number of PCI domains,
> as long as they are all strictly compliant. To software it will
Just to touch on this for others who might be reading..
IMHO any simple SOC that requires multiple domains is *broken*. A
single domain covers all reasonable needs until you get up to
mega-scale NUMA systems, encouraging people to design with multiple
domains only complicates the kernel :(
SOC internal peripherals should all show up in the bus 0 config space
of the only domain and SOC PCI-E physical ports should show up on bus
0 as PCI-PCI bridges. This is all covered in the PCI-E specs regarding
the root complex.
Generally I would expect the internal peripherals to still be
internally connected with AXI, but also connected through the ECAM
space for configuration, control, power management and address
assignment.
> 2. all address windows are set up by the boot loader, we only
> need to know the location (IMHO this should be the
> preferred way to do things regardless of SBSA).
Linux does a full address map re-assignment on boot, IIRC. You need
more magics to inhibit that if your BAR's and bridge windows don't
work.
Hot plug is a whole other thing..
> it's possible that the designware based ones get point 4 right.
The designware one's also appear to be re-purposed end point cores, so
their config handling is somewhat bonkers. Tegra got theirs sort of
close because they re-used knowledge/IP from their x86 south bridges -
but even then they didn't really implement ECAM properly for an ARM
environment.
Since config space is where everyone to date has fallen down, I think
the SBSA would have been wise to list dword by dword what a typical
ECAM config space should look like.
Jason
next prev parent reply other threads:[~2014-02-04 18:15 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-03 18:43 [PATCH] [RFC] Add AArch64 support for PCI Liviu Dudau
2014-02-03 18:43 ` [PATCH] arm64: Add architecture " Liviu Dudau
2014-02-03 18:58 ` Arnd Bergmann
2014-02-03 19:18 ` Liviu Dudau
2014-02-03 19:21 ` kodiak furr
2014-02-03 20:05 ` Arnd Bergmann
2014-02-03 21:36 ` Liviu Dudau
2014-02-04 8:44 ` Arnd Bergmann
2014-02-04 11:09 ` Liviu Dudau
2014-02-04 11:54 ` Arnd Bergmann
2014-02-04 16:41 ` Catalin Marinas
2014-02-03 23:07 ` Rob Herring
2014-02-03 23:31 ` Jason Gunthorpe
2014-02-04 9:44 ` Arnd Bergmann
2014-02-04 13:57 ` Rob Herring
2014-02-04 19:50 ` Arnd Bergmann
2014-02-04 18:15 ` Jason Gunthorpe [this message]
2014-02-04 18:34 ` Arnd Bergmann
2014-02-04 19:10 ` Jason Gunthorpe
2014-02-04 19:21 ` Arnd Bergmann
2014-02-04 9:01 ` Arnd Bergmann
2014-02-03 22:34 ` Andrew Murray
2014-02-04 12:29 ` Liviu Dudau
2014-02-04 13:23 ` Andrew Murray
2014-02-04 16:18 ` Arnd Bergmann
2014-02-18 6:33 ` Yijing Wang
2014-02-20 14:38 ` Liviu Dudau
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=20140204181514.GA25695@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=Catalin.Marinas@arm.com \
--cc=Liviu.Dudau@arm.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).