Message ID | 20231018070506.65320-1-tianruidong@linux.alibaba.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4612381vqb; Wed, 18 Oct 2023 00:06:26 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFUJpnxGULF46XLFX+8WsiVjSNSDDQPSKAZsMyYHayWbrIZ5OCxLeJYKPYmR8sxjh2YTim5 X-Received: by 2002:a05:6359:288d:b0:166:d9dc:5f5f with SMTP id qa13-20020a056359288d00b00166d9dc5f5fmr3790718rwb.3.1697612786157; Wed, 18 Oct 2023 00:06:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697612786; cv=none; d=google.com; s=arc-20160816; b=EkRpUg3GMNpjZ8NJbd4hOShjANR5u6D3VXf19vdu1qxZaOEGAC/a0bhIzMCRKan7T0 bWDZKZwpmDq4scalBcekhqUS3sc/hbpp9bXyi9pfL0bqllCrAUsq1MRRT+yv7Xi4Te09 UKnCZd/eEU5i39BM/mccEHID4ECMxsPINATAyvop8EpQrmYEsoyPWXfE/wmFWr6sBbkS 7TAGaZkSlAGdzintGYkhkrHzCy8PxSLZtBsl1FbqBGrIIryL7FmnvTU+gQhSy4Gzqs1y vP6/08dR8xZ0F7dIzZLIDsO+1+euK345jEr0ohYksTEWdnycAv/ygDSIHJ1l4TeejM1m hGmA== 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 :message-id:date:subject:cc:to:from; bh=bUqUXaWRtlBNaDc3wVUb2z3lPPZoADXFhct9+j+ZJXs=; fh=BtXCB5104GGPkVk22X8bQX3dKzvoEdEmGxuElmN9oU0=; b=XaT1AK4YL0Wd7WGzWMEJQJpUvZoRnrxxQ0R1kaXQeyv9MQ6tfqQP9GvVgsGUY/ry4+ DjmrFpLCGl/5VWiIUIPUfTUib5jTRw3jCpbxe3m95Wu0qnVXca3zy777RzRe+o882w3c etktj+Z6pbQt5QOoOBhZDaAkAAqno9xWgbT82FjX6tGQDdI1PbzHuP1aCqURk21yzQD2 D+LllGp+zL9kbrAyViwnQY+npb584oZNReAWkR2NSIodJ4JBxJWgVweVcVDChVKYLSbR zuI3tJbCJFcfm62JQaeftCfStil5Z9bpbKfjex5cnbI3VN580/3a0IELw7Ay5g6Zfeif qPvQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id d12-20020a63f24c000000b00578dfa34d95si1533937pgk.574.2023.10.18.00.06.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Oct 2023 00:06:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 466A7807479F; Wed, 18 Oct 2023 00:05:44 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344627AbjJRHF3 (ORCPT <rfc822;zwp10758@gmail.com> + 23 others); Wed, 18 Oct 2023 03:05:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34806 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344635AbjJRHF0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 18 Oct 2023 03:05:26 -0400 Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9DA3AFF for <linux-kernel@vger.kernel.org>; Wed, 18 Oct 2023 00:05:22 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R661e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045192;MF=tianruidong@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0VuPveYH_1697612709; Received: from localhost(mailfrom:tianruidong@linux.alibaba.com fp:SMTPD_---0VuPveYH_1697612709) by smtp.aliyun-inc.com; Wed, 18 Oct 2023 15:05:18 +0800 From: Ruidong Tian <tianruidong@linux.alibaba.com> To: linux-kernel@vger.kernel.org Cc: james.clark@arm.com, coresight@lists.linaro.org, suzuki.poulose@arm.com, mike.leach@linaro.org, alexander.shishkin@linux.intel.com, linux-arm-kernel@lists.infradead.org, Ruidong Tian <tianruidong@linux.alibaba.com> Subject: [PATCH] coresight: etm4x: Enable ETE device accessed via MMIO Date: Wed, 18 Oct 2023 15:05:06 +0800 Message-Id: <20231018070506.65320-1-tianruidong@linux.alibaba.com> X-Mailer: git-send-email 2.33.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H2, 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Wed, 18 Oct 2023 00:05:44 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780076024704543440 X-GMAIL-MSGID: 1780076024704543440 |
Series |
coresight: etm4x: Enable ETE device accessed via MMIO
|
|
Commit Message
Ruidong Tian
Oct. 18, 2023, 7:05 a.m. UTC
The ETM4X driver now assume that all ETE as CPU system instructions
accessed device, in fact the ETE device on some machines also accessed
via MMIO.
Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com>
---
drivers/hwtracing/coresight/coresight-etm4x-core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Comments
On 18/10/2023 08:05, Ruidong Tian wrote: > The ETM4X driver now assume that all ETE as CPU system instructions > accessed device, in fact the ETE device on some machines also accessed > via MMIO. > > Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> Why are we going backwards to MMIO from system instructions ? Is it because of an "unfriendly" hypervisor preventing access ? As such, without a sufficiently acceptable explanation, I am reluctant to make this change Suzuki > --- > drivers/hwtracing/coresight/coresight-etm4x-core.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c > index 285539104bcc..ad298c9cc87e 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -1103,8 +1103,9 @@ static bool etm4_init_iomem_access(struct etmv4_drvdata *drvdata, > * with MMIO. But we cannot touch the OSLK until we are > * sure this is an ETM. So rely only on the TRCDEVARCH. > */ > - if ((devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETMv4x_ARCH) { > - pr_warn_once("TRCDEVARCH doesn't match ETMv4 architecture\n"); > + if ((devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETMv4x_ARCH && > + (devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETE_ARCH) { > + pr_warn_once("TRCDEVARCH doesn't match ETMv4/ETE architecture\n"); > return false; > } >
Hi Suzuki, Now ETM4X driver use MMIO or system instruction depends on this check in function etm4_init_csdev_access: if (drvdata->base) return etm4_init_iomem_access(drvdata, csa); This check always true if firmware provides a address range in ACPI table of ETE, and as a result, the ETE device in this case cannot be successfully probed. I think OS should be compatible with this situation, no matter firmware how to organize ETE information in ACPI table. How do you feel about it? Thank you Ruidong Tian 在 2023/10/18 16:28, Suzuki K Poulose 写道: > On 18/10/2023 08:05, Ruidong Tian wrote: >> The ETM4X driver now assume that all ETE as CPU system instructions >> accessed device, in fact the ETE device on some machines also accessed >> via MMIO. >> >> Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> > > Why are we going backwards to MMIO from system instructions ? Is it > because of an "unfriendly" hypervisor preventing access ? > > As such, without a sufficiently acceptable explanation, I am reluctant > to make this change > > Suzuki > >> --- >> drivers/hwtracing/coresight/coresight-etm4x-core.c | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c >> b/drivers/hwtracing/coresight/coresight-etm4x-core.c >> index 285539104bcc..ad298c9cc87e 100644 >> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c >> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c >> @@ -1103,8 +1103,9 @@ static bool etm4_init_iomem_access(struct >> etmv4_drvdata *drvdata, >> * with MMIO. But we cannot touch the OSLK until we are >> * sure this is an ETM. So rely only on the TRCDEVARCH. >> */ >> - if ((devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETMv4x_ARCH) { >> - pr_warn_once("TRCDEVARCH doesn't match ETMv4 architecture\n"); >> + if ((devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETMv4x_ARCH && >> + (devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETE_ARCH) { >> + pr_warn_once("TRCDEVARCH doesn't match ETMv4/ETE >> architecture\n"); >> return false; >> }
Hi On 18/10/2023 10:30, Ruidong Tian wrote: > Hi Suzuki, > > Now ETM4X driver use MMIO or system instruction depends on this check in > function etm4_init_csdev_access: > > if (drvdata->base) > return etm4_init_iomem_access(drvdata, csa); > > This check always true if firmware provides a address range in ACPI > table of ETE, and as a result, the ETE device in this case cannot be > successfully probed. > > I think OS should be compatible with this situation, no matter firmware > how to organize ETE information in ACPI table. How do you feel about > it? My question is not about "What the patch does". But, why can't we use system instructions on your system, when ETE was designed to be used with that in the first place and get rid of the MMIO. Suzuki > > Thank you > > Ruidong Tian > 在 2023/10/18 16:28, Suzuki K Poulose 写道: >> On 18/10/2023 08:05, Ruidong Tian wrote: >>> The ETM4X driver now assume that all ETE as CPU system instructions >>> accessed device, in fact the ETE device on some machines also accessed >>> via MMIO. >>> >>> Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> >> >> Why are we going backwards to MMIO from system instructions ? Is it >> because of an "unfriendly" hypervisor preventing access ? >> >> As such, without a sufficiently acceptable explanation, I am reluctant >> to make this change >> >> Suzuki >> >>> --- >>> drivers/hwtracing/coresight/coresight-etm4x-core.c | 5 +++-- >>> 1 file changed, 3 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c >>> b/drivers/hwtracing/coresight/coresight-etm4x-core.c >>> index 285539104bcc..ad298c9cc87e 100644 >>> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c >>> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c >>> @@ -1103,8 +1103,9 @@ static bool etm4_init_iomem_access(struct >>> etmv4_drvdata *drvdata, >>> * with MMIO. But we cannot touch the OSLK until we are >>> * sure this is an ETM. So rely only on the TRCDEVARCH. >>> */ >>> - if ((devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETMv4x_ARCH) { >>> - pr_warn_once("TRCDEVARCH doesn't match ETMv4 architecture\n"); >>> + if ((devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETMv4x_ARCH && >>> + (devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETE_ARCH) { >>> + pr_warn_once("TRCDEVARCH doesn't match ETMv4/ETE >>> architecture\n"); >>> return false; >>> }
Hi Suzuki You are right, I review armv9 Spec again, and find that ETE only support system instructions access. This patch is meaningless and need to drop it. Ruidong 在 2023/10/18 17:36, Suzuki K Poulose 写道: > Hi > > On 18/10/2023 10:30, Ruidong Tian wrote: >> Hi Suzuki, >> >> Now ETM4X driver use MMIO or system instruction depends on this check >> in function etm4_init_csdev_access: >> >> if (drvdata->base) >> return etm4_init_iomem_access(drvdata, csa); >> >> This check always true if firmware provides a address range in ACPI >> table of ETE, and as a result, the ETE device in this case cannot be >> successfully probed. >> >> I think OS should be compatible with this situation, no matter firmware >> how to organize ETE information in ACPI table. How do you feel about >> it? > > My question is not about "What the patch does". But, why can't we use > system instructions on your system, when ETE was designed to be used > with that in the first place and get rid of the MMIO. > > Suzuki > >> >> Thank you >> >> Ruidong Tian >> 在 2023/10/18 16:28, Suzuki K Poulose 写道: >>> On 18/10/2023 08:05, Ruidong Tian wrote: >>>> The ETM4X driver now assume that all ETE as CPU system instructions >>>> accessed device, in fact the ETE device on some machines also accessed >>>> via MMIO. >>>> >>>> Signed-off-by: Ruidong Tian <tianruidong@linux.alibaba.com> >>> >>> Why are we going backwards to MMIO from system instructions ? Is it >>> because of an "unfriendly" hypervisor preventing access ? >>> >>> As such, without a sufficiently acceptable explanation, I am reluctant >>> to make this change >>> >>> Suzuki >>> >>>> --- >>>> drivers/hwtracing/coresight/coresight-etm4x-core.c | 5 +++-- >>>> 1 file changed, 3 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c >>>> b/drivers/hwtracing/coresight/coresight-etm4x-core.c >>>> index 285539104bcc..ad298c9cc87e 100644 >>>> --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c >>>> +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c >>>> @@ -1103,8 +1103,9 @@ static bool etm4_init_iomem_access(struct >>>> etmv4_drvdata *drvdata, >>>> * with MMIO. But we cannot touch the OSLK until we are >>>> * sure this is an ETM. So rely only on the TRCDEVARCH. >>>> */ >>>> - if ((devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETMv4x_ARCH) { >>>> - pr_warn_once("TRCDEVARCH doesn't match ETMv4 >>>> architecture\n"); >>>> + if ((devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETMv4x_ARCH && >>>> + (devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETE_ARCH) { >>>> + pr_warn_once("TRCDEVARCH doesn't match ETMv4/ETE >>>> architecture\n"); >>>> return false; >>>> }
diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c index 285539104bcc..ad298c9cc87e 100644 --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c @@ -1103,8 +1103,9 @@ static bool etm4_init_iomem_access(struct etmv4_drvdata *drvdata, * with MMIO. But we cannot touch the OSLK until we are * sure this is an ETM. So rely only on the TRCDEVARCH. */ - if ((devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETMv4x_ARCH) { - pr_warn_once("TRCDEVARCH doesn't match ETMv4 architecture\n"); + if ((devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETMv4x_ARCH && + (devarch & ETM_DEVARCH_ID_MASK) != ETM_DEVARCH_ETE_ARCH) { + pr_warn_once("TRCDEVARCH doesn't match ETMv4/ETE architecture\n"); return false; }