public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Leo Yan <leo.yan@linaro.org>
To: Andrew Murray <andrew.murray@arm.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	coresight@lists.linaro.org, Sudeep Holla <sudeep.holla@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	Mike Leach <mike.leach@linaro.org>
Subject: Re: [PATCH v2 5/5] coresight: etm4x: save/restore state across CPU low power states
Date: Mon, 1 Jul 2019 10:07:10 +0800	[thread overview]
Message-ID: <20190701020710.GC28475@leoy-ThinkPad-X240s> (raw)
In-Reply-To: <20190628092227.GJ34530@e119886-lin.cambridge.arm.com>

Hi Andrew,

On Fri, Jun 28, 2019 at 10:22:28AM +0100, Andrew Murray wrote:
> On Fri, Jun 28, 2019 at 05:12:46PM +0800, Leo Yan wrote:
> > On Fri, Jun 28, 2019 at 09:53:58AM +0100, Andrew Murray wrote:
> > 
> > [...]
> > 
> > > > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> > 
> > [...]
> > 
> > > > > +
> > > > > +#define PARAM_PM_SAVE_DISABLE	0
> > > > > +#define PARAM_PM_SAVE_ENABLE	1
> > > > > +#define PARAM_PM_SAVE_FIRMWARE	2
> > > > > +
> > > > > +static int pm_save_enable = PARAM_PM_SAVE_FIRMWARE;
> > > > > +module_param(pm_save_enable, int, 0644);
> > > > > +MODULE_PARM_DESC(pm_save_enable, "Save/restore state on power down: "
> > > > > +				  "0 = disabled, 1 = enabled, 2 = firmware");
> > > > > +
> > > > 
> > > > I understand if set pm_save_enable = 2 (firmware), then driver will
> > > > depend on drvdata->pm_save_enable to make decision for context saving
> > > > and restoring.
> > > > 
> > > > Maybe we can simplize to set pm_save_enable for binary value:
> > > > 0 (disabled) or 1 (enabled).  The reason is if we set the module
> > > > parameter 'pm_save_enable = 1', then we can set every ETM device's
> > > > drvdata->pm_save_enable in initialization phase.  So in the probe
> > > > function, we can use below code:
> > > > 
> > > >   drvdata->pm_save_enable = pm_save_enable ? : etm4_needs_save_restore(dev);
> > > 
> > > This means that when the module parameter is set to 1, then we only save/restore
> > > if the firmware suggests it is needed.
> 
> Sorry, I seemingly can't read code today.
> 
> > 
> > If the module parameter is set to 1, then we will always set every
> > device 'drvdata->pm_save_enable' to 1.  So in this case, the module
> > parameter will override the firmware property and always save/restore
> > contexts for ETM.
> > 
> > > However - what happens on hardware that ignores the PU bit (and thus requires
> > > save/restore), yet it's firmware doesn't have the
> > > 'arm,coresight-needs-save-restore' property? There is no way to override the
> > > firmware and always save/restore.
> > 
> > Actually I suggested to give the module parameter with high priority
> > and when the module parameter has set to 1, then it can override
> > firmware 'arm,coresight-needs-save-restore' property.
> > 
> > If we set the module parameter in kernel command line or when load the
> > module, its value can be used in the function etm4_probe().  So in the
> > driver probing, it detects the module parameter is 1, then it can
> > directly set every device 'drvdata->pm_save_enable' to 1.  Thus we can
> > always save/restore context for ignoring the PU bit case.
> 
> In any case, not only do we want to override the firmware to always
> save/restore. Sometimes we may also want to override the firmware to never
> save/restore (despite the firmware having the
> 'arm,coresight-needs-save-restore' flag present). For example to debug power
> management.
> 
> Thus with this current approach you can override the firmware to either enable
> or disable save/restore.

Thanks for explanation and agree with this.  Just a suggestion, maybe we
can initialize 'drvdata->pm_save_enable' in probe as below:

        if (pm_save_enable == PARAM_PM_SAVE_FIRMWARE)
                drvdata->pm_save_enable = etm4_needs_save_restore(dev);
        else
                drvdata->pm_save_enable = pm_save_enable;

From then on, we can only use 'drvdata->pm_save_enable' and don't need
to check the module parameter anymore.

Thanks,
Leo Yan

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-07-01  2:07 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-27  8:35 [PATCH v2 0/5] coresight: etm4x: save/restore ETMv4 context across CPU low power states Andrew Murray
2019-06-27  8:35 ` [PATCH v2 1/5] coresight: etm4x: remove superfluous setting of os_unlock Andrew Murray
2019-06-27  8:35 ` [PATCH v2 2/5] coresight: etm4x: use explicit barriers on enable/disable Andrew Murray
2019-06-27  9:16   ` Suzuki K Poulose
2019-06-27 11:41     ` Andrew Murray
2019-06-28  2:45   ` Leo Yan
2019-06-28  8:35     ` Andrew Murray
2019-06-28  8:51       ` Leo Yan
2019-06-28  9:00         ` Andrew Murray
2019-06-28  9:41           ` Leo Yan
2019-07-01  8:58             ` Suzuki K Poulose
2019-07-01  9:59               ` Leo Yan
2019-06-27  8:35 ` [PATCH v2 3/5] coresight: etm4x: use module_param instead of module_param_named Andrew Murray
2019-06-27  8:35 ` [PATCH v2 4/5] coresight: etm4x: improve clarity of etm4_os_unlock comment Andrew Murray
2019-06-27  8:35 ` [PATCH v2 5/5] coresight: etm4x: save/restore state across CPU low power states Andrew Murray
2019-06-27 14:25   ` Mike Leach
2019-06-27 14:55     ` Andrew Murray
2019-06-27 16:01       ` Suzuki K Poulose
2019-07-08 14:35         ` Andrew Murray
2019-06-28  8:07   ` Leo Yan
2019-06-28  8:53     ` Andrew Murray
2019-06-28  9:12       ` Leo Yan
2019-06-28  9:22         ` Andrew Murray
2019-07-01  2:07           ` Leo Yan [this message]
2019-07-01  9:34             ` Andrew Murray
2019-07-01  9:48               ` Leo Yan
2019-07-01  9:54                 ` Andrew Murray
2019-07-01 10:14                   ` Leo Yan
2019-07-04 10:21                     ` Andrew Murray
2019-07-04 14:27                       ` Mathieu Poirier
2019-07-05  1:52                         ` Leo Yan
2019-07-01 13:15   ` Suzuki K Poulose
2019-07-04  9:59     ` Andrew Murray
2019-07-03 21:21   ` Mathieu Poirier
2019-07-04 10:06     ` Andrew Murray

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190701020710.GC28475@leoy-ThinkPad-X240s \
    --to=leo.yan@linaro.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andrew.murray@arm.com \
    --cc=coresight@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=mike.leach@linaro.org \
    --cc=sudeep.holla@arm.com \
    --cc=suzuki.poulose@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox