lkml.org 
[lkml]   [2016]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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.

    Thank you,
    Lorenzo

    \
     
     \ /
      Last update: 2016-05-24 19:41    [W:2.960 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site