From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 1D2A021A16EDD for ; Tue, 30 May 2017 12:03:34 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id l14so44397827ywk.1 for ; Tue, 30 May 2017 12:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=GpzjHglG8hOUNG9+TMs6IIw3XvuYxmQ45R7ufbf0KY8=; b=AKEIQ2kMZvSHGYzSVif+OgCyQ2g1JOugSAj3lbFiMB2Hnx5hz0SOJLmpshQOD0SJ9l U53LCb3OCPyLaPzeYiQ8ZK40PsI4zYs8WQ3IkWXtl5iSkd+JnWNdS8YeM7nrtuT5zAZk GWlO4YAihT0wGQeC9hNh4yRHxCBet5CA9x7UU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=GpzjHglG8hOUNG9+TMs6IIw3XvuYxmQ45R7ufbf0KY8=; b=UU9MVK3SBRCIwz9R/lHIHskLEMJKTY9Ewns2jLEj1RUp35CELy26yDOLSRP6dAgvvC B/Use0mIPWIdyTZ6bhKLzOeR4YSfzQhVXG+mi0Z3HemIvoPjbl+weGoM9JrtpO+PHtEs 9trKdqp2oU2B9Gphyt3P4fFSKu8Vfnj1ZMfGO66D1EKUjY/ObqWx78iApAeJwkBsUe5L ouy+XCPcHX5JFPRrR4Um1Aq554wqVCQ2EamEWqzqSoeTERrMSqvg2TqkmVeK1ccY3a/4 VIZmMSTKJ3z/7DXL6UNqaJyscyBehPbJxBergB+24KPFkBq4E+lvmKAqd44fgcT7uZMU YpNg== X-Gm-Message-State: AODbwcBksGJn9NckHOOKBSXNBGQdDTCDz7Mp2AHAWkSBlxAueFA0T5Om r1P7nSpfEOfiKRNYVn5lnt4DKO9z2OVw X-Received: by 10.129.71.65 with SMTP id u62mr16386214ywa.294.1496171072550; Tue, 30 May 2017 12:04:32 -0700 (PDT) From: Vladimir Olovyannikov References: <4220315aed43c05b37b1b71a9eff432e@mail.gmail.com> <1dbbb04c-b725-d9bb-0300-283029538588@redhat.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGJgBaRYALxe2tiJNyoWDxrDGFkmQCscivxAkejEUaiiEzzQA== Date: Tue, 30 May 2017 12:04:31 -0700 Message-ID: <8e9711a0244e9cf9d1bf752f638e42dd@mail.gmail.com> To: Laszlo Ersek , edk2-devel@lists.01.org Cc: Ard Biesheuvel Subject: Re: Using a generic PciHostBridgeDxe driver for a multi-PCIe-domain platform X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 19:03:34 -0000 Content-Type: text/plain; charset="UTF-8" > -----Original Message----- > From: Laszlo Ersek [mailto:lersek@redhat.com] > Sent: May-30-17 11:50 AM > To: Vladimir Olovyannikov; edk2-devel@lists.01.org > Cc: Ard Biesheuvel > Subject: Re: [edk2] Using a generic PciHostBridgeDxe driver for a > multi-PCIe- > domain platform > > On 05/30/17 20:32, Laszlo Ersek wrote: > > On 05/30/17 18:23, Vladimir Olovyannikov wrote: > >> Hi, > >> > >> I've started PCIe stack implementation design for an armv8 aarch64 > >> platform. > >> The platform's PCIe represents several host bridges, and each > >> hostbridge has one rootbridge. > >> They do not share any resources between each other. > >> Looking into the PciHostBridgeDxe implementation I can see that it > >> supports only one hostbridge, and there is a comment: > >> // Most systems in the world including complex servers have only one > >> Host Bridge. > >> > >> So in my case should I create my own PciHostBridgeDxe driver > >> supporting multiple hostbridges and do not use the Industry standard > driver? > >> I am very new to it, and will appreciate any help or idea. > > > > I think you can use PciHostBridgeDxe on this platform: > > > > - Implement a PciHostBridgeLib instance (see > > ) that returns > > PCI_ROOT_BRIDGE objects with different Segment fields, from > > PciHostBridgeGetRootBridges(). > > > > - Implement a PciSegmentLib instance (see > > ) that routes the config space > > addresses, encoded by the PCI_SEGMENT_LIB_ADDRESS() macro, > according > > to your platform. > > > > PciHostBridgeDxe and PciBusDxe should "just work" atop. To my > > understanding, PciBusDxe delegates all config space accesses to > > PciHostBridgeDxe, via EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL. And > > PciHostBridgeDxe delegates all config space accesses to the platform's > > PciSegmentLib. > > A small addition. Assuming the general case, i.e. when you have a > different > number of root bridges on each of several host bridges, you still have to > number all those root bridges incrementally, in a curious, flat address > space. > And that address space is the PcieRoot(N) device path node that is > supposed > to start the "DevicePath" member of each PCI_ROOT_BRIDGE object that > you return from PciHostBridgeGetRootBridges(). > > You can read about the PcieRoot() devpath node in the UEFI 2.6 spec. > Basically, you have > > ACPI_HID_DEVICE_PATH.Header = ; > ACPI_HID_DEVICE_PATH.HID = EFI_PNP_ID (0x0a08); > ACPI_HID_DEVICE_PATH.UID = ; > > The UID values used in these devpath nodes should preferably match the > UID values of the corresponding PCI Express Root Bridge objects > (=PNP0A08) that you expose in your ACPI tables (DSDT and/or SSDT). Thanks for explanation Laszlo, In my case every hostbridge has exactly one rootbridge. I will follow your advice and will create SegmentPciLib and platform's PciHostBridgeLib. So basically my PciHostBridgeLib should treat hostbridges as rootbridges with different segments in this case? > > Thanks > Laszlo Thank you, Vladimir