Re: [PATCH v2 1/3] dmaengine: add DMA_PREP_CMD for non-Data descriptors.
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
Re: [PATCH v2 1/3] dmaengine: add DMA_PREP_CMD for non-Data descriptors.
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
> ---
> 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.
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
>>>---
>>> 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.
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
> >>>---
> >>> 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.
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
---
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.
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
>---
> 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.
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
---
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.
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
> >---
> > 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 1/3] dmaengine: add DMA_PREP_CMD for non-Data descriptors.
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
> ---
> 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 1/3] dmaengine: add DMA_PREP_CMD for non-Data descriptors.
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
---
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
