Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp654662imm; Wed, 29 Aug 2018 08:53:46 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaM5Rt5uDRKoFP5c6cVflfHluWrkpNVV8qEJDGNd7OlU5EE3xBkLYA3f0eM21tUO4X1VmSo X-Received: by 2002:a62:778c:: with SMTP id s134-v6mr6549470pfc.189.1535558026373; Wed, 29 Aug 2018 08:53:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535558026; cv=none; d=google.com; s=arc-20160816; b=tJaQxQJayeEu/Ww0Bb2oG5hskxNeOlCcLvhrm8iTdG7TGwRJz43K431iaTHOrM1Qyc O75kFBiNpfIy9oE9h5Sc119ENTv5PfC203+lpSdq3ZO8jfQRKS1qQiWsDTEP2oZCIYkp UK2H4xWiU7RntbjV57bPxIgv6GrPSgCHSMvPHX1idDzrvK+wfjx+uSBS1/xIfZpd2O00 R2OVf2PvUloxxhtV96/5nHsFiRZzlsgTVPnHbQ9bgk6zUdKlBNHMiuOZ351C+EEPJdWA zGqwaHDv+TPPE4WDmkTl0BJgklMg2NGK4q4MnAuj4gLS4updryfaIRzttFvbsZwmi/uJ cqsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=AWekiuJfX3qAO0aH6QtrTXICN7Tdnrxd9UZzoeA3ECg=; b=CJ1t8NkEGVsRIelS6xCQrQxXrTnwYR1iYBB/L3B4i25mj57bGg6NgA27TEhTdrAmkz yTMc4e0NnILR2Z5WDHlybSeJgv30FEh/2w2YubTrNMAPOc9i61kXpi8TfamkGSnB+Pii 9v4ka7VFjOEx4X5g5bXIyeqTbi8KO7W5kXW3hDeAnKZS1EMpUg3pkhAc78Mf60IW7Z/g ielAc4CaaWNfj9gbB0oIjIxmC2ifCwPvXrrQQ6spyQkqPo45bUH1qznrdLdzQbEhdb7O uLrcPup95u478uzpstPq/FC47nCleH2oL+6gPfn9JnoJaYFIikG/u8hvZ0TpwbyQkSDe g5mQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NEdzaFhg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u10-v6si3844738plr.58.2018.08.29.08.53.30; Wed, 29 Aug 2018 08:53:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NEdzaFhg; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729178AbeH2Tt5 (ORCPT + 99 others); Wed, 29 Aug 2018 15:49:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:42100 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728979AbeH2Tt4 (ORCPT ); Wed, 29 Aug 2018 15:49:56 -0400 Received: from localhost (unknown [171.76.77.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3A4212064E; Wed, 29 Aug 2018 15:52:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1535557942; bh=0Rr3s6QGO6YAMDJdUlKCyi4KxxVjoe/jD/+viFpjwR8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NEdzaFhgiqHEU8wGwjPNitz1tYDOGHLofmcw2osbaQ4znCFeJJPJ73OrTNddUkoEc JT5D5jIePV1vVixIUVqJ11owyr3iv/ii5EMFSA6f6CuxiyUDiTW0fgGZNw8jlmTb1C qZQFQzQ1Z7h9NkYJ8QQ4V5e8hsLYmud1fp1M/GLM= Date: Wed, 29 Aug 2018 21:22:12 +0530 From: Vinod To: Peter Ujfalusi Cc: dan.j.williams@intel.com, dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, lars@metafoo.de, radheys@xilinx.com Subject: Re: [PATCH] dmaengine: Add metadata_ops for dma_async_tx_descriptor Message-ID: <20180829155212.GG2388@vkoul-mobl> References: <20180823130728.20506-1-peter.ujfalusi@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180823130728.20506-1-peter.ujfalusi@ti.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23-08-18, 16:07, Peter Ujfalusi wrote: > The metadata is best described as side band data or parameters traveling > alongside the data DMAd by the DMA engine. It is data > which is understood by the peripheral and the peripheral driver only, the > DMA engine see it only as data block and it is not interpreting it in any > way. > > The metadata can be different per descriptor as it is a parameter for the > data being transferred. > > If the DMA supports per descriptor metadata it can implement the attach, > get_ptr/set_len callbacks. > > Client drivers must only use either attach or get_ptr/set_len to avoid > miss configuration. misconfiguration? > Client driver can check if a given metadata mode is supported by the > channel during probe time with > dmaengine_is_metadata_mode_supported(chan, DESC_METADATA_CLIENT); > dmaengine_is_metadata_mode_supported(chan, DESC_METADATA_ENGINE); > > and based on this information can use either mode. > > Wrappers are also added for the metadata_ops. > > To be used in DESC_METADATA_CLIENT mode: > dmaengine_desc_attach_metadata() > > To be used in DESC_METADATA_ENGINE mode: > dmaengine_desc_get_metadata_ptr() > dmaengine_desc_set_metadata_len() > > Signed-off-by: Peter Ujfalusi > --- > Hi, > > Changes since rfc: > - DESC_METADATA_EMBEDDED renamed to DESC_METADATA_ENGINE > - Use flow is added for both CLIENT and ENGINE metadata modes > > Regards, > Peter > > include/linux/dmaengine.h | 144 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 144 insertions(+) > > diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h > index 3db833a8c542..f809635cfeaa 100644 > --- a/include/linux/dmaengine.h > +++ b/include/linux/dmaengine.h > @@ -231,6 +231,57 @@ typedef struct { DECLARE_BITMAP(bits, DMA_TX_TYPE_END); } dma_cap_mask_t; > * @bytes_transferred: byte counter > */ > > +/** > + * enum dma_desc_metadata_mode - per descriptor metadata mode types supported > + * @DESC_METADATA_CLIENT - the metadata buffer is allocated/provided by the > + * client driver and it is attached (via the dmaengine_desc_attach_metadata() > + * helper) to the descriptor. > + * > + * Client drivers interested to use this mode can follow: > + * - DMA_MEM_TO_DEV: > + * 1. prepare the descriptor (dmaengine_prep_*) > + * construct the metadata in the clinet's buffer typo clinet > + * 2. use dmaengine_desc_attach_metadata() to attach the buffer to the > + * descriptor > + * 3. submit the transfer > + * - DMA_DEV_TO_MEM: > + * 1. prepare the descriptor (dmaengine_prep_*) > + * 2. use dmaengine_desc_attach_metadata() to attach the buffer to the > + * descriptor > + * 3. submit the transfer > + * 4. when the transfer is completed, the metadata should be available in the > + * attached buffer I guess this is good to be moved into Documentation also we dont allow this for memcpy txn? > + * > + * @DESC_METADATA_ENGINE - the metadata buffer is allocated/managed by the DMA > + * driver. The client driver can ask for the pointer, maximum size and the > + * currently used size of the metadata and can directly update or read it. > + * dmaengine_desc_get_metadata_ptr() and dmaengine_desc_set_metadata_len() is > + * provided as helper functions. > + * > + * Client drivers interested to use this mode can follow: > + * - DMA_MEM_TO_DEV: > + * 1. prepare the descriptor (dmaengine_prep_*) > + * 2. use dmaengine_desc_get_metadata_ptr() to get the pointer to the engine's > + * metadata area > + * 3. update the metadata at the pointer > + * 4. use dmaengine_desc_set_metadata_len() to tell the DMA engine the amount > + * of data the client has placed into the metadata buffer > + * 5. submit the transfer > + * - DMA_DEV_TO_MEM: > + * 1. prepare the descriptor (dmaengine_prep_*) > + * 2. submit the transfer > + * 3. on transfer completion, use dmaengine_desc_get_metadata_ptr() to get the > + * pointer to the engine's metadata are > + * 4. Read out the metadate from the pointer > + * > + * Note: the two mode is not compatible and clients must use one mode for a > + * descriptor. > + */ > +enum dma_desc_metadata_mode { > + DESC_METADATA_CLIENT = (1 << 0), > + DESC_METADATA_ENGINE = (1 << 1), BIT(x) > +}; > + > struct dma_chan_percpu { > /* stats */ > unsigned long memcpy_count; > @@ -494,6 +545,18 @@ struct dmaengine_unmap_data { > dma_addr_t addr[0]; > }; > > +struct dma_async_tx_descriptor; > + > +struct dma_descriptor_metadata_ops { > + int (*attach)(struct dma_async_tx_descriptor *desc, void *data, > + size_t len); > + > + void *(*get_ptr)(struct dma_async_tx_descriptor *desc, > + size_t *payload_len, size_t *max_len); > + int (*set_len)(struct dma_async_tx_descriptor *desc, > + size_t payload_len); > +}; > + > /** > * struct dma_async_tx_descriptor - async transaction descriptor > * ---dma generic offload fields--- > @@ -523,6 +586,8 @@ struct dma_async_tx_descriptor { > dma_async_tx_callback_result callback_result; > void *callback_param; > struct dmaengine_unmap_data *unmap; > + enum dma_desc_metadata_mode desc_metadata_mode; > + struct dma_descriptor_metadata_ops *metadata_ops; > #ifdef CONFIG_ASYNC_TX_ENABLE_CHANNEL_SWITCH > struct dma_async_tx_descriptor *next; > struct dma_async_tx_descriptor *parent; > @@ -685,6 +750,7 @@ struct dma_filter { > * @global_node: list_head for global dma_device_list > * @filter: information for device/slave to filter function/param mapping > * @cap_mask: one or more dma_capability flags > + * @desc_metadata_modes: supported metadata modes by the DMA device > * @max_xor: maximum number of xor sources, 0 if no capability > * @max_pq: maximum number of PQ sources and PQ-continue capability > * @copy_align: alignment shift for memcpy operations > @@ -749,6 +815,7 @@ struct dma_device { > struct list_head global_node; > struct dma_filter filter; > dma_cap_mask_t cap_mask; > + enum dma_desc_metadata_mode desc_metadata_modes; > unsigned short max_xor; > unsigned short max_pq; > enum dmaengine_alignment copy_align; > @@ -935,6 +1002,83 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_memcpy( > len, flags); > } > > +static inline bool dmaengine_is_metadata_mode_supported(struct dma_chan *chan, > + enum dma_desc_metadata_mode mode) > +{ > + return !!(chan->device->desc_metadata_modes & mode); > +} > + > +static inline int _desc_check_and_set_metadata_mode( why does this need to start with _ ? > + struct dma_async_tx_descriptor *desc, enum dma_desc_metadata_mode mode) > +{ > + /* Make sure that the metadata mode is not mixed */ > + if (!desc->desc_metadata_mode) { > + if (dmaengine_is_metadata_mode_supported(desc->chan, mode)) > + desc->desc_metadata_mode = mode; > + else > + return -ENOTSUPP; > + } else if (desc->desc_metadata_mode != mode) { > + return -EINVAL; > + } > + > + return 0; > +} > + > +static inline int dmaengine_desc_attach_metadata( > + struct dma_async_tx_descriptor *desc, void *data, size_t len) > +{ > + int ret; > + > + if (!desc) > + return -EINVAL; > + > + ret = _desc_check_and_set_metadata_mode(desc, DESC_METADATA_CLIENT); > + if (ret) > + return ret; > + > + if (!desc->metadata_ops || !desc->metadata_ops->attach) > + return -ENOTSUPP; > + > + return desc->metadata_ops->attach(desc, data, len); > +} > + > +static inline void *dmaengine_desc_get_metadata_ptr( > + struct dma_async_tx_descriptor *desc, size_t *payload_len, > + size_t *max_len) > +{ > + int ret; > + > + if (!desc) > + return ERR_PTR(-EINVAL); > + > + ret = _desc_check_and_set_metadata_mode(desc, DESC_METADATA_ENGINE); > + if (ret) > + return ERR_PTR(ret); > + > + if (!desc->metadata_ops || !desc->metadata_ops->get_ptr) > + return ERR_PTR(-ENOTSUPP); > + > + return desc->metadata_ops->get_ptr(desc, payload_len, max_len); > +} > + > +static inline int dmaengine_desc_set_metadata_len( > + struct dma_async_tx_descriptor *desc, size_t payload_len) > +{ > + int ret; > + > + if (!desc) > + return -EINVAL; > + > + ret = _desc_check_and_set_metadata_mode(desc, DESC_METADATA_ENGINE); > + if (ret) > + return ret; > + > + if (!desc->metadata_ops || !desc->metadata_ops->set_len) > + return -ENOTSUPP; > + > + return desc->metadata_ops->set_len(desc, payload_len); > +} thats bit too much code for a header file :( Lets move it to C file please. We can utilize local dmaengine.h and not expose all these and possible misuse by clients Also I would like to see a use :-) before further comments. -- ~Vinod