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

[tomasz.nowicki@linaro.org (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