Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp863237rwb; Tue, 27 Sep 2022 05:44:58 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7JyhwbyUQNNtPNgFERgsvibi06PXNMzzLTqvjit/dGrfxp6Yah08YolQgGrI7pJm8j1uZ4 X-Received: by 2002:a17:907:7d87:b0:783:fb5:1899 with SMTP id oz7-20020a1709077d8700b007830fb51899mr12614487ejc.456.1664282698544; Tue, 27 Sep 2022 05:44:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664282698; cv=none; d=google.com; s=arc-20160816; b=tdkiHACB+z9kdU5SHW69A28UKkDnObGRUZTeny3Ep/RMEg8Tbi7P1C+gp1tQnNZ9Cm nANxDyXCZAZjZw0eplMpRM2nH+BFasiyErDB30eJw5ltzKA5tQ6luLuV7e/I8bTZB6iJ VAOq2/g0dWOyudJh9wV/+uWGlQjWyJcZ3Aohe7x3KHYU7S/QTXITXAGfp/hHQgzw+vJ/ ly3tJ6i2Cs5aLrNvI6ouYHR9io0GC+8LopHpOxyJQp/UvPcQq/Ib7Gm2vyNp+yjq//yO 5mCvtg1mFCS0ch2LwN0RM2N2rrFEZ6m8X1ecsQJLbyNeXOScDQBeUEEMBjMRswLyfnt0 E7kQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=9JhQfvzqodePk68p00rmYA20oPfv5ClnyjhFFSjuHtc=; b=cmFayiqGWF/NIaIypjWrZJWiXta6Tu6DN16jGENISwQc//IwBQu8B5jKb4lH/bikwC GkiNNjku8F12/HRhUM0dzB+Kz2yyO6zpCQKr0jZafULs/dWFTnH9bkgh4qquU04XI5lf u4xpZJyUz8BPYlNf/fiaz/UltFq7qyI3wP63TWQjRPP98zSfg3Hh5l/JJD7k9VDB7Kcq 9zjtp6cTNHQJzo8x2FYlUma0Txa6bhbzzJK5zSunmphvNqLmXhnYlaCGpNddWRBcOcJV rqYU62jkYp2llFQU2QQmAkP+1LcAw5+KQliAflx3sFBKSe44KQJYKg/QqLO7gm9RPIIt DsQQ== 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=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s7-20020a50ab07000000b00448375a5890si1600122edc.393.2022.09.27.05.44.32; Tue, 27 Sep 2022 05:44:58 -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=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232130AbiI0MaF (ORCPT + 99 others); Tue, 27 Sep 2022 08:30:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34348 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232035AbiI0M3c (ORCPT ); Tue, 27 Sep 2022 08:29:32 -0400 Received: from out30-44.freemail.mail.aliyun.com (out30-44.freemail.mail.aliyun.com [115.124.30.44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E363E3AE60; Tue, 27 Sep 2022 05:29:20 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R611e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045176;MF=xueshuai@linux.alibaba.com;NM=1;PH=DS;RN=11;SR=0;TI=SMTPD_---0VQs2UTR_1664281755; Received: from 30.240.121.51(mailfrom:xueshuai@linux.alibaba.com fp:SMTPD_---0VQs2UTR_1664281755) by smtp.aliyun-inc.com; Tue, 27 Sep 2022 20:29:17 +0800 Message-ID: <57a0687d-d961-8f8f-8b08-818a07388e49@linux.alibaba.com> Date: Tue, 27 Sep 2022 20:29:15 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH v1 2/3] drivers/perf: add DesignWare PCIe PMU driver Content-Language: en-US To: Jonathan Cameron Cc: Bjorn Helgaas , will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, rdunlap@infradead.org, robin.murphy@arm.com, mark.rutland@arm.com, baolin.wang@linux.alibaba.com, zhuo.song@linux.alibaba.com, linux-pci@vger.kernel.org References: <20220926171857.GA1609097@bhelgaas> <7502d496-9ec1-1ca4-c643-376ec2aa662e@linux.alibaba.com> <20220927110435.00005b4d@huawei.com> From: Shuai Xue In-Reply-To: <20220927110435.00005b4d@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,USER_IN_DEF_SPF_WL 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 在 2022/9/27 PM6:04, Jonathan Cameron 写道: > 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... Yes, I realized that the prefix `pcie_bdf` is not appropriate. Let's discuss with Robin in his thread. Thank you. Best Regards, Shuai