Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()

2013-01-09 Thread Matt Porter 
On Wed, Oct 24, 2012 at 08:43:27AM +0530, Vinod Koul wrote:
> On Tue, 2012-10-23 at 23:49 +0100, Grant Likely wrote:
> > > +enum dmaengine_apis {
> > > +   DMAENGINE_MEMCPY= 0x0001,
> > > +   DMAENGINE_XOR   = 0x0002,
> > > +   DMAENGINE_XOR_VAL   = 0x0004,
> > > +   DMAENGINE_PQ= 0x0008,
> > > +   DMAENGINE_PQ_VAL= 0x0010,
> > > +   DMAENGINE_MEMSET= 0x0020,
> > > +   DMAENGINE_SLAVE = 0x0040,
> > > +   DMAENGINE_CYCLIC= 0x0080,
> > > +   DMAENGINE_INTERLEAVED   = 0x0100,
> > > +   DMAENGINE_SG= 0x0200,
> > > +};
> > 
> > Actually, one more comment. Why the new enum? Why can't the
> > dma_transaction_type enum be used directly along with dma_cap_mask_t? 
> Some of the capabilities above are not there in dma_caps_t like DMA_SG.
> Also DMA_INTERRUPT and DMA_PRIVATE would not make much sense here.
> 
> BUT would help to keep things simpler if have one definition which
> includes all.

All good points. I think we can best eliminate this redundant set of 
enums by using dma_cap_mask_t and noting in a comment as follows:

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 0181887..9add5ca 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -391,14 +391,15 @@ enum dmaengine_apis {
  * a) APIs/ops supported
  * b) channel physical capabilities
  *
- * @ops: or'ed api capability
+ * @cap_mask: api/ops capability (DMA_INTERRUPT and DMA_PRIVATE
+ *are invalid api/ops and will never be set)
  * @seg_nr: maximum number of SG segments supported on a SG/SLAVE
  * channel (0 for no maximum or not a SG/SLAVE channel)
  * @seg_len: maximum length of SG segments supported on a SG/SLAVE
  *  channel (0 for no maximum or not a SG/SLAVE channel)
  */
 struct dmaengine_chan_caps {
-   enum dmaengine_apis ops;
+   dma_cap_mask_t cap_mask;
int seg_nr;
int seg_len;
 };

If that sounds good I'll send an updated series with this change.

-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()

2013-01-09 Thread Matt Porter 
On Wed, Oct 24, 2012 at 08:43:27AM +0530, Vinod Koul wrote:
 On Tue, 2012-10-23 at 23:49 +0100, Grant Likely wrote:
   +enum dmaengine_apis {
   +   DMAENGINE_MEMCPY= 0x0001,
   +   DMAENGINE_XOR   = 0x0002,
   +   DMAENGINE_XOR_VAL   = 0x0004,
   +   DMAENGINE_PQ= 0x0008,
   +   DMAENGINE_PQ_VAL= 0x0010,
   +   DMAENGINE_MEMSET= 0x0020,
   +   DMAENGINE_SLAVE = 0x0040,
   +   DMAENGINE_CYCLIC= 0x0080,
   +   DMAENGINE_INTERLEAVED   = 0x0100,
   +   DMAENGINE_SG= 0x0200,
   +};
  
  Actually, one more comment. Why the new enum? Why can't the
  dma_transaction_type enum be used directly along with dma_cap_mask_t? 
 Some of the capabilities above are not there in dma_caps_t like DMA_SG.
 Also DMA_INTERRUPT and DMA_PRIVATE would not make much sense here.
 
 BUT would help to keep things simpler if have one definition which
 includes all.

All good points. I think we can best eliminate this redundant set of 
enums by using dma_cap_mask_t and noting in a comment as follows:

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 0181887..9add5ca 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -391,14 +391,15 @@ enum dmaengine_apis {
  * a) APIs/ops supported
  * b) channel physical capabilities
  *
