On 12/14/2021 4:05 AM, Alex Elder wrote:
On 8/10/21 12:54 PM, Souradeep Chowdhury wrote:
DCC(Data Capture and Compare) is a DMA engine designed for debugging
purposes.In case of a system
crash or manual software triggers by the user the DCC hardware stores
the value at the register
addresses which can be used for debugging purposes.The DCC driver
provides the user with sysfs
interface to configure the register addresses.The options that the
DCC hardware provides include
reading from registers,writing to registers,first reading and then
writing to registers and looping
through the values of the same register.
I realize this was posted a long time ago but I spent a little
time on it today, and I have some comments for you to consider.
You'll need to post another version of this series if you're
going to address some of my comments.
Most of the comments are in patch 2, which contains all the code
and the sysfs documentation. I have no comments on patches 3
(MAINTAINERS update) or 4 through 7 (DTS updates for specific
platforms).
First, a few comments on this cover page. The most trivial
comment is: Please make your lines narrower than 80 columns,
like the rest of the patches.
I appreciate that this goes into some detail about how this
feature has been used. But I think it could benefit from
a little better high-level overview of what it *does*.
Your first paragraph is a concise summary, but I find it
doesn't evoke a model in my mind of what exactly is going
on, or what the hardware is doing. In fact, if you can
provide a good high-level overview it might belong at the
top of "dcc.c" in comments.
Looking at the code (but not in any great depth), I see
that there are "linked lists" of what appear to be things
for the hardware to do with memory when this hardware is
"triggered." If I understand it right, there can be up
to 8 of these lists (though some versions of hardware
might advertise the number supported via a register).
If the following is wrong, I hope you'll offer a comparable
explanation and will correct my misunderstanding.
Each list consists of a set of actions to take. The actions
available include: reading a register (possibly <count> times
in succession); writing a register; and read/modify/writing
a register (affecting only bits in a given mask). Actually,
the way looping works is a little confusing to me.
Each list can be enabled and disabled separately. When
triggered, all lists are executed, and (somehow) the result
is saved into a buffer that can be read via /dev/dcc_sram.
So you use these sysfs files to configure the actions you'd
like to take when a "trigger" is signaled. The content of
/dev/dcc_sram can then be read to see what output your
lists produced.
Is that close to correct? If it is, great; I want to be
sure I understand what the hardware is supposed to do
before I comment much more on the way you represent it
in the driver and in sysfs.
In certain cases a register write needs to be executed for accessing
the rest of the registers,
also the user might want to record the changing values of a register
with time for which he has the
option to use the loop feature.
The options mentioned above are exposed to the user by sysfs files
once the driver is probed.The
details and usage of this sysfs files are documented in
Documentation/ABI/testing/sysfs-driver-dcc.
Once you've confirmed I understand what's supposed to happen
when the trigger fires, I think I'll have some comments on
the way you represent the actions in these lists. But
for now, maybe keep things as you have them, but address
some of the comments I'm giving you today. Copy me on
future revisions and I'll plan to review again.
OK, that's enough on this file for now. Onto the binding and
the code...
-Alex
Hi Alex.
Thanks for your feedback. The understanding is correct regarding DCC
hardware.
Will address all the comments and post the next version copying you.
Thanks,
Souradeep
As an example let us consider a couple of debug scenarios where DCC
has been proved to be effective
for debugging purposes:-
i)TimeStamp Related Issue
On SC7180, there was a coresight timestamp issue where it would
occasionally be all 0 instead of proper
timestamp values.
Proper timestamp:
Idx:3373; ID:10; I_TIMESTAMP : Timestamp.; Updated val =
0x13004d8f5b7aa; CC=0x9e
Zero timestamp:
Idx:3387; ID:10; I_TIMESTAMP : Timestamp.; Updated val = 0x0; CC=0xa2
Now this is a non-fatal issue and doesn't need a system reset, but
still needs
to be rootcaused and fixed for those who do care about coresight etm
traces.
Since this is a timestamp issue, we would be looking for any
timestamp related
clocks and such.
o we get all the clk register details from IP documentation and
configure it
via DCC config syfs node. Before that we set the current linked list.
/* Set the current linked list */
echo 3 > /sys/bus/platform/devices/10a2000.dcc/curr_list
/* Program the linked list with the addresses */
echo 0x10c004 > /sys/bus/platform/devices/10a2000.dcc/config
echo 0x10c008 > /sys/bus/platform/devices/10a2000.dcc/config
echo 0x10c00c > /sys/bus/platform/devices/10a2000.dcc/config
echo 0x10c010 > /sys/bus/platform/devices/10a2000.dcc/config
..... and so on for other timestamp related clk registers
/* Other way of specifying is in "addr len" pair, in below case it
specifies to capture 4 words starting 0x10C004 */
echo 0x10C004 4 > /sys/bus/platform/devices/10a2000.dcc/config
/* Enable DCC */
echo 1 > /sys/bus/platform/devices/10a2000.dcc/enable
/* Run the timestamp test for working case */
/* Send SW trigger */
echo 1 > /sys/bus/platform/devices/10a2000.dcc/trigger
/* Read SRAM */
cat /dev/dcc_sram > dcc_sram1.bin
/* Run the timestamp test for non-working case */
/* Send SW trigger */
echo 1 > /sys/bus/platform/devices/10a2000.dcc/trigger
/* Read SRAM */
cat /dev/dcc_sram > dcc_sram2.bin
Get the parser from [1] and checkout the latest branch.
/* Parse the SRAM bin */
python dcc_parser.py -s dcc_sram1.bin --v2 -o output/
python dcc_parser.py -s dcc_sram2.bin --v2 -o output/
Sample parsed output of dcc_sram1.bin:
<hwioDump version="1">
<timestamp>03/14/21</timestamp>
<generator>Linux DCC Parser</generator>
<chip name="None" version="None">
<register address="0x0010c004" value="0x80000000" />
<register address="0x0010c008" value="0x00000008" />
<register address="0x0010c00c" value="0x80004220" />
<register address="0x0010c010" value="0x80000000" />
</chip>
<next_ll_offset>next_ll_offset : 0x1c </next_ll_offset>
</hwioDump>
ii)NOC register errors
A particular class of registers called NOC which are functional
registers was reporting
errors while logging the values.To trace these errors the DCC has
been used effectively.
The steps followed were similar to the ones mentioned above.
In addition to NOC registers a few other dependent registers were
configured in DCC to
monitor it's values during a crash. A look at the dependent register
values revealed that
the crash was happening due to a secured access to one of these
dependent registers.
All these debugging activity and finding the root cause was achieved
using DCC.
DCC parser is available at the following open source location
https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/tools/tree/dcc_parser
Changes in v6:
*Added support in the dcc driver to handle multiple Qualcomm SoCs
including SC7180,SC7280,SDM845
along with existing SM8150.
*Added the support node in the respective device tree files for
SC7180,SC7280,SDM845.
Souradeep Chowdhury (7):
dt-bindings: Added the yaml bindings for DCC
soc: qcom: dcc:Add driver support for Data Capture and Compare
unit(DCC)
MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver
support
arm64: dts: qcom: sm8150: Add Data Capture and Compare(DCC) support
node
arm64: dts: qcom: sc7280: Add Data Capture and Compare(DCC) support
node
arm64: dts: qcom: sc7180: Add Data Capture and Compare(DCC) support
node
arm64: dts: qcom: sdm845: Add Data Capture and Compare(DCC) support
node
Documentation/ABI/testing/sysfs-driver-dcc | 114 ++
.../devicetree/bindings/arm/msm/qcom,dcc.yaml | 43 +
MAINTAINERS | 8 +
arch/arm64/boot/dts/qcom/sc7180.dtsi | 6 +
arch/arm64/boot/dts/qcom/sc7280.dtsi | 6 +
arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 +
arch/arm64/boot/dts/qcom/sm8150.dtsi | 6 +
drivers/soc/qcom/Kconfig | 8 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/dcc.c | 1549
++++++++++++++++++++
10 files changed, 1747 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc
create mode 100644
Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml
create mode 100644 drivers/soc/qcom/dcc.c
