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=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 5CF1AC48BD3 for ; Wed, 26 Jun 2019 10:22:02 +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 18E8B20656 for ; Wed, 26 Jun 2019 10:22:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="SvwgtXmV"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="F1tw/AdX" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 18E8B20656 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.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-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=0vNSugS89k6Nw1yVr4TH6r6hiaLvOEfWD+FzRAkzVNY=; b=SvwgtXmVq9uDsE ffCjSVtKySl6LLiaqQZhXKt2LyjKU7I59wN8s1o0f2tofa0W1fiCvOtoUC0JY0Z1N0ScmBR+f7KVU ZZMfJwV/cVDX6+hfy+EfDCUfTKb2havhSEmbxWMuvR0N2BIBL0VPzk75QvOVXQQ/MT/M5cVx7iJSF W18wKLWoymteOfWzxxfCOcxEQj3PD3sWgbjlB+hI7pcGymwlaq4hB7cqdiUMUvI1mcrGQFNH8MxRw YWXHbvUAet7+YMUbxmzs8COXsA7T2eO9+4lE6yveBZr8EHYw1aabnSbxId31ErIC0YA7eoQuhVBiW bV0masnAkdI6pST24uhA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hg53p-0003i3-Q8; Wed, 26 Jun 2019 10:21:53 +0000 Received: from mail-qt1-x844.google.com ([2607:f8b0:4864:20::844]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hg53k-0003fK-JO for linux-arm-kernel@lists.infradead.org; Wed, 26 Jun 2019 10:21:50 +0000 Received: by mail-qt1-x844.google.com with SMTP id w17so1704456qto.10 for ; Wed, 26 Jun 2019 03:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9zN3KPB1EE+ooOPoQLwdz8K8UYbtwZPUPJZxmLXvCMk=; b=F1tw/AdXo+K6TKjCnu1pThgpLW9eGCZ14UB9xwm5XzZhNdF+8rFdD3PN5eqrXw8L9W A5xmQA9c1wkx7CvPhQc3XPfifbATjiKyO8K6sAZ5DOjdEtmmJ9UiPPPGjAf6WCqA7CpY lpaU02HN7iHu2c6t+rQvk+YcdeB1a5nUaiUQr9uZ2ZQP0G6LRLQR42ZakGeGW3pFwVsn F89kA+ViYflZu40GwjjxFFMJTCv+qtDEXa6N6jjIC79cbIpb3QveF9S+ofBMYL1mZZkm zDh/2R35vdq5QyuEh6KIASuU15E/+U06CF4PDWvJBsXx86hPsImUDn8eZXKV9PcSn4ww j2NQ== 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=9zN3KPB1EE+ooOPoQLwdz8K8UYbtwZPUPJZxmLXvCMk=; b=biRDf1aXL/M61SHNs2x+y2gCntZAmfyclFEee1gcpdomsqEECue8ExB9aSYsF45wTO BCjHCXIsduQB4w0nCgM4TyZ0UYsfY8f6dxLB9OM2gUHo2lF2Y/neAGKkXh6nZiHOrSdF 8az0pyiYGLEPrLjl15EpXkT10C5C7gBZpBQHq/aMTnUKiN4RZ1pEI0y18gDXdiTh2tM8 4BxhGLx6Vb8/UOVEn/ji7ZYIE1B+vWXbsTnqYQa/YxHLtRXufYfTIyNgIYga838mK4bV I/IsyQy65e4wropRFgQktJULHZFx8QtJOIDK6wB1iX6jtAa41PRwl7jlw/BwEE5OR5OH iz9Q== X-Gm-Message-State: APjAAAU/0OkrMDJnPIJJS+78KwlwekRdHWIE0KiJTScGtwkSg52NF6+e OUoGHOmEHiyIYbeS0Z76blMBFi9RVHGeIAzISagXhg== X-Google-Smtp-Source: APXvYqxU2ga6L7D1HKOr1UtHhuSDivTpB/YVtYYMMS/Aa0d2bS99KNi5TQFpQuchtotwxpicy3hcASRle7zQYijKfVQ= X-Received: by 2002:a0c:add1:: with SMTP id x17mr2781076qvc.81.1561544506617; Wed, 26 Jun 2019 03:21:46 -0700 (PDT) MIME-Version: 1.0 References: <20190618125433.9739-1-andrew.murray@arm.com> <20190618125433.9739-6-andrew.murray@arm.com> <20190618225549.GB24894@xps15> <494e131a-0fcf-a4b0-6112-cb5861756004@arm.com> In-Reply-To: From: Mike Leach Date: Wed, 26 Jun 2019 11:21:35 +0100 Message-ID: Subject: Re: [PATCH v1 5/5] coresight: etm4x: save/restore state across CPU low power states To: Mathieu Poirier X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190626_032148_653683_9B310BFB X-CRM114-Status: GOOD ( 27.85 ) 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: Alexander Shishkin , Andrew Murray , linux-arm-kernel , Suzuki K Poulose Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, Sorry, a bit late on this set as it didn't appear in the Coresight mailing list as expected per suzukis suggestion. On Tue, 25 Jun 2019 at 20:57, Mathieu Poirier wrote: > > Hi, > > On Tue, 25 Jun 2019 at 04:07, Suzuki K Poulose wrote: > > > > Hi Mathieu, > > > > On 18/06/2019 23:55, Mathieu Poirier wrote: > > > On Tue, Jun 18, 2019 at 01:54:33PM +0100, Andrew Murray wrote: > > >> Some hardware will ignore bit TRCPDCR.PU which is used to signal > > >> to hardware that power should not be removed from the trace unit. > > >> Let's mitigate against this by saving and restoring the trace > > >> unit state when the CPU enters low power states. > > >> > > >> To provide the benefit to both self-hosted and external debuggers > > >> we save/restore the entire state which includes etmv4_config data > > >> and dynamic data such as inflight counter values, sequencer > > >> states, etc. > > >> > > >> To reduce CPU suspend/resume latency the state is only saved or > > >> restored if coresight is in use as determined by the claimset > > >> registers. > > >> > > >> To aid debug of CPU suspend/resume a disable_pm_save parameter > > >> is provided to disable this feature. > > >> > > >> Signed-off-by: Andrew Murray > > > > > > >> +static int etm4_cpu_pm_notify(struct notifier_block *nb, unsigned long cmd, > > >> + void *v) > > >> +{ > > >> + struct etmv4_drvdata *drvdata = container_of(nb, > > >> + struct etmv4_drvdata, nb); > > >> + > > >> + if (disable_pm_save) > > >> + return NOTIFY_OK; > > >> + > > >> + switch (cmd) { > > >> + case CPU_PM_ENTER: > > >> + /* save the state if coresight is in use */ > > >> + if (coresight_is_claimed_any(drvdata->base)) > > > > > > claimed_any()? At this point if coresight_is_claimed_self_hosted() == false an > > > external agent is competing with the framework and we should abdicate. > > > > I think claimed_any() is correct check. As per PSCI, ARM DEN 0022D, section > > 6.8.1 Debug and Trace save and restore, the OS software is > > in charge of save/restoring the context of Debug/Trace. The claim tags > > are a mechanism to indicate who is consuming the components. Also, given > > the OS software doesn't have a reliable way to communicate back to the > > the External debugger about its decision to power down the CPU, that > > makes sense to save/restore it. > > What I understand from section 6.8.1 is that supervisory and OS power > management SW are responsible to save the debug context when operating > in their respective mode, which reflects my comment above. > > I also see that two options are available to an external agent, i.e > either use the DBGNOPWRDWN and DBGPWRUPREQ bits to request powerdown > emulation or use the "OS Unlock Catch" debug event (which probably > relates to the lost of context bit) to restore the debug context. > From where I stand there is no provision for OS power management code > to take care of the debug context of an external agent. Am I missing > something here? > OS lock is precisely the provision designed for an OS to handle save/restore on behalf of an external debug agent. OS lock blocks the external debugger from accessing the coresight when it is powered but being updated by the OS A scenario may be:- a) external debug halts core(s) & programs Coresight subsystem - likely extracting trace via TPIU. b) external debug agent restarts cores - linux (continues) running / booting - collecting the trace we want. c) Some event happens and the external debug agent regains control. (breakpoint / halt request). During b) cores may be powering up and down. When this happens we need the state to be saved and restored so that trace continues. (assuming that the various debug power requests above are either not supported in the fw/hardware or not asserted by the external agent). The external debug agent cannot safely manipulate coresight during this period - it can never know if a register is going to be available - a classic race condition. Irrespective of whoever "owns" the ETM programming - if the CPUidle notification is required due to implementation issues, then in both cases the save and restore is required. For the external agent owner I agree that everything needs to be saved - but for self hosted, just the dynamic values should be read back, much of the remainder of the information is already held in the driver in etmv4_config. This should help reduce at least the power down latency. Regards Mike > > > > Cheers > > Suzuki > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel