Add driver support for Data Capture and Compare Engine(DCC) for SM8150

Documentation for Data Capture and Compare(DCC) device tree bindings in yaml format.

Signed-off-by Souradeep Chowdhury <[email protected]>

---
 .../devicetree/bindings/arm/msm/qcom,dcc.yaml      | 49 ++++++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml

Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml new file +23 -0

new file mode 100644
index 0000000..b8e9998
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/msm/qcom,dcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Data Capture and Compare
+
+maintainers:
+  - Souradeep Chowdhury <[email protected]>
+
+description: |
+    DCC (Data Capture and Compare) is a DMA engine which is used to save
+    configuration data or system memory contents during catastrophic failure
+    or SW trigger. DCC is used to capture and store data for debugging purpose
+
+
+properties:
+  compatible:
+    items:
+      - enum:
+          - qcom,sm8150-dcc
+      - const: qcom,dcc

Documentation/devicetree/bindings/arm/msm/qcom,dcc.yaml new file +16 -0

+
+required:
+  - compatible
+  - reg
+  - reg-names
+
+additionalProperties: false
+
+examples:
+  - |
+    dcc@10a2000{
+                compatible = "qcom,sm8150-dcc","qcom,dcc";
+                reg = <0x010a2000  0x1000>,
+                      <0x010ad000  0x2000>;
+                reg-names = "dcc-base", "dcc-ram-base";
+    };

Signature · 2 lines

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

The DCC is a DMA Engine designed to capture and store data during system crash or software triggers. The DCC operates based on link list entries which provides it with data and addresses and the function it needs to perform. These functions are read, write and loop. Added the basic driver in this patch which contains a probe method which instantiates the resources needed by the driver. DCC has it's own SRAM which needs to be instantiated at probe time as well.

Signed-off-by Souradeep Chowdhury <[email protected]>

---
 drivers/soc/qcom/Kconfig  |   8 +
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/dcc.c    | 388 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 397 insertions(+)
 create mode 100644 drivers/soc/qcom/dcc.c

drivers/soc/qcom/Kconfig +8 -0

index 79b568f..8819e0b 100644
@@ -69,6 +69,14 @@ config QCOM_LLCC
 	  SDM845. This provides interfaces to clients that use the LLCC.
 	  Say yes here to enable LLCC slice driver.
 
+config QCOM_DCC
+	tristate "Qualcomm Technologies, Inc. Data Capture and Compare 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_KRYO_L2_ACCESSORS
 	bool
 	depends on ARCH_QCOM && ARM64 || COMPILE_TEST

drivers/soc/qcom/Makefile +1 -0

index ad675a6..1b00870 100644
@@ -26,3 +26,4 @@ obj-$(CONFIG_QCOM_LLCC) += llcc-qcom.o
 obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
 obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
 obj-$(CONFIG_QCOM_KRYO_L2_ACCESSORS) +=	kryo-l2-accessors.o
+obj-$(CONFIG_QCOM_DCC) += dcc.o

drivers/soc/qcom/dcc.c new file +11 -0

new file mode 100644
index 0000000..89816bf
@@ -0,0 +1,388 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2015-2021, The Linux Foundation. All rights reserved.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/cdev.h>
+#include <linux/delay.h>
+#include <linux/fs.h>
+#include <linux/io.h>

drivers/soc/qcom/dcc.c new file +21 -0

+
+/* DCC registers */
+#define DCC_HW_INFO			0x04
+#define DCC_LL_NUM_INFO			0x10
+
+#define DCC_MAP_LEVEL1			0x18
+#define DCC_MAP_LEVEL2			0x34
+#define DCC_MAP_LEVEL3			0x4C
+
+#define DCC_MAP_OFFSET1			0x10
+#define DCC_MAP_OFFSET2			0x18
+#define DCC_MAP_OFFSET3			0x1C
+#define DCC_MAP_OFFSET4			0x8
+
+#define DCC_FIX_LOOP_OFFSET		16
+#define DCC_VER_INFO_BIT		9
+
+#define DCC_MAX_LINK_LIST		8
+#define DCC_INVALID_LINK_LIST		GENMASK(7, 0)
+
+#define DCC_VER_MASK1			GENMASK(6, 0)

drivers/soc/qcom/dcc.c new file +39 -0

+	DCC_MEM_MAP_VER2,
+	DCC_MEM_MAP_VER3
+};
+
+enum dcc_descriptor_type {
+	DCC_ADDR_TYPE,
+	DCC_LOOP_TYPE,
+	DCC_READ_WRITE_TYPE,
+	DCC_WRITE_TYPE
+};
+
+struct dcc_config_entry {
+	u32				base;
+	u32				offset;
+	u32				len;
+	u32				index;
+	u32				loop_cnt;
+	u32				write_val;
+	u32				mask;
+	bool				apb_bus;
+	enum dcc_descriptor_type	desc_type;
+	struct list_head		list;
+};
+
+struct dcc_drvdata {
+	void __iomem		*base;
+	u32			reg_size;
+	struct device		*dev;
+	struct mutex		mutex;
+	void __iomem		*ram_base;
+	u32			ram_size;
+	u32			ram_offset;
+	enum dcc_mem_map_ver	mem_map_ver;
+	u32			ram_cfg;
+	u32			ram_start;
+	bool			*enable;
+	bool			*configured;
+	bool			interrupt_disable;
+	char			*sram_node;

drivers/soc/qcom/dcc.c new file +14 -0

+{
+	if (drvdata->mem_map_ver == DCC_MEM_MAP_VER1) {
+		if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL3)
+			return (off - DCC_MAP_OFFSET3);
+		if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL2)
+			return (off - DCC_MAP_OFFSET2);
+		else if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL1)
+			return (off - DCC_MAP_OFFSET1);
+	} else if (drvdata->mem_map_ver == DCC_MEM_MAP_VER2) {
+		if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL2)
+			return (off - DCC_MAP_OFFSET4);
+	}
+	return off;
+}

drivers/soc/qcom/dcc.c new file +20 -0

