From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DA7A734AB06 for ; Fri, 1 May 2026 13:50:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777643458; cv=none; b=mcVGvoYLYd7+B74CD/xjxujoMkEG6rJ4YyHeMJEL6jH9w/5xGo+wLs84LJSjBGokHImrunt3e9aG4fjUfjPwGghgsKShZgSXusUBxv0Sz6qHi7fETX6fe+ew+0gTKuJX2jHIPuy0Hvv0ayZMHv9nK3mi6OIVTJLjjszBlucz9NM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777643458; c=relaxed/simple; bh=gIKEf1WZwbXI4L8Pus8PqCVCaNqrvltBdZxWR+B7YGA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mC/zkeZZXnOgmYS4sLjkO9QlOkONIllqmfIUFwxCGf1ispItLzXYmCcX4WZX4mwR3+c0wDQKGLA34d6w0yKw1TNHmhacYT3FsTlVTkg04M+6s4zLCrXiMTOyGFO6o2VNOgLgxIaRLcYwL/mBRHaf+pEZ6At2w3kKGaRRRrydcDk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=Hb3cCLXL; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="Hb3cCLXL" 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 D4B07176A; Fri, 1 May 2026 06:50:50 -0700 (PDT) Received: from localhost (e132581.arm.com [10.1.196.87]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D80143F62B; Fri, 1 May 2026 06:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1777643456; bh=gIKEf1WZwbXI4L8Pus8PqCVCaNqrvltBdZxWR+B7YGA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Hb3cCLXL1a2wQ8K/kvh0sjLrnJUYt96HR7Q7U25CSeLV8+0zrcpnC0fllpPtBieRV PTfKTmkz8PvAyonLZo/RSPWqA+pPAR2X09RYERxKdGqiDuHO3g+JRySj0xSczx4W8I fVjSZqIZX8UuqwtqdhhBHD1xQJ21VTLUvTRHkWcw= Date: Fri, 1 May 2026 14:50:53 +0100 From: Leo Yan To: James Clark Cc: Suzuki K Poulose , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Mike Leach , Alexander Shishkin , Mathieu Poirier Subject: Re: [PATCH 1/2] coresight: ete: Always save state on power down Message-ID: <20260501135053.GA2674113@e132581.arm.com> References: <20260428-james-cs-ete-pm_save_enable-v1-0-c7a90ca6f43b@linaro.org> <20260428-james-cs-ete-pm_save_enable-v1-1-c7a90ca6f43b@linaro.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Fri, May 01, 2026 at 10:43:09AM +0100, James Clark wrote: [...] > > > +static int etm4_init_pm_save(struct device *dev, struct > > > etmv4_drvdata *drvdata) > > > +{ > > > +    if (etm4x_is_ete(drvdata)) { > > > +        /* > > > +         * Always do PM save for ETE. It always uses system registers > > > +         * which will be lost on CPU power down. > > > +         */ > > > +        pm_save_enable = PARAM_PM_SAVE_SELF_HOSTED; > > > > Should we do this instead based on if the ETM/ETE is accessed via sys > > instructions ? That would cover all implementations? > > > > > > Suzuki > > > > I did discuss that with Leo but we thought it might be a riskier change as > ETM is older and nobody has reported any issues, and there is already the DT > option to fix it that way. Turning it on by default could cause some > performance regressions. Although it's only if the ETM is in use, so the > impact is minimal. > > In reality it probably does make sense as it's highly unlikely that sysreg > ETM wouldn't need saving, so it might make some platforms with misconfigured > DTs more stable. > > I can send another version if you think it makes sense, what do you think > Leo? If extend a bit for ACPI context, it is fine for save / restore based on sys reg implemenation. This is most nature way for support ACPI? We can limit "arm,coresight-loses-context-with-cpu" for only ETM + MMIO mode. BTW, when respin, could you consider the approach for not changing pm_save_enable. We simply take it as a global parameter, and calculate PM mode for each CPU. But it is not necessary to write the PM mode back to pm_save_enable. Thanks, Leo