Re: [PATCH V11 4/7] dma: add Qualcomm Technologies HIDMA channel driver
On 1/4/2016 1:43 PM, Andy Shevchenko wrote: >> his patch adds support for hidma engine. The driver consists of two >> > logical blocks. The DMA engine interface and the low-level interface. >> > The hardware only supports memcpy/memset and this driver only support >> > memcpy interface. HW and driver doesn't support slave interface. >> > > Looks fine now. > > Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> > Thanks. I'll wait until the end of the week to address your other comments. I'm hoping to hear from devicetree folks until that time. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V11 1/7] dma: qcom_bam_dma: move to qcom directory
Creating a QCOM directory for all QCOM DMA source files.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
Reviewed-by: Andy Gtoss <agr...@codeaurora.org>
---
drivers/dma/Kconfig| 11 ++-
drivers/dma/Makefile | 2 +-
drivers/dma/qcom/Kconfig | 8
drivers/dma/qcom/Makefile | 1 +
drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 4 ++--
5 files changed, 14 insertions(+), 12 deletions(-)
create mode 100644 drivers/dma/qcom/Kconfig
create mode 100644 drivers/dma/qcom/Makefile
rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index b458475..47b1b98 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -408,15 +408,6 @@ config PXA_DMA
16 to 32 channels for peripheral to memory or memory to memory
transfers.
-config QCOM_BAM_DMA
- tristate "QCOM BAM DMA support"
- depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
- select DMA_ENGINE
- select DMA_VIRTUAL_CHANNELS
- ---help---
- Enable support for the QCOM BAM DMA controller. This controller
- provides DMA capabilities for a variety of on-chip devices.
-
config SIRF_DMA
tristate "CSR SiRFprimaII/SiRFmarco DMA support"
depends on ARCH_SIRF
@@ -527,6 +518,8 @@ config ZX_DMA
# driver files
source "drivers/dma/bestcomm/Kconfig"
+source "drivers/dma/qcom/Kconfig"
+
source "drivers/dma/dw/Kconfig"
source "drivers/dma/hsu/Kconfig"
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 7711a71..8dba90d 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_PCH_DMA) += pch_dma.o
obj-$(CONFIG_PL330_DMA) += pl330.o
obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
obj-$(CONFIG_PXA_DMA) += pxa_dma.o
-obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
obj-$(CONFIG_RENESAS_DMA) += sh/
obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
@@ -66,4 +65,5 @@ obj-$(CONFIG_TI_EDMA) += edma.o
obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
+obj-y += qcom/
obj-y += xilinx/
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
new file mode 100644
index 000..f17c272
--- /dev/null
+++ b/drivers/dma/qcom/Kconfig
@@ -0,0 +1,8 @@
+config QCOM_BAM_DMA
+ tristate "QCOM BAM DMA support"
+ depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ ---help---
+ Enable support for the QCOM BAM DMA controller. This controller
+ provides DMA capabilities for a variety of on-chip devices.
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
new file mode 100644
index 000..f612ae3
--- /dev/null
+++ b/drivers/dma/qcom/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom/bam_dma.c
similarity index 99%
rename from drivers/dma/qcom_bam_dma.c
rename to drivers/dma/qcom/bam_dma.c
index 5a250cd..b6f053d 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -49,8 +49,8 @@
#include
#include
-#include "dmaengine.h"
-#include "virt-dma.h"
+#include "../dmaengine.h"
+#include "../virt-dma.h"
struct bam_desc_hw {
u32 addr; /* Buffer physical address */
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V11 0/7] dma: add Qualcomm Technologies HIDMA driver
Hi Vinod,
On 1/3/2016 7:06 PM, Sinan Kaya wrote:
> The Qualcomm Technologies HIDMA device has been designed
> to support virtualization technology. The driver has been
> divided into two to follow the hardware design.
>
> 1. HIDMA Management driver
> 2. HIDMA Channel driver
>
> Each HIDMA HW consists of multiple channels. These channels
> share some set of common parameters. These parameters are
> initialized by the management driver during power up.
> Same management driver is used for monitoring the execution
> of the channels. Management driver can change the performance
> behavior dynamically such as bandwidth allocation and
> prioritization in the future.
>
> The management driver is executed in hypervisor context and
> is the main management entity for all channels provided by
> the device.
>
> Changes from V10: (https://lkml.org/lkml/2015/12/17/454)
> * none
>
> Changes from V10: (https://lkml.org/lkml/2015/12/17/448)
> * none
>
> Changes from V10: (https://lkml.org/lkml/2015/12/17/449)
> * none
>
> Changes from V10: (https://lkml.org/lkml/2015/12/17/451)
> * none
>
> Changes from V10: (https://lkml.org/lkml/2015/12/17/452)
> * none
>
> Changes from V10: (https://lkml.org/lkml/2015/12/17/453)
> * none
>
> Changes from V10: (https://lkml.org/lkml/2015/12/17/450)
> * Clean up style issues
> * make depend on CONFIG_OF_IRQ too as SPARC arch doesn't seem to define
> CONFIG_OF_IRQ but it defines CONFIG_OF.
>
> Sinan Kaya (7):
> dma: qcom_bam_dma: move to qcom directory
> dma: hidma: Add Device Tree support
> dma: add Qualcomm Technologies HIDMA management driver
> dma: add Qualcomm Technologies HIDMA channel driver
> dma: qcom_hidma: implement lower level hardware interface
> dma: qcom_hidma: add debugfs hooks
> dma: qcom_hidma: add support for object hierarchy
>
> Documentation/ABI/testing/sysfs-platform-hidma | 9 +
> .../ABI/testing/sysfs-platform-hidma-mgmt | 97 +++
> .../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 79 ++
> drivers/dma/Kconfig| 11 +-
> drivers/dma/Makefile | 2 +-
> drivers/dma/qcom/Kconfig | 29 +
> drivers/dma/qcom/Makefile | 5 +
> drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 4 +-
> drivers/dma/qcom/hidma.c | 784 +
> drivers/dma/qcom/hidma.h | 162
> drivers/dma/qcom/hidma_dbg.c | 219 +
> drivers/dma/qcom/hidma_ll.c| 927
> +
> drivers/dma/qcom/hidma_mgmt.c | 400 +
> drivers/dma/qcom/hidma_mgmt.h | 39 +
> drivers/dma/qcom/hidma_mgmt_sys.c | 295 +++
> 15 files changed, 3050 insertions(+), 12 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma
> create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt
> create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
> create mode 100644 drivers/dma/qcom/Kconfig
> create mode 100644 drivers/dma/qcom/Makefile
> rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
> create mode 100644 drivers/dma/qcom/hidma.c
> create mode 100644 drivers/dma/qcom/hidma.h
> create mode 100644 drivers/dma/qcom/hidma_dbg.c
> create mode 100644 drivers/dma/qcom/hidma_ll.c
> create mode 100644 drivers/dma/qcom/hidma_mgmt.c
> create mode 100644 drivers/dma/qcom/hidma_mgmt.h
> create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c
>
Can I have your ACK on your series if you are OK?
Sinan
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V11 5/7] dma: qcom_hidma: implement lower level hardware interface
This patch implements the hardware hooks for the HIDMA channel driver.
The main functions of interest are:
- hidma_ll_init
- hidma_ll_request
- hidma_ll_queue_request
- hidma_ll_hw_start
OS layer calls the hidma_ll_init function during probe to set up the
hardware. At this moment, the number of supported descriptors are also
given. On each request, a descriptor is allocated from the free pool and
filled in with the transfer parameters. Multiple requests can be queued
into the hardware via the OS interface. When client is ready for requests
to be executed, start method is called.
Completions are delivered via callbacks via tasklet.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/dma/qcom/Makefile | 2 +
drivers/dma/qcom/hidma.h| 2 +-
drivers/dma/qcom/hidma_ll.c | 927
3 files changed, 930 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma/qcom/hidma_ll.c
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index bfea699..6bf9267 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,3 +1,5 @@
obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
obj-$(CONFIG_QCOM_HIDMA_MGMT) += hdma_mgmt.o
hdma_mgmt-objs := hidma_mgmt.o hidma_mgmt_sys.o
+obj-$(CONFIG_QCOM_HIDMA) += hdma.o
+hdma-objs:= hidma_ll.o hidma.o
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index 231e306..1e09d7c 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -37,7 +37,7 @@ struct hidma_tre {
atomic_t allocated; /* if this channel is allocated */
bool queued;/* flag whether this is pending */
u16 status; /* status */
- u32 chidx; /* index of the tre */
+ u32 idx;/* index of the tre */
u32 dma_sig;/* signature of the tre */
const char *dev_name; /* name of the device */
void (*callback)(void *data); /* requester callback */
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
new file mode 100644
index 000..0cd8d70
--- /dev/null
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -0,0 +1,927 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine low level code
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "hidma.h"
+
+#define EVRE_SIZE 16 /* each EVRE is 16 bytes */
+
+#define TRCA_CTRLSTS_OFFSET0x0
+#define TRCA_RING_LOW_OFFSET 0x8
+#define TRCA_RING_HIGH_OFFSET 0xC
+#define TRCA_RING_LEN_OFFSET 0x10
+#define TRCA_READ_PTR_OFFSET 0x18
+#define TRCA_WRITE_PTR_OFFSET 0x20
+#define TRCA_DOORBELL_OFFSET 0x400
+
+#define EVCA_CTRLSTS_OFFSET0x0
+#define EVCA_INTCTRL_OFFSET0x4
+#define EVCA_RING_LOW_OFFSET 0x8
+#define EVCA_RING_HIGH_OFFSET 0xC
+#define EVCA_RING_LEN_OFFSET 0x10
+#define EVCA_READ_PTR_OFFSET 0x18
+#define EVCA_WRITE_PTR_OFFSET 0x20
+#define EVCA_DOORBELL_OFFSET 0x400
+
+#define EVCA_IRQ_STAT_OFFSET 0x100
+#define EVCA_IRQ_CLR_OFFSET0x108
+#define EVCA_IRQ_EN_OFFSET 0x110
+
+#define EVRE_CFG_IDX 0
+#define EVRE_LEN_IDX 1
+#define EVRE_DEST_LOW_IDX 2
+#define EVRE_DEST_HI_IDX 3
+
+#define EVRE_ERRINFO_BIT_POS 24
+#define EVRE_CODE_BIT_POS 28
+
+#define EVRE_ERRINFO_MASK GENMASK(3, 0)
+#define EVRE_CODE_MASK GENMASK(3, 0)
+
+#define CH_CONTROL_MASKGENMASK(7, 0)
+#define CH_STATE_MASK GENMASK(7, 0)
+#define CH_STATE_BIT_POS 0x8
+
+#define IRQ_EV_CH_EOB_IRQ_BIT_POS 0
+#define IRQ_EV_CH_WR_RESP_BIT_POS 1
+#define IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS 9
+#define IRQ_TR_CH_DATA_RD_ER_BIT_POS 10
+#define IRQ_TR_CH_DATA_WR_ER_BIT_POS 11
+#define IRQ_TR_CH_INVALID_TRE_BIT_POS 14
+
+#defineENABLE_IRQS (BIT(IRQ_EV_CH_EOB_IRQ_BIT_POS) | \
+ BIT(IRQ_EV_CH_WR_RESP_BIT_POS) | \
+ BIT(IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS)| \
+
[PATCH V11 3/7] dma: add Qualcomm Technologies HIDMA management driver
The Qualcomm Technologies HIDMA device has been designed to support virtualization technology. The driver has been divided into two to follow the hardware design. 1. HIDMA Management driver 2. HIDMA Channel driver Each HIDMA HW consists of multiple channels. These channels share some set of common parameters. These parameters are initialized by the management driver during power up. Same management driver is used for monitoring the execution of the channels. Management driver can change the performance behavior dynamically such as bandwidth allocation and prioritization. The management driver is executed in hypervisor context and is the main management entity for all channels provided by the device. Signed-off-by: Sinan Kaya <ok...@codeaurora.org> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> --- .../ABI/testing/sysfs-platform-hidma-mgmt | 97 +++ drivers/dma/qcom/Kconfig | 11 + drivers/dma/qcom/Makefile | 2 + drivers/dma/qcom/hidma_mgmt.c | 302 + drivers/dma/qcom/hidma_mgmt.h | 39 +++ drivers/dma/qcom/hidma_mgmt_sys.c | 295 6 files changed, 746 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt create mode 100644 drivers/dma/qcom/hidma_mgmt.c create mode 100644 drivers/dma/qcom/hidma_mgmt.h create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c diff --git a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt new file mode 100644 index 000..c2fb5d0 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt @@ -0,0 +1,97 @@ +What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority + /sys/devices/platform/QCOM8060:*/chanops/chan*/priority +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains either 0 or 1 and indicates if the DMA channel is a + low priority (0) or high priority (1) channel. + +What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/weight + /sys/devices/platform/QCOM8060:*/chanops/chan*/weight +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains 0..15 and indicates the weight of the channel among + equal priority channels during round robin scheduling. + +What: /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles + /sys/devices/platform/QCOM8060:*/chreset_timeout_cycles +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains the platform specific cycle value to wait after a + reset command is issued. If the value is chosen too short, + then the HW will issue a reset failure interrupt. The value + is platform specific and should not be changed without + consultance. + +What: /sys/devices/platform/hidma-mgmt*/dma_channels + /sys/devices/platform/QCOM8060:*/dma_channels +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains the number of dma channels supported by one instance + of HIDMA hardware. The value may change from chip to chip. + +What: /sys/devices/platform/hidma-mgmt*/hw_version_major + /sys/devices/platform/QCOM8060:*/hw_version_major +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Version number major for the hardware. + +What: /sys/devices/platform/hidma-mgmt*/hw_version_minor + /sys/devices/platform/QCOM8060:*/hw_version_minor +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Version number minor for the hardware. + +What: /sys/devices/platform/hidma-mgmt*/max_rd_xactions + /sys/devices/platform/QCOM8060:*/max_rd_xactions +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains a value between 0 and 31. Maximum number of + read transactions that can be issued back to back. + Choosing a higher number gives better performance but + can also cause performance reduction to other peripherals + sharing the same bus. + +What: /sys/devices/platform/hidma-mgmt*/max_read_request + /sys/devices/platform/QCOM8060:*/max_read_request +Date: Nov 2015 +KernelVersion: 4.4
[PATCH V11 7/7] dma: qcom_hidma: add support for object hierarchy
In order to create a relationship model between the channels and the
management object, we are adding support for object hierarchy to the
drivers. This patch simplifies the userspace application development.
We will not have to traverse different firmware paths based on device
tree or ACPI baed kernels.
No matter what flavor of kernel is used, objects will be represented as
platform devices.
The new layout is as follows:
hidmam_10: hidma-mgmt@0x5A00 {
compatible = "qcom,hidma-mgmt-1.0";
...
hidma_10: hidma@0x5a01 {
compatible = "qcom,hidma-1.0";
...
}
}
The hidma_mgmt_init detects each instance of the hidma-mgmt-1.0 objects
in device tree and calls into the channel driver to create platform devices
for each child of the management object.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
Documentation/ABI/testing/sysfs-platform-hidma | 9 +++
drivers/dma/qcom/hidma.c | 39 +-
drivers/dma/qcom/hidma_mgmt.c | 104 -
3 files changed, 148 insertions(+), 4 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma
diff --git a/Documentation/ABI/testing/sysfs-platform-hidma
b/Documentation/ABI/testing/sysfs-platform-hidma
new file mode 100644
index 000..d364415
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-hidma
@@ -0,0 +1,9 @@
+What: /sys/devices/platform/hidma-*/chid
+ /sys/devices/platform/QCOM8061:*/chid
+Date: Dec 2015
+KernelVersion: 4.4
+Contact: "Sinan Kaya <ok...@cudeaurora.org>"
+Description:
+ Contains the ID of the channel within the HIDMA instance.
+ It is used to associate a given HIDMA channel with the
+ priority and weight calls in the management interface.
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index 833db9e..ac20bdb 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -549,6 +549,43 @@ static irqreturn_t hidma_chirq_handler(int chirq, void
*arg)
return hidma_ll_inthandler(chirq, lldev);
}
+static ssize_t hidma_show_values(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct hidma_dev *mdev = platform_get_drvdata(pdev);
+
+ buf[0] = 0;
+
+ if (strcmp(attr->attr.name, "chid") == 0)
+ sprintf(buf, "%d\n", mdev->chidx);
+
+ return strlen(buf);
+}
+
+static int hidma_create_sysfs_entry(struct hidma_dev *dev, char *name,
+ int mode)
+{
+ struct device_attribute *attrs;
+ char *name_copy;
+
+ attrs = devm_kmalloc(dev->ddev.dev, sizeof(struct device_attribute),
+GFP_KERNEL);
+ if (!attrs)
+ return -ENOMEM;
+
+ name_copy = devm_kstrdup(dev->ddev.dev, name, GFP_KERNEL);
+ if (!name_copy)
+ return -ENOMEM;
+
+ attrs->attr.name = name_copy;
+ attrs->attr.mode = mode;
+ attrs->show = hidma_show_values;
+ sysfs_attr_init(>attr);
+
+ return device_create_file(dev->ddev.dev, attrs);
+}
+
static int hidma_probe(struct platform_device *pdev)
{
struct hidma_dev *dmadev;
@@ -682,6 +719,7 @@ static int hidma_probe(struct platform_device *pdev)
dmadev->irq = chirq;
tasklet_init(>task, hidma_issue_task, (unsigned long)dmadev);
hidma_debug_init(dmadev);
+ hidma_create_sysfs_entry(dmadev, "chid", S_IRUGO);
dev_info(>dev, "HI-DMA engine driver registration complete\n");
platform_set_drvdata(pdev, dmadev);
pm_runtime_mark_last_busy(dmadev->ddev.dev);
@@ -730,7 +768,6 @@ static const struct of_device_id hidma_match[] = {
{.compatible = "qcom,hidma-1.0",},
{},
};
-
MODULE_DEVICE_TABLE(of, hidma_match);
static struct platform_driver hidma_driver = {
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index ef491b8..4443b47 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -17,13 +17,14 @@
#include
#include
#include
-#include
-#include
+#include
+#include
#include
#include
#include
#include
#include
+#include
#include "hidma_mgmt.h"
@@ -298,5 +299,102 @@ static struct platform_driver hidma_mgmt_driver = {
},
};
-module_platform_driver(hidma_mgmt_driver);
+#if defined(CONFIG_OF)&(CONFIG_OF_IRQ)
+static int object_counter;
+
+static int __init hidma_mgmt_of_populate_channels(struct device_node *np)
+{
+ struct platform_device *pdev_parent = of_find_device_by_node(np);
+ struct platform_device_info pdevinfo;
+ struct of_phandle_args out_irq;
[PATCH V11 6/7] dma: qcom_hidma: add debugfs hooks
Add debugfs hooks for debugging the execution behavior of the DMA
channel. The debugfs hooks get initialized by the probe function and
uninitialized by the remove function.
A stats file is created in debugfs. The stats file will show the
information about each HIDMA channel as well as each asynchronous job
queued and completed at a given time.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/dma/qcom/Makefile| 2 +-
drivers/dma/qcom/hidma.c | 3 +
drivers/dma/qcom/hidma.h | 2 +
drivers/dma/qcom/hidma_dbg.c | 219 +++
4 files changed, 225 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma/qcom/hidma_dbg.c
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index 6bf9267..4bfc38b 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -2,4 +2,4 @@ obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
obj-$(CONFIG_QCOM_HIDMA_MGMT) += hdma_mgmt.o
hdma_mgmt-objs := hidma_mgmt.o hidma_mgmt_sys.o
obj-$(CONFIG_QCOM_HIDMA) += hdma.o
-hdma-objs:= hidma_ll.o hidma.o
+hdma-objs:= hidma_ll.o hidma.o hidma_dbg.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index f8960f1..833db9e 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -681,6 +681,7 @@ static int hidma_probe(struct platform_device *pdev)
dmadev->irq = chirq;
tasklet_init(>task, hidma_issue_task, (unsigned long)dmadev);
+ hidma_debug_init(dmadev);
dev_info(>dev, "HI-DMA engine driver registration complete\n");
platform_set_drvdata(pdev, dmadev);
pm_runtime_mark_last_busy(dmadev->ddev.dev);
@@ -689,6 +690,7 @@ static int hidma_probe(struct platform_device *pdev)
return 0;
uninit:
+ hidma_debug_uninit(dmadev);
hidma_ll_uninit(dmadev->lldev);
dmafree:
if (dmadev)
@@ -706,6 +708,7 @@ static int hidma_remove(struct platform_device *pdev)
pm_runtime_get_sync(dmadev->ddev.dev);
dma_async_device_unregister(>ddev);
devm_free_irq(dmadev->ddev.dev, dmadev->irq, dmadev->lldev);
+ hidma_debug_uninit(dmadev);
hidma_ll_uninit(dmadev->lldev);
hidma_free(dmadev);
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index 1e09d7c..c6b3ae0 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -157,4 +157,6 @@ int hidma_ll_uninit(struct hidma_lldev *llhndl);
irqreturn_t hidma_ll_inthandler(int irq, void *arg);
void hidma_cleanup_pending_tre(struct hidma_lldev *llhndl, u8 err_info,
u8 err_code);
+int hidma_debug_init(struct hidma_dev *dmadev);
+void hidma_debug_uninit(struct hidma_dev *dmadev);
#endif
diff --git a/drivers/dma/qcom/hidma_dbg.c b/drivers/dma/qcom/hidma_dbg.c
new file mode 100644
index 000..fe35002
--- /dev/null
+++ b/drivers/dma/qcom/hidma_dbg.c
@@ -0,0 +1,219 @@
+/*
+ * Qualcomm Technologies HIDMA debug file
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "hidma.h"
+
+static void hidma_ll_chstats(struct seq_file *s, void *llhndl, u32 tre_ch)
+{
+ struct hidma_lldev *lldev = llhndl;
+ struct hidma_tre *tre;
+ u32 length;
+ dma_addr_t src_start;
+ dma_addr_t dest_start;
+ u32 *tre_local;
+
+ if (tre_ch >= lldev->nr_tres) {
+ dev_err(lldev->dev, "invalid TRE number in chstats:%d", tre_ch);
+ return;
+ }
+ tre = >trepool[tre_ch];
+ seq_printf(s, "--Channel %d -\n", tre_ch);
+ seq_printf(s, "allocated=%d\n", atomic_read(>allocated));
+ seq_printf(s, "queued = 0x%x\n", tre->queued);
+ seq_printf(s, "err_info = 0x%x\n",
+ lldev->tx_status_list[tre->idx].err_info);
+ seq_printf(s, "err_code = 0x%x\n",
+ lldev->tx_status_list[tre->idx].err_code);
+ seq_printf(s, "status = 0x%x\n", tre->status);
+ seq_printf(s, "idx = 0x%x\n", tre->idx);
+ seq_printf(s, "dma_sig = 0x%x\n", tre->dma_sig);
+ seq_printf(s, "dev_name=%s\n", tre->dev_name);
+ seq_printf(s, "callback=%p\n", tre->callback);
+ seq_printf(s, "data=%p\n", tre->data);
+ seq_printf(s, "tre_index = 0
[PATCH V11 4/7] dma: add Qualcomm Technologies HIDMA channel driver
This patch adds support for hidma engine. The driver consists of two
logical blocks. The DMA engine interface and the low-level interface.
The hardware only supports memcpy/memset and this driver only support
memcpy interface. HW and driver doesn't support slave interface.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/dma/qcom/Kconfig | 10 +
drivers/dma/qcom/hidma.c | 744 +++
drivers/dma/qcom/hidma.h | 160 ++
3 files changed, 914 insertions(+)
create mode 100644 drivers/dma/qcom/hidma.c
create mode 100644 drivers/dma/qcom/hidma.h
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index ebe5b8c..5588e1c 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -17,3 +17,13 @@ config QCOM_HIDMA_MGMT
start managing the channels. In a virtualized environment,
the guest OS would run QCOM_HIDMA channel driver and the
hypervisor would run the QCOM_HIDMA_MGMT management driver.
+
+config QCOM_HIDMA
+ tristate "Qualcomm Technologies HIDMA Channel support"
+ select DMA_ENGINE
+ help
+ Enable support for the Qualcomm Technologies HIDMA controller.
+ The HIDMA controller supports optimized buffer copies
+ (user to kernel, kernel to kernel, etc.). It only supports
+ memcpy interface. The core is not intended for general
+ purpose slave DMA.
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
new file mode 100644
index 000..f8960f1
--- /dev/null
+++ b/drivers/dma/qcom/hidma.c
@@ -0,0 +1,744 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine interface
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
+ * Copyright (C) Semihalf 2009
+ * Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2014
+ *
+ * Written by Piotr Ziecik <ko...@semihalf.com>. Hardware description
+ * (defines, structures and comments) was taken from MPC5121 DMA driver
+ * written by Hongjun Chen <hong-jun.c...@freescale.com>.
+ *
+ * Approved as OSADL project by a majority of OSADL members and funded
+ * by OSADL membership fees in 2009; for details see www.osadl.org.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * The full GNU General Public License is included in this distribution in the
+ * file called COPYING.
+ */
+
+/* Linux Foundation elects GPLv2 license only. */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../dmaengine.h"
+#include "hidma.h"
+
+/*
+ * Default idle time is 2 seconds. This parameter can
+ * be overridden by changing the following
+ * /sys/bus/platform/devices/QCOM8061:/power/autosuspend_delay_ms
+ * during kernel boot.
+ */
+#define HIDMA_AUTOSUSPEND_TIMEOUT 2000
+#define HIDMA_ERR_INFO_SW 0xFF
+#define HIDMA_ERR_CODE_UNEXPECTED_TERMINATE0x0
+
+static inline struct hidma_dev *to_hidma_dev(struct dma_device *dmadev)
+{
+ return container_of(dmadev, struct hidma_dev, ddev);
+}
+
+static inline
+struct hidma_dev *to_hidma_dev_from_lldev(struct hidma_lldev **_lldevp)
+{
+ return container_of(_lldevp, struct hidma_dev, lldev);
+}
+
+static inline struct hidma_chan *to_hidma_chan(struct dma_chan *dmach)
+{
+ return container_of(dmach, struct hidma_chan, chan);
+}
+
+static inline
+struct hidma_desc *to_hidma_desc(struct dma_async_tx_descriptor *t)
+{
+ return container_of(t, struct hidma_desc, desc);
+}
+
+static void hidma_free(struct hidma_dev *dmadev)
+{
+ INIT_LIST_HEAD(>ddev.channels);
+}
+
+static unsigned int nr_desc_prm;
+module_param(nr_desc_prm, uint, 0644);
+MODULE_PARM_DESC(nr_desc_prm, "number of descriptors (default: 0)");
+
+#define HIDMA_MAX_CHANNELS 64
+static int channel_idx[HIDMA_MAX_CHANNELS] = {
+
[PATCH V11 2/7] dma: hidma: Add Device Tree support
Add documentation for the Qualcomm Technologies HIDMA driver.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
Acked-by: Rob Herring <r...@kernel.org>
---
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 79 ++
1 file changed, 79 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
new file mode 100644
index 000..0e6ed1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -0,0 +1,79 @@
+Qualcomm Technologies HIDMA Management interface
+
+Qualcomm Technologies HIDMA is a high speed DMA device. It only supports
+memcpy and memset capabilities. It has been designed for virtualized
+environments.
+
+Each HIDMA HW instance consists of multiple DMA channels. These channels
+share the same bandwidth. The bandwidth utilization can be parititioned
+among channels based on the priority and weight assignments.
+
+There are only two priority levels and 15 weigh assignments possible.
+
+Other parameters here determine how much of the system bus this HIDMA
+instance can use like maximum read/write request and and number of bytes to
+read/write in a single burst.
+
+Main node required properties:
+- compatible: "qcom,hidma-mgmt-1.0";
+- reg: Address range for DMA device
+- dma-channels: Number of channels supported by this DMA controller.
+- max-write-burst-bytes: Maximum write burst in bytes. A memcpy requested is
+ fragmented to multiples of this amount.
+- max-read-burst-bytes: Maximum read burst in bytes. A memcpy request is
+ fragmented to multiples of this amount.
+- max-write-transactions: Maximum write transactions to perform in a burst
+- max-read-transactions: Maximum read transactions to perform in a burst
+- channel-reset-timeout-cycles: Channel reset timeout in cycles for this SOC.
+
+Sub-nodes:
+
+HIDMA has one or more DMA channels that are used to move data from one
+memory location to another.
+
+Each DMA channel is described as a sub-node under the management object.
+When a transfer channel is given to the guest operating system, only the
channel
+object is created. The drivers have support for both flat and hierarchical
+configuration.
+
+Required properties:
+- compatible: must contain "qcom,hidma-1.0"
+- reg: Addresses for the transfer and event channel
+- interrupts: Should contain the event interrupt
+- desc-count: Number of asynchronous requests this channel can handle
+- channel-index: The HW event channel completions will be delivered.
+
+Example:
+
+Hypervisor OS configuration:
+
+ hidma-mgmt@f9984000 = {
+ compatible = "qcom,hidma-mgmt-1.0";
+ reg = <0xf9984000 0x15000>;
+ dma-channels = <6>;
+ max-write-burst-bytes = <1024>;
+ max-read-burst-bytes = <1024>;
+ max-write-transactions = <31>;
+ max-read-transactions = <31>;
+ channel-reset-timeout-cycles = <0x500>;
+
+ hidma_24: dma-controller@0x5c05 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c05 0x0 0x1000>,
+ <0 0x5c0b 0x0 0x1000>;
+ interrupts = <0 389 0>;
+ desc-count = <10>;
+ channel-index = <4>;
+ };
+ };
+
+Guest OS configuration:
+
+ hidma_24: dma-controller@0x5c05 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c05 0x0 0x1000>,
+ <0 0x5c0b 0x0 0x1000>;
+ interrupts = <0 389 0>;
+ desc-count = <10>;
+ channel-index = <4>;
+ };
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V11 0/7] dma: add Qualcomm Technologies HIDMA driver
On 1/3/2016 10:36 PM, Vinod Koul wrote: > On Sun, Jan 03, 2016 at 07:09:23PM -0500, Sinan Kaya wrote: >> Hi Vinod, >> >>> >> >> Can I have your ACK on your series if you are OK? > > Why ACK, shouldn't this be merged thru dmaengine tree? I would need ack on > DT patches first :) > You are right about merge. I was interested in to see if you had any outstanding questions. I know I addressed your tx_status question. Mark, Arnd; Can I have your ack for the series if you are OK? I think we have beaten the patches enough. Sinan -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V10 7/7] dma: qcom_hidma: add support for object hierarchy
On 12/19/2015 1:37 PM, Andy Shevchenko wrote:
> On Thu, Dec 17, 2015 at 7:01 PM, Sinan Kaya <ok...@codeaurora.org> wrote:
>> In order to create a relationship model between the channels and the
>> management object, we are adding support for object hierarchy to the
>> drivers. This patch simplifies the userspace application development.
>> We will not have to traverse different firmware paths based on device
>> tree or ACPI baed kernels.
>>
>> No matter what flavor of kernel is used, objects will be represented as
>> platform devices.
>>
>> The new layout is as follows:
>>
>> hidmam_10: hidma-mgmt@0x5A00 {
>> compatible = "qcom,hidma-mgmt-1.0";
>> ...
>>
>> hidma_10: hidma@0x5a01 {
>> compatible = "qcom,hidma-1.0";
>> ...
>> }
>> }
>>
>> The hidma_mgmt_init detects each instance of the hidma-mgmt-1.0 objects
>> in device tree and calls into the channel driver to create platform devices
>> for each child of the management object.
>>
>> Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
>
>
>> +What: /sys/devices/platform/hidma-*/chid
>> + /sys/devices/platform/QCOM8061:*/chid
>> +Date: Dec 2015
>> +KernelVersion: 4.4
>> +Contact: "Sinan Kaya <ok...@cudeaurora.org>"
>> +Description:
>> + Contains the ID of the channel within the HIDMA instance.
>> + It is used to associate a given HIDMA channel with the
>> + priority and weight calls in the management interface.
>
>> -module_platform_driver(hidma_mgmt_driver);
>> +#ifdef CONFIG_OF
>> +static int object_counter;
>> +
>> +static int __init hidma_mgmt_of_populate_channels(struct device_node *np)
>> +{
>> + struct platform_device *pdev_parent = of_find_device_by_node(np);
>> + struct platform_device_info pdevinfo;
>> + struct of_phandle_args out_irq;
>> + struct device_node *child;
>> + struct resource *res;
>> + const __be32 *cell;
>
> Always BE ?
Yes, as Timur indicated device tree is big endian all the time.
>
>> + int ret = 0, size, i, num;
>> + u64 addr, addr_size;
>
> resource_size_t
These values are read from the device tree blob using of_read_number function.
of_read_number
returns a u64.
>
>> +
>> + for_each_available_child_of_node(np, child) {
>> + int iter = 0;
>> +
>> + cell = of_get_property(child, "reg", );
>> + if (!cell) {
>> + ret = -EINVAL;
>> + goto out;
>> + }
>> +
>> + size /= (sizeof(*cell));
>
> Redundant parens. I think it might be good to use common sense for
> operator precedence, here is a radical example of ignoring it. And
> this is not the first case.
Removed. Note that I copied most of this function from another driver.
>
>> + num = size /
>> + (of_n_addr_cells(child) + of_n_size_cells(child)) +
>> 1;
>> +
>> + /* allocate a resource array */
>> + res = kcalloc(num, sizeof(*res), GFP_KERNEL);
>> + if (!res) {
>> + ret = -ENOMEM;
>> + goto out;
>> + }
>> +
>> + /* read each reg value */
>> + i = 0;
>> + while (i < size) {
>> + addr = of_read_number([i],
>> + of_n_addr_cells(child));
>> + i += of_n_addr_cells(child);
>> +
>> + addr_size = of_read_number([i],
>> + of_n_size_cells(child));
>> + i += of_n_size_cells(child);
>> +
>> + res[iter].start = addr;
>> + res[iter].end = res[iter].start + addr_size - 1;
>> + res[iter].flags = IORESOURCE_MEM;
>
> res->start = …
> …
> res++;
ok
>
>> + iter++;
>> + }
>> +
>> + ret = of_irq_parse_one(child, 0, _irq);
>> + if (ret)
>> + goto out;
>> +
>> + res[iter].start = irq_create_of_mapping(_irq);
>> + res[iter].name = "hidma
[PATCH V10 0/7] dma: add Qualcomm Technologies HIDMA driver
The Qualcomm Technologies HIDMA device has been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design.
1. HIDMA Management driver
2. HIDMA Channel driver
Each HIDMA HW consists of multiple channels. These channels
share some set of common parameters. These parameters are
initialized by the management driver during power up.
Same management driver is used for monitoring the execution
of the channels. Management driver can change the performance
behavior dynamically such as bandwidth allocation and
prioritization in the future.
The management driver is executed in hypervisor context and
is the main management entity for all channels provided by
the device.
Changes from V9: (https://lkml.org/lkml/2015/12/11/584)
* none
Changes from V9: (https://lkml.org/lkml/2015/12/11/585)
* split device tree documentation from code
* correct syntax error in device tree documentation
* describe max value of the weight
* document that array and weight attributes are array
* add object hierarchy support
* move sysfs priority and weight files into chanops directory.
Changes from V9: (https://lkml.org/lkml/2015/12/11/588)
* add object hierarchy support
* rename event-channel to channel-index
* create a sysfs entry for channel-index
* add pm_runtime_get/sync around hidma_ll_isenabled
Changes from V9: (https://lkml.org/lkml/2015/12/11/586)
* rename TRE chidx to idx to not mix with the channel id.
Changes from V9: (https://lkml.org/lkml/2015/12/11/587)
* none
Sinan Kaya (7):
dma: qcom_bam_dma: move to qcom directory
dma: hidma: Add Device Tree support
dma: add Qualcomm Technologies HIDMA management driver
dma: add Qualcomm Technologies HIDMA channel driver
dma: qcom_hidma: implement lower level hardware interface
dma: qcom_hidma: add debugfs hooks
dma: qcom_hidma: add support for object hierarchy
Documentation/ABI/testing/sysfs-platform-hidma | 9 +
.../ABI/testing/sysfs-platform-hidma-mgmt | 97 +++
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 79 ++
drivers/dma/Kconfig| 11 +-
drivers/dma/Makefile | 2 +-
drivers/dma/qcom/Kconfig | 29 +
drivers/dma/qcom/Makefile | 4 +
drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 4 +-
drivers/dma/qcom/hidma.c | 868 +++
drivers/dma/qcom/hidma.h | 163
drivers/dma/qcom/hidma_dbg.c | 219 +
drivers/dma/qcom/hidma_ll.c| 927 +
drivers/dma/qcom/hidma_mgmt.c | 317 +++
drivers/dma/qcom/hidma_mgmt.h | 39 +
drivers/dma/qcom/hidma_mgmt_sys.c | 295 +++
15 files changed, 3051 insertions(+), 12 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma
create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
create mode 100644 drivers/dma/qcom/Kconfig
create mode 100644 drivers/dma/qcom/Makefile
rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
create mode 100644 drivers/dma/qcom/hidma.c
create mode 100644 drivers/dma/qcom/hidma.h
create mode 100644 drivers/dma/qcom/hidma_dbg.c
create mode 100644 drivers/dma/qcom/hidma_ll.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.h
create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V10 2/7] dma: hidma: Add Device Tree support
Add documentation for the Qualcomm Technologies HIDMA driver.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 79 ++
1 file changed, 79 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
new file mode 100644
index 000..0e6ed1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -0,0 +1,79 @@
+Qualcomm Technologies HIDMA Management interface
+
+Qualcomm Technologies HIDMA is a high speed DMA device. It only supports
+memcpy and memset capabilities. It has been designed for virtualized
+environments.
+
+Each HIDMA HW instance consists of multiple DMA channels. These channels
+share the same bandwidth. The bandwidth utilization can be parititioned
+among channels based on the priority and weight assignments.
+
+There are only two priority levels and 15 weigh assignments possible.
+
+Other parameters here determine how much of the system bus this HIDMA
+instance can use like maximum read/write request and and number of bytes to
+read/write in a single burst.
+
+Main node required properties:
+- compatible: "qcom,hidma-mgmt-1.0";
+- reg: Address range for DMA device
+- dma-channels: Number of channels supported by this DMA controller.
+- max-write-burst-bytes: Maximum write burst in bytes. A memcpy requested is
+ fragmented to multiples of this amount.
+- max-read-burst-bytes: Maximum read burst in bytes. A memcpy request is
+ fragmented to multiples of this amount.
+- max-write-transactions: Maximum write transactions to perform in a burst
+- max-read-transactions: Maximum read transactions to perform in a burst
+- channel-reset-timeout-cycles: Channel reset timeout in cycles for this SOC.
+
+Sub-nodes:
+
+HIDMA has one or more DMA channels that are used to move data from one
+memory location to another.
+
+Each DMA channel is described as a sub-node under the management object.
+When a transfer channel is given to the guest operating system, only the
channel
+object is created. The drivers have support for both flat and hierarchical
+configuration.
+
+Required properties:
+- compatible: must contain "qcom,hidma-1.0"
+- reg: Addresses for the transfer and event channel
+- interrupts: Should contain the event interrupt
+- desc-count: Number of asynchronous requests this channel can handle
+- channel-index: The HW event channel completions will be delivered.
+
+Example:
+
+Hypervisor OS configuration:
+
+ hidma-mgmt@f9984000 = {
+ compatible = "qcom,hidma-mgmt-1.0";
+ reg = <0xf9984000 0x15000>;
+ dma-channels = <6>;
+ max-write-burst-bytes = <1024>;
+ max-read-burst-bytes = <1024>;
+ max-write-transactions = <31>;
+ max-read-transactions = <31>;
+ channel-reset-timeout-cycles = <0x500>;
+
+ hidma_24: dma-controller@0x5c05 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c05 0x0 0x1000>,
+ <0 0x5c0b 0x0 0x1000>;
+ interrupts = <0 389 0>;
+ desc-count = <10>;
+ channel-index = <4>;
+ };
+ };
+
+Guest OS configuration:
+
+ hidma_24: dma-controller@0x5c05 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c05 0x0 0x1000>,
+ <0 0x5c0b 0x0 0x1000>;
+ interrupts = <0 389 0>;
+ desc-count = <10>;
+ channel-index = <4>;
+ };
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V10 6/7] dma: qcom_hidma: add debugfs hooks
Add debugfs hooks for debugging the execution behavior of the DMA
channel. The debugfs hooks get initialized by the probe function and
uninitialized by the remove function.
A stats file is created in debugfs. The stats file will show the
information about each HIDMA channel as well as each asynchronous job
queued and completed at a given time.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/dma/qcom/Makefile| 2 +-
drivers/dma/qcom/hidma.c | 3 +
drivers/dma/qcom/hidma.h | 2 +
drivers/dma/qcom/hidma_dbg.c | 219 +++
4 files changed, 225 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma/qcom/hidma_dbg.c
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index 6bf9267..4bfc38b 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -2,4 +2,4 @@ obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
obj-$(CONFIG_QCOM_HIDMA_MGMT) += hdma_mgmt.o
hdma_mgmt-objs := hidma_mgmt.o hidma_mgmt_sys.o
obj-$(CONFIG_QCOM_HIDMA) += hdma.o
-hdma-objs:= hidma_ll.o hidma.o
+hdma-objs:= hidma_ll.o hidma.o hidma_dbg.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index f8960f1..833db9e 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -681,6 +681,7 @@ static int hidma_probe(struct platform_device *pdev)
dmadev->irq = chirq;
tasklet_init(>task, hidma_issue_task, (unsigned long)dmadev);
+ hidma_debug_init(dmadev);
dev_info(>dev, "HI-DMA engine driver registration complete\n");
platform_set_drvdata(pdev, dmadev);
pm_runtime_mark_last_busy(dmadev->ddev.dev);
@@ -689,6 +690,7 @@ static int hidma_probe(struct platform_device *pdev)
return 0;
uninit:
+ hidma_debug_uninit(dmadev);
hidma_ll_uninit(dmadev->lldev);
dmafree:
if (dmadev)
@@ -706,6 +708,7 @@ static int hidma_remove(struct platform_device *pdev)
pm_runtime_get_sync(dmadev->ddev.dev);
dma_async_device_unregister(>ddev);
devm_free_irq(dmadev->ddev.dev, dmadev->irq, dmadev->lldev);
+ hidma_debug_uninit(dmadev);
hidma_ll_uninit(dmadev->lldev);
hidma_free(dmadev);
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index 1e09d7c..c6b3ae0 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -157,4 +157,6 @@ int hidma_ll_uninit(struct hidma_lldev *llhndl);
irqreturn_t hidma_ll_inthandler(int irq, void *arg);
void hidma_cleanup_pending_tre(struct hidma_lldev *llhndl, u8 err_info,
u8 err_code);
+int hidma_debug_init(struct hidma_dev *dmadev);
+void hidma_debug_uninit(struct hidma_dev *dmadev);
#endif
diff --git a/drivers/dma/qcom/hidma_dbg.c b/drivers/dma/qcom/hidma_dbg.c
new file mode 100644
index 000..fe35002
--- /dev/null
+++ b/drivers/dma/qcom/hidma_dbg.c
@@ -0,0 +1,219 @@
+/*
+ * Qualcomm Technologies HIDMA debug file
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "hidma.h"
+
+static void hidma_ll_chstats(struct seq_file *s, void *llhndl, u32 tre_ch)
+{
+ struct hidma_lldev *lldev = llhndl;
+ struct hidma_tre *tre;
+ u32 length;
+ dma_addr_t src_start;
+ dma_addr_t dest_start;
+ u32 *tre_local;
+
+ if (tre_ch >= lldev->nr_tres) {
+ dev_err(lldev->dev, "invalid TRE number in chstats:%d", tre_ch);
+ return;
+ }
+ tre = >trepool[tre_ch];
+ seq_printf(s, "--Channel %d -\n", tre_ch);
+ seq_printf(s, "allocated=%d\n", atomic_read(>allocated));
+ seq_printf(s, "queued = 0x%x\n", tre->queued);
+ seq_printf(s, "err_info = 0x%x\n",
+ lldev->tx_status_list[tre->idx].err_info);
+ seq_printf(s, "err_code = 0x%x\n",
+ lldev->tx_status_list[tre->idx].err_code);
+ seq_printf(s, "status = 0x%x\n", tre->status);
+ seq_printf(s, "idx = 0x%x\n", tre->idx);
+ seq_printf(s, "dma_sig = 0x%x\n", tre->dma_sig);
+ seq_printf(s, "dev_name=%s\n", tre->dev_name);
+ seq_printf(s, "callback=%p\n", tre->callback);
+ seq_printf(s, "data=%p\n", tre->data);
+ seq_printf(s, "tre_index = 0
[PATCH V10 3/7] dma: add Qualcomm Technologies HIDMA management driver
The Qualcomm Technologies HIDMA device has been designed to support virtualization technology. The driver has been divided into two to follow the hardware design. 1. HIDMA Management driver 2. HIDMA Channel driver Each HIDMA HW consists of multiple channels. These channels share some set of common parameters. These parameters are initialized by the management driver during power up. Same management driver is used for monitoring the execution of the channels. Management driver can change the performance behavior dynamically such as bandwidth allocation and prioritization. The management driver is executed in hypervisor context and is the main management entity for all channels provided by the device. Signed-off-by: Sinan Kaya <ok...@codeaurora.org> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> --- .../ABI/testing/sysfs-platform-hidma-mgmt | 97 +++ drivers/dma/qcom/Kconfig | 11 + drivers/dma/qcom/Makefile | 2 + drivers/dma/qcom/hidma_mgmt.c | 302 + drivers/dma/qcom/hidma_mgmt.h | 39 +++ drivers/dma/qcom/hidma_mgmt_sys.c | 295 6 files changed, 746 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt create mode 100644 drivers/dma/qcom/hidma_mgmt.c create mode 100644 drivers/dma/qcom/hidma_mgmt.h create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c diff --git a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt new file mode 100644 index 000..c2fb5d0 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt @@ -0,0 +1,97 @@ +What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority + /sys/devices/platform/QCOM8060:*/chanops/chan*/priority +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains either 0 or 1 and indicates if the DMA channel is a + low priority (0) or high priority (1) channel. + +What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/weight + /sys/devices/platform/QCOM8060:*/chanops/chan*/weight +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains 0..15 and indicates the weight of the channel among + equal priority channels during round robin scheduling. + +What: /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles + /sys/devices/platform/QCOM8060:*/chreset_timeout_cycles +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains the platform specific cycle value to wait after a + reset command is issued. If the value is chosen too short, + then the HW will issue a reset failure interrupt. The value + is platform specific and should not be changed without + consultance. + +What: /sys/devices/platform/hidma-mgmt*/dma_channels + /sys/devices/platform/QCOM8060:*/dma_channels +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains the number of dma channels supported by one instance + of HIDMA hardware. The value may change from chip to chip. + +What: /sys/devices/platform/hidma-mgmt*/hw_version_major + /sys/devices/platform/QCOM8060:*/hw_version_major +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Version number major for the hardware. + +What: /sys/devices/platform/hidma-mgmt*/hw_version_minor + /sys/devices/platform/QCOM8060:*/hw_version_minor +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Version number minor for the hardware. + +What: /sys/devices/platform/hidma-mgmt*/max_rd_xactions + /sys/devices/platform/QCOM8060:*/max_rd_xactions +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains a value between 0 and 31. Maximum number of + read transactions that can be issued back to back. + Choosing a higher number gives better performance but + can also cause performance reduction to other peripherals + sharing the same bus. + +What: /sys/devices/platform/hidma-mgmt*/max_read_request + /sys/devices/platform/QCOM8060:*/max_read_request +Date: Nov 2015 +KernelVersion: 4.4
[PATCH V10 5/7] dma: qcom_hidma: implement lower level hardware interface
This patch implements the hardware hooks for the HIDMA channel driver.
The main functions of interest are:
- hidma_ll_init
- hidma_ll_request
- hidma_ll_queue_request
- hidma_ll_hw_start
OS layer calls the hidma_ll_init function during probe to set up the
hardware. At this moment, the number of supported descriptors are also
given. On each request, a descriptor is allocated from the free pool and
filled in with the transfer parameters. Multiple requests can be queued
into the hardware via the OS interface. When client is ready for requests
to be executed, start method is called.
Completions are delivered via callbacks via tasklet.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/dma/qcom/Makefile | 2 +
drivers/dma/qcom/hidma.h| 2 +-
drivers/dma/qcom/hidma_ll.c | 927
3 files changed, 930 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma/qcom/hidma_ll.c
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index bfea699..6bf9267 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,3 +1,5 @@
obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
obj-$(CONFIG_QCOM_HIDMA_MGMT) += hdma_mgmt.o
hdma_mgmt-objs := hidma_mgmt.o hidma_mgmt_sys.o
+obj-$(CONFIG_QCOM_HIDMA) += hdma.o
+hdma-objs:= hidma_ll.o hidma.o
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index 231e306..1e09d7c 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -37,7 +37,7 @@ struct hidma_tre {
atomic_t allocated; /* if this channel is allocated */
bool queued;/* flag whether this is pending */
u16 status; /* status */
- u32 chidx; /* index of the tre */
+ u32 idx;/* index of the tre */
u32 dma_sig;/* signature of the tre */
const char *dev_name; /* name of the device */
void (*callback)(void *data); /* requester callback */
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
new file mode 100644
index 000..0cd8d70
--- /dev/null
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -0,0 +1,927 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine low level code
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "hidma.h"
+
+#define EVRE_SIZE 16 /* each EVRE is 16 bytes */
+
+#define TRCA_CTRLSTS_OFFSET0x0
+#define TRCA_RING_LOW_OFFSET 0x8
+#define TRCA_RING_HIGH_OFFSET 0xC
+#define TRCA_RING_LEN_OFFSET 0x10
+#define TRCA_READ_PTR_OFFSET 0x18
+#define TRCA_WRITE_PTR_OFFSET 0x20
+#define TRCA_DOORBELL_OFFSET 0x400
+
+#define EVCA_CTRLSTS_OFFSET0x0
+#define EVCA_INTCTRL_OFFSET0x4
+#define EVCA_RING_LOW_OFFSET 0x8
+#define EVCA_RING_HIGH_OFFSET 0xC
+#define EVCA_RING_LEN_OFFSET 0x10
+#define EVCA_READ_PTR_OFFSET 0x18
+#define EVCA_WRITE_PTR_OFFSET 0x20
+#define EVCA_DOORBELL_OFFSET 0x400
+
+#define EVCA_IRQ_STAT_OFFSET 0x100
+#define EVCA_IRQ_CLR_OFFSET0x108
+#define EVCA_IRQ_EN_OFFSET 0x110
+
+#define EVRE_CFG_IDX 0
+#define EVRE_LEN_IDX 1
+#define EVRE_DEST_LOW_IDX 2
+#define EVRE_DEST_HI_IDX 3
+
+#define EVRE_ERRINFO_BIT_POS 24
+#define EVRE_CODE_BIT_POS 28
+
+#define EVRE_ERRINFO_MASK GENMASK(3, 0)
+#define EVRE_CODE_MASK GENMASK(3, 0)
+
+#define CH_CONTROL_MASKGENMASK(7, 0)
+#define CH_STATE_MASK GENMASK(7, 0)
+#define CH_STATE_BIT_POS 0x8
+
+#define IRQ_EV_CH_EOB_IRQ_BIT_POS 0
+#define IRQ_EV_CH_WR_RESP_BIT_POS 1
+#define IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS 9
+#define IRQ_TR_CH_DATA_RD_ER_BIT_POS 10
+#define IRQ_TR_CH_DATA_WR_ER_BIT_POS 11
+#define IRQ_TR_CH_INVALID_TRE_BIT_POS 14
+
+#defineENABLE_IRQS (BIT(IRQ_EV_CH_EOB_IRQ_BIT_POS) | \
+ BIT(IRQ_EV_CH_WR_RESP_BIT_POS) | \
+ BIT(IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS)| \
+
[PATCH V10 4/7] dma: add Qualcomm Technologies HIDMA channel driver
This patch adds support for hidma engine. The driver consists of two
logical blocks. The DMA engine interface and the low-level interface.
The hardware only supports memcpy/memset and this driver only support
memcpy interface. HW and driver doesn't support slave interface.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/dma/qcom/Kconfig | 10 +
drivers/dma/qcom/hidma.c | 744 +++
drivers/dma/qcom/hidma.h | 160 ++
3 files changed, 914 insertions(+)
create mode 100644 drivers/dma/qcom/hidma.c
create mode 100644 drivers/dma/qcom/hidma.h
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index ebe5b8c..5588e1c 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -17,3 +17,13 @@ config QCOM_HIDMA_MGMT
start managing the channels. In a virtualized environment,
the guest OS would run QCOM_HIDMA channel driver and the
hypervisor would run the QCOM_HIDMA_MGMT management driver.
+
+config QCOM_HIDMA
+ tristate "Qualcomm Technologies HIDMA Channel support"
+ select DMA_ENGINE
+ help
+ Enable support for the Qualcomm Technologies HIDMA controller.
+ The HIDMA controller supports optimized buffer copies
+ (user to kernel, kernel to kernel, etc.). It only supports
+ memcpy interface. The core is not intended for general
+ purpose slave DMA.
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
new file mode 100644
index 000..f8960f1
--- /dev/null
+++ b/drivers/dma/qcom/hidma.c
@@ -0,0 +1,744 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine interface
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
+ * Copyright (C) Semihalf 2009
+ * Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2014
+ *
+ * Written by Piotr Ziecik <ko...@semihalf.com>. Hardware description
+ * (defines, structures and comments) was taken from MPC5121 DMA driver
+ * written by Hongjun Chen <hong-jun.c...@freescale.com>.
+ *
+ * Approved as OSADL project by a majority of OSADL members and funded
+ * by OSADL membership fees in 2009; for details see www.osadl.org.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * The full GNU General Public License is included in this distribution in the
+ * file called COPYING.
+ */
+
+/* Linux Foundation elects GPLv2 license only. */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../dmaengine.h"
+#include "hidma.h"
+
+/*
+ * Default idle time is 2 seconds. This parameter can
+ * be overridden by changing the following
+ * /sys/bus/platform/devices/QCOM8061:/power/autosuspend_delay_ms
+ * during kernel boot.
+ */
+#define HIDMA_AUTOSUSPEND_TIMEOUT 2000
+#define HIDMA_ERR_INFO_SW 0xFF
+#define HIDMA_ERR_CODE_UNEXPECTED_TERMINATE0x0
+
+static inline struct hidma_dev *to_hidma_dev(struct dma_device *dmadev)
+{
+ return container_of(dmadev, struct hidma_dev, ddev);
+}
+
+static inline
+struct hidma_dev *to_hidma_dev_from_lldev(struct hidma_lldev **_lldevp)
+{
+ return container_of(_lldevp, struct hidma_dev, lldev);
+}
+
+static inline struct hidma_chan *to_hidma_chan(struct dma_chan *dmach)
+{
+ return container_of(dmach, struct hidma_chan, chan);
+}
+
+static inline
+struct hidma_desc *to_hidma_desc(struct dma_async_tx_descriptor *t)
+{
+ return container_of(t, struct hidma_desc, desc);
+}
+
+static void hidma_free(struct hidma_dev *dmadev)
+{
+ INIT_LIST_HEAD(>ddev.channels);
+}
+
+static unsigned int nr_desc_prm;
+module_param(nr_desc_prm, uint, 0644);
+MODULE_PARM_DESC(nr_desc_prm, "number of descriptors (default: 0)");
+
+#define HIDMA_MAX_CHANNELS 64
+static int channel_idx[HIDMA_MAX_CHANNELS] = {
+
[PATCH V10 7/7] dma: qcom_hidma: add support for object hierarchy
In order to create a relationship model between the channels and the
management object, we are adding support for object hierarchy to the
drivers. This patch simplifies the userspace application development.
We will not have to traverse different firmware paths based on device
tree or ACPI baed kernels.
No matter what flavor of kernel is used, objects will be represented as
platform devices.
The new layout is as follows:
hidmam_10: hidma-mgmt@0x5A00 {
compatible = "qcom,hidma-mgmt-1.0";
...
hidma_10: hidma@0x5a01 {
compatible = "qcom,hidma-1.0";
...
}
}
The hidma_mgmt_init detects each instance of the hidma-mgmt-1.0 objects
in device tree and calls into the channel driver to create platform devices
for each child of the management object.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
Documentation/ABI/testing/sysfs-platform-hidma | 9 +++
drivers/dma/qcom/hidma.c | 39 +-
drivers/dma/qcom/hidma_mgmt.c | 103 -
3 files changed, 147 insertions(+), 4 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma
diff --git a/Documentation/ABI/testing/sysfs-platform-hidma
b/Documentation/ABI/testing/sysfs-platform-hidma
new file mode 100644
index 000..d364415
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-hidma
@@ -0,0 +1,9 @@
+What: /sys/devices/platform/hidma-*/chid
+ /sys/devices/platform/QCOM8061:*/chid
+Date: Dec 2015
+KernelVersion: 4.4
+Contact: "Sinan Kaya <ok...@cudeaurora.org>"
+Description:
+ Contains the ID of the channel within the HIDMA instance.
+ It is used to associate a given HIDMA channel with the
+ priority and weight calls in the management interface.
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index 833db9e..ac20bdb 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -549,6 +549,43 @@ static irqreturn_t hidma_chirq_handler(int chirq, void
*arg)
return hidma_ll_inthandler(chirq, lldev);
}
+static ssize_t hidma_show_values(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct hidma_dev *mdev = platform_get_drvdata(pdev);
+
+ buf[0] = 0;
+
+ if (strcmp(attr->attr.name, "chid") == 0)
+ sprintf(buf, "%d\n", mdev->chidx);
+
+ return strlen(buf);
+}
+
+static int hidma_create_sysfs_entry(struct hidma_dev *dev, char *name,
+ int mode)
+{
+ struct device_attribute *attrs;
+ char *name_copy;
+
+ attrs = devm_kmalloc(dev->ddev.dev, sizeof(struct device_attribute),
+GFP_KERNEL);
+ if (!attrs)
+ return -ENOMEM;
+
+ name_copy = devm_kstrdup(dev->ddev.dev, name, GFP_KERNEL);
+ if (!name_copy)
+ return -ENOMEM;
+
+ attrs->attr.name = name_copy;
+ attrs->attr.mode = mode;
+ attrs->show = hidma_show_values;
+ sysfs_attr_init(>attr);
+
+ return device_create_file(dev->ddev.dev, attrs);
+}
+
static int hidma_probe(struct platform_device *pdev)
{
struct hidma_dev *dmadev;
@@ -682,6 +719,7 @@ static int hidma_probe(struct platform_device *pdev)
dmadev->irq = chirq;
tasklet_init(>task, hidma_issue_task, (unsigned long)dmadev);
hidma_debug_init(dmadev);
+ hidma_create_sysfs_entry(dmadev, "chid", S_IRUGO);
dev_info(>dev, "HI-DMA engine driver registration complete\n");
platform_set_drvdata(pdev, dmadev);
pm_runtime_mark_last_busy(dmadev->ddev.dev);
@@ -730,7 +768,6 @@ static const struct of_device_id hidma_match[] = {
{.compatible = "qcom,hidma-1.0",},
{},
};
-
MODULE_DEVICE_TABLE(of, hidma_match);
static struct platform_driver hidma_driver = {
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index ef491b8..d387338 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -17,13 +17,14 @@
#include
#include
#include
-#include
-#include
+#include
+#include
#include
#include
#include
#include
#include
+#include
#include "hidma_mgmt.h"
@@ -298,5 +299,101 @@ static struct platform_driver hidma_mgmt_driver = {
},
};
-module_platform_driver(hidma_mgmt_driver);
+#ifdef CONFIG_OF
+static int object_counter;
+
+static int __init hidma_mgmt_of_populate_channels(struct device_node *np)
+{
+ struct platform_device *pdev_parent = of_find_device_by_node(np);
+ struct platform_device_info pdevinfo;
+ struct of_phandle_args out_irq;
+ struct
Re: [PATCH V7 3/3] dma: add Qualcomm Technologies HIDMA channel driver
On 12/11/2015 4:35 AM, Vinod Koul wrote: > On Thu, Dec 10, 2015 at 03:10:48PM -0500, Sinan Kaya wrote: >> On 12/5/2015 3:00 AM, Vinod Koul wrote: >>> On Wed, Dec 02, 2015 at 02:04:05PM -0500, Sinan Kaya wrote: >>>>>>> You are missing the point. Channel can be paused, yes but the descriptor >>>>>>> is in queue and is not paused. The descriptor running is paused, yes. >>>>>>> There is subtle difference between these >>>>> I'll follow your recommendation. PAUSE for the currently active >>>>> descriptor and DMA_IN_PROGRESS for the rest. >>>>> >>>> >>>> I'm now confused. >>>> >>>> I looked at several DMA driver implementations. >>>> >>>> 1. They call dma_cookie_status function to see if the job is done. >>>> 2. If done, they return right ahead. >>>> 3. Otherwise, dma_cookie_status returns DMA_IN_PROGRESS. >>>> 4. Next the code checks if the channel is paused and return value is >>>> DMA_IN_PROGRESS. The code changes return code to DMA_PAUSED. >>>> >>>> Whereas, I was returning paused first before even checking if the >>>> descriptor is done. Are you OK with the sequence 1..4 above? >>> >>> Yes am okay with this with slight change in 4. >>> >>> You should set to PAUSED only for current descriptor and not for the ones in >>> queue >>> >> >> OK. I'll post a new version with this. Is there any other comment that >> needed to be addressed? > > Looks okay to me > Vinod, Mark; Just posted a new series (V10) https://lkml.org/lkml/2015/12/17/447 that addresses Mark Rutland and your concern. Can you please review the series and queue for inclusion if you are OK? Sinan -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V9 2/5] dma: add Qualcomm Technologies HIDMA management driver
management object.
>>>>> hidma {
>>>>> compatible - "qcom,hidma-1.0";
>>>>>
>>>>> /* OPTIONAL management interface registers */
>>>>> reg = < ... ... >;
>>>>>
>>>>> ...
>>>>>
>>>>> channel0 {
>>>>> compatible = "qcom,
>>>>> reg = < ... ... >;
>>>>>
>>>>> ...
>>>>> };
>>>>>
>>>>> ...
>>>>> };
>>
>> This seems to have worked without requiring any work from me.
>>
Here is something I don't understand why and I could get some help from
DT experts.
When I have ACPI as follows
device(mgmt)
{
device(channel0)
{
}
}
The channel0 driver gets automatically probed by the OS.
When I have device tree based structure as follows, hidma_00 doesn't get
probed.
hidmam_00: hidma-mgmt@0x5800 {
compatible = "qcom,hidma_mgmt-1.0";
hidma_00: hidma@0x5801 {
compatible = "qcom,hidma-1.0";
}
}
If I put them seperately, it works
hidma_00: hidma@0x5801 {
compatible = "qcom,hidma-1.0";
}
hidmam_00: hidma-mgmt@0x5800 {
compatible = "qcom,hidma_mgmt-1.0";
}
Wondering If there is any mechanism in DT, I could have the same probing
behavior as ACPI? I hate calling the of_find_matching_node functions and
locate the child object. Then, create a platform device. This seems a
lot of hand-crafting to me. I don't have any OF/ACPI specific code in my
driver. I want to avoid it if there is a way.
>> I need to associate sysfs next.
>
> Ok. I look forward to seeing those patches.
>
OK. I'll post it as soon as I figure out DT/ACPI behavior differences.
> Thanks,
> Mark.
>
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V9 3/5] dma: add Qualcomm Technologies HIDMA channel driver
This patch adds support for hidma engine. The driver consists of two
logical blocks. The DMA engine interface and the low-level interface.
The hardware only supports memcpy/memset and this driver only support
memcpy interface. HW and driver doesn't support slave interface.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
.../devicetree/bindings/dma/qcom_hidma.txt | 18 +
drivers/dma/qcom/Kconfig | 10 +
drivers/dma/qcom/hidma.c | 740 +
drivers/dma/qcom/hidma.h | 160 +
4 files changed, 928 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
create mode 100644 drivers/dma/qcom/hidma.c
create mode 100644 drivers/dma/qcom/hidma.h
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma.txt
b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
new file mode 100644
index 000..d18c8fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
@@ -0,0 +1,18 @@
+Qualcomm Technologies HIDMA Channel driver
+
+Required properties:
+- compatible: must contain "qcom,hidma-1.0"
+- reg: Addresses for the transfer and event channel
+- interrupts: Should contain the event interrupt
+- desc-count: Number of asynchronous requests this channel can handle
+- event-channel: The HW event channel completions will be delivered.
+Example:
+
+ hidma_24: dma-controller@0x5c05 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c05 0x0 0x1000>,
+ <0 0x5c0b 0x0 0x1000>;
+ interrupts = <0 389 0>;
+ desc-count = <10>;
+ event-channel = <4>;
+ };
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index ebe5b8c..5588e1c 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -17,3 +17,13 @@ config QCOM_HIDMA_MGMT
start managing the channels. In a virtualized environment,
the guest OS would run QCOM_HIDMA channel driver and the
hypervisor would run the QCOM_HIDMA_MGMT management driver.
+
+config QCOM_HIDMA
+ tristate "Qualcomm Technologies HIDMA Channel support"
+ select DMA_ENGINE
+ help
+ Enable support for the Qualcomm Technologies HIDMA controller.
+ The HIDMA controller supports optimized buffer copies
+ (user to kernel, kernel to kernel, etc.). It only supports
+ memcpy interface. The core is not intended for general
+ purpose slave DMA.
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
new file mode 100644
index 000..d2f7e32
--- /dev/null
+++ b/drivers/dma/qcom/hidma.c
@@ -0,0 +1,740 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine interface
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
+ * Copyright (C) Semihalf 2009
+ * Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2014
+ *
+ * Written by Piotr Ziecik <ko...@semihalf.com>. Hardware description
+ * (defines, structures and comments) was taken from MPC5121 DMA driver
+ * written by Hongjun Chen <hong-jun.c...@freescale.com>.
+ *
+ * Approved as OSADL project by a majority of OSADL members and funded
+ * by OSADL membership fees in 2009; for details see www.osadl.org.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * The full GNU General Public License is included in this distribution in the
+ * file called COPYING.
+ */
+
+/* Linux Foundation elects GPLv2 license only. */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../dmaengine.h"
+#include "hidma.h"
+
+/*
+ * Default idle time is 2 seconds. This parameter can
+ * be overridden by changing the following
+ * /s
[PATCH V9 1/5] dma: qcom_bam_dma: move to qcom directory
Creating a QCOM directory for all QCOM DMA source files.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
Reviewed-by: Andy Gtoss <agr...@codeaurora.org>
---
drivers/dma/Kconfig| 11 ++-
drivers/dma/Makefile | 2 +-
drivers/dma/qcom/Kconfig | 8
drivers/dma/qcom/Makefile | 1 +
drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 4 ++--
5 files changed, 14 insertions(+), 12 deletions(-)
create mode 100644 drivers/dma/qcom/Kconfig
create mode 100644 drivers/dma/qcom/Makefile
rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index b458475..47b1b98 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -408,15 +408,6 @@ config PXA_DMA
16 to 32 channels for peripheral to memory or memory to memory
transfers.
-config QCOM_BAM_DMA
- tristate "QCOM BAM DMA support"
- depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
- select DMA_ENGINE
- select DMA_VIRTUAL_CHANNELS
- ---help---
- Enable support for the QCOM BAM DMA controller. This controller
- provides DMA capabilities for a variety of on-chip devices.
-
config SIRF_DMA
tristate "CSR SiRFprimaII/SiRFmarco DMA support"
depends on ARCH_SIRF
@@ -527,6 +518,8 @@ config ZX_DMA
# driver files
source "drivers/dma/bestcomm/Kconfig"
+source "drivers/dma/qcom/Kconfig"
+
source "drivers/dma/dw/Kconfig"
source "drivers/dma/hsu/Kconfig"
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 7711a71..8dba90d 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_PCH_DMA) += pch_dma.o
obj-$(CONFIG_PL330_DMA) += pl330.o
obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
obj-$(CONFIG_PXA_DMA) += pxa_dma.o
-obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
obj-$(CONFIG_RENESAS_DMA) += sh/
obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
@@ -66,4 +65,5 @@ obj-$(CONFIG_TI_EDMA) += edma.o
obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
+obj-y += qcom/
obj-y += xilinx/
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
new file mode 100644
index 000..f17c272
--- /dev/null
+++ b/drivers/dma/qcom/Kconfig
@@ -0,0 +1,8 @@
+config QCOM_BAM_DMA
+ tristate "QCOM BAM DMA support"
+ depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ ---help---
+ Enable support for the QCOM BAM DMA controller. This controller
+ provides DMA capabilities for a variety of on-chip devices.
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
new file mode 100644
index 000..f612ae3
--- /dev/null
+++ b/drivers/dma/qcom/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom/bam_dma.c
similarity index 99%
rename from drivers/dma/qcom_bam_dma.c
rename to drivers/dma/qcom/bam_dma.c
index 5a250cd..b6f053d 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -49,8 +49,8 @@
#include
#include
-#include "dmaengine.h"
-#include "virt-dma.h"
+#include "../dmaengine.h"
+#include "../virt-dma.h"
struct bam_desc_hw {
u32 addr; /* Buffer physical address */
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V9 4/5] dma: qcom_hidma: implement lower level hardware interface
This patch implements the hardware hooks for the HIDMA channel driver.
The main functions of interest are:
- hidma_ll_init
- hidma_ll_request
- hidma_ll_queue_request
- hidma_ll_hw_start
OS layer calls the hidma_ll_init function during probe to set up the
hardware. At this moment, the number of supported descriptors are also
given. On each request, a descriptor is allocated from the free pool and
filled in with the transfer parameters. Multiple requests can be queued
into the hardware via the OS interface. When client is ready for requests
to be executed, start method is called.
Completions are delivered via callbacks via tasklet.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/dma/qcom/Makefile | 2 +
drivers/dma/qcom/hidma.c| 2 +-
drivers/dma/qcom/hidma_ll.c | 927
3 files changed, 930 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma/qcom/hidma_ll.c
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index 1a5a96d..d2c6bda 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,2 +1,4 @@
obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
obj-$(CONFIG_QCOM_HIDMA_MGMT) += hidma_mgmt.o hidma_mgmt_sys.o
+obj-$(CONFIG_QCOM_HIDMA) += hdma.o
+hdma-objs:= hidma_ll.o hidma.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index d2f7e32..be4ff8d 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -442,7 +442,7 @@ static int hidma_terminate_channel(struct dma_chan *chan)
/* move myself to free_list */
list_move(>node, >free);
}
-
+ rc = hidma_ll_resume(dmadev->lldev);
out:
pm_runtime_mark_last_busy(dmadev->ddev.dev);
pm_runtime_put_autosuspend(dmadev->ddev.dev);
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
new file mode 100644
index 000..b4c8f77
--- /dev/null
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -0,0 +1,927 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine low level code
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "hidma.h"
+
+#define EVRE_SIZE 16 /* each EVRE is 16 bytes */
+
+#define TRCA_CTRLSTS_OFFSET0x0
+#define TRCA_RING_LOW_OFFSET 0x8
+#define TRCA_RING_HIGH_OFFSET 0xC
+#define TRCA_RING_LEN_OFFSET 0x10
+#define TRCA_READ_PTR_OFFSET 0x18
+#define TRCA_WRITE_PTR_OFFSET 0x20
+#define TRCA_DOORBELL_OFFSET 0x400
+
+#define EVCA_CTRLSTS_OFFSET0x0
+#define EVCA_INTCTRL_OFFSET0x4
+#define EVCA_RING_LOW_OFFSET 0x8
+#define EVCA_RING_HIGH_OFFSET 0xC
+#define EVCA_RING_LEN_OFFSET 0x10
+#define EVCA_READ_PTR_OFFSET 0x18
+#define EVCA_WRITE_PTR_OFFSET 0x20
+#define EVCA_DOORBELL_OFFSET 0x400
+
+#define EVCA_IRQ_STAT_OFFSET 0x100
+#define EVCA_IRQ_CLR_OFFSET0x108
+#define EVCA_IRQ_EN_OFFSET 0x110
+
+#define EVRE_CFG_IDX 0
+#define EVRE_LEN_IDX 1
+#define EVRE_DEST_LOW_IDX 2
+#define EVRE_DEST_HI_IDX 3
+
+#define EVRE_ERRINFO_BIT_POS 24
+#define EVRE_CODE_BIT_POS 28
+
+#define EVRE_ERRINFO_MASK GENMASK(3, 0)
+#define EVRE_CODE_MASK GENMASK(3, 0)
+
+#define CH_CONTROL_MASKGENMASK(7, 0)
+#define CH_STATE_MASK GENMASK(7, 0)
+#define CH_STATE_BIT_POS 0x8
+
+#define IRQ_EV_CH_EOB_IRQ_BIT_POS 0
+#define IRQ_EV_CH_WR_RESP_BIT_POS 1
+#define IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS 9
+#define IRQ_TR_CH_DATA_RD_ER_BIT_POS 10
+#define IRQ_TR_CH_DATA_WR_ER_BIT_POS 11
+#define IRQ_TR_CH_INVALID_TRE_BIT_POS 14
+
+#defineENABLE_IRQS (BIT(IRQ_EV_CH_EOB_IRQ_BIT_POS) | \
+ BIT(IRQ_EV_CH_WR_RESP_BIT_POS) | \
+ BIT(IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS)| \
+ BIT(IRQ_TR_CH_DATA_RD_ER_BIT_POS) | \
+ BIT(IRQ_TR_CH_DATA_WR_ER_BIT_POS) | \
+ BIT(IRQ_TR_CH_INVALID_TRE_BIT_POS))
+
+enum ch_command {
+ CH_DISABLE = 0,
+ CH_ENABLE = 1,
+ CH_SUSPEND = 2,
+ CH_RESET = 9,
+};
+
+enum ch_state {
+ CH_DISABLED = 0,
+ CH_ENABLED = 1,
+ CH_RU
[PATCH V9 0/5] dma: add Qualcomm Technologies HIDMA driver
The Qualcomm Technologies HIDMA device has been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design.
1. HIDMA Management driver
2. HIDMA Channel driver
Each HIDMA HW consists of multiple channels. These channels
share some set of common parameters. These parameters are
initialized by the management driver during power up.
Same management driver is used for monitoring the execution
of the channels. Management driver can change the performance
behavior dynamically such as bandwidth allocation and
prioritization in the future.
The management driver is executed in hypervisor context and
is the main management entity for all channels provided by
the device.
Changes from V8: (https://lkml.org/lkml/2015/12/3/19)
* none
Changes from V8: (https://lkml.org/lkml/2015/12/3/23)
* none
Changes from V8: (https://lkml.org/lkml/2015/12/3/20)
* Change the pause behavior. Only the running descriptor gets
DMA_PAUSED return code. All others get DMA_IN_PROGRESS.
Changes from V8: (https://lkml.org/lkml/2015/12/3/22)
* none
Changes from V8: (https://lkml.org/lkml/2015/12/3/21)
* none
Sinan Kaya (5):
dma: qcom_bam_dma: move to qcom directory
dma: add Qualcomm Technologies HIDMA management driver
dma: add Qualcomm Technologies HIDMA channel driver
dma: qcom_hidma: implement lower level hardware interface
dma: qcom_hidma: add debugfs hooks
.../ABI/testing/sysfs-platform-hidma-mgmt | 97 +++
.../devicetree/bindings/dma/qcom_hidma.txt | 18 +
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 61 ++
drivers/dma/Kconfig| 11 +-
drivers/dma/Makefile | 2 +-
drivers/dma/qcom/Kconfig | 29 +
drivers/dma/qcom/Makefile | 4 +
drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 4 +-
drivers/dma/qcom/hidma.c | 743 +
drivers/dma/qcom/hidma.h | 162
drivers/dma/qcom/hidma_dbg.c | 219 +
drivers/dma/qcom/hidma_ll.c| 927 +
drivers/dma/qcom/hidma_mgmt.c | 318 +++
drivers/dma/qcom/hidma_mgmt.h | 39 +
drivers/dma/qcom/hidma_mgmt_sys.c | 292 +++
15 files changed, 2914 insertions(+), 12 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
create mode 100644 drivers/dma/qcom/Kconfig
create mode 100644 drivers/dma/qcom/Makefile
rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
create mode 100644 drivers/dma/qcom/hidma.c
create mode 100644 drivers/dma/qcom/hidma.h
create mode 100644 drivers/dma/qcom/hidma_dbg.c
create mode 100644 drivers/dma/qcom/hidma_ll.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.h
create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V9 2/5] dma: add Qualcomm Technologies HIDMA management driver
The Qualcomm Technologies HIDMA device has been designed to support virtualization technology. The driver has been divided into two to follow the hardware design. 1. HIDMA Management driver 2. HIDMA Channel driver Each HIDMA HW consists of multiple channels. These channels share some set of common parameters. These parameters are initialized by the management driver during power up. Same management driver is used for monitoring the execution of the channels. Management driver can change the performance behavior dynamically such as bandwidth allocation and prioritization. The management driver is executed in hypervisor context and is the main management entity for all channels provided by the device. Signed-off-by: Sinan Kaya <ok...@codeaurora.org> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> --- .../ABI/testing/sysfs-platform-hidma-mgmt | 97 +++ .../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 61 drivers/dma/qcom/Kconfig | 11 + drivers/dma/qcom/Makefile | 1 + drivers/dma/qcom/hidma_mgmt.c | 318 + drivers/dma/qcom/hidma_mgmt.h | 39 +++ drivers/dma/qcom/hidma_mgmt_sys.c | 292 +++ 7 files changed, 819 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt create mode 100644 drivers/dma/qcom/hidma_mgmt.c create mode 100644 drivers/dma/qcom/hidma_mgmt.h create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c diff --git a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt new file mode 100644 index 000..4fc6876 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt @@ -0,0 +1,97 @@ +What: /sys/devices/platform/hidma-mgmt*/chan*/priority + /sys/devices/platform/QCOM8060:*/chan*/priority +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains either 0 or 1 and indicates if the DMA channel is a + low priority (0) or high priority (1) channel. + +What: /sys/devices/platform/hidma-mgmt*/chan*/weight + /sys/devices/platform/QCOM8060:*/chan*/weight +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains 0..15 and indicates the weight of the channel among + equal priority channels during round robin scheduling. + +What: /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles + /sys/devices/platform/QCOM8060:*/chreset_timeout_cycles +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains the platform specific cycle value to wait after a + reset command is issued. If the value is chosen too short, + then the HW will issue a reset failure interrupt. The value + is platform specific and should not be changed without + consultance. + +What: /sys/devices/platform/hidma-mgmt*/dma_channels + /sys/devices/platform/QCOM8060:*/dma_channels +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains the number of dma channels supported by one instance + of HIDMA hardware. The value may change from chip to chip. + +What: /sys/devices/platform/hidma-mgmt*/hw_version_major + /sys/devices/platform/QCOM8060:*/hw_version_major +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Version number major for the hardware. + +What: /sys/devices/platform/hidma-mgmt*/hw_version_minor + /sys/devices/platform/QCOM8060:*/hw_version_minor +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Version number minor for the hardware. + +What: /sys/devices/platform/hidma-mgmt*/max_rd_xactions + /sys/devices/platform/QCOM8060:*/max_rd_xactions +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains a value between 0 and 31. Maximum number of + read transactions that can be issued back to back. + Choosing a higher number gives better performance but + can also cause performance reduction to other peripherals + sharing the same bus. + +What: /sys/devices/platform/hidma-mgmt*/max_read_request +
[PATCH V9 5/5] dma: qcom_hidma: add debugfs hooks
Add debugfs hooks for debugging the execution behavior of the DMA
channel. The debugfs hooks get initialized by the probe function and
uninitialized by the remove function.
A stats file is created in debugfs. The stats file will show the
information about each HIDMA channel as well as each asynchronous job
queued and completed at a given time.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/dma/qcom/Makefile| 2 +-
drivers/dma/qcom/hidma.c | 3 +
drivers/dma/qcom/hidma.h | 2 +
drivers/dma/qcom/hidma_dbg.c | 219 +++
4 files changed, 225 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma/qcom/hidma_dbg.c
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index d2c6bda..f702df1 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
obj-$(CONFIG_QCOM_HIDMA_MGMT) += hidma_mgmt.o hidma_mgmt_sys.o
obj-$(CONFIG_QCOM_HIDMA) += hdma.o
-hdma-objs:= hidma_ll.o hidma.o
+hdma-objs:= hidma_ll.o hidma.o hidma_dbg.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index be4ff8d..23a0419 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -677,6 +677,7 @@ static int hidma_probe(struct platform_device *pdev)
dmadev->irq = chirq;
tasklet_init(>task, hidma_issue_task, (unsigned long)dmadev);
+ hidma_debug_init(dmadev);
dev_info(>dev, "HI-DMA engine driver registration complete\n");
platform_set_drvdata(pdev, dmadev);
pm_runtime_mark_last_busy(dmadev->ddev.dev);
@@ -685,6 +686,7 @@ static int hidma_probe(struct platform_device *pdev)
return 0;
uninit:
+ hidma_debug_uninit(dmadev);
hidma_ll_uninit(dmadev->lldev);
dmafree:
if (dmadev)
@@ -702,6 +704,7 @@ static int hidma_remove(struct platform_device *pdev)
pm_runtime_get_sync(dmadev->ddev.dev);
dma_async_device_unregister(>ddev);
devm_free_irq(dmadev->ddev.dev, dmadev->irq, >lldev);
+ hidma_debug_uninit(dmadev);
hidma_ll_uninit(dmadev->lldev);
hidma_free(dmadev);
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index 363b82d..ad38431 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -157,4 +157,6 @@ int hidma_ll_uninit(struct hidma_lldev *llhndl);
irqreturn_t hidma_ll_inthandler(int irq, void *arg);
void hidma_cleanup_pending_tre(struct hidma_lldev *llhndl, u8 err_info,
u8 err_code);
+int hidma_debug_init(struct hidma_dev *dmadev);
+void hidma_debug_uninit(struct hidma_dev *dmadev);
#endif
diff --git a/drivers/dma/qcom/hidma_dbg.c b/drivers/dma/qcom/hidma_dbg.c
new file mode 100644
index 000..3698257
--- /dev/null
+++ b/drivers/dma/qcom/hidma_dbg.c
@@ -0,0 +1,219 @@
+/*
+ * Qualcomm Technologies HIDMA debug file
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "hidma.h"
+
+static void hidma_ll_chstats(struct seq_file *s, void *llhndl, u32 tre_ch)
+{
+ struct hidma_lldev *lldev = llhndl;
+ struct hidma_tre *tre;
+ u32 length;
+ dma_addr_t src_start;
+ dma_addr_t dest_start;
+ u32 *tre_local;
+
+ if (tre_ch >= lldev->nr_tres) {
+ dev_err(lldev->dev, "invalid TRE number in chstats:%d", tre_ch);
+ return;
+ }
+ tre = >trepool[tre_ch];
+ seq_printf(s, "--Channel %d -\n", tre_ch);
+ seq_printf(s, "allocated=%d\n", atomic_read(>allocated));
+ seq_printf(s, "queued = 0x%x\n", tre->queued);
+ seq_printf(s, "err_info = 0x%x\n",
+ lldev->tx_status_list[tre->chidx].err_info);
+ seq_printf(s, "err_code = 0x%x\n",
+ lldev->tx_status_list[tre->chidx].err_code);
+ seq_printf(s, "status = 0x%x\n", tre->status);
+ seq_printf(s, "chidx = 0x%x\n", tre->chidx);
+ seq_printf(s, "dma_sig = 0x%x\n", tre->dma_sig);
+ seq_printf(s, "dev_name=%s\n", tre->dev_name);
+ seq_printf(s, "callback=%p\n", tre->callback);
+ seq_printf(s, "data=%p\n", tre->data);
+ seq_printf(s, "tre_index = 0x%x\n", tre->tre_index
Re: [PATCH V9 2/5] dma: add Qualcomm Technologies HIDMA management driver
stances (6 channels
>> each). This driver is only responsible for management which it can do
>> through its own dedicated HW interface. It doesn't need access to the
>> channel address space. There will be 4 HIDMA management instances in
>> this case.
>
> I don't follow.
>
> How do you know which channels are associated with which management
> interface?
The association is the other way around. User need to know the
management interface for a channel rather than the channel needing to
know the management interface.
I'll think about it.
>
> How can your sysfs interface work if that relationship is not described?
Here is the sysfs documentation. Each management object has one channel
directory under it. I still don't need to access the channel object in
order to change its weight and priority.
What: /sys/devices/platform/hidma-mgmt*/chan*/priority
/sys/devices/platform/QCOM8060:*/chan*/priority
Date: Nov 2015
KernelVersion: 4.4
Contact:"Sinan Kaya <ok...@cudeaurora.org>"
Description:
Contains either 0 or 1 and indicates if the DMA channel is a
low priority (0) or high priority (1) channel.
>
>>> I don't understand why you don't have a single binding for both the
>>> management interface and channels, e.g.
>>>
>>> hidma {
>>> compatible - "qcom,hidma-1.0";
>>>
>>> /* OPTIONAL management interface registers */
>>> reg = < ... ... >;
>>>
>>> ...
>>>
>>> channels {
>>> channel0 {
>>> compatible = "qcom,
>>> reg = < ... ... >;
>>>
>>> ...
>>> };
>>>
>>> ...
>>> };
>>> };
>>>
>>> That would be more in keeping with what we do for other componenents
>>> with hyp control elements (e.g. the GIC) and keeps everything
>>> associated.
>>
>> This was discussed before with the previous versions of the patch. This
>> split and loose coupling design is on purpose.
>
> I understand it was a deliberate choice. I am disagreeing with that
> choice.
>
In order to be able to use the same channel driver in the guest machine
context with the hierarchy you want, I need to create this.
fake management object {
fake values;
channels {
real DMA channel {
...
}
}
}
This looks really ugly to me. I need to deal with a fake management
driver and object that could be hypervisor specific.
Here is a fact:
QEMU is not capable of generating complex device-tree nodes for platform
devices that are being virtualized. QEMU only generates a very simple
device object with compatible ID and memory and interrupt resources. No
parent, child relationship and no device-specific attributes. Here is an
example:
device {
compatible-id;
reg;
interrupt;
}
This is plain and simple. It works too. No need to create some fake device.
The other issue is the ACPI. I know device-tree has all kinds of nice
gadgets for traversing the parent/child relationship and object
pointers. I can't implement this if the solution does not scale to ACPI.
I'm still leaning towards keep it simple approach.
>> The summary is that for static OS configurations where devices remain
>> active for the rest of the OS execution; it makes perfect sense to
>> create a device bus or child device object relationship.
>>
>> The use case here is virtualization and object lifetime in the
>> hypervisor is dynamic. Channel objects get unbound and bound dynamically
>> for guest OS control. At any time, the hypervisor may not have any
>> channel objects if the administrator decides to give all channels to the
>> guest machines.
>
> If the administrator tells the host to give a guest ownership of a
> channel, the host knows that it cannot use the channel itself, nor can
> it allocate the channel to another guest. Consider PCIe device
> passthrough; the host knows that there is a device on the PCIe bus, but
> also knows that a guest owns it. The same logic should apply here.
Agreed, the HIDMA channel object gets associated to the VFIO driver
while the guest is owning the HIDMA channel object.
>
> No guest should care which particular physical channels it's provided
> with.
>
>> Only the hidma channel driver gets executed in the guest machine. There
>> is no management driver and device entity in the guest. Therefore,
>> child-parent relationship does not exist.
>
> The management driver needs to know details of the channels it's
>
Re: [PATCH V9 2/5] dma: add Qualcomm Technologies HIDMA management driver
Hi Mark, On 12/11/2015 11:41 AM, Mark Rutland wrote: > Hi, > > On Fri, Dec 11, 2015 at 11:16:58AM -0500, Sinan Kaya wrote: >> The Qualcomm Technologies HIDMA device has been designed to support >> virtualization technology. The driver has been divided into two to follow >> the hardware design. >> >> 1. HIDMA Management driver >> 2. HIDMA Channel driver >> >> Each HIDMA HW consists of multiple channels. These channels share some set >> of common parameters. These parameters are initialized by the management >> driver during power up. Same management driver is used for monitoring the >> execution of the channels. Management driver can change the performance >> behavior dynamically such as bandwidth allocation and prioritization. >> >> The management driver is executed in hypervisor context and is the main >> management entity for all channels provided by the device. >> >> Signed-off-by: Sinan Kaya <ok...@codeaurora.org> >> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> >> --- >> .../ABI/testing/sysfs-platform-hidma-mgmt | 97 +++ >> .../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 61 > > Please split the binding into a separate patch, per > Documentation/devicetree/bindings/submitting-patches.txt. Done. I'm new to this. Bare with me. > >> diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt >> b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt >> new file mode 100644 >> index 000..b632635 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt >> @@ -0,0 +1,61 @@ >> +Qualcomm Technologies HIDMA Management interface >> + >> +The Qualcomm Technologies HIDMA device has been designed >> +to support virtualization technology. The driver has been >> +divided into two to follow the hardware design. The management >> +driver is executed in hypervisor context and is the main >> +management entity for all channels provided by the device. >> + >> +Each HIDMA HW consists of multiple channels. These channels >> +share some set of common parameters. These parameters are >> +initialized by the management driver during power up. >> +Same management driver is used for monitoring the execution >> +of the channels. Management driver can change the performance >> +behavior dynamically such as bandwidth allocation and >> +prioritization. >> + >> +All channel devices get probed in the hypervisor >> +context during power up. They show up as DMA engine >> +DMA channels. Then, before starting the virtualization; each >> +channel device is unbound from the hypervisor by VFIO >> +and assign to the guest machine for control. >> + >> +This management driver will be used by the system >> +admin to monitor/reset the execution state of the DMA >> +channels. This will be the management interface. > > This is a mixture of hardware and software description (e.g. VFIO has > nothing to do wit hteh hardware). We want to capture what is necessary > to describe the hardware, not what the software stack above it will look > like. Another reviewer requested guidance on how to set these parameters. That's why, I tried to provide as much data as possible. > >> +Required properties: >> +- compatible: "qcom,hidma-mgmt-1.0"; >> +- reg: Address range for DMA device > > Does this cover just the management registers, or those for channels as > well? just management. > >> +- dma-channels: Number of channels supported by this DMA controller. > > Surely this is discoverable, or can be derived from the set of channels > described in the DT? No, this is a HW configuration. Each hardware instance supports certain number of channels based on the HW build. The number of active channels on the running operating system does not necessarily represent the maximum possible. > >> +- max-write-burst-bytes: Maximum write burst in bytes. A memcpy requested is >> + fragmented to multiples of this amount. >> +- max-read-burst-bytes: Maximum read burst in bytes. A memcpy request is >> + fragmented to multiples of this amount. >> +- max-write-transactions: Maximum write transactions to perform in a burst >> +- max-read-transactions: Maximum read transactions to perform in a burst >> +- channel-reset-timeout-cycles: Channel reset timeout in cycles for this >> SOC. >> +- channel-priority: Priority of the channel. >> + Each dma channel share the same HW bandwidth with other dma channels. >> + If two requests reach to the HW at the same time from a low priority and >>
Re: [PATCH V7 3/3] dma: add Qualcomm Technologies HIDMA channel driver
On 12/5/2015 3:00 AM, Vinod Koul wrote: > On Wed, Dec 02, 2015 at 02:04:05PM -0500, Sinan Kaya wrote: >>>>> You are missing the point. Channel can be paused, yes but the descriptor >>>>> is in queue and is not paused. The descriptor running is paused, yes. >>>>> There is subtle difference between these >>> I'll follow your recommendation. PAUSE for the currently active >>> descriptor and DMA_IN_PROGRESS for the rest. >>> >> >> I'm now confused. >> >> I looked at several DMA driver implementations. >> >> 1. They call dma_cookie_status function to see if the job is done. >> 2. If done, they return right ahead. >> 3. Otherwise, dma_cookie_status returns DMA_IN_PROGRESS. >> 4. Next the code checks if the channel is paused and return value is >> DMA_IN_PROGRESS. The code changes return code to DMA_PAUSED. >> >> Whereas, I was returning paused first before even checking if the >> descriptor is done. Are you OK with the sequence 1..4 above? > > Yes am okay with this with slight change in 4. > > You should set to PAUSED only for current descriptor and not for the ones in > queue > OK. I'll post a new version with this. Is there any other comment that needed to be addressed? -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 2/3] dma: add Qualcomm Technologies HIDMA management driver
On 12/5/2015 2:58 AM, Vinod Koul wrote:
> On Tue, Dec 01, 2015 at 11:57:34PM -0500, Sinan Kaya wrote:
>> On 11/30/2015 10:17 PM, Vinod Koul wrote:
>>> On Mon, Nov 30, 2015 at 09:42:01AM -0500, Sinan Kaya wrote:
>>>
>>>>>> +static int hidma_mgmt_probe(struct platform_device *pdev)
>>>>>> +{
>>>>>> +struct hidma_mgmt_dev *mgmtdev;
>>>>>> +struct resource *res;
>>>>>> +void __iomem *virtaddr;
>>>>>> +int irq;
>>>>>> +int rc;
>>>>>> +u32 val;
>>>>>> +
>>>>>> +pm_runtime_set_autosuspend_delay(>dev,
>>>>>> AUTOSUSPEND_TIMEOUT);
>>>>>> +pm_runtime_use_autosuspend(>dev);
>>>>>> +pm_runtime_set_active(>dev);
>>>>>> +pm_runtime_enable(>dev);
>>>>>
>>>>> at this time pm core will treat device as fully enabled and pm methods can
>>>>> be invoked, but you are not ready yet right. Typically these are done at
>>>>> the
>>>>> end of the probe unless you have a reason...
>>>>
>>>> I need it here because the clocks are declared as ACPI power resources.
>>>> The kernel is turning off all power resources during initialization. In
>>>> order for this code to touch the hardware, I need to call enable so that
>>>> clocks are enabled once again.
>>>
>>> The question is are you ready in your driver routines to be invoked by pm
>>> core?
>>>
>>
>> I don't have any support for suspend and resume PM APIs. The only PM
>> interface I support is PM runtime. PM can turn on/off the clocks based
>> on the reference counts it maintains after get/set APIs. Since PM is
>> turning off the clocks during power up before my driver load, I do need
>> to grab this lock to re-enable it during HW initialization. Then, let PM
>> turn off the clocks again after the AUTOSUSPEND_TIMEOUT when I'm done.
>>
>> Is there any other interaction with the PM that I'm not aware of?
>
> No this is fine. The the runtime_resume will be onvoked and it will request
> resources are those set before you enable the device?
>
Yes, the only resource that this device needs for power management is
the ACPI power resources. The device does not support suspend/resume via
traditional _PS0 and _PS3 calls. ACPI power resources are initialized
during power up while ACPI is being enumerated.
The probing of the HIDMA driver happens much afterwards.
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 3/3] dma: add Qualcomm Technologies HIDMA channel driver
On 12/5/2015 3:00 AM, Vinod Koul wrote: > On Wed, Dec 02, 2015 at 02:04:05PM -0500, Sinan Kaya wrote: >>>>> You are missing the point. Channel can be paused, yes but the descriptor >>>>> is in queue and is not paused. The descriptor running is paused, yes. >>>>> There is subtle difference between these >>> I'll follow your recommendation. PAUSE for the currently active >>> descriptor and DMA_IN_PROGRESS for the rest. >>> >> >> I'm now confused. >> >> I looked at several DMA driver implementations. >> >> 1. They call dma_cookie_status function to see if the job is done. >> 2. If done, they return right ahead. >> 3. Otherwise, dma_cookie_status returns DMA_IN_PROGRESS. >> 4. Next the code checks if the channel is paused and return value is >> DMA_IN_PROGRESS. The code changes return code to DMA_PAUSED. >> >> Whereas, I was returning paused first before even checking if the >> descriptor is done. Are you OK with the sequence 1..4 above? > > Yes am okay with this with slight change in 4. > > You should set to PAUSED only for current descriptor and not for the ones in > queue > OK, I'll work on it. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 3/3] dma: add Qualcomm Technologies HIDMA channel driver
On 12/1/2015 4:16 PM, Sinan Kaya wrote:
>>>> >>>
>>>>> >>>> +static enum dma_status hidma_tx_status(struct dma_chan *dmach,
>>>>> >>>> +dma_cookie_t cookie, struct dma_tx_state
>>>>> >>>> *txstate)
>>>>> >>>> +{
>>>>> >>>> +struct hidma_chan *mchan = to_hidma_chan(dmach);
>>>>> >>>> +enum dma_status ret;
>>>>> >>>> +
>>>>> >>>> +if (mchan->paused)
>>>>> >>>> +ret = DMA_PAUSED;
>>>> >>>
>>>> >>> This is not quite right. The status query is for a descriptor and NOT
>>>> >>> for
>>>> >>> channel. Here if the descriptor queried was running then it would be
>>>> >>> paused
>>>> >>> for the rest pending txn, it would be DMA_IN_PROGRESS.
>>> >>
>>> >> The channel can be paused by the hypervisor. If it is paused, then no
>>> >> other transaction will go through including the pending requests. That's
>>> >> why, I'm checking the state first.
>> >
>> > You are missing the point. Channel can be paused, yes but the descriptor
>> > is in queue and is not paused. The descriptor running is paused, yes.
>> > There is subtle difference between these
> I'll follow your recommendation. PAUSE for the currently active
> descriptor and DMA_IN_PROGRESS for the rest.
>
I'm now confused.
I looked at several DMA driver implementations.
1. They call dma_cookie_status function to see if the job is done.
2. If done, they return right ahead.
3. Otherwise, dma_cookie_status returns DMA_IN_PROGRESS.
4. Next the code checks if the channel is paused and return value is
DMA_IN_PROGRESS. The code changes return code to DMA_PAUSED.
Whereas, I was returning paused first before even checking if the
descriptor is done. Are you OK with the sequence 1..4 above?
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V8 2/5] dma: add Qualcomm Technologies HIDMA management driver
The Qualcomm Technologies HIDMA device has been designed to support virtualization technology. The driver has been divided into two to follow the hardware design. 1. HIDMA Management driver 2. HIDMA Channel driver Each HIDMA HW consists of multiple channels. These channels share some set of common parameters. These parameters are initialized by the management driver during power up. Same management driver is used for monitoring the execution of the channels. Management driver can change the performance behavior dynamically such as bandwidth allocation and prioritization. The management driver is executed in hypervisor context and is the main management entity for all channels provided by the device. Signed-off-by: Sinan Kaya <ok...@codeaurora.org> Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> --- .../ABI/testing/sysfs-platform-hidma-mgmt | 97 +++ .../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 61 drivers/dma/qcom/Kconfig | 11 + drivers/dma/qcom/Makefile | 1 + drivers/dma/qcom/hidma_mgmt.c | 318 + drivers/dma/qcom/hidma_mgmt.h | 39 +++ drivers/dma/qcom/hidma_mgmt_sys.c | 292 +++ 7 files changed, 819 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt create mode 100644 drivers/dma/qcom/hidma_mgmt.c create mode 100644 drivers/dma/qcom/hidma_mgmt.h create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c diff --git a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt new file mode 100644 index 000..4fc6876 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt @@ -0,0 +1,97 @@ +What: /sys/devices/platform/hidma-mgmt*/chan*/priority + /sys/devices/platform/QCOM8060:*/chan*/priority +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains either 0 or 1 and indicates if the DMA channel is a + low priority (0) or high priority (1) channel. + +What: /sys/devices/platform/hidma-mgmt*/chan*/weight + /sys/devices/platform/QCOM8060:*/chan*/weight +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains 0..15 and indicates the weight of the channel among + equal priority channels during round robin scheduling. + +What: /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles + /sys/devices/platform/QCOM8060:*/chreset_timeout_cycles +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains the platform specific cycle value to wait after a + reset command is issued. If the value is chosen too short, + then the HW will issue a reset failure interrupt. The value + is platform specific and should not be changed without + consultance. + +What: /sys/devices/platform/hidma-mgmt*/dma_channels + /sys/devices/platform/QCOM8060:*/dma_channels +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains the number of dma channels supported by one instance + of HIDMA hardware. The value may change from chip to chip. + +What: /sys/devices/platform/hidma-mgmt*/hw_version_major + /sys/devices/platform/QCOM8060:*/hw_version_major +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Version number major for the hardware. + +What: /sys/devices/platform/hidma-mgmt*/hw_version_minor + /sys/devices/platform/QCOM8060:*/hw_version_minor +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Version number minor for the hardware. + +What: /sys/devices/platform/hidma-mgmt*/max_rd_xactions + /sys/devices/platform/QCOM8060:*/max_rd_xactions +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains a value between 0 and 31. Maximum number of + read transactions that can be issued back to back. + Choosing a higher number gives better performance but + can also cause performance reduction to other peripherals + sharing the same bus. + +What: /sys/devices/platform/hidma-mgmt*/max_read_request +
[PATCH V8 3/5] dma: add Qualcomm Technologies HIDMA channel driver
This patch adds support for hidma engine. The driver consists of two
logical blocks. The DMA engine interface and the low-level interface.
The hardware only supports memcpy/memset and this driver only support
memcpy interface. HW and driver doesn't support slave interface.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
.../devicetree/bindings/dma/qcom_hidma.txt | 18 +
drivers/dma/qcom/Kconfig | 10 +
drivers/dma/qcom/hidma.c | 713 +
drivers/dma/qcom/hidma.h | 159 +
4 files changed, 900 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
create mode 100644 drivers/dma/qcom/hidma.c
create mode 100644 drivers/dma/qcom/hidma.h
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma.txt
b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
new file mode 100644
index 000..d18c8fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
@@ -0,0 +1,18 @@
+Qualcomm Technologies HIDMA Channel driver
+
+Required properties:
+- compatible: must contain "qcom,hidma-1.0"
+- reg: Addresses for the transfer and event channel
+- interrupts: Should contain the event interrupt
+- desc-count: Number of asynchronous requests this channel can handle
+- event-channel: The HW event channel completions will be delivered.
+Example:
+
+ hidma_24: dma-controller@0x5c05 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c05 0x0 0x1000>,
+ <0 0x5c0b 0x0 0x1000>;
+ interrupts = <0 389 0>;
+ desc-count = <10>;
+ event-channel = <4>;
+ };
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index ebe5b8c..5588e1c 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -17,3 +17,13 @@ config QCOM_HIDMA_MGMT
start managing the channels. In a virtualized environment,
the guest OS would run QCOM_HIDMA channel driver and the
hypervisor would run the QCOM_HIDMA_MGMT management driver.
+
+config QCOM_HIDMA
+ tristate "Qualcomm Technologies HIDMA Channel support"
+ select DMA_ENGINE
+ help
+ Enable support for the Qualcomm Technologies HIDMA controller.
+ The HIDMA controller supports optimized buffer copies
+ (user to kernel, kernel to kernel, etc.). It only supports
+ memcpy interface. The core is not intended for general
+ purpose slave DMA.
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
new file mode 100644
index 000..0515145
--- /dev/null
+++ b/drivers/dma/qcom/hidma.c
@@ -0,0 +1,713 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine interface
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
+ * Copyright (C) Semihalf 2009
+ * Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2014
+ *
+ * Written by Piotr Ziecik <ko...@semihalf.com>. Hardware description
+ * (defines, structures and comments) was taken from MPC5121 DMA driver
+ * written by Hongjun Chen <hong-jun.c...@freescale.com>.
+ *
+ * Approved as OSADL project by a majority of OSADL members and funded
+ * by OSADL membership fees in 2009; for details see www.osadl.org.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * The full GNU General Public License is included in this distribution in the
+ * file called COPYING.
+ */
+
+/* Linux Foundation elects GPLv2 license only. */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../dmaengine.h"
+#include "hidma.h"
+
+/*
+ * Default idle time is 2 seconds. This parameter can
+ * be overridden by changing the following
+ * /s
[PATCH V8 5/5] dma: qcom_hidma: add debugfs hooks
Add debugfs hooks for debugging the execution behavior of the DMA
channel. The debugfs hooks get initialized by the probe function and
uninitialized by the remove function.
A stats file is created in debugfs. The stats file will show the
information about each HIDMA channel as well as each asynchronous job
queued and completed at a given time.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/dma/qcom/Makefile| 2 +-
drivers/dma/qcom/hidma.c | 3 +
drivers/dma/qcom/hidma.h | 2 +
drivers/dma/qcom/hidma_dbg.c | 219 +++
4 files changed, 225 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma/qcom/hidma_dbg.c
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index d2c6bda..f702df1 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
obj-$(CONFIG_QCOM_HIDMA_MGMT) += hidma_mgmt.o hidma_mgmt_sys.o
obj-$(CONFIG_QCOM_HIDMA) += hdma.o
-hdma-objs:= hidma_ll.o hidma.o
+hdma-objs:= hidma_ll.o hidma.o hidma_dbg.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index 1237a26..ee3aacd 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -650,6 +650,7 @@ static int hidma_probe(struct platform_device *pdev)
dmadev->irq = chirq;
tasklet_init(>task, hidma_issue_task, (unsigned long)dmadev);
+ hidma_debug_init(dmadev);
dev_info(>dev, "HI-DMA engine driver registration complete\n");
platform_set_drvdata(pdev, dmadev);
pm_runtime_mark_last_busy(dmadev->ddev.dev);
@@ -658,6 +659,7 @@ static int hidma_probe(struct platform_device *pdev)
return 0;
uninit:
+ hidma_debug_uninit(dmadev);
hidma_ll_uninit(dmadev->lldev);
dmafree:
if (dmadev)
@@ -675,6 +677,7 @@ static int hidma_remove(struct platform_device *pdev)
pm_runtime_get_sync(dmadev->ddev.dev);
dma_async_device_unregister(>ddev);
devm_free_irq(dmadev->ddev.dev, dmadev->irq, >lldev);
+ hidma_debug_uninit(dmadev);
hidma_ll_uninit(dmadev->lldev);
hidma_free(dmadev);
diff --git a/drivers/dma/qcom/hidma.h b/drivers/dma/qcom/hidma.h
index b8a7990..88897c7 100644
--- a/drivers/dma/qcom/hidma.h
+++ b/drivers/dma/qcom/hidma.h
@@ -156,4 +156,6 @@ int hidma_ll_uninit(struct hidma_lldev *llhndl);
irqreturn_t hidma_ll_inthandler(int irq, void *arg);
void hidma_cleanup_pending_tre(struct hidma_lldev *llhndl, u8 err_info,
u8 err_code);
+int hidma_debug_init(struct hidma_dev *dmadev);
+void hidma_debug_uninit(struct hidma_dev *dmadev);
#endif
diff --git a/drivers/dma/qcom/hidma_dbg.c b/drivers/dma/qcom/hidma_dbg.c
new file mode 100644
index 000..3698257
--- /dev/null
+++ b/drivers/dma/qcom/hidma_dbg.c
@@ -0,0 +1,219 @@
+/*
+ * Qualcomm Technologies HIDMA debug file
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "hidma.h"
+
+static void hidma_ll_chstats(struct seq_file *s, void *llhndl, u32 tre_ch)
+{
+ struct hidma_lldev *lldev = llhndl;
+ struct hidma_tre *tre;
+ u32 length;
+ dma_addr_t src_start;
+ dma_addr_t dest_start;
+ u32 *tre_local;
+
+ if (tre_ch >= lldev->nr_tres) {
+ dev_err(lldev->dev, "invalid TRE number in chstats:%d", tre_ch);
+ return;
+ }
+ tre = >trepool[tre_ch];
+ seq_printf(s, "--Channel %d -\n", tre_ch);
+ seq_printf(s, "allocated=%d\n", atomic_read(>allocated));
+ seq_printf(s, "queued = 0x%x\n", tre->queued);
+ seq_printf(s, "err_info = 0x%x\n",
+ lldev->tx_status_list[tre->chidx].err_info);
+ seq_printf(s, "err_code = 0x%x\n",
+ lldev->tx_status_list[tre->chidx].err_code);
+ seq_printf(s, "status = 0x%x\n", tre->status);
+ seq_printf(s, "chidx = 0x%x\n", tre->chidx);
+ seq_printf(s, "dma_sig = 0x%x\n", tre->dma_sig);
+ seq_printf(s, "dev_name=%s\n", tre->dev_name);
+ seq_printf(s, "callback=%p\n", tre->callback);
+ seq_printf(s, "data=%p\n", tre->data);
+ seq_printf(s, "tre_index = 0x%x\n", tre->tre_index
[PATCH V8 1/5] dma: qcom_bam_dma: move to qcom directory
Creating a QCOM directory for all QCOM DMA source files.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
Reviewed-by: Andy Gtoss <agr...@codeaurora.org>
---
drivers/dma/Kconfig| 11 ++-
drivers/dma/Makefile | 2 +-
drivers/dma/qcom/Kconfig | 8
drivers/dma/qcom/Makefile | 1 +
drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 4 ++--
5 files changed, 14 insertions(+), 12 deletions(-)
create mode 100644 drivers/dma/qcom/Kconfig
create mode 100644 drivers/dma/qcom/Makefile
rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index b458475..47b1b98 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -408,15 +408,6 @@ config PXA_DMA
16 to 32 channels for peripheral to memory or memory to memory
transfers.
-config QCOM_BAM_DMA
- tristate "QCOM BAM DMA support"
- depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
- select DMA_ENGINE
- select DMA_VIRTUAL_CHANNELS
- ---help---
- Enable support for the QCOM BAM DMA controller. This controller
- provides DMA capabilities for a variety of on-chip devices.
-
config SIRF_DMA
tristate "CSR SiRFprimaII/SiRFmarco DMA support"
depends on ARCH_SIRF
@@ -527,6 +518,8 @@ config ZX_DMA
# driver files
source "drivers/dma/bestcomm/Kconfig"
+source "drivers/dma/qcom/Kconfig"
+
source "drivers/dma/dw/Kconfig"
source "drivers/dma/hsu/Kconfig"
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 7711a71..8dba90d 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_PCH_DMA) += pch_dma.o
obj-$(CONFIG_PL330_DMA) += pl330.o
obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
obj-$(CONFIG_PXA_DMA) += pxa_dma.o
-obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
obj-$(CONFIG_RENESAS_DMA) += sh/
obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
@@ -66,4 +65,5 @@ obj-$(CONFIG_TI_EDMA) += edma.o
obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
+obj-y += qcom/
obj-y += xilinx/
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
new file mode 100644
index 000..f17c272
--- /dev/null
+++ b/drivers/dma/qcom/Kconfig
@@ -0,0 +1,8 @@
+config QCOM_BAM_DMA
+ tristate "QCOM BAM DMA support"
+ depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ ---help---
+ Enable support for the QCOM BAM DMA controller. This controller
+ provides DMA capabilities for a variety of on-chip devices.
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
new file mode 100644
index 000..f612ae3
--- /dev/null
+++ b/drivers/dma/qcom/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom/bam_dma.c
similarity index 99%
rename from drivers/dma/qcom_bam_dma.c
rename to drivers/dma/qcom/bam_dma.c
index 5a250cd..b6f053d 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -49,8 +49,8 @@
#include
#include
-#include "dmaengine.h"
-#include "virt-dma.h"
+#include "../dmaengine.h"
+#include "../virt-dma.h"
struct bam_desc_hw {
u32 addr; /* Buffer physical address */
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V8 4/5] dma: qcom_hidma: implement lower level hardware interface
This patch implements the hardware hooks for the HIDMA channel driver.
The main functions of interest are:
- hidma_ll_init
- hidma_ll_request
- hidma_ll_queue_request
- hidma_ll_hw_start
OS layer calls the hidma_ll_init function during probe to set up the
hardware. At this moment, the number of supported descriptors are also
given. On each request, a descriptor is allocated from the free pool and
filled in with the transfer parameters. Multiple requests can be queued
into the hardware via the OS interface. When client is ready for requests
to be executed, start method is called.
Completions are delivered via callbacks via tasklet.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/dma/qcom/Makefile | 2 +
drivers/dma/qcom/hidma.c| 2 +-
drivers/dma/qcom/hidma_ll.c | 927
3 files changed, 930 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma/qcom/hidma_ll.c
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index 1a5a96d..d2c6bda 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,2 +1,4 @@
obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
obj-$(CONFIG_QCOM_HIDMA_MGMT) += hidma_mgmt.o hidma_mgmt_sys.o
+obj-$(CONFIG_QCOM_HIDMA) += hdma.o
+hdma-objs:= hidma_ll.o hidma.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index 0515145..1237a26 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -415,7 +415,7 @@ static int hidma_terminate_channel(struct dma_chan *chan)
/* move myself to free_list */
list_move(>node, >free);
}
-
+ rc = hidma_ll_resume(dmadev->lldev);
out:
pm_runtime_mark_last_busy(dmadev->ddev.dev);
pm_runtime_put_autosuspend(dmadev->ddev.dev);
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
new file mode 100644
index 000..b4c8f77
--- /dev/null
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -0,0 +1,927 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine low level code
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "hidma.h"
+
+#define EVRE_SIZE 16 /* each EVRE is 16 bytes */
+
+#define TRCA_CTRLSTS_OFFSET0x0
+#define TRCA_RING_LOW_OFFSET 0x8
+#define TRCA_RING_HIGH_OFFSET 0xC
+#define TRCA_RING_LEN_OFFSET 0x10
+#define TRCA_READ_PTR_OFFSET 0x18
+#define TRCA_WRITE_PTR_OFFSET 0x20
+#define TRCA_DOORBELL_OFFSET 0x400
+
+#define EVCA_CTRLSTS_OFFSET0x0
+#define EVCA_INTCTRL_OFFSET0x4
+#define EVCA_RING_LOW_OFFSET 0x8
+#define EVCA_RING_HIGH_OFFSET 0xC
+#define EVCA_RING_LEN_OFFSET 0x10
+#define EVCA_READ_PTR_OFFSET 0x18
+#define EVCA_WRITE_PTR_OFFSET 0x20
+#define EVCA_DOORBELL_OFFSET 0x400
+
+#define EVCA_IRQ_STAT_OFFSET 0x100
+#define EVCA_IRQ_CLR_OFFSET0x108
+#define EVCA_IRQ_EN_OFFSET 0x110
+
+#define EVRE_CFG_IDX 0
+#define EVRE_LEN_IDX 1
+#define EVRE_DEST_LOW_IDX 2
+#define EVRE_DEST_HI_IDX 3
+
+#define EVRE_ERRINFO_BIT_POS 24
+#define EVRE_CODE_BIT_POS 28
+
+#define EVRE_ERRINFO_MASK GENMASK(3, 0)
+#define EVRE_CODE_MASK GENMASK(3, 0)
+
+#define CH_CONTROL_MASKGENMASK(7, 0)
+#define CH_STATE_MASK GENMASK(7, 0)
+#define CH_STATE_BIT_POS 0x8
+
+#define IRQ_EV_CH_EOB_IRQ_BIT_POS 0
+#define IRQ_EV_CH_WR_RESP_BIT_POS 1
+#define IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS 9
+#define IRQ_TR_CH_DATA_RD_ER_BIT_POS 10
+#define IRQ_TR_CH_DATA_WR_ER_BIT_POS 11
+#define IRQ_TR_CH_INVALID_TRE_BIT_POS 14
+
+#defineENABLE_IRQS (BIT(IRQ_EV_CH_EOB_IRQ_BIT_POS) | \
+ BIT(IRQ_EV_CH_WR_RESP_BIT_POS) | \
+ BIT(IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS)| \
+ BIT(IRQ_TR_CH_DATA_RD_ER_BIT_POS) | \
+ BIT(IRQ_TR_CH_DATA_WR_ER_BIT_POS) | \
+ BIT(IRQ_TR_CH_INVALID_TRE_BIT_POS))
+
+enum ch_command {
+ CH_DISABLE = 0,
+ CH_ENABLE = 1,
+ CH_SUSPEND = 2,
+ CH_RESET = 9,
+};
+
+enum ch_state {
+ CH_DISABLED = 0,
+ CH_ENABLED = 1,
+ CH_RU
[PATCH V8 0/5] dma: add Qualcomm Technologies HIDMA driver
The Qualcomm Technologies HIDMA device has been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design.
1. HIDMA Management driver
2. HIDMA Channel driver
Each HIDMA HW consists of multiple channels. These channels
share some set of common parameters. These parameters are
initialized by the management driver during power up.
Same management driver is used for monitoring the execution
of the channels. Management driver can change the performance
behavior dynamically such as bandwidth allocation and
prioritization in the future.
The management driver is executed in hypervisor context and
is the main management entity for all channels provided by
the device.
Changes from V7: (https://lkml.org/lkml/2015/11/22/221)
* none
Changes from V7: (https://lkml.org/lkml/2015/11/22/222)
* remove done goto labels
* remove extra space in device tree documentation
* correct spelling mistake
* prefix constants with HIDMA
Changes from V7: (https://lkml.org/lkml/2015/11/22/223)
* Split debugs from the patchset.
* Remove potential sleeps in PM functions.
* Seperate the lower level into its own patch.
* Remove redundant DMA_CTRL_ACK assignment.
* tx_status changes to handle completed transactions right before the
pause.
* terminate the running transactions in channel free.
Sinan Kaya (5):
dma: qcom_bam_dma: move to qcom directory
dma: add Qualcomm Technologies HIDMA management driver
dma: add Qualcomm Technologies HIDMA channel driver
dma: qcom_hidma: implement lower level hardware interface
dma: qcom_hidma: add debugfs hooks
.../ABI/testing/sysfs-platform-hidma-mgmt | 97 +++
.../devicetree/bindings/dma/qcom_hidma.txt | 18 +
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 61 ++
drivers/dma/Kconfig| 11 +-
drivers/dma/Makefile | 2 +-
drivers/dma/qcom/Kconfig | 29 +
drivers/dma/qcom/Makefile | 4 +
drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 4 +-
drivers/dma/qcom/hidma.c | 716
drivers/dma/qcom/hidma.h | 161
drivers/dma/qcom/hidma_dbg.c | 219 +
drivers/dma/qcom/hidma_ll.c| 927 +
drivers/dma/qcom/hidma_mgmt.c | 318 +++
drivers/dma/qcom/hidma_mgmt.h | 39 +
drivers/dma/qcom/hidma_mgmt_sys.c | 292 +++
15 files changed, 2886 insertions(+), 12 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
create mode 100644 drivers/dma/qcom/Kconfig
create mode 100644 drivers/dma/qcom/Makefile
rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
create mode 100644 drivers/dma/qcom/hidma.c
create mode 100644 drivers/dma/qcom/hidma.h
create mode 100644 drivers/dma/qcom/hidma_dbg.c
create mode 100644 drivers/dma/qcom/hidma_ll.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.h
create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 3/3] dma: add Qualcomm Technologies HIDMA channel driver
On 12/1/2015 6:34 AM, Vinod Koul wrote:
> On Mon, Nov 30, 2015 at 03:06:36PM -0500, Sinan Kaya wrote:
>> I have split the debugfs support from this patch to its own patch. Any
>> other idea on how else you'd break the code? I can take one more step
>> and separate the lower layer from the OS layer by using stub functions
>> on the initial commit.
>
> Yes the ll.c can be a separate patch and no need to add placeholders as
> makefile can be last
>
ok. I'll create a new patch file with the Makefile and hidma_ll.c only.
>>>
>>>> +static enum dma_status hidma_tx_status(struct dma_chan *dmach,
>>>> + dma_cookie_t cookie, struct dma_tx_state *txstate)
>>>> +{
>>>> + struct hidma_chan *mchan = to_hidma_chan(dmach);
>>>> + enum dma_status ret;
>>>> +
>>>> + if (mchan->paused)
>>>> + ret = DMA_PAUSED;
>>>
>>> This is not quite right. The status query is for a descriptor and NOT for
>>> channel. Here if the descriptor queried was running then it would be paused
>>> for the rest pending txn, it would be DMA_IN_PROGRESS.
>>
>> The channel can be paused by the hypervisor. If it is paused, then no
>> other transaction will go through including the pending requests. That's
>> why, I'm checking the state first.
>
> You are missing the point. Channel can be paused, yes but the descriptor
> is in queue and is not paused. The descriptor running is paused, yes.
> There is subtle difference between these
I'll follow your recommendation. PAUSE for the currently active
descriptor and DMA_IN_PROGRESS for the rest.
>
>>>> +static dma_cookie_t hidma_tx_submit(struct dma_async_tx_descriptor *txd)
>>>> +{
>>>> + struct hidma_chan *mchan = to_hidma_chan(txd->chan);
>>>> + struct hidma_dev *dmadev = mchan->dmadev;
>>>> + struct hidma_desc *mdesc;
>>>> + unsigned long irqflags;
>>>> + dma_cookie_t cookie;
>>>> +
>>>> + if (!hidma_ll_isenabled(dmadev->lldev))
>>>> + return -ENODEV;
>>>
>>> is this not too late for this check, you should fail this on prepare
>>> method
>>
>> The channels can be paused by the hypervisor at runtime after the guest
>> OS boot. The client might have allocated the channels during guest
>> machine boot. If a channel is paused and client makes a request, client
>> will never get the callback. By placing this check, I'm looking at the
>> runtime status of the channel and rejecting the transmit request right
>> ahead.
>
> In this case you have request already given to you, here the request is
> submitted to the pending queue,
No, it is not. Putting into the pending queue is done after this check
not before.
I'm rejecting the queue request directly here as HIDMA channel is no
longer functional. I'd rather do active error handling rather than
passive error handling. Debugging of passive faults are much more difficult.
> if hypervisor has paused you, so the entire
> txn queue is paused. But from API semantics I would argue that this should be
> accepted and suffer the same fate as already submitted txns
>
>>
>>>
>>>
>>>> +static int hidma_alloc_chan_resources(struct dma_chan *dmach)
>>>> +{
>>>> + struct hidma_chan *mchan = to_hidma_chan(dmach);
>>>> + struct hidma_dev *dmadev = mchan->dmadev;
>>>> + struct hidma_desc *mdesc, *tmp;
>>>> + unsigned long irqflags;
>>>> + LIST_HEAD(descs);
>>>> + unsigned int i;
>>>> + int rc = 0;
>>>> +
>>>> + if (mchan->allocated)
>>>> + return 0;
>>>> +
>>>> + /* Alloc descriptors for this channel */
>>>> + for (i = 0; i < dmadev->nr_descriptors; i++) {
>>>> + mdesc = kzalloc(sizeof(struct hidma_desc), GFP_KERNEL);
>>>
>>> GFP_NOWAIT pls, this can be called from atomic context
>>
>> I'll change it, but why would anyone allocate a channel in an interrupt
>> handler?
>
> remember this is dmaengine, where people traditionally wanted to offload
> from cpu and were not allowed to sleep.
>
> I think am okay with this one..
>
>>
>>>
>>>> + if (!mdesc) {
>>>> + rc = -ENOMEM;
>>>> + break;
>>>> + }
>>>> + dma_async_tx_descriptor_init(>desc, dmach);
>>>> + mdesc->desc.flags = DMA_CTRL_ACK;
>>>
>>> what is the purp
Re: [PATCH V7 2/3] dma: add Qualcomm Technologies HIDMA management driver
On 11/30/2015 10:17 PM, Vinod Koul wrote:
> On Mon, Nov 30, 2015 at 09:42:01AM -0500, Sinan Kaya wrote:
>
>>>> +static int hidma_mgmt_probe(struct platform_device *pdev)
>>>> +{
>>>> + struct hidma_mgmt_dev *mgmtdev;
>>>> + struct resource *res;
>>>> + void __iomem *virtaddr;
>>>> + int irq;
>>>> + int rc;
>>>> + u32 val;
>>>> +
>>>> + pm_runtime_set_autosuspend_delay(>dev, AUTOSUSPEND_TIMEOUT);
>>>> + pm_runtime_use_autosuspend(>dev);
>>>> + pm_runtime_set_active(>dev);
>>>> + pm_runtime_enable(>dev);
>>>
>>> at this time pm core will treat device as fully enabled and pm methods can
>>> be invoked, but you are not ready yet right. Typically these are done at the
>>> end of the probe unless you have a reason...
>>
>> I need it here because the clocks are declared as ACPI power resources.
>> The kernel is turning off all power resources during initialization. In
>> order for this code to touch the hardware, I need to call enable so that
>> clocks are enabled once again.
>
> The question is are you ready in your driver routines to be invoked by pm
> core?
>
I don't have any support for suspend and resume PM APIs. The only PM
interface I support is PM runtime. PM can turn on/off the clocks based
on the reference counts it maintains after get/set APIs. Since PM is
turning off the clocks during power up before my driver load, I do need
to grab this lock to re-enable it during HW initialization. Then, let PM
turn off the clocks again after the AUTOSUSPEND_TIMEOUT when I'm done.
Is there any other interaction with the PM that I'm not aware of?
>>
>>>
>>>> +static ssize_t show_values(struct device *dev, struct device_attribute
>>>> *attr,
>>>> + char *buf)
>>>
>>> Please fix the coding style here and other places as well.
>>
>> what's the problem here?
>>
>>> Specifically
>>> please read Chapter 2
>>>
>>
>> Why is checkpatch not complaining about any of the coding style issues?
>> I'm checking my code with checkpatch before submitting. Is there any
>> other tool that would catch this?
>
> So did you read the Chapter 2.. Quoting here
>
I did read the chapter 2. Maybe, my lack of native english speaking but
I don't get from this sentence that function parameters need to be
aligned to the opening paranthesis.
> Descendants are always substantially shorter than the parent
> and are placed substantially to the right. The same applies to function
> headers
> with a long argument list.
>
I ran Lindent and manually cleaned up the junk it introduced. The result
is this
static ssize_t show_values(struct device *dev, struct device_attribute
*attr,
char *buf)
> Your breaking lines is not placed substantially to the right..
> I do not think checkpatch is checking this..
>
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 3/3] dma: add Qualcomm Technologies HIDMA channel driver
On 11/30/2015 3:59 AM, Vinod Koul wrote:
> On Sun, Nov 22, 2015 at 09:28:25PM -0500, Sinan Kaya wrote:
>> This patch adds support for hidma engine. The driver consists
>> of two logical blocks. The DMA engine interface and the
>> low-level interface. The hardware only supports memcpy/memset
>> and this driver only support memcpy interface. HW and driver
>> doesn't support slave interface.
>>
>> Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
>> ---
>> .../devicetree/bindings/dma/qcom_hidma.txt | 18 +
>> drivers/dma/qcom/Kconfig | 10 +
>> drivers/dma/qcom/Makefile | 2 +
>> drivers/dma/qcom/hidma.c | 706
>> drivers/dma/qcom/hidma.h | 157
>> drivers/dma/qcom/hidma_dbg.c | 217 +
>> drivers/dma/qcom/hidma_ll.c| 924
>> +
>> 7 files changed, 2034 insertions(+)
>
> This was one of the reasons for slow review of this. I started few times but
> large patches made this getting pushed back
>
> Pls help reviewers by splitting your code which looking at this could have
> been done
I have split the debugfs support from this patch to its own patch. Any
other idea on how else you'd break the code? I can take one more step
and separate the lower layer from the OS layer by using stub functions
on the initial commit.
>
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> Do you need so many headers...?
probably not, let me see what I can do about them.
>
>> +MODULE_PARM_DESC(event_channel_idx,
>> +"event channel index array for the notifications");
>
> Can you explain this parameter in detail pls
OK. I added the following comment to the code.
/*
* Each DMA channel is associated with an event channel for interrupt
* delivery. The event channel index usually comes from the firmware through
* ACPI/DT. When a HIDMA channel is executed in the guest machine
context (QEMU)
* the device tree gets auto-generated based on the memory and IRQ resources
* this driver uses on the host machine. Any device specific parameter
such as
* event-channel gets ignored by the QEMU.
* We are using this command line parameter to pass the event channel
index to
* the guest machine.
*/
s
>
>> +static void hidma_callback(void *data)
>> +{
>> +struct hidma_desc *mdesc = data;
>> +struct hidma_chan *mchan = to_hidma_chan(mdesc->desc.chan);
>> +struct dma_device *ddev = mchan->chan.device;
>> +struct hidma_dev *dmadev = to_hidma_dev(ddev);
>> +unsigned long irqflags;
>> +bool queued = false;
>> +
>> +spin_lock_irqsave(>lock, irqflags);
>> +if (mdesc->node.next) {
>> +/* Delete from the active list, add to completed list */
>> +list_move_tail(>node, >completed);
>> +queued = true;
>> +}
>> +spin_unlock_irqrestore(>lock, irqflags);
>> +
>> +hidma_process_completed(dmadev);
>> +
>> +if (queued) {
>> +pm_runtime_mark_last_busy(dmadev->ddev.dev);
>> +pm_runtime_put_autosuspend(dmadev->ddev.dev);
>> +}
>> +}
>
> Callback is typically referred to client callback upon dma completion, can
> you explain what you are trying to do here
When a DMA transfer completes, the hidma_callback function in the
hidma.c file gets called from the lower layer (hidma_ll.c) in order to
move this request from active queue into the completed queue.
hidma_process_completed eventually calls the "client callback" in it.
The PM stuff is for guaranteeing that clocks are not turned off while HW
is working on it.
I grab the PM lock in issue pending and release it in the hidma_callback.
>
>> +static int hidma_chan_init(struct hidma_dev *dmadev, u32 dma_sig)
>> +{
>> +struct hidma_chan *mchan;
>> +struct dma_device *ddev;
>> +
>> +mchan = devm_kzalloc(dmadev->ddev.dev, sizeof(*mchan), GFP_KERNEL);
>> +if (!mchan)
>> +return -ENOMEM;
>> +
>> +ddev = >ddev;
>> +mchan->dma_sig = dma_sig;
>> +mchan->dmadev = dmadev;
>> +mchan->chan.device = ddev;
>> +dma_cookie_init(
Re: [PATCH V7 2/3] dma: add Qualcomm Technologies HIDMA management driver
On 11/30/2015 3:21 AM, Vinod Koul wrote:
> On Sun, Nov 22, 2015 at 09:28:24PM -0500, Sinan Kaya wrote:
>
>> +++ b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
>> @@ -0,0 +1,97 @@
>> +What: /sys/devices/platform/hidma-mgmt*/chan*/priority
>> +/sys/devices/platform/QCOM8060:*/chan*/priority
>> +Date: Nov 2015
>> +KernelVersion: 4.4
>> +Contact:"Sinan Kaya <ok...@cudeaurora.org>"
>> +Description:
>> +Contains either 0 or 1 and indicates if the DMA channel is a
>> +low priority (0) or high priority (1) channel.
>
> What is purpose of adding sysfs entries here ?
>
The goal is to run hidma channels in the guest machines and have
management driver adjust the runtime characteristics of the channels
such as round robing weight, priority, max read request etc. All of
these are runtime configurable.
There will be a userspace application that will configure this on behalf
of the system administrator via sysfs. System administrator will decide
how to allocate hardware resources to the guest machines.
>> +
>> +#define QOS_N_OFFSET0x300
>> +#define CFG_OFFSET 0x400
>> +#define MAX_BUS_REQ_LEN_OFFSET 0x41C
>> +#define MAX_XACTIONS_OFFSET 0x420
>> +#define HW_VERSION_OFFSET 0x424
>> +#define CHRESET_TIMEOUT_OFFSET 0x418
>> +
>> +#define MAX_WR_XACTIONS_MASKGENMASK(4, 0)
>> +#define MAX_RD_XACTIONS_MASKGENMASK(4, 0)
>> +#define WEIGHT_MASK GENMASK(6, 0)
>> +#define MAX_BUS_REQ_LEN_MASKGENMASK(15, 0)
>> +#define CHRESET_TIMEOUUT_MASK GENMASK(19, 0)
>> +
>> +#define MAX_WR_XACTIONS_BIT_POS 16
>> +#define MAX_BUS_WR_REQ_BIT_POS 16
>> +#define WRR_BIT_POS 8
>> +#define PRIORITY_BIT_POS15
>> +
>> +#define AUTOSUSPEND_TIMEOUT 2000
>> +#define MAX_CHANNEL_WEIGHT 15
>
> These names are quite generic and prone to collide with generic names,
> please prefix them with your driver name
>
OK
>> +}
>> +EXPORT_SYMBOL_GPL(hidma_mgmt_setup);
>
> Why is this exported or rather who would be users of this?
This driver consists of two files as hidma_mgmt.c and hidma_mgmt_sys.c.
I'm calling hidma_mgmt_setup from the hidma_mgmt_sys.c file when a
parameter such as priority and weight is changed to reconfigure the
hardware. I got linker errors without this export as this function is in
hidma_mgmt.c file.
>
>> +static int hidma_mgmt_probe(struct platform_device *pdev)
>> +{
>> +struct hidma_mgmt_dev *mgmtdev;
>> +struct resource *res;
>> +void __iomem *virtaddr;
>> +int irq;
>> +int rc;
>> +u32 val;
>> +
>> +pm_runtime_set_autosuspend_delay(>dev, AUTOSUSPEND_TIMEOUT);
>> +pm_runtime_use_autosuspend(>dev);
>> +pm_runtime_set_active(>dev);
>> +pm_runtime_enable(>dev);
>
> at this time pm core will treat device as fully enabled and pm methods can
> be invoked, but you are not ready yet right. Typically these are done at the
> end of the probe unless you have a reason...
I need it here because the clocks are declared as ACPI power resources.
The kernel is turning off all power resources during initialization. In
order for this code to touch the hardware, I need to call enable so that
clocks are enabled once again.
>
>> +static ssize_t show_values(struct device *dev, struct device_attribute
>> *attr,
>> +char *buf)
>
> Please fix the coding style here and other places as well.
what's the problem here?
> Specifically
> please read Chapter 2
>
Why is checkpatch not complaining about any of the coding style issues?
I'm checking my code with checkpatch before submitting. Is there any
other tool that would catch this?
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 1/3] dma: qcom_bam_dma: move to qcom directory
On 11/25/2015 4:42 PM, Andy Gross wrote: > On Sun, Nov 22, 2015 at 09:28:23PM -0500, Sinan Kaya wrote: >> Creating a QCOM directory for all QCOM DMA source files. >> >> Signed-off-by: Sinan Kaya <ok...@codeaurora.org> >> --- > > Kind of nice having a different directory. > > Reviewed-by: Andy Gross <agr...@codeaurora.org> > thanks -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V7 2/3] dma: add Qualcomm Technologies HIDMA management driver
On 11/23/2015 1:06 PM, Andy Shevchenko wrote: > Thanks for an update! > > Looks cool! Though still few errors spelling and style nitpicks (you > may ignore them if you wish) below. > > Reviewed-by: Andy Shevchenko <andy.shevche...@gmail.com> Thanks, I'll post an updated version next week. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 2/3] dma: add Qualcomm Technologies HIDMA management driver
>>> >>> Can it be like >>> >>> /sys/…/DEVICExx/ >>> channelYY/ >>> attr1 >>> attr2 >>> … >>> >>> ? >> >> I'll work on it. I didn't know that you are allowed to create subdirectories >> in sysfs. I was just creating attributes to keep it simple. But, your >> suggestion is cleaner. >> >>> >>> I think it will be easier to handle in code and from user. (Similar >>> way DMAEngine API does for slave DMA devices) >> >> Now, the good stuff. Can you clarify your comment? I didn't understand it. > > I meant that DMAEngine uses > /sys/class/dma > dmaYchannelX/ > attr1 > attr2 > … > > layout. > I have posted v7 with this change. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V7 0/3] dma: add Qualcomm Technologies HIDMA driver
The Qualcomm Technologies HIDMA device has been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design.
1. HIDMA Management driver
2. HIDMA Channel driver
Each HIDMA HW consists of multiple channels. These channels
share some set of common parameters. These parameters are
initialized by the management driver during power up.
Same management driver is used for monitoring the execution
of the channels. Management driver can change the performance
behavior dynamically such as bandwidth allocation and
prioritization in the future.
The management driver is executed in hypervisor context and
is the main management entity for all channels provided by
the device.
Changes from V6: (https://lkml.org/lkml/2015/11/22/111)
* none
Changes from V6: (https://lkml.org/lkml/2015/11/22/112)
* remove extra _ in documentation
* remove extra parenthesis in assignments
* create subdirectories for channels in sysfs
Changes from V6: (https://lkml.org/lkml/2015/11/22/113)
* remove extra parenthesis
Sinan Kaya (3):
dma: qcom_bam_dma: move to qcom directory
dma: add Qualcomm Technologies HIDMA management driver
dma: add Qualcomm Technologies HIDMA channel driver
.../ABI/testing/sysfs-platform-hidma-mgmt | 97 +++
.../devicetree/bindings/dma/qcom_hidma.txt | 18 +
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 61 ++
drivers/dma/Kconfig| 11 +-
drivers/dma/Makefile | 2 +-
drivers/dma/qcom/Kconfig | 29 +
drivers/dma/qcom/Makefile | 4 +
drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 4 +-
drivers/dma/qcom/hidma.c | 706
drivers/dma/qcom/hidma.h | 157
drivers/dma/qcom/hidma_dbg.c | 217 +
drivers/dma/qcom/hidma_ll.c| 924 +
drivers/dma/qcom/hidma_mgmt.c | 308 +++
drivers/dma/qcom/hidma_mgmt.h | 39 +
drivers/dma/qcom/hidma_mgmt_sys.c | 299 +++
15 files changed, 2864 insertions(+), 12 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
create mode 100644 drivers/dma/qcom/Kconfig
create mode 100644 drivers/dma/qcom/Makefile
rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
create mode 100644 drivers/dma/qcom/hidma.c
create mode 100644 drivers/dma/qcom/hidma.h
create mode 100644 drivers/dma/qcom/hidma_dbg.c
create mode 100644 drivers/dma/qcom/hidma_ll.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.h
create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V7 3/3] dma: add Qualcomm Technologies HIDMA channel driver
This patch adds support for hidma engine. The driver consists
of two logical blocks. The DMA engine interface and the
low-level interface. The hardware only supports memcpy/memset
and this driver only support memcpy interface. HW and driver
doesn't support slave interface.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
.../devicetree/bindings/dma/qcom_hidma.txt | 18 +
drivers/dma/qcom/Kconfig | 10 +
drivers/dma/qcom/Makefile | 2 +
drivers/dma/qcom/hidma.c | 706
drivers/dma/qcom/hidma.h | 157
drivers/dma/qcom/hidma_dbg.c | 217 +
drivers/dma/qcom/hidma_ll.c| 924 +
7 files changed, 2034 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
create mode 100644 drivers/dma/qcom/hidma.c
create mode 100644 drivers/dma/qcom/hidma.h
create mode 100644 drivers/dma/qcom/hidma_dbg.c
create mode 100644 drivers/dma/qcom/hidma_ll.c
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma.txt
b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
new file mode 100644
index 000..d18c8fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
@@ -0,0 +1,18 @@
+Qualcomm Technologies HIDMA Channel driver
+
+Required properties:
+- compatible: must contain "qcom,hidma-1.0"
+- reg: Addresses for the transfer and event channel
+- interrupts: Should contain the event interrupt
+- desc-count: Number of asynchronous requests this channel can handle
+- event-channel: The HW event channel completions will be delivered.
+Example:
+
+ hidma_24: dma-controller@0x5c05 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c05 0x0 0x1000>,
+ <0 0x5c0b 0x0 0x1000>;
+ interrupts = <0 389 0>;
+ desc-count = <10>;
+ event-channel = <4>;
+ };
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index ebe5b8c..5588e1c 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -17,3 +17,13 @@ config QCOM_HIDMA_MGMT
start managing the channels. In a virtualized environment,
the guest OS would run QCOM_HIDMA channel driver and the
hypervisor would run the QCOM_HIDMA_MGMT management driver.
+
+config QCOM_HIDMA
+ tristate "Qualcomm Technologies HIDMA Channel support"
+ select DMA_ENGINE
+ help
+ Enable support for the Qualcomm Technologies HIDMA controller.
+ The HIDMA controller supports optimized buffer copies
+ (user to kernel, kernel to kernel, etc.). It only supports
+ memcpy interface. The core is not intended for general
+ purpose slave DMA.
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index 1a5a96d..f702df1 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,2 +1,4 @@
obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
obj-$(CONFIG_QCOM_HIDMA_MGMT) += hidma_mgmt.o hidma_mgmt_sys.o
+obj-$(CONFIG_QCOM_HIDMA) += hdma.o
+hdma-objs:= hidma_ll.o hidma.o hidma_dbg.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
new file mode 100644
index 000..c0c7f44
--- /dev/null
+++ b/drivers/dma/qcom/hidma.c
@@ -0,0 +1,706 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine interface
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
+ * Copyright (C) Semihalf 2009
+ * Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2014
+ *
+ * Written by Piotr Ziecik <ko...@semihalf.com>. Hardware description
+ * (defines, structures and comments) was taken from MPC5121 DMA driver
+ * written by Hongjun Chen <hong-jun.c...@freescale.com>.
+ *
+ * Approved as OSADL project by a majority of OSADL members and funded
+ * by OSADL membership fees in 2009; for details see www.osadl.org.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY
[PATCH V7 2/3] dma: add Qualcomm Technologies HIDMA management driver
The Qualcomm Technologies HIDMA device has been designed to support virtualization technology. The driver has been divided into two to follow the hardware design. 1. HIDMA Management driver 2. HIDMA Channel driver Each HIDMA HW consists of multiple channels. These channels share some set of common parameters. These parameters are initialized by the management driver during power up. Same management driver is used for monitoring the execution of the channels. Management driver can change the performance behavior dynamically such as bandwidth allocation and prioritization. The management driver is executed in hypervisor context and is the main management entity for all channels provided by the device. Signed-off-by: Sinan Kaya <ok...@codeaurora.org> --- .../ABI/testing/sysfs-platform-hidma-mgmt | 97 +++ .../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 61 drivers/dma/qcom/Kconfig | 11 + drivers/dma/qcom/Makefile | 1 + drivers/dma/qcom/hidma_mgmt.c | 308 + drivers/dma/qcom/hidma_mgmt.h | 39 +++ drivers/dma/qcom/hidma_mgmt_sys.c | 299 7 files changed, 816 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt create mode 100644 drivers/dma/qcom/hidma_mgmt.c create mode 100644 drivers/dma/qcom/hidma_mgmt.h create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c diff --git a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt new file mode 100644 index 000..4fc6876 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt @@ -0,0 +1,97 @@ +What: /sys/devices/platform/hidma-mgmt*/chan*/priority + /sys/devices/platform/QCOM8060:*/chan*/priority +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains either 0 or 1 and indicates if the DMA channel is a + low priority (0) or high priority (1) channel. + +What: /sys/devices/platform/hidma-mgmt*/chan*/weight + /sys/devices/platform/QCOM8060:*/chan*/weight +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains 0..15 and indicates the weight of the channel among + equal priority channels during round robin scheduling. + +What: /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles + /sys/devices/platform/QCOM8060:*/chreset_timeout_cycles +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains the platform specific cycle value to wait after a + reset command is issued. If the value is chosen too short, + then the HW will issue a reset failure interrupt. The value + is platform specific and should not be changed without + consultance. + +What: /sys/devices/platform/hidma-mgmt*/dma_channels + /sys/devices/platform/QCOM8060:*/dma_channels +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains the number of dma channels supported by one instance + of HIDMA hardware. The value may change from chip to chip. + +What: /sys/devices/platform/hidma-mgmt*/hw_version_major + /sys/devices/platform/QCOM8060:*/hw_version_major +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Version number major for the hardware. + +What: /sys/devices/platform/hidma-mgmt*/hw_version_minor + /sys/devices/platform/QCOM8060:*/hw_version_minor +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Version number minor for the hardware. + +What: /sys/devices/platform/hidma-mgmt*/max_rd_xactions + /sys/devices/platform/QCOM8060:*/max_rd_xactions +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains a value between 0 and 31. Maximum number of + read transactions that can be issued back to back. + Choosing a higher number gives better performance but + can also cause performance reduction to other peripherals + sharing the same bus. + +What: /sys/devices/platform/hidma-mgmt*/max_read_request + /sys/devices/platform/QCOM8060:*/max_read
[PATCH V7 1/3] dma: qcom_bam_dma: move to qcom directory
Creating a QCOM directory for all QCOM DMA source files.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/dma/Kconfig| 11 ++-
drivers/dma/Makefile | 2 +-
drivers/dma/qcom/Kconfig | 8
drivers/dma/qcom/Makefile | 1 +
drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 4 ++--
5 files changed, 14 insertions(+), 12 deletions(-)
create mode 100644 drivers/dma/qcom/Kconfig
create mode 100644 drivers/dma/qcom/Makefile
rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index b458475..47b1b98 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -408,15 +408,6 @@ config PXA_DMA
16 to 32 channels for peripheral to memory or memory to memory
transfers.
-config QCOM_BAM_DMA
- tristate "QCOM BAM DMA support"
- depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
- select DMA_ENGINE
- select DMA_VIRTUAL_CHANNELS
- ---help---
- Enable support for the QCOM BAM DMA controller. This controller
- provides DMA capabilities for a variety of on-chip devices.
-
config SIRF_DMA
tristate "CSR SiRFprimaII/SiRFmarco DMA support"
depends on ARCH_SIRF
@@ -527,6 +518,8 @@ config ZX_DMA
# driver files
source "drivers/dma/bestcomm/Kconfig"
+source "drivers/dma/qcom/Kconfig"
+
source "drivers/dma/dw/Kconfig"
source "drivers/dma/hsu/Kconfig"
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 7711a71..8dba90d 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_PCH_DMA) += pch_dma.o
obj-$(CONFIG_PL330_DMA) += pl330.o
obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
obj-$(CONFIG_PXA_DMA) += pxa_dma.o
-obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
obj-$(CONFIG_RENESAS_DMA) += sh/
obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
@@ -66,4 +65,5 @@ obj-$(CONFIG_TI_EDMA) += edma.o
obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
+obj-y += qcom/
obj-y += xilinx/
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
new file mode 100644
index 000..f17c272
--- /dev/null
+++ b/drivers/dma/qcom/Kconfig
@@ -0,0 +1,8 @@
+config QCOM_BAM_DMA
+ tristate "QCOM BAM DMA support"
+ depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ ---help---
+ Enable support for the QCOM BAM DMA controller. This controller
+ provides DMA capabilities for a variety of on-chip devices.
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
new file mode 100644
index 000..f612ae3
--- /dev/null
+++ b/drivers/dma/qcom/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom/bam_dma.c
similarity index 99%
rename from drivers/dma/qcom_bam_dma.c
rename to drivers/dma/qcom/bam_dma.c
index 5a250cd..b6f053d 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -49,8 +49,8 @@
#include
#include
-#include "dmaengine.h"
-#include "virt-dma.h"
+#include "../dmaengine.h"
+#include "../virt-dma.h"
struct bam_desc_hw {
u32 addr; /* Buffer physical address */
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V6 0/3] dma: add Qualcomm Technologies HIDMA driver
been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design.
1. HIDMA Management driver
2. HIDMA Channel driver
Each HIDMA HW consists of multiple channels. These channels
share some set of common parameters. These parameters are
initialized by the management driver during power up.
Same management driver is used for monitoring the execution
of the channels. Management driver can change the performance
behavior dynamically such as bandwidth allocation and
prioritization in the future.
The management driver is executed in hypervisor context and
is the main management entity for all channels provided by
the device.
Changes from V5: (https://lkml.org/lkml/2015/11/15/135)
* none
Changes from V5: (https://lkml.org/lkml/2015/11/15/136)
* forgot to remove duplicate rc assignment.
* add missing _iomem from sparse warning.
* Add sysfs ABI documentation
Changes from V5: (https://lkml.org/lkml/2015/11/15/137)
* Remove pm lock in ISR as it is redundant caught in lockdep.
* sparse warning for missing _iomem.
* sparse warning for static required.
Sinan Kaya (3):
dma: qcom_bam_dma: move to qcom directory
dma: add Qualcomm Technologies HIDMA management driver
dma: add Qualcomm Technologies HIDMA channel driver
.../ABI/testing/sysfs-platform-hidma-mgmt | 97 +++
.../devicetree/bindings/dma/qcom_hidma.txt | 18 +
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 61 ++
drivers/dma/Kconfig| 11 +-
drivers/dma/Makefile | 2 +-
drivers/dma/qcom/Kconfig | 29 +
drivers/dma/qcom/Makefile | 4 +
drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 4 +-
drivers/dma/qcom/hidma.c | 710
drivers/dma/qcom/hidma.h | 157
drivers/dma/qcom/hidma_dbg.c | 225 +
drivers/dma/qcom/hidma_ll.c| 930 +
drivers/dma/qcom/hidma_mgmt.c | 305 +++
drivers/dma/qcom/hidma_mgmt.h | 38 +
drivers/dma/qcom/hidma_mgmt_sys.c | 231 +
15 files changed, 2810 insertions(+), 12 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
create mode 100644 drivers/dma/qcom/Kconfig
create mode 100644 drivers/dma/qcom/Makefile
rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
create mode 100644 drivers/dma/qcom/hidma.c
create mode 100644 drivers/dma/qcom/hidma.h
create mode 100644 drivers/dma/qcom/hidma_dbg.c
create mode 100644 drivers/dma/qcom/hidma_ll.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.h
create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V6 1/3] dma: qcom_bam_dma: move to qcom directory
Creating a QCOM directory for all QCOM DMA source files.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/dma/Kconfig| 11 ++-
drivers/dma/Makefile | 2 +-
drivers/dma/qcom/Kconfig | 9 +
drivers/dma/qcom/Makefile | 1 +
drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 4 ++--
5 files changed, 15 insertions(+), 12 deletions(-)
create mode 100644 drivers/dma/qcom/Kconfig
create mode 100644 drivers/dma/qcom/Makefile
rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index b458475..47b1b98 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -408,15 +408,6 @@ config PXA_DMA
16 to 32 channels for peripheral to memory or memory to memory
transfers.
-config QCOM_BAM_DMA
- tristate "QCOM BAM DMA support"
- depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
- select DMA_ENGINE
- select DMA_VIRTUAL_CHANNELS
- ---help---
- Enable support for the QCOM BAM DMA controller. This controller
- provides DMA capabilities for a variety of on-chip devices.
-
config SIRF_DMA
tristate "CSR SiRFprimaII/SiRFmarco DMA support"
depends on ARCH_SIRF
@@ -527,6 +518,8 @@ config ZX_DMA
# driver files
source "drivers/dma/bestcomm/Kconfig"
+source "drivers/dma/qcom/Kconfig"
+
source "drivers/dma/dw/Kconfig"
source "drivers/dma/hsu/Kconfig"
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 7711a71..8dba90d 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_PCH_DMA) += pch_dma.o
obj-$(CONFIG_PL330_DMA) += pl330.o
obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
obj-$(CONFIG_PXA_DMA) += pxa_dma.o
-obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
obj-$(CONFIG_RENESAS_DMA) += sh/
obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
@@ -66,4 +65,5 @@ obj-$(CONFIG_TI_EDMA) += edma.o
obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
+obj-y += qcom/
obj-y += xilinx/
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
new file mode 100644
index 000..17545df
--- /dev/null
+++ b/drivers/dma/qcom/Kconfig
@@ -0,0 +1,9 @@
+config QCOM_BAM_DMA
+ tristate "QCOM BAM DMA support"
+ depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ ---help---
+ Enable support for the QCOM BAM DMA controller. This controller
+ provides DMA capabilities for a variety of on-chip devices.
+
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
new file mode 100644
index 000..f612ae3
--- /dev/null
+++ b/drivers/dma/qcom/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom/bam_dma.c
similarity index 99%
rename from drivers/dma/qcom_bam_dma.c
rename to drivers/dma/qcom/bam_dma.c
index 5a250cd..b6f053d 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -49,8 +49,8 @@
#include
#include
-#include "dmaengine.h"
-#include "virt-dma.h"
+#include "../dmaengine.h"
+#include "../virt-dma.h"
struct bam_desc_hw {
u32 addr; /* Buffer physical address */
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V6 3/3] dma: add Qualcomm Technologies HIDMA channel driver
This patch adds support for hidma engine. The driver consists
of two logical blocks. The DMA engine interface and the
low-level interface. The hardware only supports memcpy/memset
and this driver only support memcpy interface. HW and driver
doesn't support slave interface.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
v6
---
* Remove pm lock in ISR as it is redundant.
* sparse warning for missing _iomem.
* sparse warning for static required.
---
.../devicetree/bindings/dma/qcom_hidma.txt | 18 +
drivers/dma/qcom/Kconfig | 10 +
drivers/dma/qcom/Makefile | 2 +
drivers/dma/qcom/hidma.c | 710
drivers/dma/qcom/hidma.h | 157
drivers/dma/qcom/hidma_dbg.c | 225 +
drivers/dma/qcom/hidma_ll.c| 930 +
7 files changed, 2052 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
create mode 100644 drivers/dma/qcom/hidma.c
create mode 100644 drivers/dma/qcom/hidma.h
create mode 100644 drivers/dma/qcom/hidma_dbg.c
create mode 100644 drivers/dma/qcom/hidma_ll.c
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma.txt
b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
new file mode 100644
index 000..d18c8fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
@@ -0,0 +1,18 @@
+Qualcomm Technologies HIDMA Channel driver
+
+Required properties:
+- compatible: must contain "qcom,hidma-1.0"
+- reg: Addresses for the transfer and event channel
+- interrupts: Should contain the event interrupt
+- desc-count: Number of asynchronous requests this channel can handle
+- event-channel: The HW event channel completions will be delivered.
+Example:
+
+ hidma_24: dma-controller@0x5c05 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c05 0x0 0x1000>,
+ <0 0x5c0b 0x0 0x1000>;
+ interrupts = <0 389 0>;
+ desc-count = <10>;
+ event-channel = <4>;
+ };
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index ebe5b8c..5588e1c 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -17,3 +17,13 @@ config QCOM_HIDMA_MGMT
start managing the channels. In a virtualized environment,
the guest OS would run QCOM_HIDMA channel driver and the
hypervisor would run the QCOM_HIDMA_MGMT management driver.
+
+config QCOM_HIDMA
+ tristate "Qualcomm Technologies HIDMA Channel support"
+ select DMA_ENGINE
+ help
+ Enable support for the Qualcomm Technologies HIDMA controller.
+ The HIDMA controller supports optimized buffer copies
+ (user to kernel, kernel to kernel, etc.). It only supports
+ memcpy interface. The core is not intended for general
+ purpose slave DMA.
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index 1a5a96d..f702df1 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,2 +1,4 @@
obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
obj-$(CONFIG_QCOM_HIDMA_MGMT) += hidma_mgmt.o hidma_mgmt_sys.o
+obj-$(CONFIG_QCOM_HIDMA) += hdma.o
+hdma-objs:= hidma_ll.o hidma.o hidma_dbg.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
new file mode 100644
index 000..82f50b1
--- /dev/null
+++ b/drivers/dma/qcom/hidma.c
@@ -0,0 +1,710 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine interface
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
+ * Copyright (C) Semihalf 2009
+ * Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2014
+ *
+ * Written by Piotr Ziecik <ko...@semihalf.com>. Hardware description
+ * (defines, structures and comments) was taken from MPC5121 DMA driver
+ * written by Hongjun Chen <hong-jun.c...@freescale.com>.
+ *
+ * Approved as OSADL project by a majority of OSADL members and funded
+ * by OSADL membership fees in 2009; for details see www.osadl.org.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your
[PATCH V6 2/3] dma: add Qualcomm Technologies HIDMA management driver
The Qualcomm Technologies HIDMA device has been designed to support virtualization technology. The driver has been divided into two to follow the hardware design. 1. HIDMA Management driver 2. HIDMA Channel driver Each HIDMA HW consists of multiple channels. These channels share some set of common parameters. These parameters are initialized by the management driver during power up. Same management driver is used for monitoring the execution of the channels. Management driver can change the performance behavior dynamically such as bandwidth allocation and prioritization. The management driver is executed in hypervisor context and is the main management entity for all channels provided by the device. Signed-off-by: Sinan Kaya <ok...@codeaurora.org> v6 * forgot to remove duplicate rc assignment. * add missing _iomem from sparse warning. --- .../ABI/testing/sysfs-platform-hidma-mgmt | 97 +++ .../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 61 + drivers/dma/qcom/Kconfig | 10 + drivers/dma/qcom/Makefile | 1 + drivers/dma/qcom/hidma_mgmt.c | 305 + drivers/dma/qcom/hidma_mgmt.h | 38 +++ drivers/dma/qcom/hidma_mgmt_sys.c | 231 7 files changed, 743 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt create mode 100644 drivers/dma/qcom/hidma_mgmt.c create mode 100644 drivers/dma/qcom/hidma_mgmt.h create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c diff --git a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt new file mode 100644 index 000..f6f1ce1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt @@ -0,0 +1,97 @@ +What: /sys/devices/platform/hidma-mgmt*/channel*_priority + /sys/devices/platform/QCOM8060:*/channel*_priority +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains either 0 or 1 and indicates if the DMA channel is a + low priority (0) or high priority (1) channel. + +What: /sys/devices/platform/hidma-mgmt*/channel*_weight + /sys/devices/platform/QCOM8060:*/channel*__weight +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains 0..15 and indicates the weight of the channel among + equal priority channels during round robin scheduling. + +What: /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles + /sys/devices/platform/QCOM8060:*/chreset_timeout_cycles +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains the platform specific cycle value to wait after a + reset command is issued. If the value is chosen too short, + then the HW will issue a reset failure interrupt. The value + is platform specific and should not be changed without + consultance. + +What: /sys/devices/platform/hidma-mgmt*/dma_channels + /sys/devices/platform/QCOM8060:*/dma_channels +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains the number of dma channels supported by one instance + of HIDMA hardware. The value may change from chip to chip. + +What: /sys/devices/platform/hidma-mgmt*/hw_version_major + /sys/devices/platform/QCOM8060:*/hw_version_major +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Version number major for the hardware. + +What: /sys/devices/platform/hidma-mgmt*/hw_version_minor + /sys/devices/platform/QCOM8060:*/hw_version_minor +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Version number minor for the hardware. + +What: /sys/devices/platform/hidma-mgmt*/max_rd_xactions + /sys/devices/platform/QCOM8060:*/max_rd_xactions +Date: Nov 2015 +KernelVersion: 4.4 +Contact: "Sinan Kaya <ok...@cudeaurora.org>" +Description: + Contains a value between 0 and 31. Maximum number of + read transactions that can be issued back to back. + Choosing a higher number gives better performance but + can also cause performance reduction to other peripherals + sharing the same bus. + +What: /sys
Re: [PATCH V5 2/3] dma: add Qualcomm Technologies HIDMA management driver
On 11/16/2015 10:58 AM, Arnd Bergmann wrote: >> .../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 61 >> drivers/dma/qcom/Kconfig | 10 + >> drivers/dma/qcom/Makefile | 1 + >> drivers/dma/qcom/hidma_mgmt.c | 306 >> + >> drivers/dma/qcom/hidma_mgmt.h | 38 +++ >> drivers/dma/qcom/hidma_mgmt_sys.c | 231 > > Each sysfs file API you add needs a documentation in Documentation/ABI/. > > Arnd > I'm working on the sysfs documentation now. Is there any other question regarding the patch series? If not, I'd like to have a reviewed-by after the next post if acceptable. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 2/3] dma: add Qualcomm Technologies HIDMA management driver
On 11/16/2015 10:58 AM, Arnd Bergmann wrote: >> The management driver is executed in hypervisor context and >> > is the main management entity for all channels provided by >> > the device. > Sorry for asking this question so late, but can you explain what the > point is behind this? It seems counterintuitive to me to have a > DMA engine that is meant for speeding up memory-to-memory transfers > when you run it in a virtual machine where you either need to go > through a virtual IOMMU to set up page table entries, as that will > likely cause more performance overhead than you could possibly > gain, or you assume that all the guest memory is pinned, which > in turn destroys a lot of the assumptions that we are making > in KVM to have useful VM guests. > > Where am I going wrong here? > The behavior of HIDMA is not any different from PCIe. We are using platform device pass through and giving the control of the entire HIDMA device to the guest machine. Therefore, we don’t need to trap into host machine for driver execution. I agree with the fact that the pages need to be pinned for this to work. Again, this is not any different from PCIe SRIOV passthrough. Pinning guest removes use cases like ballooning/overcommit but that is a choice for end user to make: whether he wants additional I/O performance or wants higher memory utilization at the cost of lower I/O performance. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3] acpi: add support for extended IRQ to PCI link
The ACPI compiler uses the extended format when used
interrupt numbers are greater than 256. The PCI link code
currently only supports simple interrupt format. The IRQ
numbers are represented using 32 bits when extended IRQ
syntax. This patch changes the interrupt number type to
32 bits and places an upper limit of 1020 as possible
interrupt id.
1020 is the maximum interrupt ID that can be assigned to
an ARM SPI interrupt according to ARM architecture.
Additional checks have been placed to prevent out of bounds
writes.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/acpi/pci_link.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
index 7c8408b..c13 100644
--- a/drivers/acpi/pci_link.c
+++ b/drivers/acpi/pci_link.c
@@ -1,6 +1,7 @@
/*
* pci_link.c - ACPI PCI Interrupt Link Device Driver ($Revision: 34 $)
*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
* Copyright (C) 2001, 2002 Andy Grover <andrew.gro...@intel.com>
* Copyright (C) 2001, 2002 Paul Diefenbaugh <paul.s.diefenba...@intel.com>
* Copyright (C) 2002 Dominik Brodowski <de...@brodo.de>
@@ -67,12 +68,12 @@ static struct acpi_scan_handler pci_link_handler = {
* later even the link is disable. Instead, we just repick the active irq
*/
struct acpi_pci_link_irq {
- u8 active; /* Current IRQ */
+ u32 active; /* Current IRQ */
u8 triggering; /* All IRQs */
u8 polarity;/* All IRQs */
u8 resource_type;
u8 possible_count;
- u8 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
+ u32 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
u8 initialized:1;
u8 reserved:7;
};
@@ -437,7 +438,11 @@ static int acpi_pci_link_set(struct acpi_pci_link *link,
int irq)
* enabled system.
*/
-#define ACPI_MAX_IRQS 256
+/*
+ * 1020 is the maximum interrupt ID that can be assigned to
+ * an ARM SPI interrupt according to ARM architecture.
+ */
+#define ACPI_MAX_IRQS 1020
#define ACPI_MAX_ISA_IRQ 16
#define PIRQ_PENALTY_PCI_AVAILABLE (0)
@@ -493,7 +498,8 @@ int __init acpi_irq_penalty_init(void)
penalty;
}
- } else if (link->irq.active) {
+ } else if (link->irq.active &&
+ (link->irq.active < ACPI_MAX_IRQS)) {
acpi_irq_penalty[link->irq.active] +=
PIRQ_PENALTY_PCI_POSSIBLE;
}
@@ -541,14 +547,16 @@ static int acpi_pci_link_allocate(struct acpi_pci_link
*link)
else
irq = link->irq.possible[link->irq.possible_count - 1];
- if (acpi_irq_balance || !link->irq.active) {
+ if ((acpi_irq_balance || !link->irq.active) && (irq < ACPI_MAX_IRQS)) {
/*
* Select the best IRQ. This is done in reverse to promote
* the use of IRQs 9, 10, 11, and >15.
*/
- for (i = (link->irq.possible_count - 1); i >= 0; i--) {
- if (acpi_irq_penalty[irq] >
- acpi_irq_penalty[link->irq.possible[i]])
+ i = link->irq.possible_count;
+ while (--i) {
+ if ((link->irq.possible[i] < ACPI_MAX_IRQS) &&
+ (acpi_irq_penalty[irq] >
+ acpi_irq_penalty[link->irq.possible[i]]))
irq = link->irq.possible[i];
}
}
@@ -568,7 +576,9 @@ static int acpi_pci_link_allocate(struct acpi_pci_link
*link)
acpi_device_bid(link->device));
return -ENODEV;
} else {
- acpi_irq_penalty[link->irq.active] += PIRQ_PENALTY_PCI_USING;
+ if (link->irq.active < ACPI_MAX_IRQS)
+ acpi_irq_penalty[link->irq.active] +=
+ PIRQ_PENALTY_PCI_USING;
printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n",
acpi_device_name(link->device),
acpi_device_bid(link->device), link->irq.active);
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 2/4] dma: add Qualcomm Technologies HIDMA management driver
On 11/12/2015 4:53 AM, Andy Shevchenko wrote:
> On Thu, Nov 12, 2015 at 8:41 AM, Sinan Kaya <ok...@codeaurora.org> wrote:
>> The Qualcomm Technologies HIDMA device has been designed
>> to support virtualization technology. The driver has been
>> divided into two to follow the hardware design.
>>
>> 1. HIDMA Management driver
>> 2. HIDMA Channel driver
>>
>> Each HIDMA HW consists of multiple channels. These channels
>> share some set of common parameters. These parameters are
>> initialized by the management driver during power up.
>> Same management driver is used for monitoring the execution
>> of the channels. Management driver can change the performance
>> behavior dynamically such as bandwidth allocation and
>> prioritization.
>>
>> The management driver is executed in hypervisor context and
>> is the main management entity for all channels provided by
>> the device.
>>
>> Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
>> ---
>> .../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 61
>> drivers/dma/qcom/Kconfig | 11 +
>> drivers/dma/qcom/Makefile | 1 +
>> drivers/dma/qcom/hidma_mgmt.c | 312
>> +
>> drivers/dma/qcom/hidma_mgmt.h | 38 +++
>> drivers/dma/qcom/hidma_mgmt_sys.c | 231 +++
>> 6 files changed, 654 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
>> create mode 100644 drivers/dma/qcom/hidma_mgmt.c
>> create mode 100644 drivers/dma/qcom/hidma_mgmt.h
>> create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c
>>
>> diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
>> b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
>> new file mode 100644
>> index 000..eb053b9
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
>> @@ -0,0 +1,61 @@
>> +Qualcomm Technologies HIDMA Management interface
>> +
>> +The Qualcomm Technologies HIDMA device has been designed
>> +to support virtualization technology. The driver has been
>> +divided into two to follow the hardware design. The management
>> +driver is executed in hypervisor context and is the main
>> +management entity for all channels provided by the device.
>> +
>> +Each HIDMA HW consists of multiple channels. These channels
>> +share some set of common parameters. These parameters are
>> +initialized by the management driver during power up.
>> +Same management driver is used for monitoring the execution
>> +of the channels. Management driver can change the performance
>> +behavior dynamically such as bandwidth allocation and
>> +prioritization.
>> +
>> +All channel devices get probed in the hypervisor
>> +context during power up. They show up as DMA engine
>> +DMA channels. Then, before starting the virtualization; each
>> +channel device is unbound from the hypervisor by VFIO
>> +and assign to the guest machine for control.
>> +
>> +This management driver will be used by the system
>> +admin to monitor/reset the execution state of the DMA
>> +channels. This will be the management interface.
>> +
>> +
>> +Required properties:
>> +- compatible: "qcom,hidma-mgmt-1.0";
>> +- reg: Address range for DMA device
>> +- dma-channels: Number of channels supported by this DMA controller.
>> +- max-write-burst-bytes: Maximum write burst in bytes. A memcpy requested is
>> + fragmented to multiples of this amount.
>> +- max-read-burst-bytes: Maximum read burst in bytes. A memcpy request is
>> + fragmented to multiples of this amount.
>> +- max-write-transactions: Maximum write transactions to perform in a burst
>> +- max-read-transactions: Maximum read transactions to perform in a burst
>> +- channel-reset-timeout-cycles: Channel reset timeout in cycles for this
>> SOC.
>> +- channel-priority: Priority of the channel.
>> + Each dma channel share the same HW bandwidth with other dma channels.
>> + If two requests reach to the HW at the same time from a low priority and
>> + high priority channel, high priority channel will claim the bus.
>> + 0=low priority, 1=high priority
>> +- channel-weight: Round robin weight of the channel
>> + Since there are only two priority levels supported, scheduling among
>> + the equal priority channels is done via weights.
>> +
>> +Example:
>> +
>> + hidma-mgmt@f9984000 = {
>>
[PATCH V5 2/3] dma: add Qualcomm Technologies HIDMA management driver
The Qualcomm Technologies HIDMA device has been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design.
1. HIDMA Management driver
2. HIDMA Channel driver
Each HIDMA HW consists of multiple channels. These channels
share some set of common parameters. These parameters are
initialized by the management driver during power up.
Same management driver is used for monitoring the execution
of the channels. Management driver can change the performance
behavior dynamically such as bandwidth allocation and
prioritization.
The management driver is executed in hypervisor context and
is the main management entity for all channels provided by
the device.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 61
drivers/dma/qcom/Kconfig | 10 +
drivers/dma/qcom/Makefile | 1 +
drivers/dma/qcom/hidma_mgmt.c | 306 +
drivers/dma/qcom/hidma_mgmt.h | 38 +++
drivers/dma/qcom/hidma_mgmt_sys.c | 231
6 files changed, 647 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
create mode 100644 drivers/dma/qcom/hidma_mgmt.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.h
create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
new file mode 100644
index 000..eb053b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -0,0 +1,61 @@
+Qualcomm Technologies HIDMA Management interface
+
+The Qualcomm Technologies HIDMA device has been designed
+to support virtualization technology. The driver has been
+divided into two to follow the hardware design. The management
+driver is executed in hypervisor context and is the main
+management entity for all channels provided by the device.
+
+Each HIDMA HW consists of multiple channels. These channels
+share some set of common parameters. These parameters are
+initialized by the management driver during power up.
+Same management driver is used for monitoring the execution
+of the channels. Management driver can change the performance
+behavior dynamically such as bandwidth allocation and
+prioritization.
+
+All channel devices get probed in the hypervisor
+context during power up. They show up as DMA engine
+DMA channels. Then, before starting the virtualization; each
+channel device is unbound from the hypervisor by VFIO
+and assign to the guest machine for control.
+
+This management driver will be used by the system
+admin to monitor/reset the execution state of the DMA
+channels. This will be the management interface.
+
+
+Required properties:
+- compatible: "qcom,hidma-mgmt-1.0";
+- reg: Address range for DMA device
+- dma-channels: Number of channels supported by this DMA controller.
+- max-write-burst-bytes: Maximum write burst in bytes. A memcpy requested is
+ fragmented to multiples of this amount.
+- max-read-burst-bytes: Maximum read burst in bytes. A memcpy request is
+ fragmented to multiples of this amount.
+- max-write-transactions: Maximum write transactions to perform in a burst
+- max-read-transactions: Maximum read transactions to perform in a burst
+- channel-reset-timeout-cycles: Channel reset timeout in cycles for this SOC.
+- channel-priority: Priority of the channel.
+ Each dma channel share the same HW bandwidth with other dma channels.
+ If two requests reach to the HW at the same time from a low priority and
+ high priority channel, high priority channel will claim the bus.
+ 0=low priority, 1=high priority
+- channel-weight: Round robin weight of the channel
+ Since there are only two priority levels supported, scheduling among
+ the equal priority channels is done via weights.
+
+Example:
+
+ hidma-mgmt@f9984000 = {
+ compatible = "qcom,hidma-mgmt-1.0";
+ reg = <0xf9984000 0x15000>;
+ dma-channels = 6;
+ max-write-burst-bytes = 1024;
+ max-read-burst-bytes = 1024;
+ max-write-transactions = 31;
+ max-read-transactions = 31;
+ channel-reset-timeout-cycles = 0x500;
+ channel-priority = < 1 1 0 0 0 0>;
+ channel-weight = < 1 13 10 3 4 5>;
+ };
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index 17545df..ebe5b8c 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -7,3 +7,13 @@ config QCOM_BAM_DMA
Enable support for the QCOM BAM DMA controller. This controller
provides DMA capabilities for a variety of on-chip devices.
+config QCOM_HIDMA_MGMT
+ tristate "Qualcomm Technologies HIDMA Management support"
+ s
[PATCH V5 3/3] dma: add Qualcomm Technologies HIDMA channel driver
This patch adds support for hidma engine. The driver consists
of two logical blocks. The DMA engine interface and the
low-level interface. The hardware only supports memcpy/memset
and this driver only support memcpy interface. HW and driver
doesn't support slave interface.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
.../devicetree/bindings/dma/qcom_hidma.txt | 18 +
drivers/dma/qcom/Kconfig | 10 +
drivers/dma/qcom/Makefile | 2 +
drivers/dma/qcom/hidma.c | 716
drivers/dma/qcom/hidma.h | 157
drivers/dma/qcom/hidma_dbg.c | 225 +
drivers/dma/qcom/hidma_ll.c| 930 +
7 files changed, 2058 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
create mode 100644 drivers/dma/qcom/hidma.c
create mode 100644 drivers/dma/qcom/hidma.h
create mode 100644 drivers/dma/qcom/hidma_dbg.c
create mode 100644 drivers/dma/qcom/hidma_ll.c
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma.txt
b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
new file mode 100644
index 000..d18c8fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
@@ -0,0 +1,18 @@
+Qualcomm Technologies HIDMA Channel driver
+
+Required properties:
+- compatible: must contain "qcom,hidma-1.0"
+- reg: Addresses for the transfer and event channel
+- interrupts: Should contain the event interrupt
+- desc-count: Number of asynchronous requests this channel can handle
+- event-channel: The HW event channel completions will be delivered.
+Example:
+
+ hidma_24: dma-controller@0x5c05 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c05 0x0 0x1000>,
+ <0 0x5c0b 0x0 0x1000>;
+ interrupts = <0 389 0>;
+ desc-count = <10>;
+ event-channel = <4>;
+ };
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index ebe5b8c..5588e1c 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -17,3 +17,13 @@ config QCOM_HIDMA_MGMT
start managing the channels. In a virtualized environment,
the guest OS would run QCOM_HIDMA channel driver and the
hypervisor would run the QCOM_HIDMA_MGMT management driver.
+
+config QCOM_HIDMA
+ tristate "Qualcomm Technologies HIDMA Channel support"
+ select DMA_ENGINE
+ help
+ Enable support for the Qualcomm Technologies HIDMA controller.
+ The HIDMA controller supports optimized buffer copies
+ (user to kernel, kernel to kernel, etc.). It only supports
+ memcpy interface. The core is not intended for general
+ purpose slave DMA.
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index 1a5a96d..f702df1 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,2 +1,4 @@
obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
obj-$(CONFIG_QCOM_HIDMA_MGMT) += hidma_mgmt.o hidma_mgmt_sys.o
+obj-$(CONFIG_QCOM_HIDMA) += hdma.o
+hdma-objs:= hidma_ll.o hidma.o hidma_dbg.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
new file mode 100644
index 000..2eabc80
--- /dev/null
+++ b/drivers/dma/qcom/hidma.c
@@ -0,0 +1,716 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine interface
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
+ * Copyright (C) Semihalf 2009
+ * Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2014
+ *
+ * Written by Piotr Ziecik <ko...@semihalf.com>. Hardware description
+ * (defines, structures and comments) was taken from MPC5121 DMA driver
+ * written by Hongjun Chen <hong-jun.c...@freescale.com>.
+ *
+ * Approved as OSADL project by a majority of OSADL members and funded
+ * by OSADL membership fees in 2009; for details see www.osadl.org.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY
[PATCH V5 1/3] dma: qcom_bam_dma: move to qcom directory
Creating a QCOM directory for all QCOM DMA source files.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/dma/Kconfig| 11 ++-
drivers/dma/Makefile | 2 +-
drivers/dma/qcom/Kconfig | 9 +
drivers/dma/qcom/Makefile | 1 +
drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 4 ++--
5 files changed, 15 insertions(+), 12 deletions(-)
create mode 100644 drivers/dma/qcom/Kconfig
create mode 100644 drivers/dma/qcom/Makefile
rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index b458475..47b1b98 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -408,15 +408,6 @@ config PXA_DMA
16 to 32 channels for peripheral to memory or memory to memory
transfers.
-config QCOM_BAM_DMA
- tristate "QCOM BAM DMA support"
- depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
- select DMA_ENGINE
- select DMA_VIRTUAL_CHANNELS
- ---help---
- Enable support for the QCOM BAM DMA controller. This controller
- provides DMA capabilities for a variety of on-chip devices.
-
config SIRF_DMA
tristate "CSR SiRFprimaII/SiRFmarco DMA support"
depends on ARCH_SIRF
@@ -527,6 +518,8 @@ config ZX_DMA
# driver files
source "drivers/dma/bestcomm/Kconfig"
+source "drivers/dma/qcom/Kconfig"
+
source "drivers/dma/dw/Kconfig"
source "drivers/dma/hsu/Kconfig"
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 7711a71..8dba90d 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_PCH_DMA) += pch_dma.o
obj-$(CONFIG_PL330_DMA) += pl330.o
obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
obj-$(CONFIG_PXA_DMA) += pxa_dma.o
-obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
obj-$(CONFIG_RENESAS_DMA) += sh/
obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
@@ -66,4 +65,5 @@ obj-$(CONFIG_TI_EDMA) += edma.o
obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
+obj-y += qcom/
obj-y += xilinx/
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
new file mode 100644
index 000..17545df
--- /dev/null
+++ b/drivers/dma/qcom/Kconfig
@@ -0,0 +1,9 @@
+config QCOM_BAM_DMA
+ tristate "QCOM BAM DMA support"
+ depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ ---help---
+ Enable support for the QCOM BAM DMA controller. This controller
+ provides DMA capabilities for a variety of on-chip devices.
+
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
new file mode 100644
index 000..f612ae3
--- /dev/null
+++ b/drivers/dma/qcom/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom/bam_dma.c
similarity index 99%
rename from drivers/dma/qcom_bam_dma.c
rename to drivers/dma/qcom/bam_dma.c
index 5a250cd..b6f053d 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -49,8 +49,8 @@
#include
#include
-#include "dmaengine.h"
-#include "virt-dma.h"
+#include "../dmaengine.h"
+#include "../virt-dma.h"
struct bam_desc_hw {
u32 addr; /* Buffer physical address */
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 0/3] add Qualcomm Technologies HIDMA driver
The Qualcomm Technologies HIDMA device has been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design.
1. HIDMA Management driver
2. HIDMA Channel driver
Each HIDMA HW consists of multiple channels. These channels
share some set of common parameters. These parameters are
initialized by the management driver during power up.
Same management driver is used for monitoring the execution
of the channels. Management driver can change the performance
behavior dynamically such as bandwidth allocation and
prioritization in the future.
The management driver is executed in hypervisor context and
is the main management entity for all channels provided by
the device.
Changes from V4: (https://lkml.org/lkml/2015/11/12/17)
* Restore copyright as it is a minor change.
Changes from V4: (https://lkml.org/lkml/2015/11/12/20)
* shorten variable names where possible.
* remove error check after platform_get_resource
* return the error code from device read functions
Changes from V4: (https://lkml.org/lkml/2015/11/12/19)
* remove dev_dbg messages
* seperate selftest code from the series
Sinan Kaya (3):
dma: qcom_bam_dma: move to qcom directory
dma: add Qualcomm Technologies HIDMA management driver
dma: add Qualcomm Technologies HIDMA channel driver
.../devicetree/bindings/dma/qcom_hidma.txt | 18 +
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 61 ++
drivers/dma/Kconfig| 11 +-
drivers/dma/Makefile | 2 +-
drivers/dma/qcom/Kconfig | 29 +
drivers/dma/qcom/Makefile | 4 +
drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 4 +-
drivers/dma/qcom/hidma.c | 716
drivers/dma/qcom/hidma.h | 157
drivers/dma/qcom/hidma_dbg.c | 225 +
drivers/dma/qcom/hidma_ll.c| 930 +
drivers/dma/qcom/hidma_mgmt.c | 306 +++
drivers/dma/qcom/hidma_mgmt.h | 38 +
drivers/dma/qcom/hidma_mgmt_sys.c | 231 +
14 files changed, 2720 insertions(+), 12 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
create mode 100644 drivers/dma/qcom/Kconfig
create mode 100644 drivers/dma/qcom/Makefile
rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
create mode 100644 drivers/dma/qcom/hidma.c
create mode 100644 drivers/dma/qcom/hidma.h
create mode 100644 drivers/dma/qcom/hidma_dbg.c
create mode 100644 drivers/dma/qcom/hidma_ll.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.h
create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 0/2] add self test code for DMA engine drivers
Changes from V4 (https://lkml.org/lkml/2015/11/12/18) * Seperate the series from HIDMA driver Sinan Kaya (2): dmaselftest: add memcpy selftest support functions dma: qcom_hidma: add self test hooks drivers/dma/dmaengine.h | 2 + drivers/dma/dmaselftest.c | 638 ++ drivers/dma/qcom/Makefile | 2 +- drivers/dma/qcom/hidma.c | 4 + 4 files changed, 645 insertions(+), 1 deletion(-) create mode 100644 drivers/dma/dmaselftest.c -- Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 1/2] dmaselftest: add memcpy selftest support functions
This patch adds supporting utility functions for selftest.
The intention is to share the self test code between
different drivers.
Supported test cases include:
1. dma_map_single
2. streaming DMA
3. coherent DMA
4. scatter-gather DMA
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/dma/dmaengine.h | 2 +
drivers/dma/dmaselftest.c | 638 ++
2 files changed, 640 insertions(+)
create mode 100644 drivers/dma/dmaselftest.c
diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
index 17f983a..05b5a84 100644
--- a/drivers/dma/dmaengine.h
+++ b/drivers/dma/dmaengine.h
@@ -86,4 +86,6 @@ static inline void dma_set_residue(struct dma_tx_state
*state, u32 residue)
state->residue = residue;
}
+int dma_selftest_memcpy(struct dma_device *dmadev);
+
#endif
diff --git a/drivers/dma/dmaselftest.c b/drivers/dma/dmaselftest.c
new file mode 100644
index 000..423a9a3
--- /dev/null
+++ b/drivers/dma/dmaselftest.c
@@ -0,0 +1,638 @@
+/*
+ * DMA self test code borrowed from Qualcomm Technologies HIDMA driver
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct test_result {
+ atomic_t counter;
+ wait_queue_head_t wq;
+ struct dma_device *dma;
+};
+
+static void dma_selftest_complete(void *arg)
+{
+ struct test_result *result = arg;
+ struct dma_device *dma = result->dma;
+
+ atomic_inc(>counter);
+ wake_up(>wq);
+ dev_dbg(dma->dev, "self test transfer complete :%d\n",
+ atomic_read(>counter));
+}
+
+/*
+ * Perform a transaction to verify the HW works.
+ */
+static int dma_selftest_sg(struct dma_device *dma,
+ struct dma_chan *chan, u64 size,
+ unsigned long flags)
+{
+ struct dma_async_tx_descriptor *tx;
+ struct sg_table sg_table;
+ struct scatterlist *sg;
+ struct test_result result;
+ dma_addr_t src, dest, dest_it;
+ u8 *src_buf, *dest_buf;
+ unsigned int i, j;
+ dma_cookie_t cookie;
+ int err;
+ int nents = 10, count;
+ bool free_channel = true;
+ int map_count;
+
+ init_waitqueue_head();
+ atomic_set(, 0);
+ result.dma = dma;
+
+ if (!chan)
+ return -ENOMEM;
+
+ if (dma->device_alloc_chan_resources(chan) < 1)
+ return -ENODEV;
+
+ if (!chan->device || !dma->dev) {
+ dma->device_free_chan_resources(chan);
+ return -ENODEV;
+ }
+
+ err = sg_alloc_table(_table, nents, GFP_KERNEL);
+ if (err)
+ goto sg_table_alloc_failed;
+
+ for_each_sg(sg_table.sgl, sg, nents, i) {
+ u64 alloc_sz;
+ void *cpu_addr;
+
+ alloc_sz = round_up(size, nents);
+ do_div(alloc_sz, nents);
+ cpu_addr = kmalloc(alloc_sz, GFP_KERNEL);
+
+ if (!cpu_addr) {
+ err = -ENOMEM;
+ goto sg_buf_alloc_failed;
+ }
+
+ dev_dbg(dma->dev, "set sg buf[%d] :%p\n", i, cpu_addr);
+ sg_set_buf(sg, cpu_addr, alloc_sz);
+ }
+
+ dest_buf = kmalloc(round_up(size, nents), GFP_KERNEL);
+ if (!dest_buf) {
+ err = -ENOMEM;
+ goto dst_alloc_failed;
+ }
+ dev_dbg(dma->dev, "dest:%p\n", dest_buf);
+
+ /* Fill in src buffer */
+ count = 0;
+ for_each_sg(sg_table.sgl, sg, nents, i) {
+ src_buf = sg_virt(sg);
+ dev_dbg(dma->dev,
+ "set src[%d, %p] = %d\n", i, src_buf, count);
+
+ for (j = 0; j < sg_dma_len(sg); j++)
+ src_buf[j] = count++;
+ }
+
+ /* dma_map_sg cleans and invalidates the cache in arm64 when
+* DMA_TO_DEVICE is selected for src. That's why, we need to do
+* the mapping after the data is copied.
+*/
+ map_count = dma_map_sg(dma->dev, sg_table.sgl, nents, DMA_TO_DEVICE);
+ if (!map_count) {
+ err = -EINVAL;
+ goto src_map_failed;
+ }
+
+ dest = dma_map_single(dma->dev, dest_buf, size, DMA_FROM_DEVICE);
+
+ err = dma_mapping_error(dma->dev, dest);
+ if (err)
+ goto dest
[PATCH V4 4/4] dma: add Qualcomm Technologies HIDMA channel driver
This patch adds support for hidma engine. The driver consists
of two logical blocks. The DMA engine interface and the
low-level interface. The hardware only supports memcpy/memset
and this driver only support memcpy interface. HW and driver
doesn't support slave interface.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
.../devicetree/bindings/dma/qcom_hidma.txt | 18 +
drivers/dma/qcom/Kconfig | 9 +
drivers/dma/qcom/Makefile | 2 +
drivers/dma/qcom/hidma.c | 736
drivers/dma/qcom/hidma.h | 157
drivers/dma/qcom/hidma_dbg.c | 225 +
drivers/dma/qcom/hidma_ll.c| 939 +
7 files changed, 2086 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
create mode 100644 drivers/dma/qcom/hidma.c
create mode 100644 drivers/dma/qcom/hidma.h
create mode 100644 drivers/dma/qcom/hidma_dbg.c
create mode 100644 drivers/dma/qcom/hidma_ll.c
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma.txt
b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
new file mode 100644
index 000..d18c8fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
@@ -0,0 +1,18 @@
+Qualcomm Technologies HIDMA Channel driver
+
+Required properties:
+- compatible: must contain "qcom,hidma-1.0"
+- reg: Addresses for the transfer and event channel
+- interrupts: Should contain the event interrupt
+- desc-count: Number of asynchronous requests this channel can handle
+- event-channel: The HW event channel completions will be delivered.
+Example:
+
+ hidma_24: dma-controller@0x5c05 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c05 0x0 0x1000>,
+ <0 0x5c0b 0x0 0x1000>;
+ interrupts = <0 389 0>;
+ desc-count = <10>;
+ event-channel = <4>;
+ };
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index f3e2d4c..5588e1c 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -18,3 +18,12 @@ config QCOM_HIDMA_MGMT
the guest OS would run QCOM_HIDMA channel driver and the
hypervisor would run the QCOM_HIDMA_MGMT management driver.
+config QCOM_HIDMA
+ tristate "Qualcomm Technologies HIDMA Channel support"
+ select DMA_ENGINE
+ help
+ Enable support for the Qualcomm Technologies HIDMA controller.
+ The HIDMA controller supports optimized buffer copies
+ (user to kernel, kernel to kernel, etc.). It only supports
+ memcpy interface. The core is not intended for general
+ purpose slave DMA.
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index 1a5a96d..2b68c9c 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,2 +1,4 @@
obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
obj-$(CONFIG_QCOM_HIDMA_MGMT) += hidma_mgmt.o hidma_mgmt_sys.o
+obj-$(CONFIG_QCOM_HIDMA) += hdma.o
+hdma-objs:= hidma_ll.o hidma.o hidma_dbg.o ../dmaselftest.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
new file mode 100644
index 000..1af301c
--- /dev/null
+++ b/drivers/dma/qcom/hidma.c
@@ -0,0 +1,736 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine interface
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
+ * Copyright (C) Semihalf 2009
+ * Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2014
+ *
+ * Written by Piotr Ziecik <ko...@semihalf.com>. Hardware description
+ * (defines, structures and comments) was taken from MPC5121 DMA driver
+ * written by Hongjun Chen <hong-jun.c...@freescale.com>.
+ *
+ * Approved as OSADL project by a majority of OSADL members and funded
+ * by OSADL membership fees in 2009; for details see www.osadl.org.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILIT
[PATCH V4 2/4] dma: add Qualcomm Technologies HIDMA management driver
The Qualcomm Technologies HIDMA device has been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design.
1. HIDMA Management driver
2. HIDMA Channel driver
Each HIDMA HW consists of multiple channels. These channels
share some set of common parameters. These parameters are
initialized by the management driver during power up.
Same management driver is used for monitoring the execution
of the channels. Management driver can change the performance
behavior dynamically such as bandwidth allocation and
prioritization.
The management driver is executed in hypervisor context and
is the main management entity for all channels provided by
the device.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 61
drivers/dma/qcom/Kconfig | 11 +
drivers/dma/qcom/Makefile | 1 +
drivers/dma/qcom/hidma_mgmt.c | 312 +
drivers/dma/qcom/hidma_mgmt.h | 38 +++
drivers/dma/qcom/hidma_mgmt_sys.c | 231 +++
6 files changed, 654 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
create mode 100644 drivers/dma/qcom/hidma_mgmt.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.h
create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
new file mode 100644
index 000..eb053b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -0,0 +1,61 @@
+Qualcomm Technologies HIDMA Management interface
+
+The Qualcomm Technologies HIDMA device has been designed
+to support virtualization technology. The driver has been
+divided into two to follow the hardware design. The management
+driver is executed in hypervisor context and is the main
+management entity for all channels provided by the device.
+
+Each HIDMA HW consists of multiple channels. These channels
+share some set of common parameters. These parameters are
+initialized by the management driver during power up.
+Same management driver is used for monitoring the execution
+of the channels. Management driver can change the performance
+behavior dynamically such as bandwidth allocation and
+prioritization.
+
+All channel devices get probed in the hypervisor
+context during power up. They show up as DMA engine
+DMA channels. Then, before starting the virtualization; each
+channel device is unbound from the hypervisor by VFIO
+and assign to the guest machine for control.
+
+This management driver will be used by the system
+admin to monitor/reset the execution state of the DMA
+channels. This will be the management interface.
+
+
+Required properties:
+- compatible: "qcom,hidma-mgmt-1.0";
+- reg: Address range for DMA device
+- dma-channels: Number of channels supported by this DMA controller.
+- max-write-burst-bytes: Maximum write burst in bytes. A memcpy requested is
+ fragmented to multiples of this amount.
+- max-read-burst-bytes: Maximum read burst in bytes. A memcpy request is
+ fragmented to multiples of this amount.
+- max-write-transactions: Maximum write transactions to perform in a burst
+- max-read-transactions: Maximum read transactions to perform in a burst
+- channel-reset-timeout-cycles: Channel reset timeout in cycles for this SOC.
+- channel-priority: Priority of the channel.
+ Each dma channel share the same HW bandwidth with other dma channels.
+ If two requests reach to the HW at the same time from a low priority and
+ high priority channel, high priority channel will claim the bus.
+ 0=low priority, 1=high priority
+- channel-weight: Round robin weight of the channel
+ Since there are only two priority levels supported, scheduling among
+ the equal priority channels is done via weights.
+
+Example:
+
+ hidma-mgmt@f9984000 = {
+ compatible = "qcom,hidma-mgmt-1.0";
+ reg = <0xf9984000 0x15000>;
+ dma-channels = 6;
+ max-write-burst-bytes = 1024;
+ max-read-burst-bytes = 1024;
+ max-write-transactions = 31;
+ max-read-transactions = 31;
+ channel-reset-timeout-cycles = 0x500;
+ channel-priority = < 1 1 0 0 0 0>;
+ channel-weight = < 1 13 10 3 4 5>;
+ };
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index 17545df..f3e2d4c 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -7,3 +7,14 @@ config QCOM_BAM_DMA
Enable support for the QCOM BAM DMA controller. This controller
provides DMA capabilities for a variety of on-chip devices.
+config QCOM_HIDMA_MGMT
+ tristate "Qualcomm Technologies HIDMA Management support"
+ s
[PATCH V4 1/4] dma: qcom_bam_dma: move to qcom directory
Creating a QCOM directory for all QCOM DMA source
files.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/dma/Kconfig| 11 ++-
drivers/dma/Makefile | 2 +-
drivers/dma/qcom/Kconfig | 9 +
drivers/dma/qcom/Makefile | 1 +
drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 6 +++---
5 files changed, 16 insertions(+), 13 deletions(-)
create mode 100644 drivers/dma/qcom/Kconfig
create mode 100644 drivers/dma/qcom/Makefile
rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index b458475..47b1b98 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -408,15 +408,6 @@ config PXA_DMA
16 to 32 channels for peripheral to memory or memory to memory
transfers.
-config QCOM_BAM_DMA
- tristate "QCOM BAM DMA support"
- depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
- select DMA_ENGINE
- select DMA_VIRTUAL_CHANNELS
- ---help---
- Enable support for the QCOM BAM DMA controller. This controller
- provides DMA capabilities for a variety of on-chip devices.
-
config SIRF_DMA
tristate "CSR SiRFprimaII/SiRFmarco DMA support"
depends on ARCH_SIRF
@@ -527,6 +518,8 @@ config ZX_DMA
# driver files
source "drivers/dma/bestcomm/Kconfig"
+source "drivers/dma/qcom/Kconfig"
+
source "drivers/dma/dw/Kconfig"
source "drivers/dma/hsu/Kconfig"
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 7711a71..8dba90d 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_PCH_DMA) += pch_dma.o
obj-$(CONFIG_PL330_DMA) += pl330.o
obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
obj-$(CONFIG_PXA_DMA) += pxa_dma.o
-obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
obj-$(CONFIG_RENESAS_DMA) += sh/
obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
@@ -66,4 +65,5 @@ obj-$(CONFIG_TI_EDMA) += edma.o
obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
+obj-y += qcom/
obj-y += xilinx/
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
new file mode 100644
index 000..17545df
--- /dev/null
+++ b/drivers/dma/qcom/Kconfig
@@ -0,0 +1,9 @@
+config QCOM_BAM_DMA
+ tristate "QCOM BAM DMA support"
+ depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ ---help---
+ Enable support for the QCOM BAM DMA controller. This controller
+ provides DMA capabilities for a variety of on-chip devices.
+
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
new file mode 100644
index 000..f612ae3
--- /dev/null
+++ b/drivers/dma/qcom/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom/bam_dma.c
similarity index 99%
rename from drivers/dma/qcom_bam_dma.c
rename to drivers/dma/qcom/bam_dma.c
index 5a250cd..5359234 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
@@ -49,8 +49,8 @@
#include
#include
-#include "dmaengine.h"
-#include "virt-dma.h"
+#include "../dmaengine.h"
+#include "../virt-dma.h"
struct bam_desc_hw {
u32 addr; /* Buffer physical address */
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 3/4] dmaselftest: add memcpy selftest support functions
This patch adds supporting utility functions for selftest.
The intention is to share the self test code between
different drivers.
Supported test cases include:
1. dma_map_single
2. streaming DMA
3. coherent DMA
4. scatter-gather DMA
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/dma/dmaengine.h | 2 +
drivers/dma/dmaselftest.c | 638 ++
2 files changed, 640 insertions(+)
create mode 100644 drivers/dma/dmaselftest.c
diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h
index 17f983a..05b5a84 100644
--- a/drivers/dma/dmaengine.h
+++ b/drivers/dma/dmaengine.h
@@ -86,4 +86,6 @@ static inline void dma_set_residue(struct dma_tx_state
*state, u32 residue)
state->residue = residue;
}
+int dma_selftest_memcpy(struct dma_device *dmadev);
+
#endif
diff --git a/drivers/dma/dmaselftest.c b/drivers/dma/dmaselftest.c
new file mode 100644
index 000..423a9a3
--- /dev/null
+++ b/drivers/dma/dmaselftest.c
@@ -0,0 +1,638 @@
+/*
+ * DMA self test code borrowed from Qualcomm Technologies HIDMA driver
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct test_result {
+ atomic_t counter;
+ wait_queue_head_t wq;
+ struct dma_device *dma;
+};
+
+static void dma_selftest_complete(void *arg)
+{
+ struct test_result *result = arg;
+ struct dma_device *dma = result->dma;
+
+ atomic_inc(>counter);
+ wake_up(>wq);
+ dev_dbg(dma->dev, "self test transfer complete :%d\n",
+ atomic_read(>counter));
+}
+
+/*
+ * Perform a transaction to verify the HW works.
+ */
+static int dma_selftest_sg(struct dma_device *dma,
+ struct dma_chan *chan, u64 size,
+ unsigned long flags)
+{
+ struct dma_async_tx_descriptor *tx;
+ struct sg_table sg_table;
+ struct scatterlist *sg;
+ struct test_result result;
+ dma_addr_t src, dest, dest_it;
+ u8 *src_buf, *dest_buf;
+ unsigned int i, j;
+ dma_cookie_t cookie;
+ int err;
+ int nents = 10, count;
+ bool free_channel = true;
+ int map_count;
+
+ init_waitqueue_head();
+ atomic_set(, 0);
+ result.dma = dma;
+
+ if (!chan)
+ return -ENOMEM;
+
+ if (dma->device_alloc_chan_resources(chan) < 1)
+ return -ENODEV;
+
+ if (!chan->device || !dma->dev) {
+ dma->device_free_chan_resources(chan);
+ return -ENODEV;
+ }
+
+ err = sg_alloc_table(_table, nents, GFP_KERNEL);
+ if (err)
+ goto sg_table_alloc_failed;
+
+ for_each_sg(sg_table.sgl, sg, nents, i) {
+ u64 alloc_sz;
+ void *cpu_addr;
+
+ alloc_sz = round_up(size, nents);
+ do_div(alloc_sz, nents);
+ cpu_addr = kmalloc(alloc_sz, GFP_KERNEL);
+
+ if (!cpu_addr) {
+ err = -ENOMEM;
+ goto sg_buf_alloc_failed;
+ }
+
+ dev_dbg(dma->dev, "set sg buf[%d] :%p\n", i, cpu_addr);
+ sg_set_buf(sg, cpu_addr, alloc_sz);
+ }
+
+ dest_buf = kmalloc(round_up(size, nents), GFP_KERNEL);
+ if (!dest_buf) {
+ err = -ENOMEM;
+ goto dst_alloc_failed;
+ }
+ dev_dbg(dma->dev, "dest:%p\n", dest_buf);
+
+ /* Fill in src buffer */
+ count = 0;
+ for_each_sg(sg_table.sgl, sg, nents, i) {
+ src_buf = sg_virt(sg);
+ dev_dbg(dma->dev,
+ "set src[%d, %p] = %d\n", i, src_buf, count);
+
+ for (j = 0; j < sg_dma_len(sg); j++)
+ src_buf[j] = count++;
+ }
+
+ /* dma_map_sg cleans and invalidates the cache in arm64 when
+* DMA_TO_DEVICE is selected for src. That's why, we need to do
+* the mapping after the data is copied.
+*/
+ map_count = dma_map_sg(dma->dev, sg_table.sgl, nents, DMA_TO_DEVICE);
+ if (!map_count) {
+ err = -EINVAL;
+ goto src_map_failed;
+ }
+
+ dest = dma_map_single(dma->dev, dest_buf, size, DMA_FROM_DEVICE);
+
+ err = dma_mapping_error(dma->dev, dest);
+ if (err)
+ goto dest
[PATCH V4 0/4] dma: add Qualcomm Technologies HIDMA driver
The Qualcomm Technologies HIDMA device has been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design.
1. HIDMA Management driver
2. HIDMA Channel driver
Each HIDMA HW consists of multiple channels. These channels
share some set of common parameters. These parameters are
initialized by the management driver during power up.
Same management driver is used for monitoring the execution
of the channels. Management driver can change the performance
behavior dynamically such as bandwidth allocation and
prioritization in the future.
The management driver is executed in hypervisor context and
is the main management entity for all channels provided by
the device.
Changes from V3: (https://lkml.org/lkml/2015/11/7/256)
* use git format-patch -M to reduce the difference
Changes from V3: (https://lkml.org/lkml/2015/11/7/257)
* add missing EXPORT_SYMBOL_GPL for hidma_mgmt_init_sys and
hidma_mgmt_setup
* simplify bitwise set and clear statements
Changes from V3: (https://lkml.org/lkml/2015/11/7/258)
* none
Changes from V3: (https://lkml.org/lkml/2015/11/7/259)
* remove return code on hidma_ll_start and hidma_ll_queue_request
* remove the checks after platform_get_resource.
* reorder the pm calls in failure path.
* simplify bit clear and set operations.
* correct device tree documentation compatible string
* clean unnecessary initializations and use unsigned int for
iterator types
Sinan Kaya (4):
dma: qcom_bam_dma: move to qcom directory
dma: add Qualcomm Technologies HIDMA management driver
dmaselftest: add memcpy selftest support functions
dma: add Qualcomm Technologies HIDMA channel driver
.../devicetree/bindings/dma/qcom_hidma.txt | 18 +
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 61 ++
drivers/dma/Kconfig| 11 +-
drivers/dma/Makefile | 2 +-
drivers/dma/dmaengine.h| 2 +
drivers/dma/dmaselftest.c | 638 ++
drivers/dma/qcom/Kconfig | 29 +
drivers/dma/qcom/Makefile | 4 +
drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} | 6 +-
drivers/dma/qcom/hidma.c | 736
drivers/dma/qcom/hidma.h | 157
drivers/dma/qcom/hidma_dbg.c | 225 +
drivers/dma/qcom/hidma_ll.c| 939 +
drivers/dma/qcom/hidma_mgmt.c | 312 +++
drivers/dma/qcom/hidma_mgmt.h | 38 +
drivers/dma/qcom/hidma_mgmt_sys.c | 231 +
16 files changed, 3396 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
create mode 100644 drivers/dma/dmaselftest.c
create mode 100644 drivers/dma/qcom/Kconfig
create mode 100644 drivers/dma/qcom/Makefile
rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
create mode 100644 drivers/dma/qcom/hidma.c
create mode 100644 drivers/dma/qcom/hidma.h
create mode 100644 drivers/dma/qcom/hidma_dbg.c
create mode 100644 drivers/dma/qcom/hidma_ll.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.h
create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails
On 11/10/2015 3:38 AM, Arnd Bergmann wrote:
> No, as Timur found, the driver is correct and it intentionally
sets the 32-bit mask, and that is guaranteed to work on all sane
hardware. Don't change the driver but find a better platform for
your workload, or talk to the people that are responsible for
the platform and get them to fix it.
Platform does have an IOMMU. No issues there. I am trying to clean out
the patch pipe I have in order to get this card working with and without
IOMMU.
If the platform also doesn't have an IOMMU, you can probably work
around it by setting up the dma-ranges property of the PCI host
to map the low PCI addresses to the start of RAM. This will also
require changes in the bootloader to set up the PCI outbound translation,
and it will require implementing the DMA offset on ARM64, which I was
hoping to avoid.
From the email thread, it looks like this was introduced to support
some legacy card that has 64 bit addressing limitations and is being
carried around ("rotted") since then.
I'm the second guy after the powerpc architecture complaining about the
very same issue. Any red flags?
I can't change the address map for PCIe. SBSA requires all inbound PCIe
addresses to be non-translated.
I'll just have to stick with IOMMU for this card.
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails
On 11/10/2015 1:27 PM, James Bottomley wrote:
On Tue, 2015-11-10 at 12:19 -0500, Sinan Kaya wrote:
On 11/10/2015 11:47 AM, Arnd Bergmann wrote:
On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote:
On 11/10/2015 3:38 AM, Arnd Bergmann wrote:
From the email thread, it looks like this was introduced to support
some legacy card that has 64 bit addressing limitations and is being
carried around ("rotted") since then.
I'm the second guy after the powerpc architecture complaining about the
very same issue. Any red flags?
What BenH was worried about here is that the driver sets different masks
for streaming and coherent mappings, which is indeed a worry that
could hit us on ARM as well, but I suppose we'll have to deal with
that in platform code.
Setting both masks to 32-bit is something that a lot of drivers do,
and without IOMMU enabled, you'd hit the same bug on all of them.
Maybe, maybe not. This is the only card that I had problems with.
Your characterisation of "some legacy card" isn't entirely correct.
Just to clarify how this happens, most I/O cards today are intelligent
offload engines which means they have some type of embedded CPU (it can
even be a specially designed asic). This CPU is driven by firmware
which is mostly (but not always) in the machine language of the CPU.
DMA transfers are sometimes run by this CPU, but mostly handed off to a
separate offload engine. When the board gets revised, it's often easier
to update the offload engine to 64 bits and keep the CPU at 32 (or even
16) bits. This means that all the internal addresses in the firmware
are 32 bit only. As I read the comments in the original thread, it
looks like the mpt people tried to mitigate this by using segment
registers for external addresses firmware uses ... that's why they say
that they don't have to have all the addresses in DMA32 ... they just
need the upper 32 bits to be constant so they can correctly program the
segment register. Unfortunately, we have no way to parametrise this to
the DMA allocation code.
You'll find the same thing with Adaptec SPI cards. Their route to 64
bits was via an initial 39 bit extension that had them layering the
additional 7 bits into the unused lower region of the page descriptors
for the firmware (keeping the actual pointers to DMA at 32 bits because
they're always parametrised as address, offset, length and the address
is always a 4k page).
Eventually, everything will rev to 64 bits and this problem will go
away, but, as I suspect you know, it takes time for the embedded world
to get to where everyone else already is.
As Arnd said, if you failed to allow for this in your platform, then
oops, just don't use the card. I think this solution would be better
than trying to get the driver to work out which cards can support 64 bit
firmware descriptors and only failing on your platform for those that
can't.
James
James,
I was referring to this conversation here.
https://lkml.org/lkml/2015/2/20/31
"The aic79xx hardware problem was that the DMA engine could address the
whole of memory (it had two address modes, a 39 bit one and a 64 bit
one) but the script engine that runs the mailboxes only had a 32 bit
activation register (the activating write points at the physical address
of the script to begin executing)."
The fact that LSI SAS 92118i is working with 64 bit addresses suggests
me that this problem is already solved. I have not hit any kind of
regressions with 93xx and 92xx families under load in a true 64 bit
environment. I am only mentioning this based on my testing exposure.
Another comment here from you.
https://lkml.org/lkml/2015/4/2/28
"Well, it was originally a hack for altix, because they had no regions
below 4GB and had to specifically manufacture them. As you know, in
Linux, if Intel doesn't need it, no-one cares and the implementation
bitrots."
Maybe, it is time to fix the code for more recent (even decent) hardware?
Sinan
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails
On 11/10/2015 11:47 AM, Arnd Bergmann wrote:
On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote:
On 11/10/2015 3:38 AM, Arnd Bergmann wrote:
> No, as Timur found, the driver is correct and it intentionally
sets the 32-bit mask, and that is guaranteed to work on all sane
hardware. Don't change the driver but find a better platform for
your workload, or talk to the people that are responsible for
the platform and get them to fix it.
Platform does have an IOMMU. No issues there. I am trying to clean out
the patch pipe I have in order to get this card working with and without
IOMMU.
On PowerPC, I think we automatically enable the IOMMU whenever a DMA
mask is set that doesn't cover all of the RAM. We could think about
doing the same thing on ARM64 to make all devices work out of the box.
The ACPI IORT table declares whether you enable IOMMU for a particular
device or not. The placement of IOMMU HW is system specific. The IORT
table gives the IOMMU HW topology to the operating system.
If the platform also doesn't have an IOMMU, you can probably work
around it by setting up the dma-ranges property of the PCI host
to map the low PCI addresses to the start of RAM. This will also
require changes in the bootloader to set up the PCI outbound translation,
and it will require implementing the DMA offset on ARM64, which I was
hoping to avoid.
From the email thread, it looks like this was introduced to support
some legacy card that has 64 bit addressing limitations and is being
carried around ("rotted") since then.
I'm the second guy after the powerpc architecture complaining about the
very same issue. Any red flags?
What BenH was worried about here is that the driver sets different masks
for streaming and coherent mappings, which is indeed a worry that
could hit us on ARM as well, but I suppose we'll have to deal with
that in platform code.
Setting both masks to 32-bit is something that a lot of drivers do,
and without IOMMU enabled, you'd hit the same bug on all of them.
Maybe, maybe not. This is the only card that I had problems with.
I can't change the address map for PCIe. SBSA requires all inbound PCIe
addresses to be non-translated.
What about changing the memory map? I suspect there will be more
problems for you in the future when all of your RAM is at high
addresses. Is this something you could fix in the bootloader by
moving the first 2GB to a different CPU physical address?
I'm thinking about this.
I'll just have to stick with IOMMU for this card.
Ok. But how do you currently decide whether to use the IOMMU or not?
ACPI table. I wanted to get this fix in so that all operating systems
whether they have IOMMU driver enabled or not would work.
Arnd
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails
On 11/10/2015 3:05 PM, James Bottomley wrote: OK, you don't seem to be understanding the problem: the Altix isn't a LSI card, it was a SGI platform. Got it. It was the platform where we first discovered the issue that a lot of storage cards didn't work because it by default had no memory below 4GB. The reason coherent masks were introduced was initially so the Altix could manufacture and manage a region of memory in the lower 4GB region and we would guarantee to make allocations from it so the storage cards would then work on that platform. I can't fix the issue if the card cannot do 64 bit DMA when IOMMU is not there. I need IOMMU enabled all the time for this card. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails
On 11/10/2015 2:43 PM, James Bottomley wrote: The Issue, as stated by LSI is Initially set the consistent DMA mask to 32 bit and then change it to 64 bit mask after allocating RDPQ pools by calling the function _base_change_consistent_dma_mask. This is to ensure that all the upper 32 bits of RDPQ entries's base address to be same. Need somebody from mpt to confirm that this behavior is still valid for the recent cards besides altix. If you set a 64 bit coherent mask before this point, you're benefiting from being lucky that all the upper 32 bits of the allocations are the same ... we can't code a driver to rely on luck. Particularly not when the failure mode looks like it would be silent and deadly. Of course nobody wants unreliable code. I'm wondering if I was just lucky during my testing or the 92xx and 93xx hardware supports full 64 bit range. I don't have any insight into what the endpoint does or what it is capable of. >Another comment here from you. >https://lkml.org/lkml/2015/4/2/28 > >"Well, it was originally a hack for altix, because they had no regions >below 4GB and had to specifically manufacture them. As you know, in >Linux, if Intel doesn't need it, no-one cares and the implementation >bitrots." > >Maybe, it is time to fix the code for more recent (even decent) hardware? What do you mean "fix the code"? The code isn't broken, it's parametrising issues with particular hardware. There's no software work around (except allocating memory with the correct characteristics). Need confirmation. I'm questioning if we are stuck with this behavior because of altix or something else. If the latter case, the code could have used PCI ID to do something special for it. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails
On 11/10/2015 2:56 PM, Arnd Bergmann wrote: The ACPI IORT table declares whether you enable IOMMU for a particular >device or not. The placement of IOMMU HW is system specific. The IORT >table gives the IOMMU HW topology to the operating system. This sounds odd. Clearly you need to specify the IOMMU settings for each possible PCI device independent of whether the OS actually uses the IOMMU or not. There are provisions to have DMA mask in the PCIe host bridge not at the PCIe device level inside IORT table. This setting is specific for each PCIe bus. It is not per PCIe device. It is assumed that the endpoint device driver knows the hardware for PCIe devices. The driver can also query the supported DMA bits by this platform via DMA APIs and will request the correct DMA mask from the DMA subsystem (surprise!). In a lot of cases, we want to turn it off to get better performance when the driver has set a DMA mask that covers all of RAM, but you also want to enable the IOMMU for debugging purposes or for device assignment if you run virtual machines. The bootloader doesn't know how the device is going to be used, so it cannot define the policy here. I think we'll end up adding a virtualization option to the UEFI BIOS similar to how Intel platforms work. Based on this switch, we'll end up patching the ACPI table. If I remove the IORT entry, then the device is in coherent mode with device accessing the full RAM range. If I have the IORT table, the device is in IOMMU translation mode. Details are in the IORT spec. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 3/3] scsi: mptxsas: offload IRQ execution
On 11/9/2015 2:15 AM, Hannes Reinecke wrote: On 11/09/2015 02:57 AM, Sinan Kaya wrote: The mpt2sas and mpt3sas drivers are spinning forever in their IRQ handlers if there are a lot of jobs queued up by the PCIe card. This handler is causing spikes for the rest of the system and sluggish behavior. Marking all MSI interrupts as non-shared and moving the MSI interrupts to thread context. This relexes the rest of the system execution. NACK. If there is a scalability issue when handling interrupts it should be fixed in the driver directly. Looking at the driver is should be possible to implement a worker thread handling the reply descriptor, and having the interrupt only to fetch the reply descriptor. I'll take a look. Cheers, Hannes -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails
On 11/9/2015 2:09 AM, Hannes Reinecke wrote: On 11/09/2015 02:57 AM, Sinan Kaya wrote: Current code gives up when 32 bit DMA is not supported. This problem has been observed on systems without any memory below 4 gig. This patch tests 64 bit support before bailing out to find a working combination. That feels decidedly odd. Why do you probe for 64bit if 32bit fails? Typically it's the other way round, on the grounds that 64bit DMA should be preferred over 32bit. Can you explain why it needs to be done the other way round here? Cheers, Hannes The platform does not have any memory below 4G. So, 32 bit DMA is not possible. I'm trying to use 64 bit DMA instead since both the platform and hardware supports it. Current code will not try 64 bit DMA if 32 bit DMA is not working. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails
On 11/9/2015 3:59 AM, Arnd Bergmann wrote: On Monday 09 November 2015 08:09:39 Hannes Reinecke wrote: On 11/09/2015 02:57 AM, Sinan Kaya wrote: Current code gives up when 32 bit DMA is not supported. This problem has been observed on systems without any memory below 4 gig. This patch tests 64 bit support before bailing out to find a working combination. That feels decidedly odd. Why do you probe for 64bit if 32bit fails? 32-bit DMA mask on PCI cannot fail, we rely on that in all sorts of places. If the machine has all of its RAM visible above 4GB PCI bus addresses, it must use an IOMMU. Can you be specific? PCIe does not have this limitation. It supports 32 bit and 64 bit TLPs. I have not seen any limitation so far in the OS either. Using IOMMU is fine but not required if the endpoint is a true 64 bit supporting endpoint. This endpoint supports 64bit too. Typically it's the other way round, on the grounds that 64bit DMA should be preferred over 32bit. Can you explain why it needs to be done the other way round here? Something else is odd here, the driver already checks for dma_get_required_mask(), which will return the smallest mask that fits all of RAM. If the machine has any memory above 4GB, it already uses the 64-bit mask, and only falls back to the 32-bit mask if that fails or if all memory fits within the first 4GB. I'll add some prints in the code to get to the bottom of it. I think the code is checking more than just the required mask and failing in one of the other conditions. At least that DMA comparison code was more than what I have ever seen. So both the description and the patch are wrong. :( Arnd -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/3] scsi: fix compiler warning for sg
On 11/9/2015 10:26 PM, Timur Tabi wrote: Sinan Kaya wrote: I created this patch back in March with an older version of the compiler and older kernel (3.19). I'm no longer able to reproduce this with this compiler and linux-next. Thread model: posix gcc version 4.8.3 20140401 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.04 - Linaro GCC 4.8-2014.04) I'll drop this patch. Are you sure the compiler handles the old macro correctly? Maybe it's just quiescing the error message, but it's still broken? The code says it is using these macros for small integers only which can't overflow. I was trying to get rid of compiler warning and it seems to have disappeared. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 3/4] dmaselftest: add memcpy selftest support functions
On 11/9/2015 8:48 AM, Timur Tabi wrote: Sinan Kaya wrote: And why kmalloc anyway? Why not leave it on the stack? char src[] = "hello world"; ? I need to call dma_map_single on this address to convert it to a DMA address. That's why. And you can't do that with an object that's on the stack? no, pasting from here. https://www.kernel.org/doc/Documentation/DMA-API-HOWTO.txt under 'What memory is DMA'able?' This rule also means that you may use neither kernel image addresses (items in data/text/bss segments), nor module image addresses, nor stack addresses for DMA. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 3/4] dmaselftest: add memcpy selftest support functions
On 11/9/2015 4:26 AM, Andy Shevchenko wrote: On Mon, Nov 9, 2015 at 5:07 AM, Sinan Kaya <ok...@codeaurora.org> wrote: On 11/8/2015 3:09 PM, Andy Shevchenko wrote: On Sun, Nov 8, 2015 at 6:52 AM, Sinan Kaya <ok...@codeaurora.org> wrote: This patch adds supporting utility functions for selftest. The intention is to share the self test code between different drivers. Supported test cases include: 1. dma_map_single 2. streaming DMA 3. coherent DMA 4. scatter-gather DMA + u32 i, j = 0; unsigned int why? Is i or j is going to be used for HW communication? No? What about assignment to a values of type u32? No? Plain counters? Use plain types. OK. I did an internal code review before posting the patch. Nobody complained about iterator types. I am trying to find what goes as a good practice vs. what is personal style. It's actually comment about your all patches I saw last week. + int err = 0; + int ret; Any reason to have two instead of one of similar meaning? removed ret Don't forget to check if it's redundant assignment (check in all your patches as well). I'll look. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 2/4] dma: add Qualcomm Technologies HIDMA management driver
On 11/9/2015 1:25 PM, Rob Herring wrote:
On Sun, Nov 08, 2015 at 09:17:20PM -0500, Sinan Kaya wrote:
On 11/8/2015 12:08 AM, Timur Tabi wrote:
On 11/8/2015 12:08 AM, Timur Tabi wrote:
Sinan Kaya wrote:
+val = val & ~(MAX_BUS_REQ_LEN_MASK << MAX_BUS_WR_REQ_BIT_POS);
+val = val | (mgmtdev->max_write_request << MAX_BUS_WR_REQ_BIT_POS);
+val = val & ~(MAX_BUS_REQ_LEN_MASK);
+val = val | (mgmtdev->max_read_request);
val &= ~MAX_BUS_REQ_LEN_MASK << MAX_BUS_WR_REQ_BIT_POS;
val |= mgmtdev->max_write_request << MAX_BUS_WR_REQ_BIT_POS;
val &= ~MAX_BUS_REQ_LEN_MASK;
val |= mgmtdev->max_read_request;
+static const struct of_device_id hidma_mgmt_match[] = {
+{ .compatible = "qcom,hidma-mgmt", },
+{ .compatible = "qcom,hidma-mgmt-1.0", },
+{ .compatible = "qcom,hidma-mgmt-1.1", },
+{},
+};
I thought Rob said that he did NOT want to use version numbers in
compatible strings. And what's the difference between these three
versions anyway?
This was already discussed here.
https://lkml.org/lkml/2015/11/2/689
The agreement was to use
The suggestion...
compatible = "qcom,hidma-mgmt-1.1", "qcom,hidma-mgmt-1.0",
"qcom,hidma-mgmt";
I don't really want to see 3 generic-ish strings.
I'll be adding code for v1.1 specifically in the future.
Please drop "qcom,hidma-mgmt" altogether. It is already meaningless.
Then add the 1.1 compatible when you add the code for it. Hopefully you
all can decide on part number(s) by then.
Rob
OK. I'll only have "qcom,hidma-mgmt-1.0" for now.
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 3/3] scsi: mptxsas: offload IRQ execution
On 11/9/2015 2:15 AM, Hannes Reinecke wrote: On 11/09/2015 02:57 AM, Sinan Kaya wrote: The mpt2sas and mpt3sas drivers are spinning forever in their IRQ handlers if there are a lot of jobs queued up by the PCIe card. This handler is causing spikes for the rest of the system and sluggish behavior. Marking all MSI interrupts as non-shared and moving the MSI interrupts to thread context. This relexes the rest of the system execution. NACK. If there is a scalability issue when handling interrupts it should be fixed in the driver directly. Looking at the driver is should be possible to implement a worker thread handling the reply descriptor, and having the interrupt only to fetch the reply descriptor. Can you go into the detail about which part of the _base_interrupt function needs to be executed in ISR context and which part can be queued up to worker thread? I'm not familiar with the hardware or the code. That's why, I moved the entire ISR into the thread context. Cheers, Hannes -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] acpi: add support for extended IRQ to PCI link
On 11/9/2015 8:50 AM, Timur Tabi wrote:
Sinan Kaya wrote:
I'm concerned about this though since you warned. This used to consume
1024 bytes now 4096 bytes.
static int acpi_irq_penalty[ACPI_MAX_IRQS] = {
PIRQ_PENALTY_ISA_ALWAYS,/* IRQ0 timer */
...
}
As long as it's not ever put on the stack, it should be fine.
Alright...
If 1k global is OK, 4k global should be OK too.
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/3] scsi: fix compiler warning for sg
On 11/9/2015 9:14 AM, Andy Shevchenko wrote: Parens are useless, noticed later, sorry. Isn't mult_frac() enough here? Btw, can you mention explicitly what is the warning you get (copy'n'paste of the line would be okay)? I created this patch back in March with an older version of the compiler and older kernel (3.19). I'm no longer able to reproduce this with this compiler and linux-next. Thread model: posix gcc version 4.8.3 20140401 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.04 - Linaro GCC 4.8-2014.04) I'll drop this patch. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 4/4] dma: add Qualcomm Technologies HIDMA channel driver
On 11/9/2015 1:19 PM, Rob Herring wrote: On Sat, Nov 07, 2015 at 11:53:00PM -0500, Sinan Kaya wrote: This patch adds support for hidma engine. The driver consists of two logical blocks. The DMA engine interface and the low-level interface. The hardware only supports memcpy/memset and this driver only support memcpy interface. HW and driver doesn't support slave interface. Signed-off-by: Sinan Kaya <ok...@codeaurora.org> --- .../devicetree/bindings/dma/qcom_hidma.txt | 18 + drivers/dma/qcom/Kconfig | 9 + drivers/dma/qcom/Makefile | 2 + drivers/dma/qcom/hidma.c | 743 drivers/dma/qcom/hidma.h | 157 drivers/dma/qcom/hidma_dbg.c | 225 + drivers/dma/qcom/hidma_ll.c| 944 + 7 files changed, 2098 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt create mode 100644 drivers/dma/qcom/hidma.c create mode 100644 drivers/dma/qcom/hidma.h create mode 100644 drivers/dma/qcom/hidma_dbg.c create mode 100644 drivers/dma/qcom/hidma_ll.c diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma.txt b/Documentation/devicetree/bindings/dma/qcom_hidma.txt new file mode 100644 index 000..c9fb2d44 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/qcom_hidma.txt @@ -0,0 +1,18 @@ +Qualcomm Technologies HIDMA Channel driver + +Required properties: +- compatible: must contain "qcom,hidma" This should be "qcom,hidma-1.0" to match the example and driver. I would drop "qcom,hidma" altogether. I matched it. Rob -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 4/4] dma: add Qualcomm Technologies HIDMA channel driver
On 11/8/2015 3:47 PM, Andy Shevchenko wrote:
+ trca_resource = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>+ if (!trca_resource) {
>+ rc = -ENODEV;
>+ goto bailout;
>+ }
Why did you ignore my comment about this block?
Remove that condition entirely.
>+
>+ trca = devm_ioremap_resource(>dev, trca_resource);
>+ if (IS_ERR(trca)) {
>+ rc = -ENOMEM;
>+ goto bailout;
>+ }
Sorry, I didn't quite get your comment. I thought you wanted to see
platform_get_resource and devm_ioremap_resource together.
Which one do you want me to remove?
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: fix returnvar.cocci warnings
On 11/8/2015 4:39 PM, Daniel K. wrote:
On 11/08/2015 07:45 AM, Julia Lawall wrote:
Remove unneeded variable used to store return value.
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -567,14 +567,13 @@ int hidma_ll_resume(struct hidma_lldev *
static int hidma_ll_hw_start(struct hidma_lldev *lldev)
{
- int rc = 0;
unsigned long irqflags;
spin_lock_irqsave(>lock, irqflags);
writel(lldev->tre_write_offset, lldev->trca + TRCA_DOORBELL_OFFSET);
spin_unlock_irqrestore(>lock, irqflags);
- return rc;
+ return 0;
}
bool hidma_ll_isenabled(struct hidma_lldev *lldev)
Seems rather pointless, what about 'static void ...' and dropping the
return statement?
Daniel K.
Yes, that's what I ended up doing. rc was forgotten there because I had
to restructure code to use the issue_pending API.
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 2/3] scsi: fix compiler warning for sg
The MULDIV macro has been designed for small numbers.
Compiler emits an overflow warning on 64 bit systems.
This patch uses 64 bit numbers in order to suppress
warning.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/scsi/sg.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 9d7b7db..112d8974 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -51,6 +51,7 @@ static int sg_version_num = 30536;/* 2 digits for each
component */
#include
#include
#include
+#include
#include "scsi.h"
#include
@@ -85,12 +86,17 @@ static void sg_proc_cleanup(void);
* Replacing muldiv(x) by muldiv(x)=((x % d) * m) / d + int(x / d) * m
* calculates the same, but prevents the overflow when both m and d
* are "small" numbers (like HZ and USER_HZ).
- * Of course an overflow is inavoidable if the result of muldiv doesn't fit
- * in 32 bits.
*/
-#define MULDIV(X,MUL,DIV) X % DIV) * MUL) / DIV) + ((X / DIV) * MUL))
+static inline u64 mult_frac64(u64 x, u32 numer, u32 denom)
+{
+ u64 r1 = do_div(x, denom);
+ u64 r2 = r1 * numer;
+
+ do_div(r2, denom);
+ return (x * numer) + r2;
+}
-#define SG_DEFAULT_TIMEOUT MULDIV(SG_DEFAULT_TIMEOUT_USER, HZ, USER_HZ)
+#define SG_DEFAULT_TIMEOUT mult_frac64(SG_DEFAULT_TIMEOUT_USER, HZ, USER_HZ)
int sg_big_buff = SG_DEF_RESERVED_SIZE;
/* N.B. This variable is readable and writeable via
@@ -877,10 +883,10 @@ sg_ioctl(struct file *filp, unsigned int cmd_in, unsigned
long arg)
return result;
if (val < 0)
return -EIO;
- if (val >= MULDIV (INT_MAX, USER_HZ, HZ))
- val = MULDIV (INT_MAX, USER_HZ, HZ);
+ if (val >= mult_frac64(INT_MAX, USER_HZ, HZ))
+ val = mult_frac64(INT_MAX, USER_HZ, HZ);
sfp->timeout_user = val;
- sfp->timeout = MULDIV (val, HZ, USER_HZ);
+ sfp->timeout = mult_frac64(val, HZ, USER_HZ);
return 0;
case SG_GET_TIMEOUT:/* N.B. User receives timeout as return value */
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 3/3] scsi: mptxsas: offload IRQ execution
The mpt2sas and mpt3sas drivers are spinning forever in
their IRQ handlers if there are a lot of jobs queued up
by the PCIe card. This handler is causing spikes for
the rest of the system and sluggish behavior.
Marking all MSI interrupts as non-shared and moving the
MSI interrupts to thread context. This relexes the rest
of the system execution.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/scsi/mpt2sas/mpt2sas_base.c | 12
drivers/scsi/mpt3sas/mpt3sas_base.c | 13 +
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index c61c82a..b619a0e 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -1359,14 +1359,18 @@ _base_request_irq(struct MPT2SAS_ADAPTER *ioc, u8
index, u32 vector)
cpumask_clear(reply_q->affinity_hint);
atomic_set(_q->busy, 0);
- if (ioc->msix_enable)
+ if (ioc->msix_enable) {
snprintf(reply_q->name, MPT_NAME_LENGTH, "%s%d-msix%d",
MPT2SAS_DRIVER_NAME, ioc->id, index);
- else
+ r = request_threaded_irq(vector, NULL, _base_interrupt,
+IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+reply_q->name, reply_q);
+ } else {
snprintf(reply_q->name, MPT_NAME_LENGTH, "%s%d",
MPT2SAS_DRIVER_NAME, ioc->id);
- r = request_irq(vector, _base_interrupt, IRQF_SHARED, reply_q->name,
- reply_q);
+ r = request_irq(vector, _base_interrupt, IRQF_SHARED,
+ reply_q->name, reply_q);
+ }
if (r) {
printk(MPT2SAS_ERR_FMT "unable to allocate interrupt %d!\n",
reply_q->name, vector);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 6dc391c..62bee43 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1661,14 +1661,19 @@ _base_request_irq(struct MPT3SAS_ADAPTER *ioc, u8
index, u32 vector)
cpumask_clear(reply_q->affinity_hint);
atomic_set(_q->busy, 0);
- if (ioc->msix_enable)
+ if (ioc->msix_enable) {
snprintf(reply_q->name, MPT_NAME_LENGTH, "%s%d-msix%d",
MPT3SAS_DRIVER_NAME, ioc->id, index);
- else
+
+ r = request_threaded_irq(vector, NULL, _base_interrupt,
+IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+reply_q->name, reply_q);
+ } else {
snprintf(reply_q->name, MPT_NAME_LENGTH, "%s%d",
MPT3SAS_DRIVER_NAME, ioc->id);
- r = request_irq(vector, _base_interrupt, IRQF_SHARED, reply_q->name,
- reply_q);
+ r = request_irq(vector, _base_interrupt, IRQF_SHARED,
+ reply_q->name, reply_q);
+ }
if (r) {
pr_err(MPT3SAS_FMT "unable to allocate interrupt %d!\n",
reply_q->name, vector);
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails
Current code gives up when 32 bit DMA is not supported.
This problem has been observed on systems without any
memory below 4 gig.
This patch tests 64 bit support before bailing out to find
a working combination.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
drivers/scsi/mpt2sas/mpt2sas_base.c | 21 -
drivers/scsi/mpt3sas/mpt3sas_base.c | 22 +-
2 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index c167911..c61c82a 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -1217,8 +1217,27 @@ _base_config_dma_addressing(struct MPT2SAS_ADAPTER *ioc,
struct pci_dev *pdev)
ioc->base_add_sg_single = &_base_add_sg_single_32;
ioc->sge_size = sizeof(Mpi2SGESimple32_t);
ioc->dma_mask = 32;
- } else
+ } else {
+ /* Try 64 bit, 32 bit failed */
+ consistent_dma_mask = DMA_BIT_MASK(64);
+
+ if (sizeof(dma_addr_t) > 4) {
+ const uint64_t required_mask =
+ dma_get_required_mask(>dev);
+ if ((required_mask > DMA_BIT_MASK(32)) &&
+ !pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) &&
+ !pci_set_consistent_dma_mask(pdev,
+ consistent_dma_mask)) {
+ ioc->base_add_sg_single =
+ &_base_add_sg_single_64;
+ ioc->sge_size = sizeof(Mpi2SGESimple64_t);
+ ioc->dma_mask = 64;
+ goto out;
+ }
+ }
+
return -ENODEV;
+ }
out:
si_meminfo();
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index d4f1dcd..6dc391c 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1535,9 +1535,29 @@ _base_config_dma_addressing(struct MPT3SAS_ADAPTER *ioc,
struct pci_dev *pdev)
ioc->base_add_sg_single = &_base_add_sg_single_32;
ioc->sge_size = sizeof(Mpi2SGESimple32_t);
ioc->dma_mask = 32;
- } else
+ } else {
+ /* Try 64 bit, 32 bit failed */
+ consistent_dma_mask = DMA_BIT_MASK(64);
+ if (sizeof(dma_addr_t) > 4) {
+ const uint64_t required_mask =
+ dma_get_required_mask(>dev);
+ int consistent_mask =
+ pci_set_consistent_dma_mask(pdev,
+ consistent_dma_mask);
+
+ if ((required_mask > DMA_BIT_MASK(32)) &&
+ !pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) &&
+ !consistent_mask) {
+ ioc->base_add_sg_single =
+ &_base_add_sg_single_64;
+ ioc->sge_size = sizeof(Mpi2SGESimple64_t);
+ ioc->dma_mask = 64;
+ goto out;
+ }
+ }
return -ENODEV;
+ }
out:
si_meminfo();
pr_info(MPT3SAS_FMT
--
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 0/3] scsi: mptxsas: updates for ARM64
Changes from V1: (https://lkml.org/lkml/2015/11/4/856) Changes from V1: (https://lkml.org/lkml/2015/11/4/859) * merge two patches together Changes from V1: (https://lkml.org/lkml/2015/11/4/857) * Use do_div to handle the linker errors on i386 Changes from V1: https://lkml.org/lkml/2015/11/4/858 * None Sinan Kaya (3): scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails scsi: fix compiler warning for sg scsi: mptxsas: offload IRQ execution drivers/scsi/mpt2sas/mpt2sas_base.c | 33 - drivers/scsi/mpt3sas/mpt3sas_base.c | 35 ++- drivers/scsi/sg.c | 20 +--- 3 files changed, 71 insertions(+), 17 deletions(-) -- Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 2/4] dma: add Qualcomm Technologies HIDMA management driver
On 11/8/2015 12:08 AM, Timur Tabi wrote:
On 11/8/2015 12:08 AM, Timur Tabi wrote:
Sinan Kaya wrote:
+val = val & ~(MAX_BUS_REQ_LEN_MASK << MAX_BUS_WR_REQ_BIT_POS);
+val = val | (mgmtdev->max_write_request << MAX_BUS_WR_REQ_BIT_POS);
+val = val & ~(MAX_BUS_REQ_LEN_MASK);
+val = val | (mgmtdev->max_read_request);
val &= ~MAX_BUS_REQ_LEN_MASK << MAX_BUS_WR_REQ_BIT_POS;
val |= mgmtdev->max_write_request << MAX_BUS_WR_REQ_BIT_POS;
val &= ~MAX_BUS_REQ_LEN_MASK;
val |= mgmtdev->max_read_request;
+static const struct of_device_id hidma_mgmt_match[] = {
+{ .compatible = "qcom,hidma-mgmt", },
+{ .compatible = "qcom,hidma-mgmt-1.0", },
+{ .compatible = "qcom,hidma-mgmt-1.1", },
+{},
+};
I thought Rob said that he did NOT want to use version numbers in
compatible strings. And what's the difference between these three
versions anyway?
This was already discussed here.
https://lkml.org/lkml/2015/11/2/689
The agreement was to use
compatible = "qcom,hidma-mgmt-1.1", "qcom,hidma-mgmt-1.0",
"qcom,hidma-mgmt";
I'll be adding code for v1.1 specifically in the future.
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 4/4] dma: add Qualcomm Technologies HIDMA channel driver
On 11/8/2015 2:13 PM, kbuild test robot wrote:
Hi Sinan,
[auto build test WARNING on: robh/for-next]
[also build test WARNING on: v4.3 next-20151106]
url:
https://github.com/0day-ci/linux/commits/Sinan-Kaya/ma-add-Qualcomm-Technologies-HIDMA-driver/20151108-125824
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: mn10300-allyesconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mn10300
All warnings (new ones prefixed by >>):
In file included from include/linux/printk.h:277:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/linux/dmaengine.h:20,
from drivers/dma/qcom/hidma.c:45:
drivers/dma/qcom/hidma.c: In function 'hidma_prep_dma_memcpy':
include/linux/dynamic_debug.h:64:16: warning: format '%zu' expects argument
of type 'size_t', but argument 7 has type 'unsigned int' [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:84:2: note: in expansion of macro
'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/device.h:1171:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
^
drivers/dma/qcom/hidma.c:391:2: note: in expansion of macro 'dev_dbg'
dev_dbg(mdma->ddev.dev,
^
vim +/dev_dbg +391 drivers/dma/qcom/hidma.c
375
376 mchan->allocated = 0;
377 spin_unlock_irqrestore(>lock, irqflags);
378 dev_dbg(mdma->ddev.dev, "freed channel for %u\n",
mchan->dma_sig);
379 }
380
381
382 static struct dma_async_tx_descriptor *
383 hidma_prep_dma_memcpy(struct dma_chan *dmach, dma_addr_t dma_dest,
384 dma_addr_t dma_src, size_t len, unsigned long
flags)
385 {
386 struct hidma_chan *mchan = to_hidma_chan(dmach);
387 struct hidma_desc *mdesc = NULL;
388 struct hidma_dev *mdma = mchan->dmadev;
389 unsigned long irqflags;
390
> 391 dev_dbg(mdma->ddev.dev,
392 "memcpy: chan:%p dest:%pad src:%pad len:%zu\n", mchan,
393 _dest, _src, len);
394
What am I missing?
len is size_t. This page says use %zu for size_t.
https://www.kernel.org/doc/Documentation/printk-formats.txt
395 /* Get free descriptor */
396 spin_lock_irqsave(>lock, irqflags);
397 if (!list_empty(>free)) {
398 mdesc = list_first_entry(>free, struct
hidma_desc,
399 node);
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 3/4] dmaselftest: add memcpy selftest support functions
On 11/8/2015 12:13 AM, Timur Tabi wrote:
Sinan Kaya wrote:
+static int dma_selftest_sg(struct dma_device *dmadev,
+struct dma_chan *dma_chanptr, u64 size,
+unsigned long flags)
+{
+dma_addr_t src_dma, dest_dma, dest_dma_it;
+u8 *dest_buf;
+u32 i, j = 0;
+dma_cookie_t cookie;
+struct dma_async_tx_descriptor *tx;
+int err = 0;
+int ret;
+struct sg_table sg_table;
+struct scatterlist*sg;
+int nents = 10, count;
+bool free_channel = 1;
Booleans are either 'true' or 'false'.
OK
+static int dma_selftest_mapsngle(struct device *dev)
+{
+u32 buf_size = 256;
+char *src;
+int ret = -ENOMEM;
+dma_addr_t dma_src;
+
+src = kmalloc(buf_size, GFP_KERNEL);
+if (!src)
+return -ENOMEM;
+
+strcpy(src, "hello world");
kstrdup()?
And why kmalloc anyway? Why not leave it on the stack?
char src[] = "hello world";
?
I need to call dma_map_single on this address to convert it to a DMA
address. That's why.
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] acpi: add support for extended IRQ to PCI link
On 11/8/2015 11:11 AM, Timur Tabi wrote: Sinan Kaya wrote: -#define ACPI_MAX_IRQS256 +#define ACPI_MAX_IRQS1020 Why 1020? Why not 1024? 1020 is the maximum interrupt ID that can be directed to an ARM SPI interrupt according to ARM architecture. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 4/4] dma: add Qualcomm Technologies HIDMA channel driver
On 11/8/2015 3:47 PM, Andy Shevchenko wrote:
On Sun, Nov 8, 2015 at 6:53 AM, Sinan Kaya <ok...@codeaurora.org> wrote:
This patch adds support for hidma engine. The driver
consists of two logical blocks. The DMA engine interface
and the low-level interface. The hardware only supports
memcpy/memset and this driver only support memcpy
interface. HW and driver doesn't support slave interface.
Make lines a bit longer.
OK
+ pm_runtime_set_autosuspend_delay(>dev, AUTOSUSPEND_TIMEOUT);
+ pm_runtime_use_autosuspend(>dev);
+ pm_runtime_set_active(>dev);
+ pm_runtime_enable(>dev);
+
+ trca_resource = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!trca_resource) {
+ rc = -ENODEV;
+ goto bailout;
+ }
Why did you ignore my comment about this block?
Remove that condition entirely.
Removed these four lines above.
+
+ trca = devm_ioremap_resource(>dev, trca_resource);
+ if (IS_ERR(trca)) {
+ rc = -ENOMEM;
+ goto bailout;
+ }
+
+ evca_resource = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!evca_resource) {
+ rc = -ENODEV;
+ goto bailout;
+ }
Ditto.
done
+uninit:
+ hidma_debug_uninit(dmadev);
+ hidma_ll_uninit(dmadev->lldev);
+dmafree:
+ if (dmadev)
+ hidma_free(dmadev);
+bailout:
+ pm_runtime_disable(>dev);
+ pm_runtime_put_sync_suspend(>dev);
Are you sure this is appropriate sequence?
I think
pm_runtime_put();
pm_runtime_disable();
corrected, reordered and used pm_runtime_put_sync() instead.
will do the job.
+ return rc;
+}
+
+static int hidma_remove(struct platform_device *pdev)
+{
+ struct hidma_dev *dmadev = platform_get_drvdata(pdev);
+
+ dev_dbg(>dev, "removing\n");
Useless message.
Removed.
+ pm_runtime_get_sync(dmadev->ddev.dev);
+
+ dma_async_device_unregister(>ddev);
+ hidma_debug_uninit(dmadev);
+ hidma_ll_uninit(dmadev->lldev);
+ hidma_free(dmadev);
+
+ dev_info(>dev, "HI-DMA engine removed\n");
+ pm_runtime_put_sync_suspend(>dev);
+ pm_runtime_disable(>dev);
+
+ return 0;
+}
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] acpi: add support for extended IRQ to PCI link
On 11/9/2015 12:24 AM, Jiang Liu wrote:
+ u32 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
>u8 initialized:1;
>u8 reserved:7;
> };
Hi Sinan,
This data structure become some sort of big, any idea to reduce
memory consumption?
Thanks,
Gerry
Hi Gerry,
There are two constants in the code.
#define ACPI_PCI_LINK_MAX_POSSIBLE 16
I changed the data type above. Previously it was consuming 16 bytes now
64 bytes.
The second one is this.
#define ACPI_MAX_IRQS 256
I changed ACPI_MAX_IRQS to 1020 from 256. Let's assume 1024.
I'm concerned about this though since you warned. This used to consume
1024 bytes now 4096 bytes.
static int acpi_irq_penalty[ACPI_MAX_IRQS] = {
PIRQ_PENALTY_ISA_ALWAYS,/* IRQ0 timer */
...
}
Sinan
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 1/4] dma: qcom_bam_dma: move to qcom directory
Creating a QCOM directory for all QCOM DMA source files. Signed-off-by: Sinan Kaya <ok...@codeaurora.org> --- drivers/dma/Kconfig| 13 +- drivers/dma/Makefile |2 +- drivers/dma/qcom/Kconfig |9 + drivers/dma/qcom/Makefile |1 + drivers/dma/qcom/bam_dma.c | 1259 drivers/dma/qcom_bam_dma.c | 1259 6 files changed, 1273 insertions(+), 1270 deletions(-) create mode 100644 drivers/dma/qcom/Kconfig create mode 100644 drivers/dma/qcom/Makefile create mode 100644 drivers/dma/qcom/bam_dma.c delete mode 100644 drivers/dma/qcom_bam_dma.c diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index b458475..d17d9ec 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -320,7 +320,7 @@ config MOXART_DMA select DMA_VIRTUAL_CHANNELS help Enable support for the MOXA ART SoC DMA controller. - + Say Y here if you enabled MMP ADMA, otherwise say N. config MPC512X_DMA @@ -408,15 +408,6 @@ config PXA_DMA 16 to 32 channels for peripheral to memory or memory to memory transfers. -config QCOM_BAM_DMA - tristate "QCOM BAM DMA support" - depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM) - select DMA_ENGINE - select DMA_VIRTUAL_CHANNELS - ---help--- - Enable support for the QCOM BAM DMA controller. This controller - provides DMA capabilities for a variety of on-chip devices. - config SIRF_DMA tristate "CSR SiRFprimaII/SiRFmarco DMA support" depends on ARCH_SIRF @@ -527,6 +518,8 @@ config ZX_DMA # driver files source "drivers/dma/bestcomm/Kconfig" +source "drivers/dma/qcom/Kconfig" + source "drivers/dma/dw/Kconfig" source "drivers/dma/hsu/Kconfig" diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index 7711a71..8dba90d 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -52,7 +52,6 @@ obj-$(CONFIG_PCH_DMA) += pch_dma.o obj-$(CONFIG_PL330_DMA) += pl330.o obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/ obj-$(CONFIG_PXA_DMA) += pxa_dma.o -obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o obj-$(CONFIG_RENESAS_DMA) += sh/ obj-$(CONFIG_SIRF_DMA) += sirf-dma.o obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o @@ -66,4 +65,5 @@ obj-$(CONFIG_TI_EDMA) += edma.o obj-$(CONFIG_XGENE_DMA) += xgene-dma.o obj-$(CONFIG_ZX_DMA) += zx296702_dma.o +obj-y += qcom/ obj-y += xilinx/ diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig new file mode 100644 index 000..17545df --- /dev/null +++ b/drivers/dma/qcom/Kconfig @@ -0,0 +1,9 @@ +config QCOM_BAM_DMA + tristate "QCOM BAM DMA support" + depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM) + select DMA_ENGINE + select DMA_VIRTUAL_CHANNELS + ---help--- + Enable support for the QCOM BAM DMA controller. This controller + provides DMA capabilities for a variety of on-chip devices. + diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile new file mode 100644 index 000..f612ae3 --- /dev/null +++ b/drivers/dma/qcom/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c new file mode 100644 index 000..5359234 --- /dev/null +++ b/drivers/dma/qcom/bam_dma.c @@ -0,0 +1,1259 @@ +/* + * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ +/* + * QCOM BAM DMA engine driver + * + * QCOM BAM DMA blocks are distributed amongst a number of the on-chip + * peripherals on the MSM 8x74. The configuration of the channels are dependent + * on the way they are hard wired to that specific peripheral. The peripheral + * device tree entries specify the configuration of each channel. + * + * The DMA controller requires the use of external memory for storage of the + * hardware descriptors for each channel. The descriptor FIFO is accessed as a + * circular buffer and operations are managed according to the offset within the + * FIFO. After pipe/channel reset, all of the pipe registers and internal state + * are back to defaults. + * + * During DMA operations, we write descriptors to the FIFO, being careful to + * handle wrapping and then write the last FIFO offset to that channel's + * P_EVNT_REG register to kick off the transaction. The P_SW_OFSTS register + * indicates the current FIF
[PATCH V3 0/4] *ma: add Qualcomm Technologies HIDMA driver
The Qualcomm Technologies HIDMA device has been designed to support virtualization technology. The driver has been divided into two to follow the hardware design. 1. HIDMA Management driver 2. HIDMA Channel driver Each HIDMA HW consists of multiple channels. These channels share some set of common parameters. These parameters are initialized by the management driver during power up. Same management driver is used for monitoring the execution of the channels. Management driver can change the performance behavior dynamically such as bandwidth allocation and prioritization in the future. The management driver is executed in hypervisor context and is the main management entity for all channels provided by the device. Changes from V2: (https://lkml.org/lkml/2015/11/2/43) * compatible = "qcom,hidma-mgmt-1.1", "qcom,hidma-mgmt-1.0", "qcom,hidma-mgmt"; * change channel-reset-timeout-cycles * more description for the HW operation and driver organization * consolidate devm_ioremap_resource * make print message more meaningfule. * remove print at uninstall * remove debugfs for now, create simple sysfs entries instead * Move code to qcom directory. Changes from V2: (https://lkml.org/lkml/2015/11/2/44) * none Changes from V2: (https://lkml.org/lkml/2015/11/2/45) * Clarify the relaxed accessor usage in ISR. * Replace all non-performance critical accessors with safe versions. * Correct multiline comment syntax. * Remove name variable. * Eliminate redundant list_empty checks. * Remove locks in hidma_tx_status. * Document why hidma_issue_pending is empty. * Fix the return code to 0 for hidma_ll_request. * Consolidate devm_ioremap_resource functions in probe. * Move PM calls inside the paused conditional. * One tasklet for all completions rather than one tasklet per completion. Completions are queued into kfifo and consumed by a single tasklet. * Move start of actual transfer to issue_pending * Simplify return path when DMA mask set fails. * Move code to qcom directory. Sinan Kaya (4): dma: qcom_bam_dma: move to qcom directory dma: add Qualcomm Technologies HIDMA management driver dmaselftest: add memcpy selftest support functions dma: add Qualcomm Technologies HIDMA channel driver .../devicetree/bindings/dma/qcom_hidma.txt | 18 + .../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 62 + drivers/dma/Kconfig| 13 +- drivers/dma/Makefile |2 +- drivers/dma/dmaengine.h|2 + drivers/dma/dmaselftest.c | 669 +++ drivers/dma/qcom/Kconfig | 29 + drivers/dma/qcom/Makefile |4 + drivers/dma/qcom/bam_dma.c | 1259 drivers/dma/qcom/hidma.c | 743 drivers/dma/qcom/hidma.h | 157 +++ drivers/dma/qcom/hidma_dbg.c | 225 drivers/dma/qcom/hidma_ll.c| 944 +++ drivers/dma/qcom/hidma_mgmt.c | 315 + drivers/dma/qcom/hidma_mgmt.h | 38 + drivers/dma/qcom/hidma_mgmt_sys.c | 232 drivers/dma/qcom_bam_dma.c | 1259 17 files changed, 4701 insertions(+), 1270 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt create mode 100644 drivers/dma/dmaselftest.c create mode 100644 drivers/dma/qcom/Kconfig create mode 100644 drivers/dma/qcom/Makefile create mode 100644 drivers/dma/qcom/bam_dma.c create mode 100644 drivers/dma/qcom/hidma.c create mode 100644 drivers/dma/qcom/hidma.h create mode 100644 drivers/dma/qcom/hidma_dbg.c create mode 100644 drivers/dma/qcom/hidma_ll.c create mode 100644 drivers/dma/qcom/hidma_mgmt.c create mode 100644 drivers/dma/qcom/hidma_mgmt.h create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c delete mode 100644 drivers/dma/qcom_bam_dma.c -- Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 2/4] dma: add Qualcomm Technologies HIDMA management driver
The Qualcomm Technologies HIDMA device has been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design.
1. HIDMA Management driver
2. HIDMA Channel driver
Each HIDMA HW consists of multiple channels. These channels
share some set of common parameters. These parameters are
initialized by the management driver during power up.
Same management driver is used for monitoring the execution
of the channels. Management driver can change the performance
behavior dynamically such as bandwidth allocation and
prioritization in the future.
The management driver is executed in hypervisor context and
is the main management entity for all channels provided by
the device.
Signed-off-by: Sinan Kaya <ok...@codeaurora.org>
---
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 62
drivers/dma/qcom/Kconfig | 11 +
drivers/dma/qcom/Makefile | 1 +
drivers/dma/qcom/hidma_mgmt.c | 315 +
drivers/dma/qcom/hidma_mgmt.h | 38 +++
drivers/dma/qcom/hidma_mgmt_sys.c | 232 +++
6 files changed, 659 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
create mode 100644 drivers/dma/qcom/hidma_mgmt.c
create mode 100644 drivers/dma/qcom/hidma_mgmt.h
create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
new file mode 100644
index 000..b906170
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -0,0 +1,62 @@
+Qualcomm Technologies HIDMA Management interface
+
+The Qualcomm Technologies HIDMA device has been designed
+to support virtualization technology. The driver has been
+divided into two to follow the hardware design. The management
+driver is executed in hypervisor context and is the main
+management entity for all channels provided by the device.
+
+Each HIDMA HW consists of multiple channels. These channels
+share some set of common parameters. These parameters are
+initialized by the management driver during power up.
+Same management driver is used for monitoring the execution
+of the channels. Management driver can change the performance
+behavior dynamically such as bandwidth allocation and
+prioritization.
+
+All channel devices get probed in the hypervisor
+context during power up. They show up as DMA engine
+DMA channels. Then, before starting the virtualization; each
+channel device is unbound from the hypervisor by VFIO
+and assign to the guest machine for control.
+
+This management driver will be used by the system
+admin to monitor/reset the execution state of the DMA
+channels. This will be the management interface.
+
+
+Required properties:
+- compatible: must contain one of these.
+ "qcom,hidma-mgmt-1.1", "qcom,hidma-mgmt-1.0", "qcom,hidma-mgmt";
+- reg: Address range for DMA device
+- dma-channels: Number of channels supported by this DMA controller.
+- max-write-burst-bytes: Maximum write burst in bytes. A memcpy requested is
+ fragmented to multiples of this amount.
+- max-read-burst-bytes: Maximum read burst in bytes. A memcpy request is
+ fragmented to multiples of this amount.
+- max-write-transactions: Maximum write transactions to perform in a burst
+- max-read-transactions: Maximum read transactions to perform in a burst
+- channel-reset-timeout-cycles: Channel reset timeout in cycles for this SOC.
+- channel-priority: Priority of the channel.
+ Each dma channel share the same HW bandwidth with other dma channels.
+ If two requests reach to the HW at the same time from a low priority and
+ high priority channel, high priority channel will claim the bus.
+ 0=low priority, 1=high priority
+- channel-weight: Round robin weight of the channel
+ Since there are only two priority levels supported, scheduling among
+ the equal priority channels is done via weights.
+
+Example:
+
+ hidma-mgmt@f9984000 = {
+ compatible = "qcom,hidma-mgmt-1.0";
+ reg = <0xf9984000 0x15000>;
+ dma-channels = 6;
+ max-write-burst-bytes = 1024;
+ max-read-burst-bytes = 1024;
+ max-write-transactions = 31;
+ max-read-transactions = 31;
+ channel-reset-timeout-cycles = 0x500;
+ channel-priority = < 1 1 0 0 0 0>;
+ channel-weight = < 1 13 10 3 4 5>;
+ };
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index 17545df..f3e2d4c 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -7,3 +7,14 @@ config QCOM_BAM_DMA
Enable support for the QCOM BAM DMA controller. This controller
provides DMA capabilities for a variety of on-chip devices.
+conf
