On Tue, 2015-08-25 at 14:45 -0700, Andrew Fish wrote: > > Well the GOP returns a FrameBuffer, so that address needs to be > adjusted. So that seems to be the bug in the spec. I’ll bring this up > to the UEFI Forum. > > But I think for the non FrameBuffer case it would be better to fix > the drivers.
Should we consider an optional protocol extension (or new protocol) to the PCI IO protocol that provides "BarMap" and "BarUnmap" semantics allowing a driver to effectively map a BAR into the CPU address space ? On Intel those would just return the BAR address. I am not yet familiar enough with UEFI to have a good grasp of how one extends a protocol... I assume we could create a new PCI_IO_PROTOCOL_EX that contains the new calls with its own GUID that a device can optionally implement (which PciBusDxe would instanciate if the corresponding root bridge protocol extension exists). The other option as I mentioned earlier is to see if we can make use of the translation filed in the ACPI resource descriptor, though I'm not familiar with how it's usually used on ACPI based platforms. Cheers, Ben. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
