On 20.09.2016 15:08, Bjorn Helgaas wrote:
On Tue, Sep 20, 2016 at 09:06:23AM +0200, Tomasz Nowicki wrote:
On 19.09.2016 17:45, Bjorn Helgaas wrote:
On Fri, Sep 09, 2016 at 09:24:06PM +0200, Tomasz Nowicki wrote:
ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
compliant with ECAM standard. It uses non-standard configuration space
accessors (see pci_thunder_pem_ops) and custom configuration space granulation
(see bus_shift = 24). In order to access configuration space and
probe PEM as ACPI based PCI host controller we need to add MCFG quirk
infrastructure. This involves:
1. Export PEM pci_thunder_pem_ops structure so it is visible to MCFG quirk
code.
2. New quirk entries for each PEM segment. Each contains platform IDs,
mentioned pci_thunder_pem_ops and CFG resources.
Quirk is considered for ThunderX silicon pass2.x only which is identified
via MCFG revision 1.
Is it really the case that silicon pass2.x has MCFG revision 1, and
silicon pass1.x has MCFG revision 2? That just seems backwards.
It is weird but silicon pass2.x is more common and it had MCFG
revision 1 from the beginning. Unless it is allowed to use MCFG
revision 0 ? Then we could use MCFG revision 0 for pass1.x
There's no reason to avoid revision 0. The question is really what
firmware is already in the field. We need to accommodate that. We don't
want a situation where kernel version X only works with firmware version Y,
but kernel version X+1 only works with firmware version Y+1.
Yes I agree. We have already deployed the firmware where:
pass2.x has MCFG revision 1
pass1.x has MCFG revision 2
so we need to stick to this.
Thanks,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