- * @ops: or'ed api capability
+ * @cap_mask: api/ops capability (DMA_INTERRUPT and DMA_PRIVATE
+ *are invalid api/ops and will never be set)
  * @seg_nr: maximum number of SG segments supported on a SG/SLAVE
  * channel (0 for no maximum or not a SG/SLAVE channel)
  * @seg_len: maximum length of SG segments supported on a SG/SLAVE
  *  channel (0 for no maximum or not a SG/SLAVE channel)
  */
 struct dmaengine_chan_caps {
-   enum dmaengine_apis ops;
+   dma_cap_mask_t cap_mask;
int seg_nr;
int seg_len;
 };

If that sounds good I'll send an updated series with this change.

-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()

2012-10-23 Thread Vinod Koul 
On Tue, 2012-10-23 at 23:49 +0100, Grant Likely wrote:
> > +enum dmaengine_apis {
> > +   DMAENGINE_MEMCPY= 0x0001,
> > +   DMAENGINE_XOR   = 0x0002,
> > +   DMAENGINE_XOR_VAL   = 0x0004,
> > +   DMAENGINE_PQ= 0x0008,
> > +   DMAENGINE_PQ_VAL= 0x0010,
> > +   DMAENGINE_MEMSET= 0x0020,
> > +   DMAENGINE_SLAVE = 0x0040,
> > +   DMAENGINE_CYCLIC= 0x0080,
> > +   DMAENGINE_INTERLEAVED   = 0x0100,
> > +   DMAENGINE_SG= 0x0200,
> > +};
> 
> Actually, one more comment. Why the new enum? Why can't the
> dma_transaction_type enum be used directly along with dma_cap_mask_t? 
Some of the capabilities above are not there in dma_caps_t like DMA_SG.
Also DMA_INTERRUPT and DMA_PRIVATE would not make much sense here.

BUT would help to keep things simpler if have one definition which
includes all.
 
-- 
Vinod Koul
Intel Corp.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()

2012-10-23 Thread Vinod Koul 
On Tue, 2012-10-23 at 15:54 -0700, Dan Williams wrote:
> > +struct dmaengine_chan_caps {
> > +   enum dmaengine_apis ops;
> > +   int seg_nr;
> > +   int seg_len;
> > +};
> 
> This makes sense for the potentially dynamic capability properties
> that get set after configuration, but why do we need the operation
> types here?  They can be retrieved from the parent device. 
I was thinking that each channel can have different capabilities.
You can assign one channel for mempcy operations exclusively and some
others for slave usage exclusively.
I believe some h/w do have such assignment so would help in doing that.

-- 
Vinod Koul
Intel Corp.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()

2012-10-23 Thread Dan Williams 
On Thu, Oct 18, 2012 at 7:51 PM, Matt Porter  wrote:
> Add a dmaengine API to retrieve per channel capabilities.
> Currently, only channel ops and SG segment limitations are
> implemented caps.
>
> The API is optionally implemented by drivers and when
> unimplemented will return a NULL pointer. It is intended
> to be executed after a channel has been requested and, if
> the channel is intended to be used with slave SG transfers,
> then it may only be called after dmaengine_slave_config()
> has executed. The slave driver provides parameters such as
> burst size and address width which may be necessary for
> the dmaengine driver to use in order to properly return SG
> segment limit caps.
>
> Suggested-by: Vinod Koul 
> Signed-off-by: Matt Porter 
> ---
>  include/linux/dmaengine.h |   52 
> +
>  1 file changed, 52 insertions(+)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 11d9e25..0181887 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -371,6 +371,38 @@ struct dma_slave_config {
> unsigned int slave_id;
>  };
>
> +enum dmaengine_apis {
> +   DMAENGINE_MEMCPY= 0x0001,
> +   DMAENGINE_XOR   = 0x0002,
> +   DMAENGINE_XOR_VAL   = 0x0004,
> +   DMAENGINE_PQ= 0x0008,
> +   DMAENGINE_PQ_VAL= 0x0010,
> +   DMAENGINE_MEMSET= 0x0020,
> +   DMAENGINE_SLAVE = 0x0040,
> +   DMAENGINE_CYCLIC= 0x0080,
> +   DMAENGINE_INTERLEAVED   = 0x0100,
> +   DMAENGINE_SG= 0x0200,
> +};
> +
> +/* struct dmaengine_chan_caps - expose capability of a channel
> + * Note: each channel can have same or different capabilities
> + *
> + * This primarily classifies capabilities into
> + * a) APIs/ops supported
> + * b) channel physical capabilities
> + *
> + * @ops: or'ed api capability
> + * @seg_nr: maximum number of SG segments supported on a SG/SLAVE
> + * channel (0 for no maximum or not a SG/SLAVE channel)
> + * @seg_len: maximum length of SG segments supported on a SG/SLAVE
> + *  channel (0 for no maximum or not a SG/SLAVE channel)
> + */
> +struct dmaengine_chan_caps {
> +   enum dmaengine_apis ops;
> +   int seg_nr;
> +   int seg_len;
> +};

