From: "Jeremy Linton" <jeremy.linton@arm.com>
To: Andrei Warkentin <awarkentin@vmware.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: "pete@akeo.ie" <pete@akeo.ie>,
"ardb+tianocore@kernel.org" <ardb+tianocore@kernel.org>,
"Sunny.Wang@arm.com" <Sunny.Wang@arm.com>,
"samer.el-haj-mahmoud@arm.com" <samer.el-haj-mahmoud@arm.com>,
"René Treffer" <treffer+groups.io@measite.de>
Subject: Re: [edk2-devel] [PATCH 4/5] Silicon/Broadcom/Bcm27xx: Tweak PCIe for CM4
Date: Fri, 6 Aug 2021 16:52:56 -0500 [thread overview]
Message-ID: <5ba43be0-be84-e2fa-f7c7-353e870435c7@arm.com> (raw)
In-Reply-To: <PH0PR05MB8702E31339A2A814120A4062B9F39@PH0PR05MB8702.namprd05.prod.outlook.com>
Hi,
On 8/6/21 11:04 AM, Andrei Warkentin wrote:
> Ok, I misunderstood the patch set (I thought the PciHostBridgeLib itself would eventually move to DEN0115).
>
> I still think that (in general) would be a good idea - if not for the benefit of the Pi, then for the next upstreamed platform where you could avoid implementing custom config access code...
Right, the only bit that goes away is the PciSegmentLibGetConfigBase()
code to be replaced by the SMC call. Which I will do, but I think its
better to fix to this one and make that a separate patch-set ideally
with another platform in parallel.
>
> Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
>
> --
> Andrei Warkentin,
> Arm Enablement Architect,
> Cloud Platform Business Unit, VMware
> ________________________________
> From: Andrei Warkentin <awarkentin@vmware.com>
> Sent: Friday, August 6, 2021 7:02 PM
> To: devel@edk2.groups.io <devel@edk2.groups.io>; jeremy.linton@arm.com <jeremy.linton@arm.com>
> Cc: pete@akeo.ie <pete@akeo.ie>; ardb+tianocore@kernel.org <ardb+tianocore@kernel.org>; Sunny.Wang@arm.com <Sunny.Wang@arm.com>; samer.el-haj-mahmoud@arm.com <samer.el-haj-mahmoud@arm.com>; René Treffer <treffer+groups.io@measite.de>
> Subject: Re: [edk2-devel] [PATCH 4/5] Silicon/Broadcom/Bcm27xx: Tweak PCIe for CM4
>
> Hi Jeremy,
>
> Is any of this still conceptually necessary if we adopt the SMCCC interface within UEFI?
>
> Instead of assuming the first downstream bus is bus 1, could you read the secondary BN from the RP?
>
> --
> Andrei Warkentin,
> Arm Enablement Architect,
> Cloud Platform Business Unit, VMware
> ________________________________
> From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Jeremy Linton via groups.io <jeremy.linton=arm.com@groups.io>
> Sent: Thursday, August 5, 2021 7:35 PM
> To: devel@edk2.groups.io <devel@edk2.groups.io>
> Cc: pete@akeo.ie <pete@akeo.ie>; ardb+tianocore@kernel.org <ardb+tianocore@kernel.org>; Andrei Warkentin <awarkentin@vmware.com>; Sunny.Wang@arm.com <Sunny.Wang@arm.com>; samer.el-haj-mahmoud@arm.com <samer.el-haj-mahmoud@arm.com>; Jeremy Linton <jeremy.linton@arm.com>; René Treffer <treffer+groups.io@measite.de>
> Subject: [edk2-devel] [PATCH 4/5] Silicon/Broadcom/Bcm27xx: Tweak PCIe for CM4
>
> The CM4 has an actual pcie slot, so we need to move the linkup
> check to the configuration probe logic. Further the device
> restriction logic needs to be relaxed to support downstream
> PCIe switches.
>
> Suggested-by: René Treffer <treffer+groups.io@measite.de>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
> .../Bcm2711PciHostBridgeLibConstructor.c | 5 -----
> .../Library/Bcm2711PciSegmentLib/PciSegmentLib.c | 24 +++++++++++++++-------
> 2 files changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/Silicon/Broadcom/Bcm27xx/Library/Bcm2711PciHostBridgeLib/Bcm2711PciHostBridgeLibConstructor.c b/Silicon/Broadcom/Bcm27xx/Library/Bcm2711PciHostBridgeLib/Bcm2711PciHostBridgeLibConstructor.c
> index 8587d2d36d..4d4c584726 100644
> --- a/Silicon/Broadcom/Bcm27xx/Library/Bcm2711PciHostBridgeLib/Bcm2711PciHostBridgeLibConstructor.c
> +++ b/Silicon/Broadcom/Bcm27xx/Library/Bcm2711PciHostBridgeLib/Bcm2711PciHostBridgeLibConstructor.c
> @@ -204,11 +204,6 @@ Bcm2711PciHostBridgeLibConstructor (
> } while (((Data & 0x30) != 0x030) && (Timeout));
> DEBUG ((DEBUG_VERBOSE, "PCIe link ready (status=%x) Timeout=%d\n", Data, Timeout));
>
> - if ((Data & 0x30) != 0x30) {
> - DEBUG ((DEBUG_ERROR, "PCIe link not ready (status=%x)\n", Data));
> - return EFI_DEVICE_ERROR;
> - }
> -
> if ((Data & 0x80) != 0x80) {
> DEBUG ((DEBUG_ERROR, "PCIe link not in RC mode (status=%x)\n", Data));
> return EFI_UNSUPPORTED;
> diff --git a/Silicon/Broadcom/Bcm27xx/Library/Bcm2711PciSegmentLib/PciSegmentLib.c b/Silicon/Broadcom/Bcm27xx/Library/Bcm2711PciSegmentLib/PciSegmentLib.c
> index 44ce3b4b99..3ccc131eab 100644
> --- a/Silicon/Broadcom/Bcm27xx/Library/Bcm2711PciSegmentLib/PciSegmentLib.c
> +++ b/Silicon/Broadcom/Bcm27xx/Library/Bcm2711PciSegmentLib/PciSegmentLib.c
> @@ -78,6 +78,8 @@ PciSegmentLibGetConfigBase (
> UINT64 Base;
> UINT64 Offset;
> UINT32 Dev;
> + UINT32 Bus;
> + UINT32 Data;
>
> Base = PCIE_REG_BASE;
> Offset = Address & 0xFFF; /* Pick off the 4k register offset */
> @@ -89,17 +91,25 @@ PciSegmentLibGetConfigBase (
> Base += PCIE_EXT_CFG_DATA;
> if (mPciSegmentLastAccess != Address) {
> Dev = EFI_PCI_ADDR_DEV (Address);
> + Bus = EFI_PCI_ADDR_BUS (Address);
> +
> /*
> - * Scan things out directly rather than translating the "bus" to a device, etc..
> - * only we need to limit each bus to a single device.
> + * There can only be a single device on bus 1 (downstream of root).
> + * Subsequent busses (behind a PCIe switch) can have more.
> */
> - if (Dev < 1) {
> - MmioWrite32 (PCIE_REG_BASE + PCIE_EXT_CFG_INDEX, Address);
> - mPciSegmentLastAccess = Address;
> - } else {
> - mPciSegmentLastAccess = 0;
> + if (Dev > 0 && (Bus < 2)) {
> return 0xFFFFFFFF;
> }
> +
> + /* Don't probe slots if the link is down */
> + Data = MmioRead32 (PCIE_REG_BASE + PCIE_MISC_PCIE_STATUS);
> + if ((Data & 0x30) != 0x30) {
> + DEBUG ((DEBUG_ERROR, "PCIe link not ready (status=%x)\n", Data));
> + return 0xFFFFFFFF;
> + }
> +
> + MmioWrite32 (PCIE_REG_BASE + PCIE_EXT_CFG_INDEX, Address);
> + mPciSegmentLastAccess = Address;
> }
> }
> return Base + Offset;
> --
> 2.13.7
>
>
>
>
>
>
>
next prev parent reply other threads:[~2021-08-06 21:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-05 16:35 [PATCH 0/5] RPi4: Enable ACPI PCIe conduit Jeremy Linton
2021-08-05 16:35 ` [PATCH 1/5] Platform/RaspberryPi: Add XHCI/PCI selection menu Jeremy Linton
2021-08-05 16:35 ` [PATCH 2/5] Platform/RaspberryPi: break XHCI into its own SSDT Jeremy Linton
2021-08-06 15:50 ` [edk2-devel] " Andrei Warkentin
2021-08-05 16:35 ` [PATCH 3/5] Platform/RaspberryPi: Add PCIe SSDT Jeremy Linton
2021-08-06 13:42 ` Ard Biesheuvel
2021-08-06 21:35 ` [edk2-devel] " Jeremy Linton
2021-08-06 15:37 ` Andrei Warkentin
2021-08-06 21:31 ` Jeremy Linton
2021-08-05 16:35 ` [PATCH 4/5] Silicon/Broadcom/Bcm27xx: Tweak PCIe for CM4 Jeremy Linton
2021-08-06 13:42 ` Ard Biesheuvel
2021-08-06 14:06 ` Jeremy Linton
2021-08-06 16:02 ` [edk2-devel] " Andrei Warkentin
2021-08-06 16:04 ` Andrei Warkentin
2021-08-06 21:52 ` Jeremy Linton [this message]
2021-08-05 16:35 ` [PATCH 5/5] Platform/RaspberryPi: Enable NVMe boot on cm4 Jeremy Linton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5ba43be0-be84-e2fa-f7c7-353e870435c7@arm.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox