From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B7C29C77B7A for ; Tue, 16 May 2023 15:03:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:CC:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=7iXPTWd2uBpAmifLUHYjpXWVkZyRWB5x4WAyzWE67AA=; b=hPGEQx6w0/qEZ1 9tl86F9M/qUFuSzzIiByqqG0lWYZxDLH6Y0OaaVi0sMkDNZm6jLePfFYjW292KpOd5wVulkmJR4Y0 rzrqM1CmRVWnJcruNPiJmjy3c40ECzeW85fJtWKoam9MLikvcavfMUkL4EM0Y7ODS2bp/0X6d57a/ GTXsDG5je7Fialk686SpI3ufqnt+pSKapTCzEjho2latlmbwtaa9o560bCsu5Ip817oM8uFLfBYAL hx+4MCP2QYYu6QbVnmshb9a6vEo5vors2Q0q6QUqdpdiCkU5ZeWfMmv/T8q4eO21W5ChPU7Ep+4HF I1TpZdxxK0qkKh92qXGA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pywCs-006BR2-2j; Tue, 16 May 2023 15:03:18 +0000 Received: from frasgout.his.huawei.com ([185.176.79.56]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pywCp-006BPA-22 for linux-arm-kernel@lists.infradead.org; Tue, 16 May 2023 15:03:17 +0000 Received: from lhrpeml500005.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4QLKFC4Vf1z67mgD; Tue, 16 May 2023 23:01:19 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Tue, 16 May 2023 16:03:05 +0100 Date: Tue, 16 May 2023 16:03:04 +0100 From: Jonathan Cameron To: Shuai Xue CC: Robin Murphy , , , , , , , , , , , Subject: Re: [PATCH v3 2/3] drivers/perf: add DesignWare PCIe PMU driver Message-ID: <20230516160304.00000544@Huawei.com> In-Reply-To: <7aec4dbd-91d5-2a14-8779-f239a58cbbae@linux.alibaba.com> References: <20220917121036.14864-1-xueshuai@linux.alibaba.com> <20230417061729.84422-3-xueshuai@linux.alibaba.com> <7aec4dbd-91d5-2a14-8779-f239a58cbbae@linux.alibaba.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml100003.china.huawei.com (7.191.160.210) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230516_080315_967899_19DEFBCD X-CRM114-Status: GOOD ( 25.17 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org PCI folks, Question below directed at you. Please take a look. +CC linux-cxl because a similar question is going to bite us shortly if we want CXL PMUs to work well on RP or Switch ports. > >> +static int dwc_pcie_ras_des_discover(struct dwc_pcie_pmu_priv *priv) > >> +{ > >> +=A0=A0=A0 int index =3D 0; > >> +=A0=A0=A0 struct pci_dev *pdev =3D NULL; > >> +=A0=A0=A0 struct dwc_pcie_rp_info *rp_info; > >> + > >> +=A0=A0=A0 INIT_LIST_HEAD(&priv->rp_infos); > >> + > >> +=A0=A0=A0 /* Match the rootport with VSEC_RAS_DES_ID */ > >> +=A0=A0=A0 for_each_pci_dev(pdev) { = > > = > > Does the PCI layer not offer a more robust mechanism for this? (PCI fix= ups come to mind, but I don't actually know whether that would be a viable = approach or not.) = > = > I am afraid not yet. Jonathan try to add a PMU service but it is not merg= ed into mainline. I wouldn't read much into that 'failure'. We never persisted with that dri= ver because it was for an old generation of hardware. Mostly the aim with that was to explore the area o= f PCIe PMU in general rather than to get the support upstream. Some of the counters on that hardw= are were too small to be of much use anyway :) Grabbing just relevant functions.. Bjorn, we need to figure out a way forwards for this sort of case and I'd appreciate your input on the broad brush question of 'how should it be done= '? This is a case where a PCIe port (RP here) correctly has the PCIe class code so binds to the pcie_port driver, but has a VSEC (others examples use DOE, = or DVSEC) that provides extended functionality. The referred to PCIe PMU from our ol= der Hisilicon platforms did it by adding another service driver - that probably doesn't e= xtend well. The approach used here is to separately walk the PCI topology and register = the devices. It can 'maybe' get away with that because no interrupts and I assume resets= have no nasty impacts on it because the device is fairly simple. In general that's= not going to work. CXL does a similar trick (which I don't much like, but too late n= ow), but we've also run into the problem of how to get interrupts if not the mai= n driver. So what approach should we look at to solve this in general? Jonathan > +static int dwc_pcie_ras_des_discover(struct dwc_pcie_pmu_priv *priv) > +{ > + int index =3D 0; > + struct pci_dev *pdev =3D NULL; > + struct dwc_pcie_rp_info *rp_info; > + > + INIT_LIST_HEAD(&priv->rp_infos); > + > + /* Match the rootport with VSEC_RAS_DES_ID */ > + for_each_pci_dev(pdev) { > + u16 vsec; > + u32 val; > + > + if (!pci_dev_is_rootport(pdev)) > + continue; > + > + rp_info =3D devm_kzalloc(&pdev->dev, sizeof(*rp_info), GFP_KERNEL); > + if (!rp_info) > + return -ENOMEM; > + > + rp_info->bdf =3D PCI_DEVID(pdev->bus->number, pdev->devfn); > + rp_info->pdev =3D pdev; > + > + vsec =3D pci_find_vsec_capability(pdev, PCI_VENDOR_ID_ALIBABA, > + DWC_PCIE_VSEC_RAS_DES_ID); > + if (!vsec) > + continue; > + > + pci_read_config_dword(pdev, vsec + PCI_VNDR_HEADER, &val); > + if (PCI_VNDR_HEADER_REV(val) !=3D 0x04 || > + PCI_VNDR_HEADER_LEN(val) !=3D 0x100) > + continue; > + pci_dbg(pdev, > + "Detected PCIe Vendor-Specific Extended Capability RAS DES\n"); > + > + rp_info->ras_des =3D vsec; > + rp_info->num_lanes =3D pcie_get_width_cap(pdev); > + > + list_add(&rp_info->rp_node, &priv->rp_infos); > + index++; > + } > + > + if (!index) > + return -ENODEV; > + > + priv->pcie_ctrl_num =3D index; > + > + return 0; > +} > +static int dwc_pcie_pmu_probe(struct platform_device *pdev) > +{ > + int ret; > + struct dwc_pcie_pmu_priv *priv; > + struct dwc_pcie_rp_info *rp_info; > + > + priv =3D devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); > + if (!priv) > + return -ENOMEM; > + > + priv->dev =3D &pdev->dev; > + platform_set_drvdata(pdev, priv); > + > + /* If RAS_DES PMU is not supported on current platform, keep silent */ > + ret =3D dwc_pcie_ras_des_discover(priv); > + if (ret) > + return ret; > + > + list_for_each_entry(rp_info, &priv->rp_infos, rp_node) { > + struct pci_dev *rp =3D rp_info->pdev; > + > + ret =3D __dwc_pcie_pmu_probe(priv, rp_info); > + if (ret) { > + dev_err(&rp->dev, "PCIe PMU probe fail\n"); > + goto pmu_unregister; > + } > + } > + > + return 0; > + > +pmu_unregister: > + dwc_pcie_pmu_remove(pdev); > + > + return ret; > +} _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel