Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp968810rwb; Tue, 27 Sep 2022 06:56:00 -0700 (PDT) X-Google-Smtp-Source: AMsMyM45idqdMbPbzm1+pVEcLI17Iqe/LIcoerajLJ8DS3orBctmsmgK/YEN6yVxv2KNzVYlFU6h X-Received: by 2002:aa7:952f:0:b0:540:e8ee:a077 with SMTP id c15-20020aa7952f000000b00540e8eea077mr29399847pfp.34.1664286960384; Tue, 27 Sep 2022 06:56:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664286960; cv=none; d=google.com; s=arc-20160816; b=HrWsVGEQd4ky7pZv6utInb5ylmoHvNo71sB6cXYxSu0WnkhT0fgy+3ztomxWs/uiQw 9xeL8SD/eJcSbaCkWnG1f11ENYLBb9NGJss+FYHF9Ft0I06hcUDuLlzHvMIWhMjbwwMg 5lUeDlMD2P0ytoU2db60ibq039BX643MzBa8EVpIJSrkm5fqpQvD/lBTBa7fDKc+ZU0m V+/WEGrZvLHKZ9WEyT9i7CliK00QIvhp6gyknndZ2UAsZyXTN+OlpaX6yLz+lP92hKyO slkDqWnnQR58wLN1W2MDO9kOTSCa8enf6mWDJmZkVCUbeaHLHTKI+1yvVlCAyGXK99ts tmNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=F7FNFFoI08TRi3x98H1dkbhGt3VAw1ig8YF80NkIavc=; b=Y9ePHTb2XGYMh8cklOB3DWi7nxuRGkl/5nSzETqrlnQOdwfGcFjR06ngt/ucQIOdvD wZXr3w3jhgH+sUJHACyxEa2lOPCG+AP7z/sxmvyB75T1Sw/c64iAbiz485O2/x1q90Ju uyTg+4fHVkmZSVDph28Ua0hmqGJYbd9cwqicqzTlfDORQhA9L6AYlO7le8mVMXsi+Mht MH0keuI6vDYSPNNYs3S+Cj5BN4uEwAxBDvQsNG3fImuAfX8KeIcpQNLwuoOGuL/amZGa I0PQM3+Q72s91HdQpN4Ke+QhY0rbdHho5MkWCOQsRfXgC/rIzwSCzAx+WINNCffS0yZ+ D2sw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c5-20020a056a000ac500b005368015d180si2264653pfl.37.2022.09.27.06.55.48; Tue, 27 Sep 2022 06:56:00 -0700 (PDT) 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; 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=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232688AbiI0Njy convert rfc822-to-8bit (ORCPT + 99 others); Tue, 27 Sep 2022 09:39:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41320 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231425AbiI0Njx (ORCPT ); Tue, 27 Sep 2022 09:39:53 -0400 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 17A1C3FA2A; Tue, 27 Sep 2022 06:39:52 -0700 (PDT) Received: from fraeml737-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4McLLN6tv7z67kws; Tue, 27 Sep 2022 21:38:36 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (7.191.163.240) by fraeml737-chm.china.huawei.com (10.206.15.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 27 Sep 2022 15:39:49 +0200 Received: from localhost (10.202.226.42) 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.2375.31; Tue, 27 Sep 2022 14:39:49 +0100 Date: Tue, 27 Sep 2022 14:39:48 +0100 From: Jonathan Cameron To: Shuai Xue CC: Robin Murphy , Bjorn Helgaas , , , , , , , , Subject: Re: [PATCH v1 2/3] drivers/perf: add DesignWare PCIe PMU driver Message-ID: <20220927143948.00004c43@huawei.com> In-Reply-To: <2085a695-7fa2-b560-3164-c62cb17dd5f7@linux.alibaba.com> References: <20220926171857.GA1609097@bhelgaas> <7502d496-9ec1-1ca4-c643-376ec2aa662e@linux.alibaba.com> <20220927110435.00005b4d@huawei.com> <5372edb4-5717-42a0-142e-91657a9b18c3@arm.com> <2085a695-7fa2-b560-3164-c62cb17dd5f7@linux.alibaba.com> X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.29; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Originating-IP: [10.202.226.42] X-ClientProxiedBy: lhrpeml500004.china.huawei.com (7.191.163.9) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 27 Sep 2022 20:49:26 +0800 Shuai Xue wrote: > + Jonathan > > 在 2022/9/27 PM6:14, Robin Murphy 写道: > > On 2022-09-27 11:04, Jonathan Cameron wrote: > >> On Tue, 27 Sep 2022 13:13:29 +0800 > >> Shuai Xue wrote: > >> > >>> 在 2022/9/27 AM1:18, Bjorn Helgaas 写道: > >>>> On Mon, Sep 26, 2022 at 09:31:34PM +0800, Shuai Xue wrote: > >>>>> 在 2022/9/23 PM11:54, Jonathan Cameron 写道: > >>>>>>> I found a similar definition in arch/ia64/pci/pci.c . > >>>>>>> > >>>>>>>     #define PCI_SAL_ADDRESS(seg, bus, devfn, reg)        \ > >>>>>>>     (((u64) seg << 24) | (bus << 16) | (devfn << 8) | (reg)) > >>>>>>> > >>>>>>> Should we move it into a common header first? > >>>>>> > >>>>>> Maybe. The bus, devfn, reg part is standard bdf, but I don't think > >>>>>> the PCI 6.0 spec defined a version with the seg in the upper bits. > >>>>>> I'm not sure if we want to adopt that in LInux. > >>>>> > >>>>> I found lots of code use seg,bus,devfn,reg with format "%04x:%02x:%02x.%x", > >>>>> I am not quite familiar with PCIe spec. What do you think about it, Bjorn? > >>>> > >>>> The PCIe spec defines an address encoding for bus/device/function/reg > >>>> for the purposes of ECAM (PCIe r6.0, sec 7.2.2), but as far as I know, > >>>> it doesn't define anything similar that includes the segment.  The > >>>> segment is really outside the scope of PCIe because each segment is a > >>>> completely separate PCIe hierarchy. > >>> > >>> Thank you for your explanation. > >>> > >>>> > >>>> So I probably wouldn't make this a generic definition.  But if/when > >>>> you print things like this out, please do use the format spec you > >>>> mentioned above so it matches the style used elsewhere. > >>>>    > >>> > >>> Agree. The print format of bus/device/function/reg is "%04x:%02x:%02x.%x", > >>> so I named the PMU as the same format. Then the usage flow would be: > >>> > >>> - lspci to get the device root port in format seg/bus/device/function/reg. > >>>     10:00.0 PCI bridge: Device 1ded:8000 (rev 01) > >>> - select its PMU name pcie_bdf_100000. > >>> - monitor with perf: > >>>     perf stat -a -e pcie_bdf_100000/Rx_PCIe_TLP_Data_Payload/ > >> > >> I think you probably want something in there to indicate it's an RP > >> and the bdf part may be redundant... > > > > Indeed that seems horribly unclear; personally I reckon something like "dw_pcie_200" would be more appropriate. The address is just a disambiguator between multiple instances so doesn't need any further emphasis, but what is crucial to the user is exactly what kind of PMU it is (especially if there's potential for other unrelated PCIe functions to start exposing their own different PMUs). > > I see your point. The current prefix `pcie_bdf` is not appropriate, > > - it does not indicate it is for a root point as Jonathan mentioned. > - its prefix is not `dwc` > > Is dwc_rootport_100000 more appropriate? > > - `dwc` indicates the PMU is for Synopsys DesignWare Cores PCIe controller IP > - `rootport` indicates the PMU is for a root port device > - `100000` indicates the device address Looks good to me. J > > > Thank you. > > Best Regards, > Shuai > > > >