+		list_for_each_entry_safe(entry, temp,
+			&drvdata->cfg_head[curr_list], list) {
+			list_del(&entry->list);
+			devm_kfree(drvdata->dev, entry);
+			drvdata->nr_config[curr_list]--;
+		}
+	}
+	drvdata->ram_start = 0;
+	drvdata->ram_cfg = 0;
+	mutex_unlock(&drvdata->mutex);
+}
+
+static int dcc_sram_open(struct inode *inode, struct file *file)
+{
+	struct dcc_drvdata *drvdata = container_of(inode->i_cdev,
+		struct dcc_drvdata,
+		sram_dev);
+	file->private_data = drvdata;
+
+	return	0;

drivers/soc/qcom/dcc.c new file +22 -0

+
+	if (copy_to_user(data, buf, len)) {
+		dev_err(drvdata->dev, "DCC: Couldn't copy all data to user\n");
+		kfree(buf);
+		return -EFAULT;
+	}
+
+	*ppos += len;
+
+	kfree(buf);
+
+	return len;
+}
+
+static const struct file_operations dcc_sram_fops = {
+	.owner		= THIS_MODULE,
+	.open		= dcc_sram_open,
+	.read		= dcc_sram_read,
+	.llseek		= no_llseek,
+};
+
+static int dcc_sram_dev_register(struct dcc_drvdata *drvdata)

drivers/soc/qcom/dcc.c new file +39 -0

+
+	drvdata->sram_dev.owner = THIS_MODULE;
+	ret = cdev_add(&drvdata->sram_dev, dev, 1);
+	if (ret)
+		goto err_cdev_add;
+
+	drvdata->sram_class = class_create(THIS_MODULE, drvdata->sram_node);
+	if (IS_ERR(drvdata->sram_class)) {
+		ret = PTR_ERR(drvdata->sram_class);
+		goto err_class_create;
+	}
+
+	device = device_create(drvdata->sram_class, NULL,
+						drvdata->sram_dev.dev, drvdata,
+						drvdata->sram_node);
+	if (IS_ERR(device)) {
+		ret = PTR_ERR(device);
+		goto err_dev_create;
+	}
+
+	return 0;
+err_dev_create:
+	class_destroy(drvdata->sram_class);
+err_class_create:
+	cdev_del(&drvdata->sram_dev);
+err_cdev_add:
+	unregister_chrdev_region(drvdata->sram_dev.dev, 1);
+err_alloc:
+	return ret;
+}
+
+static void dcc_sram_dev_deregister(struct dcc_drvdata *drvdata)
+{
+	device_destroy(drvdata->sram_class, drvdata->sram_dev.dev);
+	class_destroy(drvdata->sram_class);
+	cdev_del(&drvdata->sram_dev);
+	unregister_chrdev_region(drvdata->sram_dev.dev, 1);
+}
+

drivers/soc/qcom/dcc.c new file +11 -0

+	if (!drvdata->sram_node)
+		return -ENOMEM;
+
+	strlcpy(drvdata->sram_node, node_name, node_size);
+	ret = dcc_sram_dev_register(drvdata);
+	if (ret)
+		dev_err(drvdata->dev, "DCC: sram node not registered.\n");
+
+	return ret;
+}
+

drivers/soc/qcom/dcc.c new file +5 -0

+	if (!res)
+		return -EINVAL;
+
+	drvdata->ram_size = resource_size(res);
+	drvdata->ram_base = devm_ioremap(dev, res->start, resource_size(res));

drivers/soc/qcom/dcc.c new file +9 -0

+	} else if ((dcc_readl(drvdata, DCC_HW_INFO) & DCC_VER_MASK2) == DCC_VER_MASK2) {
+		drvdata->mem_map_ver = DCC_MEM_MAP_VER2;
+		drvdata->nr_link_list = dcc_readl(drvdata, DCC_LL_NUM_INFO);
+		if (drvdata->nr_link_list == 0)
+			return	-EINVAL;
+	} else {
+		drvdata->mem_map_ver = DCC_MEM_MAP_VER1;
+		drvdata->nr_link_list = DCC_MAX_LINK_LIST;
+	}

drivers/soc/qcom/dcc.c new file +6 -0

+	drvdata->configured = devm_kzalloc(dev, drvdata->nr_link_list *
+			sizeof(bool), GFP_KERNEL);
+	if (!drvdata->configured)
+		return -ENOMEM;
+	drvdata->nr_config = devm_kzalloc(dev, drvdata->nr_link_list *
+			sizeof(u32), GFP_KERNEL);

drivers/soc/qcom/dcc.c new file +12 -0

