> On Aug 25, 2015, at 6:53 PM, Tian, Feng <[email protected]> wrote: > > Hi, Ben & Andrew > > The GetBarAttributes() returns a set of ACPI 2.0 resource descriptors that > describe the current configuration of the BARs of the PCI controller. > > What I understood is the returned value of GetBarAttributes() is a CPU > address rather than a PCI address. From the view of PciIo, nobody needs to > know/use Bar's PCI address. >
I needed to go look it up in the ACPI spec to be sure, so it took me a while…. 5.1.1 Address Space Translation Some platforms may contain bridges that perform translations as I/O and/or Memory cycles pass through the bridges. This translation can take the form of the addition or subtraction of an offset. Or it can take the form of a conversion from I/O cycles into Memory cycles and back again. When translation takes place, the addresses placed on the processor bus by the processor during a read or write cycle are not the same addresses that are placed on the I/O bus by the I/O bus bridge. The address the processor places on the processor bus will be known here as the processor-relative address. And the address that the bridge places on the I/O bus will be known as the bus-relative address. Unless otherwise noted, all addresses used within this section are processor-relative addresses. For example, consider a platform with two root PCI buses. The platform designer has several choices. One solution would be to split the 16-bit I/O space into two parts, assigning one part to the first root PCI bus and one part to the second root PCI bus. Another solution would be to make both root PCI buses decode the entire 16-bit I/O space, mapping the second root PCI bus’s I/O space into memory space. In this second scenario, when the processor needs to read from an I/O register of a device underneath the second root PCI bus, it would need to perform a memory read within the range that the root PCI bus bridge is using to map the I/O space. … Note: Industry standard PCs do not provide address space translations because of historical compatibility issues. But it looks like the default in ACPI is a CPU (processor-relative) address. Thus if the mapping is not 1:1 "Address Translation Offset” is the offset for the bus view. I see from the PCI bus driver that there is not a path to return the "Address Translation Offset”. It seems like the PCI Root Bridge IO protocol could return the ""Address Translation Offset”, and the PCI Bus driver could save that per Bar and then return that value in the ACPI Address Space Descriptor. Maybe Ben could look into that a propose a patch if it works. Thanks, Andrew Fish > Thanks > Feng > > -----Original Message----- > From: edk2-devel [mailto:[email protected]] On Behalf Of > Benjamin Herrenschmidt > Sent: Wednesday, August 26, 2015 07:54 > To: Andrew Fish > Cc: [email protected] > Subject: Re: [edk2] PCI and non-1:1 mapping of MMIO space > > (Argh, I keep sending these from my IBM address which isn't the one on the > list. Sorry Andrew for the duplicates). > > On Tue, 2015-08-25 at 14:48 -0700, Andrew Fish wrote: > >> >>> So if we stick to the definition of GetBarAttributes() only >>> returning a BAR value, then it's impossible to implement a PCI GOP >>> driver by following the spec. >>> >> I came to that conclusion too. > > :( > >>> Now, there's one thing that might work, which would be to exploit >>> the "AddressTranslationOffset" field of the ACPI resource >>> descriptor. >>> >> How do you represent a system like this in ACPI? It might be a good >> idea to solve it in a similar way. > > Unfortunately, I am not familiar with the details of ACPI, I only have a high > level understanding of it. Our platforms have been Open Firmware based for as > far as I've been involved with them and lately, we use C -generated flat > device-tree along with a custom runtime firmwarealled a OPAL). > > At this point I'm not (yet) considering a move to ACPI. I'm doing a proof of > concept ppc64 UEFI port to get a feel of the water temperature more than > anything else (though I'll be happy to contribute things back once I get the > appropriate legalese sorted internally to IBM). > >> The PCI IO was designed to not required the 1:1 mapping. The direct >> access to the Framebuffer came along later, as was mostly a fallback >> for the OS on a safe mode boot kind of thing. I think we missed >> passing the frame buffer out on a system that was not 1:1. > > Ok. Well, it will be needed even on non-1:1 systems, we will have similar > requirements of the OS needing an early boot framebuffer etc... > and I suspect the desire to directly access BARs (at least prefetchable > ones) from the CPU isn't going away in other areas either. > > So maybe we should try to address this. I'm trying to figure out how to join > the appropriate working groups etc... so I can participate in the spec side > discussion as well (which I'll need to do for other reasons anyway if we are > ever going to officially defining the ppc64 ABI in the spec). > > Cheers, > Ben. > >> Thanks, >> >> Andrew Fish >> >>> Cheers, >>> Ben. > _______________________________________________ > edk2-devel mailing list > [email protected] > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=dF57sfs6vBGwtMhtJNiBhLCm__haMuk_-CfqcT3YPWI&s=wuQABUk0dxEFp6yhy8LnTMc9pArzmumbQmGOnzfjtZ0&e= > > _______________________________________________ > edk2-devel mailing list > [email protected] > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=1HnUuXD1wDvw67rut5_idw&m=dF57sfs6vBGwtMhtJNiBhLCm__haMuk_-CfqcT3YPWI&s=wuQABUk0dxEFp6yhy8LnTMc9pArzmumbQmGOnzfjtZ0&e= > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
