Re: [PATCH V2 2/5] soc: qcom: dcc: Add driver support for Data Capture and Compare unit(DCC)
On 2021-04-02 06:20, Stephen Boyd wrote:
Quoting schow...@codeaurora.org (2021-04-01 07:04:07)
On 2021-03-30 01:35, Stephen Boyd wrote:
> Quoting Souradeep Chowdhury (2021-03-25 01:02:33)
>> diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c
>> new file mode 100644
>> index 000..a55d8ca7
>> --- /dev/null
>> +++ b/drivers/soc/qcom/dcc.c
>> @@ -0,0 +1,1549 @@
[..]
>
>> + void __iomem*base;
>> + u32 reg_size;
>> + struct device *dev;
>> + struct mutexmutex;
>
> In particular what this mutex is protecting.
Ack. The mutex is used to protect the access as well as manipulation
of
the main instance of dcc_drvdata structure
initialized during probe time. This structure contains the useful
driver
data information and is set using the call
platform_set_drvdata(pdev, drvdata) which links this data to the
platform device and hence needs to be protected via
mutex locks. The same convention is followed across other similar
drivers exposing userspace like the llcc driver.
The region that the mutex is protecting seems quite large. That's
probably because I don't understand the driver.
>
>> +
>> + mutex_lock(>mutex);
>> +
>> + for (curr_list = 0; curr_list < drvdata->nr_link_list;
>> curr_list++) {
>> + if (!drvdata->enable[curr_list])
>> + continue;
>> + ll_cfg = dcc_readl(drvdata, DCC_LL_CFG(curr_list));
>> + tmp_ll_cfg = ll_cfg & ~BIT(9);
>> + dcc_writel(drvdata, tmp_ll_cfg,
>> DCC_LL_CFG(curr_list));
>> + dcc_writel(drvdata, 1, DCC_LL_SW_TRIGGER(curr_list));
>> + dcc_writel(drvdata, ll_cfg, DCC_LL_CFG(curr_list));
>> + }
>
> Does the mutex need to be held while waiting for ready?
Yes, to maintain consistency because inside the dcc_ready function,
there is access to dcc_drvdata structure set
on the platform device.
Is the drvdata going to be modified somewhere else?
Ack. Not considering holding mutex locks for Read operations.
>> +
>> + dev_info(drvdata->dev, "All values written to
>> enable.\n");
>
> Debug print?
Ack
>
>> + /* Make sure all config is written in sram */
>> + mb();
>
> This won't work as intended.
This was called to prevent instruction reordering if the driver runs
on
multiple
CPU cores. As the hardware manipulation has to be done sequentially
before the
trigger is set. Kindly let me know the concern in this case.
Device I/O with the proper accessors is sequential even if the process
moves to a different CPU. Is that what you're worried about? The
comment
says "make sure it is written to sram", which should be achieved by
reading some register back from the device after all the writes so that
the driver knows the writes have been posted to the device. I believe
this mb() is doing nothing.
Ack
>
>> +
>> + drvdata->enable[list] = true;
>> +
>> + /* 5. Configure trigger */
>> + dcc_writel(drvdata, BIT(9), DCC_LL_CFG(list));
>> + }
>> +
>> +err:
>> + mutex_unlock(>mutex);
>> + return ret;
>> +}
>> +
>> +static void dcc_disable(struct dcc_drvdata *drvdata)
>> +{
>> + int curr_list;
>> +
>> + mutex_lock(>mutex);
>> +
>> + if (!dcc_ready(drvdata))
>> + dev_err(drvdata->dev, "DCC is not ready Disabling
>> DCC...\n");
>
> Is that two sentences? And a debug print?
Ack.
>
>> +
>> + for (curr_list = 0; curr_list < drvdata->nr_link_list;
>> curr_list++) {
>> + if (!drvdata->enable[curr_list])
>> + continue;
>> + dcc_writel(drvdata, 0, DCC_LL_CFG(curr_list));
>> + dcc_writel(drvdata, 0, DCC_LL_BASE(curr_list));
>> + dcc_writel(drvdata, 0, DCC_FD_BASE(curr_list));
>> + dcc_writel(drvdata, 0, DCC_LL_LOCK(curr_list));
>> + drvdata->enable[curr_list] = false;
>> + }
>> + memset_io(drvdata->ram_base, 0, drvdata->ram_size);
>> + drvdata->ram_cfg = 0;
>> + drvdata->ram_start = 0;
>> + mutex_unlock(>mutex);
>> +}
>> +
>> +static ssize_t curr_list_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + int ret;
>> + struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
>> +
>> + mutex_lock(>mutex);
>> + if (drvdata->curr_list == DCC_INVALID_LINK_LIST) {
>> + dev_err(dev, "curr_list is not set.\n");
>> + ret = -EINVAL;
>> + goto err;
>> + }
>> +
>> + ret = scnprintf(buf, PAGE_SIZE, "%d\n", drvdata->curr_list);
>> +err:
>> + mutex_unlock(>mutex);
>> + return ret;
>> +}
>> +
>> +static ssize_t curr_list_store(struct device *dev,
>> + struct
>> device_attribute *attr,
>> + const char *buf,
>> size_t
Re: [PATCH V2 2/5] soc: qcom: dcc: Add driver support for Data Capture and Compare unit(DCC)
Quoting schow...@codeaurora.org (2021-04-01 07:04:07)
> On 2021-03-30 01:35, Stephen Boyd wrote:
> > Quoting Souradeep Chowdhury (2021-03-25 01:02:33)
> >> diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c
> >> new file mode 100644
> >> index 000..a55d8ca7
> >> --- /dev/null
> >> +++ b/drivers/soc/qcom/dcc.c
> >> @@ -0,0 +1,1549 @@
[..]
> >
> >> + void __iomem*base;
> >> + u32 reg_size;
> >> + struct device *dev;
> >> + struct mutexmutex;
> >
> > In particular what this mutex is protecting.
>
> Ack. The mutex is used to protect the access as well as manipulation of
> the main instance of dcc_drvdata structure
> initialized during probe time. This structure contains the useful driver
> data information and is set using the call
> platform_set_drvdata(pdev, drvdata) which links this data to the
> platform device and hence needs to be protected via
> mutex locks. The same convention is followed across other similar
> drivers exposing userspace like the llcc driver.
The region that the mutex is protecting seems quite large. That's
probably because I don't understand the driver.
> >
> >> +
> >> + mutex_lock(>mutex);
> >> +
> >> + for (curr_list = 0; curr_list < drvdata->nr_link_list;
> >> curr_list++) {
> >> + if (!drvdata->enable[curr_list])
> >> + continue;
> >> + ll_cfg = dcc_readl(drvdata, DCC_LL_CFG(curr_list));
> >> + tmp_ll_cfg = ll_cfg & ~BIT(9);
> >> + dcc_writel(drvdata, tmp_ll_cfg,
> >> DCC_LL_CFG(curr_list));
> >> + dcc_writel(drvdata, 1, DCC_LL_SW_TRIGGER(curr_list));
> >> + dcc_writel(drvdata, ll_cfg, DCC_LL_CFG(curr_list));
> >> + }
> >
> > Does the mutex need to be held while waiting for ready?
>
> Yes, to maintain consistency because inside the dcc_ready function,
> there is access to dcc_drvdata structure set
> on the platform device.
Is the drvdata going to be modified somewhere else?
> >> +
> >> + dev_info(drvdata->dev, "All values written to
> >> enable.\n");
> >
> > Debug print?
>
> Ack
>
> >
> >> + /* Make sure all config is written in sram */
> >> + mb();
> >
> > This won't work as intended.
>
> This was called to prevent instruction reordering if the driver runs on
> multiple
> CPU cores. As the hardware manipulation has to be done sequentially
> before the
> trigger is set. Kindly let me know the concern in this case.
Device I/O with the proper accessors is sequential even if the process
moves to a different CPU. Is that what you're worried about? The comment
says "make sure it is written to sram", which should be achieved by
reading some register back from the device after all the writes so that
the driver knows the writes have been posted to the device. I believe
this mb() is doing nothing.
>
> >
> >> +
> >> + drvdata->enable[list] = true;
> >> +
> >> + /* 5. Configure trigger */
> >> + dcc_writel(drvdata, BIT(9), DCC_LL_CFG(list));
> >> + }
> >> +
> >> +err:
> >> + mutex_unlock(>mutex);
> >> + return ret;
> >> +}
> >> +
> >> +static void dcc_disable(struct dcc_drvdata *drvdata)
> >> +{
> >> + int curr_list;
> >> +
> >> + mutex_lock(>mutex);
> >> +
> >> + if (!dcc_ready(drvdata))
> >> + dev_err(drvdata->dev, "DCC is not ready Disabling
> >> DCC...\n");
> >
> > Is that two sentences? And a debug print?
>
> Ack.
>
> >
> >> +
> >> + for (curr_list = 0; curr_list < drvdata->nr_link_list;
> >> curr_list++) {
> >> + if (!drvdata->enable[curr_list])
> >> + continue;
> >> + dcc_writel(drvdata, 0, DCC_LL_CFG(curr_list));
> >> + dcc_writel(drvdata, 0, DCC_LL_BASE(curr_list));
> >> + dcc_writel(drvdata, 0, DCC_FD_BASE(curr_list));
> >> + dcc_writel(drvdata, 0, DCC_LL_LOCK(curr_list));
> >> + drvdata->enable[curr_list] = false;
> >> + }
> >> + memset_io(drvdata->ram_base, 0, drvdata->ram_size);
> >> + drvdata->ram_cfg = 0;
> >> + drvdata->ram_start = 0;
> >> + mutex_unlock(>mutex);
> >> +}
> >> +
> >> +static ssize_t curr_list_show(struct device *dev,
> >> + struct device_attribute *attr, char *buf)
> >> +{
> >> + int ret;
> >> + struct dcc_drvdata *drvdata = dev_get_drvdata(dev);
> >> +
> >> + mutex_lock(>mutex);
> >> + if (drvdata->curr_list == DCC_INVALID_LINK_LIST) {
> >> + dev_err(dev, "curr_list is not set.\n");
> >> + ret = -EINVAL;
> >> + goto err;
> >> + }
> >> +
> >> + ret = scnprintf(buf, PAGE_SIZE, "%d\n", drvdata->curr_list);
> >> +err:
> >> + mutex_unlock(>mutex);
> >> + return ret;
> >> +}
> >> +
> >> +static ssize_t curr_list_store(struct device *dev,
> >> +
Re: [PATCH V2 2/5] soc: qcom: dcc: Add driver support for Data Capture and Compare unit(DCC)
On 2021-03-30 01:35, Stephen Boyd wrote: Quoting Souradeep Chowdhury (2021-03-25 01:02:33) 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 sysfs interface.The user gives addresses as inputs and these addresses are stored in the form of linkedlists.In case of a system crash or a manual software trigger by the user through the sysfs interface, the dcc captures and stores the values at these addresses. This patch contains the driver which has all the methods pertaining to the sysfs interface, auxiliary functions to support all the four fundamental operations of dcc namely read, write, first read then 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 manual triggers. Signed-off-by: Souradeep Chowdhury --- drivers/soc/qcom/Kconfig |8 + drivers/soc/qcom/Makefile |1 + drivers/soc/qcom/dcc.c| 1549 + Where's the document for various sysfs attributes in Documentation/ABI? Will combine the sysfs document with the driver patch as suggested. 3 files changed, 1558 insertions(+) create mode 100644 drivers/soc/qcom/dcc.c diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig index 79b568f..8819e0b 100644 --- a/drivers/soc/qcom/Kconfig +++ b/drivers/soc/qcom/Kconfig @@ -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" Put (DCC) after Compare? Ack + 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 diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile index ad675a6..1b00870 100644 --- a/drivers/soc/qcom/Makefile +++ b/drivers/soc/qcom/Makefile @@ -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 Can this be sorted based on config or file name instead of adding to the end of the file and leading to endless conflicts? Ack diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c new file mode 100644 index 000..a55d8ca7 --- /dev/null +++ b/drivers/soc/qcom/dcc.c @@ -0,0 +1,1549 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (c) 2015-2021, The Linux Foundation. All rights reserved. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +#define TIMEOUT_US 100 + +#define dcc_writel(drvdata, val, off) \ + writel((val), drvdata->base + dcc_offset_conv(drvdata, off)) +#define dcc_readl(drvdata, off) \ + readl(drvdata->base + dcc_offset_conv(drvdata, off)) + +#define dcc_sram_readl(drvdata, off) \ + readl(drvdata->ram_base + off) + +#define DCC_SRAM_NODE "dcc_sram" + +/* DCC registers */ +#define DCC_HW_INFO0x04 +#define DCC_LL_NUM_INFO0x10 +#define DCC_STATUS 0x1C +#define DCC_LL_LOCK(m) (0x34 + 0x80 * m) +#define DCC_LL_CFG(m) (0x38 + 0x80 * m) +#define DCC_LL_BASE(m) (0x3c + 0x80 * m) +#define DCC_FD_BASE(m) (0x40 + 0x80 * m) +#define DCC_LL_TIMEOUT(m) (0x44 + 0x80 * m) +#define DCC_LL_INT_ENABLE(m) (0x4C + 0x80 * m) +#define DCC_LL_INT_STATUS(m) (0x50 + 0x80 * m) +#define DCC_LL_SW_TRIGGER(m) (0x60 + 0x80 * m) +#define DCC_LL_BUS_ACCESS_STATUS(m)(0x64 + 0x80 * m) + +#define DCC_MAP_LEVEL1 0x18 +#define DCC_MAP_LEVEL2 0x34 +#define DCC_MAP_LEVEL3 0x4C + +#define DCC_MAP_OFFSET10x10 +#define DCC_MAP_OFFSET20x18 +#define DCC_MAP_OFFSET30x1C +#define DCC_MAP_OFFSET40x8 + +#define DCC_FIX_LOOP_OFFSET16 +#define DCC_VER_INFO_BIT 9 + +#define DCC_READ 0 +#define DCC_WRITE 1 +#define DCC_LOOP 2 +#define DCC_READ_WRITE 3 + +#define MAX_DCC_OFFSET
Re: [PATCH V2 2/5] soc: qcom: dcc: Add driver support for Data Capture and Compare unit(DCC)
Quoting Souradeep Chowdhury (2021-03-25 01:02:33) > 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 sysfs interface.The user gives > addresses as inputs and these addresses are stored in the > form of linkedlists.In case of a system crash or a manual > software trigger by the user through the sysfs interface, > the dcc captures and stores the values at these addresses. > This patch contains the driver which has all the methods > pertaining to the sysfs interface, auxiliary functions to > support all the four fundamental operations of dcc namely > read, write, first read then 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 manual > triggers. > > Signed-off-by: Souradeep Chowdhury > --- > drivers/soc/qcom/Kconfig |8 + > drivers/soc/qcom/Makefile |1 + > drivers/soc/qcom/dcc.c| 1549 > + Where's the document for various sysfs attributes in Documentation/ABI? > 3 files changed, 1558 insertions(+) > create mode 100644 drivers/soc/qcom/dcc.c > > diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig > index 79b568f..8819e0b 100644 > --- a/drivers/soc/qcom/Kconfig > +++ b/drivers/soc/qcom/Kconfig > @@ -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" Put (DCC) after Compare? > + 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 > diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile > index ad675a6..1b00870 100644 > --- a/drivers/soc/qcom/Makefile > +++ b/drivers/soc/qcom/Makefile > @@ -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 Can this be sorted based on config or file name instead of adding to the end of the file and leading to endless conflicts? > diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c > new file mode 100644 > index 000..a55d8ca7 > --- /dev/null > +++ b/drivers/soc/qcom/dcc.c > @@ -0,0 +1,1549 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (c) 2015-2021, The Linux Foundation. All rights reserved. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > + > +#define TIMEOUT_US 100 > + > +#define dcc_writel(drvdata, val, off) \ > + writel((val), drvdata->base + dcc_offset_conv(drvdata, off)) > +#define dcc_readl(drvdata, off) > \ > + readl(drvdata->base + dcc_offset_conv(drvdata, off)) > + > +#define dcc_sram_readl(drvdata, off) \ > + readl(drvdata->ram_base + off) > + > +#define DCC_SRAM_NODE "dcc_sram" > + > +/* DCC registers */ > +#define DCC_HW_INFO0x04 > +#define DCC_LL_NUM_INFO0x10 > +#define DCC_STATUS 0x1C > +#define DCC_LL_LOCK(m) (0x34 + 0x80 * m) > +#define DCC_LL_CFG(m) (0x38 + 0x80 * m) > +#define DCC_LL_BASE(m) (0x3c + 0x80 * m) > +#define DCC_FD_BASE(m) (0x40 + 0x80 * m) > +#define DCC_LL_TIMEOUT(m) (0x44 + 0x80 * m) > +#define DCC_LL_INT_ENABLE(m) (0x4C + 0x80 * m) > +#define DCC_LL_INT_STATUS(m) (0x50 + 0x80 * m) > +#define DCC_LL_SW_TRIGGER(m) (0x60 + 0x80 * m) > +#define DCC_LL_BUS_ACCESS_STATUS(m)(0x64 + 0x80 * m) > + > +#define DCC_MAP_LEVEL1 0x18 > +#define DCC_MAP_LEVEL2 0x34 > +#define DCC_MAP_LEVEL3 0x4C > + > +#define DCC_MAP_OFFSET10x10 > +#define DCC_MAP_OFFSET20x18 > +#define DCC_MAP_OFFSET30x1C > +#define DCC_MAP_OFFSET40x8 > + > +#define DCC_FIX_LOOP_OFFSET16 > +#define DCC_VER_INFO_BIT 9 > + > +#define DCC_READ 0 > +#define DCC_WRITE 1 > +#define
[PATCH V2 2/5] soc: qcom: dcc: Add driver support for Data Capture and Compare unit(DCC)
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 sysfs interface.The user gives addresses as inputs and these addresses are stored in the form of linkedlists.In case of a system crash or a manual software trigger by the user through the sysfs interface, the dcc captures and stores the values at these addresses. This patch contains the driver which has all the methods pertaining to the sysfs interface, auxiliary functions to support all the four fundamental operations of dcc namely read, write, first read then 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 manual triggers. Signed-off-by: Souradeep Chowdhury --- drivers/soc/qcom/Kconfig |8 + drivers/soc/qcom/Makefile |1 + drivers/soc/qcom/dcc.c| 1549 + 3 files changed, 1558 insertions(+) create mode 100644 drivers/soc/qcom/dcc.c diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig index 79b568f..8819e0b 100644 --- a/drivers/soc/qcom/Kconfig +++ b/drivers/soc/qcom/Kconfig @@ -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 diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile index ad675a6..1b00870 100644 --- a/drivers/soc/qcom/Makefile +++ b/drivers/soc/qcom/Makefile @@ -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 diff --git a/drivers/soc/qcom/dcc.c b/drivers/soc/qcom/dcc.c new file mode 100644 index 000..a55d8ca7 --- /dev/null +++ b/drivers/soc/qcom/dcc.c @@ -0,0 +1,1549 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (c) 2015-2021, The Linux Foundation. All rights reserved. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +#define TIMEOUT_US 100 + +#define dcc_writel(drvdata, val, off) \ + writel((val), drvdata->base + dcc_offset_conv(drvdata, off)) +#define dcc_readl(drvdata, off) \ + readl(drvdata->base + dcc_offset_conv(drvdata, off)) + +#define dcc_sram_readl(drvdata, off) \ + readl(drvdata->ram_base + off) + +#define DCC_SRAM_NODE "dcc_sram" + +/* DCC registers */ +#define DCC_HW_INFO0x04 +#define DCC_LL_NUM_INFO0x10 +#define DCC_STATUS 0x1C +#define DCC_LL_LOCK(m) (0x34 + 0x80 * m) +#define DCC_LL_CFG(m) (0x38 + 0x80 * m) +#define DCC_LL_BASE(m) (0x3c + 0x80 * m) +#define DCC_FD_BASE(m) (0x40 + 0x80 * m) +#define DCC_LL_TIMEOUT(m) (0x44 + 0x80 * m) +#define DCC_LL_INT_ENABLE(m) (0x4C + 0x80 * m) +#define DCC_LL_INT_STATUS(m) (0x50 + 0x80 * m) +#define DCC_LL_SW_TRIGGER(m) (0x60 + 0x80 * m) +#define DCC_LL_BUS_ACCESS_STATUS(m)(0x64 + 0x80 * m) + +#define DCC_MAP_LEVEL1 0x18 +#define DCC_MAP_LEVEL2 0x34 +#define DCC_MAP_LEVEL3 0x4C + +#define DCC_MAP_OFFSET10x10 +#define DCC_MAP_OFFSET20x18 +#define DCC_MAP_OFFSET30x1C +#define DCC_MAP_OFFSET40x8 + +#define DCC_FIX_LOOP_OFFSET16 +#define DCC_VER_INFO_BIT 9 + +#define DCC_READ 0 +#define DCC_WRITE 1 +#define DCC_LOOP 2 +#define DCC_READ_WRITE 3 + +#define MAX_DCC_OFFSET GENMASK(9, 2) +#define MAX_DCC_LENGENMASK(6, 0) +#define MAX_LOOP_CNT GENMASK(7, 0) + +#define DCC_ADDR_DESCRIPTOR0x00 +#define DCC_LOOP_DESCRIPTORBIT(30) +#define DCC_RD_MOD_WR_DESCRIPTOR BIT(31) +#define DCC_LINK_DESCRIPTORGENMASK(31, 30) + +#define DCC_READ_IND 0x00 +#define DCC_WRITE_IND