This makes sense for the potentially dynamic capability properties
that get set after configuration, but why do we need the operation
types here?  They can be retrieved from the parent device.

--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()

2012-10-23 Thread Grant Likely 
On Fri, Oct 19, 2012 at 3:51 AM, Matt Porter  wrote:
> Add a dmaengine API to retrieve per channel capabilities.
> Currently, only channel ops and SG segment limitations are
> implemented caps.
>
> The API is optionally implemented by drivers and when
> unimplemented will return a NULL pointer. It is intended
> to be executed after a channel has been requested and, if
> the channel is intended to be used with slave SG transfers,
> then it may only be called after dmaengine_slave_config()
> has executed. The slave driver provides parameters such as
> burst size and address width which may be necessary for
> the dmaengine driver to use in order to properly return SG
> segment limit caps.
>
> Suggested-by: Vinod Koul 
> Signed-off-by: Matt Porter 
> ---
>  include/linux/dmaengine.h |   52 
> +
>  1 file changed, 52 insertions(+)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 11d9e25..0181887 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -371,6 +371,38 @@ struct dma_slave_config {
> unsigned int slave_id;
>  };
>
> +enum dmaengine_apis {
> +   DMAENGINE_MEMCPY= 0x0001,
> +   DMAENGINE_XOR   = 0x0002,
> +   DMAENGINE_XOR_VAL   = 0x0004,
> +   DMAENGINE_PQ= 0x0008,
> +   DMAENGINE_PQ_VAL= 0x0010,
> +   DMAENGINE_MEMSET= 0x0020,
> +   DMAENGINE_SLAVE = 0x0040,
> +   DMAENGINE_CYCLIC= 0x0080,
> +   DMAENGINE_INTERLEAVED   = 0x0100,
> +   DMAENGINE_SG= 0x0200,
> +};

Actually, one more comment. Why the new enum? Why can't the
dma_transaction_type enum be used directly along with dma_cap_mask_t?

