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=-10.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,NICE_REPLY_A,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 3C206C63697 for ; Mon, 23 Nov 2020 05:38:46 +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 D15E9206D4 for ; Mon, 23 Nov 2020 05:38:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="pKkIs9Du" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D15E9206D4 Authentication-Results: mail.kernel.org; dmarc=fail (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-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:References: To:Subject:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=jyOmB3cJRH6qssePaGzkkzoPp4sEtMGjyqh1sGoNsTw=; b=pKkIs9DubjjUbB+liH262Yr5W q9BV7yWgeKs5TU7CpBPgT6QTuTc/4C2+7W/k8vCqfv1bbHcpa97MHf5azfVzXBLq00PvSD2L00f6u Q96QFCWpcxEOyUEhxcRC5ElkWo//qIMtKbGlJPOEhjSuBRKgWc2nJuiYgz4WD9x6LcvKpn4B0fv5E tgSI6GLBsH28dGLdc9PwkEX44s3GKdRSgcJ+AR0NjLXXSa0T0dZYwPu2XIbkGy8LaNS4skRP0QCql OtTNBar9qEkjpN9WKQaX+Fs89nYHgWUtzEk1SNZqLPPq6YRDittfI7b3BCIHXye4x4+b32WET1QVk kkKaOObfg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kh4Xa-0002TM-Ou; Mon, 23 Nov 2020 05:37:30 +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 1kh4XX-0002Ss-SQ for linux-arm-kernel@lists.infradead.org; Mon, 23 Nov 2020 05:37:29 +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 06E4B101E; Sun, 22 Nov 2020 21:37:22 -0800 (PST) Received: from [10.163.82.200] (unknown [10.163.82.200]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 249C13F71F; Sun, 22 Nov 2020 21:37:19 -0800 (PST) From: Anshuman Khandual Subject: Re: [RFC 10/11] coresgith: etm-perf: Connect TRBE sink with ETE source To: Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, coresight@lists.linaro.org References: <1605012309-24812-1-git-send-email-anshuman.khandual@arm.com> <1605012309-24812-11-git-send-email-anshuman.khandual@arm.com> Message-ID: Date: Mon, 23 Nov 2020 11:07:17 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.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-20201123_003728_071074_CBC0DB72 X-CRM114-Status: GOOD ( 18.81 ) 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: linux-kernel@vger.kernel.org, mathieu.poirier@linaro.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 On 11/12/20 3:01 PM, Suzuki K Poulose wrote: > Hi Anshuman, > On 11/10/20 12:45 PM, Anshuman Khandual wrote: >> Unlike traditional sink devices, individual TRBE instances are not detected >> via DT or ACPI nodes. Instead TRBE instances are detected during CPU online >> process. Hence a path connecting ETE and TRBE on a given CPU would not have >> been established until then. This adds two coresight helpers that will help >> modify outward connections from a source device to establish and terminate >> path to a given sink device. But this method might not be optimal and would >> be reworked later. >> >> Signed-off-by: Anshuman Khandual > > Instead of this, could we come up something like a percpu_sink concept ? That > way, the TRBE driver could register the percpu_sink for the corresponding CPU > and we don't have to worry about the order in which the ETE will be probed > on a hotplugged CPU. (i.e, if the TRBE is probed before the ETE, the following > approach would fail to register the sink). Right, it wont work. We already have a per cpu csdev sink. The current mechanism expects all ETEs to have been established and the TRBEs just get plugged in during their init while probing each individual cpus. During cpu hotplug in or out, a TRBE-ETE link either gets created and destroyed. But it assumes that an ETE is always present for TRBE to get plugged into or teared down from. csdev for TRBE sink too gets released during cpu hot remove path. Are you suggesting that there should be a percpu static csdev array defined for potential all TRBEs so that the ETE-TRBE links be permanently established given that the ETEs are permanent and never really go away with cpu hot remove event (my assumption). TRBE csdevs should just get enabled or disabled without really being destroyed during cpu hotplug, so that the corresponding TRBE-ETE connection remains in place. > > And the default sink can be initialized when the ETE instance first starts > looking for it. IIUC def_sink is the sink which will be selected by default for a source device while creating a path, in case there is no clear preference from the user. ETE's default sink should be fixed (TRBE) to be on the easy side and hence assigning that during connection expansion procedure, does make sense. But then it can be more complex where the 'default' sink for an ETE can be scenario specific and may not be always be its TRBE. The expanding connections fits into a scenario where the ETE is present with all it's other traditional sinks and TRBE is the one which comes in or goes out with the cpu. If ETE also comes in and goes out with individual cpu hotplug which is preferred ideally, we would need to also 1. Co-ordinate with TRBE bring up and connection creation to avoid race 2. Rediscover traditional sinks which were attached to the ETE before - go back, rescan the DT/ACPI entries for sinks with whom a path can be established etc. Basically there are three choices we have here 1. ETE is permanent, TRBE and ETE-TRBE path gets created or destroyed with hotplug (current proposal) 2. ETE/TRBE/ETE-TRBE path are all permanent, ETE and TRBE get enabled or disabled with hotplug 3. ETE, TRBE and ETE-TRBE path, all get created, enabled and destroyed with hotplug in sync - Anshuman _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel