lkml.org 
[lkml]   [2020]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] coresight: dynamic-replicator: Fix handling of multiple connections
On 2020-05-11 19:46, 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).
>

Here is the cid=0xb105900d for both replicators.

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation

\
 
 \ /
  Last update: 2020-05-11 16:34    [W:0.091 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site