> +
> +/* struct dmaengine_chan_caps - expose capability of a channel
> + * Note: each channel can have same or different capabilities
> + *
> + * This primarily classifies capabilities into
> + * a) APIs/ops supported
> + * b) channel physical capabilities
> + *
> + * @ops: or'ed api capability
> + * @seg_nr: maximum number of SG segments supported on a SG/SLAVE
> + * channel (0 for no maximum or not a SG/SLAVE channel)
> + * @seg_len: maximum length of SG segments supported on a SG/SLAVE
> + *  channel (0 for no maximum or not a SG/SLAVE channel)
> + */
> +struct dmaengine_chan_caps {
> +   enum dmaengine_apis ops;
> +   int seg_nr;
> +   int seg_len;
> +};
> +
>  static inline const char *dma_chan_name(struct dma_chan *chan)
>  {
> return dev_name(>dev->device);
> @@ -534,6 +566,7 @@ struct dma_tx_state {
>   * struct with auxiliary transfer status information, otherwise the call
>   * will just return a simple status code
>   * @device_issue_pending: push pending transactions to hardware
> + * @device_channel_caps: return the channel capabilities
>   */
>  struct dma_device {
>
> @@ -602,6 +635,8 @@ struct dma_device {
> dma_cookie_t cookie,
> struct dma_tx_state *txstate);
> void (*device_issue_pending)(struct dma_chan *chan);
> +   struct dmaengine_chan_caps *(*device_channel_caps)(
> +   struct dma_chan *chan, enum dma_transfer_direction direction);
>  };
>
>  static inline int dmaengine_device_control(struct dma_chan *chan,
> @@ -969,6 +1004,23 @@ dma_set_tx_state(struct dma_tx_state *st, dma_cookie_t 
> last, dma_cookie_t used,
> }
>  }
>
> +/**
> + * dma_get_channel_caps - flush pending transactions to HW
> + * @chan: target DMA channel
> + * @dir: direction of transfer
> + *
> + * Get the channel-specific capabilities. If the dmaengine
> + * driver does not implement per channel capbilities then
> + * NULL is returned.
> + */
> +static inline struct dmaengine_chan_caps
> +*dma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction dir)
> +{
> +   if (chan->device->device_channel_caps)
> +   return chan->device->device_channel_caps(chan, dir);
> +   return NULL;
> +}
> +
>  enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
>  #ifdef CONFIG_DMA_ENGINE
>  enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()

2012-10-23 Thread Grant Likely 
On Fri, Oct 19, 2012 at 3:51 AM, Matt Porter  wrote:
> Add a dmaengine API to retrieve per channel capabilities.
> Currently, only channel ops and SG segment limitations are
> implemented caps.
>
> The API is optionally implemented by drivers and when
> unimplemented will return a NULL pointer. It is intended
> to be executed after a channel has been requested and, if
> the channel is intended to be used with slave SG transfers,
> then it may only be called after dmaengine_slave_config()
> has executed. The slave driver provides parameters such as
> burst size and address width which may be necessary for
> the dmaengine driver to use in order to properly return SG
> segment limit caps.
>
> Suggested-by: Vinod Koul 
> Signed-off-by: Matt Porter 

Looks okay to me. Minor comment below...

> +/**
> + * dma_get_channel_caps - flush pending transactions to HW
> + * @chan: target DMA channel
> + * @dir: direction of transfer
> + *
> + * Get the channel-specific capabilities. If the dmaengine
> + * driver does not implement per channel capbilities then
> + * NULL is returned.
> + */
> +static inline struct dmaengine_chan_caps
> +*dma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction dir)

Looks to me like the returned pointer be a const. Ditto for the
callback prototype in the dma_device structure.

> +{
> +   if (chan->device->device_channel_caps)
> +   return chan->device->device_channel_caps(chan, dir);
> +   return NULL;
> +}
> +
>  enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
>  #ifdef CONFIG_DMA_ENGINE
>  enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()

2012-10-23 Thread Grant Likely 
On Fri, Oct 19, 2012 at 3:51 AM, Matt Porter mpor...@ti.com wrote:
 Add a dmaengine API to retrieve per channel capabilities.
 Currently, only channel ops and SG segment limitations are
 implemented caps.

 The API is optionally implemented by drivers and when
 unimplemented will return a NULL pointer. It is intended
 to be executed after a channel has been requested and, if
 the channel is intended to be used with slave SG transfers,
 then it may only be called after dmaengine_slave_config()
 has executed. The slave driver provides parameters such as
 burst size and address width which may be necessary for
 the dmaengine driver to use in order to properly return SG
 segment limit caps.

 Suggested-by: Vinod Koul vinod.k...@intel.com
 Signed-off-by: Matt Porter mpor...@ti.com

Looks okay to me. Minor comment below...

 +/**
 + * dma_get_channel_caps - flush pending transactions to HW
 + * @chan: target DMA channel
 + * @dir: direction of transfer
 + *
 + * Get the channel-specific capabilities. If the dmaengine
 + * driver does not implement per channel capbilities then
 + * NULL is returned.
 + */
 +static inline struct dmaengine_chan_caps
 +*dma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction dir)

Looks to me like the returned pointer be a const. Ditto for the
callback prototype in the dma_device structure.

 +{
 +   if (chan-device-device_channel_caps)
 +   return chan-device-device_channel_caps(chan, dir);
 +   return NULL;
 +}
 +
  enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
  #ifdef CONFIG_DMA_ENGINE
  enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
 --
 1.7.9.5

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()

