[PATCH V6 0/7] Add driver support for Data Capture and Compare Engine(DCC) for SM8150,SC7280,SC7180,SDM845
Souradeep Chowdhury
quic_schowdhu at quicinc.com
Wed Dec 15 05:56:38 PST 2021
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
>>
>
More information about the linux-arm-kernel
mailing list