Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1410890 > unrolled thread

RE: [PATCH V8 0/9] Support for ARM64 ACPI based PCI host controller

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: [PATCH V8 0/9] Support for ARM64 ACPI based PCI host controller Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2016-06-01 09:40 +0200
    Re: [PATCH V8 0/9] Support for ARM64 ACPI based PCI host controller Jon Masters <jcm@redhat.com> - 2016-06-02 09:40 +0200
      RE: [PATCH V8 0/9] Support for ARM64 ACPI based PCI host controller Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2016-06-02 12:10 +0200
    Re: [PATCH V8 0/9] Support for ARM64 ACPI based PCI host controller Tomasz Nowicki <tn@semihalf.com> - 2016-06-02 11:00 +0200
      RE: [PATCH V8 0/9] Support for ARM64 ACPI based PCI host controller Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2016-06-02 12:00 +0200

#1410890 — RE: [PATCH V8 0/9] Support for ARM64 ACPI based PCI host controller

Hi all

In v7 thread Lorenzo has summarized a roadmap to
get ACPI support for PCI controllers upstream.

The second point of the roadmap was
<< 2) In a real world (1) is not enough. Some ARM64 platforms, not entirely
      ECAM compliant, already shipped with the corresponding firmware that
      we can't update. HW has ECAM quirks and to work around it in the kernel
      we put forward many solutions to the problem, it is time we found a
      solution (when, of course, (1) is completed and upstream).
      Using the MCFG table OEMID matching floated around in this thread
      would work fine for most of the platforms (and cross-OS) that have
      shipped with HW ECAM quirks, so I think that's the starting point for
      our solution and that's how we can sort this out, _today_.

      The solution is a trivial look-up table:
      MCFG OEMID <-> PCI config space ops >>

I think maybe it is worth to post this quirk mechanism as RFC on
top of this v8 patchset, so that we can start to review it and
make some progress on the quirks.
 
If you agree I think Jon can tell who's the best person to
push the quirk RFC (as my understanding is that this mechanism
is currently used by some platforms deployed on the market...)

Thanks

Gab


