[PATCH v2 0/3] Support for QCOM BAM DMA command descriptor

[PATCH v2 0/3] Support for QCOM BAM DMA command descriptor

[Abhishek Sahu]

v2:

1. Added DMA_PREP_CMD flag and used the same for BAM DMA
   command descriptor
2. Removed custom mapping API patches

v1:

https://www.spinics.net/lists/dmaengine/msg12009.html

These patches mainly add the support for QCOM BAM command
descriptor implementing BAM DMA support for some QCOM
peripherals like QPIC NAND/LCD.

The BAM command descriptors perform all register reads and
writes while data descriptors do the actual data transfer.
The QPIC NAND forms the chain of command and data descriptors
for full page read/write and submit it to BAM DMA.

Currently there is no flag in DMA API which tells the DMA
controller that the passed data is in command descriptor
format so added the flag in DMA API for this.

Abhishek Sahu (3):
  dmaengine: add DMA_PREP_CMD for non-Data descriptors.
  dmaengine: qcom: bam_dma: wrapper functions for command descriptor
  dmaengine: qcom: bam_dma: add command descriptor flag

 drivers/dma/qcom/bam_dma.c       |  6 ++-
 include/linux/dma/qcom_bam_dma.h | 79 ++++++++++++++++++++++++++++++++++++++++
 include/linux/dmaengine.h        |  3 ++
 3 files changed, 87 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/dma/qcom_bam_dma.h

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

[PATCH v2 1/3] dmaengine: add DMA_PREP_CMD for non-Data descriptors.

[Abhishek Sahu]

Some of the DMA controllers are capable of issuing the commands
to peripheral by the DMA. These commands can be list of register
reads/writes and its different from normal data reads/writes.
This patch adds new flag DMA_PREP_CMD in DMA API which tells
the driver that the data passed to DMA API is in command format
and DMA driver will form descriptor in the required format.

This flag can be used by any DMA controller driver which requires
special handling for non-Data descriptors.

Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
---
 include/linux/dmaengine.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 5336808..bbc297e 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -186,6 +186,8 @@ struct dma_interleaved_template {
  *  on the result of this operation
  * @DMA_CTRL_REUSE: client can reuse the descriptor and submit again till
  *  cleared or freed
+ * @DMA_PREP_CMD: tell the driver that the data passed to DMA API is in command
+ *  format and it will be used for configuring the peripheral registers.
  */
 enum dma_ctrl_flags {
 	DMA_PREP_INTERRUPT = (1 << 0),
@@ -195,6 +197,7 @@ enum dma_ctrl_flags {
 	DMA_PREP_CONTINUE = (1 << 4),
 	DMA_PREP_FENCE = (1 << 5),
 	DMA_CTRL_REUSE = (1 << 6),
+	DMA_PREP_CMD = (1 << 7),
 };
 
 /**
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v2 2/3] dmaengine: qcom: bam_dma: wrapper functions for command descriptor

[Abhishek Sahu]

QCOM BAM also supports command descriptor which allows the SW to
create descriptors of type command which does not generate any
data transmissions but configures registers in the peripheral.
In command descriptor the 32bit address point to the start of
the command block which holds the command elements and the
16bit size define the size of the command block.

Each Command Element is structured by 4 words:
    Write command: address + cmd
                   register data
                   register mask
                   reserved

    Read command: address + cmd
                  read data result address,
                  reserved
                  reserved

This patch creates a new header file for BAM driver which contains the
structures and wrapper functions for command descriptor. This file will
be used by different QCOM peripheral drivers for forming the command
descriptor

Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
---
 include/linux/dma/qcom_bam_dma.h | 79 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 include/linux/dma/qcom_bam_dma.h

diff --git a/include/linux/dma/qcom_bam_dma.h b/include/linux/dma/qcom_bam_dma.h
new file mode 100644
index 0000000..077d43a
--- /dev/null
+++ b/include/linux/dma/qcom_bam_dma.h
@@ -0,0 +1,79 @@
+/*
+ * Copyright (c) 2016-2017, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _QCOM_BAM_DMA_H
+#define _QCOM_BAM_DMA_H
+
+#include <asm/byteorder.h>
+
+/*
+ * This data type corresponds to the native Command Element
+ * supported by BAM DMA Engine.
+ *
+ * @cmd_and_addr - upper 8 bits command and lower 24 bits register address.
+ * @data - for write command: content to be written into peripheral register.
+ *	   for read command: dest addr to write peripheral register value.
+ * @mask - register mask.
+ * @reserved - for future usage.
+ *
+ */
+struct bam_cmd_element {
+	__le32 cmd_and_addr;
+	__le32 data;
+	__le32 mask;
+	__le32 reserved;
+};
+
+/*
+ * This enum indicates the command type in a command element
+ */
+enum bam_command_type {
+	BAM_WRITE_COMMAND = 0,
+	BAM_READ_COMMAND,
+};
+
+/*
+ * prep_bam_ce_le32 - Wrapper function to prepare a single BAM command
+ * element with the data already in le32 format.
+ *
+ * @bam_ce: bam command element
+ * @addr: target address
+ * @cmd: BAM command
+ * @data: actual data for write and dest addr for read in le32
+ */
+static inline void
+bam_prep_ce_le32(struct bam_cmd_element *bam_ce, u32 addr,
+		 enum bam_command_type cmd, __le32 data)
+{
+	bam_ce->cmd_and_addr =
+		cpu_to_le32((addr & 0xffffff) | ((cmd & 0xff) << 24));
+	bam_ce->data = data;
+	bam_ce->mask = cpu_to_le32(0xffffffff);
+}
+
+/*
+ * bam_prep_ce - Wrapper function to prepare a single BAM command element
+ * with the data.
+ *
+ * @bam_ce: BAM command element
+ * @addr: target address
+ * @cmd: BAM command
+ * @data: actual data for write and dest addr for read
+ */
+static inline void
+bam_prep_ce(struct bam_cmd_element *bam_ce, u32 addr,
+	    enum bam_command_type cmd, u32 data)
+{
+	bam_prep_ce_le32(bam_ce, addr, cmd, cpu_to_le32(data));
+}
+#endif
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v2 3/3] dmaengine: qcom: bam_dma: add command descriptor flag

[Abhishek Sahu]

If DMA_PREP_CMD flag is passed in prep_slave_sg then peripheral
driver has passed the data is in BAM command descriptor format
and BAM driver should set CMD bit for each of the HW descriptors.

Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
---
 drivers/dma/qcom/bam_dma.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
index 03c4eb3..6d89fb6 100644
--- a/drivers/dma/qcom/bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -65,6 +65,7 @@ struct bam_desc_hw {
 #define DESC_FLAG_EOT BIT(14)
 #define DESC_FLAG_EOB BIT(13)
 #define DESC_FLAG_NWD BIT(12)
+#define DESC_FLAG_CMD BIT(11)
 
 struct bam_async_desc {
 	struct virt_dma_desc vd;
@@ -645,6 +646,9 @@ static struct dma_async_tx_descriptor *bam_prep_slave_sg(struct dma_chan *chan,
 		unsigned int curr_offset = 0;
 
 		do {
+			if (flags & DMA_PREP_CMD)
+				desc->flags |= cpu_to_le16(DESC_FLAG_CMD);
+
 			desc->addr = cpu_to_le32(sg_dma_address(sg) +
 						 curr_offset);
 
@@ -960,7 +964,7 @@ static void bam_start_dma(struct bam_chan *bchan)
 
 	/* set any special flags on the last descriptor */
 	if (async_desc->num_desc == async_desc->xfer_len)
-		desc[async_desc->xfer_len - 1].flags =
+		desc[async_desc->xfer_len - 1].flags |=
 					cpu_to_le16(async_desc->flags);
 	else
 		desc[async_desc->xfer_len - 1].flags |=
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v2 1/3] dmaengine: add DMA_PREP_CMD for non-Data descriptors.

[Abhishek Sahu]

On 2017-06-26 18:19, Abhishek Sahu wrote:
> Some of the DMA controllers are capable of issuing the commands
> to peripheral by the DMA. These commands can be list of register
> reads/writes and its different from normal data reads/writes.
> This patch adds new flag DMA_PREP_CMD in DMA API which tells
> the driver that the data passed to DMA API is in command format
> and DMA driver will form descriptor in the required format.
> 
> This flag can be used by any DMA controller driver which requires
> special handling for non-Data descriptors.
> 
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
>  include/linux/dmaengine.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 5336808..bbc297e 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -186,6 +186,8 @@ struct dma_interleaved_template {
>   *  on the result of this operation
>   * @DMA_CTRL_REUSE: client can reuse the descriptor and submit again 
> till
>   *  cleared or freed
> + * @DMA_PREP_CMD: tell the driver that the data passed to DMA API is 
> in command
> + *  format and it will be used for configuring the peripheral 
> registers.
>   */
>  enum dma_ctrl_flags {
>  	DMA_PREP_INTERRUPT = (1 << 0),
> @@ -195,6 +197,7 @@ enum dma_ctrl_flags {
>  	DMA_PREP_CONTINUE = (1 << 4),
>  	DMA_PREP_FENCE = (1 << 5),
>  	DMA_CTRL_REUSE = (1 << 6),
> +	DMA_PREP_CMD = (1 << 7),

Hi Vinod/Dan,

Could you please help in reviewing these DMA patches.
I have posted QPIC NAND support patches which are dependent
upon these DMA patches.

https://www.spinics.net/lists/kernel/msg2545386.html


>  };
> 
>  /**

-- 
Abhishek Sahu

Re: [PATCH v2 1/3] dmaengine: add DMA_PREP_CMD for non-Data descriptors.

[Vinod Koul]

On Mon, Jun 26, 2017 at 06:19:27PM +0530, Abhishek Sahu wrote:
> Some of the DMA controllers are capable of issuing the commands
> to peripheral by the DMA. These commands can be list of register
> reads/writes and its different from normal data reads/writes.
> This patch adds new flag DMA_PREP_CMD in DMA API which tells
> the driver that the data passed to DMA API is in command format
> and DMA driver will form descriptor in the required format.
> 
> This flag can be used by any DMA controller driver which requires
> special handling for non-Data descriptors.

Please add Documentation for this new flag in Documentation/dmaengine/provider.txt

> 
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
>  include/linux/dmaengine.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 5336808..bbc297e 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -186,6 +186,8 @@ struct dma_interleaved_template {
>   *  on the result of this operation
>   * @DMA_CTRL_REUSE: client can reuse the descriptor and submit again till
>   *  cleared or freed
> + * @DMA_PREP_CMD: tell the driver that the data passed to DMA API is in command
> + *  format and it will be used for configuring the peripheral registers.

Can you explain what is command format..?

>   */
>  enum dma_ctrl_flags {
>  	DMA_PREP_INTERRUPT = (1 << 0),
> @@ -195,6 +197,7 @@ enum dma_ctrl_flags {
>  	DMA_PREP_CONTINUE = (1 << 4),
>  	DMA_PREP_FENCE = (1 << 5),
>  	DMA_CTRL_REUSE = (1 << 6),
> +	DMA_PREP_CMD = (1 << 7),
>  };
>  
>  /**
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
> 

-- 
~Vinod

Re: [PATCH v2 2/3] dmaengine: qcom: bam_dma: wrapper functions for command descriptor

[Vinod Koul]

On Mon, Jun 26, 2017 at 06:19:28PM +0530, Abhishek Sahu wrote:
> QCOM BAM also supports command descriptor which allows the SW to
> create descriptors of type command which does not generate any
> data transmissions but configures registers in the peripheral.
> In command descriptor the 32bit address point to the start of
> the command block which holds the command elements and the
> 16bit size define the size of the command block.
> 
> Each Command Element is structured by 4 words:
>     Write command: address + cmd
>                    register data
>                    register mask
>                    reserved
> 
>     Read command: address + cmd
>                   read data result address,
>                   reserved
>                   reserved
> 
> This patch creates a new header file for BAM driver which contains the
> structures and wrapper functions for command descriptor. This file will
> be used by different QCOM peripheral drivers for forming the command
> descriptor
> 
> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> ---
>  include/linux/dma/qcom_bam_dma.h | 79 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 79 insertions(+)
>  create mode 100644 include/linux/dma/qcom_bam_dma.h
> 
> diff --git a/include/linux/dma/qcom_bam_dma.h b/include/linux/dma/qcom_bam_dma.h
> new file mode 100644
> index 0000000..077d43a
> --- /dev/null
> +++ b/include/linux/dma/qcom_bam_dma.h
> @@ -0,0 +1,79 @@
> +/*
> + * Copyright (c) 2016-2017, The Linux Foundation. All rights reserved.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef _QCOM_BAM_DMA_H
> +#define _QCOM_BAM_DMA_H
> +
> +#include <asm/byteorder.h>
> +
> +/*
> + * This data type corresponds to the native Command Element
> + * supported by BAM DMA Engine.
> + *
> + * @cmd_and_addr - upper 8 bits command and lower 24 bits register address.
> + * @data - for write command: content to be written into peripheral register.
> + *	   for read command: dest addr to write peripheral register value.
> + * @mask - register mask.
> + * @reserved - for future usage.
> + *
> + */
> +struct bam_cmd_element {
> +	__le32 cmd_and_addr;
> +	__le32 data;
> +	__le32 mask;
> +	__le32 reserved;
> +};
> +
> +/*
> + * This enum indicates the command type in a command element
> + */
> +enum bam_command_type {
> +	BAM_WRITE_COMMAND = 0,
> +	BAM_READ_COMMAND,
> +};
> +
> +/*
> + * prep_bam_ce_le32 - Wrapper function to prepare a single BAM command
> + * element with the data already in le32 format.
> + *
> + * @bam_ce: bam command element
> + * @addr: target address
> + * @cmd: BAM command
> + * @data: actual data for write and dest addr for read in le32
> + */
> +static inline void
> +bam_prep_ce_le32(struct bam_cmd_element *bam_ce, u32 addr,
> +		 enum bam_command_type cmd, __le32 data)
> +{
> +	bam_ce->cmd_and_addr =
> +		cpu_to_le32((addr & 0xffffff) | ((cmd & 0xff) << 24));
> +	bam_ce->data = data;
> +	bam_ce->mask = cpu_to_le32(0xffffffff);
> +}

Is this being used by clients?

> +
> +/*
> + * bam_prep_ce - Wrapper function to prepare a single BAM command element
> + * with the data.
> + *
> + * @bam_ce: BAM command element
> + * @addr: target address
> + * @cmd: BAM command
> + * @data: actual data for write and dest addr for read
> + */
> +static inline void
> +bam_prep_ce(struct bam_cmd_element *bam_ce, u32 addr,
> +	    enum bam_command_type cmd, u32 data)
> +{
> +	bam_prep_ce_le32(bam_ce, addr, cmd, cpu_to_le32(data));
> +}
> +#endif
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
> 

-- 
~Vinod

Re: [PATCH v2 1/3] dmaengine: add DMA_PREP_CMD for non-Data descriptors.

[Vinod Koul]

On Mon, Jul 17, 2017 at 02:54:21PM +0530, Abhishek Sahu wrote:
> On 2017-06-26 18:19, Abhishek Sahu wrote:
> >Some of the DMA controllers are capable of issuing the commands
> >to peripheral by the DMA. These commands can be list of register
> >reads/writes and its different from normal data reads/writes.
> >This patch adds new flag DMA_PREP_CMD in DMA API which tells
> >the driver that the data passed to DMA API is in command format
> >and DMA driver will form descriptor in the required format.
> >
> >This flag can be used by any DMA controller driver which requires
> >special handling for non-Data descriptors.
> >
> >Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> >---
> > include/linux/dmaengine.h | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> >diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> >index 5336808..bbc297e 100644
> >--- a/include/linux/dmaengine.h
> >+++ b/include/linux/dmaengine.h
> >@@ -186,6 +186,8 @@ struct dma_interleaved_template {
> >  *  on the result of this operation
> >  * @DMA_CTRL_REUSE: client can reuse the descriptor and submit again till
> >  *  cleared or freed
> >+ * @DMA_PREP_CMD: tell the driver that the data passed to DMA API is in
> >command
> >+ *  format and it will be used for configuring the peripheral registers.
> >  */
> > enum dma_ctrl_flags {
> > 	DMA_PREP_INTERRUPT = (1 << 0),
> >@@ -195,6 +197,7 @@ enum dma_ctrl_flags {
> > 	DMA_PREP_CONTINUE = (1 << 4),
> > 	DMA_PREP_FENCE = (1 << 5),
> > 	DMA_CTRL_REUSE = (1 << 6),
> >+	DMA_PREP_CMD = (1 << 7),
> 
> Hi Vinod/Dan,
> 
> Could you please help in reviewing these DMA patches.
> I have posted QPIC NAND support patches which are dependent
> upon these DMA patches.

Please allow reasonable time for review! This patch series was sent just
before the merge window and it closed couple of days back!!

> 
> https://www.spinics.net/lists/kernel/msg2545386.html
> 
> 
> > };
> >
> > /**
> 
> -- 
> Abhishek Sahu

-- 
~Vinod

Re: [PATCH v2 2/3] dmaengine: qcom: bam_dma: wrapper functions for command descriptor

[Abhishek Sahu]

On 2017-07-19 15:39, Vinod Koul wrote:
> On Mon, Jun 26, 2017 at 06:19:28PM +0530, Abhishek Sahu wrote:
>> QCOM BAM also supports command descriptor which allows the SW to
>> create descriptors of type command which does not generate any
>> data transmissions but configures registers in the peripheral.
>> In command descriptor the 32bit address point to the start of
>> the command block which holds the command elements and the
>> 16bit size define the size of the command block.
>> 
>> Each Command Element is structured by 4 words:
>>     Write command: address + cmd
>>                    register data
>>                    register mask
>>                    reserved
>> 
>>     Read command: address + cmd
>>                   read data result address,
>>                   reserved
>>                   reserved
>> 
>> This patch creates a new header file for BAM driver which contains the
>> structures and wrapper functions for command descriptor. This file 
>> will
>> be used by different QCOM peripheral drivers for forming the command
>> descriptor
>> 
>> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
>> ---
>>  include/linux/dma/qcom_bam_dma.h | 79 
>> ++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 79 insertions(+)
>>  create mode 100644 include/linux/dma/qcom_bam_dma.h
>> 
>> diff --git a/include/linux/dma/qcom_bam_dma.h 
>> b/include/linux/dma/qcom_bam_dma.h
>> new file mode 100644
>> index 0000000..077d43a
>> --- /dev/null
>> +++ b/include/linux/dma/qcom_bam_dma.h
>> @@ -0,0 +1,79 @@
>> +/*
>> + * Copyright (c) 2016-2017, The Linux Foundation. All rights 
>> reserved.
>> + *
>> + * This software is licensed under the terms of the GNU General 
>> Public
>> + * License version 2, as published by the Free Software Foundation, 
>> and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#ifndef _QCOM_BAM_DMA_H
>> +#define _QCOM_BAM_DMA_H
>> +
>> +#include <asm/byteorder.h>
>> +
>> +/*
>> + * This data type corresponds to the native Command Element
>> + * supported by BAM DMA Engine.
>> + *
>> + * @cmd_and_addr - upper 8 bits command and lower 24 bits register 
>> address.
>> + * @data - for write command: content to be written into peripheral 
>> register.
>> + *	   for read command: dest addr to write peripheral register value.
>> + * @mask - register mask.
>> + * @reserved - for future usage.
>> + *
>> + */
>> +struct bam_cmd_element {
>> +	__le32 cmd_and_addr;
>> +	__le32 data;
>> +	__le32 mask;
>> +	__le32 reserved;
>> +};
>> +
>> +/*
>> + * This enum indicates the command type in a command element
>> + */
>> +enum bam_command_type {
>> +	BAM_WRITE_COMMAND = 0,
>> +	BAM_READ_COMMAND,
>> +};
>> +
>> +/*
>> + * prep_bam_ce_le32 - Wrapper function to prepare a single BAM 
>> command
>> + * element with the data already in le32 format.
>> + *
>> + * @bam_ce: bam command element
>> + * @addr: target address
>> + * @cmd: BAM command
>> + * @data: actual data for write and dest addr for read in le32
>> + */
>> +static inline void
>> +bam_prep_ce_le32(struct bam_cmd_element *bam_ce, u32 addr,
>> +		 enum bam_command_type cmd, __le32 data)
>> +{
>> +	bam_ce->cmd_and_addr =
>> +		cpu_to_le32((addr & 0xffffff) | ((cmd & 0xff) << 24));
>> +	bam_ce->data = data;
>> +	bam_ce->mask = cpu_to_le32(0xffffffff);
>> +}
> 
> Is this being used by clients?
> 

  Yes Vinod. This wrapper function will be called by clients.
  NAND driver will call this function for reading/writing
  registers from BAM DMA.

  Following is the NAND client driver patch
  http://www.spinics.net/lists/devicetree/msg183713.html

>> +
>> +/*
>> + * bam_prep_ce - Wrapper function to prepare a single BAM command 
>> element
>> + * with the data.
>> + *
>> + * @bam_ce: BAM command element
>> + * @addr: target address
>> + * @cmd: BAM command
>> + * @data: actual data for write and dest addr for read
>> + */
>> +static inline void
>> +bam_prep_ce(struct bam_cmd_element *bam_ce, u32 addr,
>> +	    enum bam_command_type cmd, u32 data)
>> +{
>> +	bam_prep_ce_le32(bam_ce, addr, cmd, cpu_to_le32(data));
>> +}
>> +#endif
>> --
>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
>> member of Code Aurora Forum, hosted by The Linux Foundation
>> 

-- 
Abhishek Sahu

Re: [PATCH v2 1/3] dmaengine: add DMA_PREP_CMD for non-Data descriptors.

[Abhishek Sahu]

On 2017-07-19 15:37, Vinod Koul wrote:
> On Mon, Jun 26, 2017 at 06:19:27PM +0530, Abhishek Sahu wrote:
>> Some of the DMA controllers are capable of issuing the commands
>> to peripheral by the DMA. These commands can be list of register
>> reads/writes and its different from normal data reads/writes.
>> This patch adds new flag DMA_PREP_CMD in DMA API which tells
>> the driver that the data passed to DMA API is in command format
>> and DMA driver will form descriptor in the required format.
>> 
>> This flag can be used by any DMA controller driver which requires
>> special handling for non-Data descriptors.
> 
> Please add Documentation for this new flag in
> Documentation/dmaengine/provider.txt
> 

  Sure. I will add update the documentation in v3.

>> 
>> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
>> ---
>>  include/linux/dmaengine.h | 3 +++
>>  1 file changed, 3 insertions(+)
>> 
>> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
>> index 5336808..bbc297e 100644
>> --- a/include/linux/dmaengine.h
>> +++ b/include/linux/dmaengine.h
>> @@ -186,6 +186,8 @@ struct dma_interleaved_template {
>>   *  on the result of this operation
>>   * @DMA_CTRL_REUSE: client can reuse the descriptor and submit again 
>> till
>>   *  cleared or freed
>> + * @DMA_PREP_CMD: tell the driver that the data passed to DMA API is 
>> in command
>> + *  format and it will be used for configuring the peripheral 
>> registers.
> 
> Can you explain what is command format..?
> 

  The command format is not generic and its format will be dependent
  upon DMA engine. The client drivers will give data in its own
  command formats and this flag will be passed to DMA API’s to do
  the parsing according to its own command format.

  Currently this flag description and name is inclined towards
  Qualcomm BAM DMA command flag. We want to make this flag as
  generic one so require your suggestion regarding this.
  Will renaming this flag as DMA_PREP_NON_DATA or
  DMA_PREP_CUSTOM make it more generic?

>>   */
>>  enum dma_ctrl_flags {
>>  	DMA_PREP_INTERRUPT = (1 << 0),
>> @@ -195,6 +197,7 @@ enum dma_ctrl_flags {
>>  	DMA_PREP_CONTINUE = (1 << 4),
>>  	DMA_PREP_FENCE = (1 << 5),
>>  	DMA_CTRL_REUSE = (1 << 6),
>> +	DMA_PREP_CMD = (1 << 7),
>>  };
>> 
>>  /**
>> --
>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
>> member of Code Aurora Forum, hosted by The Linux Foundation
>> 

-- 
Abhishek Sahu

Re: [PATCH v2 1/3] dmaengine: add DMA_PREP_CMD for non-Data descriptors.

[Abhishek Sahu]

On 2017-07-19 15:41, Vinod Koul wrote:
> On Mon, Jul 17, 2017 at 02:54:21PM +0530, Abhishek Sahu wrote:
>> On 2017-06-26 18:19, Abhishek Sahu wrote:
>> >Some of the DMA controllers are capable of issuing the commands
>> >to peripheral by the DMA. These commands can be list of register
>> >reads/writes and its different from normal data reads/writes.
>> >This patch adds new flag DMA_PREP_CMD in DMA API which tells
>> >the driver that the data passed to DMA API is in command format
>> >and DMA driver will form descriptor in the required format.
>> >
>> >This flag can be used by any DMA controller driver which requires
>> >special handling for non-Data descriptors.
>> >
>> >Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
>> >---
>> > include/linux/dmaengine.h | 3 +++
>> > 1 file changed, 3 insertions(+)
>> >
>> >diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
>> >index 5336808..bbc297e 100644
>> >--- a/include/linux/dmaengine.h
>> >+++ b/include/linux/dmaengine.h
>> >@@ -186,6 +186,8 @@ struct dma_interleaved_template {
>> >  *  on the result of this operation
>> >  * @DMA_CTRL_REUSE: client can reuse the descriptor and submit again till
>> >  *  cleared or freed
>> >+ * @DMA_PREP_CMD: tell the driver that the data passed to DMA API is in
>> >command
>> >+ *  format and it will be used for configuring the peripheral registers.
>> >  */
>> > enum dma_ctrl_flags {
>> > 	DMA_PREP_INTERRUPT = (1 << 0),
>> >@@ -195,6 +197,7 @@ enum dma_ctrl_flags {
>> > 	DMA_PREP_CONTINUE = (1 << 4),
>> > 	DMA_PREP_FENCE = (1 << 5),
>> > 	DMA_CTRL_REUSE = (1 << 6),
>> >+	DMA_PREP_CMD = (1 << 7),
>> 
>> Hi Vinod/Dan,
>> 
>> Could you please help in reviewing these DMA patches.
>> I have posted QPIC NAND support patches which are dependent
>> upon these DMA patches.
> 
> Please allow reasonable time for review! This patch series was sent 
> just
> before the merge window and it closed couple of days back!!
> 

  Sure Vinod and extremely sorry for my ping.

  Since we are adding the flag in generic DMA engine and the complete
  QPIC NAND support patch series dependent upon this so we were
  bit concerned about this patch.

>> 
>> https://www.spinics.net/lists/kernel/msg2545386.html
>> 
>> 
>> > };
>> >
>> > /**
>> 

-- 
Abhishek Sahu

Re: [PATCH v2 1/3] dmaengine: add DMA_PREP_CMD for non-Data descriptors.

[Abhishek Sahu]

On 2017-07-19 17:48, Abhishek Sahu wrote:
> On 2017-07-19 15:37, Vinod Koul wrote:
>> On Mon, Jun 26, 2017 at 06:19:27PM +0530, Abhishek Sahu wrote:
>>> Some of the DMA controllers are capable of issuing the commands
>>> to peripheral by the DMA. These commands can be list of register
>>> reads/writes and its different from normal data reads/writes.
>>> This patch adds new flag DMA_PREP_CMD in DMA API which tells
>>> the driver that the data passed to DMA API is in command format
>>> and DMA driver will form descriptor in the required format.
>>> 
>>> This flag can be used by any DMA controller driver which requires
>>> special handling for non-Data descriptors.
>> 
>> Please add Documentation for this new flag in
>> Documentation/dmaengine/provider.txt
>> 
> 
>  Sure. I will add update the documentation in v3.
> 
>>> 
>>> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
>>> ---
>>>  include/linux/dmaengine.h | 3 +++
>>>  1 file changed, 3 insertions(+)
>>> 
>>> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
>>> index 5336808..bbc297e 100644
>>> --- a/include/linux/dmaengine.h
>>> +++ b/include/linux/dmaengine.h
>>> @@ -186,6 +186,8 @@ struct dma_interleaved_template {
>>>   *  on the result of this operation
>>>   * @DMA_CTRL_REUSE: client can reuse the descriptor and submit again 
>>> till
>>>   *  cleared or freed
>>> + * @DMA_PREP_CMD: tell the driver that the data passed to DMA API is 
>>> in command
>>> + *  format and it will be used for configuring the peripheral 
>>> registers.
>> 
>> Can you explain what is command format..?
>> 
> 
>  The command format is not generic and its format will be dependent
>  upon DMA engine. The client drivers will give data in its own
>  command formats and this flag will be passed to DMA API’s to do
>  the parsing according to its own command format.
> 
>  Currently this flag description and name is inclined towards
>  Qualcomm BAM DMA command flag. We want to make this flag as
>  generic one so require your suggestion regarding this.
>  Will renaming this flag as DMA_PREP_NON_DATA or
>  DMA_PREP_CUSTOM make it more generic?
> 

  can we use same flag name DMA_PREP_CMD or should we
  go for some other name?

>>>   */
>>>  enum dma_ctrl_flags {
>>>  	DMA_PREP_INTERRUPT = (1 << 0),
>>> @@ -195,6 +197,7 @@ enum dma_ctrl_flags {
>>>  	DMA_PREP_CONTINUE = (1 << 4),
>>>  	DMA_PREP_FENCE = (1 << 5),
>>>  	DMA_CTRL_REUSE = (1 << 6),
>>> +	DMA_PREP_CMD = (1 << 7),
>>>  };
>>> 


-- 
Abhishek Sahu

Re: [PATCH v2 1/3] dmaengine: add DMA_PREP_CMD for non-Data descriptors.

[Vinod Koul]

On Fri, Jul 28, 2017 at 09:38:56PM +0530, Abhishek Sahu wrote:
> On 2017-07-19 17:48, Abhishek Sahu wrote:
> >On 2017-07-19 15:37, Vinod Koul wrote:
> >>On Mon, Jun 26, 2017 at 06:19:27PM +0530, Abhishek Sahu wrote:
> >>>Some of the DMA controllers are capable of issuing the commands
> >>>to peripheral by the DMA. These commands can be list of register
> >>>reads/writes and its different from normal data reads/writes.
> >>>This patch adds new flag DMA_PREP_CMD in DMA API which tells
> >>>the driver that the data passed to DMA API is in command format
> >>>and DMA driver will form descriptor in the required format.
> >>>
> >>>This flag can be used by any DMA controller driver which requires
> >>>special handling for non-Data descriptors.
> >>
> >>Please add Documentation for this new flag in
> >>Documentation/dmaengine/provider.txt
> >>
> >
> > Sure. I will add update the documentation in v3.
> >
> >>>
> >>>Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
> >>>---
> >>> include/linux/dmaengine.h | 3 +++
> >>> 1 file changed, 3 insertions(+)
> >>>
> >>>diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> >>>index 5336808..bbc297e 100644
> >>>--- a/include/linux/dmaengine.h
> >>>+++ b/include/linux/dmaengine.h
> >>>@@ -186,6 +186,8 @@ struct dma_interleaved_template {
> >>>  *  on the result of this operation
> >>>  * @DMA_CTRL_REUSE: client can reuse the descriptor and submit again
> >>>till
> >>>  *  cleared or freed
> >>>+ * @DMA_PREP_CMD: tell the driver that the data passed to DMA API is
> >>>in command
> >>>+ *  format and it will be used for configuring the peripheral
> >>>registers.
> >>
> >>Can you explain what is command format..?
> >>
> >
> > The command format is not generic and its format will be dependent
> > upon DMA engine. The client drivers will give data in its own
> > command formats and this flag will be passed to DMA API’s to do
> > the parsing according to its own command format.
> >
> > Currently this flag description and name is inclined towards
> > Qualcomm BAM DMA command flag. We want to make this flag as
> > generic one so require your suggestion regarding this.
> > Will renaming this flag as DMA_PREP_NON_DATA or
> > DMA_PREP_CUSTOM make it more generic?
> >
> 
>  can we use same flag name DMA_PREP_CMD or should we
>  go for some other name?

Are you asking for using DMA_PREP_CMD, for that I think should be ok

If you asking about adding a new flag with DMA_PREP_CMD, then it would no

> 
> >>>  */
> >>> enum dma_ctrl_flags {
> >>> 	DMA_PREP_INTERRUPT = (1 << 0),
> >>>@@ -195,6 +197,7 @@ enum dma_ctrl_flags {
> >>> 	DMA_PREP_CONTINUE = (1 << 4),
> >>> 	DMA_PREP_FENCE = (1 << 5),
> >>> 	DMA_CTRL_REUSE = (1 << 6),
> >>>+	DMA_PREP_CMD = (1 << 7),
> >>> };
> >>>
> 
> 
> -- 
> Abhishek Sahu

-- 
~Vinod

Re: [PATCH v2 1/3] dmaengine: add DMA_PREP_CMD for non-Data descriptors.

[Abhishek Sahu]

On 2017-07-31 18:04, Vinod Koul wrote:
> On Fri, Jul 28, 2017 at 09:38:56PM +0530, Abhishek Sahu wrote:
>> On 2017-07-19 17:48, Abhishek Sahu wrote:
>> >On 2017-07-19 15:37, Vinod Koul wrote:
>> >>On Mon, Jun 26, 2017 at 06:19:27PM +0530, Abhishek Sahu wrote:
>> >>>Some of the DMA controllers are capable of issuing the commands
>> >>>to peripheral by the DMA. These commands can be list of register
>> >>>reads/writes and its different from normal data reads/writes.
>> >>>This patch adds new flag DMA_PREP_CMD in DMA API which tells
>> >>>the driver that the data passed to DMA API is in command format
>> >>>and DMA driver will form descriptor in the required format.
>> >>>
>> >>>This flag can be used by any DMA controller driver which requires
>> >>>special handling for non-Data descriptors.
>> >>
>> >>Please add Documentation for this new flag in
>> >>Documentation/dmaengine/provider.txt
>> >>
>> >
>> > Sure. I will add update the documentation in v3.
>> >
>> >>>
>> >>>Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
>> >>>---
>> >>> include/linux/dmaengine.h | 3 +++
>> >>> 1 file changed, 3 insertions(+)
>> >>>
>> >>>diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
>> >>>index 5336808..bbc297e 100644
>> >>>--- a/include/linux/dmaengine.h
>> >>>+++ b/include/linux/dmaengine.h
>> >>>@@ -186,6 +186,8 @@ struct dma_interleaved_template {
>> >>>  *  on the result of this operation
>> >>>  * @DMA_CTRL_REUSE: client can reuse the descriptor and submit again
>> >>>till
>> >>>  *  cleared or freed
>> >>>+ * @DMA_PREP_CMD: tell the driver that the data passed to DMA API is
>> >>>in command
>> >>>+ *  format and it will be used for configuring the peripheral
>> >>>registers.
>> >>
>> >>Can you explain what is command format..?
>> >>
>> >
>> > The command format is not generic and its format will be dependent
>> > upon DMA engine. The client drivers will give data in its own
>> > command formats and this flag will be passed to DMA API’s to do
>> > the parsing according to its own command format.
>> >
>> > Currently this flag description and name is inclined towards
>> > Qualcomm BAM DMA command flag. We want to make this flag as
>> > generic one so require your suggestion regarding this.
>> > Will renaming this flag as DMA_PREP_NON_DATA or
>> > DMA_PREP_CUSTOM make it more generic?
>> >
>> 
>>  can we use same flag name DMA_PREP_CMD or should we
>>  go for some other name?
> 
> Are you asking for using DMA_PREP_CMD, for that I think should be ok
> 
> If you asking about adding a new flag with DMA_PREP_CMD, then it would 
> no
> 

  Thanks Vinod.

  We just want to add only one flag with name DMA_PREP_CMD and no
  other new flag.

  I will update the description for DMA_PREP_CMD in
  Documentation/dmaengine/provider.txt

>> 
>> >>>  */
>> >>> enum dma_ctrl_flags {
>> >>> 	DMA_PREP_INTERRUPT = (1 << 0),
>> >>>@@ -195,6 +197,7 @@ enum dma_ctrl_flags {
>> >>> 	DMA_PREP_CONTINUE = (1 << 4),
>> >>> 	DMA_PREP_FENCE = (1 << 5),
>> >>> 	DMA_CTRL_REUSE = (1 << 6),
>> >>>+	DMA_PREP_CMD = (1 << 7),
>> >>> };
>> >>>
>> 

Re: [PATCH v2 1/3] dmaengine: add DMA_PREP_CMD for non-Data descriptors.

[Dave Jiang]

On 07/31/2017 05:34 AM, Vinod Koul wrote:
> On Fri, Jul 28, 2017 at 09:38:56PM +0530, Abhishek Sahu wrote:
>> On 2017-07-19 17:48, Abhishek Sahu wrote:
>>> On 2017-07-19 15:37, Vinod Koul wrote:
>>>> On Mon, Jun 26, 2017 at 06:19:27PM +0530, Abhishek Sahu wrote:
>>>>> Some of the DMA controllers are capable of issuing the commands
>>>>> to peripheral by the DMA. These commands can be list of register
>>>>> reads/writes and its different from normal data reads/writes.
>>>>> This patch adds new flag DMA_PREP_CMD in DMA API which tells
>>>>> the driver that the data passed to DMA API is in command format
>>>>> and DMA driver will form descriptor in the required format.
>>>>>
>>>>> This flag can be used by any DMA controller driver which requires
>>>>> special handling for non-Data descriptors.
>>>>
>>>> Please add Documentation for this new flag in
>>>> Documentation/dmaengine/provider.txt
>>>>
>>>
>>> Sure. I will add update the documentation in v3.
>>>
>>>>>
>>>>> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
>>>>> ---
>>>>> include/linux/dmaengine.h | 3 +++
>>>>> 1 file changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
>>>>> index 5336808..bbc297e 100644
>>>>> --- a/include/linux/dmaengine.h
>>>>> +++ b/include/linux/dmaengine.h
>>>>> @@ -186,6 +186,8 @@ struct dma_interleaved_template {
>>>>>  *  on the result of this operation
>>>>>  * @DMA_CTRL_REUSE: client can reuse the descriptor and submit again
>>>>> till
>>>>>  *  cleared or freed
>>>>> + * @DMA_PREP_CMD: tell the driver that the data passed to DMA API is
>>>>> in command
>>>>> + *  format and it will be used for configuring the peripheral
>>>>> registers.
>>>>
>>>> Can you explain what is command format..?
>>>>
>>>
>>> The command format is not generic and its format will be dependent
>>> upon DMA engine. The client drivers will give data in its own
>>> command formats and this flag will be passed to DMA API’s to do
>>> the parsing according to its own command format.
>>>
>>> Currently this flag description and name is inclined towards
>>> Qualcomm BAM DMA command flag. We want to make this flag as
>>> generic one so require your suggestion regarding this.
>>> Will renaming this flag as DMA_PREP_NON_DATA or
>>> DMA_PREP_CUSTOM make it more generic?
>>>
>>
>>  can we use same flag name DMA_PREP_CMD or should we
>>  go for some other name?
> 
> Are you asking for using DMA_PREP_CMD, for that I think should be ok
> 
> If you asking about adding a new flag with DMA_PREP_CMD, then it would no

Vinod, I wonder if we should introduce a DMA_PREP_CUSTOM flag and then
reserve X number of upper flag bits to vendor specified that only they
care about. That way they can define whatever they want in the upper
bits if they need it.


> 
>>
>>>>>  */
>>>>> enum dma_ctrl_flags {
>>>>> 	DMA_PREP_INTERRUPT = (1 << 0),
>>>>> @@ -195,6 +197,7 @@ enum dma_ctrl_flags {
>>>>> 	DMA_PREP_CONTINUE = (1 << 4),
>>>>> 	DMA_PREP_FENCE = (1 << 5),
>>>>> 	DMA_CTRL_REUSE = (1 << 6),
>>>>> +	DMA_PREP_CMD = (1 << 7),
>>>>> };
>>>>>
>>
>>
>> -- 
>> Abhishek Sahu
> 

Re: [PATCH v2 1/3] dmaengine: add DMA_PREP_CMD for non-Data descriptors.

[Vinod Koul]

On Mon, Jul 31, 2017 at 09:35:53AM -0700, Dave Jiang wrote:
> On 07/31/2017 05:34 AM, Vinod Koul wrote:

> > 
> > Are you asking for using DMA_PREP_CMD, for that I think should be ok
> > 
> > If you asking about adding a new flag with DMA_PREP_CMD, then it would no
> 
> Vinod, I wonder if we should introduce a DMA_PREP_CUSTOM flag and then
> reserve X number of upper flag bits to vendor specified that only they
> care about. That way they can define whatever they want in the upper
> bits if they need it.

Nah, that just leads to abuse :( So lets keep adding the flags generically
as and when we need them..

-- 
~Vinod