2012-10-23 Thread Grant Likely 
On Fri, Oct 19, 2012 at 3:51 AM, Matt Porter mpor...@ti.com wrote:
 Add a dmaengine API to retrieve per channel capabilities.
 Currently, only channel ops and SG segment limitations are
 implemented caps.

 The API is optionally implemented by drivers and when
 unimplemented will return a NULL pointer. It is intended
 to be executed after a channel has been requested and, if
 the channel is intended to be used with slave SG transfers,
 then it may only be called after dmaengine_slave_config()
 has executed. The slave driver provides parameters such as
 burst size and address width which may be necessary for
 the dmaengine driver to use in order to properly return SG
 segment limit caps.

 Suggested-by: Vinod Koul vinod.k...@intel.com
 Signed-off-by: Matt Porter mpor...@ti.com
 ---
  include/linux/dmaengine.h |   52 
 +
  1 file changed, 52 insertions(+)

 diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
 index 11d9e25..0181887 100644
 --- a/include/linux/dmaengine.h
 +++ b/include/linux/dmaengine.h
 @@ -371,6 +371,38 @@ struct dma_slave_config {
 unsigned int slave_id;
  };

 +enum dmaengine_apis {
 +   DMAENGINE_MEMCPY= 0x0001,
 +   DMAENGINE_XOR   = 0x0002,
 +   DMAENGINE_XOR_VAL   = 0x0004,
 +   DMAENGINE_PQ= 0x0008,
 +   DMAENGINE_PQ_VAL= 0x0010,
 +   DMAENGINE_MEMSET= 0x0020,
 +   DMAENGINE_SLAVE = 0x0040,
 +   DMAENGINE_CYCLIC= 0x0080,
 +   DMAENGINE_INTERLEAVED   = 0x0100,
 +   DMAENGINE_SG= 0x0200,
 +};