> -----Original Message-----
> From: linux-pci-owner@vger.kernel.org [mailto:linux-pci-
> owner@vger.kernel.org] On Behalf Of Tomasz Nowicki
> Sent: 30 May 2016 16:14
> To: helgaas@kernel.org; arnd@arndb.de; will.deacon@arm.com;
> catalin.marinas@arm.com; rafael@kernel.org; hanjun.guo@linaro.org;
> Lorenzo.Pieralisi@arm.com; okaya@codeaurora.org; jchandra@broadcom.com
> Cc: robert.richter@caviumnetworks.com; mw@semihalf.com;
> Liviu.Dudau@arm.com; ddaney@caviumnetworks.com; Wangyijing;
> Suravee.Suthikulpanit@amd.com; msalter@redhat.com; linux-
> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> acpi@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> acpi@lists.linaro.org; jcm@redhat.com; andrea.gallo@linaro.org;
> dhdang@apm.com; jeremy.linton@arm.com; liudongdong (C);
> cov@codeaurora.org; Tomasz Nowicki
> Subject: [PATCH V8 0/9] Support for ARM64 ACPI based PCI host
> controller
> 
> From the functionality point of view this series may be split into the
> following logic parts:
> 1. Export ECAM API and add parent device to pci_config_window
> 2. Add IO resources handling to PCI core code
> 3. Support for generic domain assignment based on ACPI
> 4. New MCFG driver
> 5. Implement ARM64 ACPI based PCI host controller driver under
> arch/arm64/
> 
> Patches has been built on top of 4.7-rc1 and can be found here:
> git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v8)
> 
> This has been tested on Cavium ThunderX server. Any help in reviewing
> and
> testing is very appreciated.
> 
> v7 -> v8
> - move code from drivers/acpi/pci_root_generic.c to
> arch/arm64/kernel/pci.c
> - minor changes around domain assignment
> - pci_mcfg.c improvements for parsing MCFG tables and lookup its
> entries
> 
> v6 -> v7
> - drop quirks handling
> - changes for ACPI companion and domain number assignment approach
> - implement arch pcibios_{add|remove}_bus and call
> acpi_pci_{add|remove}_bus from there
> - cleanups around nomenclature
> - use resources oriented API for ECAM
> - fix for based address calculation before mapping ECAM region
> - remove useless lock for MCFG lookup
> - move MCFG stuff to separated file pci_mcfg.c
> - drop MCFG entries caching
> - rebase against 4.6-rc7
> 
> v5 -> v6
> - drop idea of x86 MMCONFIG code refactoring
> - integrate JC's patches which introduce new ECAM API:
>   https://lkml.org/lkml/2016/4/11/907
>   git: https://github.com/jchandra-brcm/linux/ (arm64-acpi-pci-v3)
> - integrate Sinan's fix for releasing IO resources, see patch [06/13]
> - added ACPI support for ThunderX ECAM and PEM drivers
> - rebase against 4.6-rc2
> 
> v4 -> v5
> - drop MCFG refactoring group patches 1-6 from series v4 and integrate
> Jayachandran's patch
>   https://patchwork.ozlabs.org/patch/575525/
> - rewrite PCI legacy IRQs allocation
> - squash two patches 11 and 12 from series v4, fixed bisection issue
> - changelog improvements
> - rebase against 4.5-rc3
> 
> v3 -> v4
> - drop Jiang's fix
> http://lkml.iu.edu/hypermail/linux/kernel/1601.1/04318.html
> - add Lorenzo's fix patch 19/24
> - ACPI PCI bus domain number assigning cleanup
> - change resource management, we now claim and reassign resources
> - improvements for applying quirks
> - drop Matthew's http://www.spinics.net/lists/linux-pci/msg45950.html
> dependency
> - rebase against 4.5-rc1
> 
> v2 -> v3
> - fix legacy IRQ assigning and IO ports registration
> - remove reference to arch specific companion device for ia64
> - move ACPI PCI host controller driver to pci_root.c
> - drop generic domain assignment for x86 and ia64 as I am not
>   able to run all necessary test variants
> - drop patch which cleaned legacy IRQ assignment since it belongs to
>   Mathew's series:
>   https://patchwork.ozlabs.org/patch/557504/
> - extend MCFG quirk code
> - rebase against 4.4
> 
> v1 -> v2
> - move non-arch specific piece of code to dirver/acpi/ directory
> - fix IO resource handling
> - introduce PCI config accessors quirks matching
> - moved ACPI_COMPANION_SET to generic code
> 
> v1 - https://lkml.org/lkml/2015/10/27/504
> v2 - https://lkml.org/lkml/2015/12/16/246
> v3 - http://lkml.iu.edu/hypermail/linux/kernel/1601.1/04308.html
> v4 - https://lkml.org/lkml/2016/2/4/646
> v5 - https://lkml.org/lkml/2016/2/16/426
> v6 - https://lkml.org/lkml/2016/4/15/594
> 
> Jayachandran C (2):
>   PCI: ecam: move ecam.h to linux/include/pci-ecam.h
>   PCI: ecam: Add parent device field to pci_config_window
> 
> Tomasz Nowicki (7):
>   pci: Add new function to unmap IO resources.
>   acpi, pci: Support IO resources when parsing PCI host bridge
>     resources.
>   pci, acpi: add acpi hook to assign domain number.
>   arm64, pci, acpi: ACPI support for legacy IRQs parsing and
>     consolidation with DT code.
>   acpi: Add generic MCFG table handling
>   arm64, pci, acpi: Provide ACPI-specific prerequisites for PCI bus
>     enumeration.
>   pci, acpi: ARM64 support for ACPI based generic PCI host controller
> 
>  arch/arm64/Kconfig                  |   2 +
>  arch/arm64/kernel/pci.c             | 143
> ++++++++++++++++++++++++++++++++++--
>  drivers/acpi/Kconfig                |   3 +
>  drivers/acpi/Makefile               |   1 +
>  drivers/acpi/pci_mcfg.c             |  94 ++++++++++++++++++++++++
>  drivers/acpi/pci_root.c             |  39 ++++++++++
>  drivers/pci/ecam.c                  |   6 +-
>  drivers/pci/ecam.h                  |  67 -----------------
>  drivers/pci/host/pci-host-common.c  |   3 +-
>  drivers/pci/host/pci-host-generic.c |   3 +-
>  drivers/pci/host/pci-thunder-ecam.c |   3 +-
>  drivers/pci/host/pci-thunder-pem.c  |   6 +-
>  drivers/pci/pci.c                   |  29 +++++++-
>  include/linux/pci-acpi.h            |   2 +
>  include/linux/pci-ecam.h            |  67 +++++++++++++++++
>  include/linux/pci.h                 |   9 ++-
>  16 files changed, 387 insertions(+), 90 deletions(-)
>  create mode 100644 drivers/acpi/pci_mcfg.c
>  delete mode 100644 drivers/pci/ecam.h
>  create mode 100644 include/linux/pci-ecam.h
> 
> --
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [next] | [standalone]

#1411943

On 06/01/2016 03:36 AM, Gabriele Paoloni wrote:

> If you agree I think Jon can tell who's the best person to
> push the quirk RFC (as my understanding is that this mechanism
> is currently used by some platforms deployed on the market...)

Let me ping Linaro folks to see who has that (quirks) ball. We can
certainly share the older OEM matching quirks Mark Salter did for
earlier RHEL(SA) internal versions as a seed for that[0] activity.

BUT...I don't think we should block this thread on the quirks. They're
separate (but important). I see Arnd's reply as well, but nobody else
has yet chimed in to this thread (and I am about to prod all of the
vendors to reply to this thread and ACK). Can I ask whether we can't
just stage v8 as-is for -next at this point? Can Arnd's (or other)
suggestions be handled as followup patches post-merge please? Bjorn?

Jon.

[0] RHEL(SA) has had three different PCIe enabled ACPI stacks maintained
independently so far since we need PCIe to boot most of the hundreds of
v8 systems we have internal to Red Hat - which all have PCI.

-- 
Computer Architect | Sent from my Fedora powered laptop

[toc] | [prev] | [next] | [standalone]

#1412091

Hi Jon

> -----Original Message-----
> From: Jon Masters [mailto:jcm@redhat.com]
> Sent: 02 June 2016 08:32
> To: Gabriele Paoloni; Tomasz Nowicki; helgaas@kernel.org;
> arnd@arndb.de; will.deacon@arm.com; catalin.marinas@arm.com;
> rafael@kernel.org; hanjun.guo@linaro.org; Lorenzo.Pieralisi@arm.com;
> okaya@codeaurora.org; jchandra@broadcom.com
> Cc: robert.richter@caviumnetworks.com; mw@semihalf.com;
> Liviu.Dudau@arm.com; ddaney@caviumnetworks.com; Wangyijing;
> Suravee.Suthikulpanit@amd.com; msalter@redhat.com; linux-
> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> acpi@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> acpi@lists.linaro.org; jcm@redhat.com; andrea.gallo@linaro.org;
> dhdang@apm.com; jeremy.linton@arm.com
> Subject: Re: [PATCH V8 0/9] Support for ARM64 ACPI based PCI host
> controller
> 
> On 06/01/2016 03:36 AM, Gabriele Paoloni wrote:
> 
> > If you agree I think Jon can tell who's the best person to
> > push the quirk RFC (as my understanding is that this mechanism
> > is currently used by some platforms deployed on the market...)
> 
> Let me ping Linaro folks to see who has that (quirks) ball. We can
> certainly share the older OEM matching quirks Mark Salter did for
> earlier RHEL(SA) internal versions as a seed for that[0] activity.

Tomasz has posted the RFC so we'll start to look at that

> 
> BUT...I don't think we should block this thread on the quirks. They're
> separate (but important). I see Arnd's reply as well, but nobody else
> has yet chimed in to this thread (and I am about to prod all of the
> vendors to reply to this thread and ACK). Can I ask whether we can't
> just stage v8 as-is for -next at this point? Can Arnd's (or other)
> suggestions be handled as followup patches post-merge please? Bjorn?

I will ask HiSilicon folks to test it so we can add Tested-by on this

Thanks

Gab

> 
> Jon.
> 
> [0] RHEL(SA) has had three different PCIe enabled ACPI stacks
> maintained
> independently so far since we need PCIe to boot most of the hundreds of
> v8 systems we have internal to Red Hat - which all have PCI.
> 
> --
> Computer Architect | Sent from my Fedora powered laptop

[toc] | [prev] | [next] | [standalone]

#1412010

Hi Gabriele,

On 01.06.2016 09:36, Gabriele Paoloni wrote:
> I think maybe it is worth to post this quirk mechanism as RFC on
> top of this v8 patchset, so that we can start to review it and
> make some progress on the quirks.

I've just posted my RFC patches, please see:
https://patchwork.ozlabs.org/patch/629121/

We can start review from there so that this series is not blocked.

Thanks,
Tomasz

[toc] | [prev] | [next] | [standalone]

#1412079

Hi Tomasz

> -----Original Message-----
> From: Tomasz Nowicki [mailto:tn@semihalf.com]
> Sent: 02 June 2016 09:52
> To: Gabriele Paoloni; helgaas@kernel.org; arnd@arndb.de;
> will.deacon@arm.com; catalin.marinas@arm.com; rafael@kernel.org;
> hanjun.guo@linaro.org; Lorenzo.Pieralisi@arm.com; okaya@codeaurora.org;
> jchandra@broadcom.com
> Cc: robert.richter@caviumnetworks.com; mw@semihalf.com;
> Liviu.Dudau@arm.com; ddaney@caviumnetworks.com; Wangyijing;
> Suravee.Suthikulpanit@amd.com; msalter@redhat.com; linux-
> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> acpi@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
> acpi@lists.linaro.org; jcm@redhat.com; andrea.gallo@linaro.org;
> dhdang@apm.com; jeremy.linton@arm.com; liudongdong (C);
> cov@codeaurora.org
> Subject: Re: [PATCH V8 0/9] Support for ARM64 ACPI based PCI host
> controller
> 
> Hi Gabriele,
> 
> On 01.06.2016 09:36, Gabriele Paoloni wrote:
> > I think maybe it is worth to post this quirk mechanism as RFC on
> > top of this v8 patchset, so that we can start to review it and
> > make some progress on the quirks.
> 
> I've just posted my RFC patches, please see:
> https://patchwork.ozlabs.org/patch/629121/
> 
> We can start review from there so that this series is not blocked.

Many Thanks for this!

Sure let's start working on this.

Cheers

Gab

> 
> Thanks,
> Tomasz

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web