From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 2/2] PCI: exynos: Add PCIe support for Samsung GH7 SoC
Date: Wed, 23 Apr 2014 18:20:44 +0200 [thread overview]
Message-ID: <14215032.8jhN17iHj5@wuerfel> (raw)
In-Reply-To: <20140423142315.GO865@e106497-lin.cambridge.arm.com>
On Wednesday 23 April 2014 15:23:16 Liviu Dudau wrote:
> > Unfortunately we are in a tricky situation on arm64 because we have
> > to support both server-type SoCs and embedded-type SoCs. In an
> > embedded system, you can't trust the boot loader to do a proper
> > setup of all the hardware, so the kernel needs full control over
> > all the initialization. In a server, the initialization is the
> > responsibility of the firmware, and we don't want the kernel to
> > even know about those registers.
> >
> > My hope is that all server chips use an SBSA compliant PCIe
> > implementation, but we already have X-Gene, which is doing server
> > workloads with a nonstandard PCIe, and it's possible that there
> > will also be server-like systems with a DesignWare PCIe block
> > instead of an SBSA compliant one. We can still support those, but
> > I don't want to see more than one implementation of dw-pcie
> > on servers. Just like we have the generic PCIe support that Will
> > is doing for virtual machines and SBSA compliant systems, we
> > would do one dw-pcie variant for all systems that come with a
> > host firmware and rely on it being set up already.
>
> There is nothing in the SBSA that mandates firmware setup. All it requires
> is that hardware is setup in a way that is not specific to a board
> or a particular OEM. Surely if the setup being done for GH7 is always
> the same it should fit the bill?
GH7 is already not SBSA compliant because it uses a nonstandard config
space access method, and it uses its own MSI controller rather than GIC.
This means it violates at least two out of the four clauses in SBSA
describing PCIe.
Regardless of this, the level of detail describing config space and
MSI handling in SBSA can only make sense if the purpose is to handle
all compliant implementations without platform specific code. If you
require platform specific setup code in the OS, this underlying assumption
no longer holds true and there is no point in having a spec in the
first place.
I think we should treat DW-PCIe in the same way if anyone attempts
to use that in a server, e.g. in SBSA level 0. As you can see here,
even when reusing hardware between Exynos and GH7, you can't just
use the same init code, so it has to be in firmware to be any good.
On a real server platform, you can't require a kernel upgrade every
time a new SoC comes out, any basic functionality like PCI just has to
work with existing OS images.
Arnd
next prev parent reply other threads:[~2014-04-23 16:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-16 4:41 [RFC PATCH 0/2] Add support for Samsung GH7 PCIe controller Jingoo Han
2014-04-16 4:42 ` [RFC PATCH 1/2] PCI: designware: Add ARM64 PCI support Jingoo Han
2014-04-16 16:57 ` Liviu Dudau
2014-04-16 18:26 ` Arnd Bergmann
2014-04-21 1:54 ` Jingoo Han
2014-04-21 9:58 ` Jingoo Han
2014-04-22 13:01 ` Liviu Dudau
2014-04-22 15:39 ` Rob Herring
2014-04-22 12:59 ` Liviu Dudau
2014-04-22 12:54 ` Liviu Dudau
2014-04-16 4:43 ` [RFC PATCH 2/2] PCI: exynos: Add PCIe support for Samsung GH7 SoC Jingoo Han
2014-04-22 14:11 ` Arnd Bergmann
2014-04-23 9:19 ` Kukjin Kim
2014-04-23 11:03 ` Arnd Bergmann
2014-04-23 14:23 ` Liviu Dudau
2014-04-23 16:20 ` Arnd Bergmann [this message]
2014-04-24 4:53 ` Kukjin Kim
2014-04-24 9:49 ` Arnd Bergmann
2014-04-23 13:00 ` Liviu Dudau
2014-04-24 12:25 ` 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=14215032.8jhN17iHj5@wuerfel \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.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