Re: [GIT PULL] Qualcomm driver updates for v6.3

[Souradeep Chowdhury <quic_schowdhu@quicinc.com>]

On 2/22/2023 7:13 AM, Leo Yan wrote:
> On Wed, Feb 15, 2023 at 04:05:36PM +0100, Arnd Bergmann wrote:
> 
> [...]
> 
>>> To my knowledge the hwtracing framework is an interface for
>>> enabling/disabling traces and then you get a stream of trace data out of
>>> it.
>>>
>>> With DCC you essentially write a small "program" to be run at the time
>>> of an exception (or triggered manually). When the "program" is run it
>>> acquire data from mmio interfaces and stores data in sram, which can
>>> then be retrieved - possibly after the fatal reset of the system.
>>>
>>> Perhaps I've misunderstood the hwtracing framework, please help me steer
>>> Souradeep towards a subsystem you find suitable for this functionality.
>>
>> I'm also not too familiar with tracing infrastructure and was hoping
>> that the coresight maintainers (Mathieu, Suzuki, Mike and Leo)
>> would have some suggestions here. My initial guess was that in
>> both cases, you have hardware support that is abstracted by the
>> kernel in order to have a user interface that can be consumed
>> by the 'perf' tool.
> 
> My understanding is hwtracing provides a common framework for STM so
> that different tracing IPs (like Intel_th and Arm CoreSight) can
> register STM module into this framework.  The framework code is placed
> in: linux/drivers/hwtracing/stm.
> 
> Now kernel doesn't provide a general framework for all hardware tracing
> IPs, e.g. Arm CoreSight has its own framework to manage tracing
> components and creating links with sinks.
> 
> Simply to say, we can place DCC driver in linux/drivers/hwtracing folder
> (like Hisilicon's ptt driver), but we have no common framework for it to
> use.
> 
> Based on reading DCC's driver, seems to me it's more like a bus tracing
> module rather than a uncore PMU.  I found the driver does not support
> interrupt, I am not sure this is a hardware limitation or just software
> doesn't implement the interrupt handling, without interrupt, it would be
> difficult for using DCC for profiling.
> 
> If we register DCC into perf framework, the good thing is DCC can use
> perf framework (e.g. perf's configs) as its user space interface, but
> it's still not clear for me how to capture the DCC trace data (no
> interrupt and not relevant with process task switching).
> 
> [...]
> 
>> If the possible use is purely for saving some state across
>> a reboot, as opposed to other events, I wonder if there is
>> a good way to integrate it into the fs/pstore/ code, which
>> already has a way to multiplex various kinds of input (log
>> buffer, ftrace call chain, userspace strings, ...) into
>> various kinds of persistent buffers (sram, blockdev, mtd,
>> efivars, ...) with the purpose of helping analyze the
>> state after a reboot.
> 
> Good point!
> 
> I understand pstore/ramoops is somehow like a sink which routes the
> tracing data (software tracing data but not hadware tracing data) to
> persistent memory.  This is why we also can route these software
> tracing data to STM (hardware sink!).
> 
> Seems to me, Arnd suggests to connect two sinks between DCC and
> pstore (to persistent memory).  But I cannot give an example code in
> kernel for doing this way, sorry if I miss something.
> 
> Essentially, a good user case is to keep a persistent memory for the
> tracing data, then after rebooting cycle we can retrieve the tracing
> data via user space interface (like sysfs node).

Hi Leo/Arnd,

Just wanted to let you know that the justification of not using PStore 
was already given in the version 1 of this patch series as below

https://lore.kernel.org/linux-arm-msm/ab30490c016f906fd9bc5d789198530b@codeaurora.org/#r

PStore/Ramoops only persists across warm-reboots which is present for 
chrome devices but not for android ones. Also the dcc_sram contents can
also be collected by going for a software trigger after loading the 
kernel and the dcc_sram is parsed to get the register values with the
opensource parser as below

https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/tools/tree/dcc_parser

Pstore on the other hand can only be collected on the next reboot.

Thanks,
Souradeep

> 
> Thanks,
> Leo