+err:
+	return ret;
+}
+
+static int dcc_remove(struct platform_device *pdev)
+{
+	struct dcc_drvdata *drvdata = platform_get_drvdata(pdev);
+
+	dcc_sram_dev_exit(drvdata);
+
+	dcc_config_reset(drvdata);
+

drivers/soc/qcom/dcc.c new file +9 -0

+		.of_match_table	= dcc_match_table,
+	},
+};
+
+module_platform_driver(dcc_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Qualcomm Technologies Inc. DCC driver");
+

Signature · 2 lines

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Quoted 9 lines · Souradeep Chowdhury

The DCC is a DMA Engine designed to capture and store data during system crash or software triggers. The DCC operates based on link list entries which provides it with data and addresses and the function it needs to perform. These functions are read, write and loop. Added the basic driver in this patch which contains a probe method which instantiates the resources needed by the driver. DCC has it's own SRAM which needs to be instantiated at probe time as well.

So to summarize, the DCC will upon a crash copy the configured region into the dcc-ram, where it can be retrieved either by dumping the memory over USB or from sysfs on the next boot?

Quoted 9 lines

Signed-off-by Souradeep Chowdhury <[email protected]>

---
 drivers/soc/qcom/Kconfig  |   8 +
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/dcc.c    | 388 
++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 397 insertions(+)
 create mode 100644 drivers/soc/qcom/dcc.c

How about implementing this using pstore instead of exposing it through a custom /dev/dcc_sram (if I read the code correclty)

Hi Bjorn,

Quoted 12 lines · Bjorn Andersson

Quoted 9 lines · Souradeep Chowdhury

The DCC is a DMA Engine designed to capture and store data during system crash or software triggers. The DCC operates based on link list entries which provides it with data and addresses and the function it needs to perform. These functions are read, write and loop. Added the basic driver in this patch which contains a probe method which instantiates the resources needed by the driver. DCC has it's own SRAM which needs to be instantiated at probe time as well.

Quoted 4 lines

So to summarize, the DCC will upon a crash copy the configured region into the dcc-ram, where it can be retrieved either by dumping the memory over USB or from sysfs on the next boot?

Not just the next boot, but also for the current boot via /dev/dcc_sram, more below.

Quoted 9 lines

Quoted 9 lines

Signed-off-by Souradeep Chowdhury <[email protected]>

---
 drivers/soc/qcom/Kconfig  |   8 +
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/dcc.c    | 388
++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 397 insertions(+)
 create mode 100644 drivers/soc/qcom/dcc.c

<snip>...

Quoted 4 lines

How about implementing this using pstore instead of exposing it through a custom /dev/dcc_sram (if I read the code correclty)

Using pstore is definitely a good suggestion, we have been thinking of adding it as a separate change once the basic support for DCC gets in. But pstore ram backend again depends on warm reboot which is present only in chrome compute platforms but android platforms do not officially support warm reboot. Pstore with block devices as a backend would be ideal but it is still a work in progress to use mmc as the backend [1].

Now the other reason as to why we need this dev interface in addition to pstore,

* Pstore contents are retrieved on the next boot, but DCC SRAM contents can be collected via dev interface for the current boot via SW trigger. Lets say we have some non-fatal errors in one of the subsystems and we want to analyze the register values, it becomes as simple as configuring that region, trigger dcc and collect the sram contents and parse it.

   echo "addr" > /sys/bus/platform/devices/***.dcc/config
   echo  1 > /sys/bus/platform/devices/***.dcc/trigger
   cat /dev/dcc_sram > dcc_sram.bin
   python dcc_parser.py -s dcc_sram.bin --v2 -o output/

We don't have to reboot at all for SW triggers. This is very useful and widely used internally.

Is the custom /dev/dcc_sram not recommended because of the dependency on the userspace component being not available openly? If so, we already have the dcc parser upstream which we use to extract the sram contents [2].

[1]
https://lore.kernel.org/lkml/[email protected]/
[2] https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/tools/tree/dcc_parser

Thanks,
Sai

Signature · 2 lines

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Quoted 15 lines · Sai Prakash Ranjan

Hi Bjorn,

Quoted 12 lines · Bjorn Andersson

Quoted 9 lines · Souradeep Chowdhury

The DCC is a DMA Engine designed to capture and store data during system crash or software triggers. The DCC operates based on link list entries which provides it with data and addresses and the function it needs to perform. These functions are read, write and loop. Added the basic driver in this patch which contains a probe method which instantiates the resources needed by the driver. DCC has it's own SRAM which needs to be instantiated at probe time as well.

Quoted 8 lines

Quoted 4 lines

So to summarize, the DCC will upon a crash copy the configured region into the dcc-ram, where it can be retrieved either by dumping the memory over USB or from sysfs on the next boot?

Not just the next boot, but also for the current boot via /dev/dcc_sram, more below.

Interesting!

Quoted 17 lines

Quoted 9 lines

Quoted 9 lines

Signed-off-by Souradeep Chowdhury <[email protected]>

---
 drivers/soc/qcom/Kconfig  |   8 +
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/dcc.c    | 388
++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 397 insertions(+)
 create mode 100644 drivers/soc/qcom/dcc.c

<snip>...

Quoted 4 lines

How about implementing this using pstore instead of exposing it through a custom /dev/dcc_sram (if I read the code correclty)

Quoted 7 lines

Using pstore is definitely a good suggestion, we have been thinking of adding it as a separate change once the basic support for DCC gets in. But pstore ram backend again depends on warm reboot which is present only in chrome compute platforms but android platforms do not officially support warm reboot. Pstore with block devices as a backend would be ideal but it is still a work in progress to use mmc as the backend [1].

I was under the impression that we can have multiple pstore implementations active, so we would have ramoops and dcc presented side by side after such restart. Perhaps that's a misunderstanding on my part?

Quoted 17 lines

Now the other reason as to why we need this dev interface in addition to pstore,

* Pstore contents are retrieved on the next boot, but DCC SRAM contents can be collected via dev interface for the current boot via SW trigger. Lets say we have some non-fatal errors in one of the subsystems and we want to analyze the register values, it becomes as simple as configuring that region, trigger dcc and collect the sram contents and parse it.

   echo "addr" > /sys/bus/platform/devices/***.dcc/config
   echo  1 > /sys/bus/platform/devices/***.dcc/trigger
   cat /dev/dcc_sram > dcc_sram.bin
   python dcc_parser.py -s dcc_sram.bin --v2 -o output/

We don't have to reboot at all for SW triggers. This is very useful and widely used internally.

Quoted 4 lines

Is the custom /dev/dcc_sram not recommended because of the dependency on the userspace component being not available openly? If so, we already have the dcc parser upstream which we use to extract the sram contents [2].

My concern is that we come up with a custom chardev implementation for something that already exists or should exist in a more generic form.

In the runtime sequence above, why don't you have trigger just generate a devcoredump? But perhaps the answer is that we want a unified interface between the restart and runtime use cases?

It would be nice to have some more details of how I can use this and how to operate the sysfs interface to achieve that, would you be able to elaborate on this?

Quoted 9 lines · Souradeep Chowdhury

The DCC is a DMA Engine designed to capture and store data during system crash or software triggers. The DCC operates based on link list entries which provides it with data and addresses and the function it needs to perform. These functions are read, write and loop. Added the basic driver in this patch which contains a probe method which instantiates the resources needed by the driver. DCC has it's own SRAM which needs to be instantiated at probe time as well.

So to summarize, the DCC will upon a crash copy the configured region into the dcc-ram, where it can be retrieved either by dumping the memory over USB or from sysfs on the next boot?

Quoted 63 lines

Signed-off-by Souradeep Chowdhury <[email protected]>

---
 drivers/soc/qcom/Kconfig  |   8 +
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/dcc.c    | 388 
++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 397 insertions(+)
 create mode 100644 drivers/soc/qcom/dcc.c

drivers/soc/qcom/Kconfig +2 -0

index 79b568f..8819e0b 100644
@@ -69,6 +69,14 @@ config QCOM_LLCC
 	  SDM845. This provides interfaces to clients that use the LLCC.
 	  Say yes here to enable LLCC slice driver.
 
+config QCOM_DCC
+	tristate "Qualcomm Technologies, Inc. Data Capture and Compare 

engine driver"

drivers/soc/qcom/Kconfig +3 -0

+	depends on ARCH_QCOM || COMPILE_TEST
+	help
+	  This option enables driver for Data Capture and Compare engine. 

DCC

drivers/soc/qcom/Kconfig +3 -0

+	  driver provides interface to configure DCC block and read back
+	  captured data from DCC's internal SRAM.
+
 config QCOM_KRYO_L2_ACCESSORS
 	bool
 	depends on ARCH_QCOM && ARM64 || COMPILE_TEST

drivers/soc/qcom/Makefile +1 -0

index ad675a6..1b00870 100644
@@ -26,3 +26,4 @@ obj-$(CONFIG_QCOM_LLCC) += llcc-qcom.o
 obj-$(CONFIG_QCOM_RPMHPD) += rpmhpd.o
 obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
 obj-$(CONFIG_QCOM_KRYO_L2_ACCESSORS) +=	kryo-l2-accessors.o
+obj-$(CONFIG_QCOM_DCC) += dcc.o

drivers/soc/qcom/dcc.c new file +3 -0

new file mode 100644
index 0000000..89816bf
@@ -0,0 +1,388 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2015-2021, The Linux Foundation. All rights 

reserved.
+ */

drivers/soc/qcom/dcc.c new file +12 -0

+
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/cdev.h>
+#include <linux/delay.h>
+#include <linux/fs.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>

drivers/soc/qcom/dcc.c line 21

Quoted 5 lines

drivers/soc/qcom/dcc.c new file +5 -0

+#include <linux/slab.h>
+#include <linux/uaccess.h>
+
+#define dcc_readl(drvdata, off)						\
+	readl(drvdata->base + dcc_offset_conv(drvdata, off))

This is only used in probe, please just inline it, and use (a) local variable(s) to avoid the lengthy lines.

Quoted 28 lines

drivers/soc/qcom/dcc.c new file +27 -0

+
+/* DCC registers */
+#define DCC_HW_INFO			0x04
+#define DCC_LL_NUM_INFO			0x10
+
+#define DCC_MAP_LEVEL1			0x18
+#define DCC_MAP_LEVEL2			0x34
+#define DCC_MAP_LEVEL3			0x4C
+
+#define DCC_MAP_OFFSET1			0x10
+#define DCC_MAP_OFFSET2			0x18
+#define DCC_MAP_OFFSET3			0x1C
+#define DCC_MAP_OFFSET4			0x8
+
+#define DCC_FIX_LOOP_OFFSET		16
+#define DCC_VER_INFO_BIT		9
+
+#define DCC_MAX_LINK_LIST		8
+#define DCC_INVALID_LINK_LIST		GENMASK(7, 0)
+
+#define DCC_VER_MASK1			GENMASK(6, 0)
+#define DCC_VER_MASK2			GENMASK(5, 0)
+
+#define DCC_RD_MOD_WR_ADDR		0xC105E
+
+struct qcom_dcc_config {
+	const int dcc_ram_offset;

drivers/soc/qcom/dcc.c line 52

Quoted 4 lines

drivers/soc/qcom/dcc.c new file +4 -0

+};
+
+enum dcc_mem_map_ver {
+	DCC_MEM_MAP_VER1,

As these are just integers, I would suggest skipping them. If you really like them I would like to see VER1 = 1, to make any future debugging easier.

Quoted 45 lines

drivers/soc/qcom/dcc.c new file +44 -0

+	DCC_MEM_MAP_VER2,
+	DCC_MEM_MAP_VER3
+};
+
+enum dcc_descriptor_type {
+	DCC_ADDR_TYPE,
+	DCC_LOOP_TYPE,
+	DCC_READ_WRITE_TYPE,
+	DCC_WRITE_TYPE
+};
+
+struct dcc_config_entry {
+	u32				base;
+	u32				offset;
+	u32				len;
+	u32				index;
+	u32				loop_cnt;
+	u32				write_val;
+	u32				mask;
+	bool				apb_bus;
+	enum dcc_descriptor_type	desc_type;
+	struct list_head		list;
+};
+
+struct dcc_drvdata {
+	void __iomem		*base;
+	u32			reg_size;
+	struct device		*dev;
+	struct mutex		mutex;
+	void __iomem		*ram_base;
+	u32			ram_size;
+	u32			ram_offset;
+	enum dcc_mem_map_ver	mem_map_ver;
+	u32			ram_cfg;
+	u32			ram_start;
+	bool			*enable;
+	bool			*configured;
+	bool			interrupt_disable;
+	char			*sram_node;
+	struct cdev		sram_dev;
+	struct class		*sram_class;
+	struct list_head	*cfg_head;
+	u32			*nr_config;
+	u32			nr_link_list;

drivers/soc/qcom/dcc.c line 101

Quoted 5 lines

drivers/soc/qcom/dcc.c new file +5 -0

+	u8			curr_list;
+	u8			loopoff;
+};
+
+static u32 dcc_offset_conv(struct dcc_drvdata *drvdata, u32 off)

I don't see a reason for specifying that the parameter and return value are 32-bit unsigned ints, please use a generic data type...Like size_t

Quoted 19 lines

drivers/soc/qcom/dcc.c new file +19 -0

+{
+	if (drvdata->mem_map_ver == DCC_MEM_MAP_VER1) {
+		if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL3)
+			return (off - DCC_MAP_OFFSET3);
+		if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL2)
+			return (off - DCC_MAP_OFFSET2);
+		else if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL1)
+			return (off - DCC_MAP_OFFSET1);
+	} else if (drvdata->mem_map_ver == DCC_MEM_MAP_VER2) {
+		if ((off & DCC_VER_MASK1) >= DCC_MAP_LEVEL2)
+			return (off - DCC_MAP_OFFSET4);
+	}
+	return off;
+}
+
+static void dcc_config_reset(struct dcc_drvdata *drvdata)
+{
+	struct dcc_config_entry *entry, *temp;
+	int curr_list;

Quoted 6 lines

drivers/soc/qcom/dcc.c new file +4 -0

+
+	mutex_lock(&drvdata->mutex);
+
+	for (curr_list = 0; curr_list < drvdata->nr_link_list; curr_list++) 

{
+

Unnecessary newline.

Quoted 21 lines

drivers/soc/qcom/dcc.c new file +20 -0

+		list_for_each_entry_safe(entry, temp,
+			&drvdata->cfg_head[curr_list], list) {
+			list_del(&entry->list);
+			devm_kfree(drvdata->dev, entry);
+			drvdata->nr_config[curr_list]--;
+		}
+	}
+	drvdata->ram_start = 0;
+	drvdata->ram_cfg = 0;
+	mutex_unlock(&drvdata->mutex);
+}
+
+static int dcc_sram_open(struct inode *inode, struct file *file)
+{
+	struct dcc_drvdata *drvdata = container_of(inode->i_cdev,
+		struct dcc_drvdata,
+		sram_dev);
+	file->private_data = drvdata;
+
+	return	0;

drivers/soc/qcom/dcc.c line 155

Quoted 10 lines

drivers/soc/qcom/dcc.c new file +10 -0

+}
+
+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 = file->private_data;
+
+	/* EOF check */
+	if (drvdata->ram_size <= *ppos)

