Thanks Ben! Some Replies and doubts inlined. Regards, Shaveta
-----Original Message----- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Sunday, September 13, 2015 4:39 AM To: Leekha Shaveta-B20052 <shav...@freescale.com>; Andrew Fish <af...@apple.com>; edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Tian, Feng <feng.t...@intel.com> Subject: Re: PCI and non-1:1 mapping of MMIO space (Doubt o PCI Root bridge IOMap and IoAllocateBuffer) On Sat, 2015-09-12 at 18:04 +0000, Leekha Shaveta wrote: > Hi > > I was implementing PCI RootBridgeIo protocol and have some doubts in > "IoMap" and "AllocateBuffer" functions of this protocol. > > In our platform, PCI space is starting form address 0x50_0000_0000 > (40 bit addressable) > And its mapping on PCI bus is like: > 50_0000_0000 => 0000_0000 (32 bit) Is the above the mapping of MMIO or DMA ? Because AllocateBuffer/IoMap are all about DMA, not MMIO [Shaveta] It is MMIO mapping ... Note that regarding the issue of non-1:1 mappings vs. GetBarAttributes(), I have patches to fix that in the core by enabling us to use the mTranslationOffset field of the ACPI descriptor. I will be able to post these some time next week. [Shaveta] What does those patches does? As I my case also, CPU address 50_4000_0000 is being translated to PCI bus address 0x4000_0000 For memory transactions. So its also a case of non- 1:1 mapping For Mem.Read/Mem.Write I have added a translation offset. For BARs programming also, do we need to handle it? How have you handled it? > > From where the "AllocateBuffer" function should allocate memory when > > asked by any PCI device? > What is the meaning of "Allocates pages that are suitable for an > EfiPciOperationBusMasterCommonBuffer or > EfiPciOperationBusMasterCommonBuffer64 mapping" > > How to manage mapping in "RootBridgeIoMap" function? Well, it depends if the mapping you provided above is an MMIO mapping or a DMA mapping ... I to looks like MMIO to me in which case it has strictly nothing to do with IoMap/AllocateBuffer [Shaveta] then what kind of mapping IoMap function should do when PCI NIC card ask for this IoMap during its "ping" operation ?? Cheers, Ben > Thanks and Regards, > Shaveta > > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Tian, Feng > Sent: Wednesday, August 26, 2015 7:24 AM > To: Benjamin Herrenschmidt <b...@kernel.crashing.org>; Andrew Fish < > af...@apple.com> > Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Tian, Feng < > feng.t...@intel.com> > Subject: Re: [edk2] PCI and non-1:1 mapping of MMIO space > > 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. > > Thanks > Feng > > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Benjamin Herrenschmidt > Sent: Wednesday, August 26, 2015 07:54 > To: Andrew Fish > Cc: edk2-devel@lists.01.org > 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 > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
