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=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 6596BC83004 for ; Wed, 29 Apr 2020 14:48:59 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 371582073E for ; Wed, 29 Apr 2020 14:48:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="tx0CxqWp"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mg.codeaurora.org header.i=@mg.codeaurora.org header.b="cSLMpwFK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 371582073E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=8K3IZYoCg4c3V5lUSogZh2or+dRUCKfgpdalntEMPKE=; b=tx0CxqWp7EYluxaoyxYH/OvEG dU6GsCJ/pKpszl1xTN7eYXknZQh/GhqYDGwgbeMEGkgh6i/seoi4mNc/tb3b+iG3SHYSODuXiNfKO 8hj2IgMRoP3uDrtzLGPsYjMAOPFhwiEcK9QzCaiuQYtbz5KEXYGxn9EqUrY6t7M55naRft3nfL74n 8TXevAWg/5xqTn+0Qja6tvAmw6deAqK3WStejA2CZZB48a+zkUKrcJBfHRvwZ6yOOcyOoH2GTG7fi IQP05F7I9r3xekTBJd7xpBD7/pjO6OzAE3gCn/qZy/9SwEPIhNummZYCifRARfZLoG0lezM0Ld5sz kaV6zt62A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jTo1B-0002xB-IR; Wed, 29 Apr 2020 14:48:57 +0000 Received: from mail26.static.mailgun.info ([104.130.122.26]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jTo10-0002n2-P7 for linux-arm-kernel@lists.infradead.org; Wed, 29 Apr 2020 14:48:50 +0000 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1588171728; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=cBvwW5avddGOz4+VMKe7nngaLFyj5X3264YJy7F3MiY=; b=cSLMpwFKghEWqBeaYNB4iEku2xv9gSV3x3bAh6bzYHniZaSo25F1877yZShyOH9CkOLw5JLe FOSnP91ikcKRZhJAfV5Ag95vOrnqnM2O76utH1n4o1lhrFnNng58YQ+3Z4ZizKfzbaRgypKu p1BK8rdwuAPklnMc8EEx/zRQCms= X-Mailgun-Sending-Ip: 104.130.122.26 X-Mailgun-Sid: WyJiYzAxZiIsICJsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmciLCAiYmU5ZTRhIl0= Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by mxa.mailgun.org with ESMTP id 5ea993c7.7f505680a308-smtp-out-n05; Wed, 29 Apr 2020 14:48:39 -0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 6523EC433F2; Wed, 29 Apr 2020 14:48:38 +0000 (UTC) Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: saiprakash.ranjan) by smtp.codeaurora.org (Postfix) with ESMTPSA id B7F75C433CB; Wed, 29 Apr 2020 14:48:37 +0000 (UTC) MIME-Version: 1.0 Date: Wed, 29 Apr 2020 20:18:37 +0530 From: Sai Prakash Ranjan To: Mike Leach Subject: Re: [PATCH] coresight: dynamic-replicator: Fix handling of multiple connections In-Reply-To: References: <20200426143725.18116-1-saiprakash.ranjan@codeaurora.org> <84918e7d-c933-3fa1-a61e-0615d4b3cf2c@arm.com> <668ea1283a6dd6b34e701972f6f71034@codeaurora.org> <5b0f5d77c4eec22d8048bb0ffa078345@codeaurora.org> <759d47de-2101-39cf-2f1c-cfefebebd548@arm.com> <7d343e96cf0701d91152fd14c2fdec42@codeaurora.org> Message-ID: X-Sender: saiprakash.ranjan@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200429_074848_693772_387ED07D X-CRM114-Status: GOOD ( 22.14 ) 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 , Suzuki K Poulose , linux-arm-msm@vger.kernel.org, Linux Kernel Mailing List , Stephen Boyd , linux-arm-kernel Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Mike, On 2020-04-29 19:57, Mike Leach wrote: > Hi, > [...] >> >> Looking more into replicator1(swao_replicator) values as 0x0 even >> >> after replicator_reset() >> >> in replicator probe, I added dynamic_replicator_reset in >> >> dynamic_replicator_enable() >> >> and am not seeing any hardlockup. Also I added some prints to check >> >> the idfilter >> >> values before and after reset and found that its not set to 0xff even >> >> after replicator_reset() >> >> in replicator probe, I don't see any other path setting it to 0x0. >> >> >> >> After probe: >> >> >> >> [ 8.477669] func replicator_probe before reset replicator >> >> replicator1 REPLICATOR_IDFILTER0=0x0 REPLICATOR_IDFILTER1=0x0 >> >> [ 8.489470] func replicator_probe after reset replicator >> >> replicator1 REPLICATOR_IDFILTER0=0xff REPLICATOR_IDFILTER1=0xff >> > >> > AFAICS, after the reset both of them are set to 0xff. >> >> Yes I see this too as we call replicator_reset() in probe. What I >> wanted >> to highlight was the below part where it is set to 0x0 before enabling >> dynamic replicator. >> >> > >> >> [ 8.502738] func replicator_probe before reset replicator >> >> replicator0 REPLICATOR_IDFILTER0=0x0 REPLICATOR_IDFILTER1=0x0 >> >> [ 8.515214] func replicator_probe after reset replicator >> >> replicator0 REPLICATOR_IDFILTER0=0xff REPLICATOR_IDFILTER1=0xff >> > >> > >> > >> >> localhost ~ # >> >> localhost ~ # >> >> localhost ~ # echo 1 > /sys/bus/coresight/devices/tmc_etr0/enable_sink >> >> localhost ~ # >> >> localhost ~ # echo 1 > /sys/bus/coresight/devices/etm0/enable_source >> >> [ 58.490485] func dynamic_replicator_enable before reset replicator >> >> replicator0 REPLICATOR_IDFILTER0=0xff REPLICATOR_IDFILTER1=0xff >> >> [ 58.503246] func dynamic_replicator_enable after reset replicator >> >> replicator0 REPLICATOR_IDFILTER0=0xff REPLICATOR_IDFILTER1=0xff >> >> [ 58.520902] func dynamic_replicator_enable before reset replicator >> >> replicator1 REPLICATOR_IDFILTER0=0x0 REPLICATOR_IDFILTER1=0x0 >> > >> > You need to find what is resetting the IDFILTERs to 0 for replicator1. >> > >> >> That is right. >> > > By default all replicators have the IDFILTER registers set to 0 out of > hardware reset. This ensures that programmable replicators behave in > the same way as non-programmable replicators out of reset. > > The dynamic_replicator_reset() is of course a driver state reset - > which filters out all trace on the output ports. The trace is then > enabled when we set the trace path from source to sink. > Thanks for these explanations. > It seems to me that you have 2 problems that need solving here: > > 1) Why does the reset_replicator() called from probe() _not_ work > correctly on replicator 1? It seems to work later if you introduce a > reset after more of the system has powered and booted. This is > startiing to look a little like a PM / clocking issue. reset_replicator() does work in probe correctly for both replicators, below logs is collected before and after reset in probe. It is later that it's set back to 0x0 and hence the suggestion to look at firmware using this replicator1. [ 8.477669] func replicator_probe before reset replicator replicator1 REPLICATOR_IDFILTER0=0x0 REPLICATOR_IDFILTER1=0x0 [ 8.489470] func replicator_probe after reset replicator replicator1 REPLICATOR_IDFILTER0=0xff REPLICATOR_IDFILTER1=0xff > > This failure is causing the state when we are trying to set an output > port that both branches of this replicator are enabled for output. > In effect for this replicator, setting the output port has no effect > as it is already enabled. > > 2) Why does having both ports of this repilicator enabled cause a hard > lockup? This is a separate hardware / system issue. > > The worst that should happen if both branches of a replicator are > enabled is that you get undesirable back pressure. (e.g. there is a > system we have seen - I think it is Juno - where there is a static > replicator feeding the TPIU and ETR - we need to disable the TPIU to > prevent undesired back pressure). > Ok so hardlockup is not expected because of this backpressure. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel