From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: mike.leach@linaro.org, mathieu.poirier@linaro.org,
swboyd@chromium.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux@armlinux.org.uk
Subject: Re: [PATCH] coresight: dynamic-replicator: Fix handling of multiple connections
Date: Mon, 11 May 2020 20:11:52 +0530 [thread overview]
Message-ID: <d47271ee6a2a6f0f30da7e140b6f196c@codeaurora.org> (raw)
In-Reply-To: <37b3749e-2363-0877-c318-9c334a5d1881@arm.com>
Hi Suzuki,
On 2020-05-11 20:00, Suzuki K Poulose wrote:
> On 05/11/2020 03:16 PM, Sai Prakash Ranjan wrote:
>> Hi Mike,
>>
>> On 2020-05-11 16:44, Mike Leach wrote:
>> [...]
>>
>>>>
>>>> I checked with the debug team and there is a limitation with
>>>> the replicator(swao_replicator) in the AOSS group where it
>>>> loses the idfilter register context when the clock is disabled.
>>>> This is not just in SC7180 SoC but also reported on some latest
>>>> upcoming QCOM SoCs as well and will need to be taken care in
>>>> order to enable coresight on these chipsets.
>>>>
>>>> Here's what's happening - After the replicator is initialized,
>>>> the clock is disabled in amba_pm_runtime_suspend() as a part of
>>>> pm runtime workqueue with the assumption that there will be no
>>>> loss of context after the replicator is initialized. But it doesn't
>>>> hold good with the replicators with these unfortunate limitation
>>>> and the idfilter register context is lost.
>>>>
>>>> [ 5.889406] amba_pm_runtime_suspend devname=6b06000.replicator
>>>> ret=0
>>>> [ 5.914516] Workqueue: pm pm_runtime_work
>>>> [ 5.918648] Call trace:
>>>> [ 5.921185] dump_backtrace+0x0/0x1d0
>>>> [ 5.924958] show_stack+0x2c/0x38
>>>> [ 5.928382] dump_stack+0xc0/0x104
>>>> [ 5.931896] amba_pm_runtime_suspend+0xd8/0xe0
>>>> [ 5.936469] __rpm_callback+0xe0/0x140
>>>> [ 5.940332] rpm_callback+0x38/0x98
>>>> [ 5.943926] rpm_suspend+0xec/0x618
>>>> [ 5.947522] rpm_idle+0x5c/0x3f8
>>>> [ 5.950851] pm_runtime_work+0xa8/0xc0
>>>> [ 5.954718] process_one_work+0x1f8/0x4c0
>>>> [ 5.958848] worker_thread+0x50/0x468
>>>> [ 5.962623] kthread+0x12c/0x158
>>>> [ 5.965957] ret_from_fork+0x10/0x1c
>>>>
>>>> This is a platform/SoC specific replicator issue, so we can either
>>>> introduce some DT property for replicators to identify which
>>>> replicator
>>>> has this limitation, check in replicator_enable() and reset the
>>>> registers
>>>> or have something like below diff to check the idfilter registers in
>>>> replicator_enable() and then reset with clear comment specifying
>>>> it’s
>>>> the
>>>> hardware limitation on some QCOM SoCs. Please let me know your
>>>> thoughts
>>>> on
>>>> this?
>>>>
>>
>> Sorry for hurrying up and sending the patch -
>> https://lore.kernel.org/patchwork/patch/1239923/.
>> I will send v2 based on further feedbacks here or there.
>>
>>>
>>> 1) does this replicator part have a unique ID that differs from the
>>> standard ARM designed replicators?
>>> If so perhaps link the modification into this. (even if the part no
>>> in
>>> PIDR0/1 is the same the UCI should be different for a different
>>> implementation)
>>>
>>
>> pid=0x2bb909 for both replicators. So part number is same.
>> UCI will be different for different implementation(QCOM maybe
>> different from ARM),
>> but will it be different for different replicators under the same
>> impl(i.e., on QCOM).
>
> May be use PIDR4.DES_2 to match the Implementor and apply the work
> around for all QCOM replicators ?
>
> To me that sounds the best option.
>
Ok we can do this as well, but just for my understanding, why do we need
to reset replicators
in replicator_probe() and not in replicator_enable()? Are we accessing
anything before
we enable replicators?
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2020-05-11 14:42 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-26 14:37 [PATCH] coresight: dynamic-replicator: Fix handling of multiple connections Sai Prakash Ranjan
2020-04-27 9:20 ` Suzuki K Poulose
2020-04-27 9:45 ` Mike Leach
2020-04-27 13:53 ` Suzuki K Poulose
2020-04-28 12:23 ` Sai Prakash Ranjan
2020-04-29 11:47 ` Sai Prakash Ranjan
2020-04-29 13:49 ` Suzuki K Poulose
2020-04-29 13:59 ` Sai Prakash Ranjan
2020-04-29 14:27 ` Mike Leach
2020-04-29 14:48 ` Sai Prakash Ranjan
2020-04-29 16:58 ` Mike Leach
2020-04-29 17:11 ` Sai Prakash Ranjan
2020-05-06 7:35 ` Sai Prakash Ranjan
2020-05-08 8:53 ` Sai Prakash Ranjan
2020-05-11 11:14 ` Mike Leach
2020-05-11 14:16 ` Sai Prakash Ranjan
2020-05-11 14:30 ` Suzuki K Poulose
2020-05-11 14:41 ` Sai Prakash Ranjan [this message]
2020-05-12 11:49 ` Mike Leach
2020-05-12 17:45 ` Mathieu Poirier
2020-05-12 17:46 ` Sai Prakash Ranjan
2020-05-12 21:52 ` Mike Leach
2020-05-13 1:49 ` Stephen Boyd
2020-05-13 15:45 ` Sai Prakash Ranjan
2020-05-13 15:33 ` Sai Prakash Ranjan
2020-05-16 10:04 ` Sai Prakash Ranjan
2020-05-19 9:04 ` Sai Prakash Ranjan
2020-05-11 14:34 ` Sai Prakash Ranjan
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=d47271ee6a2a6f0f30da7e140b6f196c@codeaurora.org \
--to=saiprakash.ranjan@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mathieu.poirier@linaro.org \
--cc=mike.leach@linaro.org \
--cc=suzuki.poulose@arm.com \
--cc=swboyd@chromium.org \
/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).