Actually, one more comment. Why the new enum? Why can't the
dma_transaction_type enum be used directly along with dma_cap_mask_t?

 +
 +/* struct dmaengine_chan_caps - expose capability of a channel
 + * Note: each channel can have same or different capabilities
 + *
 + * This primarily classifies capabilities into
 + * a) APIs/ops supported
 + * b) channel physical capabilities
 + *
 + * @ops: or'ed api capability
 + * @seg_nr: maximum number of SG segments supported on a SG/SLAVE
 + * channel (0 for no maximum or not a SG/SLAVE channel)
 + * @seg_len: maximum length of SG segments supported on a SG/SLAVE
 + *  channel (0 for no maximum or not a SG/SLAVE channel)
 + */
 +struct dmaengine_chan_caps {
 +   enum dmaengine_apis ops;
 +   int seg_nr;
 +   int seg_len;
 +};
 +
  static inline const char *dma_chan_name(struct dma_chan *chan)
  {
 return dev_name(chan-dev-device);
 @@ -534,6 +566,7 @@ struct dma_tx_state {
   * struct with auxiliary transfer status information, otherwise the call
   * will just return a simple status code
   * @device_issue_pending: push pending transactions to hardware
 + * @device_channel_caps: return the channel capabilities
   */
  struct dma_device {

 @@ -602,6 +635,8 @@ struct dma_device {
 dma_cookie_t cookie,
 struct dma_tx_state *txstate);
 void (*device_issue_pending)(struct dma_chan *chan);
 +   struct dmaengine_chan_caps *(*device_channel_caps)(
 +   struct dma_chan *chan, enum dma_transfer_direction direction);
  };

  static inline int dmaengine_device_control(struct dma_chan *chan,
 @@ -969,6 +1004,23 @@ dma_set_tx_state(struct dma_tx_state *st, dma_cookie_t 
 last, dma_cookie_t used,
 }
  }

 +/**
 + * dma_get_channel_caps - flush pending transactions to HW
 + * @chan: target DMA channel
 + * @dir: direction of transfer
 + *
 + * Get the channel-specific capabilities. If the dmaengine
 + * driver does not implement per channel capbilities then
 + * NULL is returned.
 + */
 +static inline struct dmaengine_chan_caps
 +*dma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction dir)
 +{
 +   if (chan-device-device_channel_caps)
 +   return chan-device-device_channel_caps(chan, dir);
 +   return NULL;
 +}
 +
  enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
  #ifdef CONFIG_DMA_ENGINE
  enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
 --
 1.7.9.5

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()

2012-10-23 Thread Dan Williams 
On Thu, Oct 18, 2012 at 7:51 PM, Matt Porter mpor...@ti.com wrote:
 Add a dmaengine API to retrieve per channel capabilities.
 Currently, only channel ops and SG segment limitations are
 implemented caps.

 The API is optionally implemented by drivers and when
 unimplemented will return a NULL pointer. It is intended
 to be executed after a channel has been requested and, if
 the channel is intended to be used with slave SG transfers,
 then it may only be called after dmaengine_slave_config()
 has executed. The slave driver provides parameters such as
 burst size and address width which may be necessary for
 the dmaengine driver to use in order to properly return SG
 segment limit caps.

 Suggested-by: Vinod Koul vinod.k...@intel.com
 Signed-off-by: Matt Porter mpor...@ti.com
 ---
  include/linux/dmaengine.h |   52 
 +
  1 file changed, 52 insertions(+)

 diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
 index 11d9e25..0181887 100644
 --- a/include/linux/dmaengine.h
 +++ b/include/linux/dmaengine.h
 @@ -371,6 +371,38 @@ struct dma_slave_config {
 unsigned int slave_id;
  };

 +enum dmaengine_apis {
 +   DMAENGINE_MEMCPY= 0x0001,
 +   DMAENGINE_XOR   = 0x0002,
 +   DMAENGINE_XOR_VAL   = 0x0004,
 +   DMAENGINE_PQ= 0x0008,
 +   DMAENGINE_PQ_VAL= 0x0010,
 +   DMAENGINE_MEMSET= 0x0020,
 +   DMAENGINE_SLAVE = 0x0040,
 +   DMAENGINE_CYCLIC= 0x0080,
 +   DMAENGINE_INTERLEAVED   = 0x0100,
 +   DMAENGINE_SG= 0x0200,
 +};
 +
 +/* struct dmaengine_chan_caps - expose capability of a channel
 + * Note: each channel can have same or different capabilities
 + *
 + * This primarily classifies capabilities into
 + * a) APIs/ops supported
 + * b) channel physical capabilities
 + *
 + * @ops: or'ed api capability
 + * @seg_nr: maximum number of SG segments supported on a SG/SLAVE
 + * channel (0 for no maximum or not a SG/SLAVE channel)
 + * @seg_len: maximum length of SG segments supported on a SG/SLAVE
 + *  channel (0 for no maximum or not a SG/SLAVE channel)
 + */
 +struct dmaengine_chan_caps {
 +   enum dmaengine_apis ops;
 +   int seg_nr;
 +   int seg_len;
 +};

This makes sense for the potentially dynamic capability properties
that get set after configuration, but why do we need the operation
types here?  They can be retrieved from the parent device.

--
Dan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()

2012-10-23 Thread Vinod Koul 
On Tue, 2012-10-23 at 15:54 -0700, Dan Williams wrote:
  +struct dmaengine_chan_caps {
  +   enum dmaengine_apis ops;
  +   int seg_nr;
  +   int seg_len;
  +};
 
 This makes sense for the potentially dynamic capability properties
 that get set after configuration, but why do we need the operation
 types here?  They can be retrieved from the parent device. 
I was thinking that each channel can have different capabilities.
You can assign one channel for mempcy operations exclusively and some
others for slave usage exclusively.
I believe some h/w do have such assignment so would help in doing that.

-- 
Vinod Koul
Intel Corp.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()

2012-10-23 Thread Vinod Koul 
On Tue, 2012-10-23 at 23:49 +0100, Grant Likely wrote:
  +enum dmaengine_apis {
  +   DMAENGINE_MEMCPY= 0x0001,
  +   DMAENGINE_XOR   = 0x0002,
  +   DMAENGINE_XOR_VAL   = 0x0004,
  +   DMAENGINE_PQ= 0x0008,
  +   DMAENGINE_PQ_VAL= 0x0010,
  +   DMAENGINE_MEMSET= 0x0020,
  +   DMAENGINE_SLAVE = 0x0040,
  +   DMAENGINE_CYCLIC= 0x0080,
  +   DMAENGINE_INTERLEAVED   = 0x0100,
  +   DMAENGINE_SG= 0x0200,
  +};
 
 Actually, one more comment. Why the new enum? Why can't the
 dma_transaction_type enum be used directly along with dma_cap_mask_t? 
Some of the capabilities above are not there in dma_caps_t like DMA_SG.
Also DMA_INTERRUPT and DMA_PRIVATE would not make much sense here.

BUT would help to keep things simpler if have one definition which
includes all.
 
-- 
Vinod Koul
Intel Corp.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()

2012-10-18 Thread Matt Porter 
Add a dmaengine API to retrieve per channel capabilities.
Currently, only channel ops and SG segment limitations are
implemented caps.

The API is optionally implemented by drivers and when
unimplemented will return a NULL pointer. It is intended
to be executed after a channel has been requested and, if
the channel is intended to be used with slave SG transfers,
then it may only be called after dmaengine_slave_config()
has executed. The slave driver provides parameters such as
burst size and address width which may be necessary for
the dmaengine driver to use in order to properly return SG
segment limit caps.

Suggested-by: Vinod Koul 
Signed-off-by: Matt Porter 
---
 include/linux/dmaengine.h |   52 +
 1 file changed, 52 insertions(+)

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 11d9e25..0181887 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -371,6 +371,38 @@ struct dma_slave_config {
unsigned int slave_id;
 };
 
+enum dmaengine_apis {
+   DMAENGINE_MEMCPY= 0x0001,
+   DMAENGINE_XOR   = 0x0002,
+   DMAENGINE_XOR_VAL   = 0x0004,
+   DMAENGINE_PQ= 0x0008,
+   DMAENGINE_PQ_VAL= 0x0010,
+   DMAENGINE_MEMSET= 0x0020,
+   DMAENGINE_SLAVE = 0x0040,
+   DMAENGINE_CYCLIC= 0x0080,
+   DMAENGINE_INTERLEAVED   = 0x0100,
+   DMAENGINE_SG= 0x0200,
+};
+
+/* struct dmaengine_chan_caps - expose capability of a channel
+ * Note: each channel can have same or different capabilities
+ *
+ * This primarily classifies capabilities into
+ * a) APIs/ops supported
+ * b) channel physical capabilities
+ *
+ * @ops: or'ed api capability
+ * @seg_nr: maximum number of SG segments supported on a SG/SLAVE
+ * channel (0 for no maximum or not a SG/SLAVE channel)
+ * @seg_len: maximum length of SG segments supported on a SG/SLAVE
+ *  channel (0 for no maximum or not a SG/SLAVE channel)
+ */
+struct dmaengine_chan_caps {
+   enum dmaengine_apis ops;
+   int seg_nr;
+   int seg_len;
+};
+
 static inline const char *dma_chan_name(struct dma_chan *chan)
 {
return dev_name(>dev->device);
@@ -534,6 +566,7 @@ struct dma_tx_state {
  * struct with auxiliary transfer status information, otherwise the call
  * will just return a simple status code
  * @device_issue_pending: push pending transactions to hardware
+ * @device_channel_caps: return the channel capabilities
  */
 struct dma_device {
 
@@ -602,6 +635,8 @@ struct dma_device {
dma_cookie_t cookie,
struct dma_tx_state *txstate);
void (*device_issue_pending)(struct dma_chan *chan);
+   struct dmaengine_chan_caps *(*device_channel_caps)(
+   struct dma_chan *chan, enum dma_transfer_direction direction);
 };
 
 static inline int dmaengine_device_control(struct dma_chan *chan,
@@ -969,6 +1004,23 @@ dma_set_tx_state(struct dma_tx_state *st, dma_cookie_t 
last, dma_cookie_t used,
}
 }
 
+/**
+ * dma_get_channel_caps - flush pending transactions to HW
+ * @chan: target DMA channel
+ * @dir: direction of transfer
+ *
+ * Get the channel-specific capabilities. If the dmaengine
+ * driver does not implement per channel capbilities then
+ * NULL is returned.
+ */
+static inline struct dmaengine_chan_caps
+*dma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction dir)
+{
+   if (chan->device->device_channel_caps)
+   return chan->device->device_channel_caps(chan, dir);
+   return NULL;
+}
+
 enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
 #ifdef CONFIG_DMA_ENGINE
 enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()

2012-10-18 Thread Matt Porter 
Add a dmaengine API to retrieve per channel capabilities.
Currently, only channel ops and SG segment limitations are
implemented caps.

The API is optionally implemented by drivers and when
unimplemented will return a NULL pointer. It is intended
to be executed after a channel has been requested and, if
the channel is intended to be used with slave SG transfers,
then it may only be called after dmaengine_slave_config()
has executed. The slave driver provides parameters such as
burst size and address width which may be necessary for
the dmaengine driver to use in order to properly return SG
segment limit caps.

Suggested-by: Vinod Koul vinod.k...@intel.com
Signed-off-by: Matt Porter mpor...@ti.com
---
 include/linux/dmaengine.h |   52 +
 1 file changed, 52 insertions(+)

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 11d9e25..0181887 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -371,6 +371,38 @@ struct dma_slave_config {
unsigned int slave_id;
 };
 
+enum dmaengine_apis {
+   DMAENGINE_MEMCPY= 0x0001,
+   DMAENGINE_XOR   = 0x0002,
+   DMAENGINE_XOR_VAL   = 0x0004,
+   DMAENGINE_PQ= 0x0008,
+   DMAENGINE_PQ_VAL= 0x0010,
+   DMAENGINE_MEMSET= 0x0020,
+   DMAENGINE_SLAVE = 0x0040,
+   DMAENGINE_CYCLIC= 0x0080,
+   DMAENGINE_INTERLEAVED   = 0x0100,
+   DMAENGINE_SG= 0x0200,
+};
+
+/* struct dmaengine_chan_caps - expose capability of a channel
+ * Note: each channel can have same or different capabilities
+ *
+ * This primarily classifies capabilities into
+ * a) APIs/ops supported
+ * b) channel physical capabilities
+ *
+ * @ops: or'ed api capability
+ * @seg_nr: maximum number of SG segments supported on a SG/SLAVE
+ * channel (0 for no maximum or not a SG/SLAVE channel)
+ * @seg_len: maximum length of SG segments supported on a SG/SLAVE
+ *  channel (0 for no maximum or not a SG/SLAVE channel)
+ */
+struct dmaengine_chan_caps {
+   enum dmaengine_apis ops;
+   int seg_nr;
+   int seg_len;
+};
+
 static inline const char *dma_chan_name(struct dma_chan *chan)
 {
return dev_name(chan-dev-device);
@@ -534,6 +566,7 @@ struct dma_tx_state {
  * struct with auxiliary transfer status information, otherwise the call
  * will just return a simple status code
  * @device_issue_pending: push pending transactions to hardware
+ * @device_channel_caps: return the channel capabilities
  */
 struct dma_device {
 
@@ -602,6 +635,8 @@ struct dma_device {
dma_cookie_t cookie,
struct dma_tx_state *txstate);
void (*device_issue_pending)(struct dma_chan *chan);
+   struct dmaengine_chan_caps *(*device_channel_caps)(
+   struct dma_chan *chan, enum dma_transfer_direction direction);
 };
 
 static inline int dmaengine_device_control(struct dma_chan *chan,
@@ -969,6 +1004,23 @@ dma_set_tx_state(struct dma_tx_state *st, dma_cookie_t 
last, dma_cookie_t used,
}
 }
 
+/**
+ * dma_get_channel_caps - flush pending transactions to HW
+ * @chan: target DMA channel
+ * @dir: direction of transfer
+ *
+ * Get the channel-specific capabilities. If the dmaengine
+ * driver does not implement per channel capbilities then
+ * NULL is returned.
+ */
+static inline struct dmaengine_chan_caps
+*dma_get_channel_caps(struct dma_chan *chan, enum dma_transfer_direction dir)
+{
+   if (chan-device-device_channel_caps)
+   return chan-device-device_channel_caps(chan, dir);
+   return NULL;
+}
+
 enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
 #ifdef CONFIG_DMA_ENGINE
 enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/