From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: [RFC] dmaengine: Add metadat_ops for dma_async_tx_descriptor From: Peter Ujfalusi Message-Id: Date: Mon, 30 Jul 2018 12:46:14 +0300 To: Vinod Cc: radheys@xilinx.com, vinod.koul@intel.com, lars@metafoo.de, michal.simek@xilinx.com, linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org, dan.j.williams@intel.com, appanad@xilinx.com, linux-arm-kernel@lists.infradead.org List-ID: Vmlub2QsCgpPbiAyMDE4LTA3LTI0IDE0OjE0LCBWaW5vZCB3cm90ZToKPj4+PiBDbGllbnRzIG11 c3Qgbm90IG1peCB0aGUgdHdvIHdheSBvZiBoYW5kbGluZyB0aGUgbWV0YWRhdGEuCj4+Pj4gVGhl IHNldF9sZW4oKSBpcyBpbnRlbmRlZCB0byB0ZWxsIHRoZSBETUEgZHJpdmVyIHRoZSBjbGllbnQg cHJvdmlkZWQKPj4+PiBtZXRhZGF0YSBzaXplIChpbiBNRU1fVE9fREVWIGNhc2UgbW9zdGx5KS4K Pj4+Pgo+Pj4+IE1FTV9UT19ERVYgZmxvdyBvbiBjbGllbnQgc2lkZToKPj4+PiBnZXRfcHRyKCkK Pj4+PiBmaWxsIGluIHRoZSBtZXRhZGF0YSB0byB0aGUgcG9pbnRlciAobm90IGV4Y2VlZGluZyBt YXhfbGVuKQo+Pj4+IHNldF9sZW4oKSB0byB0ZWxsIHRoZSBETUEgZHJpdmVyIHRoZSBhbW91bnQg b2YgdmFsaWQgYnl0ZXMgd3JpdHRlbgo+Pj4+Cj4+Pj4gREVWX1RPX01FTSBmbG93IG9uIGNsaWVu dCBzaWRlOgo+Pj4+IEluIHRoZSBjb21wbGV0aW9uIGNhbGxiYWNrLCBnZXRfcHRyKCkKPj4+PiB0 aGUgbWV0YWRhdGEgaXMgcGF5bG9hZF9sZW4gYnl0ZXMgYW5kIGNhbiBiZSBhY2Nlc3NlZCBpbiB0 aGUgcmV0dXJuIHBvaW50ZXIuCj4+Pgo+Pj4gSSB3b3VsZCB0aGluayB0byB1bmlmeSB0aGlzLi4K Pj4KPj4gSSBoYXZlIHRyaWVkIGl0LCBidXQgdGhlIGF0dGFjaCBtb2RlIGFuZCB0aGUgcG9pbnRl ciBtb2RlIGlzIGhhcmQgdG8KPj4gaGFuZGxlIHdpdGggYSBnZW5lcmljIEFQSS4KPj4gSSB3aWxs IHRyeSB0byBmaW5kIGEgd2F5IHRvIHVuaWZ5IHRoaW5ncyBpbiBhIHNhbmUgd2F5Lgo+IAo+IEht bW0sIGxvb2tpbmcgZnJvbSB0aGUgZGVzY3JpcHRpb24gdGhleSB3aWxsIGJlIGZvciBkaWZmZXJl bnQgbWV0aG9kcywKPiBzbyBsZXRzIG1ha2UgdGhlbSBvcnRob2dvbmFsIGFuZCBub3QgYWxsb3cg ZHJpdmVyIHRvIHJlZ2lzdGVyIGJvdGguCgpJIHdvdWxkIGFsbG93IERNQSBkcml2ZXJzIHRvIHJl Z2lzdGVyIGJvdGgsIGJ1dCBzb21laG93IGVuZm9yY2UgdGhhdApjbGllbnRzIGFyZSBub3QgbWl4 aW5nIHRoZSB0d28gZGlzdGluY3Qgd2F5IG9mIGRlYWxpbmcgd2l0aCB0aGUgbWV0YWRhdGEuCgpU aGUgcmVhc29uIGZvciB0aGF0IGlzIGZvciBleGFtcGxlIHRoZSBhdHRhY2ggbW9kZSBpcyB0aGUg c2ltcGxlc3QgKEkKaW1wbGVtZW50ZWQgaXQgZmlyc3QgYW5kIEkgaGF2ZSBhIGNsaWVudCB1c2lu ZyBpdCksIGJ1dCBpZiB0aGUgcG9pbnRlcgptb2RlIGlzIGZvdW5kIHRvIGJlIG1vcmUgZWZmaWNp ZW50IGFuZCBmZWFzaWJsZSBmb3IgdGhlIERNQSB0aGVuIHRoZSBETUEKZHJpdmVyIGNhbiBpbXBs ZW1lbnQgdGhhdCBtb2RlIGFuZCB0aGUgY2xpZW50IGNhbiBtb3ZlIGFzIHdlbGwgdy9vCmJyZWFr aW5nIGFueXRoaW5nLgoKPiAKPj4KPj4gSSBoYXZlIG1vdmVkIHRoZSBtZXRhZGF0YV9vcHMgdG8g ZG1hX2FzeW5jX3R4X2Rlc2NyaXB0b3IgdG8gZW1waGFzaXplCj4+IHRoYXQgaXQgaXMgcGVyIGRl c2NyaXB0b3Igc2V0dGluZzoKPj4gaHR0cHM6Ly9naXRodWIuY29tL29tYXAtYXVkaW8vbGludXgt YXVkaW8vY29tbWl0LzAyZTA5NWQxMzIwYTRiYjNhZTI4MWRkYjIwOGNlODJlYWQ3NDZmMDAjZGlm Zi05MmMwYTc5ZjQxNGRjM2JlOWRmYzY3YTk2OWMwZGQ3MQo+Pgo+Pgo+Pj4+IEJUVzogVGhlIGRy aXZlciB3aGljaCBpcyBnb2luZyB0byBuZWVkIHRoaXMgaXMgbm93IGFjY2Vzc2libGUgaW4gcHVi bGljOgo+Pj4+IGh0dHBzOi8vZ2l0LnRpLmNvbS90aS1saW51eC1rZXJuZWwvdGktbGludXgta2Vy bmVsL3RyZWVzL3RpLWxpbnV4LTQuMTQueS9kcml2ZXJzL2RtYS90aQo+Pj4+Cj4+Pj4gb3IgaW4g bXkgd2lwIHRyZWU6Cj4+Pj4gaHR0cHM6Ly9naXRodWIuY29tL29tYXAtYXVkaW8vbGludXgtYXVk aW8vdHJlZS9wZXRlci90aS1saW51eC00LjE0Lnkvd2lwL2RyaXZlcnMvZG1hL3RpCj4+Pj4KPj4+ PiBwcmVmaXhlZCB3aXRoIGszLSoKPj4+Pgo+Pgo+PiAtIFDDqXRlcgo+Pgo+PiBUZXhhcyBJbnN0 cnVtZW50cyBGaW5sYW5kIE95LCBQb3Jra2FsYW5rYXR1IDIyLCAwMDE4MCBIZWxzaW5raS4KPj4g WS10dW5udXMvQnVzaW5lc3MgSUQ6IDA2MTU1MjEtNC4gS290aXBhaWtrYS9Eb21pY2lsZTogSGVs c2lua2kKPiAKCi0gUMOpdGVyCgpUZXhhcyBJbnN0cnVtZW50cyBGaW5sYW5kIE95LCBQb3Jra2Fs YW5rYXR1IDIyLCAwMDE4MCBIZWxzaW5raS4KWS10dW5udXMvQnVzaW5lc3MgSUQ6IDA2MTU1MjEt NC4gS290aXBhaWtrYS9Eb21pY2lsZTogSGVsc2lua2kKLS0tClRvIHVuc3Vic2NyaWJlIGZyb20g dGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBkbWFlbmdpbmUiIGluCnRoZSBi b2R5IG9mIGEgbWVzc2FnZSB0byBtYWpvcmRvbW9Admdlci5rZXJuZWwub3JnCk1vcmUgbWFqb3Jk b21vIGluZm8gYXQgIGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F392CFD21E1 for ; Mon, 30 Jul 2018 09:46:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id ACAD320870 for ; Mon, 30 Jul 2018 09:46:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="XYa/UVtK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ACAD320870 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=ti.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727080AbeG3LU7 (ORCPT ); Mon, 30 Jul 2018 07:20:59 -0400 Received: from fllv0016.ext.ti.com ([198.47.19.142]:59420 "EHLO fllv0016.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726663AbeG3LU7 (ORCPT ); Mon, 30 Jul 2018 07:20:59 -0400 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by fllv0016.ext.ti.com (8.15.2/8.15.2) with ESMTP id w6U9k9gi007029; Mon, 30 Jul 2018 04:46:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1532943969; bh=JY4e147qrLIjHXfj4/M2yrotXQxTEl90wjomtXqnbQI=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=XYa/UVtK+kksIpZ75Thz1mK4pJw9l+GgrfWfKaBTb4piHSLtEkd54wtY03ltZ1Ann d0BYTge0Dlzk9TyEf4LfeBFGxlVoM2tHLQOaFYdISXBuuFfXYNW7K5G0EoOcW35hBf ktEczb7kwa94xQ6NbjJQWhvHmC+UYZMZSaeGrcKc= Received: from DLEE113.ent.ti.com (dlee113.ent.ti.com [157.170.170.24]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id w6U9k8tD025805; Mon, 30 Jul 2018 04:46:09 -0500 Received: from DLEE115.ent.ti.com (157.170.170.26) by DLEE113.ent.ti.com (157.170.170.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 30 Jul 2018 04:46:08 -0500 Received: from dflp33.itg.ti.com (10.64.6.16) by DLEE115.ent.ti.com (157.170.170.26) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1466.3 via Frontend Transport; Mon, 30 Jul 2018 04:46:08 -0500 Received: from [192.168.2.6] (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp33.itg.ti.com (8.14.3/8.13.8) with ESMTP id w6U9k5H1026209; Mon, 30 Jul 2018 04:46:06 -0500 Subject: Re: [RFC] dmaengine: Add metadat_ops for dma_async_tx_descriptor To: Vinod CC: , , , , , , , , References: <32208a9c-2b15-d345-1432-f1e387531f9b@ti.com> <20180601102429.16429-1-peter.ujfalusi@ti.com> <20180710055230.GB3219@vkoul-mobl> <052ebdd9-7e68-5b78-52c3-304376f48777@ti.com> <20180719092224.GK3219@vkoul-mobl> <20180724111425.GK3219@vkoul-mobl> From: Peter Ujfalusi Message-ID: Date: Mon, 30 Jul 2018 12:46:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <20180724111425.GK3219@vkoul-mobl> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Vinod, On 2018-07-24 14:14, Vinod wrote: >>>> Clients must not mix the two way of handling the metadata. >>>> The set_len() is intended to tell the DMA driver the client provided >>>> metadata size (in MEM_TO_DEV case mostly). >>>> >>>> MEM_TO_DEV flow on client side: >>>> get_ptr() >>>> fill in the metadata to the pointer (not exceeding max_len) >>>> set_len() to tell the DMA driver the amount of valid bytes written >>>> >>>> DEV_TO_MEM flow on client side: >>>> In the completion callback, get_ptr() >>>> the metadata is payload_len bytes and can be accessed in the return pointer. >>> >>> I would think to unify this.. >> >> I have tried it, but the attach mode and the pointer mode is hard to >> handle with a generic API. >> I will try to find a way to unify things in a sane way. > > Hmmm, looking from the description they will be for different methods, > so lets make them orthogonal and not allow driver to register both. I would allow DMA drivers to register both, but somehow enforce that clients are not mixing the two distinct way of dealing with the metadata. The reason for that is for example the attach mode is the simplest (I implemented it first and I have a client using it), but if the pointer mode is found to be more efficient and feasible for the DMA then the DMA driver can implement that mode and the client can move as well w/o breaking anything. > >> >> I have moved the metadata_ops to dma_async_tx_descriptor to emphasize >> that it is per descriptor setting: >> https://github.com/omap-audio/linux-audio/commit/02e095d1320a4bb3ae281ddb208ce82ead746f00#diff-92c0a79f414dc3be9dfc67a969c0dd71 >> >> >>>> BTW: The driver which is going to need this is now accessible in public: >>>> https://git.ti.com/ti-linux-kernel/ti-linux-kernel/trees/ti-linux-4.14.y/drivers/dma/ti >>>> >>>> or in my wip tree: >>>> https://github.com/omap-audio/linux-audio/tree/peter/ti-linux-4.14.y/wip/drivers/dma/ti >>>> >>>> prefixed with k3-* >>>> >> >> - Péter >> >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. >> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki From mboxrd@z Thu Jan 1 00:00:00 1970 From: peter.ujfalusi@ti.com (Peter Ujfalusi) Date: Mon, 30 Jul 2018 12:46:14 +0300 Subject: [RFC] dmaengine: Add metadat_ops for dma_async_tx_descriptor In-Reply-To: <20180724111425.GK3219@vkoul-mobl> References: <32208a9c-2b15-d345-1432-f1e387531f9b@ti.com> <20180601102429.16429-1-peter.ujfalusi@ti.com> <20180710055230.GB3219@vkoul-mobl> <052ebdd9-7e68-5b78-52c3-304376f48777@ti.com> <20180719092224.GK3219@vkoul-mobl> <20180724111425.GK3219@vkoul-mobl> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Vinod, On 2018-07-24 14:14, Vinod wrote: >>>> Clients must not mix the two way of handling the metadata. >>>> The set_len() is intended to tell the DMA driver the client provided >>>> metadata size (in MEM_TO_DEV case mostly). >>>> >>>> MEM_TO_DEV flow on client side: >>>> get_ptr() >>>> fill in the metadata to the pointer (not exceeding max_len) >>>> set_len() to tell the DMA driver the amount of valid bytes written >>>> >>>> DEV_TO_MEM flow on client side: >>>> In the completion callback, get_ptr() >>>> the metadata is payload_len bytes and can be accessed in the return pointer. >>> >>> I would think to unify this.. >> >> I have tried it, but the attach mode and the pointer mode is hard to >> handle with a generic API. >> I will try to find a way to unify things in a sane way. > > Hmmm, looking from the description they will be for different methods, > so lets make them orthogonal and not allow driver to register both. I would allow DMA drivers to register both, but somehow enforce that clients are not mixing the two distinct way of dealing with the metadata. The reason for that is for example the attach mode is the simplest (I implemented it first and I have a client using it), but if the pointer mode is found to be more efficient and feasible for the DMA then the DMA driver can implement that mode and the client can move as well w/o breaking anything. > >> >> I have moved the metadata_ops to dma_async_tx_descriptor to emphasize >> that it is per descriptor setting: >> https://github.com/omap-audio/linux-audio/commit/02e095d1320a4bb3ae281ddb208ce82ead746f00#diff-92c0a79f414dc3be9dfc67a969c0dd71 >> >> >>>> BTW: The driver which is going to need this is now accessible in public: >>>> https://git.ti.com/ti-linux-kernel/ti-linux-kernel/trees/ti-linux-4.14.y/drivers/dma/ti >>>> >>>> or in my wip tree: >>>> https://github.com/omap-audio/linux-audio/tree/peter/ti-linux-4.14.y/wip/drivers/dma/ti >>>> >>>> prefixed with k3-* >>>> >> >> - P?ter >> >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. >> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > - P?ter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki