Re: [edk2-devel] [PATCH V5 1/1] EmbeddedPkg: DwMmcHcDxe: Add support for Designware SDMMC driver

["Andrew Fish" <afish@apple.com>]

Also remember we were working on Itanic (Itanium) so we were thinking this had to scale to mainframe and super computer. 

We also tried to undo the PC 1980 hardware assumptions that were factored into PC BIOS. We might have tended too over abstract a little. We targeted binary compatibility, so its not like we can cheat if we get the abstraction wrong and just add a bunch of #ifdef architecture X to the code like some monolithic OS codebase. 

Thanks,

Andrew Fish

> On Apr 27, 2021, at 5:06 PM, Michael D Kinney <michael.d.kinney@intel.com> wrote:
> 
> Michael,
> 
> Another feature the current design supports is PCI rebalancing.  Meaning the PCI resource assignment can change 
> during the boot.  The PCI Bus Driver does not support doing a rebalance today, but the PCI I/O Protocol was
> designed so the UEFI Driver that consumes the PCI I/O Protocol never needs to know the current resource 
> assignments.
> 
> Mike
> 
>> -----Original Message-----
>> From: Andrew Fish <afish@apple.com>
>> Sent: Tuesday, April 27, 2021 4:46 PM
>> To: Michael Brown <mcb30@ipxe.org>
>> Cc: edk2-devel-groups-io <devel@edk2.groups.io>; Loh, Tien Hock <tien.hock.loh@intel.com>; Kinney, Michael D
>> <michael.d.kinney@intel.com>; thloh85@gmail.com; Leif Lindholm <leif@nuviainc.com>; Ard Biesheuvel
>> <ardb+tianocore@kernel.org>
>> Subject: Re: [edk2-devel] [PATCH V5 1/1] EmbeddedPkg: DwMmcHcDxe: Add support for Designware SDMMC driver
>> 
>> 
>> 
>>> On Apr 27, 2021, at 2:40 PM, Michael Brown <mcb30@ipxe.org> wrote:
>>> 
>>> On 27/04/2021 18:31, Andrew Fish via groups.io wrote:
>>>> One trick people have pulled in the past is to write a driver that produces a “fake” PCI IO Protocol. The “fake” PCI IO
>> driver abstracts how the MMIO device shows up on the platform. This works well if the MMIO device is really the same IP
>> block as a PCI device. This usually maps to the PCI BAR being the same thing as the magic MMIO range. The “fake” PCI IO
>> Protocol also abstracts platform specific DMA rules from the generic driver.
>>> 
>>> Slightly off-topic, but I've always been curious about this: given that the entire purpose of PCI BARs is to allow for
>> the use of straightforward MMIO operations, in which standard CPU read/write instructions can be used to access device
>> registers with zero overhead and no possible error conditions, why do the EFI_PCI_IO_PROTOCOL.Mem.Read (and related)
>> abstractions exist?  They seem to add a lot of complexity for negative benefit, and I'd be interested to know if there was
>> some reason why the design was chosen.
>>> 
>> 
>> Michael,
>> 
>> Assuming physical address == non-catchable memory region is not always true. For example on Itainium you had to flip bit
>> 63 in physical mode to do a non-cached transaction. There are also some high end servers that have different physical
>> address ranges for PCI v.s DRAM.
>> 
>> Basically we were paranoid about portability. That and we really don’t want #ifdef in the code for different
>> architectures.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> Thanks,
>>> 
>>> Michael
> 
> 
> 
> 
> 
>