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

Andrew Fish via groups.io afish=apple.com at groups.io
Wed Apr 28 00:52:27 UTC 2021


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 at 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 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 (#74507): https://edk2.groups.io/g/devel/message/74507
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]
-=-=-=-=-=-=-=-=-=-=-=-






More information about the edk2-devel-archive mailing list