Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp710071pxu; Mon, 23 Nov 2020 02:01:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJz5+Cl4i96nOQFIpU/jEXN5E5uF282w/K1wwI6J+T7hhmCCsgQue9sT93OdaF8w23sL/0o4 X-Received: by 2002:a17:906:fa86:: with SMTP id lt6mr8889043ejb.483.1606125697335; Mon, 23 Nov 2020 02:01:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606125697; cv=none; d=google.com; s=arc-20160816; b=kXDk/rH9ZAz8332kS52hsaPFIL4Oebz5CYhjKftLv8QWnhJNoLO4Qq7yPOtdZmrCnW kSQIWcEP1CKRZMJTCvWAVFn7myJ5iYqA4QM++jGyLPcOGgZPQ1P7m3tUZoJg3JZQCz6b ZfJIwhTgegtBcircq3K2dnzWYcRgWaHgAsSXBf0eceoSBvVpl/d6DXZX4fS0q4PKLSF0 CZzybCJ9b4oT7g0yFkNe5aSDNZxfYznDwEl3rciPtR1Q1/mesMlsf6VzGERFgEpZXFCd T/srDq1E/dCb53otOaGD9rOl1HDZrLZ98P1WhlrV+99wIc2eSq/H4vyXln0GvqKU/Mek oglA== 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:from:references :cc:to:subject; bh=dG7qPH2WgoUgBWZMh4s3ULeMkUyx1Whmd5LxCMfKF6c=; b=Q/qekcaQVnU2wE5ndoLmvi/Nw2bDT3955DotElI8jKP887xgNoLwDTf9wUeS0p9w8q 3zJPd3HBipI9Yio3zIF3m7AxqABY9p0yoiGMd9XRhRQdDDOnyP/3quRRyd4tvWO1yNZQ B7cVBTkzzflf6hoolXJjMZx0jOI+yXjAYGxC/xl1HlJqeyQ9bfWCpwdDxQaCD0/Z8zJO NuJMk+J5p/oHxfjqOUpp5zz8O9/ai/Q3baxz+QYdJ8kKX0CnjpIySLwFQWq01kxDub6Z HfrntvnfDiyWzfzjdu7cdEYg7soWtDRoceYsz7S/FqzFeQ84nI82JaeoWGwj9W1knYH5 4+SA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h14si6474972eje.325.2020.11.23.02.01.14; Mon, 23 Nov 2020 02:01:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728582AbgKWJ4i (ORCPT + 99 others); Mon, 23 Nov 2020 04:56:38 -0500 Received: from foss.arm.com ([217.140.110.172]:39282 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728571AbgKWJ4h (ORCPT ); Mon, 23 Nov 2020 04:56:37 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CD6E1101E; Mon, 23 Nov 2020 01:56:36 -0800 (PST) Received: from [10.57.53.209] (unknown [10.57.53.209]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5C8B83F70D; Mon, 23 Nov 2020 01:56:35 -0800 (PST) Subject: Re: [RFC 06/11] coresight: ete: Detect ETE as one of the supported ETMs To: Tingwei Zhang , Anshuman Khandual Cc: coresight@lists.linaro.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, mike.leach@linaro.org References: <1605012309-24812-1-git-send-email-anshuman.khandual@arm.com> <1605012309-24812-7-git-send-email-anshuman.khandual@arm.com> <20201114053650.GA28964@codeaurora.org> From: Suzuki K Poulose Message-ID: <4b03b32c-edca-a19a-e10e-40d6fcd3cfcd@arm.com> Date: Mon, 23 Nov 2020 09:56:28 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201114053650.GA28964@codeaurora.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Tingwei, On 11/14/20 5:36 AM, Tingwei Zhang wrote: > Hi Anshuman, > > On Tue, Nov 10, 2020 at 08:45:04PM +0800, Anshuman Khandual wrote: >> From: Suzuki K Poulose >> >> Add ETE as one of the supported device types we support >> with ETM4x driver. The devices are named following the >> existing convention as ete. >> >> ETE mandates that the trace resource status register is programmed >> before the tracing is turned on. For the moment simply write to >> it indicating TraceActive. >> >> Signed-off-by: Suzuki K Poulose >> Signed-off-by: Anshuman Khandual >> --- >> @@ -1742,6 +1758,19 @@ static int etm4_probe(struct device *dev, void >> __iomem *base) >> if (!desc.access.io_mem || >> fwnode_property_present(dev_fwnode(dev), "qcom,skip-power-up")) >> drvdata->skip_power_up = true; >> + major = ETM_ARCH_MAJOR_VERSION(drvdata->arch); >> + minor = ETM_ARCH_MINOR_VERSION(drvdata->arch); >> + if (drvdata->arch >= ETM_ARCH_ETE) { >> + type_name = "ete"; >> + major -= 4; >> + } else { >> + type_name = "etm"; >> + } >> + > When trace unit supports ETE, could it be still compatible with ETMv4.4? > Can use selectively use it as ETM instead of ETE? No. Even though most of the register sets are compatible, there are additional restrictions and some new rules for the ETE. So, when you treat the ETE as an ETMv4.4, you could be treading into "UNPREDICTABLE" behaviors. Suzuki