"Is ppos beyond the EOF" is better expressed as:

	if (*ppos >= drvdata->ram_size)

Quoted 4 lines

drivers/soc/qcom/dcc.c new file +4 -0

+		return 0;
+
+	if ((*ppos + len) > drvdata->ram_size)
+		len = (drvdata->ram_size - *ppos);

drivers/soc/qcom/dcc.c line 165

Quoted 6 lines

drivers/soc/qcom/dcc.c new file +6 -0

+
+	buf = kzalloc(len, GFP_KERNEL);
+	if (!buf)
+		return -ENOMEM;
+
+	memcpy_fromio(buf, (drvdata->ram_base + *ppos), len);

Parenthesis are unnecessary.

Quoted 28 lines

drivers/soc/qcom/dcc.c new file +27 -0

+
+	if (copy_to_user(data, buf, len)) {
+		dev_err(drvdata->dev, "DCC: Couldn't copy all data to user\n");
+		kfree(buf);
+		return -EFAULT;
+	}
+
+	*ppos += len;
+
+	kfree(buf);
+
+	return len;
+}
+
+static const struct file_operations dcc_sram_fops = {
+	.owner		= THIS_MODULE,
+	.open		= dcc_sram_open,
+	.read		= dcc_sram_read,
+	.llseek		= no_llseek,
+};
+
+static int dcc_sram_dev_register(struct dcc_drvdata *drvdata)
+{
+	int ret;
+	struct device *device;
+	dev_t dev;
+

drivers/soc/qcom/dcc.c line 197

Quoted 5 lines

drivers/soc/qcom/dcc.c new file +5 -0

+	ret = alloc_chrdev_region(&dev, 0, 1, drvdata->sram_node);
+	if (ret)
+		goto err_alloc;
+
+	cdev_init(&drvdata->sram_dev, &dcc_sram_fops);

How about implementing this using pstore instead of exposing it through a custom /dev/dcc_sram (if I read the code correclty)

Quoted 46 lines

drivers/soc/qcom/dcc.c new file +45 -0

+
+	drvdata->sram_dev.owner = THIS_MODULE;
+	ret = cdev_add(&drvdata->sram_dev, dev, 1);
+	if (ret)
+		goto err_cdev_add;
+
+	drvdata->sram_class = class_create(THIS_MODULE, drvdata->sram_node);
+	if (IS_ERR(drvdata->sram_class)) {
+		ret = PTR_ERR(drvdata->sram_class);
+		goto err_class_create;
+	}
+
+	device = device_create(drvdata->sram_class, NULL,
+						drvdata->sram_dev.dev, drvdata,
+						drvdata->sram_node);
+	if (IS_ERR(device)) {
+		ret = PTR_ERR(device);
+		goto err_dev_create;
+	}
+
+	return 0;
+err_dev_create:
+	class_destroy(drvdata->sram_class);
+err_class_create:
+	cdev_del(&drvdata->sram_dev);
+err_cdev_add:
+	unregister_chrdev_region(drvdata->sram_dev.dev, 1);
+err_alloc:
+	return ret;
+}
+
+static void dcc_sram_dev_deregister(struct dcc_drvdata *drvdata)
+{
+	device_destroy(drvdata->sram_class, drvdata->sram_dev.dev);
+	class_destroy(drvdata->sram_class);
+	cdev_del(&drvdata->sram_dev);
+	unregister_chrdev_region(drvdata->sram_dev.dev, 1);
+}
+
+static int dcc_sram_dev_init(struct dcc_drvdata *drvdata)
+{
+	int ret = 0;
+	size_t node_size;
+	char *node_name = "dcc_sram";
+	struct device *dev = drvdata->dev;

drivers/soc/qcom/dcc.c line 246

Quoted 4 lines

drivers/soc/qcom/dcc.c new file +4 -0

+
+	node_size = strlen(node_name) + 1;
+
+	drvdata->sram_node = devm_kzalloc(dev, node_size, GFP_KERNEL);

kzalloc + strlcpy can be replaced by kstrdup(), but that said...all this does seems to be to copy a const string to the heap and lugging it around. Use a define instead.

Quoted 16 lines

drivers/soc/qcom/dcc.c new file +15 -0

+	if (!drvdata->sram_node)
+		return -ENOMEM;
+
+	strlcpy(drvdata->sram_node, node_name, node_size);
+	ret = dcc_sram_dev_register(drvdata);
+	if (ret)
+		dev_err(drvdata->dev, "DCC: sram node not registered.\n");
+
+	return ret;
+}
+
+static void dcc_sram_dev_exit(struct dcc_drvdata *drvdata)
+{
+	dcc_sram_dev_deregister(drvdata);
+}

