From patchwork Fri Jun 1 10:17:36 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Peter Ujfalusi X-Patchwork-Id: 10442931 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id B7BE8603D7 for ; Fri, 1 Jun 2018 10:17:32 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A230F28D20 for ; Fri, 1 Jun 2018 10:17:32 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 967A428D25; Fri, 1 Jun 2018 10:17:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,T_DKIM_INVALID,T_TVD_MIME_EPI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1CCF228D20 for ; Fri, 1 Jun 2018 10:17:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751311AbeFAKRU (ORCPT ); Fri, 1 Jun 2018 06:17:20 -0400 Received: from fllnx210.ext.ti.com ([198.47.19.17]:40803 "EHLO fllnx210.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750766AbeFAKRS (ORCPT ); Fri, 1 Jun 2018 06:17:18 -0400 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by fllnx210.ext.ti.com (8.15.1/8.15.1) with ESMTP id w51AGd6G028607; Fri, 1 Jun 2018 05:16:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1527848199; bh=tcWEmjaQ3Ke83uYFhgPwJKbAcvHjwK6AAyNDhJILKmo=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=qLtqxUcsGjuzSReuqjFJQpS8zsIUiKI7LRd7xjOyd88H57oPXZ6496fvHHo2LiNxY TnTJPc49pwTVxvyogv1nJ0x9UXtKhW0Yh3gPeFOon6N1cpctD2I2deTrS+S5jO2k/X Q7S5qrYFdHVCRjoe0eiSACY9IlfYOAxo0qCkQnzs= Received: from DLEE100.ent.ti.com (dlee100.ent.ti.com [157.170.170.30]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id w51AGdcd030239; Fri, 1 Jun 2018 05:16:39 -0500 Received: from DLEE104.ent.ti.com (157.170.170.34) by DLEE100.ent.ti.com (157.170.170.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 1 Jun 2018 05:16:38 -0500 Received: from dflp32.itg.ti.com (10.64.6.15) by DLEE104.ent.ti.com (157.170.170.34) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1466.3 via Frontend Transport; Fri, 1 Jun 2018 05:16:38 -0500 Received: from [192.168.2.6] (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp32.itg.ti.com (8.14.3/8.13.8) with ESMTP id w51AGan1005359; Fri, 1 Jun 2018 05:16:36 -0500 Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client To: Radhey Shyam Pandey , Vinod Koul CC: Lars-Peter Clausen , "michal.simek@xilinx.com" , "linux-kernel@vger.kernel.org" , "dmaengine@vger.kernel.org" , "dan.j.williams@intel.com" , Appana Durga Kedareswara Rao , "linux-arm-kernel@lists.infradead.org" References: <20180411090854.GY6014@localhost> <7f549d2e-fc96-8c7e-d839-edb86ae088a5@metafoo.de> <4ba085c7-5256-6c8a-5697-c0d5736a6e46@ti.com> <1fc10bec-5c2c-98f1-1d5b-b768dea844ed@metafoo.de> <78828d31-e4cd-5211-f1b6-8918ac38f599@ti.com> <8c7a5ac8-0747-9dad-f6e5-74890b64f618@ti.com> <20180424035548.GA6014@localhost> <99581088-7ef8-6fac-c934-91eadddfb04e@ti.com> From: Peter Ujfalusi Message-ID: <32208a9c-2b15-d345-1432-f1e387531f9b@ti.com> Date: Fri, 1 Jun 2018 13:17:36 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Radhey, On 2018-05-30 20:29, Radhey Shyam Pandey wrote: >> In couple of days I can update the metadata patches I have atm and send >> as RFC. >> >> Is there anything from your side I should take into account when doing that? > I think a generic interface to attach/share metadata buffer b/w client and the > dmaengine driver is good enough. Is metadata patchset (early version) > available in TI external repos? I don't have it in public repository, but now that the TRM is public I can start preparing things for upstream. I have attached the patch I ended up with, but I need to add the documentation part. Since the 'metadata' is part of the DMA descriptor itself I thought that it might be better to reflect that -> the metadata_ops is part of the dma_async_tx_descriptor struct. DMA drivers can initialize it when it is supported by the channel or setup. In my case it is optional, many peripherals did not use it at all. I have two modes to deal with the metadata: 1. attach mode Client drivers are giving a buffer and a size to the DMA driver and in case of TX the data is copied to the descriptor's metadata part. In case of RX when the transfer is completed the DMA driver will copy the data from the DMA descriptor to the client provided buffer. Here we need one memcpy for each descriptor. 2. pointer mode If we have high throughput peripheral, the per descriptor memcpy can be an obstacle for performance. TX: The client dmaengine_desc_get_metadata_ptr() to get the pointer to the metadata section of the descriptor, it will receive back the max size and the currently used size (important for RX). This is done before issue_pending(). The client can update the metadata directly and when it is done calls the dmaengine_desc_set_metadata_len() to tell the DMA driver the size of the metadata it has configured. RX: in the DMA callback the client calls dmaengine_desc_get_metadata_ptr() to get the pointer and the size of the metadata we have received and can process the information w/o memcpy. I think it might be better to rename these from metadata to client_data or something. It is part of the DMA descriptor, passed along with the DMA descriptor, but it is owned by the client driver. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki From cdd04a5876d5e2b1e10b4e5456585958715fd3a7 Mon Sep 17 00:00:00 2001 From: Peter Ujfalusi Date: Fri, 20 Apr 2018 15:10:08 +0300 Subject: [PATCH] dmaengine: Add metadat_ops for dma_async_tx_descriptor 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. Wrappers are also added for the metadata_ops: dmaengine_desc_attach_metadata() dmaengine_desc_get_metadata_ptr() dmaengine_desc_set_metadata_len() Signed-off-by: Peter Ujfalusi --- include/linux/dmaengine.h | 50 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h index 51fbb861e84b..ac42ace36aa3 100644 --- a/include/linux/dmaengine.h +++ b/include/linux/dmaengine.h @@ -491,6 +491,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--- @@ -520,6 +532,7 @@ struct dma_async_tx_descriptor { dma_async_tx_callback_result callback_result; void *callback_param; struct dmaengine_unmap_data *unmap; + 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; @@ -932,6 +945,43 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_memcpy( len, flags); } +static inline int dmaengine_desc_attach_metadata( + struct dma_async_tx_descriptor *desc, void *data, size_t len) +{ + if (!desc) + return 0; + + 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) +{ + if (!desc) + return NULL; + + 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) +{ + if (!desc) + return 0; + + if (!desc->metadata_ops || !desc->metadata_ops->set_len) + return -ENOTSUPP; + + return desc->metadata_ops->set_len(desc, payload_len); +} + /** * dmaengine_terminate_all() - Terminate all active DMA transfers * @chan: The channel for which to terminate the transfers -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki