From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from blyat.fensystems.co.uk (blyat.fensystems.co.uk [54.246.183.96]) by mx.groups.io with SMTP id smtpd.web08.3161.1619559615886277050 for ; Tue, 27 Apr 2021 14:40:17 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: ipxe.org, ip: 54.246.183.96, mailfrom: mcb30@ipxe.org) Received: from pudding.home (unknown [IPv6:2a00:23c6:5495:5e00:e4c:7e47:a165:c0fc]) by blyat.fensystems.co.uk (Postfix) with ESMTPSA id B7D10441AC; Tue, 27 Apr 2021 21:40:11 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH V5 1/1] EmbeddedPkg: DwMmcHcDxe: Add support for Designware SDMMC driver To: devel@edk2.groups.io, afish@apple.com, tien.hock.loh@intel.com Cc: Mike Kinney , "thloh85@gmail.com" , Leif Lindholm , Ard Biesheuvel References: <20210322032439.9312-1-tien.hock.loh@intel.com> <20210322032439.9312-2-tien.hock.loh@intel.com> <09F9E77A-9B6B-4D5F-A7FF-F49EAFA03FEB@apple.com> From: "Michael Brown" Message-ID: <61871098-5a01-8125-ae9b-7ccac33d3577@ipxe.org> Date: Tue, 27 Apr 2021 22:40:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <09F9E77A-9B6B-4D5F-A7FF-F49EAFA03FEB@apple.com> X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on blyat.fensystems.co.uk Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable 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=20 > produces a =E2=80=9Cfake=E2=80=9D PCI IO Protocol. The =E2=80=9Cfake=E2= =80=9D PCI IO driver abstracts=20 > how the MMIO device shows up on the platform. This works well if the=20 > MMIO device is really the same IP block as a PCI device. This usually=20 > maps to the PCI BAR being the same thing as the magic MMIO range. The=20 > =E2=80=9Cfake=E2=80=9D PCI IO Protocol also abstracts platform specific= DMA rules from=20 > the generic driver. Slightly off-topic, but I've always been curious about this: given that=20 the entire purpose of PCI BARs is to allow for the use of=20 straightforward MMIO operations, in which standard CPU read/write=20 instructions can be used to access device registers with zero overhead=20 and no possible error conditions, why do the=20 EFI_PCI_IO_PROTOCOL.Mem.Read (and related) abstractions exist? They=20 seem to add a lot of complexity for negative benefit, and I'd be=20 interested to know if there was some reason why the design was chosen. Thanks, Michael