drivers/soc/qcom/dcc.c line 267

Quoted 6 lines

drivers/soc/qcom/dcc.c new file +6 -0

+
+static int dcc_probe(struct platform_device *pdev)
+{
+	int ret = 0, i;
+	struct device *dev = &pdev->dev;
+	struct dcc_drvdata *drvdata;

I think "dcc" would be a better name than "drvdata"...

Quoted 7 lines

drivers/soc/qcom/dcc.c new file +7 -0

+	struct resource *res;
+	const struct qcom_dcc_config *cfg;
+
+	drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
+	if (!drvdata)
+		return -ENOMEM;
+

Quoted 5 lines

drivers/soc/qcom/dcc.c new file +4 -0

+	drvdata->dev = &pdev->dev;
+	platform_set_drvdata(pdev, drvdata);
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, 

"dcc-base");

platform_get_resource_byname() + devm_ioremap() is done in one go using devm_platform_ioremap_resource_byname()

drivers/soc/qcom/dcc.c line 282

Quoted 5 lines

drivers/soc/qcom/dcc.c new file +4 -0

+	if (!res)
+		return -EINVAL;
+
+	drvdata->reg_size = resource_size(res);

reg_size is unused outside this assignment, no need to lug it around in drvdata.

drivers/soc/qcom/dcc.c line 283

