Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp3930885pxb; Fri, 4 Feb 2022 22:18:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJyxcBmPQxOU0JiFJhuNccKnzdES+xcgiO4of/RR6Q7EWCK4PyEtBwewVZli4uIvfpAMUM38 X-Received: by 2002:a17:902:c652:: with SMTP id s18mr7036014pls.5.1644041920321; Fri, 04 Feb 2022 22:18:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644041920; cv=none; d=google.com; s=arc-20160816; b=KhtiFQ2vYNFwcdLnlDNWdGWS1zghlqAc6OB9DrY4ZOOm0OjbzyS+5uj19ihgxOjySm IO1XAgXGEpAXzxwRH5FAV3ceflznG7UK36GLawJOAAM8K93UMW0eJrJX+9zqRzwA9L0i l8K0ZP0idxirMZ6WfeVWJHd1AED/I5WFnPbwUm9XLTyOD+cw6YuRDOyOgNHnH4dILnKa A4yFWLtCzbzuNf4boBKEVlTKNNFT4St0/koFjjUKMPotmvgVnHQjTnRluEYPI/rxRgRp K6hP/dhqo9EFOnv3BCVTFZks7GgTEurxa0ajJaZTZnL3s/pxCohxGae5oqjRMn9I3fq1 XxLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:from:subject:dkim-signature; bh=fGcvqj8pmu0/HuF9/g0VeMM9I4TaK3Vd9U+V3O4yrwU=; b=drxocClIE+eeP9WOORLb8gqpHYgomGNtI7EpC3GbKjjhuZwW2QDXqBI2zWUScgXKSg 4fwY2q5Yprz2FIVguFVAXGZr1Ujioa+H8ErSrowR5PnoEyMlqfZz/Cru20FOgfZrLVEs 87k1ZwC77hRqCSR263cLdZVRnH8q8j4JCS3zN9vJ0HtviHiMIt1Tfqx+NPu5yPhBwVYv /fZ5/Rsa2LaN6gsiUi1btY8QYYo2xacrr+fG2J6UK7uRAp4FSclrG7UGAXkrbnrlwH62 rW8sO2U3a3zE+rlsSbOSTlz38lDJ1rnwfpPHtx9CNp+sjWZJo41kyi2Ezeu/4y9d2gwH bB/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=OILs61X1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l193si3724636pge.298.2022.02.04.22.18.25; Fri, 04 Feb 2022 22:18:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=OILs61X1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359563AbiBDPJE (ORCPT + 99 others); Fri, 4 Feb 2022 10:09:04 -0500 Received: from lelv0143.ext.ti.com ([198.47.23.248]:32964 "EHLO lelv0143.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353431AbiBDPJA (ORCPT ); Fri, 4 Feb 2022 10:09:00 -0500 Received: from fllv0035.itg.ti.com ([10.64.41.0]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 214F8pLF063155; Fri, 4 Feb 2022 09:08:51 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1643987331; bh=fGcvqj8pmu0/HuF9/g0VeMM9I4TaK3Vd9U+V3O4yrwU=; h=Subject:From:To:CC:References:Date:In-Reply-To; b=OILs61X1Jk1dwx/DtQ/3GgOH2neQgOkT+yICmFoAmg3bPOm4Spr0WD7Y3jB84EpHp vFdrwqJ35K4zgwbqXlCdisyddLisc487GmhoJkpTVCgWcgHf20LNfch/Cjmp/Xl4Uv 0rUgyW8Bp/ZxGzE+JVtDnJ7Wn0dDiQOQd7d9n2Ok= Received: from DLEE114.ent.ti.com (dlee114.ent.ti.com [157.170.170.25]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 214F8pp9040834 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 4 Feb 2022 09:08:51 -0600 Received: from DLEE104.ent.ti.com (157.170.170.34) by DLEE114.ent.ti.com (157.170.170.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14; Fri, 4 Feb 2022 09:08:51 -0600 Received: from lelv0327.itg.ti.com (10.180.67.183) by DLEE104.ent.ti.com (157.170.170.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14 via Frontend Transport; Fri, 4 Feb 2022 09:08:50 -0600 Received: from [10.250.233.89] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0327.itg.ti.com (8.15.2/8.15.2) with ESMTP id 214F8lBR081186; Fri, 4 Feb 2022 09:08:48 -0600 Subject: Re: [PATCH v2 4/5] PCI: keystone: Add quirk to mark AM654 RC BAR flag as IORESOURCE_UNSET From: Kishon Vijay Abraham I To: Lorenzo Pieralisi , Bjorn Helgaas CC: Rob Herring , =?UTF-8?Q?Krzysztof_Wilczy=c5=84ski?= , , , References: <20211126083119.16570-1-kishon@ti.com> <20211126083119.16570-5-kishon@ti.com> <20220104155741.GA28358@lpieralisi> Message-ID: Date: Fri, 4 Feb 2022 20:38:46 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Lorenzo, On 11/01/22 11:53 am, Kishon Vijay Abraham I wrote: > Hi Lorenzo, > > On 04/01/22 9:27 pm, Lorenzo Pieralisi wrote: >> On Fri, Nov 26, 2021 at 02:01:18PM +0530, Kishon Vijay Abraham I wrote: >>> AM654 RootComplex has a hard coded 64 bit BAR of size 1MB and also has >>> both MSI and MSI-X capability in it's config space. If PCIEPORTBUS is >>> enabled, it tries to configure MSI-X and msix_mask_all() adds about 10 >>> Second boot up delay when it tries to write to undefined location. >>> >>> Add quirk to mark AM654 RC BAR flag as IORESOURCE_UNSET so that >>> msix_map_region() returns NULL for Root Complex and avoid un-desirable >>> writes to MSI-X table. >> >> I don't think this is the right fix (it is not even a fix, just a >> plaster to workaround an issue). >> >> What do you mean by "writing to an undefined location" ? >> >> What does "a hard coded BAR" mean ? >> >> What happens if we _rightly_ write into it (ie to size it) ? > > There are two parts w.r.t setting the BAR; one is during the configuration and > the other is during the enumeration. > i) During the configuration, the size of the BAR is configured and the inbound > ATU is configured to map the BAR to a physical memory. > ii) During the enumeration, the size of the BAR is obtained and an address is > allocated and programmed in the BAR. > > In the case of RC, for (i) above, the BAR size is configured as '0' > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/dwc/pcie-designware-host.c#n556 > and the inbound ATU is not programmed at all. > > However, in the case of AM654, the HW configures BAR0 for a fixed size of 1MB > (irrespective of what SW programmed in [i]). While this was done more for a > endpoint usecase, since the same IP is configured for both RC mode and EP mode, > the fixed BAR size is seen with RC mode as well. AM654 also has MSI-X capability > for RC mode (the IP should have been ideally configured to have MSI-X capability > for EP mode). This results in PCIEPORTBUS doing some undesired access in > msix_mask_all(). > > Here I configure IORESOURCE_UNSET so that memory is not allocated for RC BAR. Do you need further clarifications on this? Thank You, Kishon > > Thank You, > Kishon > > >> >> Lorenzo >> >>> Signed-off-by: Kishon Vijay Abraham I >>> --- >>> drivers/pci/controller/dwc/pci-keystone.c | 8 +++++++- >>> 1 file changed, 7 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c >>> index 52d20fe17ee9..73e6626a0d8f 100644 >>> --- a/drivers/pci/controller/dwc/pci-keystone.c >>> +++ b/drivers/pci/controller/dwc/pci-keystone.c >>> @@ -557,8 +557,14 @@ static void ks_pcie_quirk(struct pci_dev *dev) >>> { 0, }, >>> }; >>> >>> - if (pci_is_root_bus(bus)) >>> + if (pci_is_root_bus(bus)) { >>> bridge = dev; >>> + if (pci_match_id(am6_pci_devids, bridge)) { >>> + struct resource *r = &dev->resource[0]; >>> + >>> + r->flags |= IORESOURCE_UNSET; >>> + } >>> + } >>> >>> /* look for the host bridge */ >>> while (!pci_is_root_bus(bus)) { >>> -- >>> 2.17.1 >>>