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: <20180912072657.GF2766@vkoul-mobl> Date: Wed, 12 Sep 2018 12:56:57 +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: T24gMTItMDktMTgsIDE0OjI1LCBNYXNhaGlybyBZYW1hZGEgd3JvdGU6Cj4gMjAxOC0wOS0xMiAx MzozNSBHTVQrMDk6MDAgVmlub2QgPHZrb3VsQGtlcm5lbC5vcmc+Ogo+ID4gT24gMTItMDktMTgs IDEyOjAxLCBNYXNhaGlybyBZYW1hZGEgd3JvdGU6Cj4gPj4gSGkgVmlub2QsCj4gPj4KPiA+Pgo+ ID4+IDIwMTgtMDktMTEgMTY6MDAgR01UKzA5OjAwIFZpbm9kIDx2a291bEBrZXJuZWwub3JnPjoK PiA+PiA+IE9uIDI0LTA4LTE4LCAxMDo0MSwgTWFzYWhpcm8gWWFtYWRhIHdyb3RlOgo+ID4+ID4K PiA+PiA+PiArLyogbWMtPnZjLmxvY2sgbXVzdCBiZSBoZWxkIGJ5IGNhbGxlciAqLwo+ID4+ID4+ ICtzdGF0aWMgdTMyIF9fdW5pcGhpZXJfbWRtYWNfZ2V0X3Jlc2lkdWUoc3RydWN0IHVuaXBoaWVy X21kbWFjX2Rlc2MgKm1kKQo+ID4+ID4+ICt7Cj4gPj4gPj4gKyAgICAgdTMyIHJlc2lkdWUgPSAw Owo+ID4+ID4+ICsgICAgIGludCBpOwo+ID4+ID4+ICsKPiA+PiA+PiArICAgICBmb3IgKGkgPSBt ZC0+c2dfY3VyOyBpIDwgbWQtPnNnX2xlbjsgaSsrKQo+ID4+ID4+ICsgICAgICAgICAgICAgcmVz aWR1ZSArPSBzZ19kbWFfbGVuKCZtZC0+c2dsW2ldKTsKPiA+PiA+Cj4gPj4gPiBzbyBpZiB0aGUg ZGVzY3JpcHRvciBpcyBzdWJtaXR0ZWQgdG8gaGFyZHdhcmUsIHdlIHJldHVybiB0aGUgZGVzY3Jp cHRvcgo+ID4+ID4gbGVuZ3RoLCB3aGljaCBpcyBub3QgY29ycmVjdC4KPiA+PiA+Cj4gPj4gPiBU d28gY2FzZXMgYXJlIHJlcXVpcmVkIHRvIGJlIGhhbmRsZWQ6Cj4gPj4gPiAxLiBEZXNjcmlwdG9y IGlzIGluIHF1ZXVlIChJTU8gYWJvdmUgbG9naWMgaXMgZmluZSBmb3IgdGhhdCwgYnV0IGl0IGNh bgo+ID4+ID4gYmUgY2FsY3VsYXRlZCBhdCBkZXNjcmlwdG9yIHN1Ym1pdCBhbmQgbG9va2VkIHVw IGhlcmUpCj4gPj4KPiA+PiBXaGVyZSBkbyB5b3Ugd2FudCBpdCB0byBiZSBjYWxjdWxhdGVkPwo+ ID4KPiA+IHdoZXJlIGlzIGl0IGNhbGN1bGF0ZWQgbm93Pwo+IAo+IAo+IFBsZWFzZSBzZWUgX191 bmlwaGllcl9tZG1hY19oYW5kbGUoKS4KPiAKPiAKPiBJdCBnZXRzIHRoZSBhZGRyZXNzIGFuZCBz aXplIGJ5IHNnX2RtYV9hZGRyZXNzKCksIHNnX2RtYV9sZW4oKQo+IGp1c3QgYmVmb3JlIHNldHRp bmcgdGhlbSB0byB0aGUgaGFyZHdhcmUgcmVnaXN0ZXJzLgo+IAo+IAo+ICAgICAgICBzZyA9ICZt ZC0+c2dsW21kLT5zZ19jdXJdOwo+IAo+ICAgICAgICBpZiAobWQtPmRpciA9PSBETUFfTUVNX1RP X0RFVikgewo+ICAgICAgICAgICAgICAgIHNyY19tb2RlID0gVU5JUEhJRVJfTURNQUNfQ0hfTU9E RV9fQUREUl9JTkM7Cj4gICAgICAgICAgICAgICAgc3JjX2FkZHIgPSBzZ19kbWFfYWRkcmVzcyhz Zyk7Cj4gICAgICAgICAgICAgICAgZGVzdF9tb2RlID0gVU5JUEhJRVJfTURNQUNfQ0hfTU9ERV9f QUREUl9GSVhFRDsKPiAgICAgICAgICAgICAgICBkZXN0X2FkZHIgPSAwOwo+ICAgICAgICB9IGVs c2Ugewo+ICAgICAgICAgICAgICAgIHNyY19tb2RlID0gVU5JUEhJRVJfTURNQUNfQ0hfTU9ERV9f QUREUl9GSVhFRDsKPiAgICAgICAgICAgICAgICBzcmNfYWRkciA9IDA7Cj4gICAgICAgICAgICAg ICAgZGVzdF9tb2RlID0gVU5JUEhJRVJfTURNQUNfQ0hfTU9ERV9fQUREUl9JTkM7Cj4gICAgICAg ICAgICAgICAgZGVzdF9hZGRyID0gc2dfZG1hX2FkZHJlc3Moc2cpOwo+ICAgICAgICB9Cj4gCj4g Cj4gCj4gCj4gCj4gCj4gCj4gPj4gVGhpcyBoYXJkd2FyZSBwcm92aWRlcyBvbmx5IHNpbXBsZSBy ZWdpc3RlcnMgKGFkZHJlc3MgYW5kIHNpemUpCj4gPj4gZm9yIG9uZS1zaG90IHRyYW5zZmVyIGlu c3RlYWQgb2YgZGVzY3JpcHRvcnMuCj4gPj4KPiA+PiBTbywgSSB1c2VkIHNnbCBhcy1pcyBiZWNh dXNlIEkgZGlkIG5vdCBzZWUgYSBnb29kIHJlYXNvbgo+ID4+IHRvIHRyYW5zZm9ybSBzZ2wgdG8g YW5vdGhlciBkYXRhIHN0cnVjdHVyZS4KPiA+Cj4gPgo+ID4+ID4gdGhpcyBzZWVtcyBtaXNzaW5n IHN0dWZmLiBXaGVyZSBkbyB5b3UgZG8gcmVnaXN0ZXIgY2FsY3VsYXRpb24gZm9yIHRoZQo+ID4+ ID4gZGVzY3JpcHRvciBhbmQgd2hlcmUgaXMgc2xhdmVfY29uZmlnIGhlcmUsIGhvdyBkbyB5b3Ug a25vdyB3aGVyZSB0bwo+ID4+ID4gc2VuZC9yZWNlaXZlIGRhdGEgZm9ybS90byAocGVyaXBoZXJh bCkKPiA+Pgo+ID4+Cj4gPj4gVGhpcyBkbWFjIGlzIHJlYWxseSBzaW1wbGUsIGFuZCB1bi1mbGV4 aWJsZS4KPiA+Pgo+ID4+IFRoZSBwZXJpcGhlcmFsIGFkZHJlc3MgdG8gc2VuZC9yZWNlaXZlIGRh dGEgZnJvbS90byBpcyBoYXJkLXdlaXJkLgo+ID4+IGNmZy0+e3NyY19hZGRyLGRzdF9hZGRyfSBp cyBub3QgY29uZmlndXJhYmxlLgo+ID4+Cj4gPj4gTG9vayBhdCBfX3VuaXBoaWVyX21kbWFjX2hh bmRsZSgpLgo+ID4+ICdkZXN0X2FkZHInIGFuZCAnc3JjX2FkZHInIG11c3QgYmUgc2V0IHRvIDAg Zm9yIHRoZSBwZXJpcGhlcmFsLgo+ID4KPiA+IEZhaXIgZW5vdWdoLCB3aGF0IGFib3V0IG90aGVy IHZhbHVlcyBsaWtlIGFkZHJfd2lkdGggYW5kIG1heGJ1cnN0Pwo+IAo+IAo+IE5vbmUgb2YgdGhl bSBpcyBjb25maWd1cmFibGUuCgp3aGF0IGlzIGNvbmZpZ3VyYWJsZSBoZXJlIDotKQoKV2hvIGFy ZSB0aGUgdXNlcnMgb2YgdGhpcyBETUE/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 1273CC4646A for ; Wed, 12 Sep 2018 07:27:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AA22420866 for ; Wed, 12 Sep 2018 07:27:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="d5C3lHe8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA22420866 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 S1727246AbeILMaV (ORCPT ); Wed, 12 Sep 2018 08:30:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:35022 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726471AbeILMaV (ORCPT ); Wed, 12 Sep 2018 08:30:21 -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 1966F206B6; Wed, 12 Sep 2018 07:27:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1536737227; bh=PbtZphGkZNv2BaFgvbYXmZ8yCeOgTP9Nbv6xg+nYhiM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=d5C3lHe86Crtqn16D5uERb91DmXK6yIFf3Hb67Vm8YMunoAilXdJqbtPliXxQM4xI pp1GuXHnPLCmBmTqPwb7GoWweafCuipNjqHhIDDhJW4A//cGF9GtZEouBUjo3azBVy 4lGKr7wD80KS4/7a7tUTZ731cV77sacjt+Txgrmc= Date: Wed, 12 Sep 2018 12:56:57 +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: <20180912072657.GF2766@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> <20180912043530.GE2766@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, 14:25, Masahiro Yamada wrote: > 2018-09-12 13:35 GMT+09:00 Vinod : > > 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? > > > Please see __uniphier_mdmac_handle(). > > > It gets the address and size by sg_dma_address(), sg_dma_len() > just before setting them to the hardware registers. > > > sg = &md->sgl[md->sg_cur]; > > if (md->dir == DMA_MEM_TO_DEV) { > src_mode = UNIPHIER_MDMAC_CH_MODE__ADDR_INC; > src_addr = sg_dma_address(sg); > dest_mode = UNIPHIER_MDMAC_CH_MODE__ADDR_FIXED; > dest_addr = 0; > } else { > src_mode = UNIPHIER_MDMAC_CH_MODE__ADDR_FIXED; > src_addr = 0; > dest_mode = UNIPHIER_MDMAC_CH_MODE__ADDR_INC; > dest_addr = sg_dma_address(sg); > } > > > > > > > > >> 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? > > > None of them is configurable. what is configurable here :-) Who are the users of this DMA? -- ~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 12:56:57 +0530 Message-ID: <20180912072657.GF2766@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> <20180912043530.GE2766@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, 14:25, Masahiro Yamada wrote: > 2018-09-12 13:35 GMT+09:00 Vinod : > > 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? > > > Please see __uniphier_mdmac_handle(). > > > It gets the address and size by sg_dma_address(), sg_dma_len() > just before setting them to the hardware registers. > > > sg = &md->sgl[md->sg_cur]; > > if (md->dir == DMA_MEM_TO_DEV) { > src_mode = UNIPHIER_MDMAC_CH_MODE__ADDR_INC; > src_addr = sg_dma_address(sg); > dest_mode = UNIPHIER_MDMAC_CH_MODE__ADDR_FIXED; > dest_addr = 0; > } else { > src_mode = UNIPHIER_MDMAC_CH_MODE__ADDR_FIXED; > src_addr = 0; > dest_mode = UNIPHIER_MDMAC_CH_MODE__ADDR_INC; > dest_addr = sg_dma_address(sg); > } > > > > > > > > >> 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? > > > None of them is configurable. what is configurable here :-) Who are the users of this DMA? -- ~Vinod From mboxrd@z Thu Jan 1 00:00:00 1970 From: vkoul@kernel.org (Vinod) Date: Wed, 12 Sep 2018 12:56:57 +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> <20180912043530.GE2766@vkoul-mobl> Message-ID: <20180912072657.GF2766@vkoul-mobl> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 12-09-18, 14:25, Masahiro Yamada wrote: > 2018-09-12 13:35 GMT+09:00 Vinod : > > 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? > > > Please see __uniphier_mdmac_handle(). > > > It gets the address and size by sg_dma_address(), sg_dma_len() > just before setting them to the hardware registers. > > > sg = &md->sgl[md->sg_cur]; > > if (md->dir == DMA_MEM_TO_DEV) { > src_mode = UNIPHIER_MDMAC_CH_MODE__ADDR_INC; > src_addr = sg_dma_address(sg); > dest_mode = UNIPHIER_MDMAC_CH_MODE__ADDR_FIXED; > dest_addr = 0; > } else { > src_mode = UNIPHIER_MDMAC_CH_MODE__ADDR_FIXED; > src_addr = 0; > dest_mode = UNIPHIER_MDMAC_CH_MODE__ADDR_INC; > dest_addr = sg_dma_address(sg); > } > > > > > > > > >> 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? > > > None of them is configurable. what is configurable here :-) Who are the users of this DMA? -- ~Vinod