Re: [PATCH 05/11] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory

[Tomasz Nowicki]

On 31.08.2015 13:01, Tomasz Nowicki wrote:
> On 08.06.2015 17:14, Lorenzo Pieralisi wrote:
> > On Mon, Jun 08, 2015 at 03:57:38AM +0100, Hanjun Guo wrote:
> >
> > [...]
> >
> > > > > > > > > Why can't we make use of the ECAM implementation used by
> > > > > > > > > pci-host-generic
> > > > > > > > > and drivers/pci/access.c?
> > > > > > > >
> > > > > > > > We had that question when I had posted MMCFG patch set separately,
> > > > > > > > please see:
> > > > > > > > https://lkml.org/lkml/2015/3/11/492
> > > > > > >
> > > > > > > Yes, but the real question is, why do we need to have PCI config
> > > > > > > space
> > > > > > > up and running before a bus struct is even created ? I think the
> > > > > > > reason is
> > > > > > > the PCI configuration address space format (ACPI 6.0, Table 5-27,
> > > > > > > page
> > > > > > > 108):
> > > > > > >
> > > > > > > "PCI Configuration space addresses must be confined to devices on
> > > > > > > PCI Segment Group 0, bus 0. This restriction exists to accommodate
> > > > > > > access to fixed hardware prior to PCI bus enumeration".
> > > > > > >
> > > > > > > On HW reduced platforms I do not even think this is required at all,
> > > > > > > we have to look into this to avoid code duplication that might well
> > > > > > > turn out useless.
> > > > > >
> > > > > > This is only for the fixed hardware, which will be not available for
> > > > > > ARM64 (reduced hardware mode), but in Generic Hardware Programming
> > > > > > Model, we using OEM-provided ACPI Machine Language (AML) code to
> > > > > > access
> > > > > > generic hardware registers, this will be available for reduced
> > > > > > hardware
> > > > > > too.
> > > > > >
> > > > > > So in ACPI spec, it says: (ACPI 6.0 page 66, last paragraph)
> > > > > >
> > > > > > ACPI defines eight address spaces that may be accessed by generic
> > > > > > hardware implementations. These include:
> > > > > > * System I/O space
> > > > > > * System memory space
> > > > > > * PCI configuration space
> > > > > > * Embedded controller space
> > > > > > * System Management Bus (SMBus) space
> > > > > > * CMOS
> > > > > > * PCI BAR Target
> > > > > > * IPMI space
> > > > > >
> > > > > > So if any device using the PCI address space for control, such
> > > > > > as a system reset control device, its address space can be reside
> > > > > > in PCI configuration space (who can prevent a OEM do that crazy
> > > > > > thing? :) ), and it should be accessible before the PCI bus is
> > > > > > created.
> > > > >
> > > > > Us, by changing attitude and questioning features whose usefulness
> > > > > is questionable. I will look into this and raise the point, I am not
> > > > > thrilled by the idea of adding another set of PCI accessor functions
> > > > > and drivers because we have to access a register through PCI before
> > > > > enumerating the bus (and on arm64 this is totally useless since
> > > > > we are not meant to support fixed HW anyway). Maybe we can make acpica
> > > > > code use a "special" stub (ACPI specific, PCI configuration space
> > > > > address
> > > > > space has restrictions anyway), I have to review this set in its
> > > > > entirety to see how to do that (and I would kindly ask you to do
> > > > > it too, before saying it is not possible to implement it).
> > > >
> > > > I'm willing to do that, actually, if we don't need a mechanism to
> > > > access PCI config space before the bus is created, the code can be
> > > > simplified a lot.
> > >
> > > After more investigation on the spec and the ACPI core code, I'm
> > > still not convinced that accessing to PCI config space before PCI
> > > bus creating is impossible, also there is no enough ARM64 hardware
> > > to prove that too. But I think we can go in this way, reuse the
> > > ECAM implementation by pci-host-generic for now, and implement the PCI
> > > accessor functions before enumerating PCI bus when needed in the
> > > future, does it make sense?
> >
> > You mean we rewrite the patch to make sure we can use the PCI host
> > generic
> > driver with MCFG and we leave the acpica PCI config call empty stubs on
> > arm64 (as they are now) ?
>
> Hi Bjorn, Rafael,
>
> Lorenzo pointed out very important problem we are having with PCI config
> space access for ARM64. Please refer to the above discussion and add
> your 2 cents. Can we forget about accessing PCI config space (for
> Hardware Reduced profile) before PCI bus creation? If not, do you see a
> way to use drivers/pci/access.c accessors here, like acpica change? Any
> opinion is very appreciated.

Kindly remainder.

Thanks,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/