From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 251821FF1C4; Thu, 18 Dec 2025 23:19:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766099993; cv=none; b=dE4l4VJlyzPLYaNiGtNnI/xGhafeMhnYzd05h+6JPLgQz3/1+wNyW0UwNG6W0b/oxnwfOeF/4VjixBNpHpX/zKmAabDebIPeiVWWMnFdK6N3UqKXmziNu6OiXKl/laUnpMR5JpHkKwK301c0wwtGXYF+eTn/Yi32Uegl3mXqrDU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766099993; c=relaxed/simple; bh=0vLRMM7En8km6VApfO++vh0HWCVI8UGkTtiJWFcXaS4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=E+LrKpwb6ag+nO3buWnZ6SC3A7aEXmxw2zO/NbdaUior9UZL0zZ+e9ghlxcPhfHXSPbJRKL0OGZNTs7w8rWw2cNKVKCsEe4klH2K0UXL/YQXbTii2UgW0U9h4a0UnqK5CVE3S60QWhGUPJzGan54Kd/zs7KwscMtosrKK/UjU+Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 F10FFFEC; Thu, 18 Dec 2025 15:19:42 -0800 (PST) Received: from [10.57.74.203] (unknown [10.57.74.203]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1D3113F73F; Thu, 18 Dec 2025 15:19:46 -0800 (PST) Message-ID: <2db74a3e-4aeb-4e87-9fe8-5c9693bfb67c@arm.com> Date: Thu, 18 Dec 2025 23:19:45 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 5/8] dt-bindings: arm: add an interrupt property for Coresight CTCU Content-Language: en-GB To: Krzysztof Kozlowski , Jie Gan , Rob Herring Cc: Mike Leach , James Clark , Alexander Shishkin , Krzysztof Kozlowski , Conor Dooley , Tingwei Zhang , Mao Jinlong , Bjorn Andersson , Konrad Dybcio , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org References: <20251211-enable-byte-cntr-for-ctcu-v8-0-3e12ff313191@oss.qualcomm.com> <20251211-enable-byte-cntr-for-ctcu-v8-5-3e12ff313191@oss.qualcomm.com> <20251211133723.GA859302-robh@kernel.org> From: Suzuki K Poulose In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 18/12/2025 10:17, Krzysztof Kozlowski wrote: > On 12/12/2025 02:12, Jie Gan wrote: >> >> >> On 12/11/2025 9:37 PM, Rob Herring wrote: >>> On Thu, Dec 11, 2025 at 02:10:44PM +0800, Jie Gan wrote: >>>> Add an interrupt property to CTCU device. The interrupt will be triggered >>>> when the data size in the ETR buffer exceeds the threshold of the >>>> BYTECNTRVAL register. Programming a threshold in the BYTECNTRVAL register >>>> of CTCU device will enable the interrupt. >>>> >>>> Acked-by: Krzysztof Kozlowski >>>> Reviewed-by: Mike Leach >>>> Signed-off-by: Jie Gan >>>> --- >>>> .../devicetree/bindings/arm/qcom,coresight-ctcu.yaml | 17 +++++++++++++++++ >>>> 1 file changed, 17 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>> index c969c16c21ef..90f88cc6cd3e 100644 >>>> --- a/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>> +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml >>>> @@ -39,6 +39,16 @@ properties: >>>> items: >>>> - const: apb >>>> >>>> + interrupts: >>>> + items: >>>> + - description: Byte cntr interrupt for the first etr device >>>> + - description: Byte cntr interrupt for the second etr device This is really vague. How do you define first vs second ? Probe order ? No way. This must be the "port" number to which the ETR is connected to the CTCU. IIUC, there is a config area for each ETR (e.g., trace id filter) connected to the CTCU. I was under the assumption that they are identified as "ports" (input ports). I don't really understand how this interrupt mapping works now. Please explain it clearly. >>>> + >>>> + interrupt-names: >>>> + items: >>>> + - const: etrirq0 >>>> + - const: etrirq1 >>> >>> Names are kind of pointless when it is just foo. >> >> Hi Rob, >> >> I was naming them as etr0/etr1. Are these names acceptable? > > Obviously irq is redundant, but how does etr0 solves the problem of > calling it foo0? > > I don't think you really read Rob's comment. > >> The interrupts are assigned exclusively to a specific ETR device. >> >> But Suzuki is concerned that this might cause confusion because the ETR >> device is named randomly in the driver. Suzuki suggested using ‘port-0’ >> and ‘port-1’ and would also like to hear your feedback on these names. > > There is no confusion here. Writing bindings luckily clarifies this what > the indices in the array mean. The point is there are "n" interrupts. Question is, could there be more devices(ETRs) connected to the CTCU than "n". e.g., Lets CTCU can control upto 4 ETRs and on a particular system, the TMC-ETR0 -> CTCU-Port0 TMC-ETR1 -> CTCU-Port2 TMC-ETR2 -> CTCU-Port3 Now, how many interrupts are described in the DT ? How do we map which interrupts correspond to the CTCU-Portn. (Finding the TMC-ETRx back from the port is possible, with the topology). This is what I raised in the previous version. Again, happy to hear if there is a standard way to describe the interrupts. Suzuki > >> >> Usually, the probe sequence follows the order of the addresses. In our >> specification, ‘ETR0’ is always probed before ‘ETR1’ because its address >> is lower. > > How is this even relevant? You are answering to something completely > different, so I don't think you really tried to understand review. > > > > Best regards, > Krzysztof