From: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
To: Borislav Petkov <bp@suse.de>,
Andreas Herrmann <herrmann.der.user@googlemail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Robert Richter <rric@kernel.org>,
Myron Stowe <myron.stowe@gmail.com>,
Myron Stowe <myron.stowe@redhat.com>,
Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>,
linux-pci <linux-pci@vger.kernel.org>, <kim.naru@amd.com>,
Daniel J Blueman <daniel@numascale.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86 <x86@kernel.org>, Steffen Persvold <sp@numascale.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"Jan Beulich" <JBeulich@suse.com>,
Yinghai Lu <yinghai@kernel.org>
Subject: Re: [PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities
Date: Tue, 29 Apr 2014 10:16:57 -0500 [thread overview]
Message-ID: <535FC269.2000808@amd.com> (raw)
In-Reply-To: <20140429102013.GA4726@pd.tnic>
On 4/29/2014 5:20 AM, Borislav Petkov wrote:
> On Tue, Apr 29, 2014 at 09:33:09AM +0200, Andreas Herrmann wrote:
>> I am sure, it's because some server systems had MMIO ECS access not
>> enabled in BIOS. I can't remember which systems were affected.
>
If you are referring to accessing PCI ECS ranges via 0xCF8, then yes,
BIOS disable this as described below in the BKDG.
"The BIOS may use either configuration space access mechanism during
boot. Before booting the OS, BIOS must disable IO access to ECS, enable
MMIO configuration and build an ACPI defined MCFG table. BIOS ACPI code
must use MMIO to access configuration space."
> Ok, now AMD people: what's the story with IO ECS, can we assume that on
> everything after F10h, BIOS has a sensible MCFG and we can limit this to
> F10h only? I like Bjorn's idea but we need to make sure a working MCFG
> is ubiquitous.
>
> Which begs the real question: Suravee, why are you even touching IO ECS
> provided F15h and later have a MCFG? Or, do they?
>
As I was trying to generalize the logic inside amd_bus.c, which seems to
be used mainly as a fallback mechanism, I tried to maintain the existing
code, which does many things:
1. Setup numa_node information (if PXM doesn't exist)
2. Probe NB for MMIO resources (if MCFG doesn't exist)
3. Probe NB for IO resources
4. Setup IO ECS
In the new code, the IO ECS was needed to retrieve the
AMD_NB_F1_MMIO_BASE_LIMIT_HI_REG (offset 0x180) during the early
initialization as part of (2) logic. However, this register exists only
on the newer systems. However, as you mentioned, for (2) we can assume
that the MCFG exists for most of the systems (family10h and later), and
should be used instead.
The main purpose of this patch set is mainly to deal with the the node
information (1). So, we might need to split these all up and handle
them separately as needed where (2) and (3) will be used as fallback for
older systems where MCFG does not exist. I am not sure if where we need (4).
Suravee
next prev parent reply other threads:[~2014-04-29 15:16 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-05 21:06 [PATCH 0/3] amd/pci: Add AMD hostbridge supports for newer AMD systems suravee.suthikulpanit
2014-03-05 21:06 ` [PATCH 1/3] amd/pci: Add supports for generic AMD hostbridges suravee.suthikulpanit
2014-03-05 21:06 ` [PATCH 2/3] amd/pci: Support additional MMIO ranges capabilities suravee.suthikulpanit
2014-03-20 17:33 ` Bjorn Helgaas
2014-03-05 21:06 ` [PATCH 3/3] amd/pci: Miscellaneous code clean up for early_fillup_mp_bus_info suravee.suthikulpanit
2014-03-05 21:24 ` [PATCH 0/3] amd/pci: Add AMD hostbridge supports for newer AMD systems Bjorn Helgaas
2014-03-06 2:13 ` Suravee Suthikulanit
2014-03-06 6:30 ` Suravee Suthikulpanit
2014-03-06 17:40 ` Bjorn Helgaas
2014-03-06 20:03 ` Suravee Suthikulpanit
2014-03-11 18:12 ` Bjorn Helgaas
2014-03-12 21:13 ` Bjorn Helgaas
2014-03-13 1:30 ` Myron Stowe
2014-03-14 2:06 ` Suravee Suthikulpanit
2014-03-17 17:18 ` Bjorn Helgaas
2014-03-20 17:42 ` Bjorn Helgaas
2014-04-19 2:53 ` [PATCH v2 0/5] x86/PCI: Add AMD hostbridge support " Myron Stowe
2014-04-19 2:53 ` [PATCH v2 1/5] x86/PCI: Add support for generic AMD hostbridges Myron Stowe
2014-04-19 11:31 ` Borislav Petkov
2014-04-28 21:10 ` Myron Stowe
2014-04-19 2:53 ` [PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities Myron Stowe
2014-04-19 13:52 ` Borislav Petkov
2014-04-20 7:59 ` Borislav Petkov
2014-04-25 22:24 ` Myron Stowe
2014-04-26 9:10 ` Borislav Petkov
2014-04-28 20:50 ` Bjorn Helgaas
2014-04-28 21:40 ` Borislav Petkov
2014-04-29 7:33 ` Andreas Herrmann
2014-04-29 10:20 ` Borislav Petkov
2014-04-29 13:07 ` Steffen Persvold
2014-04-29 15:16 ` Suravee Suthikulanit [this message]
2014-04-29 19:14 ` Borislav Petkov
2014-04-29 21:40 ` Myron Stowe
2014-04-30 7:00 ` Robert Richter
2014-04-30 7:50 ` Suravee Suthikulpanit
2014-04-30 9:51 ` Robert Richter
2014-04-30 23:03 ` Myron Stowe
2014-04-29 11:19 ` Robert Richter
2014-04-29 7:06 ` Jan Beulich
2014-04-29 3:04 ` Suravee Suthikulanit
2014-04-28 21:19 ` Myron Stowe
2014-04-29 2:47 ` Suravee Suthikulanit
2014-04-29 17:17 ` Robert Richter
2014-04-30 6:41 ` Robert Richter
2014-04-19 2:53 ` [PATCH v2 3/5] x86/PCI: Miscellaneous code clean up for early_fillup_mp_bus_info Myron Stowe
2014-04-20 8:02 ` Borislav Petkov
2014-04-28 21:21 ` Myron Stowe
2014-04-19 2:53 ` [PATCH v2 4/5] ACPI/PCI: Warn if we have to "guess" host bridge node information Myron Stowe
2014-04-20 10:21 ` Borislav Petkov
2014-04-28 21:24 ` Myron Stowe
2014-04-29 19:16 ` Borislav Petkov
2014-04-19 2:53 ` [PATCH v2 5/5] PCI: Remove redundant 'quirk_amd_nb_node' Myron Stowe
2014-04-20 10:54 ` Borislav Petkov
2014-04-20 13:44 ` Myron Stowe
2014-04-21 16:53 ` Daniel J Blueman
2014-04-29 2:02 ` Suravee Suthikulanit
2014-04-29 19:29 ` Bjorn Helgaas
2014-04-28 21:28 ` Myron Stowe
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=535FC269.2000808@amd.com \
--to=suravee.suthikulpanit@amd.com \
--cc=JBeulich@suse.com \
--cc=aravind.gopalakrishnan@amd.com \
--cc=bhelgaas@google.com \
--cc=bp@suse.de \
--cc=daniel@numascale.com \
--cc=herrmann.der.user@googlemail.com \
--cc=hpa@zytor.com \
--cc=kim.naru@amd.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=myron.stowe@gmail.com \
--cc=myron.stowe@redhat.com \
--cc=rric@kernel.org \
--cc=sp@numascale.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yinghai@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).