public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Scott Telford <stelford@cadence.com>,
	Leif Lindholm <leif.lindholm@linaro.org>
Cc: "edk2-devel@lists.01.org" <edk2-devel@ml01.01.org>,
	"Tian, Feng" <feng.tian@intel.com>,
	"Zeng, Star" <star.zeng@intel.com>
Subject: Re: [PATCH] Copy bus scanning workaround from ARM Juno PCIe driver.
Date: Wed, 24 May 2017 07:03:10 -0700	[thread overview]
Message-ID: <CAKv+Gu9aH1T7qX0gQGWWNLAEy5vPZoyQxryoRbhmyf8rWzOUTg@mail.gmail.com> (raw)
In-Reply-To: <BN6PR07MB31548707DA4B28BA5354622ECFFE0@BN6PR07MB3154.namprd07.prod.outlook.com>

(+ Leif)

On 24 May 2017 at 01:34, Scott Telford <stelford@cadence.com> wrote:
> Hi Ard,
>
> Firstly, this patch was meant for my edk2-staging branch, not mainline edk2 - sorry, forgot to edit the subject line!
>

Ah ok. In that case, do whatever you like :-)

> The issue is that, without this workaround, PCI(e) bridges and devices will be detected multiple times during bus scanning, e.g. a bridge at bus 1 device 0 will also be seen at bus 1 device 1, bus 1 device 2 etc and hence all the devices on the other side of the bridge will be duplicated too. I copied this workaround from the old Juno PCIe driver as I was seeing the same problem when I was testing the Cadence PCIe host bridge library I have been working on. I agree there should probably be a more elegant solution, but I don't know the generic PCI driver code well enough to suggest one at the moment.
>

As I said, the workaround belongs in PciExpressLib. You can just clone
that and put the workaround in there.

Interestingly, though, this PCIe IP works fine with the generic ECAM
driver in Linux, so I wonder what the difference is.

Leif, were you aware of this issue?


>> -----Original Message-----
>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
>> Sent: 23 May 2017 17:42
>> To: Scott Telford <stelford@cadence.com>
>> Cc: edk2-devel@lists.01.org <edk2-devel@ml01.01.org>; Tian, Feng
>> <feng.tian@intel.com>; Zeng, Star <star.zeng@intel.com>
>> Subject: Re: [edk2] [PATCH] Copy bus scanning workaround from ARM Juno
>> PCIe driver.
>>
>> On 23 May 2017 at 09:15, Scott Telford <stelford@cadence.com> wrote:
>> > Copy workaround previously in
>> >
>> ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciRootBridge.c:Pci
>> RbPciRead()
>> > to RootBridgeIoPciAccess(), to avoid spurious multiple detections when
>> > scanning buses.
>> >
>> > Contributed-under: TianoCore Contribution Agreement 1.0
>> > Signed-off-by: Scott Telford <stelford@cadence.com>
>> > ---
>> >  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 13
>> +++++++++++++
>>
>> This does not belong in the generic driver.
>>
>> Could you please explain in more detail what the issue is? In any
>> case, we will need to put this workaround in a Juno specific
>> implementation of PciExpressLib
>>
>> >  1 file changed, 13 insertions(+)
>> >
>> > diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>> > index a0e7e5b..3cca3c1 100644
>> > --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>> > +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
>> > @@ -945,6 +945,19 @@ RootBridgeIoPciAccess (
>> >      PciAddress.ExtendedRegister = PciAddress.Register;
>> >    }
>> >
>> > +  // The UEFI PCI enumerator scans for devices at all possible addresses,
>> > +  // and ignores some PCI rules - this results in some hardware being
>> > +  // detected multiple times. We work around this by faking absent
>> > +  // devices
>> > +  if ((PciAddress.Bus == 0) && ((PciAddress.Device != 0) ||
>> (PciAddress.Function != 0))) {
>> > +    *((UINT32 *)Buffer) = 0xffffffff;
>> > +    return EFI_SUCCESS;
>> > +  }
>> > +  if ((PciAddress.Bus == 1) && ((PciAddress.Device != 0) ||
>> (PciAddress.Function != 0))) {
>> > +    *((UINT32 *)Buffer) = 0xffffffff;
>> > +    return EFI_SUCCESS;
>> > +  }
>> > +
>> >    Address = PCI_SEGMENT_LIB_ADDRESS (
>> >                RootBridge->RootBridgeIo.SegmentNumber,
>> >                PciAddress.Bus,
>> > --
>> > 2.2.2
>> >
>> > _______________________________________________
>> > edk2-devel mailing list
>> > edk2-devel@lists.01.org
>> > https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__lists.01.org_mailman_listinfo_edk2-
>> 2Ddevel&d=DwIBaQ&c=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3GZ-
>> _haXqY&r=0b2qZ7fqn6FWL0d7Bhx7saDL-
>> B7sx3Cxz3HPARO7ozc&m=7SGL_JTC4ZjVpm7zTv_uO5MHMY48vYsBzhKmKB
>> q66zw&s=W6S9XFt8B-FdfcvWjCtvHTGo3uddEyMfM6BIEMe8dtY&e=


  reply	other threads:[~2017-05-24 14:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-23 16:15 [PATCH] Copy bus scanning workaround from ARM Juno PCIe driver Scott Telford
2017-05-23 16:42 ` Ard Biesheuvel
2017-05-24  8:34   ` Scott Telford
2017-05-24 14:03     ` Ard Biesheuvel [this message]
2017-05-26 14:50       ` Leif Lindholm
2017-05-26 17:37         ` Ard Biesheuvel
2017-05-29 16:14           ` Scott Telford
2017-05-30 10:13             ` Ard Biesheuvel
2017-05-31 10:51               ` Scott Telford

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=CAKv+Gu9aH1T7qX0gQGWWNLAEy5vPZoyQxryoRbhmyf8rWzOUTg@mail.gmail.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