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

[Michael D Kinney]

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 at apple.com>
> Sent: Tuesday, April 27, 2021 4:46 PM
> To: Michael Brown <mcb30 at ipxe.org>
> Cc: edk2-devel-groups-io <devel at edk2.groups.io>; Loh, Tien Hock <tien.hock.loh at intel.com>; Kinney, Michael D
> <michael.d.kinney at intel.com>; thloh85 at gmail.com; Leif Lindholm <leif at nuviainc.com>; Ard Biesheuvel
> <ardb+tianocore at 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 at 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



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#74506): https://edk2.groups.io/g/devel/message/74506
Mute This Topic: https://groups.io/mt/81516685/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-