linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tomasz.nowicki@linaro.org (Tomasz Nowicki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 05/11] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory
Date: Thu, 15 Oct 2015 16:34:45 +0200	[thread overview]
Message-ID: <561FB985.8070509@linaro.org> (raw)
In-Reply-To: <20151015132200.GA7621@red-moon>

On 15.10.2015 15:22, Lorenzo Pieralisi wrote:
> On Mon, Sep 14, 2015 at 03:55:50PM +0100, Tomasz Nowicki wrote:
>
> [...]
>
>>> Well, I still have not figured out whether on arm64 the raw accessors
>>> required by ACPICA make sense.
>>>
>>> So either arm64 relies on the generic MCFG based raw read and writes
>>> or we define the global raw read and writes as empty (ie x86 overrides
>>> them anyway).
>>>
>>
>> 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).
>
> I am coming back to this, I am not sure that PCI config based OperationRegions
> fall into Hardware Reduced profile, I will finally start a thread on ASWG
> to check that.
>
> Other than that, are you posting an updated version of this series soon ?
> Let me know if you need help refactoring/testing the patches.
>

I am planing to send updated version next week, but honestly next 
version does make sense if we figure out raw accessors issue. So I will 
clean up all around meanwhile and optionally raw accessor.

Of course your help in testing is welcomed. Also please have a look at 
my GICv3/ITS patches, they are important for ACPI PCI.

Regards,
Tomasz

  reply	other threads:[~2015-10-15 14:34 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
2015-10-15 13:22                               ` Lorenzo Pieralisi
2015-10-15 14:34                                 ` Tomasz Nowicki [this message]
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=561FB985.8070509@linaro.org \
    --to=tomasz.nowicki@linaro.org \
    --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;
as well as URLs for NNTP newsgroup(s).