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/dcc/../3/config
echo R 0x10c008 > /sys/kernel/debug/dcc/../3/config
echo R 0x10c00c > /sys/kernel/debug/dcc/../3/config
echo R 0x10c010 > /sys/kernel/debug/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/dcc/../3/config_read
/* Enable DCC */
echo 1 > /sys/kernel/debug/dcc/../3/enable
/* Run the timestamp test for working case */
/* Send SW trigger */
echo 1 > /sys/kernel/debug/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/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 v22
* DCC driver is added to the new location as per discussions
* Implemented the comments on the previous version of this patch
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
.../devicetree/bindings/misc/qcom,dcc.yaml | 44 +
MAINTAINERS | 8 +
drivers/misc/Kconfig | 8 +
drivers/misc/Makefile | 1 +
drivers/misc/dcc.c | 1300 ++++++++++++++++++++
5 files changed, 1361 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/qcom,dcc.yaml
create mode 100644 drivers/misc/dcc.c
--
2.7.4
Add the entries for all the files added as a part of driver support for
DCC(Data Capture and Compare).
Signed-off-by: Souradeep Chowdhury <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b4e9c5b..6b8a5c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5705,6 +5705,14 @@ W: http://lists.twibble.org/mailman/listinfo/dc395x/
F: Documentation/scsi/dc395x.rst
F: drivers/scsi/dc395x.*
+DCC QTI DRIVER
+M: Souradeep Chowdhury <[email protected]>
+L: [email protected]
+S: Maintained
+F: Documentation/ABI/testing/debugfs-driver-dcc
+F: Documentation/devicetree/bindings/misc/qcom,dcc.yaml
+F: drivers/misc/dcc.c
+
DCCP PROTOCOL
L: [email protected]
S: Orphan
--
2.7.4
The DCC is a DMA Engine designed to capture and store data during system
crash or software triggers. The DCC operates based on user inputs via
the debugfs interface. The user gives addresses as inputs and these
addresses are stored in the dcc sram. In case of a system crash or a
manual software trigger by the user through the debugfs interface, the
dcc captures and stores the values at these addresses. This patch
contains the driver which has all the methods pertaining to the debugfs
interface, auxiliary functions to support all the four fundamental
operations of dcc namely read, write, read/modify/write and loop. The
probe method here instantiates all the resources necessary for dcc to
operate mainly the dedicated dcc sram where it stores the values. The
DCC driver can be used for debugging purposes without going for a reboot
since it can perform software triggers as well based on user inputs.
Also add the documentation for debugfs entries which explains the
functionalities of each debugfs file that has been created for dcc.
The following is the justification of using debugfs interface over the
other alternatives like sysfs/ioctls
i) As can be seen from the debugfs attribute descriptions, some of the
debugfs attribute files here contains multiple arguments which needs to
be accepted from the user. This goes against the design style of sysfs.
ii) The user input patterns have been made simple and convenient in this
case with the use of debugfs interface as user doesn't need to shuffle
between different files to execute one instruction as was the case on
using other alternatives.
Signed-off-by: Souradeep Chowdhury <[email protected]>
Reviewed-by: Alex Elder <[email protected]>
---
drivers/misc/Kconfig | 8 +
drivers/misc/Makefile | 1 +
drivers/misc/dcc.c | 1300 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 1309 insertions(+)
create mode 100644 drivers/misc/dcc.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 433aa41..e2bc652 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -276,6 +276,14 @@ config QCOM_COINCELL
to maintain PMIC register and RTC state in the absence of
external power.
+config QCOM_DCC
+ tristate "Qualcomm Technologies, Inc. Data Capture and Compare(DCC) engine driver"
+ depends on ARCH_QCOM || COMPILE_TEST
+ help
+ This option enables driver for Data Capture and Compare engine. DCC
+ driver provides interface to configure DCC block and read back
+ captured data from DCC's internal SRAM.
+
config QCOM_FASTRPC
tristate "Qualcomm FastRPC"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 56de439..6fa8efa 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_TIFM_CORE) += tifm_core.o
obj-$(CONFIG_TIFM_7XX1) += tifm_7xx1.o
obj-$(CONFIG_PHANTOM) += phantom.o
obj-$(CONFIG_QCOM_COINCELL) += qcom-coincell.o
+obj-$(CONFIG_QCOM_DCC) += dcc.o
obj-$(CONFIG_QCOM_FASTRPC) += fastrpc.o
obj-$(CONFIG_SENSORS_BH1770) += bh1770glc.o
obj-$(CONFIG_SENSORS_APDS990X) += apds990x.o
diff --git a/drivers/misc/dcc.c b/drivers/misc/dcc.c
new file mode 100644
index 0000000..7231ed9
--- /dev/null
+++ b/drivers/misc/dcc.c
@@ -0,0 +1,1300 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2015-2021, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/debugfs.h>
+#include <linux/delay.h>
+#include <linux/fs.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+
+#define STATUS_READY_TIMEOUT 5000 /* microseconds */
+
+/* DCC registers */
+#define DCC_HW_INFO 0x04
+#define DCC_LL_NUM_INFO 0x10
+#define DCC_STATUS(vers) ((vers) == 1 ? 0x0c : 0x1c)
+#define DCC_LL_LOCK 0x00
+#define DCC_LL_CFG 0x04
+#define DCC_LL_BASE 0x08
+#define DCC_FD_BASE 0x0c
+#define DCC_LL_TIMEOUT 0x10
+#define DCC_LL_INT_ENABLE 0x18
+#define DCC_LL_INT_STATUS 0x1c
+#define DCC_LL_SW_TRIGGER 0x2c
+#define DCC_LL_BUS_ACCESS_STATUS 0x30
+
+/* Default value used if a bit 6 in the HW_INFO register is set. */
+#define DCC_FIX_LOOP_OFFSET 16
+
+/* Mask to find version info from HW_Info register */
+#define DCC_VER_INFO_MASK BIT(9)
+
+#define MAX_DCC_OFFSET GENMASK(9, 2)
+#define MAX_DCC_LEN GENMASK(6, 0)
+#define MAX_LOOP_CNT GENMASK(7, 0)
+#define MAX_LOOP_ADDR 10
+
+#define DCC_ADDR_DESCRIPTOR 0x00
+#define DCC_ADDR_LIMIT 27
+#define DCC_WORD_SIZE sizeof(u32)
+#define DCC_ADDR_RANGE_MASK GENMASK(31, 4)
+#define DCC_LOOP_DESCRIPTOR BIT(30)
+#define DCC_RD_MOD_WR_DESCRIPTOR BIT(31)
+#define DCC_LINK_DESCRIPTOR GENMASK(31, 30)
+#define DCC_STATUS_MASK GENMASK(1, 0)
+#define DCC_LOCK_MASK BIT(0)
+#define DCC_LOOP_OFFSET_MASK BIT(6)
+#define DCC_TRIGGER_MASK BIT(9)
+
+#define DCC_WRITE_MASK BIT(15)
+#define DCC_WRITE_OFF_MASK GENMASK(7, 0)
+#define DCC_WRITE_LEN_MASK GENMASK(14, 8)
+
+#define DCC_READ_IND 0x00
+#define DCC_WRITE_IND (BIT(28))
+
+#define DCC_AHB_IND 0x00
+#define DCC_APB_IND BIT(29)
+
+#define DCC_MAX_LINK_LIST 8
+
+#define DCC_VER_MASK2 GENMASK(5, 0)
+
+#define DCC_SRAM_WORD_LENGTH 4
+
+#define DCC_RD_MOD_WR_ADDR 0xC105E
+
+enum dcc_descriptor_type {
+ DCC_READ_TYPE,
+ DCC_LOOP_TYPE,
+ DCC_READ_WRITE_TYPE,
+ DCC_WRITE_TYPE
+};
+
+struct dcc_config_entry {
+ u32 base;
+ u32 offset;
+ u32 len;
+ u32 loop_cnt;
+ u32 write_val;
+ u32 mask;
+ bool apb_bus;
+ enum dcc_descriptor_type desc_type;
+ struct list_head list;
+};
+
+/**
+ * struct dcc_drvdata - configuration information related to a dcc device
+ * @base: Base Address of the dcc device
+ * @dev: The device attached to the driver data
+ * @mutex: Lock to protect access and manipulation of dcc_drvdata
+ * @ram_base: Base address for the SRAM dedicated for the dcc device
+ * @ram_size: Total size of the SRAM dedicated for the dcc device
+ * @ram_offset: Offset to the SRAM dedicated for dcc device
+ * @mem_map_ver: Memory map version of DCC hardware
+ * @ram_cfg: Used for address limit calculation for dcc
+ * @ram_start: Starting address of DCC SRAM
+ * @sram_dev: Miscellaneous device equivalent of dcc SRAM
+ * @cfg_head: Points to the head of the linked list of addresses
+ * @dbg_dir: The dcc debugfs directory under which all the debugfs files are placed
+ * @nr_link_list: Total number of linkedlists supported by the DCC configuration
+ * @loop_shift: Loop offset bits range for the addresses
+ * @enable_bitmap: Bitmap to capture the enabled status of each linked list of addresses
+ */
+struct dcc_drvdata {
+ void __iomem *base;
+ void __iomem *ram_base;
+ struct device *dev;
+ struct mutex mutex;
+ size_t ram_size;
+ size_t ram_offset;
+ int mem_map_ver;
+ unsigned int ram_cfg;
+ unsigned int ram_start;
+ struct miscdevice sram_dev;
+ struct list_head *cfg_head;
+ struct dentry *dbg_dir;
+ size_t nr_link_list;
+ u8 loop_shift;
+ unsigned long *enable_bitmap;
+};
+
+struct dcc_cfg_attr {
+ u32 addr;
+ u32 prev_addr;
+ u32 prev_off;
+ u32 link;
+ u32 sram_offset;
+};
+
+struct dcc_cfg_loop_attr {
+ u32 loop_cnt;
+ u32 loop_len;
+ u32 loop_off;
+ bool loop_start;
+};
+
+static inline u32 dcc_list_offset(int version)
+{
+ return version == 1 ? 0x1c : version == 2 ? 0x2c : 0x34;
+}
+
+static inline void dcc_list_writel(struct dcc_drvdata *drvdata,
+ u32 ll, u32 val, u32 off)
+{
+ u32 offset = dcc_list_offset(drvdata->mem_map_ver) + off;
+
+ writel(val, drvdata->base + ll * 0x80 + offset);
+}
+
+static inline u32 dcc_list_readl(struct dcc_drvdata *drvdata, u32 ll, u32 off)
+{
+ u32 offset = dcc_list_offset(drvdata->mem_map_ver) + off;
+
+ return readl(drvdata->base + ll * 0x80 + offset);
+}
+
+static void dcc_sram_write_auto(struct dcc_drvdata *drvdata,
+ u32 val, u32 *off)
+{
+ /* If the overflow condition is met increment the offset
+ * and return to indicate that overflow has occurred
+ */
+ if (unlikely(*off > drvdata->ram_size - 4)) {
+ *off += 4;
+ return;
+ }
+
+ writel(val, drvdata->ram_base + *off);
+
+ *off += 4;
+}
+
+static int dcc_sw_trigger(struct dcc_drvdata *drvdata)
+{
+ void __iomem *addr;
+ int i;
+ u32 status;
+ u32 ll_cfg;
+ u32 tmp_ll_cfg;
+ u32 val;
+ int ret = 0;
+
+ mutex_lock(&drvdata->mutex);
+
+ for (i = 0; i < drvdata->nr_link_list; i++) {
+ if (!test_bit(i, drvdata->enable_bitmap))
+ continue;
+ ll_cfg = dcc_list_readl(drvdata, i, DCC_LL_CFG);
+ tmp_ll_cfg = ll_cfg & ~DCC_TRIGGER_MASK;
+ dcc_list_writel(drvdata, tmp_ll_cfg, i, DCC_LL_CFG);
+ dcc_list_writel(drvdata, 1, i, DCC_LL_SW_TRIGGER);
+ dcc_list_writel(drvdata, ll_cfg, i, DCC_LL_CFG);
+ }
+
+ addr = drvdata->base + DCC_STATUS(drvdata->mem_map_ver);
+ if (readl_poll_timeout(addr, val, !FIELD_GET(DCC_STATUS_MASK, val),
+ 1, STATUS_READY_TIMEOUT)) {
+ dev_err(drvdata->dev, "DCC is busy after receiving sw trigger\n");
+ ret = -EBUSY;
+ goto out_unlock;
+ }
+
+ for (i = 0; i < drvdata->nr_link_list; i++) {
+ if (!test_bit(i, drvdata->enable_bitmap))
+ continue;
+
+ status = dcc_list_readl(drvdata, i, DCC_LL_BUS_ACCESS_STATUS);
+ if (!status)
+ continue;
+
+ dev_err(drvdata->dev, "Read access error for list %d err: 0x%x\n",
+ i, status);
+ ll_cfg = dcc_list_readl(drvdata, i, DCC_LL_CFG);
+ tmp_ll_cfg = ll_cfg & ~DCC_TRIGGER_MASK;
+ dcc_list_writel(drvdata, tmp_ll_cfg, i, DCC_LL_CFG);
+ dcc_list_writel(drvdata, DCC_STATUS_MASK, i, DCC_LL_BUS_ACCESS_STATUS);
+ dcc_list_writel(drvdata, ll_cfg, i, DCC_LL_CFG);
+ ret = -ENODATA;
+ break;
+ }
+
+out_unlock:
+ mutex_unlock(&drvdata->mutex);
+ return ret;
+}
+
+static void dcc_ll_cfg_reset_link(struct dcc_cfg_attr *cfg)
+{
+ cfg->addr = 0x00;
+ cfg->link = 0;
+ cfg->prev_off = 0;
+ cfg->prev_addr = cfg->addr;
+}
+
+static void dcc_emit_read_write(struct dcc_drvdata *drvdata,
+ struct dcc_config_entry *entry,
+ struct dcc_cfg_attr *cfg)
+{
+ if (cfg->link) {
+ /*
+ * write new offset = 1 to continue
+ * processing the list
+ */
+
+ dcc_sram_write_auto(drvdata, cfg->link, &cfg->sram_offset);
+
+ /* Reset link and prev_off */
+ dcc_ll_cfg_reset_link(cfg);
+ }
+
+ cfg->addr = DCC_RD_MOD_WR_DESCRIPTOR;
+ dcc_sram_write_auto(drvdata, cfg->addr, &cfg->sram_offset);
+
+ dcc_sram_write_auto(drvdata, entry->mask, &cfg->sram_offset);
+
+ dcc_sram_write_auto(drvdata, entry->write_val, &cfg->sram_offset);
+
+ cfg->addr = 0;
+}
+
+static void dcc_emit_loop(struct dcc_drvdata *drvdata, struct dcc_config_entry *entry,
+ struct dcc_cfg_attr *cfg,
+ struct dcc_cfg_loop_attr *cfg_loop,
+ u32 *total_len)
+{
+ int loop;
+
+ /* Check if we need to write link of prev entry */
+ if (cfg->link)
+ dcc_sram_write_auto(drvdata, cfg->link, &cfg->sram_offset);
+
+ if (cfg_loop->loop_start) {
+ loop = (cfg->sram_offset - cfg_loop->loop_off) / 4;
+ loop |= (cfg_loop->loop_cnt << drvdata->loop_shift) &
+ GENMASK(DCC_ADDR_LIMIT, drvdata->loop_shift);
+ loop |= DCC_LOOP_DESCRIPTOR;
+ *total_len += (*total_len - cfg_loop->loop_len) * cfg_loop->loop_cnt;
+
+ dcc_sram_write_auto(drvdata, loop, &cfg->sram_offset);
+
+ cfg_loop->loop_start = false;
+ cfg_loop->loop_len = 0;
+ cfg_loop->loop_off = 0;
+ } else {
+ cfg_loop->loop_start = true;
+ cfg_loop->loop_cnt = entry->loop_cnt - 1;
+ cfg_loop->loop_len = *total_len;
+ cfg_loop->loop_off = cfg->sram_offset;
+ }
+
+ /* Reset link and prev_off */
+ dcc_ll_cfg_reset_link(cfg);
+}
+
+static void dcc_emit_write(struct dcc_drvdata *drvdata,
+ struct dcc_config_entry *entry,
+ struct dcc_cfg_attr *cfg)
+{
+ u32 off;
+
+ if (cfg->link) {
+ /*
+ * write new offset = 1 to continue
+ * processing the list
+ */
+ dcc_sram_write_auto(drvdata, cfg->link, &cfg->sram_offset);
+
+ /* Reset link and prev_off */
+ cfg->addr = 0x00;
+ cfg->prev_off = 0;
+ cfg->prev_addr = cfg->addr;
+ }
+
+ off = entry->offset / 4;
+ /* write new offset-length pair to correct position */
+ cfg->link |= ((off & DCC_WRITE_OFF_MASK) | DCC_WRITE_MASK |
+ FIELD_PREP(DCC_WRITE_LEN_MASK, entry->len));
+ cfg->link |= DCC_LINK_DESCRIPTOR;
+
+ /* Address type */
+ cfg->addr = (entry->base >> 4) & GENMASK(DCC_ADDR_LIMIT, 0);
+ if (entry->apb_bus)
+ cfg->addr |= DCC_ADDR_DESCRIPTOR | DCC_WRITE_IND | DCC_APB_IND;
+ else
+ cfg->addr |= DCC_ADDR_DESCRIPTOR | DCC_WRITE_IND | DCC_AHB_IND;
+ dcc_sram_write_auto(drvdata, cfg->addr, &cfg->sram_offset);
+
+ dcc_sram_write_auto(drvdata, cfg->link, &cfg->sram_offset);
+
+ dcc_sram_write_auto(drvdata, entry->write_val, &cfg->sram_offset);
+
+ cfg->addr = 0x00;
+ cfg->link = 0;
+}
+
+static int dcc_emit_read(struct dcc_drvdata *drvdata,
+ struct dcc_config_entry *entry,
+ struct dcc_cfg_attr *cfg,
+ u32 *pos, u32 *total_len)
+{
+ u32 off;
+ u32 temp_off;
+
+ cfg->addr = (entry->base >> 4) & GENMASK(27, 0);
+
+ if (entry->apb_bus)
+ cfg->addr |= DCC_ADDR_DESCRIPTOR | DCC_READ_IND | DCC_APB_IND;
+ else
+ cfg->addr |= DCC_ADDR_DESCRIPTOR | DCC_READ_IND | DCC_AHB_IND;
+
+ off = entry->offset / 4;
+
+ *total_len += entry->len * 4;
+
+ if (!cfg->prev_addr || cfg->prev_addr != cfg->addr || cfg->prev_off > off) {
+ /* Check if we need to write prev link entry */
+ if (cfg->link)
+ dcc_sram_write_auto(drvdata, cfg->link, &cfg->sram_offset);
+ dev_dbg(drvdata->dev, "DCC: sram address 0x%x\n", cfg->sram_offset);
+
+ /* Write address */
+ dcc_sram_write_auto(drvdata, cfg->addr, &cfg->sram_offset);
+
+ /* Reset link and prev_off */
+ cfg->link = 0;
+ cfg->prev_off = 0;
+ }
+
+ if ((off - cfg->prev_off) > 0xff || entry->len > MAX_DCC_LEN) {
+ dev_err(drvdata->dev, "DCC: Programming error Base: 0x%x, offset 0x%x\n",
+ entry->base, entry->offset);
+ return -EINVAL;
+ }
+
+ if (cfg->link) {
+ /*
+ * link already has one offset-length so new
+ * offset-length needs to be placed at
+ * bits [29:15]
+ */
+ *pos = 15;
+
+ /* Clear bits [31:16] */
+ cfg->link &= GENMASK(14, 0);
+ } else {
+ /*
+ * link is empty, so new offset-length needs
+ * to be placed at bits [15:0]
+ */
+ *pos = 0;
+ cfg->link = 1 << 15;
+ }
+
+ /* write new offset-length pair to correct position */
+ temp_off = (off - cfg->prev_off) & GENMASK(7, 0);
+ cfg->link |= temp_off | ((entry->len << 8) & GENMASK(14, 8)) << *pos;
+
+ cfg->link |= DCC_LINK_DESCRIPTOR;
+
+ if (*pos) {
+ dcc_sram_write_auto(drvdata, cfg->link, &cfg->sram_offset);
+ cfg->link = 0;
+ }
+
+ cfg->prev_off = off + entry->len - 1;
+ cfg->prev_addr = cfg->addr;
+ return 0;
+}
+
+static int dcc_emit_config(struct dcc_drvdata *drvdata, unsigned int curr_list)
+{
+ int ret;
+ u32 total_len, pos;
+ struct dcc_config_entry *entry;
+ struct dcc_cfg_attr cfg;
+ struct dcc_cfg_loop_attr cfg_loop;
+
+ memset(&cfg, 0, sizeof(cfg));
+ memset(&cfg_loop, 0, sizeof(cfg_loop));
+ cfg.sram_offset = drvdata->ram_cfg * 4;
+ total_len = 0;
+
+ list_for_each_entry(entry, &drvdata->cfg_head[curr_list], list) {
+ switch (entry->desc_type) {
+ case DCC_READ_WRITE_TYPE:
+ dcc_emit_read_write(drvdata, entry, &cfg);
+ break;
+
+ case DCC_LOOP_TYPE:
+ dcc_emit_loop(drvdata, entry, &cfg, &cfg_loop, &total_len);
+ break;
+
+ case DCC_WRITE_TYPE:
+ dcc_emit_write(drvdata, entry, &cfg);
+ break;
+
+ case DCC_READ_TYPE:
+ ret = dcc_emit_read(drvdata, entry, &cfg, &pos, &total_len);
+ if (ret)
+ goto err;
+ break;
+ }
+ }
+
+ if (cfg.link)
+ dcc_sram_write_auto(drvdata, cfg.link, &cfg.sram_offset);
+
+ if (cfg_loop.loop_start) {
+ dev_err(drvdata->dev, "DCC: Programming error: Loop unterminated\n");
+ ret = -EINVAL;
+ goto err;
+ }
+
+ /* Handling special case of list ending with a rd_mod_wr */
+ if (cfg.addr == DCC_RD_MOD_WR_DESCRIPTOR) {
+ cfg.addr = (DCC_RD_MOD_WR_ADDR) & GENMASK(27, 0);
+ cfg.addr |= DCC_ADDR_DESCRIPTOR;
+ dcc_sram_write_auto(drvdata, cfg.addr, &cfg.sram_offset);
+ }
+
+ /* Setting zero to indicate end of the list */
+ cfg.link = DCC_LINK_DESCRIPTOR;
+ dcc_sram_write_auto(drvdata, cfg.link, &cfg.sram_offset);
+
+ /* Check if sram offset exceeds the ram size */
+ if (cfg.sram_offset > drvdata->ram_size)
+ goto overstep;
+
+ /* Update ram_cfg and check if the data will overstep */
+ drvdata->ram_cfg = (cfg.sram_offset + total_len) / 4;
+
+ if (cfg.sram_offset + total_len > drvdata->ram_size) {
+ cfg.sram_offset += total_len;
+ goto overstep;
+ }
+
+ drvdata->ram_start = cfg.sram_offset / 4;
+ return 0;
+overstep:
+ ret = -EINVAL;
+ memset_io(drvdata->ram_base, 0, drvdata->ram_size);
+
+err:
+ return ret;
+}
+
+static bool dcc_valid_list(struct dcc_drvdata *drvdata, unsigned int curr_list)
+{
+ u32 lock_reg;
+
+ if (list_empty(&drvdata->cfg_head[curr_list]))
+ return false;
+
+ if (test_bit(curr_list, drvdata->enable_bitmap)) {
+ dev_err(drvdata->dev, "List %d is already enabled\n", curr_list);
+ return false;
+ }
+
+ lock_reg = dcc_list_readl(drvdata, curr_list, DCC_LL_LOCK);
+ if (lock_reg & DCC_LOCK_MASK) {
+ dev_err(drvdata->dev, "List %d is already locked\n", curr_list);
+ return false;
+ }
+
+ return true;
+}
+
+static bool is_dcc_enabled(struct dcc_drvdata *drvdata)
+{
+ int list;
+
+ for (list = 0; list < drvdata->nr_link_list; list++)
+ if (test_bit(list, drvdata->enable_bitmap))
+ return true;
+
+ return false;
+}
+
+static int dcc_enable(struct dcc_drvdata *drvdata, unsigned int curr_list)
+{
+ int ret;
+ u32 ram_cfg_base;
+
+ mutex_lock(&drvdata->mutex);
+
+ if (!dcc_valid_list(drvdata, curr_list)) {
+ ret = -EINVAL;
+ goto out_unlock;
+ }
+
+ /* Fill dcc sram with the poison value.
+ * This helps in understanding bus
+ * hang from registers returning a zero
+ */
+ if (!is_dcc_enabled(drvdata))
+ memset_io(drvdata->ram_base, 0xde, drvdata->ram_size);
+
+ /* 1. Take ownership of the list */
+ dcc_list_writel(drvdata, DCC_LOCK_MASK, curr_list, DCC_LL_LOCK);
+
+ /* 2. Program linked-list in the SRAM */
+ ram_cfg_base = drvdata->ram_cfg;
+ ret = dcc_emit_config(drvdata, curr_list);
+ if (ret) {
+ dcc_list_writel(drvdata, 0, curr_list, DCC_LL_LOCK);
+ goto out_unlock;
+ }
+
+ /* 3. Program DCC_RAM_CFG reg */
+ dcc_list_writel(drvdata, ram_cfg_base +
+ drvdata->ram_offset / 4, curr_list, DCC_LL_BASE);
+ dcc_list_writel(drvdata, drvdata->ram_start +
+ drvdata->ram_offset / 4, curr_list, DCC_FD_BASE);
+ dcc_list_writel(drvdata, 0xFFF, curr_list, DCC_LL_TIMEOUT);
+
+ /* 4. Clears interrupt status register */
+ dcc_list_writel(drvdata, 0, curr_list, DCC_LL_INT_ENABLE);
+ dcc_list_writel(drvdata, (BIT(0) | BIT(1) | BIT(2)),
+ curr_list, DCC_LL_INT_STATUS);
+
+ set_bit(curr_list, drvdata->enable_bitmap);
+
+ /* 5. Configure trigger */
+ dcc_list_writel(drvdata, DCC_TRIGGER_MASK,
+ curr_list, DCC_LL_CFG);
+
+out_unlock:
+ mutex_unlock(&drvdata->mutex);
+ return ret;
+}
+
+static void dcc_disable(struct dcc_drvdata *drvdata, int curr_list)
+{
+ mutex_lock(&drvdata->mutex);
+
+ if (!test_bit(curr_list, drvdata->enable_bitmap))
+ goto out_unlock;
+ dcc_list_writel(drvdata, 0, curr_list, DCC_LL_CFG);
+ dcc_list_writel(drvdata, 0, curr_list, DCC_LL_BASE);
+ dcc_list_writel(drvdata, 0, curr_list, DCC_FD_BASE);
+ dcc_list_writel(drvdata, 0, curr_list, DCC_LL_LOCK);
+ clear_bit(curr_list, drvdata->enable_bitmap);
+out_unlock:
+ mutex_unlock(&drvdata->mutex);
+}
+
+static u32 dcc_filp_curr_list(const struct file *filp)
+{
+ struct dentry *dentry = file_dentry(filp);
+ int curr_list, ret;
+
+ ret = kstrtoint(dentry->d_parent->d_name.name, 0, &curr_list);
+ if (ret)
+ return ret;
+
+ return curr_list;
+}
+
+static ssize_t enable_read(struct file *filp, char __user *userbuf,
+ size_t count, loff_t *ppos)
+{
+ char *buf;
+ struct dcc_drvdata *drvdata = filp->private_data;
+
+ mutex_lock(&drvdata->mutex);
+
+ if (is_dcc_enabled(drvdata))
+ buf = "Y\n";
+ else
+ buf = "N\n";
+
+ mutex_unlock(&drvdata->mutex);
+
+ return simple_read_from_buffer(userbuf, count, ppos, buf, strlen(buf));
+}
+
+static ssize_t enable_write(struct file *filp, const char __user *userbuf,
+ size_t count, loff_t *ppos)
+{
+ int ret = 0, curr_list;
+ bool val;
+ struct dcc_drvdata *drvdata = filp->private_data;
+
+ curr_list = dcc_filp_curr_list(filp);
+ if (curr_list < 0)
+ return curr_list;
+
+ ret = kstrtobool_from_user(userbuf, count, &val);
+ if (ret < 0)
+ return ret;
+
+ if (val) {
+ ret = dcc_enable(drvdata, curr_list);
+ if (ret)
+ return ret;
+ } else {
+ dcc_disable(drvdata, curr_list);
+ }
+
+ return count;
+}
+
+static const struct file_operations enable_fops = {
+ .read = enable_read,
+ .write = enable_write,
+ .open = simple_open,
+ .llseek = generic_file_llseek,
+};
+
+static ssize_t trigger_write(struct file *filp,
+ const char __user *user_buf, size_t count,
+ loff_t *ppos)
+{
+ int ret;
+ unsigned int val;
+ struct dcc_drvdata *drvdata = filp->private_data;
+
+ ret = kstrtouint_from_user(user_buf, count, 0, &val);
+ if (ret < 0)
+ return ret;
+
+ if (val != 1)
+ return -EINVAL;
+
+ ret = dcc_sw_trigger(drvdata);
+ if (ret < 0)
+ return ret;
+
+ return count;
+}
+
+static const struct file_operations trigger_fops = {
+ .write = trigger_write,
+ .open = simple_open,
+ .llseek = generic_file_llseek,
+};
+
+static int dcc_config_add(struct dcc_drvdata *drvdata, unsigned int addr,
+ unsigned int len, bool apb_bus, int curr_list)
+{
+ int ret = 0;
+ struct dcc_config_entry *entry, *pentry;
+ unsigned int base, offset;
+
+ mutex_lock(&drvdata->mutex);
+
+ if (!len || len > drvdata->ram_size / DCC_WORD_SIZE) {
+ dev_err(drvdata->dev, "DCC: Invalid length\n");
+ ret = -EINVAL;
+ goto out_unlock;
+ }
+
+ base = addr & DCC_ADDR_RANGE_MASK;
+
+ if (!list_empty(&drvdata->cfg_head[curr_list])) {
+ pentry = list_last_entry(&drvdata->cfg_head[curr_list],
+ struct dcc_config_entry, list);
+
+ if (pentry->desc_type == DCC_READ_TYPE &&
+ addr >= (pentry->base + pentry->offset) &&
+ addr <= (pentry->base + pentry->offset + MAX_DCC_OFFSET)) {
+ /* Re-use base address from last entry */
+ base = pentry->base;
+
+ if ((pentry->len * 4 + pentry->base + pentry->offset)
+ == addr) {
+ len += pentry->len;
+
+ if (len > MAX_DCC_LEN)
+ pentry->len = MAX_DCC_LEN;
+ else
+ pentry->len = len;
+
+ addr = pentry->base + pentry->offset +
+ pentry->len * 4;
+ len -= pentry->len;
+ }
+ }
+ }
+
+ offset = addr - base;
+
+ while (len) {
+ entry = kzalloc(sizeof(*entry), GFP_KERNEL);
+ if (!entry) {
+ ret = -ENOMEM;
+ goto out_unlock;
+ }
+
+ entry->base = base;
+ entry->offset = offset;
+ entry->len = min_t(u32, len, MAX_DCC_LEN);
+ entry->desc_type = DCC_READ_TYPE;
+ entry->apb_bus = apb_bus;
+ INIT_LIST_HEAD(&entry->list);
+ list_add_tail(&entry->list,
+ &drvdata->cfg_head[curr_list]);
+
+ len -= entry->len;
+ offset += MAX_DCC_LEN * 4;
+ }
+
+out_unlock:
+ mutex_unlock(&drvdata->mutex);
+ return ret;
+}
+
+static ssize_t dcc_config_add_read(struct dcc_drvdata *drvdata, char *buf, int curr_list)
+{
+ bool bus;
+ int len, nval;
+ unsigned int base;
+ char apb_bus[4];
+
+ nval = sscanf(buf, "%x %i %3s", &base, &len, apb_bus);
+ if (nval <= 0 || nval > 3)
+ return -EINVAL;
+
+ if (nval == 1) {
+ len = 1;
+ bus = false;
+ } else if (nval == 2) {
+ bus = false;
+ } else if (!strcmp("apb", apb_bus)) {
+ bus = true;
+ } else if (!strcmp("ahb", apb_bus)) {
+ bus = false;
+ } else {
+ return -EINVAL;
+ }
+
+ return dcc_config_add(drvdata, base, len, bus, curr_list);
+}
+
+static void dcc_config_reset(struct dcc_drvdata *drvdata)
+{
+ struct dcc_config_entry *entry, *temp;
+ int curr_list;
+
+ mutex_lock(&drvdata->mutex);
+
+ for (curr_list = 0; curr_list < drvdata->nr_link_list; curr_list++) {
+ list_for_each_entry_safe(entry, temp,
+ &drvdata->cfg_head[curr_list], list) {
+ list_del(&entry->list);
+ kfree(entry);
+ }
+ }
+ drvdata->ram_start = 0;
+ drvdata->ram_cfg = 0;
+ mutex_unlock(&drvdata->mutex);
+}
+
+static ssize_t config_reset_write(struct file *filp,
+ const char __user *user_buf, size_t count,
+ loff_t *ppos)
+{
+ unsigned int val, ret;
+ struct dcc_drvdata *drvdata = filp->private_data;
+
+ ret = kstrtouint_from_user(user_buf, count, 0, &val);
+ if (ret < 0)
+ return ret;
+
+ if (val)
+ dcc_config_reset(drvdata);
+
+ return count;
+}
+
+static const struct file_operations config_reset_fops = {
+ .write = config_reset_write,
+ .open = simple_open,
+ .llseek = generic_file_llseek,
+};
+
+static ssize_t ready_read(struct file *filp, char __user *userbuf,
+ size_t count, loff_t *ppos)
+{
+ int ret = 0;
+ char *buf;
+ struct dcc_drvdata *drvdata = filp->private_data;
+
+ mutex_lock(&drvdata->mutex);
+
+ if (!is_dcc_enabled(drvdata)) {
+ ret = -EINVAL;
+ goto out_unlock;
+ }
+
+ if (!FIELD_GET(BIT(1), readl(drvdata->base + DCC_STATUS(drvdata->mem_map_ver))))
+ buf = "Y\n";
+ else
+ buf = "N\n";
+out_unlock:
+ mutex_unlock(&drvdata->mutex);
+
+ if (ret < 0)
+ return -EINVAL;
+ else
+ return simple_read_from_buffer(userbuf, count, ppos, buf, strlen(buf) + 1);
+}
+
+static const struct file_operations ready_fops = {
+ .read = ready_read,
+ .open = simple_open,
+ .llseek = generic_file_llseek,
+};
+
+static int dcc_add_loop(struct dcc_drvdata *drvdata, unsigned long loop_cnt, int curr_list)
+{
+ struct dcc_config_entry *entry;
+
+ entry = kzalloc(sizeof(*entry), GFP_KERNEL);
+ if (!entry)
+ return -ENOMEM;
+
+ entry->loop_cnt = min_t(u32, loop_cnt, MAX_LOOP_CNT);
+ entry->desc_type = DCC_LOOP_TYPE;
+ INIT_LIST_HEAD(&entry->list);
+ list_add_tail(&entry->list, &drvdata->cfg_head[curr_list]);
+
+ return 0;
+}
+
+static ssize_t dcc_config_add_loop(struct dcc_drvdata *drvdata, char *buf, int curr_list)
+{
+ int ret, i = 0;
+ char *token, *input;
+ char delim[2] = " ";
+ unsigned int val[MAX_LOOP_ADDR];
+
+ input = buf;
+
+ while ((token = strsep(&input, delim)) && i < MAX_LOOP_ADDR) {
+ ret = kstrtoint(token, 0, &val[i++]);
+ if (ret)
+ return ret;
+ }
+
+ if (token) {
+ dev_err(drvdata->dev, "Max limit %u of loop address exceeded",
+ MAX_LOOP_ADDR);
+ return -EINVAL;
+ }
+
+ if (val[1] < 1 || val[1] > 8)
+ return -EINVAL;
+
+ ret = dcc_add_loop(drvdata, val[0], curr_list);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < val[1]; i++)
+ dcc_config_add(drvdata, val[i + 2], 1, false, curr_list);
+
+ return dcc_add_loop(drvdata, 1, curr_list);
+}
+
+static int dcc_rd_mod_wr_add(struct dcc_drvdata *drvdata, unsigned int mask,
+ unsigned int val, int curr_list)
+{
+ int ret = 0;
+ struct dcc_config_entry *entry;
+
+ mutex_lock(&drvdata->mutex);
+
+ if (list_empty(&drvdata->cfg_head[curr_list])) {
+ dev_err(drvdata->dev, "DCC: No read address programmed\n");
+ ret = -EPERM;
+ goto out_unlock;
+ }
+
+ entry = devm_kzalloc(drvdata->dev, sizeof(*entry), GFP_KERNEL);
+ if (!entry) {
+ ret = -ENOMEM;
+ goto out_unlock;
+ }
+
+ entry->desc_type = DCC_READ_WRITE_TYPE;
+ entry->mask = mask;
+ entry->write_val = val;
+ list_add_tail(&entry->list, &drvdata->cfg_head[curr_list]);
+out_unlock:
+ mutex_unlock(&drvdata->mutex);
+ return ret;
+}
+
+static ssize_t dcc_config_add_read_write(struct dcc_drvdata *drvdata, char *buf, int curr_list)
+{
+ int ret;
+ int nval;
+ unsigned int addr, mask, val;
+
+ nval = sscanf(buf, "%x %x %x", &addr, &mask, &val);
+
+ if (nval <= 1 || nval > 3)
+ return -EINVAL;
+
+ ret = dcc_config_add(drvdata, addr, 1, false, curr_list);
+ if (ret)
+ return ret;
+
+ return dcc_rd_mod_wr_add(drvdata, mask, val, curr_list);
+}
+
+static int dcc_add_write(struct dcc_drvdata *drvdata, unsigned int addr,
+ unsigned int write_val, int apb_bus, int curr_list)
+{
+ struct dcc_config_entry *entry;
+
+ entry = devm_kzalloc(drvdata->dev, sizeof(*entry), GFP_KERNEL);
+ if (!entry)
+ return -ENOMEM;
+
+ entry->desc_type = DCC_WRITE_TYPE;
+ entry->base = addr & GENMASK(31, 4);
+ entry->offset = addr - entry->base;
+ entry->write_val = write_val;
+ entry->len = 1;
+ entry->apb_bus = apb_bus;
+ list_add_tail(&entry->list, &drvdata->cfg_head[curr_list]);
+
+ return 0;
+}
+
+static ssize_t dcc_config_add_write(struct dcc_drvdata *drvdata, char *buf, int curr_list)
+{
+ bool bus;
+ int nval;
+ unsigned int addr, write_val;
+ char apb_bus[4];
+
+ nval = sscanf(buf, "%x %x %3s", &addr, &write_val, apb_bus);
+
+ if (nval <= 1 || nval > 3)
+ return -EINVAL;
+
+ if (nval == 2)
+ bus = true;
+
+ if (nval == 3) {
+ if (!strcmp("apb", apb_bus))
+ bus = true;
+ else if (!strcmp("ahb", apb_bus))
+ bus = false;
+ else
+ return -EINVAL;
+ }
+
+ return dcc_add_write(drvdata, addr, write_val, bus, curr_list);
+}
+
+static int config_show(struct seq_file *m, void *data)
+{
+ struct dcc_drvdata *drvdata = m->private;
+ struct dcc_config_entry *entry;
+ int index = 0, curr_list;
+
+ curr_list = dcc_filp_curr_list(m->file);
+ if (curr_list < 0)
+ return curr_list;
+
+ mutex_lock(&drvdata->mutex);
+
+ list_for_each_entry(entry, &drvdata->cfg_head[curr_list], list) {
+ index++;
+ switch (entry->desc_type) {
+ case DCC_READ_WRITE_TYPE:
+ seq_printf(m, "RW mask: 0x%x, val: 0x%x\n index: 0x%x\n",
+ entry->mask, entry->write_val, index);
+ break;
+ case DCC_LOOP_TYPE:
+ seq_printf(m, "L index: 0x%x Loop: %d\n", index, entry->loop_cnt);
+ break;
+ case DCC_WRITE_TYPE:
+ seq_printf(m, "W Base:0x%x, Offset: 0x%x, val: 0x%x, APB: %d\n, Index: 0x%x\n",
+ entry->base, entry->offset, entry->write_val, entry->apb_bus,
+ index);
+ break;
+ case DCC_READ_TYPE:
+ seq_printf(m, "R Base:0x%x, Offset: 0x%x, len: 0x%x, APB: %d\n, Index: 0x%x\n",
+ entry->base, entry->offset, entry->len, entry->apb_bus, index);
+ }
+ }
+ mutex_unlock(&drvdata->mutex);
+ return 0;
+}
+
+static int config_open(struct inode *inode, struct file *file)
+{
+ struct dcc_drvdata *drvdata = inode->i_private;
+
+ return single_open(file, config_show, drvdata);
+}
+
+static ssize_t config_write(struct file *filp,
+ const char __user *user_buf, size_t count,
+ loff_t *ppos)
+{
+ int ret, curr_list;
+ char *token, buf[50];
+ char *bufp = buf;
+ char *delim = " ";
+ struct dcc_drvdata *drvdata = filp->private_data;
+
+ if (count > sizeof(buf) || count == 0)
+ return -EINVAL;
+
+ ret = copy_from_user(buf, user_buf, count);
+ if (ret)
+ return -EFAULT;
+
+ curr_list = dcc_filp_curr_list(filp);
+ if (curr_list < 0)
+ return curr_list;
+
+ if (buf[count - 1] == '\n')
+ buf[count - 1] = '\0';
+ else
+ return -EINVAL;
+
+ token = strsep(&bufp, delim);
+
+ if (!strcmp("R", token)) {
+ ret = dcc_config_add_read(drvdata, bufp, curr_list);
+ } else if (!strcmp("W", token)) {
+ ret = dcc_config_add_write(drvdata, bufp, curr_list);
+ } else if (!strcmp("RW", token)) {
+ ret = dcc_config_add_read_write(drvdata, bufp, curr_list);
+ } else if (!strcmp("L", token)) {
+ ret = dcc_config_add_loop(drvdata, bufp, curr_list);
+ } else {
+ dev_err(drvdata->dev, "%s is not a correct input\n", token);
+ return -EINVAL;
+ }
+
+ if (ret)
+ return ret;
+
+ return count;
+}
+
+static const struct file_operations config_fops = {
+ .open = config_open,
+ .read = seq_read,
+ .write = config_write,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static void dcc_delete_debug_dir(struct dcc_drvdata *drvdata)
+{
+ debugfs_remove_recursive(drvdata->dbg_dir);
+};
+
+static void dcc_create_debug_dir(struct dcc_drvdata *drvdata)
+{
+ int i;
+ char list_num[10];
+ struct dentry *dcc_dev, *list;
+ struct device *dev = drvdata->dev;
+
+ drvdata->dbg_dir = debugfs_create_dir(KBUILD_MODNAME, NULL);
+ dcc_dev = debugfs_create_dir(dev_name(dev), drvdata->dbg_dir);
+
+ for (i = 0; i <= drvdata->nr_link_list; i++) {
+ sprintf(list_num, "%d", i);
+ list = debugfs_create_dir(list_num, dcc_dev);
+ debugfs_create_file("enable", 0600, list, drvdata, &enable_fops);
+ debugfs_create_file("config", 0600, list, drvdata, &config_fops);
+ }
+
+ debugfs_create_file("trigger", 0200, drvdata->dbg_dir, drvdata, &trigger_fops);
+ debugfs_create_file("ready", 0400, drvdata->dbg_dir, drvdata, &ready_fops);
+ debugfs_create_file("config_reset", 0200, drvdata->dbg_dir,
+ drvdata, &config_reset_fops);
+}
+
+static ssize_t dcc_sram_read(struct file *file, char __user *data,
+ size_t len, loff_t *ppos)
+{
+ unsigned char *buf;
+ struct dcc_drvdata *drvdata;
+
+ drvdata = container_of(file->private_data, struct dcc_drvdata,
+ sram_dev);
+
+ /* EOF check */
+ if (*ppos >= drvdata->ram_size)
+ return 0;
+
+ if ((*ppos + len) > drvdata->ram_size)
+ len = (drvdata->ram_size - *ppos);
+
+ buf = kzalloc(len, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ memcpy_fromio(buf, drvdata->ram_base + *ppos, len);
+
+ if (copy_to_user(data, buf, len)) {
+ kfree(buf);
+ return -EFAULT;
+ }
+
+ *ppos += len;
+
+ kfree(buf);
+
+ return len;
+}
+
+static const struct file_operations dcc_sram_fops = {
+ .owner = THIS_MODULE,
+ .read = dcc_sram_read,
+ .llseek = no_llseek,
+};
+
+static int dcc_sram_dev_init(struct dcc_drvdata *drvdata)
+{
+ drvdata->sram_dev.minor = MISC_DYNAMIC_MINOR;
+ drvdata->sram_dev.name = "dcc_sram";
+ drvdata->sram_dev.fops = &dcc_sram_fops;
+
+ return misc_register(&drvdata->sram_dev);
+}
+
+static void dcc_sram_dev_exit(struct dcc_drvdata *drvdata)
+{
+ misc_deregister(&drvdata->sram_dev);
+}
+
+static int dcc_probe(struct platform_device *pdev)
+{
+ u32 val;
+ int ret = 0, i;
+ struct device *dev = &pdev->dev;
+ struct dcc_drvdata *drvdata;
+ struct resource *res;
+
+ drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata)
+ return -ENOMEM;
+
+ drvdata->dev = &pdev->dev;
+ platform_set_drvdata(pdev, drvdata);
+
+ drvdata->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(drvdata->base))
+ return PTR_ERR(drvdata->base);
+
+ drvdata->ram_base = devm_platform_get_and_ioremap_resource(pdev, 1, &res);
+ if (IS_ERR(drvdata->ram_base))
+ return PTR_ERR(drvdata->ram_base);
+
+ drvdata->ram_size = resource_size(res);
+
+ drvdata->ram_offset = (size_t)of_device_get_match_data(&pdev->dev);
+
+ val = readl(drvdata->base + DCC_HW_INFO);
+
+ if (FIELD_GET(DCC_VER_INFO_MASK, val)) {
+ drvdata->mem_map_ver = 3;
+ drvdata->nr_link_list = readl(drvdata->base + DCC_LL_NUM_INFO);
+ if (!drvdata->nr_link_list)
+ return -EINVAL;
+ } else if ((val & DCC_VER_MASK2) == DCC_VER_MASK2) {
+ drvdata->mem_map_ver = 2;
+ drvdata->nr_link_list = readl(drvdata->base + DCC_LL_NUM_INFO);
+ if (!drvdata->nr_link_list)
+ return -EINVAL;
+ } else {
+ drvdata->mem_map_ver = 1;
+ drvdata->nr_link_list = DCC_MAX_LINK_LIST;
+ }
+
+ /* Either set the fixed loop offset or calculate
+ * it from the total number of words in dcc_sram.
+ * Max consecutive addresses dcc can loop is
+ * equivalent to the words in dcc_sram.
+ */
+ if (val & DCC_LOOP_OFFSET_MASK)
+ drvdata->loop_shift = DCC_FIX_LOOP_OFFSET;
+ else
+ drvdata->loop_shift = get_bitmask_order((drvdata->ram_offset +
+ drvdata->ram_size) / DCC_SRAM_WORD_LENGTH - 1);
+
+ mutex_init(&drvdata->mutex);
+
+ drvdata->enable_bitmap = devm_kcalloc(dev, BITS_TO_LONGS(drvdata->nr_link_list),
+ sizeof(*drvdata->enable_bitmap), GFP_KERNEL);
+ if (!drvdata->enable_bitmap)
+ return -ENOMEM;
+
+ drvdata->cfg_head = devm_kcalloc(dev, drvdata->nr_link_list,
+ sizeof(*drvdata->cfg_head), GFP_KERNEL);
+ if (!drvdata->cfg_head)
+ return -ENOMEM;
+
+ for (i = 0; i < drvdata->nr_link_list; i++)
+ INIT_LIST_HEAD(&drvdata->cfg_head[i]);
+
+ ret = dcc_sram_dev_init(drvdata);
+ if (ret) {
+ dev_err(drvdata->dev, "DCC: sram node not registered.\n");
+ return ret;
+ }
+
+ dcc_create_debug_dir(drvdata);
+
+ return 0;
+}
+
+static int dcc_remove(struct platform_device *pdev)
+{
+ struct dcc_drvdata *drvdata = platform_get_drvdata(pdev);
+
+ dcc_delete_debug_dir(drvdata);
+ dcc_sram_dev_exit(drvdata);
+ dcc_config_reset(drvdata);
+
+ return 0;
+}
+
+static const struct of_device_id dcc_match_table[] = {
+ { .compatible = "qcom,sc7180-dcc", .data = (void *)0x6000 },
+ { .compatible = "qcom,sc7280-dcc", .data = (void *)0x12000 },
+ { .compatible = "qcom,sdm845-dcc", .data = (void *)0x6000 },
+ { .compatible = "qcom,sm8150-dcc", .data = (void *)0x5000 },
+ { }
+};
+MODULE_DEVICE_TABLE(of, dcc_match_table);
+
+static struct platform_driver dcc_driver = {
+ .probe = dcc_probe,
+ .remove = dcc_remove,
+ .driver = {
+ .name = "qcom-dcc",
+ .of_match_table = dcc_match_table,
+ },
+};
+
+module_platform_driver(dcc_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Qualcomm Technologies Inc. DCC driver");
+
--
2.7.4
On Tue, Apr 18, 2023 at 08:52:36PM +0530, Souradeep Chowdhury wrote:
> The DCC is a DMA Engine designed to capture and store data during system
> crash or software triggers. The DCC operates based on user inputs via
> the debugfs interface. The user gives addresses as inputs and these
> addresses are stored in the dcc sram. In case of a system crash or a
> manual software trigger by the user through the debugfs interface, the
> dcc captures and stores the values at these addresses. This patch
> contains the driver which has all the methods pertaining to the debugfs
> interface, auxiliary functions to support all the four fundamental
> operations of dcc namely read, write, read/modify/write and loop. The
> probe method here instantiates all the resources necessary for dcc to
> operate mainly the dedicated dcc sram where it stores the values. The
> DCC driver can be used for debugging purposes without going for a reboot
> since it can perform software triggers as well based on user inputs.
>
> Also add the documentation for debugfs entries which explains the
> functionalities of each debugfs file that has been created for dcc.
I see no documentation entries in this commit :(
> The following is the justification of using debugfs interface over the
> other alternatives like sysfs/ioctls
>
> i) As can be seen from the debugfs attribute descriptions, some of the
> debugfs attribute files here contains multiple arguments which needs to
> be accepted from the user. This goes against the design style of sysfs.
>
> ii) The user input patterns have been made simple and convenient in this
> case with the use of debugfs interface as user doesn't need to shuffle
> between different files to execute one instruction as was the case on
> using other alternatives.
Why do you have debugfs and also a misc device? How are they related?
Why both? Why not just one? What userspace tools are going to use
either of these interfaces and where are they published to show how this
all was tested?
> Signed-off-by: Souradeep Chowdhury <[email protected]>
> Reviewed-by: Alex Elder <[email protected]>
> ---
> drivers/misc/Kconfig | 8 +
> drivers/misc/Makefile | 1 +
> drivers/misc/dcc.c | 1300 +++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 1309 insertions(+)
> create mode 100644 drivers/misc/dcc.c
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 433aa41..e2bc652 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -276,6 +276,14 @@ config QCOM_COINCELL
> to maintain PMIC register and RTC state in the absence of
> external power.
>
> +config QCOM_DCC
> + tristate "Qualcomm Technologies, Inc. Data Capture and Compare(DCC) engine driver"
> + depends on ARCH_QCOM || COMPILE_TEST
> + help
> + This option enables driver for Data Capture and Compare engine. DCC
> + driver provides interface to configure DCC block and read back
> + captured data from DCC's internal SRAM.
What is the module name?
> +
> config QCOM_FASTRPC
> tristate "Qualcomm FastRPC"
> depends on ARCH_QCOM || COMPILE_TEST
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 56de439..6fa8efa 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_TIFM_CORE) += tifm_core.o
> obj-$(CONFIG_TIFM_7XX1) += tifm_7xx1.o
> obj-$(CONFIG_PHANTOM) += phantom.o
> obj-$(CONFIG_QCOM_COINCELL) += qcom-coincell.o
> +obj-$(CONFIG_QCOM_DCC) += dcc.o
Why such a generic name? Shouldn't it be qcom-dcc?
> obj-$(CONFIG_QCOM_FASTRPC) += fastrpc.o
> obj-$(CONFIG_SENSORS_BH1770) += bh1770glc.o
> obj-$(CONFIG_SENSORS_APDS990X) += apds990x.o
> diff --git a/drivers/misc/dcc.c b/drivers/misc/dcc.c
> new file mode 100644
> index 0000000..7231ed9
> --- /dev/null
> +++ b/drivers/misc/dcc.c
> @@ -0,0 +1,1300 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2015-2021, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved.
No work happened on this code in 2022? All 22 of these entries were
only in 2021 and 2023?
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bitops.h>
> +#include <linux/debugfs.h>
> +#include <linux/delay.h>
> +#include <linux/fs.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/miscdevice.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/uaccess.h>
> +
> +#define STATUS_READY_TIMEOUT 5000 /* microseconds */
> +
> +/* DCC registers */
> +#define DCC_HW_INFO 0x04
> +#define DCC_LL_NUM_INFO 0x10
> +#define DCC_STATUS(vers) ((vers) == 1 ? 0x0c : 0x1c)
Why isn't this just an inline function?
> +#define DCC_LL_LOCK 0x00
> +#define DCC_LL_CFG 0x04
> +#define DCC_LL_BASE 0x08
> +#define DCC_FD_BASE 0x0c
> +#define DCC_LL_TIMEOUT 0x10
> +#define DCC_LL_INT_ENABLE 0x18
> +#define DCC_LL_INT_STATUS 0x1c
> +#define DCC_LL_SW_TRIGGER 0x2c
> +#define DCC_LL_BUS_ACCESS_STATUS 0x30
> +
> +/* Default value used if a bit 6 in the HW_INFO register is set. */
> +#define DCC_FIX_LOOP_OFFSET 16
> +
> +/* Mask to find version info from HW_Info register */
> +#define DCC_VER_INFO_MASK BIT(9)
> +
> +#define MAX_DCC_OFFSET GENMASK(9, 2)
> +#define MAX_DCC_LEN GENMASK(6, 0)
> +#define MAX_LOOP_CNT GENMASK(7, 0)
> +#define MAX_LOOP_ADDR 10
> +
> +#define DCC_ADDR_DESCRIPTOR 0x00
> +#define DCC_ADDR_LIMIT 27
> +#define DCC_WORD_SIZE sizeof(u32)
> +#define DCC_ADDR_RANGE_MASK GENMASK(31, 4)
> +#define DCC_LOOP_DESCRIPTOR BIT(30)
> +#define DCC_RD_MOD_WR_DESCRIPTOR BIT(31)
> +#define DCC_LINK_DESCRIPTOR GENMASK(31, 30)
> +#define DCC_STATUS_MASK GENMASK(1, 0)
> +#define DCC_LOCK_MASK BIT(0)
> +#define DCC_LOOP_OFFSET_MASK BIT(6)
> +#define DCC_TRIGGER_MASK BIT(9)
> +
> +#define DCC_WRITE_MASK BIT(15)
> +#define DCC_WRITE_OFF_MASK GENMASK(7, 0)
> +#define DCC_WRITE_LEN_MASK GENMASK(14, 8)
> +
> +#define DCC_READ_IND 0x00
> +#define DCC_WRITE_IND (BIT(28))
> +
> +#define DCC_AHB_IND 0x00
> +#define DCC_APB_IND BIT(29)
> +
> +#define DCC_MAX_LINK_LIST 8
> +
> +#define DCC_VER_MASK2 GENMASK(5, 0)
> +
> +#define DCC_SRAM_WORD_LENGTH 4
> +
> +#define DCC_RD_MOD_WR_ADDR 0xC105E
> +
> +enum dcc_descriptor_type {
> + DCC_READ_TYPE,
> + DCC_LOOP_TYPE,
> + DCC_READ_WRITE_TYPE,
> + DCC_WRITE_TYPE
> +};
> +
> +struct dcc_config_entry {
> + u32 base;
> + u32 offset;
> + u32 len;
> + u32 loop_cnt;
> + u32 write_val;
> + u32 mask;
> + bool apb_bus;
> + enum dcc_descriptor_type desc_type;
> + struct list_head list;
> +};
No documentation for this structure?
> +
> +/**
> + * struct dcc_drvdata - configuration information related to a dcc device
> + * @base: Base Address of the dcc device
> + * @dev: The device attached to the driver data
> + * @mutex: Lock to protect access and manipulation of dcc_drvdata
> + * @ram_base: Base address for the SRAM dedicated for the dcc device
> + * @ram_size: Total size of the SRAM dedicated for the dcc device
> + * @ram_offset: Offset to the SRAM dedicated for dcc device
> + * @mem_map_ver: Memory map version of DCC hardware
> + * @ram_cfg: Used for address limit calculation for dcc
> + * @ram_start: Starting address of DCC SRAM
> + * @sram_dev: Miscellaneous device equivalent of dcc SRAM
> + * @cfg_head: Points to the head of the linked list of addresses
> + * @dbg_dir: The dcc debugfs directory under which all the debugfs files are placed
> + * @nr_link_list: Total number of linkedlists supported by the DCC configuration
> + * @loop_shift: Loop offset bits range for the addresses
> + * @enable_bitmap: Bitmap to capture the enabled status of each linked list of addresses
> + */
> +struct dcc_drvdata {
> + void __iomem *base;
> + void __iomem *ram_base;
> + struct device *dev;
Why do you need this back-pointer here?
> + struct mutex mutex;
> + size_t ram_size;
> + size_t ram_offset;
> + int mem_map_ver;
> + unsigned int ram_cfg;
> + unsigned int ram_start;
> + struct miscdevice sram_dev;
Wait, this is the struct device, right? Or not?
> + struct list_head *cfg_head;
> + struct dentry *dbg_dir;
Why is this needed and not just looked up when necessary?
> + size_t nr_link_list;
> + u8 loop_shift;
> + unsigned long *enable_bitmap;
So this is a list of bitmaps? Why "unsigned long"? Why not u64?
> +};
> +
> +struct dcc_cfg_attr {
> + u32 addr;
> + u32 prev_addr;
> + u32 prev_off;
> + u32 link;
> + u32 sram_offset;
> +};
> +
> +struct dcc_cfg_loop_attr {
> + u32 loop_cnt;
> + u32 loop_len;
> + u32 loop_off;
> + bool loop_start;
> +};
> +
> +static inline u32 dcc_list_offset(int version)
> +{
> + return version == 1 ? 0x1c : version == 2 ? 0x2c : 0x34;
> +}
Ah, you do have an inline function for the above mentioned macro.
Please drop the macro.
And write this inline function out to be readable, single-level ?:
comments are impossible to read, let alone double-level ones.
Write code for people first, compilers second. You gain nothing by
making this terse except to confuse people.
> +
> +static inline void dcc_list_writel(struct dcc_drvdata *drvdata,
> + u32 ll, u32 val, u32 off)
> +{
> + u32 offset = dcc_list_offset(drvdata->mem_map_ver) + off;
> +
> + writel(val, drvdata->base + ll * 0x80 + offset);
What is this magic 0x80 for?
> +}
> +
> +static inline u32 dcc_list_readl(struct dcc_drvdata *drvdata, u32 ll, u32 off)
> +{
> + u32 offset = dcc_list_offset(drvdata->mem_map_ver) + off;
> +
> + return readl(drvdata->base + ll * 0x80 + offset);
Again, where did 0x80 come from?
> +}
> +
> +static void dcc_sram_write_auto(struct dcc_drvdata *drvdata,
> + u32 val, u32 *off)
> +{
> + /* If the overflow condition is met increment the offset
> + * and return to indicate that overflow has occurred
> + */
> + if (unlikely(*off > drvdata->ram_size - 4)) {
> + *off += 4;
> + return;
You didn't indicate anything here, all you did was succeed at the call,
the caller has no way of ever knowing this failed.
Why not return an error?
> + }
> +
> + writel(val, drvdata->ram_base + *off);
> +
> + *off += 4;
See, same modification as your "error" above.
How was this tested?
> +static int dcc_emit_config(struct dcc_drvdata *drvdata, unsigned int curr_list)
> +{
> + int ret;
> + u32 total_len, pos;
> + struct dcc_config_entry *entry;
> + struct dcc_cfg_attr cfg;
> + struct dcc_cfg_loop_attr cfg_loop;
> +
> + memset(&cfg, 0, sizeof(cfg));
> + memset(&cfg_loop, 0, sizeof(cfg_loop));
Why are these large structures on the stack?
And if on the stack, why not have the compiler initialize them to 0 for
you automatically?
I stopped reviewing here...
greg k-h
On 4/18/2023 9:15 PM, Greg Kroah-Hartman wrote:
> On Tue, Apr 18, 2023 at 08:52:36PM +0530, Souradeep Chowdhury wrote:
>> The DCC is a DMA Engine designed to capture and store data during system
>> crash or software triggers. The DCC operates based on user inputs via
>> the debugfs interface. The user gives addresses as inputs and these
>> addresses are stored in the dcc sram. In case of a system crash or a
>> manual software trigger by the user through the debugfs interface, the
>> dcc captures and stores the values at these addresses. This patch
>> contains the driver which has all the methods pertaining to the debugfs
>> interface, auxiliary functions to support all the four fundamental
>> operations of dcc namely read, write, read/modify/write and loop. The
>> probe method here instantiates all the resources necessary for dcc to
>> operate mainly the dedicated dcc sram where it stores the values. The
>> DCC driver can be used for debugging purposes without going for a reboot
>> since it can perform software triggers as well based on user inputs.
>>
>> Also add the documentation for debugfs entries which explains the
>> functionalities of each debugfs file that has been created for dcc.
>
> I see no documentation entries in this commit :(
My apologies, this patch was given from qcom-next tree which already has
the documentation merged. Will include it from the next versions.
>
>> The following is the justification of using debugfs interface over the
>> other alternatives like sysfs/ioctls
>>
>> i) As can be seen from the debugfs attribute descriptions, some of the
>> debugfs attribute files here contains multiple arguments which needs to
>> be accepted from the user. This goes against the design style of sysfs.
>>
>> ii) The user input patterns have been made simple and convenient in this
>> case with the use of debugfs interface as user doesn't need to shuffle
>> between different files to execute one instruction as was the case on
>> using other alternatives.
>
> Why do you have debugfs and also a misc device? How are they related?
> Why both? Why not just one? What userspace tools are going to use
> either of these interfaces and where are they published to show how this
> all was tested?
DCC has two fundamental steps of usage:-
1.Configuring the register addresses on the dcc_sram which is done by
user through the debugfs interface. For example:-
echo R 0x10c004 > /sys/kernel/debug/dcc/../3/config
Here we are configuring the register addresses for list 3, the 'R'
indicates a read operation, so this register value will be read
in case of a software trigger or kernel panic/watchdog bite and
dumped into the dcc_sram.
2.The dcc_sram content is exposed to the user in the form of a misc
device. The user can parse the content of this dcc_sram to get the
register values. There is an opensource parser available for dcc at
the following location:-
https://git.codelinaro.org/clo/le/platform/vendor/qcom-opensource/tools/-/tree/opensource-tools.lnx.1.0.r176-rel/dcc_parser
>
>> Signed-off-by: Souradeep Chowdhury <[email protected]>
>> Reviewed-by: Alex Elder <[email protected]>
>> ---
>> drivers/misc/Kconfig | 8 +
>> drivers/misc/Makefile | 1 +
>> drivers/misc/dcc.c | 1300 +++++++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 1309 insertions(+)
>> create mode 100644 drivers/misc/dcc.c
>>
>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>> index 433aa41..e2bc652 100644
>> --- a/drivers/misc/Kconfig
>> +++ b/drivers/misc/Kconfig
>> @@ -276,6 +276,14 @@ config QCOM_COINCELL
>> to maintain PMIC register and RTC state in the absence of
>> external power.
>>
>> +config QCOM_DCC
>> + tristate "Qualcomm Technologies, Inc. Data Capture and Compare(DCC) engine driver"
>> + depends on ARCH_QCOM || COMPILE_TEST
>> + help
>> + This option enables driver for Data Capture and Compare engine. DCC
>> + driver provides interface to configure DCC block and read back
>> + captured data from DCC's internal SRAM.
>
>
> What is the module name?
It's qcom-dcc, will update the name here.
>
>> +
>> config QCOM_FASTRPC
>> tristate "Qualcomm FastRPC"
>> depends on ARCH_QCOM || COMPILE_TEST
>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
>> index 56de439..6fa8efa 100644
>> --- a/drivers/misc/Makefile
>> +++ b/drivers/misc/Makefile
>> @@ -16,6 +16,7 @@ obj-$(CONFIG_TIFM_CORE) += tifm_core.o
>> obj-$(CONFIG_TIFM_7XX1) += tifm_7xx1.o
>> obj-$(CONFIG_PHANTOM) += phantom.o
>> obj-$(CONFIG_QCOM_COINCELL) += qcom-coincell.o
>> +obj-$(CONFIG_QCOM_DCC) += dcc.o
>
> Why such a generic name? Shouldn't it be qcom-dcc?
Ack
>
>
>
>> obj-$(CONFIG_QCOM_FASTRPC) += fastrpc.o
>> obj-$(CONFIG_SENSORS_BH1770) += bh1770glc.o
>> obj-$(CONFIG_SENSORS_APDS990X) += apds990x.o
>> diff --git a/drivers/misc/dcc.c b/drivers/misc/dcc.c
>> new file mode 100644
>> index 0000000..7231ed9
>> --- /dev/null
>> +++ b/drivers/misc/dcc.c
>> @@ -0,0 +1,1300 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (c) 2015-2021, The Linux Foundation. All rights reserved.
>> + * Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved.
>
> No work happened on this code in 2022? All 22 of these entries were
> only in 2021 and 2023?
Ack
>
>> + */
>> +
>> +#include <linux/bitfield.h>
>> +#include <linux/bitops.h>
>> +#include <linux/debugfs.h>
>> +#include <linux/delay.h>
>> +#include <linux/fs.h>
>> +#include <linux/io.h>
>> +#include <linux/iopoll.h>
>> +#include <linux/miscdevice.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/slab.h>
>> +#include <linux/uaccess.h>
>> +
>> +#define STATUS_READY_TIMEOUT 5000 /* microseconds */
>> +
>> +/* DCC registers */
>> +#define DCC_HW_INFO 0x04
>> +#define DCC_LL_NUM_INFO 0x10
>> +#define DCC_STATUS(vers) ((vers) == 1 ? 0x0c : 0x1c)
>
> Why isn't this just an inline function?
Ack. Will make this inline
>
>> +#define DCC_LL_LOCK 0x00
>> +#define DCC_LL_CFG 0x04
>> +#define DCC_LL_BASE 0x08
>> +#define DCC_FD_BASE 0x0c
>> +#define DCC_LL_TIMEOUT 0x10
>> +#define DCC_LL_INT_ENABLE 0x18
>> +#define DCC_LL_INT_STATUS 0x1c
>> +#define DCC_LL_SW_TRIGGER 0x2c
>> +#define DCC_LL_BUS_ACCESS_STATUS 0x30
>> +
>> +/* Default value used if a bit 6 in the HW_INFO register is set. */
>> +#define DCC_FIX_LOOP_OFFSET 16
>> +
>> +/* Mask to find version info from HW_Info register */
>> +#define DCC_VER_INFO_MASK BIT(9)
>> +
>> +#define MAX_DCC_OFFSET GENMASK(9, 2)
>> +#define MAX_DCC_LEN GENMASK(6, 0)
>> +#define MAX_LOOP_CNT GENMASK(7, 0)
>> +#define MAX_LOOP_ADDR 10
>> +
>> +#define DCC_ADDR_DESCRIPTOR 0x00
>> +#define DCC_ADDR_LIMIT 27
>> +#define DCC_WORD_SIZE sizeof(u32)
>> +#define DCC_ADDR_RANGE_MASK GENMASK(31, 4)
>> +#define DCC_LOOP_DESCRIPTOR BIT(30)
>> +#define DCC_RD_MOD_WR_DESCRIPTOR BIT(31)
>> +#define DCC_LINK_DESCRIPTOR GENMASK(31, 30)
>> +#define DCC_STATUS_MASK GENMASK(1, 0)
>> +#define DCC_LOCK_MASK BIT(0)
>> +#define DCC_LOOP_OFFSET_MASK BIT(6)
>> +#define DCC_TRIGGER_MASK BIT(9)
>> +
>> +#define DCC_WRITE_MASK BIT(15)
>> +#define DCC_WRITE_OFF_MASK GENMASK(7, 0)
>> +#define DCC_WRITE_LEN_MASK GENMASK(14, 8)
>> +
>> +#define DCC_READ_IND 0x00
>> +#define DCC_WRITE_IND (BIT(28))
>> +
>> +#define DCC_AHB_IND 0x00
>> +#define DCC_APB_IND BIT(29)
>> +
>> +#define DCC_MAX_LINK_LIST 8
>> +
>> +#define DCC_VER_MASK2 GENMASK(5, 0)
>> +
>> +#define DCC_SRAM_WORD_LENGTH 4
>> +
>> +#define DCC_RD_MOD_WR_ADDR 0xC105E
>> +
>> +enum dcc_descriptor_type {
>> + DCC_READ_TYPE,
>> + DCC_LOOP_TYPE,
>> + DCC_READ_WRITE_TYPE,
>> + DCC_WRITE_TYPE
>> +};
>> +
>> +struct dcc_config_entry {
>> + u32 base;
>> + u32 offset;
>> + u32 len;
>> + u32 loop_cnt;
>> + u32 write_val;
>> + u32 mask;
>> + bool apb_bus;
>> + enum dcc_descriptor_type desc_type;
>> + struct list_head list;
>> +};
>
> No documentation for this structure?
Ack. Will add documentation to this structure as well.
>
>> +
>> +/**
>> + * struct dcc_drvdata - configuration information related to a dcc device
>> + * @base: Base Address of the dcc device
>> + * @dev: The device attached to the driver data
>> + * @mutex: Lock to protect access and manipulation of dcc_drvdata
>> + * @ram_base: Base address for the SRAM dedicated for the dcc device
>> + * @ram_size: Total size of the SRAM dedicated for the dcc device
>> + * @ram_offset: Offset to the SRAM dedicated for dcc device
>> + * @mem_map_ver: Memory map version of DCC hardware
>> + * @ram_cfg: Used for address limit calculation for dcc
>> + * @ram_start: Starting address of DCC SRAM
>> + * @sram_dev: Miscellaneous device equivalent of dcc SRAM
>> + * @cfg_head: Points to the head of the linked list of addresses
>> + * @dbg_dir: The dcc debugfs directory under which all the debugfs files are placed
>> + * @nr_link_list: Total number of linkedlists supported by the DCC configuration
>> + * @loop_shift: Loop offset bits range for the addresses
>> + * @enable_bitmap: Bitmap to capture the enabled status of each linked list of addresses
>> + */
>> +struct dcc_drvdata {
>> + void __iomem *base;
>> + void __iomem *ram_base;
>> + struct device *dev;
>
> Why do you need this back-pointer here?
This is getting used at multiple places to log
dev_err and also for resource allocation using
devm_kzalloc.
>
>> + struct mutex mutex;
>> + size_t ram_size;
>> + size_t ram_offset;
>> + int mem_map_ver;
>> + unsigned int ram_cfg;
>> + unsigned int ram_start;
>> + struct miscdevice sram_dev;
>
> Wait, this is the struct device, right? Or not?
miscdevice here represents the dcc_sram, an io-memory
dedicated to dcc for configuring/storing register values.
Whereas struct device represents the dcc_device which can
be used to write control signals on the bus to handle dcc
hardware operation sequence(like config_reset,sw_trigger etc.)
>
>> + struct list_head *cfg_head;
>> + struct dentry *dbg_dir;
>
> Why is this needed and not just looked up when necessary?
This needs to be passed while creating sub-directories and also
while removing. Rather than looking up everytime,saving and
re-using this in here.
>
>> + size_t nr_link_list;
>> + u8 loop_shift;
>> + unsigned long *enable_bitmap;
>
> So this is a list of bitmaps? Why "unsigned long"? Why not u64?
Ack
>
>> +};
>> +
>> +struct dcc_cfg_attr {
>> + u32 addr;
>> + u32 prev_addr;
>> + u32 prev_off;
>> + u32 link;
>> + u32 sram_offset;
>> +};
>> +
>> +struct dcc_cfg_loop_attr {
>> + u32 loop_cnt;
>> + u32 loop_len;
>> + u32 loop_off;
>> + bool loop_start;
>> +};
>> +
>> +static inline u32 dcc_list_offset(int version)
>> +{
>> + return version == 1 ? 0x1c : version == 2 ? 0x2c : 0x34;
>> +}
>
> Ah, you do have an inline function for the above mentioned macro.
> Please drop the macro.
>
> And write this inline function out to be readable, single-level ?:
> comments are impossible to read, let alone double-level ones.
>
> Write code for people first, compilers second. You gain nothing by
> making this terse except to confuse people.
Ack. This inline function is different from the previous macro.
Will keep both as inline functions.
>
>> +
>> +static inline void dcc_list_writel(struct dcc_drvdata *drvdata,
>> + u32 ll, u32 val, u32 off)
>> +{
>> + u32 offset = dcc_list_offset(drvdata->mem_map_ver) + off;
>> +
>> + writel(val, drvdata->base + ll * 0x80 + offset);
>
> What is this magic 0x80 for?
This is the list offset needed for address calculation as per the
dcc-hardware specification. Will declare a macro for this.
>
>> +}
>> +
>> +static inline u32 dcc_list_readl(struct dcc_drvdata *drvdata, u32 ll, u32 off)
>> +{
>> + u32 offset = dcc_list_offset(drvdata->mem_map_ver) + off;
>> +
>> + return readl(drvdata->base + ll * 0x80 + offset);
>
> Again, where did 0x80 come from?
Same as above.
>
>> +}
>> +
>> +static void dcc_sram_write_auto(struct dcc_drvdata *drvdata,
>> + u32 val, u32 *off)
>> +{
>> + /* If the overflow condition is met increment the offset
>> + * and return to indicate that overflow has occurred
>> + */
>> + if (unlikely(*off > drvdata->ram_size - 4)) {
>> + *off += 4;
>> + return;
>
> You didn't indicate anything here, all you did was succeed at the call,
> the caller has no way of ever knowing this failed.
>
> Why not return an error?
As per previous discussions it was decided to perform the write
speculatively. So that while writing to the dcc_sram if we exceed
the memory size, dcc will skip the write and keep incrementing
the offset. In the method "dcc_emit_config" we have the check to
finally detect if we have exceeded the sram offset
if (cfg.sram_offset + total_len > drvdata->ram_size) {
cfg.sram_offset += total_len;
goto overstep;
}
>
>> + }
>> +
>> + writel(val, drvdata->ram_base + *off);
>> +
>> + *off += 4;
>
> See, same modification as your "error" above.
>
> How was this tested?
This increment is needed to update the offset for the next memory
position in dcc_sram.
>
>> +static int dcc_emit_config(struct dcc_drvdata *drvdata, unsigned int curr_list)
>> +{
>> + int ret;
>> + u32 total_len, pos;
>> + struct dcc_config_entry *entry;
>> + struct dcc_cfg_attr cfg;
>> + struct dcc_cfg_loop_attr cfg_loop;
>> +
>> + memset(&cfg, 0, sizeof(cfg));
>> + memset(&cfg_loop, 0, sizeof(cfg_loop));
>
> Why are these large structures on the stack?
cfg_loop is needed for offset calculation in case of dcc loop
instructions based on the way it needs to be configured in dcc_sram
for dcc hardware to interpret it. entry, cfg is a generic structure used
across all dcc instructions. All these structures are needed for the
memory checks after we are done with configuring all the dcc instructions.
>
> And if on the stack, why not have the compiler initialize them to 0 for
> you automatically?
Ack
>
> I stopped reviewing here...
>
> greg k-h
On Wed, Apr 19, 2023, at 09:00, Souradeep Chowdhury wrote:
> On 4/18/2023 9:15 PM, Greg Kroah-Hartman wrote:
>>
>>> The following is the justification of using debugfs interface over the
>>> other alternatives like sysfs/ioctls
>>>
>>> i) As can be seen from the debugfs attribute descriptions, some of the
>>> debugfs attribute files here contains multiple arguments which needs to
>>> be accepted from the user. This goes against the design style of sysfs.
>>>
>>> ii) The user input patterns have been made simple and convenient in this
>>> case with the use of debugfs interface as user doesn't need to shuffle
>>> between different files to execute one instruction as was the case on
>>> using other alternatives.
>>
>> Why do you have debugfs and also a misc device? How are they related?
>> Why both? Why not just one? What userspace tools are going to use
>> either of these interfaces and where are they published to show how this
>> all was tested?
>
> DCC has two fundamental steps of usage:-
>
> 1.Configuring the register addresses on the dcc_sram which is done by
> user through the debugfs interface. For example:-
>
> echo R 0x10c004 > /sys/kernel/debug/dcc/../3/config
>
> Here we are configuring the register addresses for list 3, the 'R'
> indicates a read operation, so this register value will be read
> in case of a software trigger or kernel panic/watchdog bite and
> dumped into the dcc_sram.
Can you describe why the register location needs to be
runtime configurable? I would have expected this type of setting
to be part of the devicetree, which already describes other
parts that interact with sram devices.
How does a user ensure that the address they configure does
not overlap with some other use of the sram?
Arnd
On 4/19/2023 1:00 PM, Arnd Bergmann wrote:
> On Wed, Apr 19, 2023, at 09:00, Souradeep Chowdhury wrote:
>> On 4/18/2023 9:15 PM, Greg Kroah-Hartman wrote:
>>>
>>>> The following is the justification of using debugfs interface over the
>>>> other alternatives like sysfs/ioctls
>>>>
>>>> i) As can be seen from the debugfs attribute descriptions, some of the
>>>> debugfs attribute files here contains multiple arguments which needs to
>>>> be accepted from the user. This goes against the design style of sysfs.
>>>>
>>>> ii) The user input patterns have been made simple and convenient in this
>>>> case with the use of debugfs interface as user doesn't need to shuffle
>>>> between different files to execute one instruction as was the case on
>>>> using other alternatives.
>>>
>>> Why do you have debugfs and also a misc device? How are they related?
>>> Why both? Why not just one? What userspace tools are going to use
>>> either of these interfaces and where are they published to show how this
>>> all was tested?
>>
>> DCC has two fundamental steps of usage:-
>>
>> 1.Configuring the register addresses on the dcc_sram which is done by
>> user through the debugfs interface. For example:-
>>
>> echo R 0x10c004 > /sys/kernel/debug/dcc/../3/config
>>
>> Here we are configuring the register addresses for list 3, the 'R'
>> indicates a read operation, so this register value will be read
>> in case of a software trigger or kernel panic/watchdog bite and
>> dumped into the dcc_sram.
>
> Can you describe why the register location needs to be
> runtime configurable? I would have expected this type of setting
> to be part of the devicetree, which already describes other
> parts that interact with sram devices.
Register addresses are made runtime configurable to give the user the
option of going for a software trigger. So the user can debug issues
during run-time as well. These register locations are arbitrary
and is configured by the user for debugging purposes and is not related
to the DCC hardware itself.
>
> How does a user ensure that the address they configure does
> not overlap with some other use of the sram?
The dcc_sram is a dedicated io-memory for exclusive usage by dcc.
The register addresses are programmed in the dcc_sram corresponding
to a particular list and the start and end location on dcc_sram for
a particular list is updated in dcc hardware registers. So no two
lists can overlap. This is ensured by the driver code as follows:-
/* 3. Program DCC_RAM_CFG reg */
dcc_list_writel(drvdata, ram_cfg_base +
drvdata->ram_offset / 4, curr_list, DCC_LL_BASE);
dcc_list_writel(drvdata, drvdata->ram_start +
drvdata->ram_offset / 4, curr_list, DCC_FD_BASE);
>
> Arnd
On 4/19/2023 3:20 AM, Souradeep Chowdhury wrote:
>
>
> On 4/19/2023 1:00 PM, Arnd Bergmann wrote:
>> On Wed, Apr 19, 2023, at 09:00, Souradeep Chowdhury wrote:
>>> On 4/18/2023 9:15 PM, Greg Kroah-Hartman wrote:
>>>>
>>>>> The following is the justification of using debugfs interface over the
>>>>> other alternatives like sysfs/ioctls
>>>>>
>>>>> i) As can be seen from the debugfs attribute descriptions, some of the
>>>>> debugfs attribute files here contains multiple arguments which
>>>>> needs to
>>>>> be accepted from the user. This goes against the design style of
>>>>> sysfs.
>>>>>
>>>>> ii) The user input patterns have been made simple and convenient in
>>>>> this
>>>>> case with the use of debugfs interface as user doesn't need to shuffle
>>>>> between different files to execute one instruction as was the case on
>>>>> using other alternatives.
>>>>
>>>> Why do you have debugfs and also a misc device? How are they related?
>>>> Why both? Why not just one? What userspace tools are going to use
>>>> either of these interfaces and where are they published to show how
>>>> this
>>>> all was tested?
>>>
>>> DCC has two fundamental steps of usage:-
>>>
>>> 1.Configuring the register addresses on the dcc_sram which is done by
>>> user through the debugfs interface. For example:-
>>>
>>> echo R 0x10c004 > /sys/kernel/debug/dcc/../3/config
>>>
>>> Here we are configuring the register addresses for list 3, the 'R'
>>> indicates a read operation, so this register value will be read
>>> in case of a software trigger or kernel panic/watchdog bite and
>>> dumped into the dcc_sram.
>>
>> Can you describe why the register location needs to be
>> runtime configurable? I would have expected this type of setting
>> to be part of the devicetree, which already describes other
>> parts that interact with sram devices.
>
> Register addresses are made runtime configurable to give the user the
> option of going for a software trigger. So the user can debug issues
> during run-time as well. These register locations are arbitrary
> and is configured by the user for debugging purposes and is not related
> to the DCC hardware itself.
Please note that we don't want to recompile the devicetree for new
settings since these registers can be set by team of engineers who are
debugging system level issues with various IPs across the SOCs. You
don't want to recompile the images while reproducing the system hangs/IP
watchdogs etc;
---Trilok Soni
On 4/19/2023 9:08 AM, Trilok Soni wrote:
> On 4/19/2023 3:20 AM, Souradeep Chowdhury wrote:
>>
>>
>> On 4/19/2023 1:00 PM, Arnd Bergmann wrote:
>>> On Wed, Apr 19, 2023, at 09:00, Souradeep Chowdhury wrote:
>>>> On 4/18/2023 9:15 PM, Greg Kroah-Hartman wrote:
>>>>>
>>>>>> The following is the justification of using debugfs interface over
>>>>>> the
>>>>>> other alternatives like sysfs/ioctls
>>>>>>
>>>>>> i) As can be seen from the debugfs attribute descriptions, some of
>>>>>> the
>>>>>> debugfs attribute files here contains multiple arguments which
>>>>>> needs to
>>>>>> be accepted from the user. This goes against the design style of
>>>>>> sysfs.
>>>>>>
>>>>>> ii) The user input patterns have been made simple and convenient
>>>>>> in this
>>>>>> case with the use of debugfs interface as user doesn't need to
>>>>>> shuffle
>>>>>> between different files to execute one instruction as was the case on
>>>>>> using other alternatives.
>>>>>
>>>>> Why do you have debugfs and also a misc device? How are they related?
>>>>> Why both? Why not just one? What userspace tools are going to use
>>>>> either of these interfaces and where are they published to show how
>>>>> this
>>>>> all was tested?
>>>>
>>>> DCC has two fundamental steps of usage:-
>>>>
>>>> 1.Configuring the register addresses on the dcc_sram which is done by
>>>> user through the debugfs interface. For example:-
>>>>
>>>> echo R 0x10c004 > /sys/kernel/debug/dcc/../3/config
>>>>
>>>> Here we are configuring the register addresses for list 3, the 'R'
>>>> indicates a read operation, so this register value will be read
>>>> in case of a software trigger or kernel panic/watchdog bite and
>>>> dumped into the dcc_sram.
>>>
>>> Can you describe why the register location needs to be
>>> runtime configurable? I would have expected this type of setting
>>> to be part of the devicetree, which already describes other
>>> parts that interact with sram devices.
>>
>> Register addresses are made runtime configurable to give the user the
>> option of going for a software trigger. So the user can debug issues
>> during run-time as well. These register locations are arbitrary
>> and is configured by the user for debugging purposes and is not
>> related to the DCC hardware itself.
>
> Please note that we don't want to recompile the devicetree for new
> settings since these registers can be set by team of engineers who are
> debugging system level issues with various IPs across the SOCs. You
> don't want to recompile the images while reproducing the system hangs/IP
> watchdogs etc;
...and also these registers list is not fixed, it will vary based on the
problem you are seeing and debugging on the SOC across the IPs.
---Trilok Soni
On Wed, Apr 19, 2023 at 09:10:14AM -0700, Trilok Soni wrote:
> On 4/19/2023 9:08 AM, Trilok Soni wrote:
> > On 4/19/2023 3:20 AM, Souradeep Chowdhury wrote:
> > >
> > >
> > > On 4/19/2023 1:00 PM, Arnd Bergmann wrote:
> > > > On Wed, Apr 19, 2023, at 09:00, Souradeep Chowdhury wrote:
> > > > > On 4/18/2023 9:15 PM, Greg Kroah-Hartman wrote:
> > > > > >
> > > > > > > The following is the justification of using debugfs
> > > > > > > interface over the
> > > > > > > other alternatives like sysfs/ioctls
> > > > > > >
> > > > > > > i) As can be seen from the debugfs attribute
> > > > > > > descriptions, some of the
> > > > > > > debugfs attribute files here contains multiple
> > > > > > > arguments which needs to
> > > > > > > be accepted from the user. This goes against the
> > > > > > > design style of sysfs.
> > > > > > >
> > > > > > > ii) The user input patterns have been made simple
> > > > > > > and convenient in this
> > > > > > > case with the use of debugfs interface as user
> > > > > > > doesn't need to shuffle
> > > > > > > between different files to execute one instruction as was the case on
> > > > > > > using other alternatives.
> > > > > >
> > > > > > Why do you have debugfs and also a misc device?? How are they related?
> > > > > > Why both?? Why not just one?? What userspace tools are going to use
> > > > > > either of these interfaces and where are they published
> > > > > > to show how this
> > > > > > all was tested?
> > > > >
> > > > > DCC has two fundamental steps of usage:-
> > > > >
> > > > > 1.Configuring the register addresses on the dcc_sram which is done by
> > > > > user through the debugfs interface. For example:-
> > > > >
> > > > > echo R 0x10c004 > /sys/kernel/debug/dcc/../3/config
> > > > >
> > > > > Here we are configuring the register addresses for list 3, the 'R'
> > > > > indicates a read operation, so this register value will be read
> > > > > in case of a software trigger or kernel panic/watchdog bite and
> > > > > dumped into the dcc_sram.
> > > >
> > > > Can you describe why the register location needs to be
> > > > runtime configurable? I would have expected this type of setting
> > > > to be part of the devicetree, which already describes other
> > > > parts that interact with sram devices.
> > >
> > > Register addresses are made runtime configurable to give the user the
> > > option of going for a software trigger. So the user can debug issues
> > > during run-time as well. These register locations are arbitrary
> > > and is configured by the user for debugging purposes and is not
> > > related to the DCC hardware itself.
> >
> > Please note that we don't want to recompile the devicetree for new
> > settings since these registers can be set by team of engineers who are
> > debugging system level issues with various IPs across the SOCs. You
> > don't want to recompile the images while reproducing the system hangs/IP
> > watchdogs etc;
>
> ...and also these registers list is not fixed, it will vary based on the
> problem you are seeing and debugging on the SOC across the IPs.
Then all of this should be documented in the driver, and in the
changelog please.
thanks,
greg k-h