From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"hanjun.guo@linaro.org" <hanjun.guo@linaro.org>,
Liviu Dudau <Liviu.Dudau@arm.com>,
Yijing Wang <wangyijing@huawei.com>,
Will Deacon <Will.Deacon@arm.com>, Arnd Bergmann <arnd@arndb.de>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Jiang Liu <jiang.liu@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
"msalter@redhat.com" <msalter@redhat.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>
Subject: Re: [PATCH 05/11] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory
Date: Fri, 25 Sep 2015 17:19:24 +0100 [thread overview]
Message-ID: <20150925161924.GA2271@red-moon> (raw)
In-Reply-To: <56057001.9000101@linaro.org>
On Fri, Sep 25, 2015 at 05:02:09PM +0100, Tomasz Nowicki wrote:
[...]
> > My concerns/ideas related to raw accessors for ARM64, please correct me
> > at any point.
> >
> > ACPI spec - chapter: 19.5.96 OperationRegion (Declare Operation Region)
> > defines PCI_Config as one of region types. Every time ASL opcode
> > operates on corresponding PCI config space region, ASL interpreter is
> > dispatching address space to our raw accessors, please see
> > acpi_ex_pci_config_space_handler, acpi_ev_pci_config_region_setup calls.
> > What is more important, such operations may happen after (yes after) bus
> > enumeration, but always raw accessors are called at the end with the
> > {segment, bus, dev, fn} tuple.
> >
> > Giving above, here are some ideas:
> > 1. We force somehow vendors to avoid operations on PCI config regions in
> > ASL code. PCI config region definitions still fall into Hardware Reduced
> > profile, so new ACPICA special subset for ARM64 is need. Then raw ACPI
> > accessors can be empty (and overridden by x86).
> > 2. We provide raw accessors which translate {segment, bus, dev, fn}
> > tuple to Linux generic accessors (this can be considered only if PCI
> > config accesses happened after bus enumeration for HR profile, thus
> > tuple to bus structure map is possible).
> > 4. We rely on the generic MCFG based raw read and writes.
>
> I will appreciate your opinion on above ideas.
Well, (1) does not seem allowed by the ACPI specification, the only
way we can detect that is by leaving the raw accessors empty for
now and see how things will turn out on ARM64, in the meantime
I will start a thread on ASWG to check how that's used on x86, I
do not have any machine to test this and grokking ACPICA is not
trivial, there is lots of history there and it is hard to fathom.
(2) is tempting but I am not sure it works all the time (I still
think that's a quirk of ACPI specs, namely that some OperationRegion
should always be available to ASL, maybe that's just an unused ACPI
spec quirk).
If I read you series correctly (4) can be implemented easily if and
when we deem the raw accessors necessary, on top of the MCFG layer,
by making the MCFG raw accessors the default instead of leaving them
empty.
I pulled your branch and started testing it on AMD Seattle, next week
we should try to get this done.
I think you should target option (1) and in the meantime we should
reach a conclusion on the raw accessors usage on ARM64.
Thanks,
Lorenzo
next prev parent reply other threads:[~2015-09-25 16:19 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-26 12:49 [PATCH 00/11] ARM64 PCI hostbridge init based on ACPI Hanjun Guo
2015-05-26 12:49 ` [PATCH 01/11] ARM64 / PCI: introduce struct pci_controller for ACPI Hanjun Guo
2015-05-26 16:58 ` Liviu Dudau
2015-05-26 17:20 ` Jiang Liu
2015-05-27 8:21 ` Hanjun Guo
2015-09-07 4:14 ` Ganapatrao Kulkarni
2015-09-07 8:45 ` Lorenzo Pieralisi
2015-09-08 13:35 ` Hanjun Guo
2015-05-27 9:47 ` Liviu Dudau
2015-05-27 11:29 ` Jiang Liu
2015-05-26 12:49 ` [PATCH 02/11] x86, pci: Clean up comment about buggy MMIO config space access for AMD Fam10h CPUs Hanjun Guo
2015-08-31 12:04 ` Tomasz Nowicki
2015-05-26 12:49 ` [PATCH 03/11] x86, pci: Abstract PCI config accessors and use AMD Fam10h workaround exclusively Hanjun Guo
2015-05-26 12:49 ` [PATCH 04/11] x86, pci: Reorder logic of pci_mmconfig_insert() function Hanjun Guo
2015-05-26 12:49 ` [PATCH 05/11] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory Hanjun Guo
2015-05-26 17:08 ` Will Deacon
2015-05-27 8:06 ` Tomasz Nowicki
2015-06-02 13:32 ` Lorenzo Pieralisi
2015-06-04 9:28 ` Hanjun Guo
2015-06-04 10:22 ` Lorenzo Pieralisi
2015-06-04 12:28 ` Hanjun Guo
2015-06-08 2:57 ` Hanjun Guo
2015-06-08 15:14 ` Lorenzo Pieralisi
2015-08-31 11:01 ` Tomasz Nowicki
2015-09-07 9:59 ` Tomasz Nowicki
2015-09-08 15:07 ` Lorenzo Pieralisi
2015-09-09 13:47 ` Tomasz Nowicki
2015-09-11 11:20 ` Lorenzo Pieralisi
2015-09-11 12:35 ` Tomasz Nowicki
2015-09-14 9:37 ` Lorenzo Pieralisi
2015-09-14 11:34 ` Tomasz Nowicki
2015-09-14 14:55 ` Tomasz Nowicki
2015-09-25 16:02 ` Tomasz Nowicki
2015-09-25 16:19 ` Lorenzo Pieralisi [this message]
2015-10-15 13:22 ` Lorenzo Pieralisi
2015-10-15 14:34 ` Tomasz Nowicki
2015-10-15 16:26 ` Marc Zyngier
2015-10-15 18:51 ` Tomasz Nowicki
2015-05-26 12:49 ` [PATCH 06/11] pci, acpi, mcfg: Provide generic implementation of MCFG code initialization Hanjun Guo
2015-05-26 12:49 ` [PATCH 07/11] x86, pci: mmconfig_{32, 64}.c code refactoring - remove code duplication Hanjun Guo
2015-05-26 12:49 ` [PATCH 08/11] x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM driver Hanjun Guo
2015-05-26 12:49 ` [PATCH 09/11] pci, acpi, mcfg: Share ACPI PCI config space accessors Hanjun Guo
2015-05-26 12:49 ` [PATCH 10/11] XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y Hanjun Guo
2015-05-26 13:54 ` Boris Ostrovsky
2015-05-26 14:00 ` Boris Ostrovsky
2015-05-26 14:54 ` Tomasz Nowicki
2015-05-26 15:44 ` Boris Ostrovsky
2015-05-27 3:55 ` Hanjun Guo
2015-05-26 12:49 ` [PATCH 11/11] ARM64 / PCI / ACPI: support for ACPI based PCI hostbridge init Hanjun Guo
2015-05-26 15:12 ` Tomasz Nowicki
2015-05-27 7:31 ` Hanjun Guo
2015-05-26 17:13 ` Will Deacon
2015-05-26 17:24 ` Jiang Liu
2015-05-27 0:30 ` [PATCH 00/11] ARM64 PCI hostbridge init based on ACPI Rafael J. Wysocki
2015-05-27 3:57 ` Hanjun Guo
2015-06-08 12:05 ` Jagan Teki
2015-06-10 2:47 ` Hanjun Guo
2015-10-15 19:15 ` Jon Masters
2015-10-15 23:42 ` Hanjun Guo
2015-10-15 23:49 ` Jon Masters
2015-12-07 20:29 ` Bjorn Helgaas
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=20150925161924.GA2271@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=Liviu.Dudau@arm.com \
--cc=Will.Deacon@arm.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=hanjun.guo@linaro.org \
--cc=jiang.liu@linux.intel.com \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=msalter@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=suravee.suthikulpanit@amd.com \
--cc=tglx@linutronix.de \
--cc=tomasz.nowicki@linaro.org \
--cc=wangyijing@huawei.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).