From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 49777C433E0 for ; Wed, 1 Jul 2020 22:21:19 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EA30B20780 for ; Wed, 1 Jul 2020 22:21:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="2IBQYn2u" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EA30B20780 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Ys1S5Fy6KFqAjMWn+oxFJmRmC2jyeefqrBybIWTTS7o=; b=2IBQYn2ugdlL/DA83HRpSwOYH SMYc0a6wWzkvZNLVf+YtWe/7CkvEjZXeFrxXaY9fZFeo/O7kC6LbzrKBy75JBrIS9suU56PrLW4DE L6iIAVGA4jV5pnLCLq+3OojD1ZHeyE6R77aKlnjzSdDJEo845uWtwt5Vjp81ChM3youyBsdLG0T2l oV/fCNB8DivdNxo7t8+HjZ7dB+1taYKsockOLC3sroXMU9WBv1LwO/tCbphCWY+sLtjrM6vCFGNkf tchN6mW7rX4n9ii0sx4jAp6c8uhSDuLtuqybn7keKAJg9A/3eQTwDaWPCsdVbZT5kmiQXW9/KZM4C zeKaZZj9A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jql5C-0002n8-1h; Wed, 01 Jul 2020 22:19:58 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jql59-0002ma-9x for linux-arm-kernel@lists.infradead.org; Wed, 01 Jul 2020 22:19:56 +0000 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 4BEB21FB; Wed, 1 Jul 2020 15:19:54 -0700 (PDT) Received: from [10.37.12.95] (unknown [10.37.12.95]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D0E413F73C; Wed, 1 Jul 2020 15:19:52 -0700 (PDT) Subject: Re: [PATCH v5 4/5] coresight: sysfs: Allow select default sink on source enable. To: mike.leach@linaro.org, mathieu.poirier@linaro.org References: <20200616164006.15309-1-mike.leach@linaro.org> <20200616164006.15309-5-mike.leach@linaro.org> <20200629174756.GA3724199@xps15> From: Suzuki K Poulose Message-ID: Date: Wed, 1 Jul 2020 23:24:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200701_181955_470567_3468D4FB X-CRM114-Status: GOOD ( 41.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: coresight@lists.linaro.org, corbet@lwn.net, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Mike, Mathieu, On 07/01/2020 05:40 PM, Mike Leach wrote: > Hi Mathieu, > > On Mon, 29 Jun 2020 at 18:47, Mathieu Poirier > wrote: >> >> Hi Mike, >> >> I have applied patches 1 to 3 of this set. Please see below for comments on >> this patch. >> >> On Tue, Jun 16, 2020 at 05:40:05PM +0100, Mike Leach wrote: >>> When enabling a trace source using sysfs, allow the CoreSight system to >>> auto-select a default sink if none has been enabled by the user. >>> >>> Uses the sink select algorithm that uses the default select priorities >>> set when sinks are registered with the system. At present this will >>> prefer ETR over ETB / ETF. >>> >>> Adds a new attribute 'last_sink' to source CoreSight devices. This is set >>> when a source is enabled using sysfs, to the sink that the device will >>> trace into. This applies for both user enabled and default enabled sinks. >>> >>> Signed-off-by: Mike Leach >>> --- >>> drivers/hwtracing/coresight/coresight.c | 39 +++++++++++++++++++++++-- >>> include/linux/coresight.h | 3 ++ >>> 2 files changed, 40 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c >>> index e9c90f2de34a..db39e0b56994 100644 >>> --- a/drivers/hwtracing/coresight/coresight.c >>> +++ b/drivers/hwtracing/coresight/coresight.c >>> @@ -934,6 +934,16 @@ static void coresight_clear_default_sink(struct coresight_device *csdev) >>> } >>> } >>> >>> +static void coresight_set_last_sink_name(struct coresight_device *source, >>> + struct coresight_device *sink) >>> +{ >>> + /* remove current value and set new one if *sink not NULL */ >>> + kfree(source->last_sink); >>> + source->last_sink = NULL; >>> + if (sink) >>> + source->last_sink = kstrdup(dev_name(&sink->dev), GFP_KERNEL); >>> +} >>> + >>> /** coresight_validate_source - make sure a source has the right credentials >>> * @csdev: the device structure for a source. >>> * @function: the function this was called from. >>> @@ -994,8 +1004,15 @@ int coresight_enable(struct coresight_device *csdev) >>> */ >>> sink = coresight_get_enabled_sink(false); >>> if (!sink) { >>> - ret = -EINVAL; >>> - goto out; >>> + /* look for a default sink if nothing enabled */ >>> + sink = coresight_find_default_sink(csdev); >>> + if (!sink) { >>> + ret = -EINVAL; >>> + goto out; >>> + } >>> + /* mark the default as enabled */ >>> + sink->activated = true; >>> + dev_info(&sink->dev, "Enabled default sink."); >> >> I'm very ambivalent about extending the automatic sink selection to the sysfs >> interface, mainly because of the new sysfs entry it requires. > > That's interesting - this was added to overcome Suzuki's objection > that it wasn't possible to determine which sink was in use! I personally don't prefer the auto selection for sysfs mode. And that was one of the arguments to support it. > > However, I think it is important to allow this as once we see systems > with many cores + many sinks, determining the correct sink to enable > becomes much more difficult. > > You said yourself, albeit in relation to perf, that for 1:1 systems, > sink selection should be implicit. This is something I completely > agree with, and hence the automatic selection algorithm that was > chosen to ensure that this is the case. > Is there any reason not to make the same assertion for sysfs? > > Further, this allows sysfs users to write board agnostic tests > (similar to the one Leo wrote for perf) - effectively all we need to > do to test the coresight function on a board is iterate through the > cpus / etms without worrying about the sink in use, then name of which > can be read from the etm and then data read out. The tests could use the "connections" exposed via the sysfs to figure out the appropriate sink for a given source. > > As an aside - last_sink also shows which sink was used should you > happen to explicitly enable two sinks in the etm path (e.g. etf & > etr). > >> I find it >> clunky that users don't have to specify the sink to use but have to explicitly >> disable it after the trace session. > > Sure - but is it not just as clunky to have to figure out which sink > attaches to your etm in the first place? (yes there are topolgy links > now but this is not the most straighforward thing to use) > Ultimately, if you are only using sysfs, you never actually need to > disable the sink to read back data if you don't want to. I am not sure > there are many people who use both syfs and perf in the same session > to collect trace - and these are the ones who would need to be careful > about disabling the sink. The problem lies exactly there. Just like we don't know how many actual sysfs mode users are there, who consume the trace data and use it in a production environment compared to a bring up situation (verifying that the board topology is detected fine and the components are working fine), there could be users of the perf on these systems. Debugging such cases where someone forgot to disable the trace can be a painful process. Like I have said from the beginning, this is not worth the benefit that we get from this code (i.e, figuring out which sink is closer to a source in sysfs mode, when there is an existing infrastructure, i.e, "connections" already available for this). Cheers Suzuki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel