| Message ID | cover.1683265984.git.quic_schowdhu@quicinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | misc: Add driver support for Data Capture and Compare unit(DCC) | expand |
On 5/5/2023 12:06 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 debugfs 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 debugfs files once the driver > is probed. The details and usage of this debugfs files are documented in > Documentation/ABI/testing/debugfs-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. > > We get all the clk register details from IP documentation and configure it > via DCC config_read debugfs node. Before that we set the current linked list. > > /* Program the linked list with the addresses */ > echo R 0x10c004 > /sys/kernel/debug/qcom-dcc/../3/config > echo R 0x10c008 > /sys/kernel/debug/qcom-dcc/../3/config > echo R 0x10c00c > /sys/kernel/debug/qcom-dcc/../3/config > echo R 0x10c010 > /sys/kernel/debug/qcom-dcc/../3/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 R 0x10C004 4 > /sys/kernel/debug/qcom-dcc/../3/config_read > > /* Enable DCC */ > echo 1 > /sys/kernel/debug/qcom-dcc/../3/enable > > /* Run the timestamp test for working case */ > > /* Send SW trigger */ > echo 1 > /sys/kernel/debug/qcom-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/kernel/debug/qcom-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://git.codelinaro.org/clo/le/platform/vendor/qcom-opensource/tools/-/tree/opensource-tools.lnx.1.0.r176-rel/dcc_parser > > Souradeep Chowdhury (3): > dt-bindings: misc: qcom,dcc: Add the dtschema > misc: dcc: Add driver support for Data Capture and Compare unit(DCC) > MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver > support > > Documentation/ABI/testing/debugfs-driver-dcc | 10 +- > .../devicetree/bindings/misc/qcom,dcc.yaml | 44 + > MAINTAINERS | 8 + > drivers/misc/Kconfig | 9 + > drivers/misc/Makefile | 1 + > drivers/misc/qcom-dcc.c | 1325 +++++++++++++++++ > 6 files changed, 1392 insertions(+), 5 deletions(-) > create mode 100644 Documentation/devicetree/bindings/misc/qcom,dcc.yaml > create mode 100644 drivers/misc/qcom-dcc.c > Gentle Ping
On 5/5/2023 12:06 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 debugfs 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 debugfs files once the driver > is probed. The details and usage of this debugfs files are documented in > Documentation/ABI/testing/debugfs-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. > > We get all the clk register details from IP documentation and configure it > via DCC config_read debugfs node. Before that we set the current linked list. > > /* Program the linked list with the addresses */ > echo R 0x10c004 > /sys/kernel/debug/qcom-dcc/../3/config > echo R 0x10c008 > /sys/kernel/debug/qcom-dcc/../3/config > echo R 0x10c00c > /sys/kernel/debug/qcom-dcc/../3/config > echo R 0x10c010 > /sys/kernel/debug/qcom-dcc/../3/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 R 0x10C004 4 > /sys/kernel/debug/qcom-dcc/../3/config_read > > /* Enable DCC */ > echo 1 > /sys/kernel/debug/qcom-dcc/../3/enable > > /* Run the timestamp test for working case */ > > /* Send SW trigger */ > echo 1 > /sys/kernel/debug/qcom-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/kernel/debug/qcom-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://git.codelinaro.org/clo/le/platform/vendor/qcom-opensource/tools/-/tree/opensource-tools.lnx.1.0.r176-rel/dcc_parser > > Souradeep Chowdhury (3): > dt-bindings: misc: qcom,dcc: Add the dtschema > misc: dcc: Add driver support for Data Capture and Compare unit(DCC) > MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver > support > > Documentation/ABI/testing/debugfs-driver-dcc | 10 +- > .../devicetree/bindings/misc/qcom,dcc.yaml | 44 + > MAINTAINERS | 8 + > drivers/misc/Kconfig | 9 + > drivers/misc/Makefile | 1 + > drivers/misc/qcom-dcc.c | 1325 +++++++++++++++++ > 6 files changed, 1392 insertions(+), 5 deletions(-) > create mode 100644 Documentation/devicetree/bindings/misc/qcom,dcc.yaml > create mode 100644 drivers/misc/qcom-dcc.c > Gentle ping.
On Thu, May 04, 2023 at 11:36:20PM -0700, 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 debugfs 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 debugfs files once the driver > is probed. The details and usage of this debugfs files are documented in > Documentation/ABI/testing/debugfs-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. > > We get all the clk register details from IP documentation and configure it > via DCC config_read debugfs node. Before that we set the current linked list. > > /* Program the linked list with the addresses */ > echo R 0x10c004 > /sys/kernel/debug/qcom-dcc/../3/config > echo R 0x10c008 > /sys/kernel/debug/qcom-dcc/../3/config > echo R 0x10c00c > /sys/kernel/debug/qcom-dcc/../3/config > echo R 0x10c010 > /sys/kernel/debug/qcom-dcc/../3/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 R 0x10C004 4 > /sys/kernel/debug/qcom-dcc/../3/config_read > > /* Enable DCC */ > echo 1 > /sys/kernel/debug/qcom-dcc/../3/enable > > /* Run the timestamp test for working case */ > > /* Send SW trigger */ > echo 1 > /sys/kernel/debug/qcom-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/kernel/debug/qcom-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://git.codelinaro.org/clo/le/platform/vendor/qcom-opensource/tools/-/tree/opensource-tools.lnx.1.0.r176-rel/dcc_parser > > Souradeep Chowdhury (3): > dt-bindings: misc: qcom,dcc: Add the dtschema > misc: dcc: Add driver support for Data Capture and Compare unit(DCC) > MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver > support > > Documentation/ABI/testing/debugfs-driver-dcc | 10 +- > .../devicetree/bindings/misc/qcom,dcc.yaml | 44 + > MAINTAINERS | 8 + > drivers/misc/Kconfig | 9 + > drivers/misc/Makefile | 1 + > drivers/misc/qcom-dcc.c | 1325 +++++++++++++++++ > 6 files changed, 1392 insertions(+), 5 deletions(-) > create mode 100644 Documentation/devicetree/bindings/misc/qcom,dcc.yaml > create mode 100644 drivers/misc/qcom-dcc.c > > -- > 2.17.1 > Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - This looks like a new version of a previously submitted patch, but you did not list below the --- line any changes from the previous version. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/process/submitting-patches.rst for what needs to be done here to properly describe this. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
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 debugfs 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 debugfs files once the driver is probed. The details and usage of this debugfs files are documented in Documentation/ABI/testing/debugfs-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. We get all the clk register details from IP documentation and configure it via DCC config_read debugfs node. Before that we set the current linked list. /* Program the linked list with the addresses */ echo R 0x10c004 > /sys/kernel/debug/qcom-dcc/../3/config echo R 0x10c008 > /sys/kernel/debug/qcom-dcc/../3/config echo R 0x10c00c > /sys/kernel/debug/qcom-dcc/../3/config echo R 0x10c010 > /sys/kernel/debug/qcom-dcc/../3/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 R 0x10C004 4 > /sys/kernel/debug/qcom-dcc/../3/config_read /* Enable DCC */ echo 1 > /sys/kernel/debug/qcom-dcc/../3/enable /* Run the timestamp test for working case */ /* Send SW trigger */ echo 1 > /sys/kernel/debug/qcom-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/kernel/debug/qcom-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://git.codelinaro.org/clo/le/platform/vendor/qcom-opensource/tools/-/tree/opensource-tools.lnx.1.0.r176-rel/dcc_parser Souradeep Chowdhury (3): dt-bindings: misc: qcom,dcc: Add the dtschema misc: dcc: Add driver support for Data Capture and Compare unit(DCC) MAINTAINERS: Add the entry for DCC(Data Capture and Compare) driver support Documentation/ABI/testing/debugfs-driver-dcc | 10 +- .../devicetree/bindings/misc/qcom,dcc.yaml | 44 + MAINTAINERS | 8 + drivers/misc/Kconfig | 9 + drivers/misc/Makefile | 1 + drivers/misc/qcom-dcc.c | 1325 +++++++++++++++++ 6 files changed, 1392 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/misc/qcom,dcc.yaml create mode 100644 drivers/misc/qcom-dcc.c