[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160920130839.GA13855@localhost>
Date: Tue, 20 Sep 2016 08:08:39 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Tomasz Nowicki <tn@...ihalf.com>
Cc: will.deacon@....com, catalin.marinas@....com, rafael@...nel.org,
Lorenzo.Pieralisi@....com, arnd@...db.de, hanjun.guo@...aro.org,
okaya@...eaurora.org, jchandra@...adcom.com, cov@...eaurora.org,
dhdang@....com, ard.biesheuvel@...aro.org,
robert.richter@...iumnetworks.com, mw@...ihalf.com,
Liviu.Dudau@....com, ddaney@...iumnetworks.com,
wangyijing@...wei.com, msalter@...hat.com,
linux-pci@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linaro-acpi@...ts.linaro.org, jcm@...hat.com,
andrea.gallo@...aro.org, jeremy.linton@....com,
liudongdong3@...wei.com, gabriele.paoloni@...wei.com,
jhugo@...eaurora.org, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V6 4/5] PCI: thunder: Enable ACPI PCI controller for
ThunderX pass2.x silicon version
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.
Bjorn
Powered by blists - more mailing lists