Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933947Ab2JWWt4 (ORCPT ); Tue, 23 Oct 2012 18:49:56 -0400 Received: from mail-da0-f46.google.com ([209.85.210.46]:48978 "EHLO mail-da0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933543Ab2JWWty (ORCPT ); Tue, 23 Oct 2012 18:49:54 -0400 MIME-Version: 1.0 In-Reply-To: <1350615088-14562-2-git-send-email-mporter@ti.com> References: <1350615088-14562-1-git-send-email-mporter@ti.com> <1350615088-14562-2-git-send-email-mporter@ti.com> From: Grant Likely Date: Tue, 23 Oct 2012 23:49:33 +0100 X-Google-Sender-Auth: lcXxSP9bcLZfUCoQMI9Cn44EqtM Message-ID: Subject: Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps() To: Matt Porter Cc: Vinod Koul , Dan Williams , Chris Ball , Linux DaVinci Kernel List , Linux Kernel Mailing List , Linux MMC List Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4880 Lines: 128 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(&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 majordomo@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/