Received: by 2002:a05:7412:98c1:b0:fa:551:50a7 with SMTP id kc1csp1545269rdb; Mon, 8 Jan 2024 02:43:05 -0800 (PST) X-Google-Smtp-Source: AGHT+IGte3t/hZIrJOouORotGuK7LI6IzUNclmbCwT4eLlJMplIYYASJfqiD0OR//TdmssOBSEfS X-Received: by 2002:a17:90b:3d3:b0:28b:e576:3ab2 with SMTP id go19-20020a17090b03d300b0028be5763ab2mr1336774pjb.44.1704710585049; Mon, 08 Jan 2024 02:43:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704710585; cv=none; d=google.com; s=arc-20160816; b=tWJnFXXAUBam01NHESo3gamj9XDs6IlNX60lHhrOeXNS+IPxJM1RiK5BR2YLAk4VaA sfp5BTF+pmSp42ejtkIZm9k+QdpXUdTPSW9FVt1hqGaan1ZYVU6Z/Lj5tBOY9SAvG87C E/HXK8+njPzYgKAaP/M6zkdJFfTODgK1hfsjHgQ//bA9SBcfuxlfU7FlZOdvYHRdqfwe vUR8NW1r/qMJeW9ki3WiWpm4No2vgc0uXUm2Ln+wjuxXLuAa9EgWCEK7m0Ucg0RyCy2B OusZNtPFRJz7WQEpwmctKar9PiHt5Bp+tkFg8Zvxg6No8h58U/d8Z8bFlkK4qDKiNa50 BCLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=dvNYc6mXw795UNDW62mbhexLLvbAFowXWR3nwPa9fcc=; fh=mbscLyIbiqeKhAAvOgq1FD2y7FAkicSP1DMkcnlFuFE=; b=UApclma+wAHARZzaQMZMs35AI22a3EwnNZu7XlM/U6GsGobxjl+5SLiqBLU9qukHxs 4L9vvCUYRDxgaTcdn9KK6SF8mtEH57XiKSWFBMwEFZ48rgG7hsfDlOzGkod3PicZg+e+ NyEZT5zE2A7ukLeF2GlznO+tACPf7cyrnlSvJ0g1VgRrMhp8sxsan+jI9UizGbrnth1C xij16oulFqIun3lBv2GPxs4K3dzlH639b0GlUlD9BTqfrvHXAeK4P3Auku88BHK6gmc0 VWidJLoG51IXOYx4JjvrkqIbRgz7/pGrM4HeA0C13ptmmhLhxYvhuTZQnsv86vtMK7br KiJw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-19342-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-19342-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id m20-20020a17090ab79400b0028c21de8e0csi5470663pjr.183.2024.01.08.02.43.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jan 2024 02:43:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-19342-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-19342-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-19342-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id C9926B209F1 for ; Mon, 8 Jan 2024 10:43:01 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 700DF14008; Mon, 8 Jan 2024 10:42:51 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A71FD13FFB; Mon, 8 Jan 2024 10:42:47 +0000 (UTC) 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 556FE2F4; Mon, 8 Jan 2024 02:43:27 -0800 (PST) Received: from [10.1.197.1] (ewhatever.cambridge.arm.com [10.1.197.1]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BB0923F5A1; Mon, 8 Jan 2024 02:42:38 -0800 (PST) Message-ID: Date: Mon, 8 Jan 2024 10:42:37 +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 v3 6/8] coresight-tpdm: Add timestamp control register support for the CMB To: Tao Zhang , Mathieu Poirier , Alexander Shishkin , Konrad Dybcio , Mike Leach , Rob Herring , Krzysztof Kozlowski Cc: Jinlong Mao , Greg Kroah-Hartman , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Tingwei Zhang , Yuanfang Zhang , Trilok Soni , Song Chai , linux-arm-msm@vger.kernel.org, andersson@kernel.org References: <1700533494-19276-1-git-send-email-quic_taozha@quicinc.com> <1700533494-19276-7-git-send-email-quic_taozha@quicinc.com> <797eadf6-2708-47ad-a61f-88bb0d4fcf28@quicinc.com> <4ae81e28-1791-4128-860f-eb6a83ea3742@arm.com> <616eba43-678c-4bc9-be7e-7b766e8d7c29@quicinc.com> Content-Language: en-US From: Suzuki K Poulose In-Reply-To: <616eba43-678c-4bc9-be7e-7b766e8d7c29@quicinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 05/01/2024 07:49, Tao Zhang wrote: > > On 12/30/2023 5:39 PM, Suzuki K Poulose wrote: >> On 25/12/2023 01:55, Tao Zhang wrote: >>> >>> On 12/20/2023 7:07 PM, Suzuki K Poulose wrote: >>>> On 20/12/2023 09:51, Tao Zhang wrote: >>>>> >>>>> On 12/19/2023 9:51 PM, Suzuki K Poulose wrote: >>>>>> On 19/12/2023 02:43, Tao Zhang wrote: >>>>>>> >>>>>>> On 12/18/2023 6:46 PM, Suzuki K Poulose wrote: >>>>>>>> On 21/11/2023 02:24, Tao Zhang wrote: >>>>>>>>> CMB_TIER register is CMB subunit timestamp insertion enable >>>>>>>>> register. >>>>>>>>> Bit 0 is PATT_TSENAB bit. Set this bit to 1 to request a timestamp >>>>>>>>> following a CMB interface pattern match. Bit 1 is XTRIG_TSENAB >>>>>>>>> bit. >>>>>>>>> Set this bit to 1 to request a timestamp following a CMB CTI >>>>>>>>> timestamp >>>>>>>>> request. Bit 2 is TS_ALL bit. Set this bit to 1 to request >>>>>>>>> timestamp >>>>>>>>> for all packets. >>>>>>>>> >>>>>>>>> Reviewed-by: James Clark >>>>>>>>> Signed-off-by: Tao Zhang >>>>>>>>> Signed-off-by: Jinlong Mao >>>>>>>>> --- >>>>>>>>>   .../testing/sysfs-bus-coresight-devices-tpdm  | 35 ++++++ >>>>>>>>>   drivers/hwtracing/coresight/coresight-tpdm.c  | 116 >>>>>>>>> +++++++++++++++++- >>>>>>>>>   drivers/hwtracing/coresight/coresight-tpdm.h  | 14 +++ >>>>>>>>>   3 files changed, 162 insertions(+), 3 deletions(-) >>>>>>>>> >>>>>>>>> diff --git >>>>>>>>> a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm >>>>>>>>> b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm >>>>>>>>> index 53662ce7c2d0..e0b77107be13 100644 >>>>>>>>> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm >>>>>>>>> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm >>>>>>>>> @@ -214,3 +214,38 @@ KernelVersion    6.7 >>>>>>>>>   Contact:    Jinlong Mao (QUIC) , >>>>>>>>> Tao Zhang (QUIC) >>>>>>>>>   Description: >>>>>>>>>           (RW) Set/Get the mask of the pattern for the CMB >>>>>>>>> subunit TPDM. >>>>>>>>> + >>>>>>>>> +What: /sys/bus/coresight/devices//cmb_patt/enable_ts >>>>>>>>> +Date:        September 2023 >>>>>>>>> +KernelVersion    6.7 >>>>>>>>> +Contact:    Jinlong Mao (QUIC) , Tao >>>>>>>>> Zhang (QUIC) >>>>>>>>> +Description: >>>>>>>>> +        (Write) Set the pattern timestamp of CMB tpdm. Read >>>>>>>>> +        the pattern timestamp of CMB tpdm. >>>>>>>>> + >>>>>>>>> +        Accepts only one of the 2 values -  0 or 1. >>>>>>>>> +        0 : Disable CMB pattern timestamp. >>>>>>>>> +        1 : Enable CMB pattern timestamp. >>>>>>>>> + >>>>>>>>> +What: /sys/bus/coresight/devices//cmb_trig_ts >>>>>>>>> +Date:        September 2023 >>>>>>>>> +KernelVersion    6.7 >>>>>>>>> +Contact:    Jinlong Mao (QUIC) , Tao >>>>>>>>> Zhang (QUIC) >>>>>>>>> +Description: >>>>>>>>> +        (RW) Set/Get the trigger timestamp of the CMB for tpdm. >>>>>>>>> + >>>>>>>>> +        Accepts only one of the 2 values -  0 or 1. >>>>>>>>> +        0 : Set the CMB trigger type to false >>>>>>>>> +        1 : Set the CMB trigger type to true >>>>>>>>> + >>>>>>>>> +What: /sys/bus/coresight/devices//cmb_ts_all >>>>>>>>> +Date:        September 2023 >>>>>>>>> +KernelVersion    6.7 >>>>>>>>> +Contact:    Jinlong Mao (QUIC) , Tao >>>>>>>>> Zhang (QUIC) >>>>>>>>> +Description: >>>>>>>>> +        (RW) Read or write the status of timestamp upon all >>>>>>>>> interface. >>>>>>>>> +        Only value 0 and 1  can be written to this node. Set >>>>>>>>> this node to 1 to requeset >>>>>>>>> +        timestamp to all trace packet. >>>>>>>>> +        Accepts only one of the 2 values -  0 or 1. >>>>>>>>> +        0 : Disable the timestamp of all trace packets. >>>>>>>>> +        1 : Enable the timestamp of all trace packets. >>>>>>>>> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c >>>>>>>>> b/drivers/hwtracing/coresight/coresight-tpdm.c >>>>>>>>> index 894d4309f1c7..f6cda5616e84 100644 >>>>>>>>> --- a/drivers/hwtracing/coresight/coresight-tpdm.c >>>>>>>>> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c >>>>>>>>> @@ -331,6 +331,36 @@ static void tpdm_enable_dsb(struct >>>>>>>>> tpdm_drvdata *drvdata) >>>>>>>>>       writel_relaxed(val, drvdata->base + TPDM_DSB_CR); >>>>>>>>>   } >>>>>>>>>   +static void set_cmb_tier(struct tpdm_drvdata *drvdata) >>>>>>>>> +{ >>>>>>>>> +    u32 val; >>>>>>>>> + >>>>>>>>> +    val = readl_relaxed(drvdata->base + TPDM_CMB_TIER); >>>>>>>>> + >>>>>>>>> +    /* Clear all relevant fields */ >>>>>>>>> +    val &= ~(TPDM_CMB_TIER_PATT_TSENAB | TPDM_CMB_TIER_TS_ALL | >>>>>>>>> +         TPDM_CMB_TIER_XTRIG_TSENAB); >>>>>>>>> + >>>>>>>>> +    /* Set pattern timestamp type and enablement */ >>>>>>>>> +    if (drvdata->cmb->patt_ts) >>>>>>>>> +        val |= TPDM_CMB_TIER_PATT_TSENAB; >>>>>>>> >>>>>>>>  -- cut -- >>>>>>>>> +    else >>>>>>>>> +        val &= ~TPDM_CMB_TIER_PATT_TSENAB; >>>>>>>> >>>>>>>> >>>>>>>> All the else cases in this function are superfluous. Please >>>>>>>> remove all >>>>>>>> of them. >>>>>>> I will update this in the next patch. >>>>>>>> >>>>>>>>> + >>>>>>>>> +    /* Set trigger timestamp */ >>>>>>>>> +    if (drvdata->cmb->trig_ts) >>>>>>>>> +        val |= TPDM_CMB_TIER_XTRIG_TSENAB; >>>>>>>>> +    else >>>>>>>>> +        val &= ~TPDM_CMB_TIER_XTRIG_TSENAB; >>>>>>>>> + >>>>>>>>> +    /* Set all timestamp enablement*/ >>>>>>>>> +    if (drvdata->cmb->ts_all) >>>>>>>>> +        val |= TPDM_CMB_TIER_TS_ALL; >>>>>>>>> +    else >>>>>>>>> +        val &= ~TPDM_CMB_TIER_TS_ALL; >>>>>>>>> +    writel_relaxed(val, drvdata->base + TPDM_CMB_TIER); >>>>>>>>> +} >>>>>>>>> + >>>>>>>>>   static void tpdm_enable_cmb(struct tpdm_drvdata *drvdata) >>>>>>>>>   { >>>>>>>>>       u32 val, i; >>>>>>>>> @@ -347,6 +377,8 @@ static void tpdm_enable_cmb(struct >>>>>>>>> tpdm_drvdata *drvdata) >>>>>>>>>                   drvdata->base + TPDM_CMB_XPMR(i)); >>>>>>>>>       } >>>>>>>>>   +    set_cmb_tier(drvdata); >>>>>>>>> + >>>>>>>>>       val = readl_relaxed(drvdata->base + TPDM_CMB_CR); >>>>>>>>>       /* >>>>>>>>>        * Set to 0 for continuous CMB collection mode, >>>>>>>>> @@ -695,9 +727,17 @@ static ssize_t enable_ts_show(struct >>>>>>>>> device *dev, >>>>>>>>>                     char *buf) >>>>>>>>>   { >>>>>>>>>       struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent); >>>>>>>>> +    ssize_t size = 0; >>>>>>>>>   -    return sysfs_emit(buf, "%u\n", >>>>>>>>> -             (unsigned int)drvdata->dsb->patt_ts); >>>>>>>>> +    if (tpdm_has_dsb_dataset(drvdata)) >>>>>>>>> +        size = sysfs_emit(buf, "%u\n", >>>>>>>>> +                 (unsigned int)drvdata->dsb->patt_ts); >>>>>>>>> + >>>>>>>>> +    if (tpdm_has_cmb_dataset(drvdata)) >>>>>>>>> +        size = sysfs_emit(buf, "%u\n", >>>>>>>>> +                 (unsigned int)drvdata->cmb->patt_ts); >>>>>>>> >>>>>>>> Why does this need to show two values ? This must only show ONE >>>>>>>> value. >>>>>>>> How you deduce that might be based on the availability of the >>>>>>>> feature >>>>>>>> set. Or store the TS value in the drvdata and use that instead for >>>>>>>> controlling CMB/DSB. >>>>>>> >>>>>>> Since both of CMB/DSB need to have "enable_ts" SysFs file, can I >>>>>>> separate them >>>>>> >>>>>> The question really is, do we need fine grained control. i.e., >>>>>> >>>>>> enable TS for DSB but not for CMB or vice versa. >>>>>> >>>>>> I am not an expert on the usage scenario of the same. So, if >>>>>> you/Qcomm >>>>>> thinks the users need separate, fine grained control for timestamp >>>>>> for the DSB and CMB, then yes, follow your recommendation below. >>>>>> i.e., tpdm.../dsb_patt/enable_ts >>>>>> >>>>>>> as "enable_dsb_ts" and "enable_cmb_ts"? The path will be like below. >>>>>>> >>>>>>> tpdm0/dsb_patt/enable_dsb_ts >>>>>> >>>>>> You don't need enable_dsb_ts. It could be "enable_ts" >>>>>> >>>>>>> >>>>>>> tpdm1/cmb_patt/enable_cmb_ts >>>>>>> >>>>>>> Is this design appropriate? >>>>>> >>>>>> >>>>>> Otherwise, stick to single enable_ts : which enables the ts for both >>>>>> CMB/DSB. And it only ever show one value : 0 (TS is disabled for both >>>>>> CMB/DSB) 1 : TS enabled for both. >>>>> >>>>> We have a very special case, such as the TPDM supporting both CMB and >>>>> >>>>> DSB datasets. Although this case is very rare, it still exists. >>>>> >>>>> Can I use the data bit to instruct whether timestamp is enabled for >>>>> CMB/DSB or not? For example, >>>>> >>>>> size = sysfs_emit(buf, "%u\n", >>>>>                  (unsigned int)(drvdata->dsb->patt_ts << 1 | >>>>> drvdata->cmb->patt_ts)); >>>>> >>>>> Thus, this value can instruct the following situations. >>>>> >>>>> 0 - TS is disabled for both CMB/DSB >>>>> >>>>> 1 - TS is enabled for CMB >>>>> >>>>> 2 - TS is enabled for DSB >>>>> >>>>> 3 - TS is enabled for both >>>>> >>>>> Is this approach acceptable? >>>>> >>>> >>>> No, please stick to separate controls for TS. Do not complicate >>>> the user interface. >>>> >>>> i.e., >>>> tpdm0/dsb_patt/enable_ts >>>> tpdm0/cmb_patt/enable_ts >>> >>> We need to be able to control/show dsb and cmb timestamp enablement >>> independently. >>> >>> Can we achieve this requirement if we use a sysfs file with the same >>> name? >> >> They are independent and in their respective directory (group) for CMB >> and DSB. What am I missing ? >> e.g., if you want to enable TS for DSB, you do : >> >> $ echo 1 > dsb_patt/enable_ts >> >> And that only works for DSB not for CMB. > > We have a special case that the TPDM supports both DSB and CMB dataset. > In this special case, when we > > issue this command to enable timestamp, it will call enable_ts_store > API, right? > >     if (tpdm_has_dsb_dataset(drvdata)) >         drvdata->dsb->patt_ts = !!val; > >     if (tpdm_has_cmb_dataset(drvdata)) >         drvdata->cmb->patt_ts = !!val; I don't understand. If they both are under different subgroups, why should they be conflicting ? Are you not able to distinguish them, when you creat those attributes ? i.e., create two different "attributes" ? See below. > Since this special TPDM supports both DSB and CMB dataset, both DSB > patt_ts and CMB patt_ts will be set > > in this case even if I only configure the file in the DSB directory, right? > > This is the problem we have now. > >>>>>>>> >>>>>>>> >>>>>>>>> + >>>>>>>>> +    return size; >>>>>>>>>   } >>>>>>>>>     /* >>>>>>>>> @@ -715,8 +755,13 @@ static ssize_t enable_ts_store(struct >>>>>>>>> device *dev, >>>>>>>>>           return -EINVAL; >>>>>>>>>         spin_lock(&drvdata->spinlock); >>>>>>>>> -    drvdata->dsb->patt_ts = !!val; >>>>>>>>> +    if (tpdm_has_dsb_dataset(drvdata)) >>>>>>>>> +        drvdata->dsb->patt_ts = !!val; >>>>>>>>> + >>>>>>>>> +    if (tpdm_has_cmb_dataset(drvdata)) >>>>>>>>> +        drvdata->cmb->patt_ts = !!val; >>>>>>>>>       spin_unlock(&drvdata->spinlock); >>>>>>>>> + >>>>>>>>>       return size; >>>>>>>>>   } >>>>>>>>>   static DEVICE_ATTR_RW(enable_ts); Do not overload the same for both DSB and CMB. Create one for each in DSB and CMB ? They could share the same show/store routines, but could be done with additional variable to indicate which attribute they are controlling. Like the other attributes, using dev_ext_attribute or such. Suzuki