Quoted 2 lines

drivers/soc/qcom/dcc.c new file +1 -0

+	drvdata->base = devm_ioremap(dev, res->start, resource_size(res));

drvdata->base is only accessed from this function, use a local variable instead.

drivers/soc/qcom/dcc.c line 288

Quoted 6 lines

drivers/soc/qcom/dcc.c new file +5 -0

+	if (!drvdata->base)
+		return -ENOMEM;
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+							"dcc-ram-base");

Here you're actually carrying the resource size, so it makes sense.

But it's okay not to wrap this line.

Quoted 11 lines

drivers/soc/qcom/dcc.c new file +5 -0

+	if (!res)
+		return -EINVAL;
+
+	drvdata->ram_size = resource_size(res);
+	drvdata->ram_base = devm_ioremap(dev, res->start, 

resource_size(res));

drivers/soc/qcom/dcc.c new file +5 -0

+	if (!drvdata->ram_base)
+		return -ENOMEM;
+	cfg = of_device_get_match_data(&pdev->dev);
+	drvdata->ram_offset = cfg->dcc_ram_offset;
+

drivers/soc/qcom/dcc.c line 303

Quoted 6 lines

drivers/soc/qcom/dcc.c new file +1 -0

+	if (FIELD_GET(BIT(DCC_VER_INFO_BIT), dcc_readl(drvdata, 

DCC_HW_INFO))) {

drivers/soc/qcom/dcc.c new file +4 -0

+		drvdata->mem_map_ver = DCC_MEM_MAP_VER3;
+		drvdata->nr_link_list = dcc_readl(drvdata, DCC_LL_NUM_INFO);
+		if (drvdata->nr_link_list == 0)
+			return	-EINVAL;

Replace the \t in the middle

Quoted 14 lines

drivers/soc/qcom/dcc.c new file +1 -0

+	} else if ((dcc_readl(drvdata, DCC_HW_INFO) & DCC_VER_MASK2) == 

DCC_VER_MASK2) {

drivers/soc/qcom/dcc.c new file +12 -0

+		drvdata->mem_map_ver = DCC_MEM_MAP_VER2;
+		drvdata->nr_link_list = dcc_readl(drvdata, DCC_LL_NUM_INFO);
+		if (drvdata->nr_link_list == 0)
+			return	-EINVAL;
+	} else {
+		drvdata->mem_map_ver = DCC_MEM_MAP_VER1;
+		drvdata->nr_link_list = DCC_MAX_LINK_LIST;
+	}
+
+	if ((dcc_readl(drvdata, DCC_HW_INFO) & BIT(6)) == BIT(6))
+		drvdata->loopoff = DCC_FIX_LOOP_OFFSET;
+	else

drivers/soc/qcom/dcc.c line 322

Quoted 6 lines

drivers/soc/qcom/dcc.c new file +6 -0

+		drvdata->loopoff = get_bitmask_order((drvdata->ram_size +
+				drvdata->ram_offset) / 4 - 1);
+	mutex_init(&drvdata->mutex);
+
+	drvdata->enable = devm_kzalloc(dev, drvdata->nr_link_list *
+			sizeof(bool), GFP_KERNEL);

kzalloc(, items * sizeof(), ...) is kcalloc()

drivers/soc/qcom/dcc.c

Quoted 2 lines

drivers/soc/qcom/dcc.c new file +2 -0

+	if (!drvdata->enable)
+		return -ENOMEM;

Add a newline between each check and the subsequent allocation, or do all the allocation then do a

	if (!dcc->enable || !dcc->configured ...)
		return -ENOMEM;

Quoted 10 lines

drivers/soc/qcom/dcc.c new file +10 -0

+	drvdata->configured = devm_kzalloc(dev, drvdata->nr_link_list *
+			sizeof(bool), GFP_KERNEL);
+	if (!drvdata->configured)
+		return -ENOMEM;
+	drvdata->nr_config = devm_kzalloc(dev, drvdata->nr_link_list *
+			sizeof(u32), GFP_KERNEL);
+	if (!drvdata->nr_config)
+		return -ENOMEM;
+	drvdata->cfg_head = devm_kzalloc(dev, drvdata->nr_link_list *
+			sizeof(struct list_head), GFP_KERNEL);

drivers/soc/qcom/dcc.c line 340

Quoted 6 lines

drivers/soc/qcom/dcc.c new file +6 -0

+	if (!drvdata->cfg_head)
+		return -ENOMEM;
+
+	for (i = 0; i < drvdata->nr_link_list; i++) {
+		INIT_LIST_HEAD(&drvdata->cfg_head[i]);
+		drvdata->nr_config[i] = 0;

kzalloc() already initialized nr_config.

Quoted 6 lines

drivers/soc/qcom/dcc.c new file +6 -0

+	}
+
+	memset_io(drvdata->ram_base, 0, drvdata->ram_size);
+
+	drvdata->curr_list = DCC_INVALID_LINK_LIST;
+

drivers/soc/qcom/dcc.c line 351

Quoted 5 lines

drivers/soc/qcom/dcc.c new file +5 -0

+	ret = dcc_sram_dev_init(drvdata);
+	if (ret)
+		goto err;
+
+	return ret;

We know ret is 0 here, but if you rename "err" to "out" and move it above this line you can reuse return.

Quoted 17 lines

drivers/soc/qcom/dcc.c new file +16 -0

+err:
+	return ret;
+}
+
+static int dcc_remove(struct platform_device *pdev)
+{
+	struct dcc_drvdata *drvdata = platform_get_drvdata(pdev);
+
+	dcc_sram_dev_exit(drvdata);
+
+	dcc_config_reset(drvdata);
+
+	return 0;
+}
+
+static const struct qcom_dcc_config sm8150_cfg = {

drivers/soc/qcom/dcc.c line 373

Quoted 6 lines

drivers/soc/qcom/dcc.c new file +6 -0

+	.dcc_ram_offset                         = 0x5000,
+};
+
+static const struct of_device_id dcc_match_table[] = {
+	{ .compatible = "qcom,sm8150-dcc", .data = &sm8150_cfg },
+};

MODULE_DEVICE_TABLE(of, dcc_match_table);

drivers/soc/qcom/dcc.c line 376

Quoted 4 lines

drivers/soc/qcom/dcc.c new file +3 -0

+
+static struct platform_driver dcc_driver = {
+	.probe					= dcc_probe,

The indentation here is excessive, feel free to use a single space.

drivers/soc/qcom/dcc.c line 379

Quoted 3 lines

drivers/soc/qcom/dcc.c new file +3 -0

+	.remove					= dcc_remove,
+	.driver					= {
+		.name		= "msm-dcc",

We tend to not use "msm" anymore, so how about "qcom-dcc"?

PS. It's hard to comment on some of the things in this patch, as they are not used until the next patch...

Regards,
Bjorn

Quoted 13 lines

drivers/soc/qcom/dcc.c new file +9 -1

+		.of_match_table	= dcc_match_table,
+	},
+};
+
+module_platform_driver(dcc_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Qualcomm Technologies Inc. DCC driver");
+
--

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Quoted 12 lines · Bjorn Andersson

Quoted 9 lines · Souradeep Chowdhury

The DCC is a DMA Engine designed to capture and store data during system crash or software triggers. The DCC operates based on link list entries which provides it with data and addresses and the function it needs to perform. These functions are read, write and loop. Added the basic driver in this patch which contains a probe method which instantiates the resources needed by the driver. DCC has it's own SRAM which needs to be instantiated at probe time as well.

Quoted 3 lines

So to summarize, the DCC will upon a crash copy the configured region into the dcc-ram, where it can be retrieved either by dumping the memory over USB or from sysfs on the next boot?

Replied by Sai

Quoted 17 lines · On Thu 11 Mar 04:06 CST 2021, [email protected] wrote:

Quoted 15 lines · Bjorn Andersson

Quoted 9 lines · Souradeep Chowdhury

The DCC is a DMA Engine designed to capture and store data during system crash or software triggers. The DCC operates based on link list entries which provides it with data and addresses and the function it needs to perform. These functions are read, write and loop. Added the basic driver in this patch which contains a probe method which instantiates the resources needed by the driver. DCC has it's own SRAM which needs to be instantiated at probe time as well.

So to summarize, the DCC will upon a crash copy the configured region into the dcc-ram, where it can be retrieved either by dumping the memory over USB or from sysfs on the next boot?

Quoted 2 lines

Replied by Sai

Thanks Souradeep and Sai, I'm definitely interested in learning more about what the hardware block can do and how we can use it.

The DCC is a DMA engine designed to store register values either in case of a system crash or in case of software triggers manually done by the user. Using DCC hardware and the sysfs interface of the driver the user can exploit various functionalities of DCC. The user can specify the register addresses, the values of which is stored by DCC in it's dedicated SRAM. The register addresses can be used either to read from, write to, first read and store value and then write or to loop. All these options can be exploited using the sysfs interface given to the user. Following are the sysfs interfaces exposed in DCC driver which are documented
1)trigger
2)config
3)config_write
4)config_reset
5)enable
6)rd_mod_wr
7)loop

Signed-off-by Souradeep Chowdhury <[email protected]>

---
 Documentation/ABI/testing/sysfs-driver-dcc | 74 ++++++++++++++++++++++++++++++
 1 file changed, 74 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc

Documentation/ABI/testing/sysfs-driver-dcc new file +17 -0

new file mode 100644
index 0000000..7a855ca
@@ -0,0 +1,74 @@
+What:           /sys/bus/platform/devices/.../trigger
+Date:           February 2021
+Contact:        Souradeep Chowdhury <[email protected]>
+Description:
+		This file allows the software trigger to be enabled
+		by the user through the sysfs interface.Through this
+		interface the user can manually start a software trigger
+		in dcc where by the dcc driver stores the current status
+		of the specified registers in dcc sram.
+
+What:           /sys/bus/platform/devices/.../enable
+Date:           February 2021
+Contact:        Souradeep Chowdhury <[email protected]>
+Description:
+		This file allows the user to manually enable or
+		disable dcc driver.The dcc hardware needs to be
+		enabled before use.

