From patchwork Tue Apr 17 13:46:43 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Peter Ujfalusi X-Patchwork-Id: 10345109 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 DFA5560216 for ; Tue, 17 Apr 2018 13:47:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D56F926247 for ; Tue, 17 Apr 2018 13:47:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C9DC426E46; Tue, 17 Apr 2018 13:47:34 +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 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 18CEC26D08 for ; Tue, 17 Apr 2018 13:47:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753953AbeDQNrL (ORCPT ); Tue, 17 Apr 2018 09:47:11 -0400 Received: from lelnx193.ext.ti.com ([198.47.27.77]:63776 "EHLO lelnx193.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753902AbeDQNrI (ORCPT ); Tue, 17 Apr 2018 09:47:08 -0400 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by lelnx193.ext.ti.com (8.15.1/8.15.1) with ESMTP id w3HDkKaO014022; Tue, 17 Apr 2018 08:46:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1523972780; bh=aplvBqtlr1NlibMPAHzfs+301jCEJDvgTG353drumIA=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=OA9JNA/VAwS1jLQ7l6TotSd0Sw3EVjw7hsdcCOwlMI1Cw4qoeIZZD22bFwAIn6Nrz 6geR8NbfVSQQzBvK7jlzQt9bRLnW0Hv6FcAoWIGPsohwGU2N26TLhb7xLT3v9aWlXE Tbgp+OR7lXbE4MSJVlDIsl/4ff6exfz621wISRPQ= Received: from DLEE112.ent.ti.com (dlee112.ent.ti.com [157.170.170.23]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id w3HDkKro019369; Tue, 17 Apr 2018 08:46:20 -0500 Received: from DLEE110.ent.ti.com (157.170.170.21) by DLEE112.ent.ti.com (157.170.170.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Tue, 17 Apr 2018 08:46:20 -0500 Received: from dlep33.itg.ti.com (157.170.170.75) by DLEE110.ent.ti.com (157.170.170.21) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1261.35 via Frontend Transport; Tue, 17 Apr 2018 08:46:20 -0500 Received: from [192.168.2.6] (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep33.itg.ti.com (8.14.3/8.13.8) with ESMTP id w3HDkHY0016324; Tue, 17 Apr 2018 08:46:18 -0500 Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control words to netdev dma client To: Lars-Peter Clausen , Radhey Shyam Pandey , Vinod Koul CC: "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: <1522665546-10035-1-git-send-email-radheys@xilinx.com> <1522665546-10035-3-git-send-email-radheys@xilinx.com> <20180411090854.GY6014@localhost> <7f549d2e-fc96-8c7e-d839-edb86ae088a5@metafoo.de> From: Peter Ujfalusi Message-ID: <4ba085c7-5256-6c8a-5697-c0d5736a6e46@ti.com> Date: Tue, 17 Apr 2018 16:46:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <7f549d2e-fc96-8c7e-d839-edb86ae088a5@metafoo.de> 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 On 2018-04-17 15:54, Lars-Peter Clausen wrote: > On 04/17/2018 01:43 PM, Radhey Shyam Pandey wrote: >> Hi Vinod, >> >>> -----Original Message----- >>> From: Vinod Koul [mailto:vinod.koul@intel.com] >>> Sent: Wednesday, April 11, 2018 2:39 PM >>> To: Radhey Shyam Pandey >>> Cc: dan.j.williams@intel.com; michal.simek@xilinx.com; Appana Durga >>> Kedareswara Rao ; Radhey Shyam Pandey >>> ; lars@metafoo.de; dmaengine@vger.kernel.org; >>> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org >>> Subject: Re: [RFC 2/6] dmaengine: xilinx_dma: Pass AXI4-Stream control >>> words to netdev dma client >>> >>> On Mon, Apr 02, 2018 at 04:09:02PM +0530, Radhey Shyam Pandey wrote: >>> >>>> + >>>> + if (chan->xdev->has_axieth_connected) { >>>> + seg = list_first_entry(&desc->segments, >>>> + struct xilinx_axidma_tx_segment, >>> node); >>>> + if (cb.callback_param) { >>>> + app_w = (u32 *) cb.callback_param; >>> >>> why are you interpreting callback_param? This is plainly wrong. >>> we do not know what is the interpretation of callback_param and it is >>> internal to submitter. >> In design, if AXI DMA is connected to AXI Ethernet IP there are certain >> AXI4-Stream Status fields (RX) that we need to pass to ethernet driver >> along with data buffer. An example includes: checksum fields, packet >> length etc. To pass these control words there is a structure defined >> between dmaengine and client. Before calling the client callback >> stream control words are copied to dma client callback_param struct >> (only if axieth is connected). >> >> I understand it's not an ideal way and we shouldn't be interpreting >> callback_param but couldn't find any better alternative of passing >> custom information from dmaengine to client driver and still be >> aligned to the framework. >> >>> >>> What exactly is the problem you are trying to solve? >> As mentioned above we need to pass AXI4-stream words(custom >> data) from dmaengine driver to dma client driver(ethernet) for >> each DMA descriptor. Current solution populates callback_param >> struct (only if axieth is connected). Please let me know if there is >> an alternate solution. > > The standard interfaces need to work in a way that a client using them does > not have to know to which DMA controller it is connected. In a similar way > the DMA controller shouldn't have any client specific logic for the generic > interfaces. Otherwise there is no point of having a generic interface. > > There are two options. > > Either you extend the generic interfaces so it can cover your usecase in a > generic way. E.g. the ability to attach meta data to transfer. Fwiw I have this patch as part of a bigger work to achieve similar results: commit f7cf442a37618bbd996f2640ececc4a990ea655e Author: Peter Ujfalusi Date: Wed Nov 22 10:21:59 2017 +0200 dmaengine: Add callback to set per descriptor metadata Some DMA engines can send and receive side band information, commands or parameters which is not transferred within the data stream itself. In such case clients can set the metadata to the given descriptor and it is going to be sent to the peripheral, or in case of DEV_TO_MEM the provided buffer will receive the metadata. Signed-off-by: Peter Ujfalusi The drawback is that the DMA drivers need to do memcpy. I'm considering to change this to get metadata_ptr() so clients can directly write to the buffer w/o memcpy. > Or you can implement a interface that is specific to your DMA controller and > any client using this interface knows it is talking to your DMA controller. Hrm, so we can have DMA driver specific calls? The reason why TI's keystone 2 navigator DMA support was rejected that it was introducing NAV specific calls for clients to configure features not yet supported by the framework. > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki --- 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 diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h index cc887a6f74ba..fb8e9c92fb01 100644 --- a/include/linux/dmaengine.h +++ b/include/linux/dmaengine.h @@ -709,6 +709,11 @@ struct dma_filter { * be called after period_len bytes have been transferred. * @device_prep_interleaved_dma: Transfer expression in a generic way. * @device_prep_dma_imm_data: DMA's 8 byte immediate data to the dst address + * @device_attach_metadata: Some DMA engines can send and receive side band + * information, commands or parameters which is not transferred within the + * data stream itself. In such case clients can set the metadata to the + * given descriptor and it is going to be sent to the peripheral, or in + * case of DEV_TO_MEM the provided buffer will receive the metadata. * @device_config: Pushes a new configuration to a channel, return 0 or an error * code * @device_pause: Pauses any transfer happening on a channel. Returns @@ -796,6 +801,9 @@ struct dma_device { struct dma_chan *chan, dma_addr_t dst, u64 data, unsigned long flags); + int (*device_attach_metadata)(struct dma_async_tx_descriptor *desc, + void *data, size_t len); + int (*device_config)(struct dma_chan *chan, struct dma_slave_config *config); int (*device_pause)(struct dma_chan *chan); @@ -909,6 +917,21 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_dma_memcpy( len, flags); } +static inline int dmaengine_attach_metadata( + struct dma_async_tx_descriptor *desc, void *data, size_t len) +{ + struct dma_chan *chan; + + if (!desc) + return 0; + + chan = desc->chan; + if (!chan || !chan->device || !chan->device->device_attach_metadata) + return 0; + + return chan->device->device_attach_metadata(desc, data, len); +} + /** * dmaengine_terminate_all() - Terminate all active DMA transfers * @chan: The channel for which to terminate the transfers