public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Eric Song <EricSong@zhaoxin.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: Tiger Liu <TigerLiu@zhaoxin.com>, "Ni, Ruiyu" <ruiyu.ni@intel.com>
Subject: Re: PCI bus do 2 Enumeration when 2 root bridges under 1 host bridge
Date: Thu, 17 Aug 2017 11:18:48 +0200	[thread overview]
Message-ID: <2915a7f4-3f13-f16f-cf36-03a90ed0a681@redhat.com> (raw)
In-Reply-To: <41761EF483901349B2FAB9B696E9F0B905066FC3@ZXBJMBX01.zhaoxin.com>

Adding Ray

On 08/17/17 06:50, Eric Song wrote:
> Hi, experts
> If there is 2 root bridges under 1 host bridge on the PCI hierarchy,
> whether EDK2 Pci bus driver can support it ? the answer is YES, but
> some confused things in it.
>
> 1)       On BDS phase, ConnectController is called for every root
> bridge, so Pci bus start() will be called for every root bridge.
>
>   VisitAllInstancesOfProtocol (&gEfiPciRootBridgeIoProtocolGuid, ConnectRootBridge, NULL);
>
> 2)       In PCI bus driver, Pci start() will do enumeration on the
> entire host bridge
>
> PciEnumerator()->PciHostBridgeEnumerator->\x1dPciResAlloc->GetNextRootBridge()
>
> That means Do enumeration on entire host bridge for every one root
> bridge. So there are 2 enumerations on entire host bridge for my PCI
> hierarchy.
> What I confused is why do 2 enumerations on entire host bridge by
> every one root bridge. Since BDS connect controller by one root bridge
> , Pci bus driver should enumerate corresponding root bridge, But it do
> the entire host bridge which is the parent of the root bridge. Or BDS
> should connect controller by one host bridge, then it will match the
> pci bus driver \x18s enumeration policy. In a word, I think it is
> illogical for current EDKII code.
>
> Well, the current code execution will do 2 enumerations on host bridge
> for 2 root bridges under 1 host bridge. Even though 2rd enumeration
> would be not full enumeration, but do PciEnumeratorLight(), I think it
> is still not necessary. Whether there is any side effect ? In another
> word, current PCI bus driver enumeration can\x19t be Suitable for 2
> root bridges under 1 host bridge or not? It indeed match the PCI
> hierarchy of 2 host bridges and 1 root bridge under 1 host bridge.

While I don't know the internals of this host bridge-level enumeration,
it is worth looking at:

(a) in what context PciEnumerator() is called, and

(b) how PciEnumerator() works across multiple calls.

Regarding (a): PciEnumerator() is called from
PciBusDriverBindingStart(), that is, when the PciBusDxe driver is
binding a root brirdge. This is the code:

  //
  // Enumerate the entire host bridge
  // After enumeration, a database that records all the device information will be created
  //
  //
  Status = PciEnumerator (Controller);

Regarding (b): the PciEnumerator() function depends on a global variable
called "gFullEnumeration". This is what we have at the beginning and at
the end of PciEnumerator(), respectively:

  //
  // If PCI bus has already done the full enumeration, never do it again
  //
  if (!gFullEnumeration) {
    return PciEnumeratorLight (Controller);
  }

...

  gFullEnumeration = FALSE;

  Status = gBS->InstallProtocolInterface (
                  &HostBridgeHandle,
                  &gEfiPciEnumerationCompleteProtocolGuid,
                  EFI_NATIVE_INTERFACE,
                  NULL
                  );

The above seems to imply that PciBusDxe needs host bridge-level
information to do its job. This information is apparently collected when
the first root bridge is bound. When binding further root bridges (under
the same host bridge), the same information collecting is not repeated;
PciEnumerator() branches to PciEnumeratorLight() instead.

Hope this helps,
Laszlo


  reply	other threads:[~2017-08-17  9:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-17  4:50 PCI bus do 2 Enumeration when 2 root bridges under 1 host bridge Eric Song
2017-08-17  9:18 ` Laszlo Ersek [this message]
2017-08-17  9:37   ` 答复: " Eric Song
     [not found] ` <734D49CCEBEEF84792F5B80ED585239D5B9F07CC@SHSMSX104.ccr.corp.intel.com>
2017-08-17 10:59   ` Eric Song

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=2915a7f4-3f13-f16f-cf36-03a90ed0a681@redhat.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