public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ni, Ray" <ray.ni@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"Javeed, Ashraf" <ashraf.javeed@intel.com>
Cc: "Wang, Jian J" <jian.j.wang@intel.com>, "Wu, Hao A" <hao.a.wu@intel.com>
Subject: Re: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH 14/15] MdeModulePkg/PciBusDxe: Enable ExtendedTag feature
Date: Wed, 13 May 2020 08:09:50 +0000	[thread overview]
Message-ID: <734D49CCEBEEF84792F5B80ED585239D5C53B0B6@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <20200510161412.13832-15-ashraf.javeed@intel.com>

> +
> +  //
> +  // BIT0 of the policy value is for 5b or 8b Extended Tag (DeviceControl BIT8)
> +  // BIT1 of the policy value is for 10b Extended Tag (DeviceControl2 BIT12)
> +  //
> +  if ((PciIoDevice->DeviceState.ExtendedTag >> 2) != 0) {
> +    return EFI_INVALID_PARAMETER;
> +  }

Because there is a separate routine to formalize all policy values, this parameter check may be unnecessary.
Similar comments apply to all the scan/program routines for different features.
What do you think?


> +  //
> +  // the device should be capable of 10b Extended Tag Requester
> +  //
> +  if ((PciIoDevice->DeviceState.ExtendedTag & BIT1) &&
> +      (PciIoDevice->PciExpressCapability.DeviceCapability2.Bits.TenBitTagRequesterSupported)) {
> +    //
> +    // for the Endpoint device 10b Extended Tag Requester Enable, the RC should be
> +    // 10b Completer capable
> +    //
> +    if (PciIoDevice->PciExpressCapability.Capability.Bits.DevicePortType == PCIE_DEVICE_PORT_TYPE_PCIE_ENDPOINT ||
> +        PciIoDevice->PciExpressCapability.Capability.Bits.DevicePortType ==
> PCIE_DEVICE_PORT_TYPE_LEGACY_PCIE_ENDPOINT) {
> +      //
> +      // check the parent Root Port 10b Extended Tag Completer Capability
> +      //
> +      TenBitCompleterCapable = *Context;
> +      if (*TenBitCompleterCapable == TRUE) {
> +        //
> +        // since the RC is 10b COmpleter capable, enable the EP as 10b Requester
> +        //
> +        DeviceCtl2.Bits.TenBitTagRequesterEnable = 1;


I read through PCIE spec 5.0 chapter 2.2.6.2 but cannot find any statement that says:
Enable EP only when RP supports.

My understanding is:
Each EP can have its own 8-bit/10-bit enable setting.
Can you please help to explain?

> +      }
> +    } else {
> +      //
> +      // enable the device as 10b Requester if it is capable and per platform ask
> +      //
> +      DeviceCtl2.Bits.TenBitTagRequesterEnable = 1;

My understanding is for switches, the enable is not necessary.
Because spec says switches forward the request without modifying the Transaction ID.

> +
> +  //
> +  // if no 10b Extended Tag Requester for this device than consider 8b or 5b Extended Requester
> +  //
> +  if (!DeviceCtl2.Bits.TenBitTagRequesterEnable) {
> +    //
> +    // the device should be capable of 8b Extended Tag Requester
> +    //
> +    DeviceCtl.Bits.ExtendedTagField = (UINT16)
> +              ((PciIoDevice->DeviceState.ExtendedTag & BIT0) &&
> +               (PciIoDevice->PciExpressCapability.DeviceCapability.Bits.ExtendedTagField));

Why you don't check the RP's capability for 8bit case?


  reply	other threads:[~2020-05-13  8:09 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200510161412.13832-1-ashraf.javeed@intel.com>
2020-05-10 16:13 ` [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH 01/15] MdePkg/Protocols: Deprecated the EFI encoded macros Javeed, Ashraf
2020-05-13  8:21   ` Ni, Ray
2020-05-10 16:13 ` [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH 02/15] MdeModulePkg/PciBusDxe: PciBusDxe Code refactor Javeed, Ashraf
2020-05-13  6:31   ` Ni, Ray
2020-05-10 16:14 ` [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH 03/15] MdeModulePkg/PciBus: Rename Cache PCIe Capability Structure Javeed, Ashraf
2020-05-13  6:31   ` Ni, Ray
2020-05-10 16:14 ` [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH 04/15] MdeModulePkg/PciBusDxe: Refactor the PCIe Bridge enable Javeed, Ashraf
2020-05-13  6:31   ` Ni, Ray
2020-05-10 16:14 ` [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH 05/15] MdeModulePkg/PciBusDxe: Locate PciePlatform/PcieOverride protocol Javeed, Ashraf
2020-05-13  6:31   ` Ni, Ray
2020-05-10 16:14 ` [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH 06/15] MdeModulePkg/PciBusDxe: Add the framework to init PCIe features Javeed, Ashraf
2020-05-13  6:39   ` Ni, Ray
2020-05-13  6:46     ` Javeed, Ashraf
2020-05-10 16:14 ` [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH 07/15] MdeModulePkg/PciBusDxe: Enable MaxPayloadSize feature Javeed, Ashraf
2020-05-13  6:45   ` Ni, Ray
2020-05-13  6:54     ` Javeed, Ashraf
2020-05-10 16:14 ` [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH 08/15] MdeModulePkg/PciBusDxe: Enable MaxReadRequestSize feature Javeed, Ashraf
2020-05-13  6:49   ` Ni, Ray
2020-05-10 16:14 ` [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH 09/15] MdeModulePkg/PciBusDxe: Enable RelaxedOrdering feature Javeed, Ashraf
2020-05-13  6:49   ` Ni, Ray
2020-05-10 16:14 ` [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH 10/15] MdeModulePkg/PciBusDxe: Enable NoSnoop feature Javeed, Ashraf
2020-05-13  6:49   ` Ni, Ray
2020-05-10 16:14 ` [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH 11/15] MdeModulePkg/PciBusDxe: Enable CompletionTimeout feature Javeed, Ashraf
2020-05-13  6:49   ` Ni, Ray
2020-05-10 16:14 ` [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH 12/15] MdeModulePkg/PciBusDxe: Enable LTR feature Javeed, Ashraf
2020-05-13  6:49   ` Ni, Ray
2020-05-13  7:10     ` Javeed, Ashraf
2020-05-10 16:14 ` [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH 13/15] MdeModulePkg/PciBusDxe: Enable AtomicOp feature Javeed, Ashraf
2020-05-13  6:51   ` [edk2-devel] " Ni, Ray
2020-05-10 16:14 ` [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH 14/15] MdeModulePkg/PciBusDxe: Enable ExtendedTag feature Javeed, Ashraf
2020-05-13  8:09   ` Ni, Ray [this message]
2020-05-10 16:14 ` [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH 15/15] MdeModulePkg/PciBusDxe: Enable CommonClockConfiguration feature Javeed, Ashraf
2020-05-13  8:19   ` Ni, Ray

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=734D49CCEBEEF84792F5B80ED585239D5C53B0B6@SHSMSX104.ccr.corp.intel.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