Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1398230 > unrolled thread
| Started by | Tomasz Nowicki <tn@semihalf.com> |
|---|---|
| First post | 2016-05-10 17:30 +0200 |
| Last post | 2016-05-23 17:40 +0200 |
| Articles | 12 on this page of 52 — 15 participants |
Back to article view | Back to linux.kernel
[PATCH V7 00/11] Support for generic ACPI based PCI host controller Tomasz Nowicki <tn@semihalf.com> - 2016-05-10 17:30 +0200
[PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller Tomasz Nowicki <tn@semihalf.com> - 2016-05-10 17:30 +0200
Re: [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller "Rafael J. Wysocki" <rafael@kernel.org> - 2016-05-10 20:00 +0200
Re: [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller "Rafael J. Wysocki" <rafael@kernel.org> - 2016-05-10 20:20 +0200
Re: [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller Jayachandran C <jchandra@broadcom.com> - 2016-05-13 13:30 +0200
Re: [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller "Rafael J. Wysocki" <rafael@kernel.org> - 2016-05-13 13:40 +0200
Re: [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller Tomasz Nowicki <tn@semihalf.com> - 2016-05-13 13:50 +0200
Re: [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller Jayachandran C <jchandra@broadcom.com> - 2016-05-14 11:10 +0200
Re: [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller Tomasz Nowicki <tn@semihalf.com> - 2016-05-23 13:40 +0200
Re: [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller Matthias Brugger <mbrugger@suse.com> - 2016-05-19 19:00 +0200
[PATCH V7 05/11] acpi, pci: Support IO resources when parsing PCI host bridge resources. Tomasz Nowicki <tn@semihalf.com> - 2016-05-10 17:30 +0200
Re: [PATCH V7 05/11] acpi, pci: Support IO resources when parsing PCI host bridge resources. "Rafael J. Wysocki" <rafael@kernel.org> - 2016-05-10 20:30 +0200
Re: [PATCH V7 05/11] acpi, pci: Support IO resources when parsing PCI host bridge resources. Tomasz Nowicki <tn@semihalf.com> - 2016-05-11 09:40 +0200
[PATCH V7 01/11] PCI: Provide common functions for ECAM mapping Tomasz Nowicki <tn@semihalf.com> - 2016-05-10 17:30 +0200
[PATCH V7 03/11] pci, of: Move the PCI I/O space management to PCI core code. Tomasz Nowicki <tn@semihalf.com> - 2016-05-10 17:30 +0200
Re: [PATCH V7 03/11] pci, of: Move the PCI I/O space management to PCI core code. "Rafael J. Wysocki" <rafael@kernel.org> - 2016-05-10 20:00 +0200
Re: [PATCH V7 03/11] pci, of: Move the PCI I/O space management to PCI core code. Tomasz Nowicki <tn@semihalf.com> - 2016-05-11 09:40 +0200
Re: [PATCH V7 03/11] pci, of: Move the PCI I/O space management to PCI core code. Arnd Bergmann <arnd@arndb.de> - 2016-05-11 13:10 +0200
[PATCH V7 11/11] arm64, pci, acpi: Start using ACPI based PCI host controller driver for ARM64. Tomasz Nowicki <tn@semihalf.com> - 2016-05-10 17:30 +0200
[PATCH V7 04/11] pci: Add new function to unmap IO resources. Tomasz Nowicki <tn@semihalf.com> - 2016-05-10 17:30 +0200
Re: [PATCH V7 04/11] pci: Add new function to unmap IO resources. Jayachandran C <jchandra@broadcom.com> - 2016-05-23 10:30 +0200
[PATCH V7 02/11] PCI: generic, thunder: update to use generic ECAM API Tomasz Nowicki <tn@semihalf.com> - 2016-05-10 17:30 +0200
RE: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2016-05-11 12:50 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Tomasz Nowicki <tn@semihalf.com> - 2016-05-11 13:10 +0200
RE: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2016-05-11 15:00 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Jon Masters <jcm@redhat.com> - 2016-05-20 06:50 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-05-20 09:40 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Jon Masters <jcm@redhat.com> - 2016-05-20 10:10 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-05-20 10:30 +0200
RE: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2016-05-20 10:50 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2016-05-20 11:20 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2016-05-23 13:00 +0200
RE: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2016-05-23 17:20 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Bjorn Helgaas <helgaas@kernel.org> - 2016-05-24 01:40 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Jon Masters <jcm@redhat.com> - 2016-05-24 03:20 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Jon Masters <jcm@redhat.com> - 2016-05-24 03:50 +0200
RE: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2016-05-24 16:40 +0200
RE: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2016-05-24 09:30 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Jon Masters <jcm@redhat.com> - 2016-05-24 16:40 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2016-05-24 19:30 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Jon Masters <jcm@redhat.com> - 2016-05-24 19:40 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Bjorn Helgaas <helgaas@kernel.org> - 2016-05-24 21:10 +0200
RE: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2016-05-26 12:00 +0200
RE: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2016-05-25 08:40 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Jon Masters <jcm@redhat.com> - 2016-05-24 06:30 +0200
RE: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2016-05-20 10:20 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Jon Masters <jcm@redhat.com> - 2016-05-20 10:30 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Duc Dang <dhdang@apm.com> - 2016-05-13 05:00 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Jeremy Linton <jeremy.linton@arm.com> - 2016-05-19 20:20 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Jon Masters <jcm@jonmasters.org> - 2016-05-20 10:30 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Dongdong Liu <liudongdong3@huawei.com> - 2016-05-23 13:40 +0200
Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller Sinan Kaya <okaya@codeaurora.org> - 2016-05-23 17:40 +0200
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Jon Masters <jcm@redhat.com> |
|---|---|
| Date | 2016-05-24 19:40 +0200 |
| Message-ID | <rCotc-6fG-13@gated-at.bofh.it> |
| In reply to | #1406300 |
A big +1 to the below :) :) :) -- Computer Architect | Sent from my 64-bit #ARM Powered phone > On May 24, 2016, at 13:24, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote: > > Hi Bjorn, > > On Mon, May 23, 2016 at 06:39:18PM -0500, Bjorn Helgaas wrote: > > [...] > >> On Mon, May 23, 2016 at 03:16:01PM +0000, Gabriele Paoloni wrote: >> I don't think of ECAM support itself as a "driver". It's just a >> service available to drivers, similar to OF resource parsing. >> >> Per PCI Firmware r3.2, sec 4.1.5, "PNP0A03" means a PCI/PCI-X/PCIe >> host bridge. "PNP0A08" means a PCI-X Mode 2 or PCIe bridge that >> supports extended config space. It doesn't specify how we access that >> config space, so I think hardware with non-standard ECAM should still >> have PNP0A03 and PNP0A08 in _CID or _HID. >> >> "ECAM" as used in the specs (PCIe r3.0, sec 7.2.2, and PCI Firmware >> r3.2, sec 4.1) means: >> >> (a) a memory-mapped model for config space access, and >> (b) a specific mapping of address bits to bus/device/function/ >> register >> >> MCFG and _CBA assume both (a) and (b), so I think a device with >> non-standard ECAM mappings should not be described in MCFG or _CBA. >> >> If a bridge has ECAM with non-standard mappings, I think either a >> vendor-specific _HID or a device-specific method, e.g., _DSM, could >> communicate that. >> >> Jon, I agree that we should avoid describing non-standardized hardware >> in Linux-specific ways. Is there a mechanism in use already? How >> does Windows handle this? DMI is a poor long-term solution because it >> requires ongoing maintenance for new platforms, but I think it's OK >> for getting started with platforms already shipping. >> >> A _DSM has the advantage that once it is defined and supported, OEMs >> can ship new platforms without requiring a new quirk or a new _HID to >> be added to a driver. >> >> There would still be the problem of config access before the namespace >> is available, i.e., the MCFG use case. I don't know how important >> that is. Defining an MCFG extension seems like the most obvious >> solution. > > Your summary above is a perfect representation of the situation. > > We had an opportunity to sync-up on the current status of ACPI PCI > for ARM64 (and talked about a way forward for this series, which > includes quirks handling), let me summarize it here for everyone > involved so that we can agree on a way forward. > > 1) ACPI PCI support for PNP0A03/PNP0A08 host bridges on top of MCFG > ECAM for config space is basically ready (Tomasz and JC addressed > Rafael's concerns in relation to ARM64 specific code, and managed > to find a way to allocate domain numbers in preparation for Arnd > pci_create_root_bus() clean-up, v8 to be posted shortly and should > be final). This provides support for de-facto ACPI/PCI ECAM base > standard for ARM64 (with a clean-split between generic code and ARM64 > bits, where ARM64, like X86 and IA64, manages in arch code IO space and > PCI resources, to be further consolidated in the near future). > I do not think anyone can complain about the generality of what we > achieved, for systems that are PCI standard (yes, PCI STANDARD) this > would just be sufficient. > 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 > > 3) (2) does not just work on some platforms (and we can't predict the > future either - actually I can, it is three letters, ECAM), simply > because MCFG OEMID matching does not provide a way to attach further > data to the MCFG (eg if config space for, say, bus 0 domain 0, is not > ECAM compliant, the config region can't be handled and must not be > handled through a corresponding MCFG region. > That's the problem Gabriele is facing and wants to solve through > something like: > > https://lkml.org/lkml/2016/3/9/91 > > in the respective ACPI tables-bindings. It may be an idea worth > pursuing, it does not solve (2) simply because that FW has shipped, > we can't patch it any longer. > > Hence to finally support ACPI PCI on ARM64 I suggest we carry out the > following steps, in order: > > - Let's complete/merge (1), that's fundamental to this whole thread > - On top of (1) we apply a quirking mechanism based on (2) that allows > us to boot mainline with boxes shipping today with no FW update required. > - We devise a way to handle quirks that is more generic than (2) so that > can we can accomodate further platforms that can't rely on (2) but > have more leeway in terms of FW updates. > > I hope that's a reasonable plan, Tomasz's v8 series coming to kick it off. > > Thank you, > Lorenzo
[toc] | [prev] | [next] | [standalone]
| From | Bjorn Helgaas <helgaas@kernel.org> |
|---|---|
| Date | 2016-05-24 21:10 +0200 |
| Subject | Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller |
| Message-ID | <rCpSi-7fZ-13@gated-at.bofh.it> |
| In reply to | #1406300 |
On Tue, May 24, 2016 at 06:24:23PM +0100, Lorenzo Pieralisi wrote:
> Hi Bjorn,
>
> On Mon, May 23, 2016 at 06:39:18PM -0500, Bjorn Helgaas wrote:
>
> [...]
>
> > On Mon, May 23, 2016 at 03:16:01PM +0000, Gabriele Paoloni wrote:
> > I don't think of ECAM support itself as a "driver". It's just a
> > service available to drivers, similar to OF resource parsing.
> >
> > Per PCI Firmware r3.2, sec 4.1.5, "PNP0A03" means a PCI/PCI-X/PCIe
> > host bridge. "PNP0A08" means a PCI-X Mode 2 or PCIe bridge that
> > supports extended config space. It doesn't specify how we access that
> > config space, so I think hardware with non-standard ECAM should still
> > have PNP0A03 and PNP0A08 in _CID or _HID.
> >
> > "ECAM" as used in the specs (PCIe r3.0, sec 7.2.2, and PCI Firmware
> > r3.2, sec 4.1) means:
> >
> > (a) a memory-mapped model for config space access, and
> > (b) a specific mapping of address bits to bus/device/function/
> > register
> >
> > MCFG and _CBA assume both (a) and (b), so I think a device with
> > non-standard ECAM mappings should not be described in MCFG or _CBA.
> >
> > If a bridge has ECAM with non-standard mappings, I think either a
> > vendor-specific _HID or a device-specific method, e.g., _DSM, could
> > communicate that.
> >
> > Jon, I agree that we should avoid describing non-standardized hardware
> > in Linux-specific ways. Is there a mechanism in use already? How
> > does Windows handle this? DMI is a poor long-term solution because it
> > requires ongoing maintenance for new platforms, but I think it's OK
> > for getting started with platforms already shipping.
> >
> > A _DSM has the advantage that once it is defined and supported, OEMs
> > can ship new platforms without requiring a new quirk or a new _HID to
> > be added to a driver.
> >
> > There would still be the problem of config access before the namespace
> > is available, i.e., the MCFG use case. I don't know how important
> > that is. Defining an MCFG extension seems like the most obvious
> > solution.
>
> Your summary above is a perfect representation of the situation.
>
> We had an opportunity to sync-up on the current status of ACPI PCI
> for ARM64 (and talked about a way forward for this series, which
> includes quirks handling), let me summarize it here for everyone
> involved so that we can agree on a way forward.
>
> 1) ACPI PCI support for PNP0A03/PNP0A08 host bridges on top of MCFG
> ECAM for config space is basically ready (Tomasz and JC addressed
> Rafael's concerns in relation to ARM64 specific code, and managed
> to find a way to allocate domain numbers in preparation for Arnd
> pci_create_root_bus() clean-up, v8 to be posted shortly and should
> be final). This provides support for de-facto ACPI/PCI ECAM base
> standard for ARM64 (with a clean-split between generic code and ARM64
> bits, where ARM64, like X86 and IA64, manages in arch code IO space and
> PCI resources, to be further consolidated in the near future).
> I do not think anyone can complain about the generality of what we
> achieved, for systems that are PCI standard (yes, PCI STANDARD) this
> would just be sufficient.
Sounds good to me.
> 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
Sounds reasonable to me.
> 3) (2) does not just work on some platforms (and we can't predict the
> future either - actually I can, it is three letters, ECAM), simply
> because MCFG OEMID matching does not provide a way to attach further
> data to the MCFG (eg if config space for, say, bus 0 domain 0, is not
> ECAM compliant, the config region can't be handled and must not be
> handled through a corresponding MCFG region.
Couldn't this be handled by custom pci_ops that do something special
for bus 0 domain 0, and default to some different pci_ops for the
rest?
> That's the problem Gabriele is facing and wants to solve through
> something like:
>
> https://lkml.org/lkml/2016/3/9/91
>
> in the respective ACPI tables-bindings. It may be an idea worth
> pursuing, it does not solve (2) simply because that FW has shipped,
> we can't patch it any longer.
(2) is for quirks to deal with MCFG. Gabriele's post is a proposal
for ACPI namespace. We can't use anything in the namespace to
implement MCFG quirks because MCFG is needed before the namespace is
available.
I think Gabriele's post is a good proposal for the namespace, but I
would propose the following modifications:
- Add PNP0A08 to the PCI1 _CID since this is a PCIe host bridge
- Add a PCI1 _DSM describing the ECAM space
- Remove the HISI0081 _HID
The result would be:
Device (PCI1) {
Name(_HID, "HISI0080")
Name(_CID, "PNP0A03,PNP0A08")
Method(_CRS) { ... }
Method(_DSM) { <describe ECAM base and mapping function> }
}
Device (RES0) {
Name(_HID, "PNP0C02")
Name(_CRS) { <describe ECAM base and size> }
}
RES0 could also be contained within PCI1, as Gabriele suggested. I
don't really care whether it's contained or not, and making it
contained might make it easier for firmware, because addition/removal
of PCI1 and RES0 should always happen together.
I think the _DSM is important because it is really ugly if the
HISI0080 driver has to look for a separate HISI0081 device to learn
about the ECAM space. There are several PCI drivers that do something
similar, using for_each_pci_dev(), and I cringe every time I see them,
because this totally screws up the driver model. A driver should
claim a device via a .probe() method called by the core, and it
shouldn't look at devices it hasn't claimed. This is required to make
hotplug work correctly.
> Hence to finally support ACPI PCI on ARM64 I suggest we carry out the
> following steps, in order:
>
> - Let's complete/merge (1), that's fundamental to this whole thread
> - On top of (1) we apply a quirking mechanism based on (2) that allows
> us to boot mainline with boxes shipping today with no FW update required.
> - We devise a way to handle quirks that is more generic than (2) so that
> can we can accomodate further platforms that can't rely on (2) but
> have more leeway in terms of FW updates.
>
> I hope that's a reasonable plan, Tomasz's v8 series coming to kick it off.
Sounds very good to me; I'm looking forward to v8.
Bjorn
[toc] | [prev] | [next] | [standalone]
| From | Gabriele Paoloni <gabriele.paoloni@huawei.com> |
|---|---|
| Date | 2016-05-26 12:00 +0200 |
| Subject | RE: [PATCH V7 00/11] Support for generic ACPI based PCI host controller |
| Message-ID | <rD0f7-4Ml-5@gated-at.bofh.it> |
| In reply to | #1406397 |
Hi Bjorn many thanks for your suggestions
> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas@kernel.org]
> Sent: 24 May 2016 20:01
> To: Lorenzo Pieralisi
> Cc: Gabriele Paoloni; Ard Biesheuvel; Jon Masters; Tomasz Nowicki;
> arnd@arndb.de; will.deacon@arm.com; catalin.marinas@arm.com;
> rafael@kernel.org; hanjun.guo@linaro.org; okaya@codeaurora.org;
> jchandra@broadcom.com; linaro-acpi@lists.linaro.org; linux-
> pci@vger.kernel.org; dhdang@apm.com; Liviu.Dudau@arm.com;
> ddaney@caviumnetworks.com; jeremy.linton@arm.com; linux-
> kernel@vger.kernel.org; linux-acpi@vger.kernel.org;
> robert.richter@caviumnetworks.com; Suravee.Suthikulpanit@amd.com;
> msalter@redhat.com; Wangyijing; mw@semihalf.com;
> andrea.gallo@linaro.org; linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH V7 00/11] Support for generic ACPI based PCI host
> controller
>
> On Tue, May 24, 2016 at 06:24:23PM +0100, Lorenzo Pieralisi wrote:
> > Hi Bjorn,
> >
> > On Mon, May 23, 2016 at 06:39:18PM -0500, Bjorn Helgaas wrote:
> >
> > [...]
> >
> > > On Mon, May 23, 2016 at 03:16:01PM +0000, Gabriele Paoloni wrote:
> > > I don't think of ECAM support itself as a "driver". It's just a
> > > service available to drivers, similar to OF resource parsing.
> > >
> > > Per PCI Firmware r3.2, sec 4.1.5, "PNP0A03" means a PCI/PCI-X/PCIe
> > > host bridge. "PNP0A08" means a PCI-X Mode 2 or PCIe bridge that
> > > supports extended config space. It doesn't specify how we access
> that
> > > config space, so I think hardware with non-standard ECAM should
> still
> > > have PNP0A03 and PNP0A08 in _CID or _HID.
> > >
> > > "ECAM" as used in the specs (PCIe r3.0, sec 7.2.2, and PCI Firmware
> > > r3.2, sec 4.1) means:
> > >
> > > (a) a memory-mapped model for config space access, and
> > > (b) a specific mapping of address bits to bus/device/function/
> > > register
> > >
> > > MCFG and _CBA assume both (a) and (b), so I think a device with
> > > non-standard ECAM mappings should not be described in MCFG or _CBA.
> > >
> > > If a bridge has ECAM with non-standard mappings, I think either a
> > > vendor-specific _HID or a device-specific method, e.g., _DSM, could
> > > communicate that.
> > >
> > > Jon, I agree that we should avoid describing non-standardized
> hardware
> > > in Linux-specific ways. Is there a mechanism in use already? How
> > > does Windows handle this? DMI is a poor long-term solution because
> it
> > > requires ongoing maintenance for new platforms, but I think it's OK
> > > for getting started with platforms already shipping.
> > >
> > > A _DSM has the advantage that once it is defined and supported,
> OEMs
> > > can ship new platforms without requiring a new quirk or a new _HID
> to
> > > be added to a driver.
> > >
> > > There would still be the problem of config access before the
> namespace
> > > is available, i.e., the MCFG use case. I don't know how important
> > > that is. Defining an MCFG extension seems like the most obvious
> > > solution.
> >
> > Your summary above is a perfect representation of the situation.
> >
> > We had an opportunity to sync-up on the current status of ACPI PCI
> > for ARM64 (and talked about a way forward for this series, which
> > includes quirks handling), let me summarize it here for everyone
> > involved so that we can agree on a way forward.
> >
> > 1) ACPI PCI support for PNP0A03/PNP0A08 host bridges on top of MCFG
> > ECAM for config space is basically ready (Tomasz and JC addressed
> > Rafael's concerns in relation to ARM64 specific code, and managed
> > to find a way to allocate domain numbers in preparation for Arnd
> > pci_create_root_bus() clean-up, v8 to be posted shortly and should
> > be final). This provides support for de-facto ACPI/PCI ECAM base
> > standard for ARM64 (with a clean-split between generic code and
> ARM64
> > bits, where ARM64, like X86 and IA64, manages in arch code IO
> space and
> > PCI resources, to be further consolidated in the near future).
> > I do not think anyone can complain about the generality of what we
> > achieved, for systems that are PCI standard (yes, PCI STANDARD)
> this
> > would just be sufficient.
>
> Sounds good to me.
>
> > 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
>
> Sounds reasonable to me.
>
> > 3) (2) does not just work on some platforms (and we can't predict the
> > future either - actually I can, it is three letters, ECAM), simply
> > because MCFG OEMID matching does not provide a way to attach
> further
> > data to the MCFG (eg if config space for, say, bus 0 domain 0, is
> not
> > ECAM compliant, the config region can't be handled and must not be
> > handled through a corresponding MCFG region.
>
> Couldn't this be handled by custom pci_ops that do something special
> for bus 0 domain 0, and default to some different pci_ops for the
> rest?
My idea was to remove bus 0 from domain 0 MCFG (and also the other
buses corresponding to the root complexes ports)
So the driver would use the ECAM access with addresses retrieved from
MCFG for any devices except the RCs.
For the RC we could retrieve special addresses from the "PNP0C02"
reserved resource...
>
> > That's the problem Gabriele is facing and wants to solve through
> > something like:
> >
> > https://lkml.org/lkml/2016/3/9/91
> >
> > in the respective ACPI tables-bindings. It may be an idea worth
> > pursuing, it does not solve (2) simply because that FW has
> shipped,
> > we can't patch it any longer.
>
> (2) is for quirks to deal with MCFG. Gabriele's post is a proposal
> for ACPI namespace. We can't use anything in the namespace to
> implement MCFG quirks because MCFG is needed before the namespace is
> available.
Honestly I have to dig better into this (and I will once V8 is out),
However from my current understanding so far we have look-up where
MCFG OEMID is going to tell which specific pci-ops are going to be used.
Now from my quirk idea I need to retrieve the "special address" from the
ACPI namespace before cfg rd/wr take place...if this is not doable then
I need to find a different solution...than can be the one you proposed
below (many thanks for this).
I will look into details later on once v8 is out.
Thanks
Gab
>
> I think Gabriele's post is a good proposal for the namespace, but I
> would propose the following modifications:
>
> - Add PNP0A08 to the PCI1 _CID since this is a PCIe host bridge
> - Add a PCI1 _DSM describing the ECAM space
> - Remove the HISI0081 _HID
>
> The result would be:
>
> Device (PCI1) {
> Name(_HID, "HISI0080")
> Name(_CID, "PNP0A03,PNP0A08")
> Method(_CRS) { ... }
> Method(_DSM) { <describe ECAM base and mapping function> }
> }
> Device (RES0) {
> Name(_HID, "PNP0C02")
> Name(_CRS) { <describe ECAM base and size> }
> }
>
> RES0 could also be contained within PCI1, as Gabriele suggested. I
> don't really care whether it's contained or not, and making it
> contained might make it easier for firmware, because addition/removal
> of PCI1 and RES0 should always happen together.
>
> I think the _DSM is important because it is really ugly if the
> HISI0080 driver has to look for a separate HISI0081 device to learn
> about the ECAM space. There are several PCI drivers that do something
> similar, using for_each_pci_dev(), and I cringe every time I see them,
> because this totally screws up the driver model. A driver should
> claim a device via a .probe() method called by the core, and it
> shouldn't look at devices it hasn't claimed. This is required to make
> hotplug work correctly.
>
> > Hence to finally support ACPI PCI on ARM64 I suggest we carry out the
> > following steps, in order:
> >
> > - Let's complete/merge (1), that's fundamental to this whole thread
> > - On top of (1) we apply a quirking mechanism based on (2) that
> allows
> > us to boot mainline with boxes shipping today with no FW update
> required.
> > - We devise a way to handle quirks that is more generic than (2) so
> that
> > can we can accomodate further platforms that can't rely on (2) but
> > have more leeway in terms of FW updates.
> >
> > I hope that's a reasonable plan, Tomasz's v8 series coming to kick it
> off.
>
> Sounds very good to me; I'm looking forward to v8.
>
> Bjorn
[toc] | [prev] | [next] | [standalone]
| From | Gabriele Paoloni <gabriele.paoloni@huawei.com> |
|---|---|
| Date | 2016-05-25 08:40 +0200 |
| Subject | RE: [PATCH V7 00/11] Support for generic ACPI based PCI host controller |
| Message-ID | <rCAE1-646-5@gated-at.bofh.it> |
| In reply to | #1406300 |
Hi Lorenzo > -----Original Message----- > From: Lorenzo Pieralisi [mailto:lorenzo.pieralisi@arm.com] > Sent: 24 May 2016 18:24 > To: Bjorn Helgaas > Cc: Gabriele Paoloni; Ard Biesheuvel; Jon Masters; Tomasz Nowicki; > arnd@arndb.de; will.deacon@arm.com; catalin.marinas@arm.com; > rafael@kernel.org; hanjun.guo@linaro.org; okaya@codeaurora.org; > jchandra@broadcom.com; linaro-acpi@lists.linaro.org; linux- > pci@vger.kernel.org; dhdang@apm.com; Liviu.Dudau@arm.com; > ddaney@caviumnetworks.com; jeremy.linton@arm.com; linux- > kernel@vger.kernel.org; linux-acpi@vger.kernel.org; > robert.richter@caviumnetworks.com; Suravee.Suthikulpanit@amd.com; > msalter@redhat.com; Wangyijing; mw@semihalf.com; > andrea.gallo@linaro.org; linux-arm-kernel@lists.infradead.org > Subject: Re: [PATCH V7 00/11] Support for generic ACPI based PCI host > controller > > Hi Bjorn, > > On Mon, May 23, 2016 at 06:39:18PM -0500, Bjorn Helgaas wrote: > > [...] > > > On Mon, May 23, 2016 at 03:16:01PM +0000, Gabriele Paoloni wrote: > > I don't think of ECAM support itself as a "driver". It's just a > > service available to drivers, similar to OF resource parsing. > > > > Per PCI Firmware r3.2, sec 4.1.5, "PNP0A03" means a PCI/PCI-X/PCIe > > host bridge. "PNP0A08" means a PCI-X Mode 2 or PCIe bridge that > > supports extended config space. It doesn't specify how we access > that > > config space, so I think hardware with non-standard ECAM should still > > have PNP0A03 and PNP0A08 in _CID or _HID. > > > > "ECAM" as used in the specs (PCIe r3.0, sec 7.2.2, and PCI Firmware > > r3.2, sec 4.1) means: > > > > (a) a memory-mapped model for config space access, and > > (b) a specific mapping of address bits to bus/device/function/ > > register > > > > MCFG and _CBA assume both (a) and (b), so I think a device with > > non-standard ECAM mappings should not be described in MCFG or _CBA. > > > > If a bridge has ECAM with non-standard mappings, I think either a > > vendor-specific _HID or a device-specific method, e.g., _DSM, could > > communicate that. > > > > Jon, I agree that we should avoid describing non-standardized > hardware > > in Linux-specific ways. Is there a mechanism in use already? How > > does Windows handle this? DMI is a poor long-term solution because > it > > requires ongoing maintenance for new platforms, but I think it's OK > > for getting started with platforms already shipping. > > > > A _DSM has the advantage that once it is defined and supported, OEMs > > can ship new platforms without requiring a new quirk or a new _HID to > > be added to a driver. > > > > There would still be the problem of config access before the > namespace > > is available, i.e., the MCFG use case. I don't know how important > > that is. Defining an MCFG extension seems like the most obvious > > solution. > > Your summary above is a perfect representation of the situation. > > We had an opportunity to sync-up on the current status of ACPI PCI > for ARM64 (and talked about a way forward for this series, which > includes quirks handling), let me summarize it here for everyone > involved so that we can agree on a way forward. > > 1) ACPI PCI support for PNP0A03/PNP0A08 host bridges on top of MCFG > ECAM for config space is basically ready (Tomasz and JC addressed > Rafael's concerns in relation to ARM64 specific code, and managed > to find a way to allocate domain numbers in preparation for Arnd > pci_create_root_bus() clean-up, v8 to be posted shortly and should > be final). This provides support for de-facto ACPI/PCI ECAM base > standard for ARM64 (with a clean-split between generic code and > ARM64 > bits, where ARM64, like X86 and IA64, manages in arch code IO space > and > PCI resources, to be further consolidated in the near future). > I do not think anyone can complain about the generality of what we > achieved, for systems that are PCI standard (yes, PCI STANDARD) this > would just be sufficient. > 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 > > 3) (2) does not just work on some platforms (and we can't predict the > future either - actually I can, it is three letters, ECAM), simply > because MCFG OEMID matching does not provide a way to attach further > data to the MCFG (eg if config space for, say, bus 0 domain 0, is > not > ECAM compliant, the config region can't be handled and must not be > handled through a corresponding MCFG region. > That's the problem Gabriele is facing and wants to solve through > something like: > > https://lkml.org/lkml/2016/3/9/91 > > in the respective ACPI tables-bindings. It may be an idea worth > pursuing, it does not solve (2) simply because that FW has shipped, > we can't patch it any longer. > > Hence to finally support ACPI PCI on ARM64 I suggest we carry out the > following steps, in order: > > - Let's complete/merge (1), that's fundamental to this whole thread > - On top of (1) we apply a quirking mechanism based on (2) that allows > us to boot mainline with boxes shipping today with no FW update > required. > - We devise a way to handle quirks that is more generic than (2) so > that > can we can accomodate further platforms that can't rely on (2) but > have more leeway in terms of FW updates. > > I hope that's a reasonable plan, Tomasz's v8 series coming to kick it > off. Thanks for summarizing. 100% agree on the summary and next steps. Cheers Gab > > Thank you, > Lorenzo
[toc] | [prev] | [next] | [standalone]
| From | Jon Masters <jcm@redhat.com> |
|---|---|
| Date | 2016-05-24 06:30 +0200 |
| Subject | Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller |
| Message-ID | <rCc8F-6N7-1@gated-at.bofh.it> |
| In reply to | #1405241 |
On 05/23/2016 06:56 AM, Lorenzo Pieralisi wrote: > The only way this can be implemented is by pretending that the > ACPI/PCI arch/arm64 implementation is generic code (that's what this > series does), move it to /drivers (where it is in this series), and > implement _DSD vendor specific bindings (per HID) to set-up the pci > operations; whether this solution should go upstream, given that it > is just a short-term solution for early platforms bugs, it is another > story and my personal answer is no. Just for completeness, let me also followup to this one. We have real, shipping, systems in the field based on ARMv8. For example, HPE Moonshot ProLiant m400. Not everyone loves the first generation of anything (Applied get a lot of stick, but the reality is that someone had to go first, and whoever that was was going to learn all of the lessons that others don't need to) but it is out there and we need an upstream kernel solution that includes support for that. In the server world, we (speaking as a major distro vendor here) are not going to entertain a situation in which non-upstream patches are needed to even boot a platform. That simply won't do. We need to separate out the issue of getting the core in place from the quirks, but then we need quirks that include support for all early ARMv8 platforms that are out there today. If we can't get to a point where a Moonshot[0] cartridge boots out of the box with an upstream kernel, let's just give up and do something else instead :) (joke) Jon. [0] HPE have been *amazingly* patient with this stuff. They've reworked the firmware when someone (cough) pointed out that the early stuff they'd been fed was not built according to the standards (U-Boot). They have *really good* UEFI and ACPI enabled firmware that is running RHEL(SA) great. But that's not good enough. We don't ship a distro with hacks. We ship a distro derived from upstream code (although we might have to backport a lot of stuff later). There's wiggle room, but there is not wiggle room for core platforms. On ARM, users and developers *will* be able to take an upstream kernel and boot it on their RHEL install. And they *will* be able to reproduce problems against upstream, and help develop against upstream, and further the upstream first mentality in the ARM ecosystem. There will not be "oh well, it runs RHEL so that's good enough for the early generation...". -- Computer Architect | Sent from my Fedora powered laptop
[toc] | [prev] | [next] | [standalone]
| From | Gabriele Paoloni <gabriele.paoloni@huawei.com> |
|---|---|
| Date | 2016-05-20 10:20 +0200 |
| Subject | RE: [PATCH V7 00/11] Support for generic ACPI based PCI host controller |
| Message-ID | <rANP3-35u-7@gated-at.bofh.it> |
| In reply to | #1404198 |
Hi Ard, Jon > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > Sent: 20 May 2016 08:38 > To: Jon Masters > Cc: Tomasz Nowicki; 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; linaro-acpi@lists.linaro.org; linux- > pci@vger.kernel.org; dhdang@apm.com; Liviu.Dudau@arm.com; > ddaney@caviumnetworks.com; jeremy.linton@arm.com; linux- > kernel@vger.kernel.org; linux-acpi@vger.kernel.org; > robert.richter@caviumnetworks.com; Suravee.Suthikulpanit@amd.com; > msalter@redhat.com; Wangyijing; mw@semihalf.com; > andrea.gallo@linaro.org; linux-arm-kernel@lists.infradead.org > Subject: Re: [PATCH V7 00/11] Support for generic ACPI based PCI host > controller > > On 20 May 2016 at 06:41, Jon Masters <jcm@redhat.com> wrote: > > Hi Tomasz, all, > > > > On 05/11/2016 07:08 AM, Tomasz Nowicki wrote: > > > >> On 11.05.2016 12:41, Gabriele Paoloni wrote: > > > >>>> v6 -> v7 > >>>> - drop quirks handling > >>> > >>> Maybe I missed something in the v6 discussion thread; when was it > >>> decided to drop quirk handling? > >> > >> I had such requests in previous series. > > > > A quick note on quirk handling. This, I believe, applies post-merge > of > > the base infrastructure, which I realize will likely not have quirks. > > > > We've some "gen1" ARMv8 server platforms where we end up doing quirks > > (for things like forcing 32-bit config space accessors and the like) > due > > to people repurposing existing embedded PCIe IP blocks or using them > for > > the first time (especially in servers), and those being involved in > the > > design not necessarily seeing this problem ahead of time, or not > > realizing that it would be an issue for servers. In the early days of > > ARM server designs 3-4 years ago, many of us had never really played > > with ECAM or realized how modern topologies are built. > > > > Anyway. We missed this one in our SBSA requirements. They say (words > to > > the effect of) "thou shalt do PCIe the way it is done on servers" but > > they aren't prescriptive, and they don't tell people how that > actually > > is in reality. That is being fixed. A lot of things are happening > behind > > the scenes - especially with third party IP block providers (all of > whom > > myself and others are speaking with directly about this) - to ensure > > that the next wave of designs won't repeat these mistakes. We don't > have > > a time machine, but we can contain this from becoming an ongoing mess > > for upstream, and we will do so. It won't be a zoo. > > > > Various proposals have arisen for how to handle quirks in the longer > > term, including elaborate frameworks and tables to describe them > > generically. I would like to caution against such approaches, > especially > > in the case that they deviate from practice on x86, or prior to being > > standardized fully with other Operating System vendors. I don't > expect > > there to be too many more than the existing initial set of quirks we > > have seen posted. A number of "future" server SoCs have already been > > fixed prior to silicon, and new design starts are being warned not to > > make this a problem for us to have to clean up later. > > > > So, I would like to suggest that the eventual framework mirror the > > existing approach on x86 systems (matching DMI, etc.) and not be made > > into some kind of generic, utopia. This is a case where we want there > to > > be pain involved (and upstream patches required) when people screw up, > > so that they have a level of pain in response to ever making this > > mistake in the future. If we try to create too grand a generic scheme > > and make it too easy to handle this kind of situation beyond the > small > > number of existing offenders, we undermine efforts to force vendors > to > > ensure that their IP blocks are compliant going forward. > > > > I understand that there is a desire from the RedHat side to mimic x86 > as closely as possible, but I never saw any technical justification > for that. DMI contains strings that are visible to userland, and you > effectively lock those down to certain values just so that the kernel > can distinguish a broken PCIe root complex from a working one. Linux > on x86 had no choice, since the overwhelming majority of existing > hardware misrepresented itself as generic, and DMI was the only thing > available to actually distinguish these broken implementations from > one another. This does not mean we should allow and/or encourage this > first gen hardware to misrepresent non-compliant hardware as compliant > as well. > > Since you are talking to all the people involved, how about you > convince them to put something in the ACPI tables that allows the > kernel to distinguish those non-standard PCIe implementations from > hardware that is really generic? This way, we can sidestep the quirks > debate entirely, since it will simply be a different device as far as > the kernel is concerned. This is no worse than a quirk from a > practical point of view, since an older OS will be equally unable to > run on newer hardware, but it is arguably more true to the standards > compliance you tend to preach about, especially since this small pool > of third party IP could potentially be identified directly rather than > based on some divination of the SoC we may or may not be running on. I > am also convinced that adding support for an additional HID() to the > ACPI ECAM driver with some special config space handling wired in is > an easier sell upstream than making the same ugly mess x86 has had to > make because they did not have any choice to begin with. In our case (HiSilicon Hip05/Hip06) we are using the Designware IP that unfortunately is non-ECAM for the RC config space. A possible ACPI table solution was discussed already in this thread https://lkml.org/lkml/2016/3/14/722 where <<Name (_CID, "PNP0C02") // Motherboard reserved resource>> is used to specify an Host Controller specific resource. It looks to me that this can be an approach that can accommodate different vendors/scenarios and Bjorn seemed to be quite ok with it. It comes without saying that for future HW releases we all should make an effort to deliver fully ECAM compliant controllers. What's your view about this approach? Thanks Gab > > If we do need a quirks handling mechanism, I still don't see how the > x86 situation extrapolates to ARM. ACPI offers plenty of ways for a > SoC vendor to identify the make and particular revision, and quirks > could be keyed off of that. > > -- > Ard.
[toc] | [prev] | [next] | [standalone]
| From | Jon Masters <jcm@redhat.com> |
|---|---|
| Date | 2016-05-20 10:30 +0200 |
| Subject | Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller |
| Message-ID | <rANYK-38Z-21@gated-at.bofh.it> |
| In reply to | #1404225 |
On 05/20/2016 04:11 AM, Gabriele Paoloni wrote: > Hi Ard, Jon Hi Gabriele :) > In our case (HiSilicon Hip05/Hip06) we are using the Designware IP > that unfortunately is non-ECAM for the RC config space. Yea, I know, and I've pinged them already. > A possible ACPI table solution was discussed already in this thread > > https://lkml.org/lkml/2016/3/14/722 > > where <<Name (_CID, "PNP0C02") // Motherboard reserved resource>> > is used to specify an Host Controller specific resource. > It looks to me that this can be an approach that can accommodate > different vendors/scenarios and Bjorn seemed to be quite ok with > it. Yeah, pondering that. We'll chat with a few others about it. > It comes without saying that for future HW releases we all should > make an effort to deliver fully ECAM compliant controllers. Right. Like I said, a number of designs have been fixed already. > What's your view about this approach? Will followup over the weekend. Jon. -- Computer Architect | Sent from my Fedora powered laptop
[toc] | [prev] | [next] | [standalone]
| From | Duc Dang <dhdang@apm.com> |
|---|---|
| Date | 2016-05-13 05:00 +0200 |
| Message-ID | <rybuy-2om-9@gated-at.bofh.it> |
| In reply to | #1398230 |
On Tue, May 10, 2016 at 8:19 AM, Tomasz Nowicki <tn@semihalf.com> wrote:
> From the functionality point of view this series may be split into the
> following logic parts:
> 1. New ECAM API and update for users of the pci-host-common API
> 2. Necessary fixes as the preparation for using driver on ARM64.
> 3. Use new MCFG interface and implement generic ACPI based PCI host controller driver.
> 4. Enable above driver on ARM64
>
> Patches has been built on top of 4.6-rc7 and can be found here:
> git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v7)
>
> This has been tested on Cavium ThunderX server. Any help in reviewing and
> testing is very appreciated.
I tried this series on APM X-Gene platforms (with ECAM fix-up quirk
added) and PCIe works fine.
Regards,
Duc Dang.
>
> 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: Provide common functions for ECAM mapping
> PCI: generic, thunder: update to use generic ECAM API
>
> Tomasz Nowicki (9):
> pci, of: Move the PCI I/O space management to PCI core code.
> pci: Add new function to unmap IO resources.
> acpi, pci: Support IO resources when parsing PCI host bridge
> resources.
> pci, acpi: Provide a way to assign bus domain number.
> pci, acpi: Handle ACPI companion assignment.
> pci, acpi: Support for ACPI based generic PCI host controller
> arm64, pci, acpi: ACPI support for legacy IRQs parsing and
> consolidation with DT code.
> arm64, pci, acpi: Provide ACPI-specific prerequisites for PCI bus
> enumeration.
> arm64, pci, acpi: Start using ACPI based PCI host controller driver
> for ARM64.
>
> arch/arm64/Kconfig | 1 +
> arch/arm64/kernel/pci.c | 34 +++-----
> drivers/acpi/Kconfig | 8 ++
> drivers/acpi/Makefile | 1 +
> drivers/acpi/pci_mcfg.c | 97 ++++++++++++++++++++++
> drivers/acpi/pci_root.c | 33 ++++++++
> drivers/acpi/pci_root_generic.c | 149 +++++++++++++++++++++++++++++++++
> drivers/of/address.c | 116 +-------------------------
> drivers/pci/Kconfig | 3 +
> drivers/pci/Makefile | 2 +
> drivers/pci/ecam.c | 161 ++++++++++++++++++++++++++++++++++++
> drivers/pci/ecam.h | 72 ++++++++++++++++
> drivers/pci/host/Kconfig | 1 +
> drivers/pci/host/pci-host-common.c | 114 +++++++++++--------------
> drivers/pci/host/pci-host-common.h | 47 -----------
> drivers/pci/host/pci-host-generic.c | 52 +++---------
> drivers/pci/host/pci-thunder-ecam.c | 39 ++-------
> drivers/pci/host/pci-thunder-pem.c | 92 ++++++++++-----------
> drivers/pci/pci.c | 150 ++++++++++++++++++++++++++++++++-
> drivers/pci/probe.c | 2 +
> include/linux/of_address.h | 9 --
> include/linux/pci-acpi.h | 14 ++++
> include/linux/pci.h | 11 ++-
> 23 files changed, 823 insertions(+), 385 deletions(-)
> create mode 100644 drivers/acpi/pci_mcfg.c
> create mode 100644 drivers/acpi/pci_root_generic.c
> create mode 100644 drivers/pci/ecam.c
> create mode 100644 drivers/pci/ecam.h
> delete mode 100644 drivers/pci/host/pci-host-common.h
>
> --
> 1.9.1
>
[toc] | [prev] | [next] | [standalone]
| From | Jeremy Linton <jeremy.linton@arm.com> |
|---|---|
| Date | 2016-05-19 20:20 +0200 |
| Subject | Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller |
| Message-ID | <rAAI9-3fU-1@gated-at.bofh.it> |
| In reply to | #1398230 |
On 05/10/2016 10:19 AM, Tomasz Nowicki wrote: > From the functionality point of view this series may be split into the > following logic parts: > 1. New ECAM API and update for users of the pci-host-common API > 2. Necessary fixes as the preparation for using driver on ARM64. > 3. Use new MCFG interface and implement generic ACPI based PCI host controller driver. > 4. Enable above driver on ARM64 Thomasz, Unless i'm doing something wrong, this patch causes a build break if NUMA is enabled in a 4.6+ kernel. Thanks, drivers/built-in.o: In function `pci_device_add': /home/jlinton/linux-main/drivers/pci/probe.c:1744: undefined reference to `pcibus_to_node' drivers/built-in.o: In function `pci_create_root_bus': /home/jlinton/linux-main/drivers/pci/probe.c:2163: undefined reference to `pcibus_to_node' drivers/built-in.o: In function `cpulistaffinity_show': /home/jlinton/linux-main/drivers/pci/pci-sysfs.c:123: undefined reference to `pcibus_to_node' /home/jlinton/linux-main/drivers/pci/pci-sysfs.c:123: undefined reference to `pcibus_to_node' drivers/built-in.o: In function `cpuaffinity_show': /home/jlinton/linux-main/drivers/pci/pci-sysfs.c:114: undefined reference to `pcibus_to_node' drivers/built-in.o:/home/jlinton/linux-main/drivers/pci/pci-sysfs.c:114: more undefined references to `pcibus_to_node' follow Makefile:937: recipe for target 'vmlinux' failed
[toc] | [prev] | [next] | [standalone]
| From | Jon Masters <jcm@jonmasters.org> |
|---|---|
| Date | 2016-05-20 10:30 +0200 |
| Subject | Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller |
| Message-ID | <rANYK-38Z-23@gated-at.bofh.it> |
| In reply to | #1398230 |
[Multipart message — attachments visible in raw view] — view raw
On 05/10/2016 11:19 AM, Tomasz Nowicki wrote: > This has been tested on Cavium ThunderX server. Any help in reviewing and > testing is very appreciated. Boot log from Intel Itanium 2 system attached. Jon.
[toc] | [prev] | [next] | [standalone]
| From | Dongdong Liu <liudongdong3@huawei.com> |
|---|---|
| Date | 2016-05-23 13:40 +0200 |
| Subject | Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller |
| Message-ID | <rBWnf-5dm-9@gated-at.bofh.it> |
| In reply to | #1398230 |
在 2016/5/10 23:19, Tomasz Nowicki 写道: >>From the functionality point of view this series may be split into the > following logic parts: > 1. New ECAM API and update for users of the pci-host-common API > 2. Necessary fixes as the preparation for using driver on ARM64. > 3. Use new MCFG interface and implement generic ACPI based PCI host controller driver. > 4. Enable above driver on ARM64 > > Patches has been built on top of 4.6-rc7 and can be found here: > git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v7) > > This has been tested on Cavium ThunderX server. Any help in reviewing and > testing is very appreciated. > Based on the patchset (with ECAM fix-up quirk added) and added the patch(Add ACPI support for HiSilicon PCIe Host Controllers). Tested on the HiSilicon ARM64 D02 board. It can work ok with Intel 82599 networking card. This is the bootup log which contains PCIe host and Intel 82599 networking card part. Tested-by: Dongdong Liu <liudongdong3@huawei.com> EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... GMAC ExitBootServicesEvent SMMU ExitBootServicesEvent [ 0.000000] Booting Linux on physical CPU 0x20000 [ 0.000000] Linux version 4.6.0-rc1+ (l00290354@linux-ioko) (gcc version 4.9.3 20150211 (prerelease) (20150316) ) #43 SMP PREEMPT Thu May 19 17:15:30 CST 2016 [ 0.000000] Boot CPU: AArch64 Processor [411fd071] [ 0.000000] earlycon: uart8250 at MMIO32 0x0000000080300000 (options '') [ 0.000000] bootconsole [uart8250] enabled [ 0.000000] efi: Getting EFI parameters from FDT: [ 0.000000] EFI v2.50 by EDK II [ 0.000000] efi: SMBIOS=0x7a650000 SMBIOS 3.0=0x7a630000 ACPI=0x7aba0000 ACPI 2.0=0x7aba0014 [ 0.000000] cma: Reserved 16 MiB at 0x000000007e800000 [ 0.000000] ACPI: Early table checksum verification disabled [ 0.000000] ACPI: RSDP 0x000000007ABA0014 000024 (v02 HISI ) [ 0.000000] ACPI: XSDT 0x000000007A7000E8 000064 (v01 HISI HISI-D02 20140727 01000013) [ 0.000000] ACPI: FACP 0x000000007A5F0000 00010C (v05 HISI HISI-D02 20140727 HISI 00000099) [ 0.000000] ACPI: DSDT 0x000000007A5A0000 001656 (v01 HISI HISI-D02 20140727 INTL 20150619) [ 0.000000] ACPI: DBG2 0x000000007A610000 00005A (v00 HISI HISI-D02 20140727 HISI 00000099) [ 0.000000] ACPI: GTDT 0x000000007A5E0000 000060 (v02 HISI HISI-D02 20140727 HISI 00000099) [ 0.000000] ACPI: APIC 0x000000007A5D0000 000554 (v01 HISI HISI-D02 20140727 HISI 00000099) [ 0.000000] ACPI: MCFG 0x000000007A5C0000 00004C (v01 HISI HISI-D02 20140727 HISI 00000099) [ 0.000000] ACPI: SPCR 0x000000007A5B0000 000050 (v02 HISI HISI-D02 20140727 HISI 00000099) [ 0.000000] ACPI: IORT 0x000000007A590000 0001FC (v00 INTEL TEMPLATE 00000000 INTL 20150619) [ 0.000000] ACPI: SSDT 0x000000007A580000 00046E (v01 HISI SAS0 20140727 INTL 20150619) [ 0.000000] ACPI: SPCR: console: uart,mmio,0x80300000,115200 [ 0.000000] psci: probing for conduit method from ACPI. NOTICE: [psci_smc_handler]:[347L] PSCI_VERSION CALL NOTICE: [psci_version]:[99L] PSCI_MAJOR_VER: 10000: PSCI_MINOR_VER: 0 0808?844 [ 0.000000] psci: PSCIv1.0 detected in firmware. [ 0.000000] psci: Using standard PSCI v0.2 function IDs 0808?844 [ 0.000000] psci: MIGRATE_INFO_TYPE not supported. 0808?844 0808?844 [ 0.000000] percpu: Embedded 20 pages/cpu @ffffffd1ffe7e000 s43008 r8192 d30720 u81920 [ 0.000000] Detected PIPT I-cache on CPU0 [ 0.000000] CPU features: enabling workaround for ARM erratum 832075 [ 0.000000] CPU features: enabling workaround for ARM erratum 834220 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 2063376 [ 0.000000] Kernel command line: console=ttyS0,115200 earlycon=uart8250,mmio32,0x80300000 initrd=filesystem.cpio.gz acpi=force pcie_aspm=off [ 0.000000] PCIe ASPM is disabled [ 0.000000] log_buf_len individual max cpu contribution: 4096 bytes [ 0.000000] log_buf_len total cpu_extra contributions: 61440 bytes [ 0.000000] log_buf_len min size: 16384 bytes [ 0.000000] log_buf_len: 131072 bytes [ 0.000000] early log buf free: 12988(79%) [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes) [ 0.000000] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes) [ 0.000000] software IO TLB [mem 0x764e0000-0x7a4e0000] (64MB) mapped at [ffffffc0764e0000-ffffffc07a4dffff] [ 0.000000] Memory: 8110296K/8384512K available (7240K kernel code, 632K rwdata, 3028K rodata, 840K init, 247K bss, 257832K reserved, 16384K cma-reserved) [ 0.000000] Virtual kernel memory layout: [ 0.000000] modules : 0xffffff8000000000 - 0xffffff8008000000 ( 128 MB) [ 0.000000] vmalloc : 0xffffff8008000000 - 0xffffffbdbfff0000 ( 246 GB) [ 0.000000] .text : 0xffffff8008080000 - 0xffffff8008790000 ( 7232 KB) [ 0.000000] .rodata : 0xffffff8008790000 - 0xffffff8008a89000 ( 3044 KB) [ 0.000000] .init : 0xffffff8008a89000 - 0xffffff8008b5b000 ( 840 KB) [ 0.000000] .data : 0xffffff8008b5b000 - 0xffffff8008bf9200 ( 633 KB) [ 0.000000] vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000 ( 8 GB maximum) [ 0.000000] 0xffffffbdc0000000 - 0xffffffbe08000000 ( 1152 MB actual) [ 0.000000] fixed : 0xffffffbffe7fd000 - 0xffffffbffec00000 ( 4108 KB) [ 0.000000] PCI I/O : 0xffffffbffee00000 - 0xffffffbfffe00000 ( 16 MB) [ 0.000000] memory : 0xffffffc000000000 - 0xffffffd200000000 ( 73728 MB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=16, Nodes=1 [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] Build-time adjustment of leaf fanout to 64. [ 0.000000] RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=16. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=16 [ 0.000000] NR_IRQS:64 nr_irqs:64 0 [ 0.000000] GIC: Using split EOI/Deactivate mode [ 0.000000] ITS@0x8c000000 [ 0.000000] ITS: allocated 65536 Devices @11f6c80000 (psz 4K, shr 1) [ 0.000000] ITS: allocated 512 Virtual CPUs @11f6c0f000 (psz 4K, shr 1) [ 0.000000] ITS: allocated 512 Interrupt Collections @11f6c20000 (psz 4K, shr 1) [ 0.000000] ITS@0xc6000000 [ 0.000000] ITS: allocated 65536 Devices @11f6d00000 (psz 4K, shr 1) [ 0.000000] ITS: allocated 512 Virtual CPUs @11f6c21000 (psz 4K, shr 1) [ 0.000000] ITS: allocated 512 Interrupt Collections @11f6c22000 (psz 4K, shr 1) [ 0.000000] ITS@0xa3000000 [ 0.000000] ITS: allocated 65536 Devices @11f6d80000 (psz 4K, shr 1) [ 0.000000] ITS: allocated 512 Virtual CPUs @11f6c24000 (psz 4K, shr 1) [ 0.000000] ITS: allocated 512 Interrupt Collections @11f6c25000 (psz 4K, shr 1) [ 0.000000] ITS@0xb7000000 [ 0.000000] ITS: allocated 65536 Devices @11f6e00000 (psz 4K, shr 1) [ 0.000000] ITS: allocated 512 Virtual CPUs @11f6c26000 (psz 4K, shr 1) [ 0.000000] ITS: allocated 512 Interrupt Collections @11f6c27000 (psz 4K, shr 1) [ 0.000000] GIC: using LPI property table @0x00000011f6c60000 [ 0.000000] ITS: Allocated 1792 chunks for LPIs [ 0.000000] CPU0: found redistributor 20000 region 0:0x000000008d100000 [ 0.000000] CPU0: using LPI pending table @0x00000011f6c70000 [ 0.000000] Unable to get hardware information used for virtualization [ 0.000000] GTDT: No Platform Timer structures. [ 0.000000] arch_timer: Can't find GT Block. [ 0.000000] Architected cp15 and mmio timer(s) running at 50.00MHz (phys/phys). [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xb8812736b, max_idle_ns: 440795202655 ns [ 0.000001] sched_clock: 56 bits at 50MHz, resolution 20ns, wraps every 4398046511100ns [ 0.008025] Console: colour dummy device 80x25 [ 0.012459] Calibrating delay loop (skipped), value calculated using timer frequency.. 100.00 BogoMIPS (lpj=200000) [ 0.022850] pid_max: default: 32768 minimum: 301 [ 0.027450] ACPI: Core revision 20160108 [ 0.032284] ACPI: 2 ACPI AML tables successfully acquired and loaded [ 0.038617] [ 0.040126] Security Framework initialized [ 0.044213] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes) [ 0.051053] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes) [ 0.058747] ASID allocator initialised with 65536 entries [ 0.064393] PCI/MSI: ITS@0x8c000000 domain created [ 0.069162] PCI/MSI: ITS@0xc6000000 domain created [ 0.073927] PCI/MSI: ITS@0xa3000000 domain created [ 0.078693] PCI/MSI: ITS@0xb7000000 domain created [ 0.083463] Platform MSI: irqchip@000000008c000000 domain created [ 0.089525] Platform MSI: irqchip@00000000c6000000 domain created [ 0.095586] Platform MSI: irqchip@00000000a3000000 domain created [ 0.101648] Platform MSI: irqchip@00000000b7000000 domain created [ 0.107753] Remapping and enabling EFI services. [ 0.112370] EFI remap 0x000000007a4e0000 => 0000000020000000 [ 0.118185] EFI remap 0x000000007a530000 => 0000000020050000 [ 0.124008] EFI remap 0x000000007a620000 => 00000000200a0000 [ 0.129822] EFI remap 0x000000007a6b0000 => 0000000020130000 [ 0.135636] EFI remap 0x000000007a710000 => 0000000020180000 [ 0.141454] EFI remap 0x000000007a760000 => 00000000201d0000 [ 0.147269] EFI remap 0x000000007a7b0000 => 0000000020220000 [ 0.153083] EFI remap 0x000000007a800000 => 0000000020270000 [ 0.158897] EFI remap 0x000000007a850000 => 00000000202c0000 [ 0.164711] EFI remap 0x000000007a8a0000 => 0000000020310000 [ 0.170525] EFI remap 0x000000007a8f0000 => 0000000020360000 [ 0.176339] EFI remap 0x000000007a940000 => 00000000203b0000 [ 0.182160] EFI remap 0x000000007a990000 => 0000000020400000 [ 0.187974] EFI remap 0x000000007aa00000 => 0000000020470000 [ 0.193788] EFI remap 0x000000007aa50000 => 00000000204c0000 [ 0.199602] EFI remap 0x000000007aaa0000 => 0000000020510000 [ 0.205417] EFI remap 0x000000007aaf0000 => 0000000020560000 [ 0.211230] EFI remap 0x000000007ab40000 => 00000000205b0000 [ 0.217043] EFI remap 0x000000007fbb0000 => 0000000020600000 [ 0.222849] EFI remap 0x0000000080300000 => 0000000020630000 [ 0.228654] EFI remap 0x00000000a00f0000 => 0000000020640000 [ 0.234457] EFI remap 0x00000000a4000000 => 0000000020800000 [ 0.240266] EFI remap 0x00000000a6000000 => 0000000021800000 NOTICE: [psci_smc_handler]:[408L] PSCI_CPU_ON_AARCH64 CALL NOTICE: [psci_smc_handler]:[409L] x1=0x20001 x2=0x82870 x3=0x0 NOTICE: [scpi_set_css_power_state]:[85L] domain_cluster=0x1 NOTICE: [scpi_set_css_power_state]:[93L] domain_cluster=0x1 0808?8AB44 NOTICE: [psci_afflvl_power_on_finish]:[504L] NOTICE: [cm_prepare_el3_exit]:[262L] read_tpidr_el3 = 7fc3c080 NOTICE: [cm_prepare_el3_exit]:[319L] ctx add = 7fc3d190 NOTICE: [psci_afflvl_power_on_finish]:[562L] 00082870 NOTICE: [psci_smc_handler]:[408L] PSCI_CPU_ON_AARCH64 CALL NOTICE: [psci_smc_handler]:[409L] x1=0x20002 x2=0x82870 x3=0x0 NOTICE: [scpi_set_css_power_state]:[85L] domain_cluster=0x1 NOTICE: [scpi_set_css_power_state]:[93L] domain_cluster=0x1 0808?8AB44 NOTICE: [psci_afflvl_power_on_finish]:[504L] NOTICE: [cm_prepare_el3_exit]:[262L] read_tpidr_el3 = 7fc3c100 NOTICE: [cm_prepare_el3_exit]:[319L] ctx add = 7fc3d3a0 NOTICE: [psci_afflvl_power_on_finish]:[562L] 00082870 NOTICE: [psci_smc_handler]:[408L] PSCI_CPU_ON_AARCH64 CALL NOTICE: [psci_smc_handler]:[409L] x1=0x20003 x2=0x82870 x3=0x0 NOTICE: [scpi_set_css_power_state]:[85L] domain_cluster=0x1 NOTICE: [scpi_set_css_power_state]:[93L] domain_cluster=0x1 0808?8AB44 NOTICE: [psci_afflvl_power_on_finish]:[504L] NOTICE: [cm_prepare_el3_exit]:[262L] read_tpidr_el3 = 7fc3c180 NOTICE: [cm_prepare_el3_exit]:[319L] ctx add = 7fc3d5b0 NOTICE: [psci_afflvl_power_on_finish]:[562L] 00082870 NOTICE: [psci_smc_handler]:[408L] PSCI_CPU_ON_AARCH64 CALL NOTICE: [psci_smc_handler]:[409L] x1=0x20100 x2=0x82870 x3=0x0 NOTICE: [scpi_set_css_power_state]:[85L] domain_cluster=0x1 NOTICE: [scpi_set_css_power_state]:[93L] domain_cluster=0x3 0808?8AB44 NOTICE: [psci_afflvl_power_on_finish]:[504L] NOTICE: [cm_prepare_el3_exit]:[262L] read_tpidr_el3 = 7fc3c200 NOTICE: [cm_prepare_el3_exit]:[319L] ctx add = 7fc3d7c0 NOTICE: [psci_afflvl_power_on_finish]:[562L] 00082870 NOTICE: [psci_smc_handler]:[408L] PSCI_CPU_ON_AARCH64 CALL NOTICE: [psci_smc_handler]:[409L] x1=0x20101 x2=0x82870 x3=0x0 NOTICE: [scpi_set_css_power_state]:[85L] domain_cluster=0x3 NOTICE: [scpi_set_css_power_state]:[93L] domain_cluster=0x3 0808?8AB44 NOTICE: [psci_afflvl_power_on_finish]:[504L] NOTICE: [cm_prepare_el3_exit]:[262L] read_tpidr_el3 = 7fc3c280 NOTICE: [cm_prepare_el3_exit]:[319L] ctx add = 7fc3d9d0 NOTICE: [psci_afflvl_power_on_finish]:[562L] 00082870 NOTICE: [psci_smc_handler]:[408L] PSCI_CPU_ON_AARCH64 CALL NOTICE: [psci_smc_handler]:[409L] x1=0x20102 x2=0x82870 x3=0x0 NOTICE: [scpi_set_css_power_state]:[85L] domain_cluster=0x3 NOTICE: [scpi_set_css_power_state]:[93L] domain_cluster=0x3 0808?8AB44 NOTICE: [psci_afflvl_power_on_finish]:[504L] NOTICE: [cm_prepare_el3_exit]:[262L] read_tpidr_el3 = 7fc3c300 NOTICE: [cm_prepare_el3_exit]:[319L] ctx add = 7fc3dbe0 NOTICE: [psci_afflvl_power_on_finish]:[562L] 00082870 NOTICE: [psci_smc_handler]:[408L] PSCI_CPU_ON_AARCH64 CALL NOTICE: [psci_smc_handler]:[409L] x1=0x20103 x2=0x82870 x3=0x0 NOTICE: [scpi_set_css_power_state]:[85L] domain_cluster=0x3 NOTICE: [scpi_set_css_power_state]:[93L] domain_cluster=0x3 0808?8AB44 NOTICE: [psci_afflvl_power_on_finish]:[504L] NOTICE: [cm_prepare_el3_exit]:[262L] read_tpidr_el3 = 7fc3c380 NOTICE: [cm_prepare_el3_exit]:[319L] ctx add = 7fc3ddf0 NOTICE: [psci_afflvl_power_on_finish]:[562L] 00082870 NOTICE: [psci_smc_handler]:[408L] PSCI_CPU_ON_AARCH64 CALL NOTICE: [psci_smc_handler]:[409L] x1=0x20200 x2=0x82870 x3=0x0 NOTICE: [scpi_set_css_power_state]:[85L] domain_cluster=0x3 NOTICE: [scpi_set_css_power_state]:[93L] domain_cluster=0x7 0808?8AB44 NOTICE: [psci_afflvl_power_on_finish]:[504L] NOTICE: [cm_prepare_el3_exit]:[262L] read_tpidr_el3 = 7fc3c400 NOTICE: [cm_prepare_el3_exit]:[319L] ctx add = 7fc3e000 NOTICE: [psci_afflvl_power_on_finish]:[562L] 00082870 NOTICE: [psci_smc_handler]:[408L] PSCI_CPU_ON_AARCH64 CALL NOTICE: [psci_smc_handler]:[409L] x1=0x20201 x2=0x82870 x3=0x0 NOTICE: [scpi_set_css_power_state]:[85L] domain_cluster=0x7 NOTICE: [scpi_set_css_power_state]:[93L] domain_cluster=0x7 0808?8AB44 NOTICE: [psci_afflvl_power_on_finish]:[504L] NOTICE: [cm_prepare_el3_exit]:[262L] read_tpidr_el3 = 7fc3c480 NOTICE: [cm_prepare_el3_exit]:[319L] ctx add = 7fc3e210 NOTICE: [psci_afflvl_power_on_finish]:[562L] 00082870 NOTICE: [psci_smc_handler]:[408L] PSCI_CPU_ON_AARCH64 CALL NOTICE: [psci_smc_handler]:[409L] x1=0x20202 x2=0x82870 x3=0x0 NOTICE: [scpi_set_css_power_state]:[85L] domain_cluster=0x7 NOTICE: [scpi_set_css_power_state]:[93L] domain_cluster=0x7 0808?8AB44 NOTICE: [psci_afflvl_power_on_finish]:[504L] NOTICE: [cm_prepare_el3_exit]:[262L] read_tpidr_el3 = 7fc3c500 NOTICE: [cm_prepare_el3_exit]:[319L] ctx add = 7fc3e420 NOTICE: [psci_afflvl_power_on_finish]:[562L] 00082870 NOTICE: [psci_smc_handler]:[408L] PSCI_CPU_ON_AARCH64 CALL NOTICE: [psci_smc_handler]:[409L] x1=0x20203 x2=0x82870 x3=0x0 NOTICE: [scpi_set_css_power_state]:[85L] domain_cluster=0x7 NOTICE: [scpi_set_css_power_state]:[93L] domain_cluster=0x7 0808?8AB44 NOTICE: [psci_afflvl_power_on_finish]:[504L] NOTICE: [cm_prepare_el3_exit]:[262L] read_tpidr_el3 = 7fc3c580 NOTICE: [cm_prepare_el3_exit]:[319L] ctx add = 7fc3e630 NOTICE: [psci_afflvl_power_on_finish]:[562L] 00082870 NOTICE: [psci_smc_handler]:[408L] PSCI_CPU_ON_AARCH64 CALL NOTICE: [psci_smc_handler]:[409L] x1=0x20300 x2=0x82870 x3=0x0 NOTICE: [scpi_set_css_power_state]:[85L] domain_cluster=0x7 NOTICE: [scpi_set_css_power_state]:[93L] domain_cluster=0xf 0808?8AB44 NOTICE: [psci_afflvl_power_on_finish]:[504L] NOTICE: [cm_prepare_el3_exit]:[262L] read_tpidr_el3 = 7fc3c600 NOTICE: [cm_prepare_el3_exit]:[319L] ctx add = 7fc3e840 NOTICE: [psci_afflvl_power_on_finish]:[562L] 00082870 NOTICE: [psci_smc_handler]:[408L] PSCI_CPU_ON_AARCH64 CALL NOTICE: [psci_smc_handler]:[409L] x1=0x20301 x2=0x82870 x3=0x0 NOTICE: [scpi_set_css_power_state]:[85L] domain_cluster=0xf NOTICE: [scpi_set_css_power_state]:[93L] domain_cluster=0xf 0808?8AB44 NOTICE: [psci_afflvl_power_on_finish]:[504L] NOTICE: [cm_prepare_el3_exit]:[262L] read_tpidr_el3 = 7fc3c680 NOTICE: [cm_prepare_el3_exit]:[319L] ctx add = 7fc3ea50 NOTICE: [psci_afflvl_power_on_finish]:[562L] 00082870 NOTICE: [psci_smc_handler]:[408L] PSCI_CPU_ON_AARCH64 CALL NOTICE: [psci_smc_handler]:[409L] x1=0x20302 x2=0x82870 x3=0x0 NOTICE: [scpi_set_css_power_state]:[85L] domain_cluster=0xf NOTICE: [scpi_set_css_power_state]:[93L] domain_cluster=0xf 0808?8AB44 NOTICE: [psci_afflvl_power_on_finish]:[504L] NOTICE: [cm_prepare_el3_exit]:[262L] read_tpidr_el3 = 7fc3c700 NOTICE: [cm_prepare_el3_exit]:[319L] ctx add = 7fc3ec60 NOTICE: [psci_afflvl_power_on_finish]:[562L] 00082870 NOTICE: [psci_smc_handler]:[408L] PSCI_CPU_ON_AARCH64 CALL NOTICE: [psci_smc_handler]:[409L] x1=0x20303 x2=0x82870 x3=0x0 NOTICE: [scpi_set_css_power_state]:[85L] domain_cluster=0xf NOTICE: [scpi_set_css_power_state]:[93L] domain_cluster=0xf 0808?8AB44 NOTICE: [psci_afflvl_power_on_finish]:[504L] NOTICE: [cm_prepare_el3_exit]:[262L] read_tpidr_el3 = 7fc3c780 NOTICE: [cm_prepare_el3_exit]:[319L] ctx add = 7fc3ee70 NOTICE: [psci_afflvl_power_on_finish]:[562L] 00082870 [ 0.288031] Detected PIPT I-cache on CPU1 [ 0.288043] CPU1: found redistributor 20001 region 1:0x000000008d130000 [ 0.288064] CPU1: using LPI pending table @0x00000011f6410000 [ 0.288122] CPU1: Booted secondary processor [411fd071] [ 0.331143] Detected PIPT I-cache on CPU2 [ 0.331150] CPU2: found redistributor 20002 region 2:0x000000008d160000 [ 0.331170] CPU2: using LPI pending table @0x00000011f6440000 [ 0.331218] CPU2: Booted secondary processor [411fd071] [ 0.374257] Detected PIPT I-cache on CPU3 [ 0.374263] CPU3: found redistributor 20003 region 3:0x000000008d190000 [ 0.374283] CPU3: using LPI pending table @0x00000011f6480000 [ 0.374328] CPU3: Booted secondary processor [411fd071] [ 0.417372] Detected PIPT I-cache on CPU4 [ 0.417380] CPU4: found redistributor 20100 region 4:0x000000008d1c0000 [ 0.417400] CPU4: using LPI pending table @0x00000011f64c0000 [ 0.417447] CPU4: Booted secondary processor [411fd071] [ 0.460484] Detected PIPT I-cache on CPU5 [ 0.460491] CPU5: found redistributor 20101 region 5:0x000000008d1f0000 [ 0.460511] CPU5: using LPI pending table @0x00000011f64f0000 [ 0.460558] CPU5: Booted secondary processor [411fd071] [ 0.503598] Detected PIPT I-cache on CPU6 [ 0.503605] CPU6: found redistributor 20102 region 6:0x000000008d220000 [ 0.503625] CPU6: using LPI pending table @0x00000011f6530000 [ 0.503669] CPU6: Booted secondary processor [411fd071] [ 0.546711] Detected PIPT I-cache on CPU7 [ 0.546718] CPU7: found redistributor 20103 region 7:0x000000008d250000 [ 0.546738] CPU7: using LPI pending table @0x00000011f6560000 [ 0.546783] CPU7: Booted secondary processor [411fd071] [ 0.589826] Detected PIPT I-cache on CPU8 [ 0.589835] CPU8: found redistributor 20200 region 8:0x000000008d280000 [ 0.589857] CPU8: using LPI pending table @0x00000011f65a0000 [ 0.589910] CPU8: Booted secondary processor [411fd071] [ 0.632939] Detected PIPT I-cache on CPU9 [ 0.632946] CPU9: found redistributor 20201 region 9:0x000000008d2b0000 [ 0.632967] CPU9: using LPI pending table @0x00000011f65e0000 [ 0.633014] CPU9: Booted secondary processor [411fd071] [ 0.676052] Detected PIPT I-cache on CPU10 [ 0.676060] CPU10: found redistributor 20202 region 10:0x000000008d2e0000 [ 0.676081] CPU10: using LPI pending table @0x00000011f6610000 [ 0.676126] CPU10: Booted secondary processor [411fd071] [ 0.719166] Detected PIPT I-cache on CPU11 [ 0.719173] CPU11: found redistributor 20203 region 11:0x000000008d310000 [ 0.719195] CPU11: using LPI pending table @0x00000011f6650000 [ 0.719240] CPU11: Booted secondary processor [411fd071] [ 0.762280] Detected PIPT I-cache on CPU12 [ 0.762289] CPU12: found redistributor 20300 region 12:0x000000008d340000 [ 0.762311] CPU12: using LPI pending table @0x00000011f6680000 [ 0.762360] CPU12: Booted secondary processor [411fd071] [ 0.805392] Detected PIPT I-cache on CPU13 [ 0.805400] CPU13: found redistributor 20301 region 13:0x000000008d370000 [ 0.805421] CPU13: using LPI pending table @0x00000011f66c0000 [ 0.805466] CPU13: Booted secondary processor [411fd071] [ 0.848506] Detected PIPT I-cache on CPU14 [ 0.848513] CPU14: found redistributor 20302 region 14:0x000000008d3a0000 [ 0.848534] CPU14: using LPI pending table @0x00000011f6700000 [ 0.848579] CPU14: Booted secondary processor [411fd071] [ 0.891620] Detected PIPT I-cache on CPU15 [ 0.891628] CPU15: found redistributor 20303 region 15:0x000000008d3d0000 [ 0.891648] CPU15: using LPI pending table @0x00000011f6750000 [ 0.891693] CPU15: Booted secondary processor [411fd071] [ 0.891723] Brought up 16 CPUs [ 1.220754] SMP: Total of 16 processors activated. [ 1.225520] CPU features: detected feature: GIC system register CPU interface [ 1.232620] CPU: All CPU(s) started at EL2 [ 1.236718] alternatives: patching kernel code [ 1.243905] devtmpfs: initialized [ 1.247446] SMBIOS 3.0.0 present. [ 1.250851] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns [ 1.260790] pinctrl core: initialized pinctrl subsystem [ 1.266365] NET: Registered protocol family 16 [ 1.282800] cpuidle: using governor menu [ 1.286747] vdso: 2 pages (1 code @ ffffff8008796000, 1 data @ ffffff8008b60000) [ 1.294122] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers. [ 1.301211] DMA: preallocated 256 KiB pool for atomic allocations [ 1.307340] ACPI: bus type PCI registered [ 1.311388] Serial: AMBA PL011 UART driver [ 1.331638] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.338373] ACPI: Added _OSI(Module Device) [ 1.342562] ACPI: Added _OSI(Processor Device) [ 1.346984] ACPI: Added _OSI(3.0 _SCP Extensions) [ 1.351664] ACPI: Added _OSI(Processor Aggregator Device) [ 1.358469] ACPI: Interpreter enabled [ 1.362116] ACPI: Using GIC for interrupt routing [ 1.366815] ACPI: MCFG table loaded, 2 entries detected [ 1.375180] Hisilicon MBIGEN-V1 HISI0151:00: Allocated 256 MSIs [ 1.381158] Hisilicon MBIGEN-V1 HISI0151:01: Allocated 640 MSIs [ 1.387123] Hisilicon MBIGEN-V1 HISI0151:02: Allocated 256 MSIs [ 1.393091] Hisilicon MBIGEN-V1 HISI0151:03: Allocated 640 MSIs [ 1.399213] ACPI: IORT: can't find node related to (null) device [ 1.405292] ACPI: IORT: can't find node related to (null) device [ 1.411324] ACPI: IORT: can't find node related to (null) device [ 1.417348] ACPI: IORT: can't find node related to (null) device [ 1.423370] ACPI: IORT: can't find node related to (null) device [ 1.429391] ACPI: IORT: can't find node related to (null) device [ 1.436634] ACPI: IORT: can't find node related to (null) device [ 1.442681] ACPI: IORT: can't find node related to (null) device [ 1.448698] ACPI: IORT: can't find node related to (null) device [ 1.454712] ACPI: IORT: can't find node related to (null) device [ 1.460724] ACPI: IORT: can't find node related to (null) device [ 1.466764] ACPI: PCI Root Bridge [PCI1] (domain 0001 [bus 40-7f]) [ 1.472918] acpi HISI0080:00: _OSC: OS supports [ExtendedConfig Segments MSI] [ 1.480025] acpi HISI0080:00: _OSC failed (AE_NOT_FOUND); disabling ASPM [ 1.486771] acpi HISI0080:00: ECAM at [mem 0x22004000000-0x22007ffffff] for [bus 40-7f] [ 1.494762] Remapped I/O 0x000002200fff0000 to [io 0x0000-0xffff window] [ 1.501592] PCI host bridge to bus 0001:40 [ 1.505671] pci_bus 0001:40: root bus resource [mem 0x22008000000-0x2200ffeffff window] (bus address [0xb0000000-0xb7feffff]) [ 1.516919] pci_bus 0001:40: root bus resource [io 0x0000-0xffff window] [ 1.523675] pci_bus 0001:40: root bus resource [bus 40-7f] [ 1.534090] pci 0001:41:00.0: VF(n) BAR0 space: [mem 0x22008e08000-0x22008f07fff 64bit pref] (contains BAR0 for 64 VFs) [ 1.545323] pci 0001:41:00.0: VF(n) BAR3 space: [mem 0x22008f08000-0x22009007fff 64bit pref] (contains BAR3 for 64 VFs) [ 1.568223] pci 0001:41:00.1: VF(n) BAR0 space: [mem 0x22008c04000-0x22008d03fff 64bit pref] (contains BAR0 for 64 VFs) [ 1.579460] pci 0001:41:00.1: VF(n) BAR3 space: [mem 0x22008d04000-0x22008e03fff 64bit pref] (contains BAR3 for 64 VFs) [ 1.597823] pci 0001:40:00.0: BAR 15: assigned [mem 0x22008000000-0x220095fffff pref] [ 1.605616] pci 0001:40:00.0: BAR 13: assigned [io 0x1000-0x1fff] [ 1.611771] pci 0001:41:00.0: BAR 0: assigned [mem 0x22008000000-0x220083fffff 64bit pref] [ 1.620245] pci 0001:41:00.0: BAR 6: assigned [mem 0x22008400000-0x220087fffff pref] [ 1.627952] pci 0001:41:00.1: BAR 0: assigned [mem 0x22008800000-0x22008bfffff 64bit pref] [ 1.636430] pci 0001:41:00.1: BAR 6: assigned [mem 0x22008c00000-0x22008ffffff pref] [ 1.644138] pci 0001:41:00.0: BAR 4: assigned [mem 0x22009000000-0x22009003fff 64bit pref] [ 1.652610] pci 0001:41:00.0: BAR 7: assigned [mem 0x22009004000-0x22009103fff 64bit pref] [ 1.661083] pci 0001:41:00.0: BAR 10: assigned [mem 0x22009104000-0x22009203fff 64bit pref] [ 1.669640] pci 0001:41:00.1: BAR 4: assigned [mem 0x22009204000-0x22009207fff 64bit pref] [ 1.678115] pci 0001:41:00.1: BAR 7: assigned [mem 0x22009208000-0x22009307fff 64bit pref] [ 1.686591] pci 0001:41:00.1: BAR 10: assigned [mem 0x22009308000-0x22009407fff 64bit pref] [ 1.695148] pci 0001:41:00.0: BAR 2: assigned [io 0x1000-0x101f] [ 1.701285] pci 0001:41:00.1: BAR 2: assigned [io 0x1020-0x103f] [ 1.707421] pci 0001:40:00.0: PCI bridge to [bus 41-42] [ 1.712621] pci 0001:40:00.0: bridge window [io 0x1000-0x1fff] [ 1.718685] pci 0001:40:00.0: bridge window [mem 0x22008000000-0x220095fffff pref] [ 1.726434] ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 80-bf]) [ 1.732594] acpi HISI0080:01: _OSC: OS supports [ExtendedConfig Segments MSI] [ 1.739696] acpi HISI0080:01: _OSC failed (AE_NOT_FOUND); disabling ASPM [ 1.746425] acpi HISI0080:01: link status is down [ 1.751106] acpi HISI0080:01: ECAM at [mem 0x24008000000-0x2400bffffff] for [bus 80-bf] [ 1.759090] Remapped I/O 0x000002400fff0000 to [io 0x10000-0x1ffff window] [ 1.766086] PCI host bridge to bus 0002:80 [ 1.770172] pci_bus 0002:80: root bus resource [mem 0x2400c000000-0x2400ffeffff window] (bus address [0xc0000000-0xc3feffff]) [ 1.781422] pci_bus 0002:80: root bus resource [io 0x10000-0x1ffff window] (bus address [0x0000-0xffff]) [ 1.790940] pci_bus 0002:80: root bus resource [bus 80-bf] [ 1.796414] pci 0002:80:00.0: ignoring class 0x000000 (doesn't match header type 01) [ 1.804311] pci 0002:80:00.0: not setting up bridge for bus 0002:81 [ 1.810956] ACPI: IORT: can't find node related to (null) device [ 1.817228] ACPI: IORT: can't find node related to (null) device [ 1.823453] vgaarb: loaded [ 1.826246] SCSI subsystem initialized [ 1.830103] ACPI: bus type USB registered [ 1.834130] usbcore: registered new interface driver usbfs [ 1.839606] usbcore: registered new interface driver hub [ 1.844933] usbcore: registered new device driver usb [ 1.850014] pps_core: LinuxPPS API ver. 1 registered [ 1.854953] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 1.864048] PTP clock support registered [ 1.868069] Advanced Linux Sound Architecture Driver Initialized. [ 1.874376] clocksource: Switched to clocksource arch_sys_counter [ 1.880489] VFS: Disk quotas dquot_6.6.0 [ 1.884414] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 1.891385] pnp: PnP ACPI init [ 1.894570] system 00:00: [mem 0xb0080000-0xb008ffff] has been reserved [ 1.901209] system 00:01: [mem 0xb0090000-0xb009ffff] has been reserved [ 1.907813] pnp: PnP ACPI: found 2 devices [ 1.914467] NET: Registered protocol family 2 [ 1.919030] TCP established hash table entries: 65536 (order: 7, 524288 bytes) [ 1.926352] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) [ 1.933333] TCP: Hash tables configured (established 65536 bind 65536) [ 1.939876] UDP hash table entries: 4096 (order: 5, 131072 bytes) [ 1.945968] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes) [ 1.952576] NET: Registered protocol family 1 [ 1.957013] RPC: Registered named UNIX socket transport module. [ 1.962905] RPC: Registered udp transport module. [ 1.967586] RPC: Registered tcp transport module. [ 1.972266] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 1.978872] Unpacking initramfs... [ 2.340835] Freeing initrd memory: 27492K (ffffffc01e520000 - ffffffc01fff9000) [ 2.348645] kvm [1]: 8-bit VMID [ 2.351776] kvm [1]: Hyp mode initialized successfully [ 2.356892] kvm [1]: error: KVM vGIC probing failed [ 2.361790] kvm [1]: virtual timer IRQ3 [ 2.366650] ACPI: IORT: can't find node related to (null) device [ 2.373057] futex hash table entries: 4096 (order: 7, 524288 bytes) [ 2.379403] audit: initializing netlink subsys (disabled) [ 2.384813] audit: type=2000 audit(1.864:1): initialized [ 2.390302] workingset: timestamp_bits=44 max_order=21 bucket_order=0 [ 2.400222] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 2.406342] NFS: Registering the id_resolver key type [ 2.411393] Key type id_resolver registered [ 2.415557] Key type id_legacy registered [ 2.419609] fuse init (API version 7.24) [ 2.423687] 9p: Installing v9fs 9p2000 file system support [ 2.429982] io scheduler noop registered [ 2.433946] io scheduler cfq registered (default) [ 2.439027] pcieport 0001:40:00.0: can't derive routing for PCI INT A [ 2.445438] pcieport 0001:40:00.0: PCI INT A: no GSI [ 2.451126] xenfs: not registering filesystem on non-xen platform [ 2.458262] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 2.465049] console [ttyS0] disabled [ 2.468627] APMC0D08:00: ttyS0 at MMIO 0x80300000 (irq = 5, base_baud = 12500000) is a 16550A [ 2.477133] console [ttyS0] enabled [ 2.477133] console [ttyS0] enabled [ 2.484137] bootconsole [uart8250] disabled [ 2.484137] bootconsole [uart8250] disabled [ 2.492728] SuperH (H)SCI(F) driver initialized [ 2.497322] msm_serial: driver initialized [ 2.501649] Failed to find cpu0 device node [ 2.505852] Unable to detect cache hierarchy from DT for CPU 0 [ 2.514093] loop: module loaded [ 2.517694] tun: Universal TUN/TAP device driver, 1.6 [ 2.522771] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> [ 2.529079] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k [ 2.534939] e1000e: Copyright(c) 1999 - 2015 Intel Corporation. [ 2.540908] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.3.0-k [ 2.547900] igb: Copyright (c) 2007-2014 Intel Corporation. [ 2.553518] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.0.2-k [ 2.561382] igbvf: Copyright (c) 2009 - 2012 Intel Corporation. [ 2.567350] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 4.2.1-k [ 2.575039] ixgbe: Copyright (c) 1999-2015 Intel Corporation. [ 2.580854] pcieport 0001:40:00.0: can't derive routing for PCI INT A [ 2.587326] ixgbe 0001:41:00.0: PCI INT A: no GSI [ 2.592178] ixgbe 0001:41:00.0: enabling device (0000 -> 0002) [ 2.753716] ixgbe 0001:41:00.0: Multiqueue Enabled: Rx Queue count = 16, Tx Queue count = 16 [ 2.762393] ixgbe 0001:41:00.0: PCI Express bandwidth of 32GT/s available [ 2.769213] ixgbe 0001:41:00.0: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%) [ 2.776457] ixgbe 0001:41:00.0: MAC: 2, PHY: 17, SFP+: 5, PBA No: FFFFFF-0FF [ 2.783537] ixgbe 0001:41:00.0: 68:a8:28:2e:c9:10 [ 2.792732] ixgbe 0001:41:00.0: Intel(R) 10 Gigabit Network Connection [ 2.799312] pcieport 0001:40:00.0: can't derive routing for PCI INT B [ 2.805783] ixgbe 0001:41:00.1: PCI INT B: no GSI [ 2.810598] ixgbe 0001:41:00.1: enabling device (0000 -> 0002) [ 3.949697] ixgbe 0001:41:00.1: Multiqueue Enabled: Rx Queue count = 16, Tx Queue count = 16 [ 3.958365] ixgbe 0001:41:00.1: PCI Express bandwidth of 32GT/s available [ 3.965185] ixgbe 0001:41:00.1: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%) [ 3.972427] ixgbe 0001:41:00.1: MAC: 2, PHY: 1, PBA No: FFFFFF-0FF [ 3.978634] ixgbe 0001:41:00.1: 68:a8:28:2e:c9:11 [ 3.987790] ixgbe 0001:41:00.1: Intel(R) 10 Gigabit Network Connection [ 3.994388] sky2: driver version 1.30 [ 3.998201] VFIO - User Level meta-driver version: 0.3 [ 4.003889] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 4.010459] ehci-pci: EHCI PCI platform driver [ 4.014944] ehci-platform: EHCI generic platform driver [ 4.020226] ehci-platform PNP0D20:00: EHCI Host Controller [ 4.025745] ehci-platform PNP0D20:00: new USB bus registered, assigned bus number 1 [ 4.033572] ehci-platform PNP0D20:00: irq 6, io mem 0xa1000000 [ 4.050387] ehci-platform PNP0D20:00: USB 2.0 started, EHCI 1.00 [ 4.056652] hub 1-0:1.0: USB hub found [ 4.060428] hub 1-0:1.0: 1 port detected [ 4.064517] ehci-msm: Qualcomm On-Chip EHCI Host Controller [ 4.070137] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 4.076351] ohci-pci: OHCI PCI platform driver [ 4.080834] ohci-platform: OHCI generic platform driver [ 4.086166] usbcore: registered new interface driver usb-storage [ 4.092427] mousedev: PS/2 mouse device common for all mice [ 4.161533] rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0 [ 4.168513] i2c /dev entries driver [ 4.172251] sdhci: Secure Digital Host Controller Interface driver [ 4.178458] sdhci: Copyright(c) Pierre Ossman [ 4.182850] Synopsys Designware Multimedia Card Interface Driver [ 4.188933] sdhci-pltfm: SDHCI platform and OF driver helper [ 4.194701] ledtrig-cpu: registered to indicate activity on CPUs [ 4.200950] usbcore: registered new interface driver usbhid [ 4.206549] usbhid: USB HID core driver [ 4.210569] ACPI: IORT: can't find node related to (null) device [ 4.216837] NET: Registered protocol family 17 [ 4.221334] 9pnet: Installing 9P2000 support [ 4.225652] Key type dns_resolver registered [ 4.230166] registered taskstats version 1 [ 4.297850] rtc-efi rtc-efi: hctosys: unable to read the hardware clock [ 4.304576] ALSA device list: [ 4.307561] No soundcards found. [ 4.311063] ttyS0 - failed to request DMA [ 4.315348] Freeing unused kernel memory: 840K (ffffff8008a89000 - ffffff8008b5b000) root@(none)$ ifconfig eth0 192.168.20.188 [ 15.679957] ixgbe 0001:41:00.0: registered PHC device on eth0 root@(none)$ [ 15.851142] ixgbe 0001:41:00.0 eth0: detected SFP+: 5 [ 15.990419] ixgbe 0001:41:00.0 eth0: NIC Link is Up 10 Gbps, Flow Control: RX/TX root@(none)$ ping 192.168.20.188 PING 192.168.20.4 (192.168.20.4): 56 data bytes 64 bytes from 192.168.20.4: seq=14 ttl=128 time=1.465 ms 64 bytes from 192.168.20.4: seq=15 ttl=128 time=0.616 ms 64 bytes from 192.168.20.4: seq=16 ttl=128 time=0.391 ms 64 bytes from 192.168.20.4: seq=17 ttl=128 time=0.698 ms 64 bytes from 192.168.20.4: seq=18 ttl=128 time=0.676 ms 64 bytes from 192.168.20.4: seq=19 ttl=128 time=0.524 ms 64 bytes from 192.168.20.4: seq=20 ttl=128 time=0.301 ms 64 bytes from 192.168.20.4: seq=21 ttl=128 time=0.248 ms 64 bytes from 192.168.20.4: seq=22 ttl=128 time=0.403 ms
[toc] | [prev] | [next] | [standalone]
| From | Sinan Kaya <okaya@codeaurora.org> |
|---|---|
| Date | 2016-05-23 17:40 +0200 |
| Subject | Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller |
| Message-ID | <rC07w-7GV-11@gated-at.bofh.it> |
| In reply to | #1398230 |
On 5/10/2016 11:19 AM, Tomasz Nowicki wrote: > From the functionality point of view this series may be split into the > following logic parts: > 1. New ECAM API and update for users of the pci-host-common API > 2. Necessary fixes as the preparation for using driver on ARM64. > 3. Use new MCFG interface and implement generic ACPI based PCI host controller driver. > 4. Enable above driver on ARM64 > > Patches has been built on top of 4.6-rc7 and can be found here: > git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v7) > > This has been tested on Cavium ThunderX server. Any help in reviewing and > testing is very appreciated. > Tested on Qualcomm QDF2XXX server using Mellanox CX3 and Intel e1000e adapters. Tested-by: Sinan Kaya <okaya@codeaurora.org> -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | linux.kernel
csiph-web