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: [v2,2/2] dmaengine: uniphier-mdmac: add UniPhier MIO DMAC driver From: Vinod Koul Message-Id: <20180912043530.GE2766@vkoul-mobl> Date: Wed, 12 Sep 2018 10:05:30 +0530 To: Masahiro Yamada Cc: "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" , DTML , Rob Herring , Linux Kernel Mailing List , Masami Hiramatsu , Jassi Brar , Dan Williams , linux-arm-kernel List-ID: T24gMTItMDktMTgsIDEyOjAxLCBNYXNhaGlybyBZYW1hZGEgd3JvdGU6Cj4gSGkgVmlub2QsCj4g Cj4gCj4gMjAxOC0wOS0xMSAxNjowMCBHTVQrMDk6MDAgVmlub2QgPHZrb3VsQGtlcm5lbC5vcmc+ Ogo+ID4gT24gMjQtMDgtMTgsIDEwOjQxLCBNYXNhaGlybyBZYW1hZGEgd3JvdGU6Cj4gPgo+ID4+ ICsvKiBtYy0+dmMubG9jayBtdXN0IGJlIGhlbGQgYnkgY2FsbGVyICovCj4gPj4gK3N0YXRpYyB1 MzIgX191bmlwaGllcl9tZG1hY19nZXRfcmVzaWR1ZShzdHJ1Y3QgdW5pcGhpZXJfbWRtYWNfZGVz YyAqbWQpCj4gPj4gK3sKPiA+PiArICAgICB1MzIgcmVzaWR1ZSA9IDA7Cj4gPj4gKyAgICAgaW50 IGk7Cj4gPj4gKwo+ID4+ICsgICAgIGZvciAoaSA9IG1kLT5zZ19jdXI7IGkgPCBtZC0+c2dfbGVu OyBpKyspCj4gPj4gKyAgICAgICAgICAgICByZXNpZHVlICs9IHNnX2RtYV9sZW4oJm1kLT5zZ2xb aV0pOwo+ID4KPiA+IHNvIGlmIHRoZSBkZXNjcmlwdG9yIGlzIHN1Ym1pdHRlZCB0byBoYXJkd2Fy ZSwgd2UgcmV0dXJuIHRoZSBkZXNjcmlwdG9yCj4gPiBsZW5ndGgsIHdoaWNoIGlzIG5vdCBjb3Jy ZWN0Lgo+ID4KPiA+IFR3byBjYXNlcyBhcmUgcmVxdWlyZWQgdG8gYmUgaGFuZGxlZDoKPiA+IDEu IERlc2NyaXB0b3IgaXMgaW4gcXVldWUgKElNTyBhYm92ZSBsb2dpYyBpcyBmaW5lIGZvciB0aGF0 LCBidXQgaXQgY2FuCj4gPiBiZSBjYWxjdWxhdGVkIGF0IGRlc2NyaXB0b3Igc3VibWl0IGFuZCBs b29rZWQgdXAgaGVyZSkKPiAKPiBXaGVyZSBkbyB5b3Ugd2FudCBpdCB0byBiZSBjYWxjdWxhdGVk PwoKd2hlcmUgaXMgaXQgY2FsY3VsYXRlZCBub3c/Cgo+IFRoaXMgaGFyZHdhcmUgcHJvdmlkZXMg b25seSBzaW1wbGUgcmVnaXN0ZXJzIChhZGRyZXNzIGFuZCBzaXplKQo+IGZvciBvbmUtc2hvdCB0 cmFuc2ZlciBpbnN0ZWFkIG9mIGRlc2NyaXB0b3JzLgo+IAo+IFNvLCBJIHVzZWQgc2dsIGFzLWlz IGJlY2F1c2UgSSBkaWQgbm90IHNlZSBhIGdvb2QgcmVhc29uCj4gdG8gdHJhbnNmb3JtIHNnbCB0 byBhbm90aGVyIGRhdGEgc3RydWN0dXJlLgoKCj4gPiB0aGlzIHNlZW1zIG1pc3Npbmcgc3R1ZmYu IFdoZXJlIGRvIHlvdSBkbyByZWdpc3RlciBjYWxjdWxhdGlvbiBmb3IgdGhlCj4gPiBkZXNjcmlw dG9yIGFuZCB3aGVyZSBpcyBzbGF2ZV9jb25maWcgaGVyZSwgaG93IGRvIHlvdSBrbm93IHdoZXJl IHRvCj4gPiBzZW5kL3JlY2VpdmUgZGF0YSBmb3JtL3RvIChwZXJpcGhlcmFsKQo+IAo+IAo+IFRo aXMgZG1hYyBpcyByZWFsbHkgc2ltcGxlLCBhbmQgdW4tZmxleGlibGUuCj4gCj4gVGhlIHBlcmlw aGVyYWwgYWRkcmVzcyB0byBzZW5kL3JlY2VpdmUgZGF0YSBmcm9tL3RvIGlzIGhhcmQtd2VpcmQu Cj4gY2ZnLT57c3JjX2FkZHIsZHN0X2FkZHJ9IGlzIG5vdCBjb25maWd1cmFibGUuCj4gCj4gTG9v ayBhdCBfX3VuaXBoaWVyX21kbWFjX2hhbmRsZSgpLgo+ICdkZXN0X2FkZHInIGFuZCAnc3JjX2Fk ZHInIG11c3QgYmUgc2V0IHRvIDAgZm9yIHRoZSBwZXJpcGhlcmFsLgoKRmFpciBlbm91Z2gsIHdo YXQgYWJvdXQgb3RoZXIgdmFsdWVzIGxpa2UgYWRkcl93aWR0aCBhbmQgbWF4YnVyc3Q/Cg== 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=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,T_DKIMWL_WL_HIGH,USER_AGENT_MUTT 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 11ED8C46469 for ; Wed, 12 Sep 2018 04:35:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AAE1320880 for ; Wed, 12 Sep 2018 04:35:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Enra9o8u" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AAE1320880 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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 S1726501AbeILJiU (ORCPT ); Wed, 12 Sep 2018 05:38:20 -0400 Received: from mail.kernel.org ([198.145.29.99]:53224 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725738AbeILJiT (ORCPT ); Wed, 12 Sep 2018 05:38:19 -0400 Received: from localhost (unknown [171.76.126.1]) (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 66B08206B6; Wed, 12 Sep 2018 04:35:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1536726940; bh=qlSRNh7I87/Zh5D+AEgF5XtMMtu1XdLNhNmUK7gOOK0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Enra9o8u3YIS9CdDHTxMsdC8OdpD0pGmT7G1rebnLBkR1wnZgFYu8h41l3ul+0epF 9zloKau4KM8uxs2NkT0hPmOEfQPQ46nuGzA3TBDuQDvmUL/GD3YaFoR9n089mtw5NB P5oWLOuNM6UiI3lip1/VjuN2RYveDIA7TDJu2QqM= Date: Wed, 12 Sep 2018 10:05:30 +0530 From: Vinod To: Masahiro Yamada Cc: "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" , DTML , Rob Herring , Linux Kernel Mailing List , Masami Hiramatsu , Jassi Brar , Dan Williams , linux-arm-kernel Subject: Re: [PATCH v2 2/2] dmaengine: uniphier-mdmac: add UniPhier MIO DMAC driver Message-ID: <20180912043530.GE2766@vkoul-mobl> References: <1535074873-15617-1-git-send-email-yamada.masahiro@socionext.com> <1535074873-15617-3-git-send-email-yamada.masahiro@socionext.com> <20180911070003.GI2634@vkoul-mobl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 12-09-18, 12:01, Masahiro Yamada wrote: > Hi Vinod, > > > 2018-09-11 16:00 GMT+09:00 Vinod : > > On 24-08-18, 10:41, Masahiro Yamada wrote: > > > >> +/* mc->vc.lock must be held by caller */ > >> +static u32 __uniphier_mdmac_get_residue(struct uniphier_mdmac_desc *md) > >> +{ > >> + u32 residue = 0; > >> + int i; > >> + > >> + for (i = md->sg_cur; i < md->sg_len; i++) > >> + residue += sg_dma_len(&md->sgl[i]); > > > > so if the descriptor is submitted to hardware, we return the descriptor > > length, which is not correct. > > > > Two cases are required to be handled: > > 1. Descriptor is in queue (IMO above logic is fine for that, but it can > > be calculated at descriptor submit and looked up here) > > Where do you want it to be calculated? where is it calculated now? > This hardware provides only simple registers (address and size) > for one-shot transfer instead of descriptors. > > So, I used sgl as-is because I did not see a good reason > to transform sgl to another data structure. > > this seems missing stuff. Where do you do register calculation for the > > descriptor and where is slave_config here, how do you know where to > > send/receive data form/to (peripheral) > > > This dmac is really simple, and un-flexible. > > The peripheral address to send/receive data from/to is hard-weird. > cfg->{src_addr,dst_addr} is not configurable. > > Look at __uniphier_mdmac_handle(). > 'dest_addr' and 'src_addr' must be set to 0 for the peripheral. Fair enough, what about other values like addr_width and maxburst? -- ~Vinod From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vinod Subject: Re: [PATCH v2 2/2] dmaengine: uniphier-mdmac: add UniPhier MIO DMAC driver Date: Wed, 12 Sep 2018 10:05:30 +0530 Message-ID: <20180912043530.GE2766@vkoul-mobl> References: <1535074873-15617-1-git-send-email-yamada.masahiro@socionext.com> <1535074873-15617-3-git-send-email-yamada.masahiro@socionext.com> <20180911070003.GI2634@vkoul-mobl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Masahiro Yamada Cc: "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" , DTML , Rob Herring , Linux Kernel Mailing List , Masami Hiramatsu , Jassi Brar , Dan Williams , linux-arm-kernel List-Id: devicetree@vger.kernel.org On 12-09-18, 12:01, Masahiro Yamada wrote: > Hi Vinod, > > > 2018-09-11 16:00 GMT+09:00 Vinod : > > On 24-08-18, 10:41, Masahiro Yamada wrote: > > > >> +/* mc->vc.lock must be held by caller */ > >> +static u32 __uniphier_mdmac_get_residue(struct uniphier_mdmac_desc *md) > >> +{ > >> + u32 residue = 0; > >> + int i; > >> + > >> + for (i = md->sg_cur; i < md->sg_len; i++) > >> + residue += sg_dma_len(&md->sgl[i]); > > > > so if the descriptor is submitted to hardware, we return the descriptor > > length, which is not correct. > > > > Two cases are required to be handled: > > 1. Descriptor is in queue (IMO above logic is fine for that, but it can > > be calculated at descriptor submit and looked up here) > > Where do you want it to be calculated? where is it calculated now? > This hardware provides only simple registers (address and size) > for one-shot transfer instead of descriptors. > > So, I used sgl as-is because I did not see a good reason > to transform sgl to another data structure. > > this seems missing stuff. Where do you do register calculation for the > > descriptor and where is slave_config here, how do you know where to > > send/receive data form/to (peripheral) > > > This dmac is really simple, and un-flexible. > > The peripheral address to send/receive data from/to is hard-weird. > cfg->{src_addr,dst_addr} is not configurable. > > Look at __uniphier_mdmac_handle(). > 'dest_addr' and 'src_addr' must be set to 0 for the peripheral. Fair enough, what about other values like addr_width and maxburst? -- ~Vinod From mboxrd@z Thu Jan 1 00:00:00 1970 From: vkoul@kernel.org (Vinod) Date: Wed, 12 Sep 2018 10:05:30 +0530 Subject: [PATCH v2 2/2] dmaengine: uniphier-mdmac: add UniPhier MIO DMAC driver In-Reply-To: References: <1535074873-15617-1-git-send-email-yamada.masahiro@socionext.com> <1535074873-15617-3-git-send-email-yamada.masahiro@socionext.com> <20180911070003.GI2634@vkoul-mobl> Message-ID: <20180912043530.GE2766@vkoul-mobl> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 12-09-18, 12:01, Masahiro Yamada wrote: > Hi Vinod, > > > 2018-09-11 16:00 GMT+09:00 Vinod : > > On 24-08-18, 10:41, Masahiro Yamada wrote: > > > >> +/* mc->vc.lock must be held by caller */ > >> +static u32 __uniphier_mdmac_get_residue(struct uniphier_mdmac_desc *md) > >> +{ > >> + u32 residue = 0; > >> + int i; > >> + > >> + for (i = md->sg_cur; i < md->sg_len; i++) > >> + residue += sg_dma_len(&md->sgl[i]); > > > > so if the descriptor is submitted to hardware, we return the descriptor > > length, which is not correct. > > > > Two cases are required to be handled: > > 1. Descriptor is in queue (IMO above logic is fine for that, but it can > > be calculated at descriptor submit and looked up here) > > Where do you want it to be calculated? where is it calculated now? > This hardware provides only simple registers (address and size) > for one-shot transfer instead of descriptors. > > So, I used sgl as-is because I did not see a good reason > to transform sgl to another data structure. > > this seems missing stuff. Where do you do register calculation for the > > descriptor and where is slave_config here, how do you know where to > > send/receive data form/to (peripheral) > > > This dmac is really simple, and un-flexible. > > The peripheral address to send/receive data from/to is hard-weird. > cfg->{src_addr,dst_addr} is not configurable. > > Look at __uniphier_mdmac_handle(). > 'dest_addr' and 'src_addr' must be set to 0 for the peripheral. Fair enough, what about other values like addr_width and maxburst? -- ~Vinod