From: Sinan Kaya <hidden> Date: 2016-01-11 14:46:04
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.
Creating a QCOM directory for all QCOM DMA source files.
Changes from V11: (https://lkml.org/lkml/2016/1/3/249)
* none
dma: hidma: Add Device Tree support
Changes from V11: (https://lkml.org/lkml/2016/1/3/243)
* none
dma: add Qualcomm Technologies HIDMA management driver
Changes from V11: (https://lkml.org/lkml/2016/1/3/248)
* Correct range check in the sysfs.
* increase the print array in sysfs.
dma: add Qualcomm Technologies HIDMA channel driver
Changes from V11: (https://lkml.org/lkml/2016/1/3/244)
* none
dma: qcom_hidma: implement lower level hardware interface
Changes from V11: (https://lkml.org/lkml/2016/1/3/247)
* introduce HIDMA_CH_STATE macro to simplify testing conditions.
* introduce HIDMA_INCREMENT_ITERATOR macro to simplify code
* replace devm_kzalloc with devm_kcalloc in certain places.
dma: qcom_hidma: add debugfs hooks
Changes from V11: (https://lkml.org/lkml/2016/1/3/245)
* none
dma: qcom_hidma: add support for object hierarchy
Changes from V11: (https://lkml.org/lkml/2016/1/3/246)
* 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 | 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
--
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
@@ -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 at 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 at 0x5c050000 {+ compatible = "qcom,hidma-1.0";+ reg = <0 0x5c050000 0x0 0x1000>,+ <0 0x5c0b0000 0x0 0x1000>;+ interrupts = <0 389 0>;+ desc-count = <10>;+ channel-index = <4>;+ };+ };++Guest OS configuration:++ hidma_24: dma-controller at 0x5c050000 {+ compatible = "qcom,hidma-1.0";+ reg = <0 0x5c050000 0x0 0x1000>,+ <0 0x5c0b0000 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
From: Sinan Kaya <hidden> Date: 2016-01-11 14:46:14
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 <redacted>
Reviewed-by: Andy Shevchenko <redacted>
---
.../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
@@ -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 <okaya@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 <okaya@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 <okaya@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 <okaya@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 <okaya@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 <okaya@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 <okaya@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+Contact: "Sinan Kaya <okaya@cudeaurora.org>"+Description:+ Size of each read request. The value needs to be a power+ of two and can be between 128 and 1024.++What: /sys/devices/platform/hidma-mgmt*/max_wr_xactions+ /sys/devices/platform/QCOM8060:*/max_wr_xactions+Date: Nov 2015+KernelVersion: 4.4+Contact: "Sinan Kaya <okaya@cudeaurora.org>"+Description:+ Contains a value between 0 and 31. Maximum number of+ write 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_write_request+ /sys/devices/platform/QCOM8060:*/max_write_request+Date: Nov 2015+KernelVersion: 4.4+Contact: "Sinan Kaya <okaya@cudeaurora.org>"+Description:+ Size of each write request. The value needs to be a power+ of two and can be between 128 and 1024.
@@ -0,0 +1,295 @@+/*+*QualcommTechnologiesHIDMAManagementSYSinterface+*+*Copyright(c)2015,TheLinuxFoundation.Allrightsreserved.+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodify+*itunderthetermsoftheGNUGeneralPublicLicenseversion2and+*onlyversion2aspublishedbytheFreeSoftwareFoundation.+*+*Thisprogramisdistributedinthehopethatitwillbeuseful,+*butWITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+*MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.Seethe+*GNUGeneralPublicLicenseformoredetails.+*/++#include<linux/sysfs.h>+#include<linux/platform_device.h>++#include"hidma_mgmt.h"++structhidma_chan_attr{+structhidma_mgmt_dev*mdev;+intindex;+structkobj_attributeattr;+};++structhidma_mgmt_fileinfo{+char*name;+intmode;+int(*get)(structhidma_mgmt_dev*mdev);+int(*set)(structhidma_mgmt_dev*mdev,u64val);+};++#define IMPLEMENT_GETSET(name) \+staticintget_##name(structhidma_mgmt_dev*mdev)\+{\+returnmdev->name;\+}\+staticintset_##name(structhidma_mgmt_dev*mdev,u64val)\+{\+u64tmp;\+intrc;\+\+tmp=mdev->name;\+mdev->name=val;\+rc=hidma_mgmt_setup(mdev);\+if(rc)\+mdev->name=tmp;\+returnrc;\+}++#define DECLARE_ATTRIBUTE(name, mode) \+{#name,mode,get_##name,set_##name}++IMPLEMENT_GETSET(hw_version_major)+IMPLEMENT_GETSET(hw_version_minor)+IMPLEMENT_GETSET(max_wr_xactions)+IMPLEMENT_GETSET(max_rd_xactions)+IMPLEMENT_GETSET(max_write_request)+IMPLEMENT_GETSET(max_read_request)+IMPLEMENT_GETSET(dma_channels)+IMPLEMENT_GETSET(chreset_timeout_cycles)++staticintset_priority(structhidma_mgmt_dev*mdev,unsignedinti,u64val)+{+u64tmp;+intrc;++if(i>=mdev->dma_channels)+return-EINVAL;++tmp=mdev->priority[i];+mdev->priority[i]=val;+rc=hidma_mgmt_setup(mdev);+if(rc)+mdev->priority[i]=tmp;+returnrc;+}++staticintset_weight(structhidma_mgmt_dev*mdev,unsignedinti,u64val)+{+u64tmp;+intrc;++if(i>=mdev->dma_channels)+return-EINVAL;++tmp=mdev->weight[i];+mdev->weight[i]=val;+rc=hidma_mgmt_setup(mdev);+if(rc)+mdev->weight[i]=tmp;+returnrc;+}++staticstructhidma_mgmt_fileinfohidma_mgmt_files[]={+DECLARE_ATTRIBUTE(hw_version_major,S_IRUGO),+DECLARE_ATTRIBUTE(hw_version_minor,S_IRUGO),+DECLARE_ATTRIBUTE(dma_channels,S_IRUGO),+DECLARE_ATTRIBUTE(chreset_timeout_cycles,S_IRUGO),+DECLARE_ATTRIBUTE(max_wr_xactions,(S_IRUGO|S_IWUGO)),+DECLARE_ATTRIBUTE(max_rd_xactions,(S_IRUGO|S_IWUGO)),+DECLARE_ATTRIBUTE(max_write_request,(S_IRUGO|S_IWUGO)),+DECLARE_ATTRIBUTE(max_read_request,(S_IRUGO|S_IWUGO)),+};++staticssize_tshow_values(structdevice*dev,structdevice_attribute*attr,+char*buf)+{+structplatform_device*pdev=to_platform_device(dev);+structhidma_mgmt_dev*mdev=platform_get_drvdata(pdev);+unsignedinti;++buf[0]=0;++for(i=0;i<ARRAY_SIZE(hidma_mgmt_files);i++){+if(strcmp(attr->attr.name,hidma_mgmt_files[i].name)==0){+sprintf(buf,"%d\n",hidma_mgmt_files[i].get(mdev));+break;+}+}+returnstrlen(buf);+}++staticssize_tset_values(structdevice*dev,structdevice_attribute*attr,+constchar*buf,size_tcount)+{+structplatform_device*pdev=to_platform_device(dev);+structhidma_mgmt_dev*mdev=platform_get_drvdata(pdev);+unsignedlongtmp;+unsignedinti;+intrc;++rc=kstrtoul(buf,0,&tmp);+if(rc)+returnrc;++for(i=0;i<ARRAY_SIZE(hidma_mgmt_files);i++){+if(strcmp(attr->attr.name,hidma_mgmt_files[i].name)==0){+rc=hidma_mgmt_files[i].set(mdev,tmp);+if(rc)+returnrc;++break;+}+}+returncount;+}++staticssize_tshow_values_channel(structkobject*kobj,+structkobj_attribute*attr,char*buf)+{+structhidma_chan_attr*chattr;+structhidma_mgmt_dev*mdev;++buf[0]=0;+chattr=container_of(attr,structhidma_chan_attr,attr);+mdev=chattr->mdev;+if(strcmp(attr->attr.name,"priority")==0)+sprintf(buf,"%d\n",mdev->priority[chattr->index]);+elseif(strcmp(attr->attr.name,"weight")==0)+sprintf(buf,"%d\n",mdev->weight[chattr->index]);++returnstrlen(buf);+}++staticssize_tset_values_channel(structkobject*kobj,+structkobj_attribute*attr,constchar*buf,+size_tcount)+{+structhidma_chan_attr*chattr;+structhidma_mgmt_dev*mdev;+unsignedlongtmp;+intrc;++chattr=container_of(attr,structhidma_chan_attr,attr);+mdev=chattr->mdev;++rc=kstrtoul(buf,0,&tmp);+if(rc)+returnrc;++if(strcmp(attr->attr.name,"priority")==0){+rc=set_priority(mdev,chattr->index,tmp);+if(rc)+returnrc;+}elseif(strcmp(attr->attr.name,"weight")==0){+rc=set_weight(mdev,chattr->index,tmp);+if(rc)+returnrc;+}+returncount;+}++staticintcreate_sysfs_entry(structhidma_mgmt_dev*dev,char*name,intmode)+{+structdevice_attribute*attrs;+char*name_copy;++attrs=devm_kmalloc(&dev->pdev->dev,+sizeof(structdevice_attribute),GFP_KERNEL);+if(!attrs)+return-ENOMEM;++name_copy=devm_kstrdup(&dev->pdev->dev,name,GFP_KERNEL);+if(!name_copy)+return-ENOMEM;++attrs->attr.name=name_copy;+attrs->attr.mode=mode;+attrs->show=show_values;+attrs->store=set_values;+sysfs_attr_init(&attrs->attr);++returndevice_create_file(&dev->pdev->dev,attrs);+}++staticintcreate_sysfs_entry_channel(structhidma_mgmt_dev*mdev,char*name,+intmode,intindex,+structkobject*parent)+{+structhidma_chan_attr*chattr;+char*name_copy;++chattr=devm_kmalloc(&mdev->pdev->dev,sizeof(*chattr),GFP_KERNEL);+if(!chattr)+return-ENOMEM;++name_copy=devm_kstrdup(&mdev->pdev->dev,name,GFP_KERNEL);+if(!name_copy)+return-ENOMEM;++chattr->mdev=mdev;+chattr->index=index;+chattr->attr.attr.name=name_copy;+chattr->attr.attr.mode=mode;+chattr->attr.show=show_values_channel;+chattr->attr.store=set_values_channel;+sysfs_attr_init(&chattr->attr.attr);++returnsysfs_create_file(parent,&chattr->attr.attr);+}++inthidma_mgmt_init_sys(structhidma_mgmt_dev*mdev)+{+unsignedinti;+intrc;+intrequired;+structkobject*chanops;++required=sizeof(*mdev->chroots)*mdev->dma_channels;+mdev->chroots=devm_kmalloc(&mdev->pdev->dev,required,GFP_KERNEL);+if(!mdev->chroots)+return-ENOMEM;++chanops=kobject_create_and_add("chanops",&mdev->pdev->dev.kobj);+if(!chanops)+return-ENOMEM;++/* create each channel directory here */+for(i=0;i<mdev->dma_channels;i++){+charname[20];++snprintf(name,sizeof(name),"chan%d",i);+mdev->chroots[i]=kobject_create_and_add(name,chanops);+if(!mdev->chroots[i])+return-ENOMEM;+}++/* populate common parameters */+for(i=0;i<ARRAY_SIZE(hidma_mgmt_files);i++){+rc=create_sysfs_entry(mdev,hidma_mgmt_files[i].name,+hidma_mgmt_files[i].mode);+if(rc)+returnrc;+}++/* populate parameters that are per channel */+for(i=0;i<mdev->dma_channels;i++){+rc=create_sysfs_entry_channel(mdev,"priority",+(S_IRUGO|S_IWUGO),i,+mdev->chroots[i]);+if(rc)+returnrc;++rc=create_sysfs_entry_channel(mdev,"weight",+(S_IRUGO|S_IWUGO),i,+mdev->chroots[i]);+if(rc)+returnrc;+}++return0;+}+EXPORT_SYMBOL_GPL(hidma_mgmt_init_sys);
--
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
From: Sinan Kaya <hidden> Date: 2016-01-11 14:46:21
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 <redacted>
---
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
@@ -37,7 +37,7 @@ struct hidma_tre {atomic_tallocated;/* if this channel is allocated */boolqueued;/* flag whether this is pending */u16status;/* status */-u32chidx;/* index of the tre */+u32idx;/* index of the tre */u32dma_sig;/* signature of the tre */constchar*dev_name;/* name of the device */void(*callback)(void*data);/* requester callback */
@@ -0,0 +1,927 @@+/*+*QualcommTechnologiesHIDMADMAenginelowlevelcode+*+*Copyright(c)2015,TheLinuxFoundation.Allrightsreserved.+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodify+*itunderthetermsoftheGNUGeneralPublicLicenseversion2and+*onlyversion2aspublishedbytheFreeSoftwareFoundation.+*+*Thisprogramisdistributedinthehopethatitwillbeuseful,+*butWITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+*MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.Seethe+*GNUGeneralPublicLicenseformoredetails.+*/++#include<linux/dmaengine.h>+#include<linux/slab.h>+#include<linux/interrupt.h>+#include<linux/mm.h>+#include<linux/highmem.h>+#include<linux/dma-mapping.h>+#include<linux/delay.h>+#include<linux/atomic.h>+#include<linux/iopoll.h>+#include<linux/kfifo.h>+#include<linux/bitops.h>++#include"hidma.h"++#define EVRE_SIZE 16 /* each EVRE is 16 bytes */++#define TRCA_CTRLSTS_OFFSET 0x000+#define TRCA_RING_LOW_OFFSET 0x008+#define TRCA_RING_HIGH_OFFSET 0x00C+#define TRCA_RING_LEN_OFFSET 0x010+#define TRCA_READ_PTR_OFFSET 0x018+#define TRCA_WRITE_PTR_OFFSET 0x020+#define TRCA_DOORBELL_OFFSET 0x400++#define EVCA_CTRLSTS_OFFSET 0x000+#define EVCA_INTCTRL_OFFSET 0x004+#define EVCA_RING_LOW_OFFSET 0x008+#define EVCA_RING_HIGH_OFFSET 0x00C+#define EVCA_RING_LEN_OFFSET 0x010+#define EVCA_READ_PTR_OFFSET 0x018+#define EVCA_WRITE_PTR_OFFSET 0x020+#define EVCA_DOORBELL_OFFSET 0x400++#define EVCA_IRQ_STAT_OFFSET 0x100+#define EVCA_IRQ_CLR_OFFSET 0x108+#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_MASK GENMASK(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++#define ENABLE_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))++#define HIDMA_INCREMENT_ITERATOR(iter, size, ring_size) \+do{\+iter+=size;\+if(iter>=ring_size)\+iter-=ring_size;\+}while(0)++#define HIDMA_CH_STATE(val) \+((val>>CH_STATE_BIT_POS)&CH_STATE_MASK)++enumch_command{+CH_DISABLE=0,+CH_ENABLE=1,+CH_SUSPEND=2,+CH_RESET=9,+};++enumch_state{+CH_DISABLED=0,+CH_ENABLED=1,+CH_RUNNING=2,+CH_SUSPENDED=3,+CH_STOPPED=4,+CH_ERROR=5,+CH_IN_RESET=9,+};++enumtre_type{+TRE_MEMCPY=3,+TRE_MEMSET=4,+};++enumevre_type{+EVRE_DMA_COMPLETE=0x23,+EVRE_IMM_DATA=0x24,+};++enumerr_code{+EVRE_STATUS_COMPLETE=1,+EVRE_STATUS_ERROR=4,+};++voidhidma_ll_free(structhidma_lldev*lldev,u32tre_ch)+{+structhidma_tre*tre;++if(tre_ch>=lldev->nr_tres){+dev_err(lldev->dev,"invalid TRE number in free:%d",tre_ch);+return;+}++tre=&lldev->trepool[tre_ch];+if(atomic_read(&tre->allocated)!=true){+dev_err(lldev->dev,"trying to free an unused TRE:%d",tre_ch);+return;+}++atomic_set(&tre->allocated,0);+}++inthidma_ll_request(structhidma_lldev*lldev,u32dma_sig,+constchar*dev_name,+void(*callback)(void*data),void*data,u32*tre_ch)+{+unsignedinti;+structhidma_tre*tre;+u32*tre_local;++if(!tre_ch||!lldev)+return-EINVAL;++/* need to have at least one empty spot in the queue */+for(i=0;i<lldev->nr_tres-1;i++){+if(atomic_add_unless(&lldev->trepool[i].allocated,1,1))+break;+}++if(i==(lldev->nr_tres-1))+return-ENOMEM;++tre=&lldev->trepool[i];+tre->dma_sig=dma_sig;+tre->dev_name=dev_name;+tre->callback=callback;+tre->data=data;+tre->idx=i;+tre->status=0;+tre->queued=0;+lldev->tx_status_list[i].err_code=0;+tre->lldev=lldev;+tre_local=&tre->tre_local[0];+tre_local[TRE_CFG_IDX]=TRE_MEMCPY;+tre_local[TRE_CFG_IDX]|=(lldev->chidx&0xFF)<<8;+tre_local[TRE_CFG_IDX]|=BIT(16);/* set IEOB */+*tre_ch=i;+if(callback)+callback(data);+return0;+}++/*+*MultipleTREsmaybequeuedandwaitinginthe+*pendingqueue.+*/+staticvoidhidma_ll_tre_complete(unsignedlongarg)+{+structhidma_lldev*lldev=(structhidma_lldev*)arg;+structhidma_tre*tre;++while(kfifo_out(&lldev->handoff_fifo,&tre,1)){+/* call the user if it has been read by the hardware */+if(tre->callback)+tre->callback(tre->data);+}+}++/*+*Calledtohandletheinterruptforthechannel.+*ReturnapositivenumberifTREorEVREwereconsumedonthisrun.+*ReturnapositivenumberiftherearependingTREsorEVREs.+*Return0ifthereisnothingtoconsumeornopendingTREs/EVREsfound.+*/+staticinthidma_handle_tre_completion(structhidma_lldev*lldev)+{+structhidma_tre*tre;+u32evre_write_off;+u32evre_ring_size=lldev->evre_ring_size;+u32tre_ring_size=lldev->tre_ring_size;+u32num_completed=0,tre_iterator,evre_iterator;+unsignedlongflags;++evre_write_off=readl_relaxed(lldev->evca+EVCA_WRITE_PTR_OFFSET);+tre_iterator=lldev->tre_processed_off;+evre_iterator=lldev->evre_processed_off;++if((evre_write_off>evre_ring_size)||+((evre_write_off%EVRE_SIZE)!=0)){+dev_err(lldev->dev,"HW reports invalid EVRE write offset\n");+return0;+}++/*+*BythetimecontrolreachesherethenumberofEVREsandTREs+*maynotmatch.Onlyconsumetheonesthathardwaretoldus.+*/+while((evre_iterator!=evre_write_off)){+u32*current_evre=lldev->evre_ring+evre_iterator;+u32cfg;+u8err_info;++spin_lock_irqsave(&lldev->lock,flags);+tre=lldev->pending_tre_list[tre_iterator/TRE_SIZE];+if(!tre){+spin_unlock_irqrestore(&lldev->lock,flags);+dev_warn(lldev->dev,+"tre_index [%d] and tre out of sync\n",+tre_iterator/TRE_SIZE);+HIDMA_INCREMENT_ITERATOR(tre_iterator,TRE_SIZE,+tre_ring_size);+HIDMA_INCREMENT_ITERATOR(evre_iterator,EVRE_SIZE,+evre_ring_size);+continue;+}+lldev->pending_tre_list[tre->tre_index]=NULL;++/*+*KeeptrackofpendingTREsthatSWisexpectingtoreceive+*fromHW.Wegotonenow.Decrementourcounter.+*/+lldev->pending_tre_count--;+if(lldev->pending_tre_count<0){+dev_warn(lldev->dev,+"tre count mismatch on completion");+lldev->pending_tre_count=0;+}++spin_unlock_irqrestore(&lldev->lock,flags);++cfg=current_evre[EVRE_CFG_IDX];+err_info=cfg>>EVRE_ERRINFO_BIT_POS;+err_info&=EVRE_ERRINFO_MASK;+lldev->tx_status_list[tre->idx].err_info=err_info;+lldev->tx_status_list[tre->idx].err_code=+(cfg>>EVRE_CODE_BIT_POS)&EVRE_CODE_MASK;+tre->queued=0;++kfifo_put(&lldev->handoff_fifo,tre);+tasklet_schedule(&lldev->task);++HIDMA_INCREMENT_ITERATOR(tre_iterator,TRE_SIZE,+tre_ring_size);+HIDMA_INCREMENT_ITERATOR(evre_iterator,EVRE_SIZE,+evre_ring_size);++/*+*ReadtheneweventdescriptorwrittenbytheHW.+*Asweareprocessingthedeliveredevents,otherevents+*getqueuedtotheSWforprocessing.+*/+evre_write_off=+readl_relaxed(lldev->evca+EVCA_WRITE_PTR_OFFSET);+num_completed++;+}++if(num_completed){+u32evre_read_off=(lldev->evre_processed_off++EVRE_SIZE*num_completed);+u32tre_read_off=(lldev->tre_processed_off++TRE_SIZE*num_completed);++evre_read_off=evre_read_off%evre_ring_size;+tre_read_off=tre_read_off%tre_ring_size;++writel(evre_read_off,lldev->evca+EVCA_DOORBELL_OFFSET);++/* record the last processed tre offset */+lldev->tre_processed_off=tre_read_off;+lldev->evre_processed_off=evre_read_off;+}++returnnum_completed;+}++voidhidma_cleanup_pending_tre(structhidma_lldev*lldev,u8err_info,+u8err_code)+{+u32tre_iterator;+structhidma_tre*tre;+u32tre_ring_size=lldev->tre_ring_size;+intnum_completed=0;+u32tre_read_off;+unsignedlongflags;++tre_iterator=lldev->tre_processed_off;+while(lldev->pending_tre_count){+inttre_index=tre_iterator/TRE_SIZE;++spin_lock_irqsave(&lldev->lock,flags);+tre=lldev->pending_tre_list[tre_index];+if(!tre){+spin_unlock_irqrestore(&lldev->lock,flags);+HIDMA_INCREMENT_ITERATOR(tre_iterator,TRE_SIZE,+tre_ring_size);+continue;+}+lldev->pending_tre_list[tre_index]=NULL;+lldev->pending_tre_count--;+if(lldev->pending_tre_count<0){+dev_warn(lldev->dev,+"tre count mismatch on completion");+lldev->pending_tre_count=0;+}+spin_unlock_irqrestore(&lldev->lock,flags);++lldev->tx_status_list[tre->idx].err_info=err_info;+lldev->tx_status_list[tre->idx].err_code=err_code;+tre->queued=0;++kfifo_put(&lldev->handoff_fifo,tre);+tasklet_schedule(&lldev->task);++HIDMA_INCREMENT_ITERATOR(tre_iterator,TRE_SIZE,+tre_ring_size);+num_completed++;+}+tre_read_off=(lldev->tre_processed_off+TRE_SIZE*num_completed);++tre_read_off=tre_read_off%tre_ring_size;++/* record the last processed tre offset */+lldev->tre_processed_off=tre_read_off;+}++staticinthidma_ll_reset(structhidma_lldev*lldev)+{+u32val;+intret;++val=readl(lldev->trca+TRCA_CTRLSTS_OFFSET);+val&=~(CH_CONTROL_MASK<<16);+val|=CH_RESET<<16;+writel(val,lldev->trca+TRCA_CTRLSTS_OFFSET);++/*+*Delay10msafterresettoallowDMAlogictoquiesce.+*Doapolledreadupto1msand10msmaximum.+*/+ret=readl_poll_timeout(lldev->trca+TRCA_CTRLSTS_OFFSET,val,+HIDMA_CH_STATE(val)==CH_DISABLED,1000,+10000);+if(ret){+dev_err(lldev->dev,"transfer channel did not reset\n");+returnret;+}++val=readl(lldev->evca+EVCA_CTRLSTS_OFFSET);+val&=~(CH_CONTROL_MASK<<16);+val|=CH_RESET<<16;+writel(val,lldev->evca+EVCA_CTRLSTS_OFFSET);++/*+*Delay10msafterresettoallowDMAlogictoquiesce.+*Doapolledreadupto1msand10msmaximum.+*/+ret=readl_poll_timeout(lldev->evca+EVCA_CTRLSTS_OFFSET,val,+HIDMA_CH_STATE(val)==CH_DISABLED,1000,+10000);+if(ret)+returnret;++lldev->trch_state=CH_DISABLED;+lldev->evch_state=CH_DISABLED;+return0;+}++staticvoidhidma_ll_enable_irq(structhidma_lldev*lldev,u32irq_bits)+{+writel(irq_bits,lldev->evca+EVCA_IRQ_EN_OFFSET);+}++/*+*TheinterrupthandlerforHIDMAwilltrytoconsumeasmanypending+*EVREfromtheeventqueueaspossible.EachEVREhasanassociated+*TREthatholdstheuserinterfaceparameters.EVREreportsthe+*resultofthetransaction.HardwareguaranteesorderingbetweenEVREs+*andTREs.WeuselastprocessedoffsettofigureoutwhichTREis+*associatedwithwhichEVRE.IftwoTREsareconsumedbyHW,theEVREs+*areinorderintheeventring.+*+*ThishandlerwilldoaonepassforconsumingEVREs.OtherEVREsmay+*bedeliveredwhileweareworking.Itwilltrytoconsumeincoming+*EVREsonemoretimeandreturn.+*+*ForunprocessedEVREs,hardwarewilltriggeranotherinterruptuntil+*alltheinterruptbitsarecleared.+*+*Hardwareguaranteesthatbythetimeinterruptisobserved,alldata+*transactionsinflightaredeliveredtotheirrespectiveplacesand+*arevisibletotheCPU.+*+*OndemandpagingforIOMMUisonlysupportedforPCIeviaPRI+*(PageRequestInterface)notforHIDMA.Allotherhardwareinstances+*includingHIDMAworkonpinnedDMAaddresses.+*+*HIDMAisnotawareofIOMMUpresencesinceitfollowstheDMAAPI.All+*IOMMUlatencywillbebuiltintothedatamovementtime.Bythetime+*interrupthappens,IOMMUlookups+datamovementhasalreadytakenplace.+*+*WhilethefirstreadinatypicalPCIendpointISRflushesalloutstanding+*requeststraditionallytothedestination,thisconceptdoesnotapply+*hereforthisHW.+*/+staticvoidhidma_ll_int_handler_internal(structhidma_lldev*lldev)+{+u32status;+u32enable;+u32cause;+intrepeat=2;+unsignedlongtimeout;++/*+*FinetunedforthisHW...+*+*ThisISRhasbeendesignedforthisparticularhardware.Relaxed+*readandwriteaccessorsareusedforperformancereasonsdueto+*interruptdeliveryguarantees.Donotcopythiscodeblindlyand+*expectthattowork.+*/+status=readl_relaxed(lldev->evca+EVCA_IRQ_STAT_OFFSET);+enable=readl_relaxed(lldev->evca+EVCA_IRQ_EN_OFFSET);+cause=status&enable;++if((cause&(BIT(IRQ_TR_CH_INVALID_TRE_BIT_POS)))||+(cause&BIT(IRQ_TR_CH_TRE_RD_RSP_ER_BIT_POS))||+(cause&BIT(IRQ_EV_CH_WR_RESP_BIT_POS))||+(cause&BIT(IRQ_TR_CH_DATA_RD_ER_BIT_POS))||+(cause&BIT(IRQ_TR_CH_DATA_WR_ER_BIT_POS))){+u8err_code=EVRE_STATUS_ERROR;+u8err_info=0xFF;++/* Clear out pending interrupts */+writel(cause,lldev->evca+EVCA_IRQ_CLR_OFFSET);++dev_err(lldev->dev,"error 0x%x, resetting...\n",cause);++hidma_cleanup_pending_tre(lldev,err_info,err_code);++/* reset the channel for recovery */+if(hidma_ll_setup(lldev)){+dev_err(lldev->dev,+"channel reinitialize failed after error\n");+return;+}+hidma_ll_enable_irq(lldev,ENABLE_IRQS);+return;+}++/*+*TrytoconsumeasmanyEVREsaspossible.+*skipthisloopiftheinterruptisspurious.+*/+while(cause&&repeat){+unsignedlongstart=jiffies;++/* This timeout should be sufficent for core to finish */+timeout=start+msecs_to_jiffies(500);++while(lldev->pending_tre_count){+hidma_handle_tre_completion(lldev);+if(time_is_before_jiffies(timeout)){+dev_warn(lldev->dev,+"ISR timeout %lx-%lx from %lx [%d]\n",+jiffies,timeout,start,+lldev->pending_tre_count);+break;+}+}++/* We consumed TREs or there are pending TREs or EVREs. */+writel_relaxed(cause,lldev->evca+EVCA_IRQ_CLR_OFFSET);++/*+*Anotherinterruptmighthavearrivedwhileweare+*processingthisone.Readthenewcause.+*/+status=readl_relaxed(lldev->evca+EVCA_IRQ_STAT_OFFSET);+enable=readl_relaxed(lldev->evca+EVCA_IRQ_EN_OFFSET);+cause=status&enable;++repeat--;+}+}++staticinthidma_ll_enable(structhidma_lldev*lldev)+{+u32val;+intret;++val=readl(lldev->evca+EVCA_CTRLSTS_OFFSET);+val&=~(CH_CONTROL_MASK<<16);+val|=CH_ENABLE<<16;+writel(val,lldev->evca+EVCA_CTRLSTS_OFFSET);++ret=readl_poll_timeout(lldev->evca+EVCA_CTRLSTS_OFFSET,val,+(HIDMA_CH_STATE(val)==CH_ENABLED)||+(HIDMA_CH_STATE(val)==CH_RUNNING),1000,+10000);+if(ret){+dev_err(lldev->dev,"event channel did not get enabled\n");+returnret;+}++val=readl(lldev->trca+TRCA_CTRLSTS_OFFSET);+val&=~(CH_CONTROL_MASK<<16);+val|=CH_ENABLE<<16;+writel(val,lldev->trca+TRCA_CTRLSTS_OFFSET);++ret=readl_poll_timeout(lldev->trca+TRCA_CTRLSTS_OFFSET,val,+(HIDMA_CH_STATE(val)==CH_ENABLED)||+(HIDMA_CH_STATE(val)==CH_RUNNING),1000,+10000);+if(ret){+dev_err(lldev->dev,"transfer channel did not get enabled\n");+returnret;+}++lldev->trch_state=CH_ENABLED;+lldev->evch_state=CH_ENABLED;++return0;+}++inthidma_ll_resume(structhidma_lldev*lldev)+{+returnhidma_ll_enable(lldev);+}++staticvoidhidma_ll_hw_start(structhidma_lldev*lldev)+{+unsignedlongirqflags;++spin_lock_irqsave(&lldev->lock,irqflags);+writel(lldev->tre_write_offset,lldev->trca+TRCA_DOORBELL_OFFSET);+spin_unlock_irqrestore(&lldev->lock,irqflags);+}++boolhidma_ll_isenabled(structhidma_lldev*lldev)+{+u32val;++val=readl(lldev->trca+TRCA_CTRLSTS_OFFSET);+lldev->trch_state=HIDMA_CH_STATE(val);+val=readl(lldev->evca+EVCA_CTRLSTS_OFFSET);+lldev->evch_state=HIDMA_CH_STATE(val);++/* both channels have to be enabled before calling this function */+if(((lldev->trch_state==CH_ENABLED)||+(lldev->trch_state==CH_RUNNING))&&+((lldev->evch_state==CH_ENABLED)||+(lldev->evch_state==CH_RUNNING)))+returntrue;++returnfalse;+}++voidhidma_ll_queue_request(structhidma_lldev*lldev,u32tre_ch)+{+structhidma_tre*tre;+unsignedlongflags;++tre=&lldev->trepool[tre_ch];++/* copy the TRE into its location in the TRE ring */+spin_lock_irqsave(&lldev->lock,flags);+tre->tre_index=lldev->tre_write_offset/TRE_SIZE;+lldev->pending_tre_list[tre->tre_index]=tre;+memcpy(lldev->tre_ring+lldev->tre_write_offset,&tre->tre_local[0],+TRE_SIZE);+lldev->tx_status_list[tre->idx].err_code=0;+lldev->tx_status_list[tre->idx].err_info=0;+tre->queued=1;+lldev->pending_tre_count++;+lldev->tre_write_offset=(lldev->tre_write_offset+TRE_SIZE)+%lldev->tre_ring_size;+spin_unlock_irqrestore(&lldev->lock,flags);+}++voidhidma_ll_start(structhidma_lldev*lldev)+{+hidma_ll_hw_start(lldev);+}++/*+*Notethateventhoughwestopthischannel+*ifthereisapendingtransactioninflight+*itwillcompleteandfollowthecallback.+*Thisrequestwillpreventfurtherrequests+*tobemade.+*/+inthidma_ll_pause(structhidma_lldev*lldev)+{+u32val;+intret;++val=readl(lldev->evca+EVCA_CTRLSTS_OFFSET);+lldev->evch_state=HIDMA_CH_STATE(val);+val=readl(lldev->trca+TRCA_CTRLSTS_OFFSET);+lldev->trch_state=HIDMA_CH_STATE(val);++/* already suspended by this OS */+if((lldev->trch_state==CH_SUSPENDED)||+(lldev->evch_state==CH_SUSPENDED))+return0;++/* already stopped by the manager */+if((lldev->trch_state==CH_STOPPED)||+(lldev->evch_state==CH_STOPPED))+return0;++val=readl(lldev->trca+TRCA_CTRLSTS_OFFSET);+val&=~(CH_CONTROL_MASK<<16);+val|=CH_SUSPEND<<16;+writel(val,lldev->trca+TRCA_CTRLSTS_OFFSET);++/*+*Startthewaitrightafterthesuspendisconfirmed.+*Doapolledreadupto1msand10msmaximum.+*/+ret=readl_poll_timeout(lldev->trca+TRCA_CTRLSTS_OFFSET,val,+HIDMA_CH_STATE(val)==CH_SUSPENDED,1000,+10000);+if(ret)+returnret;++val=readl(lldev->evca+EVCA_CTRLSTS_OFFSET);+val&=~(CH_CONTROL_MASK<<16);+val|=CH_SUSPEND<<16;+writel(val,lldev->evca+EVCA_CTRLSTS_OFFSET);++/*+*Startthewaitrightafterthesuspendisconfirmed+*Delayupto10msafterresettoallowDMAlogictoquiesce.+*/+ret=readl_poll_timeout(lldev->evca+EVCA_CTRLSTS_OFFSET,val,+HIDMA_CH_STATE(val)==CH_SUSPENDED,1000,+10000);+if(ret)+returnret;++lldev->trch_state=CH_SUSPENDED;+lldev->evch_state=CH_SUSPENDED;+return0;+}++voidhidma_ll_set_transfer_params(structhidma_lldev*lldev,u32tre_ch,+dma_addr_tsrc,dma_addr_tdest,u32len,+u32flags)+{+structhidma_tre*tre;+u32*tre_local;++if(tre_ch>=lldev->nr_tres){+dev_err(lldev->dev,+"invalid TRE number in transfer params:%d",tre_ch);+return;+}++tre=&lldev->trepool[tre_ch];+if(atomic_read(&tre->allocated)!=true){+dev_err(lldev->dev,+"trying to set params on an unused TRE:%d",tre_ch);+return;+}++tre_local=&tre->tre_local[0];+tre_local[TRE_LEN_IDX]=len;+tre_local[TRE_SRC_LOW_IDX]=lower_32_bits(src);+tre_local[TRE_SRC_HI_IDX]=upper_32_bits(src);+tre_local[TRE_DEST_LOW_IDX]=lower_32_bits(dest);+tre_local[TRE_DEST_HI_IDX]=upper_32_bits(dest);+tre->int_flags=flags;+}++/*+*Calledduringinitializationandafteranerrorcondition+*torestorehardwarestate.+*/+inthidma_ll_setup(structhidma_lldev*lldev)+{+intrc;+u64addr;+u32val;+u32nr_tres=lldev->nr_tres;++lldev->pending_tre_count=0;+lldev->tre_processed_off=0;+lldev->evre_processed_off=0;+lldev->tre_write_offset=0;++/* disable interrupts */+hidma_ll_enable_irq(lldev,0);++/* clear all pending interrupts */+val=readl(lldev->evca+EVCA_IRQ_STAT_OFFSET);+writel(val,lldev->evca+EVCA_IRQ_CLR_OFFSET);++rc=hidma_ll_reset(lldev);+if(rc)+returnrc;++/*+*Clearallpendinginterruptsagain.+*Otherwise,weobserveresetcompleteinterrupts.+*/+val=readl(lldev->evca+EVCA_IRQ_STAT_OFFSET);+writel(val,lldev->evca+EVCA_IRQ_CLR_OFFSET);++/* disable interrupts again after reset */+hidma_ll_enable_irq(lldev,0);++addr=lldev->tre_ring_handle;+writel(lower_32_bits(addr),lldev->trca+TRCA_RING_LOW_OFFSET);+writel(upper_32_bits(addr),lldev->trca+TRCA_RING_HIGH_OFFSET);+writel(lldev->tre_ring_size,lldev->trca+TRCA_RING_LEN_OFFSET);++addr=lldev->evre_ring_handle;+writel(lower_32_bits(addr),lldev->evca+EVCA_RING_LOW_OFFSET);+writel(upper_32_bits(addr),lldev->evca+EVCA_RING_HIGH_OFFSET);+writel(EVRE_SIZE*nr_tres,lldev->evca+EVCA_RING_LEN_OFFSET);++/* support IRQ only for now */+val=readl(lldev->evca+EVCA_INTCTRL_OFFSET);+val&=~0xF;+val|=0x1;+writel(val,lldev->evca+EVCA_INTCTRL_OFFSET);++/* clear all pending interrupts and enable them */+writel(ENABLE_IRQS,lldev->evca+EVCA_IRQ_CLR_OFFSET);+hidma_ll_enable_irq(lldev,ENABLE_IRQS);++rc=hidma_ll_enable(lldev);+if(rc)+returnrc;++returnrc;+}++structhidma_lldev*hidma_ll_init(structdevice*dev,u32nr_tres,+void__iomem*trca,void__iomem*evca,+u8chidx)+{+u32required_bytes;+structhidma_lldev*lldev;+intrc;++if(!trca||!evca||!dev||!nr_tres)+returnNULL;++/* need at least four TREs */+if(nr_tres<4)+returnNULL;++/* need an extra space */+nr_tres+=1;++lldev=devm_kzalloc(dev,sizeof(structhidma_lldev),GFP_KERNEL);+if(!lldev)+returnNULL;++lldev->evca=evca;+lldev->trca=trca;+lldev->dev=dev;+lldev->trepool=devm_kcalloc(lldev->dev,nr_tres,+sizeof(structhidma_tre),GFP_KERNEL);+if(!lldev->trepool)+returnNULL;++required_bytes=sizeof(lldev->pending_tre_list[0]);+lldev->pending_tre_list=devm_kcalloc(dev,nr_tres,required_bytes,+GFP_KERNEL);+if(!lldev->pending_tre_list)+returnNULL;++lldev->tx_status_list=devm_kcalloc(dev,nr_tres,+sizeof(lldev->tx_status_list[0]),+GFP_KERNEL);+if(!lldev->tx_status_list)+returnNULL;++lldev->tre_ring=dmam_alloc_coherent(dev,(TRE_SIZE+1)*nr_tres,+&lldev->tre_ring_handle,+GFP_KERNEL);+if(!lldev->tre_ring)+returnNULL;++memset(lldev->tre_ring,0,(TRE_SIZE+1)*nr_tres);+lldev->tre_ring_size=TRE_SIZE*nr_tres;+lldev->nr_tres=nr_tres;++/* the TRE ring has to be TRE_SIZE aligned */+if(!IS_ALIGNED(lldev->tre_ring_handle,TRE_SIZE)){+u8tre_ring_shift;++tre_ring_shift=lldev->tre_ring_handle%TRE_SIZE;+tre_ring_shift=TRE_SIZE-tre_ring_shift;+lldev->tre_ring_handle+=tre_ring_shift;+lldev->tre_ring+=tre_ring_shift;+}++lldev->evre_ring=dmam_alloc_coherent(dev,(EVRE_SIZE+1)*nr_tres,+&lldev->evre_ring_handle,+GFP_KERNEL);+if(!lldev->evre_ring)+returnNULL;++memset(lldev->evre_ring,0,(EVRE_SIZE+1)*nr_tres);+lldev->evre_ring_size=EVRE_SIZE*nr_tres;++/* the EVRE ring has to be EVRE_SIZE aligned */+if(!IS_ALIGNED(lldev->evre_ring_handle,EVRE_SIZE)){+u8evre_ring_shift;++evre_ring_shift=lldev->evre_ring_handle%EVRE_SIZE;+evre_ring_shift=EVRE_SIZE-evre_ring_shift;+lldev->evre_ring_handle+=evre_ring_shift;+lldev->evre_ring+=evre_ring_shift;+}+lldev->nr_tres=nr_tres;+lldev->chidx=chidx;++rc=kfifo_alloc(&lldev->handoff_fifo,+nr_tres*sizeof(structhidma_tre*),GFP_KERNEL);+if(rc)+returnNULL;++rc=hidma_ll_setup(lldev);+if(rc)+returnNULL;++spin_lock_init(&lldev->lock);+tasklet_init(&lldev->task,hidma_ll_tre_complete,(unsignedlong)lldev);+lldev->initialized=1;+hidma_ll_enable_irq(lldev,ENABLE_IRQS);+returnlldev;+}++inthidma_ll_uninit(structhidma_lldev*lldev)+{+intrc=0;+u32val;++if(!lldev)+return-ENODEV;++if(lldev->initialized){+u32required_bytes;++lldev->initialized=0;++required_bytes=sizeof(structhidma_tre)*lldev->nr_tres;+tasklet_kill(&lldev->task);+memset(lldev->trepool,0,required_bytes);+lldev->trepool=NULL;+lldev->pending_tre_count=0;+lldev->tre_write_offset=0;++rc=hidma_ll_reset(lldev);++/*+*Clearallpendinginterruptsagain.+*Otherwise,weobserveresetcompleteinterrupts.+*/+val=readl(lldev->evca+EVCA_IRQ_STAT_OFFSET);+writel(val,lldev->evca+EVCA_IRQ_CLR_OFFSET);+hidma_ll_enable_irq(lldev,0);+}+returnrc;+}++irqreturn_thidma_ll_inthandler(intchirq,void*arg)+{+structhidma_lldev*lldev=arg;++hidma_ll_int_handler_internal(lldev);+returnIRQ_HANDLED;+}++enumdma_statushidma_ll_status(structhidma_lldev*lldev,u32tre_ch)+{+enumdma_statusret=DMA_ERROR;+unsignedlongflags;+u8err_code;++spin_lock_irqsave(&lldev->lock,flags);+err_code=lldev->tx_status_list[tre_ch].err_code;++if(err_code&EVRE_STATUS_COMPLETE)+ret=DMA_COMPLETE;+elseif(err_code&EVRE_STATUS_ERROR)+ret=DMA_ERROR;+else+ret=DMA_IN_PROGRESS;+spin_unlock_irqrestore(&lldev->lock,flags);++returnret;+}
--
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
From: Sinan Kaya <hidden> Date: 2016-01-11 14:46:38
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 at 0x5A000000 {
compatible = "qcom,hidma-mgmt-1.0";
...
hidma_10: hidma at 0x5a010000 {
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 <redacted>
---
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
@@ -0,0 +1,9 @@+What: /sys/devices/platform/hidma-*/chid+ /sys/devices/platform/QCOM8061:*/chid+Date: Dec 2015+KernelVersion: 4.4+Contact: "Sinan Kaya <okaya@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.
@@ -298,5 +299,102 @@ static struct platform_driver hidma_mgmt_driver = {},};-module_platform_driver(hidma_mgmt_driver);+#if defined(CONFIG_OF) && defined(CONFIG_OF_IRQ)+staticintobject_counter;++staticint__inithidma_mgmt_of_populate_channels(structdevice_node*np)+{+structplatform_device*pdev_parent=of_find_device_by_node(np);+structplatform_device_infopdevinfo;+structof_phandle_argsout_irq;+structdevice_node*child;+structresource*res;+const__be32*cell;+intret=0,size,i,num;+u64addr,addr_size;++for_each_available_child_of_node(np,child){+structresource*res_iter;++cell=of_get_property(child,"reg",&size);+if(!cell){+ret=-EINVAL;+gotoout;+}++size/=sizeof(*cell);+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;+gotoout;+}++/* read each reg value */+i=0;+res_iter=res;+while(i<size){+addr=of_read_number(&cell[i],+of_n_addr_cells(child));+i+=of_n_addr_cells(child);++addr_size=of_read_number(&cell[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_iter++;+}++ret=of_irq_parse_one(child,0,&out_irq);+if(ret)+gotoout;++res_iter->start=irq_create_of_mapping(&out_irq);+res_iter->name="hidma event irq";+res_iter->flags=IORESOURCE_IRQ;++pdevinfo.fwnode=&child->fwnode;+pdevinfo.parent=pdev_parent?&pdev_parent->dev:NULL;+pdevinfo.name=child->name;+pdevinfo.id=object_counter++;+pdevinfo.res=res;+pdevinfo.num_res=num;+pdevinfo.data=NULL;+pdevinfo.size_data=0;+pdevinfo.dma_mask=DMA_BIT_MASK(64);+platform_device_register_full(&pdevinfo);++kfree(res);+res=NULL;+}+out:+kfree(res);++returnret;+}+#endif++staticint__inithidma_mgmt_init(void)+{+#if defined(CONFIG_OF) && defined(CONFIG_OF_IRQ)+structdevice_node*child;++for(child=of_find_matching_node(NULL,hidma_mgmt_match);child;+child=of_find_matching_node(child,hidma_mgmt_match)){+/* device tree based firmware here */+hidma_mgmt_of_populate_channels(child);+of_node_put(child);+}+#endif+platform_driver_register(&hidma_mgmt_driver);++return0;+}+module_init(hidma_mgmt_init);MODULE_LICENSE("GPL v2");
--
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
From: Sinan Kaya <hidden> Date: 2016-01-11 14:46:57
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 <redacted>
---
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
@@ -0,0 +1,219 @@+/*+*QualcommTechnologiesHIDMAdebugfile+*+*Copyright(c)2015,TheLinuxFoundation.Allrightsreserved.+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodify+*itunderthetermsoftheGNUGeneralPublicLicenseversion2and+*onlyversion2aspublishedbytheFreeSoftwareFoundation.+*+*Thisprogramisdistributedinthehopethatitwillbeuseful,+*butWITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+*MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.Seethe+*GNUGeneralPublicLicenseformoredetails.+*/++#include<linux/debugfs.h>+#include<linux/device.h>+#include<linux/list.h>+#include<linux/pm_runtime.h>++#include"hidma.h"++staticvoidhidma_ll_chstats(structseq_file*s,void*llhndl,u32tre_ch)+{+structhidma_lldev*lldev=llhndl;+structhidma_tre*tre;+u32length;+dma_addr_tsrc_start;+dma_addr_tdest_start;+u32*tre_local;++if(tre_ch>=lldev->nr_tres){+dev_err(lldev->dev,"invalid TRE number in chstats:%d",tre_ch);+return;+}+tre=&lldev->trepool[tre_ch];+seq_printf(s,"------Channel %d -----\n",tre_ch);+seq_printf(s,"allocated=%d\n",atomic_read(&tre->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 = 0x%x\n",tre->tre_index);++tre_local=&tre->tre_local[0];+src_start=tre_local[TRE_SRC_LOW_IDX];+src_start=((u64)(tre_local[TRE_SRC_HI_IDX])<<32)+src_start;+dest_start=tre_local[TRE_DEST_LOW_IDX];+dest_start+=((u64)(tre_local[TRE_DEST_HI_IDX])<<32);+length=tre_local[TRE_LEN_IDX];++seq_printf(s,"src=%pap\n",&src_start);+seq_printf(s,"dest=%pap\n",&dest_start);+seq_printf(s,"length = 0x%x\n",length);+}++staticvoidhidma_ll_devstats(structseq_file*s,void*llhndl)+{+structhidma_lldev*lldev=llhndl;++seq_puts(s,"------Device -----\n");+seq_printf(s,"lldev init = 0x%x\n",lldev->initialized);+seq_printf(s,"trch_state = 0x%x\n",lldev->trch_state);+seq_printf(s,"evch_state = 0x%x\n",lldev->evch_state);+seq_printf(s,"chidx = 0x%x\n",lldev->chidx);+seq_printf(s,"nr_tres = 0x%x\n",lldev->nr_tres);+seq_printf(s,"trca=%p\n",lldev->trca);+seq_printf(s,"tre_ring=%p\n",lldev->tre_ring);+seq_printf(s,"tre_ring_handle=%pap\n",&lldev->tre_ring_handle);+seq_printf(s,"tre_ring_size = 0x%x\n",lldev->tre_ring_size);+seq_printf(s,"tre_processed_off = 0x%x\n",lldev->tre_processed_off);+seq_printf(s,"pending_tre_count=%d\n",lldev->pending_tre_count);+seq_printf(s,"evca=%p\n",lldev->evca);+seq_printf(s,"evre_ring=%p\n",lldev->evre_ring);+seq_printf(s,"evre_ring_handle=%pap\n",&lldev->evre_ring_handle);+seq_printf(s,"evre_ring_size = 0x%x\n",lldev->evre_ring_size);+seq_printf(s,"evre_processed_off = 0x%x\n",lldev->evre_processed_off);+seq_printf(s,"tre_write_offset = 0x%x\n",lldev->tre_write_offset);+}++/*+*hidma_chan_stats:displayHIDMAchannelstatistics+*+*DisplaythestatisticsforthecurrentHIDMAvirtualchanneldevice.+*/+staticinthidma_chan_stats(structseq_file*s,void*unused)+{+structhidma_chan*mchan=s->private;+structhidma_desc*mdesc;+structhidma_dev*dmadev=mchan->dmadev;++pm_runtime_get_sync(dmadev->ddev.dev);+seq_printf(s,"paused=%u\n",mchan->paused);+seq_printf(s,"dma_sig=%u\n",mchan->dma_sig);+seq_puts(s,"prepared\n");+list_for_each_entry(mdesc,&mchan->prepared,node)+hidma_ll_chstats(s,mchan->dmadev->lldev,mdesc->tre_ch);++seq_puts(s,"active\n");+list_for_each_entry(mdesc,&mchan->active,node)+hidma_ll_chstats(s,mchan->dmadev->lldev,mdesc->tre_ch);++seq_puts(s,"completed\n");+list_for_each_entry(mdesc,&mchan->completed,node)+hidma_ll_chstats(s,mchan->dmadev->lldev,mdesc->tre_ch);++hidma_ll_devstats(s,mchan->dmadev->lldev);+pm_runtime_mark_last_busy(dmadev->ddev.dev);+pm_runtime_put_autosuspend(dmadev->ddev.dev);+return0;+}++/*+*hidma_dma_info:displayHIDMAdeviceinfo+*+*DisplaytheinfoforthecurrentHIDMAdevice.+*/+staticinthidma_dma_info(structseq_file*s,void*unused)+{+structhidma_dev*dmadev=s->private;+resource_size_tsz;++seq_printf(s,"nr_descriptors=%d\n",dmadev->nr_descriptors);+seq_printf(s,"dev_trca=%p\n",&dmadev->dev_trca);+seq_printf(s,"dev_trca_phys=%pa\n",&dmadev->trca_resource->start);+sz=resource_size(dmadev->trca_resource);+seq_printf(s,"dev_trca_size=%pa\n",&sz);+seq_printf(s,"dev_evca=%p\n",&dmadev->dev_evca);+seq_printf(s,"dev_evca_phys=%pa\n",&dmadev->evca_resource->start);+sz=resource_size(dmadev->evca_resource);+seq_printf(s,"dev_evca_size=%pa\n",&sz);+return0;+}++staticinthidma_chan_stats_open(structinode*inode,structfile*file)+{+returnsingle_open(file,hidma_chan_stats,inode->i_private);+}++staticinthidma_dma_info_open(structinode*inode,structfile*file)+{+returnsingle_open(file,hidma_dma_info,inode->i_private);+}++staticconststructfile_operationshidma_chan_fops={+.open=hidma_chan_stats_open,+.read=seq_read,+.llseek=seq_lseek,+.release=single_release,+};++staticconststructfile_operationshidma_dma_fops={+.open=hidma_dma_info_open,+.read=seq_read,+.llseek=seq_lseek,+.release=single_release,+};++voidhidma_debug_uninit(structhidma_dev*dmadev)+{+debugfs_remove_recursive(dmadev->debugfs);+debugfs_remove_recursive(dmadev->stats);+}++inthidma_debug_init(structhidma_dev*dmadev)+{+intrc=0;+intchidx=0;+structlist_head*position=NULL;++dmadev->debugfs=debugfs_create_dir(dev_name(dmadev->ddev.dev),NULL);+if(!dmadev->debugfs){+rc=-ENODEV;+returnrc;+}++/* walk through the virtual channel list */+list_for_each(position,&dmadev->ddev.channels){+structhidma_chan*chan;++chan=list_entry(position,structhidma_chan,+chan.device_node);+sprintf(chan->dbg_name,"chan%d",chidx);+chan->debugfs=debugfs_create_dir(chan->dbg_name,+dmadev->debugfs);+if(!chan->debugfs){+rc=-ENOMEM;+gotocleanup;+}+chan->stats=debugfs_create_file("stats",S_IRUGO,+chan->debugfs,chan,+&hidma_chan_fops);+if(!chan->stats){+rc=-ENOMEM;+gotocleanup;+}+chidx++;+}++dmadev->stats=debugfs_create_file("stats",S_IRUGO,+dmadev->debugfs,dmadev,+&hidma_dma_fops);+if(!dmadev->stats){+rc=-ENOMEM;+gotocleanup;+}++return0;+cleanup:+hidma_debug_uninit(dmadev);+returnrc;+}
--
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
From: Sinan Kaya <hidden> Date: 2016-01-11 14:47:28
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 <redacted>
Reviewed-by: Andy Shevchenko <redacted>
---
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
@@ -0,0 +1,744 @@+/*+*QualcommTechnologiesHIDMADMAengineinterface+*+*Copyright(c)2015,TheLinuxFoundation.Allrightsreserved.+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodify+*itunderthetermsoftheGNUGeneralPublicLicenseversion2and+*onlyversion2aspublishedbytheFreeSoftwareFoundation.+*+*Thisprogramisdistributedinthehopethatitwillbeuseful,+*butWITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+*MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.Seethe+*GNUGeneralPublicLicenseformoredetails.+*/++/*+*Copyright(C)FreescaleSemicondutor,Inc.2007,2008.+*Copyright(C)Semihalf2009+*Copyright(C)IlyaYanok,EmcraftSystems2010+*Copyright(C)AlexanderPopov,Promcontroller2014+*+*WrittenbyPiotrZiecik<kosmo@semihalf.com>.Hardwaredescription+*(defines,structuresandcomments)wastakenfromMPC5121DMAdriver+*writtenbyHongjunChen<hong-jun.chen@freescale.com>.+*+*ApprovedasOSADLprojectbyamajorityofOSADLmembersandfunded+*byOSADLmembershipfeesin2009;fordetailsseewww.osadl.org.+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodifyit+*underthetermsoftheGNUGeneralPublicLicenseaspublishedbytheFree+*SoftwareFoundation;eitherversion2oftheLicense,or(atyouroption)+*anylaterversion.+*+*Thisprogramisdistributedinthehopethatitwillbeuseful,butWITHOUT+*ANYWARRANTY;withouteventheimpliedwarrantyofMERCHANTABILITYor+*FITNESSFORAPARTICULARPURPOSE.SeetheGNUGeneralPublicLicensefor+*moredetails.+*+*ThefullGNUGeneralPublicLicenseisincludedinthisdistributioninthe+*filecalledCOPYING.+*/++/* Linux Foundation elects GPLv2 license only. */++#include<linux/dmaengine.h>+#include<linux/dma-mapping.h>+#include<linux/list.h>+#include<linux/module.h>+#include<linux/platform_device.h>+#include<linux/slab.h>+#include<linux/spinlock.h>+#include<linux/of_dma.h>+#include<linux/property.h>+#include<linux/delay.h>+#include<linux/acpi.h>+#include<linux/irq.h>+#include<linux/atomic.h>+#include<linux/pm_runtime.h>++#include"../dmaengine.h"+#include"hidma.h"++/*+*Defaultidletimeis2seconds.Thisparametercan+*beoverriddenbychangingthefollowing+*/sys/bus/platform/devices/QCOM8061:<xy>/power/autosuspend_delay_ms+*duringkernelboot.+*/+#define HIDMA_AUTOSUSPEND_TIMEOUT 2000+#define HIDMA_ERR_INFO_SW 0xFF+#define HIDMA_ERR_CODE_UNEXPECTED_TERMINATE 0x0++staticinlinestructhidma_dev*to_hidma_dev(structdma_device*dmadev)+{+returncontainer_of(dmadev,structhidma_dev,ddev);+}++staticinline+structhidma_dev*to_hidma_dev_from_lldev(structhidma_lldev**_lldevp)+{+returncontainer_of(_lldevp,structhidma_dev,lldev);+}++staticinlinestructhidma_chan*to_hidma_chan(structdma_chan*dmach)+{+returncontainer_of(dmach,structhidma_chan,chan);+}++staticinline+structhidma_desc*to_hidma_desc(structdma_async_tx_descriptor*t)+{+returncontainer_of(t,structhidma_desc,desc);+}++staticvoidhidma_free(structhidma_dev*dmadev)+{+INIT_LIST_HEAD(&dmadev->ddev.channels);+}++staticunsignedintnr_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+staticintchannel_idx[HIDMA_MAX_CHANNELS]={+[0...(HIDMA_MAX_CHANNELS-1)]=-1+};++/*+*EachDMAchannelisassociatedwithaneventchannelforinterrupt+*delivery.Theeventchannelindexusuallycomesfromthefirmwarethrough+*ACPI/DT.WhenaHIDMAchannelisexecutedintheguestmachinecontext(QEMU)+*thedevicetreegetsauto-generatedbasedonthememoryandIRQresources+*thisdriverusesonthehostmachine.Anydevicespecificparaemetersuchas+*channel-indexgetsignoredbytheQEMU.+*Weareusingthiscommandlineparametertopasstheeventchannelindexto+*theguestmachine.+*/+staticunsignedintnum_channel_idx;+module_param_array_named(channel_idx,channel_idx,int,&num_channel_idx,+0644);+MODULE_PARM_DESC(channel_idx,"channel index array for the notifications");+staticatomic_tchannel_ref_count;++/* process completed descriptors */+staticvoidhidma_process_completed(structhidma_chan*mchan)+{+structdma_device*ddev=mchan->chan.device;+structhidma_dev*mdma=to_hidma_dev(ddev);+structdma_async_tx_descriptor*desc;+dma_cookie_tlast_cookie;+structhidma_desc*mdesc;+unsignedlongirqflags;+structlist_headlist;++INIT_LIST_HEAD(&list);++/* Get all completed descriptors */+spin_lock_irqsave(&mchan->lock,irqflags);+list_splice_tail_init(&mchan->completed,&list);+spin_unlock_irqrestore(&mchan->lock,irqflags);++/* Execute callbacks and run dependencies */+list_for_each_entry(mdesc,&list,node){+enumdma_statusllstat;++desc=&mdesc->desc;++spin_lock_irqsave(&mchan->lock,irqflags);+dma_cookie_complete(desc);+spin_unlock_irqrestore(&mchan->lock,irqflags);++llstat=hidma_ll_status(mdma->lldev,mdesc->tre_ch);+if(desc->callback&&(llstat==DMA_COMPLETE))+desc->callback(desc->callback_param);++last_cookie=desc->cookie;+dma_run_dependencies(desc);+}++/* Free descriptors */+spin_lock_irqsave(&mchan->lock,irqflags);+list_splice_tail_init(&list,&mchan->free);+spin_unlock_irqrestore(&mchan->lock,irqflags);++}++/*+*Calledonceforeachsubmitteddescriptor.+*PMislockedonceforeachdescriptorthatiscurrently+*inexecution.+*/+staticvoidhidma_callback(void*data)+{+structhidma_desc*mdesc=data;+structhidma_chan*mchan=to_hidma_chan(mdesc->desc.chan);+structdma_device*ddev=mchan->chan.device;+structhidma_dev*dmadev=to_hidma_dev(ddev);+unsignedlongirqflags;+boolqueued=false;++spin_lock_irqsave(&mchan->lock,irqflags);+if(mdesc->node.next){+/* Delete from the active list, add to completed list */+list_move_tail(&mdesc->node,&mchan->completed);+queued=true;++/* calculate the next running descriptor */+mchan->running=list_first_entry(&mchan->active,+structhidma_desc,node);+}+spin_unlock_irqrestore(&mchan->lock,irqflags);++hidma_process_completed(mchan);++if(queued){+pm_runtime_mark_last_busy(dmadev->ddev.dev);+pm_runtime_put_autosuspend(dmadev->ddev.dev);+}+}++staticinthidma_chan_init(structhidma_dev*dmadev,u32dma_sig)+{+structhidma_chan*mchan;+structdma_device*ddev;++mchan=devm_kzalloc(dmadev->ddev.dev,sizeof(*mchan),GFP_KERNEL);+if(!mchan)+return-ENOMEM;++ddev=&dmadev->ddev;+mchan->dma_sig=dma_sig;+mchan->dmadev=dmadev;+mchan->chan.device=ddev;+dma_cookie_init(&mchan->chan);++INIT_LIST_HEAD(&mchan->free);+INIT_LIST_HEAD(&mchan->prepared);+INIT_LIST_HEAD(&mchan->active);+INIT_LIST_HEAD(&mchan->completed);++spin_lock_init(&mchan->lock);+list_add_tail(&mchan->chan.device_node,&ddev->channels);+dmadev->ddev.chancnt++;+return0;+}++staticvoidhidma_issue_task(unsignedlongarg)+{+structhidma_dev*dmadev=(structhidma_dev*)arg;++pm_runtime_get_sync(dmadev->ddev.dev);+hidma_ll_start(dmadev->lldev);+}++staticvoidhidma_issue_pending(structdma_chan*dmach)+{+structhidma_chan*mchan=to_hidma_chan(dmach);+structhidma_dev*dmadev=mchan->dmadev;+unsignedlongflags;+intstatus;++spin_lock_irqsave(&mchan->lock,flags);+if(!mchan->running){+structhidma_desc*desc=list_first_entry(&mchan->active,+structhidma_desc,+node);+mchan->running=desc;+}+spin_unlock_irqrestore(&mchan->lock,flags);++/* PM will be released in hidma_callback function. */+status=pm_runtime_get(dmadev->ddev.dev);+if(status<0)+tasklet_schedule(&dmadev->task);+else+hidma_ll_start(dmadev->lldev);+}++staticenumdma_statushidma_tx_status(structdma_chan*dmach,+dma_cookie_tcookie,+structdma_tx_state*txstate)+{+structhidma_chan*mchan=to_hidma_chan(dmach);+enumdma_statusret;++ret=dma_cookie_status(dmach,cookie,txstate);+if(ret==DMA_COMPLETE)+returnret;++if(mchan->paused&&(ret==DMA_IN_PROGRESS)){+unsignedlongflags;+dma_cookie_truncookie;++spin_lock_irqsave(&mchan->lock,flags);+if(mchan->running)+runcookie=mchan->running->desc.cookie;+else+runcookie=-EINVAL;++if(runcookie==cookie)+ret=DMA_PAUSED;++spin_unlock_irqrestore(&mchan->lock,flags);+}++returnret;+}++/*+*Submitdescriptortohardware.+*LockthePMforeachdescriptorwearesending.+*/+staticdma_cookie_thidma_tx_submit(structdma_async_tx_descriptor*txd)+{+structhidma_chan*mchan=to_hidma_chan(txd->chan);+structhidma_dev*dmadev=mchan->dmadev;+structhidma_desc*mdesc;+unsignedlongirqflags;+dma_cookie_tcookie;++pm_runtime_get_sync(dmadev->ddev.dev);+if(!hidma_ll_isenabled(dmadev->lldev)){+pm_runtime_mark_last_busy(dmadev->ddev.dev);+pm_runtime_put_autosuspend(dmadev->ddev.dev);+return-ENODEV;+}++mdesc=container_of(txd,structhidma_desc,desc);+spin_lock_irqsave(&mchan->lock,irqflags);++/* Move descriptor to active */+list_move_tail(&mdesc->node,&mchan->active);++/* Update cookie */+cookie=dma_cookie_assign(txd);++hidma_ll_queue_request(dmadev->lldev,mdesc->tre_ch);+spin_unlock_irqrestore(&mchan->lock,irqflags);++returncookie;+}++staticinthidma_alloc_chan_resources(structdma_chan*dmach)+{+structhidma_chan*mchan=to_hidma_chan(dmach);+structhidma_dev*dmadev=mchan->dmadev;+structhidma_desc*mdesc,*tmp;+unsignedlongirqflags;+LIST_HEAD(descs);+unsignedinti;+intrc=0;++if(mchan->allocated)+return0;++/* Alloc descriptors for this channel */+for(i=0;i<dmadev->nr_descriptors;i++){+mdesc=kzalloc(sizeof(structhidma_desc),GFP_NOWAIT);+if(!mdesc){+rc=-ENOMEM;+break;+}+dma_async_tx_descriptor_init(&mdesc->desc,dmach);+mdesc->desc.tx_submit=hidma_tx_submit;++rc=hidma_ll_request(dmadev->lldev,mchan->dma_sig,+"DMA engine",hidma_callback,mdesc,+&mdesc->tre_ch);+if(rc){+dev_err(dmach->device->dev,+"channel alloc failed at %u\n",i);+kfree(mdesc);+break;+}+list_add_tail(&mdesc->node,&descs);+}++if(rc){+/* return the allocated descriptors */+list_for_each_entry_safe(mdesc,tmp,&descs,node){+hidma_ll_free(dmadev->lldev,mdesc->tre_ch);+kfree(mdesc);+}+returnrc;+}++spin_lock_irqsave(&mchan->lock,irqflags);+list_splice_tail_init(&descs,&mchan->free);+mchan->allocated=true;+spin_unlock_irqrestore(&mchan->lock,irqflags);+return1;+}++staticstructdma_async_tx_descriptor*+hidma_prep_dma_memcpy(structdma_chan*dmach,dma_addr_tdest,dma_addr_tsrc,+size_tlen,unsignedlongflags)+{+structhidma_chan*mchan=to_hidma_chan(dmach);+structhidma_desc*mdesc=NULL;+structhidma_dev*mdma=mchan->dmadev;+unsignedlongirqflags;++/* Get free descriptor */+spin_lock_irqsave(&mchan->lock,irqflags);+if(!list_empty(&mchan->free)){+mdesc=list_first_entry(&mchan->free,structhidma_desc,node);+list_del(&mdesc->node);+}+spin_unlock_irqrestore(&mchan->lock,irqflags);++if(!mdesc)+returnNULL;++hidma_ll_set_transfer_params(mdma->lldev,mdesc->tre_ch,+src,dest,len,flags);++/* Place descriptor in prepared list */+spin_lock_irqsave(&mchan->lock,irqflags);+list_add_tail(&mdesc->node,&mchan->prepared);+spin_unlock_irqrestore(&mchan->lock,irqflags);++return&mdesc->desc;+}++staticinthidma_terminate_channel(structdma_chan*chan)+{+structhidma_chan*mchan=to_hidma_chan(chan);+structhidma_dev*dmadev=to_hidma_dev(mchan->chan.device);+structhidma_desc*tmp,*mdesc;+unsignedlongirqflags;+LIST_HEAD(list);+intrc;++pm_runtime_get_sync(dmadev->ddev.dev);+/* give completed requests a chance to finish */+hidma_process_completed(mchan);++spin_lock_irqsave(&mchan->lock,irqflags);+list_splice_init(&mchan->active,&list);+list_splice_init(&mchan->prepared,&list);+list_splice_init(&mchan->completed,&list);+spin_unlock_irqrestore(&mchan->lock,irqflags);++/* this suspends the existing transfer */+rc=hidma_ll_pause(dmadev->lldev);+if(rc){+dev_err(dmadev->ddev.dev,"channel did not pause\n");+gotoout;+}++/* return all user requests */+list_for_each_entry_safe(mdesc,tmp,&list,node){+structdma_async_tx_descriptor*txd=&mdesc->desc;+dma_async_tx_callbackcallback=mdesc->desc.callback;+void*param=mdesc->desc.callback_param;++dma_descriptor_unmap(txd);++if(callback)+callback(param);++dma_run_dependencies(txd);++/* move myself to free_list */+list_move(&mdesc->node,&mchan->free);+}++rc=hidma_ll_resume(dmadev->lldev);+out:+pm_runtime_mark_last_busy(dmadev->ddev.dev);+pm_runtime_put_autosuspend(dmadev->ddev.dev);+returnrc;+}++staticinthidma_terminate_all(structdma_chan*chan)+{+structhidma_chan*mchan=to_hidma_chan(chan);+structhidma_dev*dmadev=to_hidma_dev(mchan->chan.device);+intrc;++rc=hidma_terminate_channel(chan);+if(rc)+returnrc;++/* reinitialize the hardware */+pm_runtime_get_sync(dmadev->ddev.dev);+rc=hidma_ll_setup(dmadev->lldev);+pm_runtime_mark_last_busy(dmadev->ddev.dev);+pm_runtime_put_autosuspend(dmadev->ddev.dev);+returnrc;+}++staticvoidhidma_free_chan_resources(structdma_chan*dmach)+{+structhidma_chan*mchan=to_hidma_chan(dmach);+structhidma_dev*mdma=mchan->dmadev;+structhidma_desc*mdesc,*tmp;+unsignedlongirqflags;+LIST_HEAD(descs);++/* terminate running transactions and free descriptors */+hidma_terminate_channel(dmach);++spin_lock_irqsave(&mchan->lock,irqflags);++/* Move data */+list_splice_tail_init(&mchan->free,&descs);++/* Free descriptors */+list_for_each_entry_safe(mdesc,tmp,&descs,node){+hidma_ll_free(mdma->lldev,mdesc->tre_ch);+list_del(&mdesc->node);+kfree(mdesc);+}++mchan->allocated=0;+spin_unlock_irqrestore(&mchan->lock,irqflags);+}++staticinthidma_pause(structdma_chan*chan)+{+structhidma_chan*mchan;+structhidma_dev*dmadev;++mchan=to_hidma_chan(chan);+dmadev=to_hidma_dev(mchan->chan.device);+if(!mchan->paused){+pm_runtime_get_sync(dmadev->ddev.dev);+if(hidma_ll_pause(dmadev->lldev))+dev_warn(dmadev->ddev.dev,"channel did not stop\n");+mchan->paused=true;+pm_runtime_mark_last_busy(dmadev->ddev.dev);+pm_runtime_put_autosuspend(dmadev->ddev.dev);+}+return0;+}++staticinthidma_resume(structdma_chan*chan)+{+structhidma_chan*mchan;+structhidma_dev*dmadev;+intrc=0;++mchan=to_hidma_chan(chan);+dmadev=to_hidma_dev(mchan->chan.device);+if(mchan->paused){+pm_runtime_get_sync(dmadev->ddev.dev);+rc=hidma_ll_resume(dmadev->lldev);+if(!rc)+mchan->paused=false;+else+dev_err(dmadev->ddev.dev,+"failed to resume the channel");+pm_runtime_mark_last_busy(dmadev->ddev.dev);+pm_runtime_put_autosuspend(dmadev->ddev.dev);+}+returnrc;+}++staticirqreturn_thidma_chirq_handler(intchirq,void*arg)+{+structhidma_lldev*lldev=arg;++/*+*Allinterruptsarerequestdriven.+*HWdoesn'tsendaninterruptbyitself.+*/+returnhidma_ll_inthandler(chirq,lldev);+}++staticinthidma_probe(structplatform_device*pdev)+{+structhidma_dev*dmadev;+structresource*trca_resource;+structresource*evca_resource;+intchirq;+intcurrent_channel_index=atomic_read(&channel_ref_count);+void__iomem*evca;+void__iomem*trca;+intrc;++pm_runtime_set_autosuspend_delay(&pdev->dev,HIDMA_AUTOSUSPEND_TIMEOUT);+pm_runtime_use_autosuspend(&pdev->dev);+pm_runtime_set_active(&pdev->dev);+pm_runtime_enable(&pdev->dev);++trca_resource=platform_get_resource(pdev,IORESOURCE_MEM,0);+trca=devm_ioremap_resource(&pdev->dev,trca_resource);+if(IS_ERR(trca)){+rc=-ENOMEM;+gotobailout;+}++evca_resource=platform_get_resource(pdev,IORESOURCE_MEM,1);+evca=devm_ioremap_resource(&pdev->dev,evca_resource);+if(IS_ERR(evca)){+rc=-ENOMEM;+gotobailout;+}++/*+*ThisdriveronlyhandlesthechannelIRQs.+*CommonIRQishandledbythemanagementdriver.+*/+chirq=platform_get_irq(pdev,0);+if(chirq<0){+rc=-ENODEV;+gotobailout;+}++dmadev=devm_kzalloc(&pdev->dev,sizeof(*dmadev),GFP_KERNEL);+if(!dmadev){+rc=-ENOMEM;+gotobailout;+}++INIT_LIST_HEAD(&dmadev->ddev.channels);+spin_lock_init(&dmadev->lock);+dmadev->ddev.dev=&pdev->dev;+pm_runtime_get_sync(dmadev->ddev.dev);++dma_cap_set(DMA_MEMCPY,dmadev->ddev.cap_mask);+if(WARN_ON(!pdev->dev.dma_mask)){+rc=-ENXIO;+gotodmafree;+}++dmadev->dev_evca=evca;+dmadev->evca_resource=evca_resource;+dmadev->dev_trca=trca;+dmadev->trca_resource=trca_resource;+dmadev->ddev.device_prep_dma_memcpy=hidma_prep_dma_memcpy;+dmadev->ddev.device_alloc_chan_resources=hidma_alloc_chan_resources;+dmadev->ddev.device_free_chan_resources=hidma_free_chan_resources;+dmadev->ddev.device_tx_status=hidma_tx_status;+dmadev->ddev.device_issue_pending=hidma_issue_pending;+dmadev->ddev.device_pause=hidma_pause;+dmadev->ddev.device_resume=hidma_resume;+dmadev->ddev.device_terminate_all=hidma_terminate_all;+dmadev->ddev.copy_align=8;++device_property_read_u32(&pdev->dev,"desc-count",+&dmadev->nr_descriptors);++if(!dmadev->nr_descriptors&&nr_desc_prm)+dmadev->nr_descriptors=nr_desc_prm;++if(!dmadev->nr_descriptors){+rc=-EINVAL;+gotodmafree;+}++if(current_channel_index>HIDMA_MAX_CHANNELS){+rc=-EINVAL;+gotodmafree;+}++dmadev->chidx=-1;+device_property_read_u32(&pdev->dev,"channel-index",&dmadev->chidx);++/* kernel command line override for the guest machine */+if(channel_idx[current_channel_index]!=-1)+dmadev->chidx=channel_idx[current_channel_index];++if(dmadev->chidx==-1){+rc=-EINVAL;+gotodmafree;+}++/* Set DMA mask to 64 bits. */+rc=dma_set_mask_and_coherent(&pdev->dev,DMA_BIT_MASK(64));+if(rc){+dev_warn(&pdev->dev,"unable to set coherent mask to 64");+rc=dma_set_mask_and_coherent(&pdev->dev,DMA_BIT_MASK(32));+if(rc)+gotodmafree;+}++dmadev->lldev=hidma_ll_init(dmadev->ddev.dev,+dmadev->nr_descriptors,dmadev->dev_trca,+dmadev->dev_evca,dmadev->chidx);+if(!dmadev->lldev){+rc=-EPROBE_DEFER;+gotodmafree;+}++rc=devm_request_irq(&pdev->dev,chirq,hidma_chirq_handler,0,+"qcom-hidma",dmadev->lldev);+if(rc)+gotouninit;++INIT_LIST_HEAD(&dmadev->ddev.channels);+rc=hidma_chan_init(dmadev,0);+if(rc)+gotouninit;++rc=dma_async_device_register(&dmadev->ddev);+if(rc)+gotouninit;++dmadev->irq=chirq;+tasklet_init(&dmadev->task,hidma_issue_task,(unsignedlong)dmadev);+dev_info(&pdev->dev,"HI-DMA engine driver registration complete\n");+platform_set_drvdata(pdev,dmadev);+pm_runtime_mark_last_busy(dmadev->ddev.dev);+pm_runtime_put_autosuspend(dmadev->ddev.dev);+atomic_inc(&channel_ref_count);+return0;++uninit:+hidma_ll_uninit(dmadev->lldev);+dmafree:+if(dmadev)+hidma_free(dmadev);+bailout:+pm_runtime_put_sync(&pdev->dev);+pm_runtime_disable(&pdev->dev);+returnrc;+}++staticinthidma_remove(structplatform_device*pdev)+{+structhidma_dev*dmadev=platform_get_drvdata(pdev);++pm_runtime_get_sync(dmadev->ddev.dev);+dma_async_device_unregister(&dmadev->ddev);+devm_free_irq(dmadev->ddev.dev,dmadev->irq,dmadev->lldev);+hidma_ll_uninit(dmadev->lldev);+hidma_free(dmadev);++dev_info(&pdev->dev,"HI-DMA engine removed\n");+pm_runtime_put_sync_suspend(&pdev->dev);+pm_runtime_disable(&pdev->dev);++return0;+}++#if IS_ENABLED(CONFIG_ACPI)+staticconststructacpi_device_idhidma_acpi_ids[]={+{"QCOM8061"},+{},+};+#endif++staticconststructof_device_idhidma_match[]={+{.compatible="qcom,hidma-1.0",},+{},+};++MODULE_DEVICE_TABLE(of,hidma_match);++staticstructplatform_driverhidma_driver={+.probe=hidma_probe,+.remove=hidma_remove,+.driver={+.name="hidma",+.of_match_table=hidma_match,+.acpi_match_table=ACPI_PTR(hidma_acpi_ids),+},+};++module_platform_driver(hidma_driver);+MODULE_LICENSE("GPL v2");
@@ -0,0 +1,160 @@+/*+*QualcommTechnologiesHIDMAdatastructures+*+*Copyright(c)2014,TheLinuxFoundation.Allrightsreserved.+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodify+*itunderthetermsoftheGNUGeneralPublicLicenseversion2and+*onlyversion2aspublishedbytheFreeSoftwareFoundation.+*+*Thisprogramisdistributedinthehopethatitwillbeuseful,+*butWITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+*MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.Seethe+*GNUGeneralPublicLicenseformoredetails.+*/++#ifndef QCOM_HIDMA_H+#define QCOM_HIDMA_H++#include<linux/kfifo.h>+#include<linux/interrupt.h>+#include<linux/dmaengine.h>++#define TRE_SIZE 32 /* each TRE is 32 bytes */+#define TRE_CFG_IDX 0+#define TRE_LEN_IDX 1+#define TRE_SRC_LOW_IDX 2+#define TRE_SRC_HI_IDX 3+#define TRE_DEST_LOW_IDX 4+#define TRE_DEST_HI_IDX 5++structhidma_tx_status{+u8err_info;/* error record in this transfer */+u8err_code;/* completion code */+};++structhidma_tre{+atomic_tallocated;/* if this channel is allocated */+boolqueued;/* flag whether this is pending */+u16status;/* status */+u32chidx;/* index of the tre */+u32dma_sig;/* signature of the tre */+constchar*dev_name;/* name of the device */+void(*callback)(void*data);/* requester callback */+void*data;/* Data associated with this channel*/+structhidma_lldev*lldev;/* lldma device pointer */+u32tre_local[TRE_SIZE/sizeof(u32)+1];/* TRE local copy */+u32tre_index;/* the offset where this was written*/+u32int_flags;/* interrupt flags */+};++structhidma_lldev{+boolinitialized;/* initialized flag */+u8trch_state;/* trch_state of the device */+u8evch_state;/* evch_state of the device */+u8chidx;/* channel index in the core */+u32nr_tres;/* max number of configs */+spinlock_tlock;/* reentrancy */+structhidma_tre*trepool;/* trepool of user configs */+structdevice*dev;/* device */+void__iomem*trca;/* Transfer Channel address */+void__iomem*evca;/* Event Channel address */+structhidma_tre+**pending_tre_list;/* Pointers to pending TREs */+structhidma_tx_status+*tx_status_list;/* Pointers to pending TREs status*/+s32pending_tre_count;/* Number of TREs pending */++void*tre_ring;/* TRE ring */+dma_addr_ttre_ring_handle;/* TRE ring to be shared with HW */+u32tre_ring_size;/* Byte size of the ring */+u32tre_processed_off;/* last processed TRE */++void*evre_ring;/* EVRE ring */+dma_addr_tevre_ring_handle;/* EVRE ring to be shared with HW */+u32evre_ring_size;/* Byte size of the ring */+u32evre_processed_off;/* last processed EVRE */++u32tre_write_offset;/* TRE write location */+structtasklet_structtask;/* task delivering notifications */+DECLARE_KFIFO_PTR(handoff_fifo,+structhidma_tre*);/* pending TREs FIFO */+};++structhidma_desc{+structdma_async_tx_descriptordesc;+/* link list node for this channel*/+structlist_headnode;+u32tre_ch;+};++structhidma_chan{+boolpaused;+boolallocated;+chardbg_name[16];+u32dma_sig;++/*+*activedescriptoronthischannel+*ItisusedbytheDMAcompletenotificationto+*locatethedescriptorthatinitiatedthetransfer.+*/+structdentry*debugfs;+structdentry*stats;+structhidma_dev*dmadev;+structhidma_desc*running;++structdma_chanchan;+structlist_headfree;+structlist_headprepared;+structlist_headactive;+structlist_headcompleted;++/* Lock for this structure */+spinlock_tlock;+};++structhidma_dev{+intirq;+intchidx;+u32nr_descriptors;++structhidma_lldev*lldev;+void__iomem*dev_trca;+structresource*trca_resource;+void__iomem*dev_evca;+structresource*evca_resource;++/* used to protect the pending channel list*/+spinlock_tlock;+structdma_deviceddev;++structdentry*debugfs;+structdentry*stats;++/* Task delivering issue_pending */+structtasklet_structtask;+};++inthidma_ll_request(structhidma_lldev*llhndl,u32dev_id,+constchar*dev_name,+void(*callback)(void*data),void*data,u32*tre_ch);++voidhidma_ll_free(structhidma_lldev*llhndl,u32tre_ch);+enumdma_statushidma_ll_status(structhidma_lldev*llhndl,u32tre_ch);+boolhidma_ll_isenabled(structhidma_lldev*llhndl);+voidhidma_ll_queue_request(structhidma_lldev*llhndl,u32tre_ch);+voidhidma_ll_start(structhidma_lldev*llhndl);+inthidma_ll_pause(structhidma_lldev*llhndl);+inthidma_ll_resume(structhidma_lldev*llhndl);+voidhidma_ll_set_transfer_params(structhidma_lldev*llhndl,u32tre_ch,+dma_addr_tsrc,dma_addr_tdest,u32len,u32flags);+inthidma_ll_setup(structhidma_lldev*lldev);+structhidma_lldev*hidma_ll_init(structdevice*dev,u32max_channels,+void__iomem*trca,void__iomem*evca,+u8chidx);+inthidma_ll_uninit(structhidma_lldev*llhndl);+irqreturn_thidma_ll_inthandler(intirq,void*arg);+voidhidma_cleanup_pending_tre(structhidma_lldev*llhndl,u8err_info,+u8err_code);+#endif
--
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
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom/bam_dma.csimilarity index 99%rename from drivers/dma/qcom_bam_dma.crename to drivers/dma/qcom/bam_dma.cindex 5a250cd..b6f053d 100644--- a/drivers/dma/qcom_bam_dma.c+++ b/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
From: Mark Rutland <mark.rutland@arm.com> Date: 2016-01-15 15:00:05
Hi,
[adding KVM people, given this is meant for virtualization]
On Mon, Jan 11, 2016 at 09:45:43AM -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.
You mention repeatedly that this is designed for virtualization, but
looking at the series as it stands today I can't see how this operates
from the host side.
This doesn't seem to tie into KVM or VFIO, and as far as I can tell
there's no mechanism for associating channels with a particular virtual
address space (i.e. no configuration of an external or internal IOMMU),
nor pinning of guest pages to allow for DMA to occur safely.
Given that, I'm at a loss as to how this would be used in a hypervisor
context. What am I missing?
Are there additional patches, or do you have some userspace that works
with this in some limited configuration?
Thanks,
Mark.
@@ -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 <okaya@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 <okaya@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 <okaya@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 <okaya@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 <okaya@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 <okaya@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 <okaya@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+Contact: "Sinan Kaya <okaya@cudeaurora.org>"+Description:+ Size of each read request. The value needs to be a power+ of two and can be between 128 and 1024.++What: /sys/devices/platform/hidma-mgmt*/max_wr_xactions+ /sys/devices/platform/QCOM8060:*/max_wr_xactions+Date: Nov 2015+KernelVersion: 4.4+Contact: "Sinan Kaya <okaya@cudeaurora.org>"+Description:+ Contains a value between 0 and 31. Maximum number of+ write 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_write_request+ /sys/devices/platform/QCOM8060:*/max_write_request+Date: Nov 2015+KernelVersion: 4.4+Contact: "Sinan Kaya <okaya@cudeaurora.org>"+Description:+ Size of each write request. The value needs to be a power+ of two and can be between 128 and 1024.
@@ -0,0 +1,295 @@+/*+*QualcommTechnologiesHIDMAManagementSYSinterface+*+*Copyright(c)2015,TheLinuxFoundation.Allrightsreserved.+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodify+*itunderthetermsoftheGNUGeneralPublicLicenseversion2and+*onlyversion2aspublishedbytheFreeSoftwareFoundation.+*+*Thisprogramisdistributedinthehopethatitwillbeuseful,+*butWITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+*MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.Seethe+*GNUGeneralPublicLicenseformoredetails.+*/++#include<linux/sysfs.h>+#include<linux/platform_device.h>++#include"hidma_mgmt.h"++structhidma_chan_attr{+structhidma_mgmt_dev*mdev;+intindex;+structkobj_attributeattr;+};++structhidma_mgmt_fileinfo{+char*name;+intmode;+int(*get)(structhidma_mgmt_dev*mdev);+int(*set)(structhidma_mgmt_dev*mdev,u64val);+};++#define IMPLEMENT_GETSET(name) \+staticintget_##name(structhidma_mgmt_dev*mdev)\+{\+returnmdev->name;\+}\+staticintset_##name(structhidma_mgmt_dev*mdev,u64val)\+{\+u64tmp;\+intrc;\+\+tmp=mdev->name;\+mdev->name=val;\+rc=hidma_mgmt_setup(mdev);\+if(rc)\+mdev->name=tmp;\+returnrc;\+}++#define DECLARE_ATTRIBUTE(name, mode) \+{#name,mode,get_##name,set_##name}++IMPLEMENT_GETSET(hw_version_major)+IMPLEMENT_GETSET(hw_version_minor)+IMPLEMENT_GETSET(max_wr_xactions)+IMPLEMENT_GETSET(max_rd_xactions)+IMPLEMENT_GETSET(max_write_request)+IMPLEMENT_GETSET(max_read_request)+IMPLEMENT_GETSET(dma_channels)+IMPLEMENT_GETSET(chreset_timeout_cycles)++staticintset_priority(structhidma_mgmt_dev*mdev,unsignedinti,u64val)+{+u64tmp;+intrc;++if(i>=mdev->dma_channels)+return-EINVAL;++tmp=mdev->priority[i];+mdev->priority[i]=val;+rc=hidma_mgmt_setup(mdev);+if(rc)+mdev->priority[i]=tmp;+returnrc;+}++staticintset_weight(structhidma_mgmt_dev*mdev,unsignedinti,u64val)+{+u64tmp;+intrc;++if(i>=mdev->dma_channels)+return-EINVAL;++tmp=mdev->weight[i];+mdev->weight[i]=val;+rc=hidma_mgmt_setup(mdev);+if(rc)+mdev->weight[i]=tmp;+returnrc;+}++staticstructhidma_mgmt_fileinfohidma_mgmt_files[]={+DECLARE_ATTRIBUTE(hw_version_major,S_IRUGO),+DECLARE_ATTRIBUTE(hw_version_minor,S_IRUGO),+DECLARE_ATTRIBUTE(dma_channels,S_IRUGO),+DECLARE_ATTRIBUTE(chreset_timeout_cycles,S_IRUGO),+DECLARE_ATTRIBUTE(max_wr_xactions,(S_IRUGO|S_IWUGO)),+DECLARE_ATTRIBUTE(max_rd_xactions,(S_IRUGO|S_IWUGO)),+DECLARE_ATTRIBUTE(max_write_request,(S_IRUGO|S_IWUGO)),+DECLARE_ATTRIBUTE(max_read_request,(S_IRUGO|S_IWUGO)),+};++staticssize_tshow_values(structdevice*dev,structdevice_attribute*attr,+char*buf)+{+structplatform_device*pdev=to_platform_device(dev);+structhidma_mgmt_dev*mdev=platform_get_drvdata(pdev);+unsignedinti;++buf[0]=0;++for(i=0;i<ARRAY_SIZE(hidma_mgmt_files);i++){+if(strcmp(attr->attr.name,hidma_mgmt_files[i].name)==0){+sprintf(buf,"%d\n",hidma_mgmt_files[i].get(mdev));+break;+}+}+returnstrlen(buf);+}++staticssize_tset_values(structdevice*dev,structdevice_attribute*attr,+constchar*buf,size_tcount)+{+structplatform_device*pdev=to_platform_device(dev);+structhidma_mgmt_dev*mdev=platform_get_drvdata(pdev);+unsignedlongtmp;+unsignedinti;+intrc;++rc=kstrtoul(buf,0,&tmp);+if(rc)+returnrc;++for(i=0;i<ARRAY_SIZE(hidma_mgmt_files);i++){+if(strcmp(attr->attr.name,hidma_mgmt_files[i].name)==0){+rc=hidma_mgmt_files[i].set(mdev,tmp);+if(rc)+returnrc;++break;+}+}+returncount;+}++staticssize_tshow_values_channel(structkobject*kobj,+structkobj_attribute*attr,char*buf)+{+structhidma_chan_attr*chattr;+structhidma_mgmt_dev*mdev;++buf[0]=0;+chattr=container_of(attr,structhidma_chan_attr,attr);+mdev=chattr->mdev;+if(strcmp(attr->attr.name,"priority")==0)+sprintf(buf,"%d\n",mdev->priority[chattr->index]);+elseif(strcmp(attr->attr.name,"weight")==0)+sprintf(buf,"%d\n",mdev->weight[chattr->index]);++returnstrlen(buf);+}++staticssize_tset_values_channel(structkobject*kobj,+structkobj_attribute*attr,constchar*buf,+size_tcount)+{+structhidma_chan_attr*chattr;+structhidma_mgmt_dev*mdev;+unsignedlongtmp;+intrc;++chattr=container_of(attr,structhidma_chan_attr,attr);+mdev=chattr->mdev;++rc=kstrtoul(buf,0,&tmp);+if(rc)+returnrc;++if(strcmp(attr->attr.name,"priority")==0){+rc=set_priority(mdev,chattr->index,tmp);+if(rc)+returnrc;+}elseif(strcmp(attr->attr.name,"weight")==0){+rc=set_weight(mdev,chattr->index,tmp);+if(rc)+returnrc;+}+returncount;+}++staticintcreate_sysfs_entry(structhidma_mgmt_dev*dev,char*name,intmode)+{+structdevice_attribute*attrs;+char*name_copy;++attrs=devm_kmalloc(&dev->pdev->dev,+sizeof(structdevice_attribute),GFP_KERNEL);+if(!attrs)+return-ENOMEM;++name_copy=devm_kstrdup(&dev->pdev->dev,name,GFP_KERNEL);+if(!name_copy)+return-ENOMEM;++attrs->attr.name=name_copy;+attrs->attr.mode=mode;+attrs->show=show_values;+attrs->store=set_values;+sysfs_attr_init(&attrs->attr);++returndevice_create_file(&dev->pdev->dev,attrs);+}++staticintcreate_sysfs_entry_channel(structhidma_mgmt_dev*mdev,char*name,+intmode,intindex,+structkobject*parent)+{+structhidma_chan_attr*chattr;+char*name_copy;++chattr=devm_kmalloc(&mdev->pdev->dev,sizeof(*chattr),GFP_KERNEL);+if(!chattr)+return-ENOMEM;++name_copy=devm_kstrdup(&mdev->pdev->dev,name,GFP_KERNEL);+if(!name_copy)+return-ENOMEM;++chattr->mdev=mdev;+chattr->index=index;+chattr->attr.attr.name=name_copy;+chattr->attr.attr.mode=mode;+chattr->attr.show=show_values_channel;+chattr->attr.store=set_values_channel;+sysfs_attr_init(&chattr->attr.attr);++returnsysfs_create_file(parent,&chattr->attr.attr);+}++inthidma_mgmt_init_sys(structhidma_mgmt_dev*mdev)+{+unsignedinti;+intrc;+intrequired;+structkobject*chanops;++required=sizeof(*mdev->chroots)*mdev->dma_channels;+mdev->chroots=devm_kmalloc(&mdev->pdev->dev,required,GFP_KERNEL);+if(!mdev->chroots)+return-ENOMEM;++chanops=kobject_create_and_add("chanops",&mdev->pdev->dev.kobj);+if(!chanops)+return-ENOMEM;++/* create each channel directory here */+for(i=0;i<mdev->dma_channels;i++){+charname[20];++snprintf(name,sizeof(name),"chan%d",i);+mdev->chroots[i]=kobject_create_and_add(name,chanops);+if(!mdev->chroots[i])+return-ENOMEM;+}++/* populate common parameters */+for(i=0;i<ARRAY_SIZE(hidma_mgmt_files);i++){+rc=create_sysfs_entry(mdev,hidma_mgmt_files[i].name,+hidma_mgmt_files[i].mode);+if(rc)+returnrc;+}++/* populate parameters that are per channel */+for(i=0;i<mdev->dma_channels;i++){+rc=create_sysfs_entry_channel(mdev,"priority",+(S_IRUGO|S_IWUGO),i,+mdev->chroots[i]);+if(rc)+returnrc;++rc=create_sysfs_entry_channel(mdev,"weight",+(S_IRUGO|S_IWUGO),i,+mdev->chroots[i]);+if(rc)+returnrc;+}++return0;+}+EXPORT_SYMBOL_GPL(hidma_mgmt_init_sys);
--
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
From: Sinan Kaya <hidden> Date: 2016-01-15 15:12:07
Hi Mark,
On 1/15/2016 9:56 AM, Mark Rutland wrote:
Hi,
[adding KVM people, given this is meant for virtualization]
On Mon, Jan 11, 2016 at 09:45:43AM -0500, Sinan Kaya wrote:
quoted
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.
You mention repeatedly that this is designed for virtualization, but
looking at the series as it stands today I can't see how this operates
from the host side.
This doesn't seem to tie into KVM or VFIO, and as far as I can tell
there's no mechanism for associating channels with a particular virtual
address space (i.e. no configuration of an external or internal IOMMU),
nor pinning of guest pages to allow for DMA to occur safely.
I'm using VFIO platform driver for this purpose. VFIO platform driver is
capable of assigning any platform device to a guest machine with this driver.
You just unbind the HIDMA channel driver from the hypervisor and bind to vfio
driver using the very same approach you'd use with PCIe.
Of course, this all assumes the presence of an IOMMU driver on the system. VFIO
driver uses the IOMMU driver to create the mappings.
The mechanism used here is not different from VFIO PCI from user perspective.
Given that, I'm at a loss as to how this would be used in a hypervisor
context. What am I missing?
Are there additional patches, or do you have some userspace that works
with this in some limited configuration?
No, these are the only patches. We have one patch for the QEMU but from kernel
perspective this is it.
I just rely on the platform VFIO driver to do the work.
From: Marc Zyngier <hidden> Date: 2016-01-15 15:14:35
On 15/01/16 14:56, Mark Rutland wrote:
Hi,
[adding KVM people, given this is meant for virtualization]
On Mon, Jan 11, 2016 at 09:45:43AM -0500, Sinan Kaya wrote:
quoted
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.
You mention repeatedly that this is designed for virtualization, but
looking at the series as it stands today I can't see how this operates
from the host side.
Nor the guest's, TBH. How do host and guest communicate, what is the
infrastructure, how is it meant to be used? A lot of questions, and no
answer whatsoever in this series.
This doesn't seem to tie into KVM or VFIO, and as far as I can tell
there's no mechanism for associating channels with a particular virtual
address space (i.e. no configuration of an external or internal IOMMU),
nor pinning of guest pages to allow for DMA to occur safely.
Given that, I'm at a loss as to how this would be used in a hypervisor
context. What am I missing?
Are there additional patches, or do you have some userspace that works
with this in some limited configuration?
Well, this looks so far like a code dumping exercise. I'd very much
appreciate a HIDMA101 crash course:
- How do host and guest communicate?
- How is the integration performed in the hypervisor?
- Does the HYP side requires any context switch (and how is that done)?
- What makes it safe?
Without any of this information (and pointer to the code to back it up),
I'm very reluctant to take any of this.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
@@ -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
Just to check, where do these max-* values come from?
Are they some correctness requirement of the bus this is attached to?
Are they tuning values?
The latter doesn't really belong in the DT. Given they're writeable from
the driver, it seems like that's what they are...
+- channel-reset-timeout-cycles: Channel reset timeout in cycles for this SOC.
I'm not sure what this means. Could you elaborate on this is?
quoted hunk
++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.
Don't mention drivers here.
All you need to state is that when the OS is not in control of the
management interface (i.e. it's a guest), the channel nodes appear on
their own, not under a management node.
Other than the above questions, this looks ok to me.
Thanks,
Mark.
+
+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 at 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 at 0x5c050000 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c050000 0x0 0x1000>,
+ <0 0x5c0b0000 0x0 0x1000>;
+ interrupts = <0 389 0>;
+ desc-count = <10>;
+ channel-index = <4>;
+ };
+ };
+
+Guest OS configuration:
+
+ hidma_24: dma-controller at 0x5c050000 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c050000 0x0 0x1000>,
+ <0 0x5c0b0000 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
From: Mark Rutland <mark.rutland@arm.com> Date: 2016-01-15 15:23:23
On Fri, Jan 15, 2016 at 10:12:00AM -0500, Sinan Kaya wrote:
Hi Mark,
On 1/15/2016 9:56 AM, Mark Rutland wrote:
quoted
Hi,
[adding KVM people, given this is meant for virtualization]
On Mon, Jan 11, 2016 at 09:45:43AM -0500, Sinan Kaya wrote:
quoted
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.
You mention repeatedly that this is designed for virtualization, but
looking at the series as it stands today I can't see how this operates
from the host side.
This doesn't seem to tie into KVM or VFIO, and as far as I can tell
there's no mechanism for associating channels with a particular virtual
address space (i.e. no configuration of an external or internal IOMMU),
nor pinning of guest pages to allow for DMA to occur safely.
I'm using VFIO platform driver for this purpose. VFIO platform driver is
capable of assigning any platform device to a guest machine with this driver.
Typically VFIO-platform also comes with a corresponding reset driver.
You don't need one?
You just unbind the HIDMA channel driver from the hypervisor and bind to vfio
driver using the very same approach you'd use with PCIe.
Of course, this all assumes the presence of an IOMMU driver on the system. VFIO
driver uses the IOMMU driver to create the mappings.
No IOMMU was described in the DT binding. It sounds like you'd need an
optional (not present in the guest) iommus property per-channel
The mechanism used here is not different from VFIO PCI from user perspective.
quoted
Given that, I'm at a loss as to how this would be used in a hypervisor
context. What am I missing?
Are there additional patches, or do you have some userspace that works
with this in some limited configuration?
No, these are the only patches. We have one patch for the QEMU but from kernel
perspective this is it.
Do you have a link to that? Seeing it would help to ease my concerns.
Thanks,
Mark.
From: Mark Rutland <mark.rutland@arm.com> Date: 2016-01-15 15:31:20
On Fri, Jan 15, 2016 at 03:16:38PM +0000, Mark Rutland wrote:
On Mon, Jan 11, 2016 at 09:45:42AM -0500, Sinan Kaya wrote:
quoted
Add documentation for the Qualcomm Technologies HIDMA driver.
s/driver/binding/
quoted
Signed-off-by: Sinan Kaya <redacted>
Acked-by: Rob Herring <robh@kernel.org>
Further to my reply below, I'm generally uncomfortable with some
properties (max-* need a better description if they are a HW
requirement, and probably should not be present otherwise). I'm also
concerned that information necessary for the advertised use-case of the
device (e.g. IOMMUs) is missing [1], and we're missing parts of the
story necessary to review this for correctness.
Until that's settled, I don't think this is ready yet, and I don't think
this should be picked up.
I'm sorry to say that at this stage, as I realise that may sound
obstructive. That's not my intention, and I hope we can figure out those
details quickly.
Thanks,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/399850.html
@@ -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
Just to check, where do these max-* values come from?
Are they some correctness requirement of the bus this is attached to?
Are they tuning values?
The latter doesn't really belong in the DT. Given they're writeable from
the driver, it seems like that's what they are...
quoted
+- channel-reset-timeout-cycles: Channel reset timeout in cycles for this SOC.
I'm not sure what this means. Could you elaborate on this is?
quoted
++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.
Don't mention drivers here.
All you need to state is that when the OS is not in control of the
management interface (i.e. it's a guest), the channel nodes appear on
their own, not under a management node.
Other than the above questions, this looks ok to me.
Thanks,
Mark.
quoted
+
+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 at 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 at 0x5c050000 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c050000 0x0 0x1000>,
+ <0 0x5c0b0000 0x0 0x1000>;
+ interrupts = <0 389 0>;
+ desc-count = <10>;
+ channel-index = <4>;
+ };
+ };
+
+Guest OS configuration:
+
+ hidma_24: dma-controller at 0x5c050000 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c050000 0x0 0x1000>,
+ <0 0x5c0b0000 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 devicetree" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Mark Rutland <mark.rutland@arm.com> Date: 2016-01-15 15:37:23
On Fri, Jan 15, 2016 at 03:14:28PM +0000, Marc Zyngier wrote:
On 15/01/16 14:56, Mark Rutland wrote:
quoted
Hi,
[adding KVM people, given this is meant for virtualization]
On Mon, Jan 11, 2016 at 09:45:43AM -0500, Sinan Kaya wrote:
quoted
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.
You mention repeatedly that this is designed for virtualization, but
looking at the series as it stands today I can't see how this operates
from the host side.
Nor the guest's, TBH. How do host and guest communicate, what is the
infrastructure, how is it meant to be used? A lot of questions, and no
answer whatsoever in this series.
I think the guest's PoV is fairly simple and understood. The DMA channel
is pased in as with any passthrough of any other platform device.
No communication with the host is necessary -- an isolated channel is
usable.
The larger concern is isolation, given the lack of IOMMU, or anything
obvious w.r.t. pinning of pages.
quoted
This doesn't seem to tie into KVM or VFIO, and as far as I can tell
there's no mechanism for associating channels with a particular virtual
address space (i.e. no configuration of an external or internal IOMMU),
nor pinning of guest pages to allow for DMA to occur safely.
Given that, I'm at a loss as to how this would be used in a hypervisor
context. What am I missing?
Are there additional patches, or do you have some userspace that works
with this in some limited configuration?
Well, this looks so far like a code dumping exercise. I'd very much
appreciate a HIDMA101 crash course:
- How do host and guest communicate?
- How is the integration performed in the hypervisor?
- Does the HYP side requires any context switch (and how is that done)?
I don't believe this requires any context-switch -- it's the same as
assigning any other platform device other than additional proeprties
being controlled in the managament interface.
- What makes it safe?
I'm concerned with how this is safe, and with the userspace interface.
e.g. if the user wants to up the QoS for a VM, how to they find the
right channel in sysfs to alter?
Without any of this information (and pointer to the code to back it up),
I'm very reluctant to take any of this.
From: Sinan Kaya <hidden> Date: 2016-01-15 15:40:54
On 1/15/2016 10:14 AM, Marc Zyngier wrote:
On 15/01/16 14:56, Mark Rutland wrote:
quoted
Hi,
[adding KVM people, given this is meant for virtualization]
On Mon, Jan 11, 2016 at 09:45:43AM -0500, Sinan Kaya wrote:
quoted
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.
You mention repeatedly that this is designed for virtualization, but
looking at the series as it stands today I can't see how this operates
from the host side.
Nor the guest's, TBH. How do host and guest communicate, what is the
infrastructure, how is it meant to be used? A lot of questions, and no
answer whatsoever in this series.
I always make an analogy of HIDMA channel driver to a PCI endpoint device driver (8139too for example)
running on the guest machine.
Both HIDMA and PCI uses device pass-through approach.
I don't have an infrastructure for host and guest to communicate as I don't need to.
A HIDMA channel is assigned to a guest machine after an unbind from the host machine.
Guest machine uses HIDMA channel driver to offload DMA operations. The guest machine owns the
HW registers for the channel. It doesn't need to trap to host for register read/writes etc.
All guest machine pages used are assumed to be pinned similar to VFIO PCI.
The reason is performance. The IOMMU takes care of the address translation for me.
quoted
This doesn't seem to tie into KVM or VFIO, and as far as I can tell
there's no mechanism for associating channels with a particular virtual
address space (i.e. no configuration of an external or internal IOMMU),
nor pinning of guest pages to allow for DMA to occur safely.
Given that, I'm at a loss as to how this would be used in a hypervisor
context. What am I missing?
Are there additional patches, or do you have some userspace that works
with this in some limited configuration?
Well, this looks so far like a code dumping exercise. I'd very much
appreciate a HIDMA101 crash course:
Sure, I'm ready to answer any questions. This is really a VFIO platform course. Not
a HIDMA driver course. The approach is not different if you assign a platfom
SATA (AHCI) or SDHC driver to a guest machine.
The summary is that:
- IOMMU takes care of the mappings via VFIO driver.
- Guest machine owns the HW. No hypervisor interaction.
- How do host and guest communicate?
They don't.
- How is the integration performed in the hypervisor?
Hypervisor has a bunch of channel resources. For each guest machine, the channel gets
unbound from the hypervisor. Channels get bind to each VFIO platform device and then
control is given to the guest machine.
Once the guest machine is shutdown, VFIO driver still owns the channel device. It can
assign the device to another guest machine.
- Does the HYP side requires any context switch (and how is that done)?
No communication is needed.
- What makes it safe?
No communication is needed.
Without any of this information (and pointer to the code to back it up),
I'm very reluctant to take any of this.
Please let me know what exactly is not clear.
You don't write a virtualization driver for 8139too driver. The driver works whether it is running in the
guest machine or the hypervisor.
The 8139too driver does not trap to the hypervisor for functionality when used in device
pass-through mode.
No difference here.
Thanks,
M.
--
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
From: Sinan Kaya <hidden> Date: 2016-01-15 16:01:18
On 1/15/2016 10:36 AM, Mark Rutland wrote:
On Fri, Jan 15, 2016 at 03:14:28PM +0000, Marc Zyngier wrote:
quoted
On 15/01/16 14:56, Mark Rutland wrote:
quoted
Hi,
[adding KVM people, given this is meant for virtualization]
On Mon, Jan 11, 2016 at 09:45:43AM -0500, Sinan Kaya wrote:
quoted
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.
You mention repeatedly that this is designed for virtualization, but
looking at the series as it stands today I can't see how this operates
from the host side.
Nor the guest's, TBH. How do host and guest communicate, what is the
infrastructure, how is it meant to be used? A lot of questions, and no
answer whatsoever in this series.
I think the guest's PoV is fairly simple and understood. The DMA channel
is pased in as with any passthrough of any other platform device.
No communication with the host is necessary -- an isolated channel is
usable.
Correct, I'm behind on emails. I'm following you.
The larger concern is isolation, given the lack of IOMMU, or anything
obvious w.r.t. pinning of pages.
I assume the presence of an IOMMU if used in the guest machine. I wonder
if I can place a check and make the driver fail if IOMMU driver is not present.
Any ideas?
quoted
quoted
This doesn't seem to tie into KVM or VFIO, and as far as I can tell
there's no mechanism for associating channels with a particular virtual
address space (i.e. no configuration of an external or internal IOMMU),
nor pinning of guest pages to allow for DMA to occur safely.
Given that, I'm at a loss as to how this would be used in a hypervisor
context. What am I missing?
Are there additional patches, or do you have some userspace that works
with this in some limited configuration?
I forgot to mention that these are the only kernel patches. A userspace application
is being built as we speak by another team.
The userspace application will use sysfs to communicate to the management driver.
The management driver knows how to change runtime characteristics like priority and
weight.
quoted
Well, this looks so far like a code dumping exercise. I'd very much
appreciate a HIDMA101 crash course:
- How do host and guest communicate?
- How is the integration performed in the hypervisor?
- Does the HYP side requires any context switch (and how is that done)?
I don't believe this requires any context-switch -- it's the same as
assigning any other platform device other than additional proeprties
being controlled in the managament interface.
Agreed.
quoted
- What makes it safe?
I'm concerned with how this is safe, and with the userspace interface.
e.g. if the user wants to up the QoS for a VM, how to they find the
right channel in sysfs to alter?
The HW supports changing the QoS values on the flight. In order to locate the
object, I'm exporting a
I tried to address your concern on v10 last series. Here is brief summary.
Each channel device has a sysfs entry named chid.
What: /sys/devices/platform/hidma-*/chid
+ /sys/devices/platform/QCOM8061:*/chid
Each management object has one priority and weight file per channel.
+What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority
+ /sys/devices/platform/QCOM8060:*/chanops/chan*/priority
Suppose you want to change the priority of a channel you assigned to guess,
the userspace application goes and reads the chid value of the channel.
Then goes to chanops/chan<chid>/ directory and can change priority and weight
parameters here.
Here is how the directory looks like. QCOM8060:00 is a management object.
QCOM8061:0x are the channel objects.
/sys/devices/platform/QCOM8060:00# ls
QCOM8061:00
QCOM8061:01
QCOM8061:02
QCOM8061:03
QCOM8061:04
QCOM8061:05
chanops
<other common attributes>
quoted
Without any of this information (and pointer to the code to back it up),
I'm very reluctant to take any of this.
Likewise.
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
@@ -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
Just to check, where do these max-* values come from?
These are HW bus parameters like the burst count and
size of each burst. These values change based on the SoC this IP is in use.
Are they some correctness requirement of the bus this is attached to?
You can starve other peripherals if you use incorrect values as the bus is
shared with other peripherals. Yes, correctness is required.
Are they tuning values?
Correct value is necessary for functioning. I'd consider weight and priority
as the only tuning parameters.
The latter doesn't really belong in the DT. Given they're writeable from
the driver, it seems like that's what they are...
Good catch. Those should have been read-only. I wanted to be able to export these
information to the userspace app. I'll fix the sysfs to make them read-only.
quoted
+- channel-reset-timeout-cycles: Channel reset timeout in cycles for this SOC.
I'm not sure what this means. Could you elaborate on this is?
After each reset command, HW starts a timer. This is the time HW waits before it declares
reset failed.
quoted
++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.
Don't mention drivers here.
All you need to state is that when the OS is not in control of the
management interface (i.e. it's a guest), the channel nodes appear on
their own, not under a management node.
Replaced the above paragraph with yours.
Other than the above questions, this looks ok to me.
Thanks,
Mark.
quoted
+
+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 at 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 at 0x5c050000 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c050000 0x0 0x1000>,
+ <0 0x5c0b0000 0x0 0x1000>;
+ interrupts = <0 389 0>;
+ desc-count = <10>;
+ channel-index = <4>;
+ };
+ };
+
+Guest OS configuration:
+
+ hidma_24: dma-controller at 0x5c050000 {
+ compatible = "qcom,hidma-1.0";
+ reg = <0 0x5c050000 0x0 0x1000>,
+ <0 0x5c0b0000 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
--
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
From: Sinan Kaya <hidden> Date: 2016-01-15 17:05:25
On 1/15/2016 10:30 AM, Mark Rutland wrote:
Further to my reply below, I'm generally uncomfortable with some
properties (max-* need a better description if they are a HW
requirement, and probably should not be present otherwise).
I'll add more description.
I'm also
concerned that information necessary for the advertised use-case of the
device (e.g. IOMMUs) is missing [1], and we're missing parts of the
story necessary to review this for correctness.
OK. Let me work on this. I tried to capture as much documentation as possible
into the series before. One reviewer said I should add it. Another reviewer said I should
remove it.
Where would be the best place to document the use case?
- In the source file?
- In the commit message?
- In the device-tree documentation?
I'll try to write up something based on your and Mark Zyngier's questions for the
next release.
Until that's settled, I don't think this is ready yet, and I don't think
this should be picked up.
I'm sorry to say that at this stage, as I realise that may sound
obstructive. That's not my intention, and I hope we can figure out those
details quickly.
I hope so too. I'm going towards V20 with small nitpicks rather than the good
feedback like yours.
--
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
From: Sinan Kaya <hidden> Date: 2016-01-15 17:17:04
quoted
quoted
This doesn't seem to tie into KVM or VFIO, and as far as I can tell
there's no mechanism for associating channels with a particular virtual
address space (i.e. no configuration of an external or internal IOMMU),
nor pinning of guest pages to allow for DMA to occur safely.
I'm using VFIO platform driver for this purpose. VFIO platform driver is
capable of assigning any platform device to a guest machine with this driver.
Typically VFIO-platform also comes with a corresponding reset driver.
You don't need one?
The HIDMA channel driver resets the channel before using it. That's why, I never
bothered with writing a reset driver on the hypervisor.
quoted
You just unbind the HIDMA channel driver from the hypervisor and bind to vfio
driver using the very same approach you'd use with PCIe.
Of course, this all assumes the presence of an IOMMU driver on the system. VFIO
driver uses the IOMMU driver to create the mappings.
No IOMMU was described in the DT binding. It sounds like you'd need an
optional (not present in the guest) iommus property per-channel
You are right. I missed that part. I'll update the device-tree binding documentation.
quoted
The mechanism used here is not different from VFIO PCI from user perspective.
quoted
Given that, I'm at a loss as to how this would be used in a hypervisor
context. What am I missing?
Are there additional patches, or do you have some userspace that works
with this in some limited configuration?
No, these are the only patches. We have one patch for the QEMU but from kernel
perspective this is it.
Do you have a link to that? Seeing it would help to ease my concerns.
The QEMU driver has not been posted yet. As far as I know, it just discovers the memory
resources on the platform object and creates mappings for the guest machine only.
Shanker Donthineni and Vikram Sethi will post the QEMU patch later.
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
From: Marc Zyngier <hidden> Date: 2016-01-15 17:28:55
On 15/01/16 15:40, Sinan Kaya wrote:
On 1/15/2016 10:14 AM, Marc Zyngier wrote:
quoted
On 15/01/16 14:56, Mark Rutland wrote:
quoted
Hi,
[adding KVM people, given this is meant for virtualization]
On Mon, Jan 11, 2016 at 09:45:43AM -0500, Sinan Kaya wrote:
quoted
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.
You mention repeatedly that this is designed for virtualization, but
looking at the series as it stands today I can't see how this operates
from the host side.
Nor the guest's, TBH. How do host and guest communicate, what is the
infrastructure, how is it meant to be used? A lot of questions, and no
answer whatsoever in this series.
I always make an analogy of HIDMA channel driver to a PCI endpoint device driver (8139too for example)
running on the guest machine.
Both HIDMA and PCI uses device pass-through approach.
I don't have an infrastructure for host and guest to communicate as I don't need to.
A HIDMA channel is assigned to a guest machine after an unbind from the host machine.
Guest machine uses HIDMA channel driver to offload DMA operations. The guest machine owns the
HW registers for the channel. It doesn't need to trap to host for register read/writes etc.
All guest machine pages used are assumed to be pinned similar to VFIO PCI.
The reason is performance. The IOMMU takes care of the address translation for me.
quoted
quoted
This doesn't seem to tie into KVM or VFIO, and as far as I can tell
there's no mechanism for associating channels with a particular virtual
address space (i.e. no configuration of an external or internal IOMMU),
nor pinning of guest pages to allow for DMA to occur safely.
Given that, I'm at a loss as to how this would be used in a hypervisor
context. What am I missing?
Are there additional patches, or do you have some userspace that works
with this in some limited configuration?
Well, this looks so far like a code dumping exercise. I'd very much
appreciate a HIDMA101 crash course:
Sure, I'm ready to answer any questions. This is really a VFIO platform course. Not
a HIDMA driver course. The approach is not different if you assign a platfom
SATA (AHCI) or SDHC driver to a guest machine.
I happen to have an idea of how VFIO works...
The summary is that:
- IOMMU takes care of the mappings via VFIO driver.
- Guest machine owns the HW. No hypervisor interaction.
Then it might be worth mentioning all of this
quoted
- How do host and guest communicate?
They don't.
quoted
- How is the integration performed in the hypervisor?
Hypervisor has a bunch of channel resources. For each guest machine, the channel gets
unbound from the hypervisor. Channels get bind to each VFIO platform device and then
control is given to the guest machine.
And what does the hypervisor do with those in the meantime? Above, you
say "Guest machine owns the HW". So what is that hypervisor code used
for? Is that your reset driver?
You may want to drop the "hypervisor" designation, BTW, because this has
no real connection to virtualisation.
Once the guest machine is shutdown, VFIO driver still owns the channel device. It can
assign the device to another guest machine.
quoted
- Does the HYP side requires any context switch (and how is that done)?
No communication is needed.
quoted
- What makes it safe?
No communication is needed.
quoted
Without any of this information (and pointer to the code to back it up),
I'm very reluctant to take any of this.
Please let me know what exactly is not clear.
You don't write a virtualization driver for 8139too driver. The driver works whether it is running in the
guest machine or the hypervisor.
Exactly. No hypervisor code needed whatsoever. So please get rid of this
hypervisor nonsense! ;-)
Thanks,
M.
--
Jazz is not dead. It just smells funny...
From: Marc Zyngier <hidden> Date: 2016-01-15 17:32:14
On 15/01/16 17:16, Sinan Kaya wrote:
quoted
quoted
quoted
This doesn't seem to tie into KVM or VFIO, and as far as I can tell
there's no mechanism for associating channels with a particular virtual
address space (i.e. no configuration of an external or internal IOMMU),
nor pinning of guest pages to allow for DMA to occur safely.
I'm using VFIO platform driver for this purpose. VFIO platform driver is
capable of assigning any platform device to a guest machine with this driver.
Typically VFIO-platform also comes with a corresponding reset driver.
You don't need one?
The HIDMA channel driver resets the channel before using it. That's why, I never
bothered with writing a reset driver on the hypervisor.
quoted
quoted
You just unbind the HIDMA channel driver from the hypervisor and bind to vfio
driver using the very same approach you'd use with PCIe.
Of course, this all assumes the presence of an IOMMU driver on the system. VFIO
driver uses the IOMMU driver to create the mappings.
No IOMMU was described in the DT binding. It sounds like you'd need an
optional (not present in the guest) iommus property per-channel
You are right. I missed that part. I'll update the device-tree binding documentation.
quoted
quoted
The mechanism used here is not different from VFIO PCI from user perspective.
quoted
Given that, I'm at a loss as to how this would be used in a hypervisor
context. What am I missing?
Are there additional patches, or do you have some userspace that works
with this in some limited configuration?
No, these are the only patches. We have one patch for the QEMU but from kernel
perspective this is it.
Do you have a link to that? Seeing it would help to ease my concerns.
The QEMU driver has not been posted yet. As far as I know, it just discovers the memory
resources on the platform object and creates mappings for the guest machine only.
Shanker Donthineni and Vikram Sethi will post the QEMU patch later.
Then may I suggest you both synchronize your submissions? I'd really
like to hear from the QEMU maintainers that they are satisfied with that
side of the story as well.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
From: Sinan Kaya <hidden> Date: 2016-01-15 17:44:17
quoted
Sure, I'm ready to answer any questions. This is really a VFIO platform course. Not
a HIDMA driver course. The approach is not different if you assign a platfom
SATA (AHCI) or SDHC driver to a guest machine.
I happen to have an idea of how VFIO works...
OK. Good to know that we are speaking the same language.
quoted
The summary is that:
- IOMMU takes care of the mappings via VFIO driver.
- Guest machine owns the HW. No hypervisor interaction.
Then it might be worth mentioning all of this
Sure thing. I'm trying to locate where the right place would be.
I'll target commit message and source code for now.
quoted
quoted
- How do host and guest communicate?
They don't.
quoted
- How is the integration performed in the hypervisor?
Hypervisor has a bunch of channel resources. For each guest machine, the channel gets
unbound from the hypervisor. Channels get bind to each VFIO platform device and then
control is given to the guest machine.
And what does the hypervisor do with those in the meantime? Above, you
say "Guest machine owns the HW".
The guest machine owns the channel HW which runs independent of the management HW.
So what is that hypervisor code used
for? Is that your reset driver?
The HIDMA "management" driver which runs at the hypervisor owns the management HW.
Management driver serves two purposes.
1. Common bus parameter configuration (could be called reset driver).
2. Fine tuning the HW resources.
Multiple HIDMA channels share common HW resources. The management driver is able to change
the priority (high/low) and weight (round-robin priority) of each HIDMA channel on the flight.
The system administrator will use a userspace application to allocate HW resources to each channel via
the management driver.
The management driver does some common configuration too for these parameters.
The management interface also has to be enabled before any channel can be enabled.
- max-write-burst-bytes: Maximum write burst in bytes that HIDMA can
occupy the bus for in a single transaction. A memcpy requested is
fragmented to multiples of this amount. This parameter is used while
writing into destination memory. Setting this value incorrectly can
starve other peripherals in the system.
- max-read-burst-bytes: Maximum read burst in bytes that HIDMA can
occupy the bus for in a single transaction. A memcpy request is
fragmented to multiples of this amount. This parameter is used while
reading the source memory. Setting this value incorrectly can starve
other peripherals in the system.
- max-write-transactions: This value is how many times a write burst is
applied back to back while writing to the destination before yielding
the bus.
- max-read-transactions: This value is how many times a read burst is
applied back to back while reading the source before a yielding the bus.
- channel-reset-timeout-cycles: Channel reset timeout in cycles for this SOC.
Once a reset is applied to the HW, HW starts a timer for reset operation
to confirm. If reset is not completed within this time, HW reports reset
failure.
You may want to drop the "hypervisor" designation, BTW, because this has
no real connection to virtualisation.
Would you use host/guest relationship?
quoted
Once the guest machine is shutdown, VFIO driver still owns the channel device. It can
assign the device to another guest machine.
quoted
- Does the HYP side requires any context switch (and how is that done)?
No communication is needed.
quoted
- What makes it safe?
No communication is needed.
quoted
Without any of this information (and pointer to the code to back it up),
I'm very reluctant to take any of this.
Please let me know what exactly is not clear.
You don't write a virtualization driver for 8139too driver. The driver works whether it is running in the
guest machine or the hypervisor.
Exactly. No hypervisor code needed whatsoever. So please get rid of this
hypervisor nonsense! ;-)
I need the management driver for administrative purposes and common initialization.
I like the split SW design as it follows the HW design too.
Thanks,
M.
--
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
From: Marc Zyngier <hidden> Date: 2016-01-15 18:08:59
On 15/01/16 17:44, Sinan Kaya wrote:
quoted
quoted
[...]
quoted
You may want to drop the "hypervisor" designation, BTW, because this has
no real connection to virtualisation.
Would you use host/guest relationship?
Not even that. This is a host/user relationship, as VFIO is in no way
virtualisation specific. It just gives you a way to make a device
accessible to userspace. KVM is just a specialised instance of a more
generic problem.
quoted
quoted
Once the guest machine is shutdown, VFIO driver still owns the channel device. It can
assign the device to another guest machine.
quoted
- Does the HYP side requires any context switch (and how is that done)?
No communication is needed.
quoted
- What makes it safe?
No communication is needed.
quoted
Without any of this information (and pointer to the code to back it up),
I'm very reluctant to take any of this.
Please let me know what exactly is not clear.
You don't write a virtualization driver for 8139too driver. The driver works whether it is running in the
guest machine or the hypervisor.
Exactly. No hypervisor code needed whatsoever. So please get rid of this
hypervisor nonsense! ;-)
I need the management driver for administrative purposes and common initialization.
I like the split SW design as it follows the HW design too.
I have no problem with the split design (whatever floats your boat),
more with the terminology which I find very confusing. It would be a lot
better if you stuck with management (host) and client (user), or some
other general terminology.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
From: Sinan Kaya <hidden> Date: 2016-01-15 22:47:58
On 1/15/2016 12:32 PM, Marc Zyngier wrote:
quoted
quoted
Do you have a link to that? Seeing it would help to ease my concerns.
The QEMU driver has not been posted yet. As far as I know, it just discovers the memory
resources on the platform object and creates mappings for the guest machine only.
Shanker Donthineni and Vikram Sethi will post the QEMU patch later.
Then may I suggest you both synchronize your submissions? I'd really
like to hear from the QEMU maintainers that they are satisfied with that
side of the story as well.
From: Marc Zyngier <hidden> Date: 2016-01-18 09:06:24
On 15/01/16 22:47, Sinan Kaya wrote:
On 1/15/2016 12:32 PM, Marc Zyngier wrote:
quoted
quoted
quoted
Do you have a link to that? Seeing it would help to ease my concerns.
The QEMU driver has not been posted yet. As far as I know, it just discovers the memory
resources on the platform object and creates mappings for the guest machine only.
Shanker Donthineni and Vikram Sethi will post the QEMU patch later.
Then may I suggest you both synchronize your submissions? I'd really
like to hear from the QEMU maintainers that they are satisfied with that
side of the story as well.
The HIDMA QEMU driver is also based on VFIO platform driver in QEMU. It is not a new concept
or new framework. All tried and tested solutions.
The driver below is already using this feature. HIDMA is no exception.
I have verified functionality of HIDMA linux driver with HIDMA QEMU driver already.
That you have tested what you propose is the minimum you can do.
None of which warrants that what you're doing is the right thing. Since
nobody has seen your QEMU code, I'm not going to take any bet.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
From: Mark Rutland <mark.rutland@arm.com> Date: 2016-01-18 11:40:05
On Fri, Jan 15, 2016 at 12:05:19PM -0500, Sinan Kaya wrote:
On 1/15/2016 10:30 AM, Mark Rutland wrote:
quoted
Further to my reply below, I'm generally uncomfortable with some
properties (max-* need a better description if they are a HW
requirement, and probably should not be present otherwise).
I'll add more description.
quoted
I'm also
concerned that information necessary for the advertised use-case of the
device (e.g. IOMMUs) is missing [1], and we're missing parts of the
story necessary to review this for correctness.
OK. Let me work on this. I tried to capture as much documentation as possible
into the series before. One reviewer said I should add it. Another reviewer said I should
remove it.
Where would be the best place to document the use case?
- In the source file?
- In the commit message?
- In the device-tree documentation?
Mostly the cover letter, but to varying degrees some information should
appear in the commit messages, documentation, and code.
The cover letter should give a high-level overview sufficient to get
reviewing (e.g. that should point out we expect isolation by IOMMUs).
There should also be pointers to related components (i.e. the QEMU
driver intended to communicate with this).
Things subject to change should go in the cover letter, as it's not
permanent.
If something strongly influences the design in a way that's non-obvious,
then that will probably remain non-obvious. For that, there should
certainly be something in the commit message. If it's something that
will be hit in general usage of the binding (or forms part of the
contract of the binding), that should be described in the binding
documentation.
If there's some caveat other developers need to be aware of, drop a
comment in the code.
Thanks,
Mark.
From: Mark Rutland <mark.rutland@arm.com> Date: 2016-01-18 11:49:58
quoted
quoted
+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
Just to check, where do these max-* values come from?
These are HW bus parameters like the burst count and
size of each burst. These values change based on the SoC this IP is in use.
quoted
Are they some correctness requirement of the bus this is attached to?
You can starve other peripherals if you use incorrect values as the bus is
shared with other peripherals. Yes, correctness is required.
Is that a property of the system known statically, or one determined by
testing the system under particular workloads? It feels like the latter
(though I appreciate that not starving other masters is certainly a
correctness property regardless of how this is derived).
I'd have expected the bus this is plugged into to have appropriate QoS
settings pre-configured so as to avoid starvation, though it sounds like
that's not possible here?
quoted
Are they tuning values?
Correct value is necessary for functioning. I'd consider weight and priority
as the only tuning parameters.
quoted
The latter doesn't really belong in the DT. Given they're writeable from
the driver, it seems like that's what they are...
Good catch. Those should have been read-only. I wanted to be able to export these
information to the userspace app. I'll fix the sysfs to make them read-only.
quoted
quoted
+- channel-reset-timeout-cycles: Channel reset timeout in cycles for this SOC.
I'm not sure what this means. Could you elaborate on this is?
After each reset command, HW starts a timer. This is the time HW waits before it declares
reset failed.
Is that a reset command sent to the HIDMA by the OS, or a reset command
from the HIDMA to something else?
What does it do when it declares a reset as failed?
How can the OS make use of this information? It has no idea of the
clocks input to the HIDMA, so it has no idea how long a cycle is.
Is this programmed by the OS?
Is the particular duration in cycles a requirement of some other agent?
Thanks,
Mark.
From: Sinan Kaya <hidden> Date: 2016-01-18 14:04:38
On 1/18/2016 6:49 AM, Mark Rutland wrote:
quoted
quoted
quoted
+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
Just to check, where do these max-* values come from?
These are HW bus parameters like the burst count and
size of each burst. These values change based on the SoC this IP is in use.
quoted
Are they some correctness requirement of the bus this is attached to?
You can starve other peripherals if you use incorrect values as the bus is
shared with other peripherals. Yes, correctness is required.
Is that a property of the system known statically, or one determined by
testing the system under particular workloads? It feels like the latter
(though I appreciate that not starving other masters is certainly a
correctness property regardless of how this is derived).
It is known statically and is determined through simulations according to the SoC design.
It is later verified on chip. Once verified, these values never change.
Values change from one SoC to another.
I'd have expected the bus this is plugged into to have appropriate QoS
settings pre-configured so as to avoid starvation, though it sounds like
that's not possible here?
There are some very safe values but they are not correct until validated on the chip.
quoted
quoted
Are they tuning values?
Correct value is necessary for functioning. I'd consider weight and priority
as the only tuning parameters.
quoted
The latter doesn't really belong in the DT. Given they're writeable from
the driver, it seems like that's what they are...
Good catch. Those should have been read-only. I wanted to be able to export these
information to the userspace app. I'll fix the sysfs to make them read-only.
quoted
quoted
+- channel-reset-timeout-cycles: Channel reset timeout in cycles for this SOC.
I'm not sure what this means. Could you elaborate on this is?
After each reset command, HW starts a timer. This is the time HW waits before it declares
reset failed.
Is that a reset command sent to the HIDMA by the OS, or a reset command
from the HIDMA to something else?
First one.
As I said on another email, The HIDMA channel driver resets the transfer and event channels
before using them. The reset command is intended for the HIDMA HW itself.
What does it do when it declares a reset as failed?
The channel probe will fail with reset failed message.
How can the OS make use of this information? It has no idea of the
clocks input to the HIDMA, so it has no idea how long a cycle is.
This is a HW parameter. The OS doesn't use timers or any other facility to time correctness.
The HIDMA channel driver issues a reset and then waits for confirmation while polling a status
register. If no confirmation is received, then the HW is assumed broken or incorrectly configured.
The HW channel is removed from the OS access.
Is this programmed by the OS?
The HIDMA management driver programs this value to the HW. It is not consumed by the OS directly.
Is the particular duration in cycles a requirement of some other agent?
It is a requirement of the HW. Not the OS.
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
From: Sinan Kaya <hidden> Date: 2016-01-20 22:19:48
Mark,
On 1/15/2016 11:01 AM, Sinan Kaya wrote:
quoted
I'm concerned with how this is safe, and with the userspace interface.
quoted
e.g. if the user wants to up the QoS for a VM, how to they find the
right channel in sysfs to alter?
The HW supports changing the QoS values on the flight. In order to locate the
object, I'm exporting a
I tried to address your concern on v10 last series. Here is brief summary.
Each channel device has a sysfs entry named chid.
What: /sys/devices/platform/hidma-*/chid
+ /sys/devices/platform/QCOM8061:*/chid
Each management object has one priority and weight file per channel.
+What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority
+ /sys/devices/platform/QCOM8060:*/chanops/chan*/priority
Suppose you want to change the priority of a channel you assigned to guess,
the userspace application goes and reads the chid value of the channel.
Then goes to chanops/chan<chid>/ directory and can change priority and weight
parameters here.
Here is how the directory looks like. QCOM8060:00 is a management object.
QCOM8061:0x are the channel objects.
/sys/devices/platform/QCOM8060:00# ls
QCOM8061:00
QCOM8061:01
QCOM8061:02
QCOM8061:03
QCOM8061:04
QCOM8061:05
chanops
<other common attributes>
Did this answer your question?
I'm capturing all the questions and answers as FAQ into the cover letter as I keep
repeating myself for every single reviewer.
Besides from the "lack of documentation", is there any code related change you'd like to
discuss in the series.
--
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
From: Sinan Kaya <hidden> Date: 2016-01-22 18:39:22
On 1/15/2016 10:22 AM, Mark Rutland wrote:
Typically VFIO-platform also comes with a corresponding reset driver.
You don't need one?
Digging this further, I do need a HIDMA reset driver. The reset driver is useful if HIDMA
operation is aborted in the middle and guest machine is shutdown.
I'm preparing a reset driver and I'll post it soon.
In the meantime, I have observed a lack of ACPI HID support in the platform reset interface
vfio_platform_lookup_reset and vfio_platform_probe_common specifically.
The interface is querying objects with "compatible" string. Of course on a true ACPI system
with proper named HIDs except PRP001, "compatible" attribute does not exist. I'm also preparing a
patch for this too.
Since VFIO patches go through another branch and the reset driver also needs to go through vfio along
with the ACPI object querying support, would you like this to be addressed independently with a different series
or have it reviewed altogether here then figure out the merge path later?
--
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