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=-12.0 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 5BCC0C433E1 for ; Mon, 3 Aug 2020 11:27:52 +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 2BF792076B for ; Mon, 3 Aug 2020 11:27:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="o5QyhWFU"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="u33JwKO8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2BF792076B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.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-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=e0oagJfCR2aMMZEPYYJ3LdWyVZiOSZlWk1rXG+cb9rU=; b=o5QyhWFUZAhPR6t6SiBLlRVZE x3idoytD0uzfLkpgyr5fugHxfvKR+pkhHYYecKuipJhaS0Zj51sFuv/b5Xh6ch75kCbdh2TQ9ROf5 eOipWOuPMP7+cXYWjb68+0vMBO4ItyxwKVDUegxuXqUZoRcT9sFH3LTVWcnaszwghFU62Ta3NVHbn 1DUB4RUrlIEst7jEamWSmqPFvBtEZ7g+yA479JrTQjBy7k5m+Mhqk6ItmnlC77RuItk3r+LVctN2q vI753XVBEkIteXtCsdKNDYf3Sv3xppSdeOQvcAbASDZ2gimnHZVdrWv1yvcUMk+XeDlpA4YEiW/3b 0yUUAMpKg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k2Ybx-0005m7-5p; Mon, 03 Aug 2020 11:26:33 +0000 Received: from mail-ed1-x541.google.com ([2a00:1450:4864:20::541]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k2Ybt-0005l0-RL for linux-arm-kernel@lists.infradead.org; Mon, 03 Aug 2020 11:26:31 +0000 Received: by mail-ed1-x541.google.com with SMTP id i26so23620428edv.4 for ; Mon, 03 Aug 2020 04:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NSl9YW7cFoU+dbzcR6Qr4XG07WfST78waa3npUecpQo=; b=u33JwKO82kP2rT/zx61kVrC1HH+EA6eBGuYxIxmeObp0WFdqTGsmrt7Kl69Me7NoqN AVoTTPBFiNuiJcR4Lvvd8ZOvU7oLeuqmpbQuOYZxj44oAQ+EoXvY2c/XQbIrmi89fSbH FUF95qNTpx1L+fmyvcHBFkNCEwBvzE6opCF51Ai0C1/j6glTrfQFEiJRx89erUW+jDbh soGIrSxU3SZtixtuQ6sRdoOtBs0LPVHF7JnPTBUnx+5VXeFKKHHdGMj2jV5PuYywPN4Z +vJmhFv1aHdMm5Nm14Dj3Y3QTOgNTDRk9G1ViQq3BDUYOvWaD0FMclNkCdjGfiQ0yLWj lVHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NSl9YW7cFoU+dbzcR6Qr4XG07WfST78waa3npUecpQo=; b=azscXD8VqIu1CJKapt82i5VcPPuFmrFZ4egZ0plwqdQunYvqc8rSbtfOgWoZzUXvmP ZrMx/cgYj+Cq+GlCNAzOTMW5Mj2/iE514eUfWogOpW/I+/KnyYAK4Y4kF4izkVZl7767 U3eomk4D0MSbQLyiU/2k8OEhDLV6whkYGFkeu/UimQYD83h//93i7m1w5RCNW+SYHYu5 wepI4xWU4+mdehHEYRoMbqKG6qTKLFamCjBk14RY3+aEcYUhG8XWc12uj1oSV0MIJzJQ 4+PknC0Zw2+LMLi66XOjiepbET8fNc27qCu/i2+v+zYZJptZvvaQcqOLzU0/SBbSJkW+ a9tw== X-Gm-Message-State: AOAM531UqIfqMr5HhZ6GH1x8YtTz4Z/u5KRk+W8ZS9WE+PQBOnKYEKTk CyQDg/8Q+J1edEJh/5mJh83mY+MySWdoUfc2j2E= X-Google-Smtp-Source: ABdhPJxjXDwnslKB5NevfxYdvjikaJ9YPEEVDZPOjEj5C61wRwuxgcrjsZUY2eM/J3+dCNingQZ5tkvBR9K5Ij3j3q8= X-Received: by 2002:a05:6402:308e:: with SMTP id de14mr14917922edb.344.1596453986992; Mon, 03 Aug 2020 04:26:26 -0700 (PDT) MIME-Version: 1.0 References: <20200801090950.19420-1-lcherian@marvell.com> In-Reply-To: From: Linu Cherian Date: Mon, 3 Aug 2020 16:56:15 +0530 Message-ID: Subject: Re: [PATCH V2] coresight: Make sysFS functional on topologies with per core sink To: Anshuman Khandual X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200803_072630_005442_4417CB7A X-CRM114-Status: GOOD ( 28.70 ) 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: mathieu.poirier@linaro.org, suzuki.poulose@arm.com, coresight@lists.linaro.org, Linu Cherian , linux-arm-kernel@lists.infradead.org, mike.leach@linaro.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Anshuman, On Mon, Aug 3, 2020 at 3:07 PM Anshuman Khandual wrote: > > Hello Linu, > > Please do mention the tree on which this patch applies on. The coresight > API functions being changed here are not even present on v5.8 but instead > are part of linux-next (atleast next-20200731). Will be more explicit next time, though i have mentioned the relevant tree below. > > On 08/01/2020 02:39 PM, Linu Cherian wrote: > > Coresight driver assumes sink is common across all the ETMs, > > Does 'common' just implies reachable here. Should not all the sinks on > the system be reachable from all the sources. Common implies, a topology where a sink is common to all ETMs, a global ETR for example. Please see below for details. > > > and tries to build a path between ETM and the first enabled > > sink found using bus based search. This breaks sysFS usage > > on implementations that has multiple per core sinks in > > enabled state. > > Could you please explain how it breaks the sysfs usage ? Why those per > core sinks were not found through existing bus based search. > On an implementation with per core ETR, and when a user tries to enable multiple sinks using the syfs interface, only the first sink on the bus would get enabled at hardware level. This is because coresight_get_enabled_sink would always select the first user enabled sink on the coresight bus, which works fine on implementations with global ETR but not for per core ETR/ETF. So for example, when an user enables ETM 0 and ETR0 , followed by ETM 1 and ETR 1, then ETR1 hardware block will never get enabled. > > > > For this, > > - coresight_find_sink API is updated with an additional flag > > so that it is able to return an enabled sink > > - coresight_get_enabled_sink API is updated to do a > > connection based search, when a source reference is given. > > > > Change-Id: I6cc91ddb3ef8936a8f41a5f7c7c455b0ece9d85d > > Signed-off-by: Linu Cherian > > --- > > Applies on https://git.linaro.org/kernel/coresight.git/log/?h=next > > > > Changes in V2: > > - Fixed few typos in commit message > > - Rephrased commit message > > > > .../hwtracing/coresight/coresight-etm-perf.c | 2 +- > > drivers/hwtracing/coresight/coresight-priv.h | 5 +- > > drivers/hwtracing/coresight/coresight.c | 51 +++++++++++++++++-- > > 3 files changed, 51 insertions(+), 7 deletions(-) > > > > +/** > > + * coresight_find_enabled_sink: Find the suitable enabled sink > > + * > > + * @csdev: starting source to find a connected sink. > > + * > > + * Walks connections graph looking for a suitable sink to enable for the > > + * supplied source. Uses CoreSight device subtypes and distance from source > > + * to select the best sink. > > + * > > + * Used in cases where the CoreSight user (sysfs) has selected a sink. > > + */ > > +struct coresight_device * > > +coresight_find_enabled_sink(struct coresight_device *csdev) > > +{ > > + int depth = 0; > > + > > + /* look for the enabled sink */ > > + return coresight_find_sink(csdev, &depth, true); > > +} > > + > > Why this wrapper is required ? Could not coresight_find_sink() be used > directly in the only caller i.e coresight_get_enabled_sink(). Besides, > their names are really very similar and might lead to confusion. Thought that a wrapper avoids exposing the internals like "depth" in the search API to its users. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel