summaryrefslogtreecommitdiffstats
path: root/MdeModulePkg/Bus/Pci
Commit message (Collapse)AuthorAgeFilesLines
* PciBusDxe: duplicate node insertion for every PPB device in the systemJaveed, Ashraf2019-07-011-18/+1
| | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1796 Bug fixed in PciBusDxe\PciLib.c. Removed the redundant second call to PciSearchDevice sub-routine when the PCD for the Hot-Plug support is disabled. Signed-off-by: Ashraf Javeed <Ashraf.javeed@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/SdMmcHcDxe: Implement revision 3 of SdMmcOverrideProtocolAlbecki, Mateusz2019-07-016-231/+814
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1882 Implement support for GetOperatingParamters notify phase in SdMmcHcDxe driver. GetOperatingParameters notify phase is signaled before we start card detection and initialization. Code has been updated for both eMMC and SD card controllers to take into consideration those new parameters. Initialization process has been divided into 2 steps. In the first step we bring the link up to the point where we can get card identification data(Extended CSD in eMMC case and SWITCH command response in SD card case). This data is later used along with controller capabilities and operating parameters passed in GetOperatingParameters phase to choose preferred bus settings in GetTargetBusSettings function. Those settings are later on to start bus training to high speeds. If user passes incompatible setting with selected bus timing driver will assume it's standard behavior with respect to that setting. For instance if HS400 has been selected as a target bus timing due to card and controller support bus width setting of 4 and 1 bit won't be respected and 8 bit setting will be chosen instead. Tests on Marvell boards were also performed by Marcin Wojtas <mw@semihalf.com>: https://edk2.groups.io/g/devel/message/42999 Board 1 (out of tree): SD - OK, MMC - OK Board 2: (Armada80x0McBin): SD - OK, MMC - OK Board 3: (Armada70x0Db): SD - problems, MMC - OK Please note that the problem on Armada70x0Db SD devices are introduced by adding new types of SD bus modes, a subsequent patch within edk2-platforms repository will be proposed to address it. (More details can be referred from the above link.) Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Regression-tested-by: Sumit Garg <sumit.garg@linaro.org>
* MdeModulePkg/NvmExpressPei: Produce NVM Express PassThru PPIMaggie Chu2019-06-248-117/+420
| | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1879 This commit will add codes to produce the NVM Express PassThru PPI. Signed-off-by: Maggie Chu <maggie.chu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/PciBusDxe: catch unimplemented extended config space readsLaszlo Ersek2019-06-111-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When assigning a physical PCIe device to a QEMU/KVM guest, PciBusDxe may find that the extended config space is not (fully) implemented. In LocatePciExpressCapabilityRegBlock(), "CapabilityEntry" may be read as 0xFFFF_FFFF at a given config space offset, after which the loop gets stuck spinning on offset 0xFFC (the read at offset 0xFFC returns 0xFFFF_FFFF most likely as well). Another scenario (not related to virtualization) for triggering the above is when a Conventional PCI bus -- exposed by a PCIe-to-PCI bridge in the topology -- intervenes between a PCI Express Root Port and a PCI Express Endpoint. The Conventional PCI bus limits the accessible config space of the PCI Express Endpoint, even though the endpoint advertizes the PCI Express capability. Here's a diagram, courtesy of Alex Williamson: [PCIe Root Port]--[PCIe-to-PCI]--[PCI-to-PCIe]--[PCIe EP] ->| |<- Conventional PCI bus Catch reads of 0xFFFF_FFFF in LocatePciExpressCapabilityRegBlock(), and break out of the scan with a warning message. The function will return EFI_NOT_FOUND. Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg: Remove BootInRecoveryMode PPIxuwei62019-05-094-4/+4
| | | | | | | | | | | | | | | | | | DEPEX from PEI storage stack. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1777 BootInRecoveryMode Ppi dependency should be removed from PEI storage stack drivers. Besides recovery, more features are using the storage stack. Platform can apply Ppi dependency in Recovery FV which contains full storage driver stack. Platform storage stack modules, such as host controller init PEI module, should also remove this dependency. Cc: Ray Ni <ray.ni@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Wei6 Xu <wei6.xu@intel.com> Reviewed-by: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
* MdeModulePkg/NvmExpressHci.c: Change commentsZhichao Gao2019-04-281-4/+1
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460 Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific or not. So change the comments of NvmeShutdownAllControllers. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Michael Turner <Michael.Turner@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/PciBusDxe: dispatch option ROMs for foreign architecturesArd Biesheuvel2019-04-141-7/+0
| | | | | | | | | | | Delete the explicit machine type check for option ROM images, and instead, rely on the LoadImage() boot service to decide whether an option ROM can be dispatched or not. This permits platforms to ship with emulators to execute option ROMs that are not native to the processor architecture. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-09196-1411/+196
| | | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Add V3 64b DMA SupportAshish Singhal2019-03-114-73/+161
| | | | | | | | | | | | | | Driver was supporting only 32b DMA support for V3 controllers. Add support for 64b DMA as well for completeness. For V4.0 64b support, driver was looking at incorrect capability register bit. Fix for that is present as well. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1583 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com> Tested-by: Eugene Cohen <eugene@hp.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList LockBoxHao Wu2019-02-225-1/+236
| | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409 For the NvmExpressPei driver, this commit will update the driver to consume the S3StorageDeviceInitList LockBox in S3 phase. The purpose is to perform an on-demand (partial) NVM Express device enumeration/initialization to benefit the S3 resume performance. Cc: Jian J Wang <jian.j.wang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/NvmExpressPei: Add logic to produce SSC PPIHao Wu2019-02-228-89/+1075
| | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409 For the NvmExpressPei driver, this commit will add codes to produce the Storage Security Command PPI if the underlying NVM Express controller supports the Security Send and Security Receive commands. Cc: Jian J Wang <jian.j.wang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/NvmExpressPei: Avoid updating the module-level variableHao Wu2019-02-223-84/+92
| | | | | | | | | | | | | | | This commit is out of the scope for BZ-1409. The commit will remove the call of RegisterForShadow() at the entry point of the driver. By doing so, the driver is now possible to be executed without being re-loaded into permanent memory. Thus, this commit will update the NvmExpressPei driver to avoid updating the content of a global variable. Cc: Jian J Wang <jian.j.wang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widthsEdgar Handal2019-02-201-4/+21
| | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1537 Use 16-bit and 32-bit IO widths for SDMMC MMIO to prevent all register accesses from being split up into 8-bit accesses. The SDHCI specification states that the registers shall be accessible in byte, word, and double word accesses. (SD Host Controller Simplified Specification 4.20 Section 1.2) Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jeff Brasen <jbrasen@nvidia.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/SdMmcPciHcDxe Fix eMMC HS400 switch sequenceAlbecki, Mateusz2019-02-201-16/+17
| | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140 In eMMC HS400 switch sequence flow eMMC driver attempted to execute SEND_STATUS just after switching bus timing to high speed and before downgrading clock frequency to 52MHz. Since link was at that time in incorrect state SEND_STATUS was failing which made driver think switch to HS400 failed. This change makes driver always change clock frequency after switching bus timing and before executing SEND_STATUS. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Albecki Mateusz <mateusz.albecki@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/PciBus: Fix a bug PPB MEM32 BAR isn't restored sometimesRay Ni2019-02-141-28/+23
| | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1505 When a device under PPB contains option ROM but doesn't require 32bit MMIO, ProgrameUpstreamBridgeForRom() cannot correctly restore the PPB MEM32 RANGE BAR. It causes the 32bit MMIO conflict which may cause system hangs in boot. The root cause is when ProgrameUpstreamBridgeForRom() calls ProgramPpbApperture() to restore the PPB MEM32 RANGE BAR, the ProgramPpbApperture() skips to program the BAR when the resource length is 0. This patch fixes this issue by not calling ProgramPpbApperture(). Instead, it directly programs the PPB MEM32 RANGE BAR. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> Cc: Dandan Bi <dandan.bi@intel.com>
* MdeModulePkg/PciBus: Correct typosRay Ni2019-02-1420-156/+154
| | | | | | Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/PciBus: Change PCI_IO_DEVICE.RomSize to UINT32 typeRay Ni2019-02-145-13/+13
| | | | | | | | | Per PCI Spec, the option ROM BAR is 32bit so the maximum option ROM size can be hold by UINT32 type. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/NvmExpressDxe: Report StatusCode for device init failureSean Brogan2019-02-133-3/+13
| | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1408 According to the information of the above BZ-1408 and other platform owners, NVM Express devices are becoming more likely to be a critical part during the boot process. This commit will add the calls to 'REPORT_STATUS_CODE' when there is a failure happens during the NVM Express controller/device initialization process. Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <brbarkel@microsoft.com> Cc: Jian J Wang <jian.j.wang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Update comment for spec compliance statusHao Wu2019-02-014-8/+14
| | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1441 This commit will update the file-level comments within the SdMmcPciHcDxe to reflect the latest specification compliance status of the driver. Cc: Ray Ni <ray.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg/NonDiscoverablePciDevice: Remove the redundant checkDandan Bi2019-01-081-5/+3
| | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1422 if (Attributes) { if ((Attributes & (~(DEV_SUPPORTED_ATTRIBUTES))) != 0) { return EFI_UNSUPPORTED; } } In above code block, "If ((Attributes & (~(DEV_SUPPORTED_ATTRIBUTES))) != 0)" is TRUE, the Attributes must be not 0. So we can remove the redundant check "if (Attributes)". Cc: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT build failureHao Wu2019-01-051-4/+4
| | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1425 This commit will resolve the VS2015 IA32 NOOPT build failure within SdMmcPciHcDxe. More specifically, this commit will use BaseLib API RShiftU64() to perform right-shift operations for UINT64 type operators. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Bi Dandan <dandan.bi@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Add SDMMC HC v4 and above Support.Ashish Singhal2019-01-036-83/+366
| | | | | | | | | | | | | | | | | | | | | | Add SDMA, ADMA2 and 26b data length support. If V4 64 bit address mode is supported in capabilities register, program controller to enable V4 host mode and use appropriate SDMA registers supporting 64 bit addresses. If V4 64 bit address mode is supported in capabilities register, program controller to enable V4 host mode and use appropriate ADMA descriptors supporting 64 bit addresses. If host controller version is above V4.0, enable ADMA2 with 26b data length support for better performance. HC 2 register is configured to use 26 bit data lengths and ADMA2 descriptors are configured appropriately. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1359 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/PciBus: Fix system hang when no PCI Option ROM existsRuiyu Ni2018-12-171-4/+6
| | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1394 When there is no PCI option ROM exists, today's logic still creates virtual BAR for option ROM using Length = 0, Alignment = (-1). It causes the final MEM32 alignment requirement is as big as 0xFFFFFFFF_FFFFFFFF. The patch fixes this issue by only creating virtual BAR for option ROM when there is PCI option ROM. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Chiu Chasel <chasel.chiu@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* MdeModulePkg/NonDiscoverablePciDeviceDxe: add missing validationVladimir Olovyannikov2018-12-171-1/+49
| | | | | | | | | | UEFI SCT crashed and failed in NonDiscoverablePciDeviceDxe becase required checks were not performed. Perform parameters validation in NonDiscoverablePciDeviceDxe. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
* MdeModulePkg/PciBus: Shadow option ROM after BARs are programmedRuiyu Ni2018-12-104-62/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1376 Today's implementation reuses the 32bit MMIO resource requested by all PCI devices MMIO BARs when shadowing the option ROM. Take a simple example, a system has only one PCI device. It requires 8MB 32bit MMIO and contains a 4MB option ROM. Today's implementation only requests 8MB (max of 4M and 8M) 32bit MMIO from PciHostBridgeResourceAllocation protocol. Let's assume the MMIO range [3GB, 3GB+8MB) is allocated. The 3GB base address is firstly programmed to the option ROM BAR for option ROM shadow. Then the option ROM decoding is turned off and 3GB base address is programmed to the 32bit MMIO BAR. It doesn't cause issues when the device doesn't request too much MMIO. But when the device contains a 64bit MMIO BAR which requests 4GB MMIO and a 4MB option ROM. Let's assume [3GB, 3GB+8MB) 32bit MMIO range is allocated for the option ROM. When the option ROM is being shadowed, 64bit MMIO BAR is programmed to value 0, which means [0, 4GB) MMIO is given to the 64bit BAR. The range overlaps with the option ROM range which may cause the device malfunction (e.g.: option ROM cannot be read out) when the device has two separate decoders: one for MMIO BAR, the other for option ROM. The patch requests dedicated MEM32 resource for Option ROMs and moves the Option ROM shadow logic after all MMIO BARs are programmed. The MMIO BAR setting to 0 when shadowing Option ROM is also skipped because the MMIO BAR already contains the correct value. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Allow overriding base clock frequencyMarcin Wojtas2018-11-206-20/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some SdMmc host controllers are run by clocks with different frequency than it is reflected in Capabilities Register 1. It is allowed by SDHCI specification ver. 4.2 - if BaseClkFreq field value of the Capability Register 1 is zero, the clock frequency must be obtained via another method. Because the bitfield is only 8 bits wide, a maximum value that could be obtained from hardware is 255MHz. In case the actual frequency exceeds 255MHz, the 8-bit BaseClkFreq member of SD_MMC_HC_SLOT_CAP structure occurs to be not sufficient to be used for setting the clock speed in SdMmcHcClockSupply function. This patch adds new UINT32 array ('BaseClkFreq[]') to SD_MMC_HC_PRIVATE_DATA structure for specifying the input clock speed for each slot of the host controller. All routines that are used for clock configuration are updated accordingly. This patch also adds new IN OUT BaseClockFreq field in the Capability callback of the SdMmcOverride, protocol which allows to update BaseClkFreq value. The patch reuses original commit from edk2-platforms: 20f6f144d3a8 ("Marvell/Drivers: XenonDxe: Allow overriding base clock frequency") Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marcin Wojtas <mw@semihalf.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Add SwitchClockFreqPost to SdMmcOverrideTomasz Michalec2018-11-202-4/+45
| | | | | | | | | | | | | Some SD Host Controlers need to do additional operations after clock frequency switch. This patch add new callback type to NotifyPhase of the SdMmcOverride protocol. It is called after SdMmcHcClockSupply. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marcin Wojtas <mw@semihalf.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Add UhsSignaling to SdMmcOverride protocolTomasz Michalec2018-11-204-60/+164
| | | | | | | | | | | | | | | Some SD Host Controllers use different values in Host Control 2 Register to select UHS Mode. This patch adds a new UhsSignaling type routine to the NotifyPhase of the SdMmcOverride protocol. UHS signaling configuration is moved to a common, default routine (SdMmcHcUhsSignaling). After it is executed, the protocol producer can override the values if needed. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marcin Wojtas <mw@semihalf.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Add an optional parameter in NotifyPhaseMarcin Wojtas2018-11-201-4/+8
| | | | | | | | | | | | | In order to ensure bigger flexibility in the NotifyPhase routine of the SdMmcOverride protocol, enable using an optional phase-specific data. This will allow to exchange more information between the protocol producer driver and SdMmcPciHcDxe in the newly added callbacks. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marcin Wojtas <mw@semihalf.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/NvmExpressPei: Refine data buffer & len check in PassThruHao Wu2018-11-131-15/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1142 The fix is similar to commit ebb6c7633bca47fcd5b460a67e18e4a717ea91cc. We found that a similar fix should be applied to the NVMe PEI driver as well. Hence, this one is for the PEI counterpart driver. According to the the NVM Express spec Revision 1.1, for some commands (like Get/Set Feature Command, Figure 89 & 90 of the spec), the Memory Buffer maybe optional although the command opcode indicates there is a data transfer between host & controller (Get/Set Feature Command, Figure 38 of the spec). Hence, this commit refine the checks for the 'TransferLength' and 'TransferBuffer' field of the EDKII_PEI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET structure to address this issue. Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jiewen Yao <Jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* Revert "XhciDxe: Use common buffer for AsyncInterruptTransfer"Star Zeng2018-11-073-63/+103
| | | | | | | | | | | | There is concern at the thread https://lists.01.org/pipermail/edk2-devel/2018-November/031951.html. And the time point is a little sensitive as it is near edk2-stable201811. This reverts commit 777920997152a2e68f664241f6080b64ff21edd6. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* Revert "EhciDxe: Use common buffer for AsyncInterruptTransfer"Star Zeng2018-11-074-57/+95
| | | | | | | | | | | | There is concern at the thread https://lists.01.org/pipermail/edk2-devel/2018-November/031951.html. And the time point is a little sensitive as it is near edk2-stable201811. This reverts commit 0cd645250306b244a5d6e0e293ed1786ec101641. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* MdeModulePkg EhciDxe: Use common buffer for AsyncInterruptTransferStar Zeng2018-10-284-95/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1274 In current code, EhcMonitorAsyncRequests (timer handler) will do unmap and map operations for AsyncIntTransfers to "Flush data from PCI controller specific address to mapped system memory address". EhcMonitorAsyncRequests EhcFlushAsyncIntMap PciIo->Unmap IoMmu->SetAttribute PciIo->Map IoMmu->SetAttribute This may impact the boot performance. Since the data buffer for EhcMonitorAsyncRequests is internal buffer, we can allocate common buffer by PciIo->AllocateBuffer and map the buffer with EfiPciIoOperationBusMasterCommonBuffer, then the unmap and map operations can be removed. /// /// Provides both read and write access to system memory by /// both the processor and a bus master. The buffer is coherent /// from both the processor's and the bus master's point of view. /// EfiPciIoOperationBusMasterCommonBuffer, Test done: USB KB works normally. USB disk read/write works normally. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg XhciDxe: Use common buffer for AsyncInterruptTransferStar Zeng2018-10-283-103/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V3: Call XhcFreeUrb after XhcCreateTransferTrb fails in XhcCreateTrb. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1274 In current code, XhcMonitorAsyncRequests (timer handler) will do unmap and map operations for AsyncIntTransfers to "Flush data from PCI controller specific address to mapped system memory address". XhcMonitorAsyncRequests XhcFlushAsyncIntMap PciIo->Unmap IoMmu->SetAttribute PciIo->Map IoMmu->SetAttribute This may impact the boot performance. Since the data buffer for XhcMonitorAsyncRequests is internal buffer, we can allocate common buffer by PciIo->AllocateBuffer and map the buffer with EfiPciIoOperationBusMasterCommonBuffer, then the unmap and map operations can be removed. /// /// Provides both read and write access to system memory by /// both the processor and a bus master. The buffer is coherent /// from both the processor's and the bus master's point of view. /// EfiPciIoOperationBusMasterCommonBuffer, Test done: USB KB works normally. USB disk read/write works normally. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg EhciDxe: Extract new EhciInsertAsyncIntTransfer functionStar Zeng2018-10-283-25/+111
| | | | | | | | | | | | | | | | | | | | | | | | | V3: Match function parameter name and description between EhciSched.c and EhciSched.h. V2: Add the missing "gBS->FreePool (Data);". REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1274 Extract new EhciInsertAsyncIntTransfer function from EhcAsyncInterruptTransfer. It is code preparation for following patch, no essential functional change. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg XhciDxe: Extract new XhciInsertAsyncIntTransfer functionStar Zeng2018-10-283-17/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | V3: Match function parameter name and description between XhciSched.c and XhciSched.h. V2: Add the missing "FreePool (Data);". Remove the unnecessary indentation change. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1274 Extract new XhciInsertAsyncIntTransfer function from XhcAsyncInterruptTransfer. It is code preparation for following patch, no essential functional change. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/NvmExpressDxe: Refine PassThru IO queue creation behaviorHao Wu2018-10-253-9/+29
| | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1260 For the PassThru() service of NVM Express Pass Through Protocol, the current implementation (function NvmExpressPassThru()) will only use the IO Completion/Submission queues created internally by this driver during the controller initialization process. Any other IO queues created will not be consumed. So the value is little to accept external IO Completion/Submission queue creation request. This commit will refine the behavior of function NvmExpressPassThru(), it will only accept driver internal IO queue creation commands and will return "EFI_UNSUPPORTED" for external ones. Cc: Jiewen Yao <Jiewen.yao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* MdeModulePkg/NvmExpressDxe: Always copy CQ entry to PassThru packetHao Wu2018-10-251-5/+4
| | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1259 According to the the NVM Express spec Revision 1.1, for some commands, command-related information will be stored in the Dword 0 of the completion queue entry. One case is for the Get Features Command (Section 5.9.2 of the spec), Dword 0 of the completion queue entry may contain feature information. Hence, this commit will always copy the content of completion queue entry to the PassThru packet regardless of the execution result of the command. Cc: Liangcheng Tang <liangcheng.tang@intel.com> Cc: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* MdeModulePkg/NvmExpressDxe: Refine data buffer & len check in PassThruHao Wu2018-10-251-15/+18
| | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1142 According to the the NVM Express spec Revision 1.1, for some commands (like Get/Set Feature Command, Figure 89 & 90 of the spec), the Memory Buffer maybe optional although the command opcode indicates there is a data transfer between host & controller (Get/Set Feature Command, Figure 38 of the spec). Hence, this commit refine the checks for the 'TransferLength' and 'TransferBuffer' field of the EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET structure to address this issue. Cc: Liangcheng Tang <liangcheng.tang@intel.com> Cc: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* MdeModulePkg Xhci: Handle value 5 in Port Speed field of PORTSCStar Zeng2018-10-234-8/+12
| | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1267 The value 5 Port Speed field of PORTSC is new defined in XHCI 1.1 spec November 2017. This patch updates XhciDxe and XhciPei to handle it, otherwise the USB 3.1 device may not be recognized with the XHCI controller following XHCI 1.1 spec November 2017. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* MdeModulePkg XhciDxe: Assign Usb2Hc.XXXRevision based on SBRNStar Zeng2018-10-232-0/+16
| | | | | | | | | | | | | | Current hard code Usb2Hc.XXXRevision may be not accurate. This patch updates code to assign Usb2Hc.XXXRevision based on SBRN (Serial Bus Release Number, PCI configuration space offset 0x60) although there is no code consuming them. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
* MdeModulePkg/Usb: Make sure data from HW is no more than expectedRuiyu Ni2018-10-173-9/+16
| | | | | | | | | | Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Allow additional SDHCI versionsJeff Brasen2018-10-122-2/+4
| | | | | | | | | | | | | | Clock control is similar in SDHCI versions greater then version 2. Add support for more recent versions of the controller specification. SD card support for 1.8V is also present in controller versions 3 and greater. https://bugzilla.tianocore.org/show_bug.cgi?id=1233 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jeff Brasen <jbrasen@nvidia.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/SdMmcPciHcDxe: Add controller version definesJeff Brasen2018-10-123-3/+13
| | | | | | | | | | | | Add SDHCI controller defines, this is useful as the version in the register does not explictly map to a specification version. For example vesion 4.10 of the specification is version 0x04. https://bugzilla.tianocore.org/show_bug.cgi?id=1233 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jeff Brasen <jbrasen@nvidia.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
* MdeModulePkg/NonDiscoverablePciDeviceDxe: expose unique B/D/F identifiersArd Biesheuvel2018-10-103-3/+23
| | | | | | | | | | | | | | | | | | | | Currently, the implementation of EFI_PCI_IO_PROTOCOL::GetLocation() in NonDiscoverablePciDeviceDxe returns the same set of dummy values for each instance of the NON_DISCOVERABLE_DEVICE protocol that it attaches itself to. However, this turns out to be causing problems in cases where software (such as the ARM Compliance Test Suite [ACS]) attempts to use these values to uniquely identify controllers, since the collisions create ambiguity in this regard. So let's modify GetLocation() to return an arbitrary bus/device tuple on segment 0xff instead. This is guaranteed not to clash with other non-discoverable PCI devices, and highly unlikely to clash with real PCIe devices. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Marcin Wojtas <mw@semihalf.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
* MdeModulePkg/PciHostBridge: Move declaration of mIoMmu to header fileRuiyu Ni2018-09-264-34/+34
| | | | | | | | | | | | The change doesn't have functionality impact. It just renames the mIoMmuProtocol to mIoMmu and moves the declaration from PciRootBridgeIo.c to PciHostBridge.h. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Suggested-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* MdeModulePkg/PciHostBridge: Add RESOURCE_VALID() to simplify codeRuiyu Ni2018-09-261-14/+12
| | | | | | | | Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Garrett Kirkendall <garrett.kirkendall@amd.com>
* MdeModulePkg/PciHostBridge: Fix a bug that prevents PMEM accessRuiyu Ni2018-09-261-4/+10
| | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1196 RootBridgeIoCheckParameter() verifies that the requested MMIO access can fit in any of the MEM/PMEM 32/64 ranges. But today's logic somehow only checks the requested access against MEM 32/64 ranges. It should also check the requested access against PMEM 32/64 ranges. The patch fixes this issue. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Garrett Kirkendall <garrett.kirkendall@amd.com>
* MdeModulePkg/PciHostBridge: Enhance boundary check in Io/Mem.Read/WriteRuiyu Ni2018-09-261-5/+23
| | | | | | | | Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Garrett Kirkendall <garrett.kirkendall@amd.com>
* MdeModulePkg: XhciDxe: Prevent illegal memory access in XhcSetHseeMarcin Wojtas2018-09-261-1/+1
| | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1206 Newly added XhcSetHsee() routine reads 4 bytes into a UINT16 variable causing issues on PCIE and NonDiscoverable Xhci controllers. Fix that. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Fei1 Wang <fei1.wang@intel.com> Cc: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marcin Wojtas <mw@semihalf.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-30 23:02:53 +0000