| Message ID | cover.1628617260.git.schowdhu@codeaurora.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add driver support for Data Capture and Compare Engine(DCC) for SM8150,SC7280,SC7180,SDM845 | expand |
On 2021-08-10 23:24, 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. > > 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. > > 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 Gentle ping
On 2021-08-10 23:24, 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. > > 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. > > 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 Gentle ping
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 > 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 >
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 >> >
On 8/10/21 1: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. > > 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. Hello Souradeep, First of all, I think this is very a useful feature to have. I have some generic design related queries/comments on driver and the interface exposed to the user space. Also, I do not understand the h/w well here, so feel free to correct me if I am wrong. 1. Linked list looks like a very internal feature to the h/w. It really is not an info that user should be aware of. I tried reading the code a bit. IUC, every time a s/w trigger is issued the configs in all the enabled linked lists are executed. The final ram dump that you get from /dev/dcc_sram is a dump of contents from all the enabled list? Is this understanding correct ? And we are talking of at-most 4 linked list? If yes, I think it might be better to have a folder per linked list with config, config_write etc. Also if possible it will be better to dump the results to a file in the specific folder instead of reading from /dev/dcc_sram. If no, there is no real need for user to know the linked list, right? Choosing of linked list can be done by kernel driver in this case with no input needed from user. 2. Now to the sysfs interface itself, I know lot of thought has gone into sysfs vs debugfs considerations. But, have you considered using netlink interface instead of sysfs. Netlink interface is used for asynchronous communication between kernel and user space. In case of DCC, the communication appears to be asynchronous, where in user asks the kernel to capture some info and kernel can indicate back to user when the info is captured. Also the entire mess surrounding echoing addr / value / offset repeatedly into a sysfs entry can be avoided using netlink interface.
On 12/16/2021 9:18 PM, Thara Gopinath wrote: > > > On 8/10/21 1: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. >> >> 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. > > Hello Souradeep, > > First of all, I think this is very a useful feature to have. I have > some generic design related queries/comments on driver and the > interface exposed to the user space. Also, I do not understand the h/w > well here, so feel free to correct me if I am wrong. > > 1. Linked list looks like a very internal feature to the h/w. It > really is not an info that user should be aware of. I tried reading > the code a bit. IUC, every time a s/w trigger is issued the configs in > all the enabled linked lists are executed. The final ram dump that you > get from /dev/dcc_sram is a dump of contents from all the enabled > list? Is this understanding correct ? And we are talking of at-most 4 > linked list? > If yes, I think it might be better to have a folder per linked list > with config, config_write etc. Also if possible it will be better to > dump the results to a file in the specific folder instead of reading > from /dev/dcc_sram. > If no, there is no real need for user to know the linked list, right? > Choosing of linked list can be done by kernel driver in this case with > no input needed from user. > > 2. Now to the sysfs interface itself, I know lot of thought has gone > into sysfs vs debugfs considerations. But, have you considered using > netlink interface instead of sysfs. Netlink interface is used for > asynchronous communication between kernel and user space. In case of > DCC, the communication appears to be asynchronous, where in user asks > the kernel to capture some info and kernel can indicate back to user > when the info is captured. Also the entire mess surrounding echoing > addr / value / offset repeatedly into a sysfs entry can be avoided > using netlink interface. > Hello Thara, Thanks for your review comments. Following are some points from my end 1) Each linked list represent a particular block of memory in DCC_SRAM which is preserved for that particular list. That is why offset calculation is done on the driver based on the linked list chosen by the user. This choice needs to be made by the user since the number for the linked list chosen is specific to the registers used to debug a particular component. Also we are giving the user flexibility to configure multiple linked lists at one go so that even if we don't have a separate folder for it , the dumps are collected as a separate list of registers. Also there are certain curr_list values which may be supported by the dcc hardware but may not be accessible to the user and so the choice cannot be made arbitrarily from the driver. 2) From opensource, I can see that Netlink has been used in most of the cases where we need to notify stats to the user by taking the advantage of asynchronous communication. In this case, that requirement is not there since it is mostly one way communication from user to kernel. Also since this is used for debugging purposes perhaps sysfs adds more reliability than Netlink. In case of Netlink we have the additional overhead of dealing with socket calls. Let me know otherwise. Thanks, Souradeep
On Thu 06 Jan 07:20 PST 2022, Souradeep Chowdhury wrote: > > On 12/16/2021 9:18 PM, Thara Gopinath wrote: > > > > > > On 8/10/21 1: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. > > > > > > 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. > > > > Hello Souradeep, > > > > First of all, I think this is very a useful feature to have. I have some > > generic design related queries/comments on driver and the interface > > exposed to the user space. Also, I do not understand the h/w well here, > > so feel free to correct me if I am wrong. > > > > 1. Linked list looks like a very internal feature to the h/w. It really > > is not an info that user should be aware of. I tried reading the code a > > bit. IUC, every time a s/w trigger is issued the configs in all the > > enabled linked lists are executed. The final ram dump that you get from > > /dev/dcc_sram is a dump of contents from all the enabled list? Is this > > understanding correct ? And we are talking of at-most 4 linked list? > > If yes, I think it might be better to have a folder per linked list with > > config, config_write etc. Also if possible it will be better to dump the > > results to a file in the specific folder instead of reading from > > /dev/dcc_sram. > > If no, there is no real need for user to know the linked list, right? > > Choosing of linked list can be done by kernel driver in this case with > > no input needed from user. > > > > 2. Now to the sysfs interface itself, I know lot of thought has gone > > into sysfs vs debugfs considerations. But, have you considered using > > netlink interface instead of sysfs. Netlink interface is used for > > asynchronous communication between kernel and user space. In case of > > DCC, the communication appears to be asynchronous, where in user asks > > the kernel to capture some info and kernel can indicate back to user > > when the info is captured. Also the entire mess surrounding echoing addr > > / value / offset repeatedly into a sysfs entry can be avoided using > > netlink interface. > > > Hello Thara, > > Thanks for your review comments. Following are some points from my end > > > 1) Each linked list represent a particular block of memory in DCC_SRAM which > is preserved for that particular list. That is why offset calculation is > done on the driver based on the linked list chosen by the user. > > This choice needs to be made by the user since the number for the linked > list chosen is specific to the registers used to debug a particular > component. Also we are giving the user flexibility to configure multiple > > linked lists at one go so that even if we don't have a separate folder > for it , the dumps are collected as a separate list of registers. Also there > are certain curr_list values which may be supported by the dcc > > hardware but may not be accessible to the user and so the choice cannot > be made arbitrarily from the driver. > But in the end, as you write out the SRAM content, is there really any linked lists? Afaict it's just a sequence of operations/commands. The linked list part seems to be your data structure of choice to keep track of these operations in the driver before flushing them out. Regards, Bjorn > > 2) From opensource, I can see that Netlink has been used in most of the > cases where we need to notify stats to the user by taking the advantage of > asynchronous communication. In this case, that requirement is not > > there since it is mostly one way communication from user to kernel. Also > since this is used for debugging purposes perhaps sysfs adds more > reliability than Netlink. In case of Netlink we have the additional > > overhead of dealing with socket calls. Let me know otherwise. > > > Thanks, > > Souradeep > > > > >
On 1/7/2022 5:35 AM, Bjorn Andersson wrote: > On Thu 06 Jan 07:20 PST 2022, Souradeep Chowdhury wrote: > >> On 12/16/2021 9:18 PM, Thara Gopinath wrote: >>> >>> On 8/10/21 1: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. >>>> >>>> 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. >>> Hello Souradeep, >>> >>> First of all, I think this is very a useful feature to have. I have some >>> generic design related queries/comments on driver and the interface >>> exposed to the user space. Also, I do not understand the h/w well here, >>> so feel free to correct me if I am wrong. >>> >>> 1. Linked list looks like a very internal feature to the h/w. It really >>> is not an info that user should be aware of. I tried reading the code a >>> bit. IUC, every time a s/w trigger is issued the configs in all the >>> enabled linked lists are executed. The final ram dump that you get from >>> /dev/dcc_sram is a dump of contents from all the enabled list? Is this >>> understanding correct ? And we are talking of at-most 4 linked list? >>> If yes, I think it might be better to have a folder per linked list with >>> config, config_write etc. Also if possible it will be better to dump the >>> results to a file in the specific folder instead of reading from >>> /dev/dcc_sram. >>> If no, there is no real need for user to know the linked list, right? >>> Choosing of linked list can be done by kernel driver in this case with >>> no input needed from user. >>> >>> 2. Now to the sysfs interface itself, I know lot of thought has gone >>> into sysfs vs debugfs considerations. But, have you considered using >>> netlink interface instead of sysfs. Netlink interface is used for >>> asynchronous communication between kernel and user space. In case of >>> DCC, the communication appears to be asynchronous, where in user asks >>> the kernel to capture some info and kernel can indicate back to user >>> when the info is captured. Also the entire mess surrounding echoing addr >>> / value / offset repeatedly into a sysfs entry can be avoided using >>> netlink interface. >>> >> Hello Thara, >> >> Thanks for your review comments. Following are some points from my end >> >> >> 1) Each linked list represent a particular block of memory in DCC_SRAM which >> is preserved for that particular list. That is why offset calculation is >> done on the driver based on the linked list chosen by the user. >> >> This choice needs to be made by the user since the number for the linked >> list chosen is specific to the registers used to debug a particular >> component. Also we are giving the user flexibility to configure multiple >> >> linked lists at one go so that even if we don't have a separate folder >> for it , the dumps are collected as a separate list of registers. Also there >> are certain curr_list values which may be supported by the dcc >> >> hardware but may not be accessible to the user and so the choice cannot >> be made arbitrarily from the driver. >> > But in the end, as you write out the SRAM content, is there really any > linked lists? Afaict it's just a sequence of operations/commands. The > linked list part seems to be your data structure of choice to keep track > of these operations in the driver before flushing them out. That is correct, the linked list defined in the driver is for storing the addresses sequentially in DCC_SRAM and is just an internal data structure of the driver. However, there is also a "list" from DCC hardware perspective. The following driver code shows how a list is initiated with the beginning and end sram offset so that DCC hardware can treat it as a separate list of addresses and dump the values separately. /* 1. Take ownership of the list */ dcc_writel(drvdata, BIT(0), DCC_LL_LOCK(list)); /* 2. Program linked-list in the SRAM */ ram_cfg_base = drvdata->ram_cfg; ret = __dcc_ll_cfg(drvdata, list); if (ret) { dcc_writel(drvdata, 0, DCC_LL_LOCK(list)); goto err; } /* 3. program DCC_RAM_CFG reg */ dcc_writel(drvdata, ram_cfg_base + drvdata->ram_offset/4, DCC_LL_BASE(list)); dcc_writel(drvdata, drvdata->ram_start + drvdata->ram_offset/4, DCC_FD_BASE(list)); dcc_writel(drvdata, 0xFFF, DCC_LL_TIMEOUT(list)); /* 4. Clears interrupt status register */ dcc_writel(drvdata, 0, DCC_LL_INT_ENABLE(list)); dcc_writel(drvdata, (BIT(0) | BIT(1) | BIT(2)), DCC_LL_INT_STATUS(list)); drvdata->enable[list] = true; So when user enters multiple lists, the DCC hardware will process it as separate group of register values. > > Regards, > Bjorn > >> 2) From opensource, I can see that Netlink has been used in most of the >> cases where we need to notify stats to the user by taking the advantage of >> asynchronous communication. In this case, that requirement is not >> >> there since it is mostly one way communication from user to kernel. Also >> since this is used for debugging purposes perhaps sysfs adds more >> reliability than Netlink. In case of Netlink we have the additional >> >> overhead of dealing with socket calls. Let me know otherwise. >> >> >> Thanks, >> >> Souradeep >> >> >> >> >>
On Fri 07 Jan 07:43 PST 2022, Souradeep Chowdhury wrote: > > On 1/7/2022 5:35 AM, Bjorn Andersson wrote: > > On Thu 06 Jan 07:20 PST 2022, Souradeep Chowdhury wrote: > > > > > On 12/16/2021 9:18 PM, Thara Gopinath wrote: > > > > > > > > On 8/10/21 1: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. > > > > > > > > > > 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. > > > > Hello Souradeep, > > > > > > > > First of all, I think this is very a useful feature to have. I have some > > > > generic design related queries/comments on driver and the interface > > > > exposed to the user space. Also, I do not understand the h/w well here, > > > > so feel free to correct me if I am wrong. > > > > > > > > 1. Linked list looks like a very internal feature to the h/w. It really > > > > is not an info that user should be aware of. I tried reading the code a > > > > bit. IUC, every time a s/w trigger is issued the configs in all the > > > > enabled linked lists are executed. The final ram dump that you get from > > > > /dev/dcc_sram is a dump of contents from all the enabled list? Is this > > > > understanding correct ? And we are talking of at-most 4 linked list? > > > > If yes, I think it might be better to have a folder per linked list with > > > > config, config_write etc. Also if possible it will be better to dump the > > > > results to a file in the specific folder instead of reading from > > > > /dev/dcc_sram. > > > > If no, there is no real need for user to know the linked list, right? > > > > Choosing of linked list can be done by kernel driver in this case with > > > > no input needed from user. > > > > > > > > 2. Now to the sysfs interface itself, I know lot of thought has gone > > > > into sysfs vs debugfs considerations. But, have you considered using > > > > netlink interface instead of sysfs. Netlink interface is used for > > > > asynchronous communication between kernel and user space. In case of > > > > DCC, the communication appears to be asynchronous, where in user asks > > > > the kernel to capture some info and kernel can indicate back to user > > > > when the info is captured. Also the entire mess surrounding echoing addr > > > > / value / offset repeatedly into a sysfs entry can be avoided using > > > > netlink interface. > > > > > > > Hello Thara, > > > > > > Thanks for your review comments. Following are some points from my end > > > > > > > > > 1) Each linked list represent a particular block of memory in DCC_SRAM which > > > is preserved for that particular list. That is why offset calculation is > > > done on the driver based on the linked list chosen by the user. > > > > > > This choice needs to be made by the user since the number for the linked > > > list chosen is specific to the registers used to debug a particular > > > component. Also we are giving the user flexibility to configure multiple > > > > > > linked lists at one go so that even if we don't have a separate folder > > > for it , the dumps are collected as a separate list of registers. Also there > > > are certain curr_list values which may be supported by the dcc > > > > > > hardware but may not be accessible to the user and so the choice cannot > > > be made arbitrarily from the driver. > > > > > But in the end, as you write out the SRAM content, is there really any > > linked lists? Afaict it's just a sequence of operations/commands. The > > linked list part seems to be your data structure of choice to keep track > > of these operations in the driver before flushing them out. > > That is correct, the linked list defined in the driver is for storing the > addresses sequentially in DCC_SRAM and is just an internal > data structure of the driver. However, there is also a "list" from DCC > hardware perspective. The following driver code shows how > a list is initiated with the beginning and end sram offset so that DCC > hardware can treat it as a separate list of addresses and dump > the values separately. > Makes sense. But I think you should use "list" (or "sequence") and not "linked list" in the API/documentation then. > /* 1. Take ownership of the list */ > dcc_writel(drvdata, BIT(0), DCC_LL_LOCK(list)); > > /* 2. Program linked-list in the SRAM */ > ram_cfg_base = drvdata->ram_cfg; > ret = __dcc_ll_cfg(drvdata, list); > if (ret) { > dcc_writel(drvdata, 0, DCC_LL_LOCK(list)); > goto err; > } > > /* 3. program DCC_RAM_CFG reg */ > dcc_writel(drvdata, ram_cfg_base + > drvdata->ram_offset/4, DCC_LL_BASE(list)); > dcc_writel(drvdata, drvdata->ram_start + > drvdata->ram_offset/4, DCC_FD_BASE(list)); > dcc_writel(drvdata, 0xFFF, DCC_LL_TIMEOUT(list)); > > /* 4. Clears interrupt status register */ > dcc_writel(drvdata, 0, DCC_LL_INT_ENABLE(list)); > dcc_writel(drvdata, (BIT(0) | BIT(1) | BIT(2)), > DCC_LL_INT_STATUS(list)); > > drvdata->enable[list] = true; > > So when user enters multiple lists, the DCC hardware will process it as > separate group of register values. > But as the DCC supports reading, writing, looping and rmw I don't think it's correct to say that a list is a "group of register values". It's a "sequence (or list) of operations". Regards, Bjorn > > > > Regards, > > Bjorn > > > > > 2) From opensource, I can see that Netlink has been used in most of the > > > cases where we need to notify stats to the user by taking the advantage of > > > asynchronous communication. In this case, that requirement is not > > > > > > there since it is mostly one way communication from user to kernel. Also > > > since this is used for debugging purposes perhaps sysfs adds more > > > reliability than Netlink. In case of Netlink we have the additional > > > > > > overhead of dealing with socket calls. Let me know otherwise. > > > > > > > > > Thanks, > > > > > > Souradeep > > > > > > > > > > > > > > >
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. 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. 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