From: Suzuki K Poulose <Suzuki.Poulose@arm.com>
To: Leo Yan <leo.yan@linaro.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Wei Xu <xuwei5@hisilicon.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Andy Gross <andy.gross@linaro.org>,
David Brown <david.brown@linaro.org>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@codeaurora.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Guodong Xu <guodong.xu@linaro.org>,
John Stultz <john.stultz@linaro.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org,
linux-clk@vger.kernel.org, mike.leach@linaro.org,
sudeep.holla@arm.com
Subject: Re: [PATCH v5 6/9] coresight: add support for CPU debug module
Date: Wed, 29 Mar 2017 10:07:07 +0100 [thread overview]
Message-ID: <5584203e-cb19-a5d2-45b1-3e78d3482c55@arm.com> (raw)
In-Reply-To: <20170329030735.GA23889@leoy-linaro>
On 29/03/17 04:07, Leo Yan wrote:
> Hi Suzuki,
>
> On Mon, Mar 27, 2017 at 05:34:57PM +0100, Suzuki K Poulose wrote:
>> On 25/03/17 18:23, Leo Yan wrote:
>
> [...]
>
>> Leo,
>>
>> Thanks a lot for the quick rework. I don't fully understand (yet!) why we need the
>> idle_constraint. I will leave it for Sudeep to comment on it, as he is the expert
>> in that area. Some minor comments below.
>
> Thanks a lot for quick reviewing :)
>
>>> Signed-off-by: Leo Yan <leo.yan@linaro.org>
>>> ---
>>> drivers/hwtracing/coresight/Kconfig | 11 +
>>> drivers/hwtracing/coresight/Makefile | 1 +
>>> drivers/hwtracing/coresight/coresight-cpu-debug.c | 704 ++++++++++++++++++++++
>>> 3 files changed, 716 insertions(+)
>>> create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c
>>>
>>> diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
>>> index 130cb21..18d7931 100644
>>> --- a/drivers/hwtracing/coresight/Kconfig
>>> +++ b/drivers/hwtracing/coresight/Kconfig
>>> @@ -89,4 +89,15 @@ config CORESIGHT_STM
>>> logging useful software events or data coming from various entities
>>> in the system, possibly running different OSs
>>>
>>> +config CORESIGHT_CPU_DEBUG
>>> + tristate "CoreSight CPU Debug driver"
>>> + depends on ARM || ARM64
>>> + depends on DEBUG_FS
>>> + help
>>> + This driver provides support for coresight debugging module. This
>>> + is primarily used to dump sample-based profiling registers when
>>> + system triggers panic, the driver will parse context registers so
>>> + can quickly get to know program counter (PC), secure state,
>>> + exception level, etc.
>>
>> May be we should mention/warn the user about the possible caveats of using
>> this feature to help him make a better decision ? And / Or we should add a documentation
>> for it. We have collected some real good information over the discussions and
>> it is a good idea to capture it somewhere.
>
> Sure, I will add a documentation for this.
>
> [...]
>
>>> +static struct pm_qos_request debug_qos_req;
>>> +static int idle_constraint = PM_QOS_DEFAULT_VALUE;
>>> +module_param(idle_constraint, int, 0600);
>>> +MODULE_PARM_DESC(idle_constraint, "Latency requirement in microseconds for CPU "
>>> + "idle states (default is -1, which means have no limiation "
>>> + "to CPU idle states; 0 means disabling all idle states; user "
>>> + "can choose other platform dependent values so can disable "
>>> + "specific idle states for the platform)");
>>
>> Correct me if I am wrong,
>>
>> All we want to do is disable the CPUIdle explicitly if the user knows that this
>> could be a problem to use CPU debug on his platform. So, in effect, we should
>> only be using idle_constraint = 0 or -1.
>>
>> In which case, we could make it easier for the user to tell us, either
>>
>> 0 - Don't do anything with CPUIdle (default)
>> 1 - Disable CPUIdle for me as I know the platform has issues with CPU debug and CPUidle.
>
> The reason for not using bool flag is: usually SoC may have many idle
> states, so if user wants to partially enable some states then can set
> the latency to constraint.
>
> But of course, we can change this to binary value as you suggested,
> this means turn on of turn off all states. The only one reason to use
> latency value is it is more friendly for hardware design, e.g. some
> platforms can enable partial states to save power and avoid overheat
> after using this driver.
>
> If you guys think this is a bit over design, I will follow up your
> suggestion. I also have some replying in Mathieu's reviewing, please
> help review as well.
>
>> than explaining the miscrosecond latency etc and make the appropriate calls underneath.
>> something like (not necessarily the same name) :
>>
>> module_param(broken_with_cpuidle, bool, 0600);
>> MODULE_PARAM_DESC(broken_with_cpuidle, "Specifies whether the CPU debug has issues with CPUIdle on"
>> " the platform. Non-zero value implies CPUIdle has to be"
>> " explicitly disabled.",);
>
> [...]
>
>>> + /*
>>> + * Unfortunately the CPU cannot be powered up, so return
>>> + * back and later has no permission to access other
>>> + * registers. For this case, should set 'idle_constraint'
>>> + * to ensure CPU power domain is enabled!
>>> + */
>>> + if (!(drvdata->edprsr & EDPRSR_PU)) {
>>> + pr_err("%s: power up request for CPU%d failed\n",
>>> + __func__, drvdata->cpu);
>>> + goto out;
>>> + }
>>> +
>>> +out_powered_up:
>>> + debug_os_unlock(drvdata);
>>
>> Question: Do we need a matching debug_os_lock() once we are done ?
>
> I have checked ARM ARMv8, but there have no detailed description for
> this. I refered coresight-etmv4 code and Mike's pseudo code, ther have
> no debug_os_lock() related operations.
>
> Mike, Mathieu, could you also help confirm this?
>
> [...]
>
>>> +static void debug_init_arch_data(void *info)
>>> +{
>>> + struct debug_drvdata *drvdata = info;
>>> + u32 mode, pcsr_offset;
>>> +
>>> + CS_UNLOCK(drvdata->base);
>>> +
>>> + debug_os_unlock(drvdata);
>>> +
>>> + /* Read device info */
>>> + drvdata->eddevid = readl_relaxed(drvdata->base + EDDEVID);
>>> + drvdata->eddevid1 = readl_relaxed(drvdata->base + EDDEVID1);
>>
>> As mentioned above, both of these registers are only need at init time to
>> figure out the flags we set here. So we could remove them.
>>
>>> +
>>> + CS_LOCK(drvdata->base);
>>> +
>>> + /* Parse implementation feature */
>>> + mode = drvdata->eddevid & EDDEVID_PCSAMPLE_MODE;
>>> + pcsr_offset = drvdata->eddevid1 & EDDEVID1_PCSR_OFFSET_MASK;
>>
>>
>>> +
>>> + if (mode == EDDEVID_IMPL_NONE) {
>>> + drvdata->edpcsr_present = false;
>>> + drvdata->edcidsr_present = false;
>>> + drvdata->edvidsr_present = false;
>>> + } else if (mode == EDDEVID_IMPL_EDPCSR) {
>>> + drvdata->edpcsr_present = true;
>>> + drvdata->edcidsr_present = false;
>>> + drvdata->edvidsr_present = false;
>>> + } else if (mode == EDDEVID_IMPL_EDPCSR_EDCIDSR) {
>>> + if (!IS_ENABLED(CONFIG_64BIT) &&
>>> + (pcsr_offset == EDDEVID1_PCSR_NO_OFFSET_DIS_AARCH32))
>>> + drvdata->edpcsr_present = false;
>>> + else
>>> + drvdata->edpcsr_present = true;
>>
>> Sorry, I forgot why we do this check only in this mode. Shouldn't this be
>> common to all modes (of course which implies PCSR is present) ?
>
> No. PCSROffset is defined differently in ARMv7 and ARMv8; So finally we
> simplize PCSROffset value :
> 0000 - Sample offset applies based on the instruction state (indicated by PCSR[0])
> 0001 - No offset applies.
> 0010 - No offset applies, but do not use in AArch32 mode!
>
> So we need handle the corner case is when CPU runs AArch32 mode and
> PCSRoffset = 'b0010. Other cases the pcsr should be present.
I understand that reasoning. But my question is, why do we check for PCSROffset
only when mode == EDDEVID_IMPL_EDPCSR_EDCIDSR and not for say mode == EDDEVID_IMPL_EDPCSR or
any other mode where PCSR is present.
Suzuki
next prev parent reply other threads:[~2017-03-29 9:07 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-25 18:23 [PATCH v5 0/9] coresight: enable debug module Leo Yan
2017-03-25 18:23 ` [PATCH v5 1/9] coresight: bindings for CPU " Leo Yan
2017-03-30 22:49 ` Rob Herring
2017-03-31 9:04 ` Suzuki K Poulose
2017-03-25 18:23 ` [PATCH v5 2/9] doc: Add documentation for Coresight CPU debug Leo Yan
2017-03-25 18:23 ` [PATCH v5 3/9] coresight: of_get_coresight_platform_data: Add missing of_node_put Leo Yan
2017-03-25 18:23 ` [PATCH v5 4/9] coresight: refactor with function of_coresight_get_cpu Leo Yan
2017-03-31 9:05 ` Suzuki K Poulose
2017-03-25 18:23 ` [PATCH v5 5/9] coresight: use const for device_node structures Leo Yan
2017-04-04 21:48 ` Stephen Boyd
2017-03-25 18:23 ` [PATCH v5 6/9] coresight: add support for CPU debug module Leo Yan
2017-03-27 16:34 ` Suzuki K Poulose
2017-03-29 3:07 ` Leo Yan
2017-03-29 9:07 ` Suzuki K Poulose [this message]
2017-03-29 10:27 ` Leo Yan
2017-03-29 10:31 ` Suzuki K Poulose
2017-03-29 10:37 ` Leo Yan
2017-03-29 15:50 ` Suzuki K Poulose
2017-03-29 15:17 ` Mike Leach
2017-03-30 1:18 ` Leo Yan
2017-03-29 15:41 ` Mathieu Poirier
2017-03-28 16:50 ` Mathieu Poirier
2017-03-29 1:54 ` Leo Yan
2017-03-29 14:56 ` Mike Leach
2017-03-30 1:03 ` Leo Yan
2017-03-30 9:00 ` Suzuki K Poulose
2017-03-30 13:51 ` Leo Yan
2017-03-30 15:47 ` Sudeep Holla
2017-03-29 16:55 ` Mathieu Poirier
2017-03-30 1:59 ` Leo Yan
2017-03-30 15:46 ` Mathieu Poirier
2017-03-30 16:04 ` Sudeep Holla
2017-03-30 15:56 ` Sudeep Holla
2017-03-31 0:54 ` Leo Yan
2017-03-25 18:23 ` [PATCH v5 7/9] clk: hi6220: add debug APB clock Leo Yan
2017-04-04 21:51 ` Stephen Boyd
2017-04-06 13:59 ` Leo Yan
2017-03-25 18:23 ` [PATCH v5 8/9] arm64: dts: hi6220: register debug module Leo Yan
2017-03-25 18:23 ` [PATCH v5 9/9] arm64: dts: qcom: msm8916: Add debug unit Leo Yan
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=5584203e-cb19-a5d2-45b1-3e78d3482c55@arm.com \
--to=suzuki.poulose@arm.com \
--cc=andy.gross@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=david.brown@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=guodong.xu@linaro.org \
--cc=john.stultz@linaro.org \
--cc=leo.yan@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-soc@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.poirier@linaro.org \
--cc=mike.leach@linaro.org \
--cc=mturquette@baylibre.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@codeaurora.org \
--cc=sudeep.holla@arm.com \
--cc=will.deacon@arm.com \
--cc=xuwei5@hisilicon.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;
as well as URLs for NNTP newsgroup(s).