| Message ID | 1498481369-29497-2-git-send-email-absahu@codeaurora.org (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
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 > }; > > /**
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 >
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
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 >>
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 >> >> >> > }; >> > >> > /** >>
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), >>> }; >>>
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
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), >> >>> }; >> >>> >> -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 > -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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..
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), }; /**
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(+)