From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web12.5565.1639132934878869437 for ; Fri, 10 Dec 2021 02:42:15 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=CamtZ2pA; spf=pass (domain: kernel.org, ip: 145.40.68.75, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 11B9EB80E48 for ; Fri, 10 Dec 2021 10:42:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6B5DC341C8 for ; Fri, 10 Dec 2021 10:42:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1639132930; bh=UgXW3wRpsYPxdBe929v/pRTg8TPbKsxrgKZWp9m+x6E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=CamtZ2pAJcuUBGQEVYXLsnlPLOGmVO7gDIcP0RjvlyPKukrqsvcIH1F/A04Vhr8t7 dzjVO5hes+u5uf8oSQZMEgmwm60OA3E6aBO41BJsi0vW9f9Wu26JNMafMyF8wFfvvq ODAGFP54yeYl5Q13p6rlahBdBB7tYxUjUCCjH2pdCgYCENpB2BLfaQbytdVCNx9BFE yIj9OwMrvHqW4xMSs6CqZEZHK08iXrGet3g+urN3v5h2xq71XAdRX8hKHvf/7Lej/y FUvNRXK4gPvyZsXb9brDTHvfLrfFgpGCyP3AKsSHLVXsH/TT+0prZexpx9gKoahkMn sdKB/2mbuigVA== Received: by mail-oo1-f54.google.com with SMTP id r18-20020a4a7252000000b002c5f52d1834so2340698ooe.0 for ; Fri, 10 Dec 2021 02:42:10 -0800 (PST) X-Gm-Message-State: AOAM531gDqXStzUZ6fT5tqBz2KZBIM/FD7xQck2vjw7NRie2Md3I3fuK OiWlIxrlgqxamhS3py2C92PUWR0JghBdCk5xfWk= X-Google-Smtp-Source: ABdhPJwM88CnvzL8MDOrMLTDBtd+LkYjNRY1id5q77obucdPeL8mcjCEvT1Jz+JQgZIVceEFf4v6BdW5TNx0fANCdD8= X-Received: by 2002:a4a:5a43:: with SMTP id v64mr7861701ooa.26.1639132930075; Fri, 10 Dec 2021 02:42:10 -0800 (PST) MIME-Version: 1.0 References: <2d695d9d-eb38-f8d0-d7bd-d77dbe609ec3@arm.com> <8622.1638932156872484301@groups.io> In-Reply-To: From: "Ard Biesheuvel" Date: Fri, 10 Dec 2021 11:41:58 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [edk2-platforms][PATCH V1 07/11] Platform/ARM/Morello: Port PCI Express library To: chandni cherukuri Cc: edk2-devel-groups-io , khasim.mohammed@arm.com, Sami Mujawar , Ard Biesheuvel , Leif Lindholm , Pierre Content-Type: text/plain; charset="UTF-8" On Thu, 9 Dec 2021 at 13:30, chandni cherukuri wrote: > > Hi Ard, Leif, Sami, Pierre, > > For Morello platform, we created two custom libraries based on the > below two native libraries: > - https://github.com/tianocore/edk2/tree/master/MdePkg/Library/BasePciSegmentLibPci > - https://github.com/tianocore/edk2/tree/master/MdePkg/Library/BasePciExpressLib > > because of the following reasons. > 1. In Morello platform, the ECAM region of the two root ports > are placed in non-contiguous memory as per the memory map architecture > of the Morello platform. The native PCI Express Library expects both > the ECAM regions for all the root ports to be contiguous. Do you mean root ports or host bridges? If root ports don't share the MMIO resource windows provided by the respective host bridges, they are really different host bridges and should be modeled as such. Note that the Cadence and Synopsys IP usually does not implement a root port at all, and gets away with this because it only implements a single link. > 2. IORT and kernel currently require each root port to be in a > separate segment. You can refer to the code for more details - > Please take a look at the SynQuaecer platform for inspiration. That platform is very similar in this respect. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/arm64/iort.c#n307. > The native PCI Segment Library supports only a single segment. > > Because of these reasons, the current patch series adapts the native > libraries as follows: > > The custom PCI Segment Library passes the complete address which is > consumed by the custom PCI Express library where based on the Segment > number, the base address of the PCI Express is returned. > > The rationale behind maintaining two separate libraries is that when > the software evolves and support for multiple segments is adapted in > the native PCI Segment Library the custom library could be removed. > Also, we might have other protocols which might try to use the PCI > Express library directly. However, there are some other platforms > where all the platform specific changes have gone in a single custom > PCI library > > Could you please provide some inputs as to which of two approaches > would be better to follow as there is one more platform to follow > based on the decision taken? > > Thanks > Chandni > > On Wed, Dec 8, 2021 at 8:25 AM Khasim Mohammed wrote: > > > > Hi Sami, Chandni, > > > > There was a suggestion from Pierre on a similar patch for N1SDP to remove PCIExpressLib.c and move to workarounds to PCISegmentLib.c, > > > > https://edk2.groups.io/g/devel/message/84165?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Arecentpostdate%2Fsticky%2C%2Ckhasim%2C20%2C2%2C0%2C87257273 > > > > I think we should discuss this implementation for both N1SDP and Morello as they have similar implementation. > > > > Regards, > > Khasim > >