Documentation/ABI/testing/sysfs-driver-dcc new file +29 -0

+
+What:           /sys/bus/platform/devices/.../config_reset
+Date:           February 2021
+Contact:        Souradeep Chowdhury <[email protected]>
+Description:
+		This file is used to reset the configuration of
+		a dcc driver to the default configuration.
+
+What:           /sys/bus/platform/devices/.../loop
+Date:           February 2021
+Contact:        Souradeep Chowdhury <[email protected]>
+Description:
+		This file is used to enter the loop count as dcc
+		driver gives the option to loop multiple times on
+		the same register and store the values for each
+		loop.
+
+What:           /sys/bus/platform/devices/.../rd_mod_wr
+Date:           February 2021
+Contact:        Souradeep Chowdhury <[email protected]>
+Description:
+		This file is used to read the value of the register
+		and then write the value given as an argument to the
+		register address in config.The address argument should
+		be given of the form <mask> <value>.
+
+What:           /sys/bus/platform/devices/.../ready
+Date:           February 2021
+Contact:        Souradeep Chowdhury <[email protected]>

Signature · 2 lines

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Quoted 52 lines · Souradeep Chowdhury

The DCC is a DMA engine designed to store register values either in case of a system crash or in case of software triggers manually done by the user. Using DCC hardware and the sysfs interface of the driver the user can exploit various functionalities of DCC. The user can specify the register addresses, the values of which is stored by DCC in it's dedicated SRAM. The register addresses can be used either to read from, write to, first read and store value and then write or to loop. All these options can be exploited using the sysfs interface given to the user. Following are the sysfs interfaces exposed in DCC driver which are documented
1)trigger
2)config
3)config_write
4)config_reset
5)enable
6)rd_mod_wr
7)loop

Signed-off-by Souradeep Chowdhury <[email protected]>

---
 Documentation/ABI/testing/sysfs-driver-dcc | 74 
++++++++++++++++++++++++++++++
 1 file changed, 74 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-dcc

Documentation/ABI/testing/sysfs-driver-dcc new file +21 -0

new file mode 100644
index 0000000..7a855ca
@@ -0,0 +1,74 @@
+What:           /sys/bus/platform/devices/.../trigger
+Date:           February 2021
+Contact:        Souradeep Chowdhury <[email protected]>
+Description:
+		This file allows the software trigger to be enabled
+		by the user through the sysfs interface.Through this
+		interface the user can manually start a software trigger
+		in dcc where by the dcc driver stores the current status
+		of the specified registers in dcc sram.
+
+What:           /sys/bus/platform/devices/.../enable
+Date:           February 2021
+Contact:        Souradeep Chowdhury <[email protected]>
+Description:
+		This file allows the user to manually enable or
+		disable dcc driver. The dcc hardware needs to be
+		enabled before use.
+
+What:           /sys/bus/platform/devices/.../config
+Date:           February 2021
+Contact:        Souradeep Chowdhury <[email protected]>

Documentation/ABI/testing/sysfs-driver-dcc line 27

Quoted 6 lines

Documentation/ABI/testing/sysfs-driver-dcc new file +6 -0

+Description:
+		This file allows user to configure the register values
+		along with addresses to the dcc driver.This register
+		addresses are used to read from,write or loop through.
+		To enable all these options separate sysfs files have
+		are created.

Please describe the expected content of this file.

Quoted 4 lines

Documentation/ABI/testing/sysfs-driver-dcc new file +4 -0

+
+What:           /sys/bus/platform/devices/.../config_write
+Date:           February 2021
+Contact:        Souradeep Chowdhury <[email protected]>

Documentation/ABI/testing/sysfs-driver-dcc line 35

Quoted 4 lines

Documentation/ABI/testing/sysfs-driver-dcc new file +4 -0

+Description:
+		This file allows user to write a value to the register
+		address given as argument.The values are entered in the
+		form of <register_address> <value>.

So it's just a generic 'write some user defined data to some user defined register'? This doesn't sound like the typical way things are exposed in sysfs.

Quoted 34 lines

Documentation/ABI/testing/sysfs-driver-dcc new file +33 -0

+
+What:           /sys/bus/platform/devices/.../config_reset
+Date:           February 2021
+Contact:        Souradeep Chowdhury <[email protected]>
+Description:
+		This file is used to reset the configuration of
+		a dcc driver to the default configuration.
+
+What:           /sys/bus/platform/devices/.../loop
+Date:           February 2021
+Contact:        Souradeep Chowdhury <[email protected]>
+Description:
+		This file is used to enter the loop count as dcc
+		driver gives the option to loop multiple times on
+		the same register and store the values for each
+		loop.
+
+What:           /sys/bus/platform/devices/.../rd_mod_wr
+Date:           February 2021
+Contact:        Souradeep Chowdhury <[email protected]>
+Description:
+		This file is used to read the value of the register
+		and then write the value given as an argument to the
+		register address in config.The address argument should
+		be given of the form <mask> <value>.
+
+What:           /sys/bus/platform/devices/.../ready
+Date:           February 2021
+Contact:        Souradeep Chowdhury <[email protected]>
+Description:
+		This file is used to check the status of the dcc
+		hardware if it's ready to take the inputs.
+

Documentation/ABI/testing/sysfs-driver-dcc line 74

Quoted 6 lines

Documentation/ABI/testing/sysfs-driver-dcc new file +6 -0

+What:		/sys/bus/platform/devices/.../curr_list
+Date:		February 2021
+Contact:	Souradeep Chowdhury <[email protected]>
+Description:
+		This file is used to configure the linkedlist data
+		to be used while configuring addresses.

Please describe the format of this attr. Is it read/write?

Regards,
Bjorn

Quoted 4 lines

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation