From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B10852FCC1D for ; Mon, 22 Dec 2025 06:58:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766386738; cv=none; b=uwsFEaMprZQOxcnBlI51vPG6YtQoPsRiFyVmnPjLygsAjdB6POKxVZ3hl6e2Qunr6uq3QrRSqIbAPTRifdAiVlsSHeM+btiJSnDrNkPz+Nle2LoWAtXQHHZiX0cyVzyD1GtmhjMbRPS2oRqZuvBxCFNeRu0X0mc1pg4KtKcVeYA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766386738; c=relaxed/simple; bh=BC2DATRVLjyGGrI+/IOZpGrlevdSZVA+kZM7aOv6gs8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=KitammC4t50PKMxWZwqYl0ipoMliYXanaYDpcciTczvBffGiZrH6b5dPUaku5MoGRC74jTU6FuAjWu7gZTXJApd1q9ydq6hWK3Dt1dc9WJgoyzYxFqwSKwSWw7kNzn84Yx/04EggX83UlIAdc5x+Nk8ECvkyV4kDsaiy+xObrik= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=JOKWRQT/; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=cgwdBUjB; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="JOKWRQT/"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="cgwdBUjB" Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 5BM1j44S3964176 for ; Mon, 22 Dec 2025 06:58:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= SMxuqKVWm3OclsZ+GWtTTlP0TisA0si8nmJC4yO6AdI=; b=JOKWRQT/Rb5Me+Q0 IADVjaPsTvHas15qk1e4hTv0HmtQWVt32pwpLO7ZhwLBuQgwxuyXkbeEbOOYHcD7 zAfxBttIlnzjdNDMSQXdHLS6/lNEDkqu/z8tlp1FDjqXeZ+ofaE18ADp5EB0/uLV UYFajkuRb6//ncxlhA+sA6SpKy1qbddJoNTHxmLuWh0gPXC2ufaGKZshVw6uNdyz Xsn8Kw8bsE82CT3itnV8H3wmHX8e2PyZzd0Ckra5cwq4dV/8Yl9Dx/IpO+E+n78E Q+x9uJbVlzKXkm6mDWz1E2L3TRkPEN/nICrUS6KJSW/AXfM5B/GO9lXDqjnrFxHD vBpI3w== Received: from mail-pf1-f200.google.com (mail-pf1-f200.google.com [209.85.210.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4b6vk6grtw-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 22 Dec 2025 06:58:55 +0000 (GMT) Received: by mail-pf1-f200.google.com with SMTP id d2e1a72fcca58-7f046e16d50so6082929b3a.3 for ; Sun, 21 Dec 2025 22:58:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1766386735; x=1766991535; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=SMxuqKVWm3OclsZ+GWtTTlP0TisA0si8nmJC4yO6AdI=; b=cgwdBUjB4aHF1yeGsVlSlK84/IGArPCMnGO/VyR70fxLy2oj8GOe9cCV4nf6u00An1 4uRQ838+GIVzOhN8bQZ8VO28wukxmmXrWmh+CuajGvVJIW9F2K9GjQzkEphjKpSqs1xM KowBS9VISP24EIRlJRzYx6j5gCFhRnZjHhSEzaRVMEF+qhcm8KiNb4wbcckefuylbsFb iX+sPUW0zCSU9N9ZzIbuaoG6DYLp/ZSqfqhARq2QPIwx0XiF1EVkKqUb5W7izZdQhQbl DHus3LExisb7TNJf8j6/LF2AcRHQv3c8g+6e79B4DxqLONGOSFtmKUxCwjoGaPEvT6D7 qBtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766386735; x=1766991535; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SMxuqKVWm3OclsZ+GWtTTlP0TisA0si8nmJC4yO6AdI=; b=cj9PxLLNUJMrhDon0DrMyEoyRcRPQALN+cOvWqZV3BV7LXrXNUMAY4K6OGhTYdHsQb rrcMPyofTKGcMy9Fq6seH2GubykR7GROanm+88I6AzQqBt1vJqYjiBmJtDZGSgedk6IQ 46Bs0UQihypLh93dkt2mlo+v0nv0hEaEa9jUyfzT0HDFkZl2+E84let5AkF404WQqp9D hM+XU4BwwiHV9oUC54uzVP19+gjGNDCDDHShfx+Y9kF4M8oBB5GayzEY+8gL0QSf04rx tYCVhwGB5q06YQgQ06IdHT19cmgjG6ZnKICg8EfjGz2mS+0z09QYToe3NV3d8mUlin7k y4ww== X-Forwarded-Encrypted: i=1; AJvYcCUzN3BINojMzg8M2qNeEcjqlr7Lq1QzAn9Cnvf7CCV877KgYQxixmJHWAmEewEdXcInanv3CYBuZi8Cpp4=@vger.kernel.org X-Gm-Message-State: AOJu0Yx73cRQftS8q4X2R+g6AeibZRs1WjYQO++YRAU5zIkl6sysKfWC 9bDi8m9Xc5oLJmAA+/slKjLKFIOlUHoVcR2pU7+yBtp0H7Ul+KBmRRwK2icSk1T7chgCRQ/dxgP ECumSPMnN/JY0ynYIArs+bk47m3JhbMCTnslbDTk6Hj/RctjOSo+b0RNwrTRYBvTeFio= X-Gm-Gg: AY/fxX761nhgZZOf0534bX7+dK0DLnVx7nyxCrO4tbQaqAH8S8Fjp8zFej9Owao0SPg l5fbbLnSmYGfzmUFanPqB2rAXNzhif2M33J9Z775m2nhLpb6Z6ZCabONhLl0PG6MmX3YSDIxjuZ MNAoBFkEoVjcIkMdDQmdAjARqmvazdohDCxWq6oWBVK0mshhTXURazj+bFv2bw/kLiK9Rkz5G73 uV8P25CflBLb79HKzmkFAL5VUvzvAm/AM+rJd5KdqdsHO20rh8fJpxfgicNTvBUMDb59YaZJq1b PXh94OC0WfxN0Vs8q6CI2OemwrAwbYX2dyVxicDbYSpNdBJ+zOHUhNgrmGZTn6KOTeGmHDYYvZ7 ngDh6XJvpaWzsNxcxo3CmFMuzsdCMKVs7T7qa63jP5EuH6wiFykVXPp0G13oBYkU/aI+Ic/6TMg I= X-Received: by 2002:a05:6a00:7613:b0:7ff:acc3:2f40 with SMTP id d2e1a72fcca58-7ffacc33e69mr7059146b3a.26.1766386735068; Sun, 21 Dec 2025 22:58:55 -0800 (PST) X-Google-Smtp-Source: AGHT+IEO+6I8pHuD+xmFtIYOJqkUxAi0nAsXhcjYzo9deCdZ2wwdODhLF8KzB5WTxUNjuepx5+QCTg== X-Received: by 2002:a05:6a00:7613:b0:7ff:acc3:2f40 with SMTP id d2e1a72fcca58-7ffacc33e69mr7059129b3a.26.1766386734539; Sun, 21 Dec 2025 22:58:54 -0800 (PST) Received: from [10.133.33.169] (tpe-colo-wan-fw-bordernet.qualcomm.com. [103.229.16.4]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7ff7e0a1a2asm9254539b3a.41.2025.12.21.22.58.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 21 Dec 2025 22:58:54 -0800 (PST) Message-ID: <097dbefb-f679-40da-bce4-d6e09dc4cf08@oss.qualcomm.com> Date: Mon, 22 Dec 2025 14:58:47 +0800 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 To: Suzuki K Poulose , Krzysztof Kozlowski , 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> <2db74a3e-4aeb-4e87-9fe8-5c9693bfb67c@arm.com> <46afd4f6-f287-4d19-bc68-f2f6eac36e6a@oss.qualcomm.com> <95ac571a-1c8f-45d9-9874-648d4123ce18@arm.com> Content-Language: en-US From: Jie Gan In-Reply-To: <95ac571a-1c8f-45d9-9874-648d4123ce18@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-ORIG-GUID: R-aSv1qcnZUZu4UJyOjdmaOYCvljTFTO X-Authority-Analysis: v=2.4 cv=cuuWUl4i c=1 sm=1 tr=0 ts=6948ec2f cx=c_pps a=mDZGXZTwRPZaeRUbqKGCBw==:117 a=nuhDOHQX5FNHPW3J6Bj6AA==:17 a=IkcTkHD0fZMA:10 a=wP3pNCr1ah4A:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=KKAkSRfTAAAA:8 a=EUspDBNiAAAA:8 a=W9kkhuXnUgcddjO-hjkA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=zc0IvFSfCIW2DFIPzwfm:22 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMjIyMDA2MSBTYWx0ZWRfX7fO4+NFZ32q7 2sHSuwF1bfryuTqypR3rvCastpTumHK5LZ2UrrRqLT3Q5RDJ9HQzvzxYUWindYpdZWnJM8fVr0r TAQ0tq1ewhdqoO3EGm2glIjFq0xhX6omkW4Hcw15x9oJwjoiRLAWfN1eBCTgBI1YcdKiX6c2axm +P+OitD0RpivjMgOmzpyvrxgJLdrO+N2pBhUVXXxqCHwQ6F36wtnw+evI7IBXscEdTaeu2NmT29 tiF/ujVOJUWVwcFto/4CSp3SD6EW/o+BNeTXd5Xwfwi3bwjUrE3o8hMWlHo0vQLtPX0UQ6IBzIn +80NkAYnVH1LJslzbwbWNUV8tN0sl24WDTPS1dM2DU9qaC+d++koQ6wGWbMFMLDHxxI3mbrpXR6 a9Mz0mexOZanR1iPNTwx/L1L6M3aT6+cAcwdSxff72DNMmR/f54OZKrvoyIVwzW2Jh3Z+ZSpeCd PJicbpt+9T2PIpcl8eQ== X-Proofpoint-GUID: R-aSv1qcnZUZu4UJyOjdmaOYCvljTFTO X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2025-12-21_05,2025-12-19_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 lowpriorityscore=0 adultscore=0 malwarescore=0 priorityscore=1501 spamscore=0 bulkscore=0 suspectscore=0 clxscore=1015 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2512120000 definitions=main-2512220061 On 12/19/2025 5:54 PM, Suzuki K Poulose wrote: > On 19/12/2025 02:05, Jie Gan wrote: >> >> >> On 12/19/2025 7:19 AM, Suzuki K Poulose wrote: >>> 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. >>> >> >> Sorry for the misunderstanding. >> >> Each ETR device should have its own interrupt line and an IRQ register >> within the CTCU device, as defined by the specification. In existing >> projects, the maximum supported number of ETR devices is 2. >> >> Each interrupt is directly mapped to a specific ETR device, for example: >> tmc@1000 → interrupt line 0 >> tmc@1001 → interrupt line 1 >> >> The suggestion to identify devices by ‘ports’ is much clearer than my >> previous explanation, as it explicitly shows which device is connected >> to which port. > > Thanks for confirming. > >> >>>>>>> + >>>>>>> +  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). >>> >> >> Got your point and it's much clearer. >> >>> 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. >>>> >> >> My previous explanation was definitely unclear. As Suzuki suggested, >> mapping the interrupt to the port number (to identify the relevant >> device based on topology) makes sense and provides a much easier way >> to understand the relationship between the interrupt and the ETR device. >> >> So with the suggestion, here is the new description about the interrupts: >> >>    interrupts: >>      items: >>        - description: Interrupt for the ETR device connected to in-port0. >>        - description: Interrupt for the ETR device connected to in-port1. >> >>   interrupt-names: >>      items: >>       - const: port0 >>       - const: port1 > > Which brings us back to the question I posted in the previous version. > Do we really need a "name" or are there other ways to define, a sparse > list of interrupts ? > Each interrupt is dedicated to a specific ETR device. While we can retrieve the list of interrupts using of_irq_get, we cannot guarantee that the obtained interrupt corresponds to the correct ETR device? I believe it would be better to have an interrupt-name property, so we can assign the name in the data structure and retrieve the interrupt by its name, ensuring it maps to the correct ETR device. Thanks, Jie