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: Masahiro Yamada Message-Id: Date: Wed, 12 Sep 2018 14:25:38 +0900 To: Vinod 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: MjAxOC0wOS0xMiAxMzozNSBHTVQrMDk6MDAgVmlub2QgPHZrb3VsQGtlcm5lbC5vcmc+Ogo+IE9u IDEyLTA5LTE4LCAxMjowMSwgTWFzYWhpcm8gWWFtYWRhIHdyb3RlOgo+PiBIaSBWaW5vZCwKPj4K Pj4KPj4gMjAxOC0wOS0xMSAxNjowMCBHTVQrMDk6MDAgVmlub2QgPHZrb3VsQGtlcm5lbC5vcmc+ Ogo+PiA+IE9uIDI0LTA4LTE4LCAxMDo0MSwgTWFzYWhpcm8gWWFtYWRhIHdyb3RlOgo+PiA+Cj4+ ID4+ICsvKiBtYy0+dmMubG9jayBtdXN0IGJlIGhlbGQgYnkgY2FsbGVyICovCj4+ID4+ICtzdGF0 aWMgdTMyIF9fdW5pcGhpZXJfbWRtYWNfZ2V0X3Jlc2lkdWUoc3RydWN0IHVuaXBoaWVyX21kbWFj X2Rlc2MgKm1kKQo+PiA+PiArewo+PiA+PiArICAgICB1MzIgcmVzaWR1ZSA9IDA7Cj4+ID4+ICsg ICAgIGludCBpOwo+PiA+PiArCj4+ID4+ICsgICAgIGZvciAoaSA9IG1kLT5zZ19jdXI7IGkgPCBt ZC0+c2dfbGVuOyBpKyspCj4+ID4+ICsgICAgICAgICAgICAgcmVzaWR1ZSArPSBzZ19kbWFfbGVu KCZtZC0+c2dsW2ldKTsKPj4gPgo+PiA+IHNvIGlmIHRoZSBkZXNjcmlwdG9yIGlzIHN1Ym1pdHRl ZCB0byBoYXJkd2FyZSwgd2UgcmV0dXJuIHRoZSBkZXNjcmlwdG9yCj4+ID4gbGVuZ3RoLCB3aGlj aCBpcyBub3QgY29ycmVjdC4KPj4gPgo+PiA+IFR3byBjYXNlcyBhcmUgcmVxdWlyZWQgdG8gYmUg aGFuZGxlZDoKPj4gPiAxLiBEZXNjcmlwdG9yIGlzIGluIHF1ZXVlIChJTU8gYWJvdmUgbG9naWMg aXMgZmluZSBmb3IgdGhhdCwgYnV0IGl0IGNhbgo+PiA+IGJlIGNhbGN1bGF0ZWQgYXQgZGVzY3Jp cHRvciBzdWJtaXQgYW5kIGxvb2tlZCB1cCBoZXJlKQo+Pgo+PiBXaGVyZSBkbyB5b3Ugd2FudCBp dCB0byBiZSBjYWxjdWxhdGVkPwo+Cj4gd2hlcmUgaXMgaXQgY2FsY3VsYXRlZCBub3c/CgoKUGxl YXNlIHNlZSBfX3VuaXBoaWVyX21kbWFjX2hhbmRsZSgpLgoKCkl0IGdldHMgdGhlIGFkZHJlc3Mg YW5kIHNpemUgYnkgc2dfZG1hX2FkZHJlc3MoKSwgc2dfZG1hX2xlbigpCmp1c3QgYmVmb3JlIHNl dHRpbmcgdGhlbSB0byB0aGUgaGFyZHdhcmUgcmVnaXN0ZXJzLgoKCiAgICAgICBzZyA9ICZtZC0+ c2dsW21kLT5zZ19jdXJdOwoKICAgICAgIGlmIChtZC0+ZGlyID09IERNQV9NRU1fVE9fREVWKSB7 CiAgICAgICAgICAgICAgIHNyY19tb2RlID0gVU5JUEhJRVJfTURNQUNfQ0hfTU9ERV9fQUREUl9J TkM7CiAgICAgICAgICAgICAgIHNyY19hZGRyID0gc2dfZG1hX2FkZHJlc3Moc2cpOwogICAgICAg ICAgICAgICBkZXN0X21vZGUgPSBVTklQSElFUl9NRE1BQ19DSF9NT0RFX19BRERSX0ZJWEVEOwog ICAgICAgICAgICAgICBkZXN0X2FkZHIgPSAwOwogICAgICAgfSBlbHNlIHsKICAgICAgICAgICAg ICAgc3JjX21vZGUgPSBVTklQSElFUl9NRE1BQ19DSF9NT0RFX19BRERSX0ZJWEVEOwogICAgICAg ICAgICAgICBzcmNfYWRkciA9IDA7CiAgICAgICAgICAgICAgIGRlc3RfbW9kZSA9IFVOSVBISUVS X01ETUFDX0NIX01PREVfX0FERFJfSU5DOwogICAgICAgICAgICAgICBkZXN0X2FkZHIgPSBzZ19k bWFfYWRkcmVzcyhzZyk7CiAgICAgICB9CgoKCgoKCgo+PiBUaGlzIGhhcmR3YXJlIHByb3ZpZGVz IG9ubHkgc2ltcGxlIHJlZ2lzdGVycyAoYWRkcmVzcyBhbmQgc2l6ZSkKPj4gZm9yIG9uZS1zaG90 IHRyYW5zZmVyIGluc3RlYWQgb2YgZGVzY3JpcHRvcnMuCj4+Cj4+IFNvLCBJIHVzZWQgc2dsIGFz LWlzIGJlY2F1c2UgSSBkaWQgbm90IHNlZSBhIGdvb2QgcmVhc29uCj4+IHRvIHRyYW5zZm9ybSBz Z2wgdG8gYW5vdGhlciBkYXRhIHN0cnVjdHVyZS4KPgo+Cj4+ID4gdGhpcyBzZWVtcyBtaXNzaW5n IHN0dWZmLiBXaGVyZSBkbyB5b3UgZG8gcmVnaXN0ZXIgY2FsY3VsYXRpb24gZm9yIHRoZQo+PiA+ IGRlc2NyaXB0b3IgYW5kIHdoZXJlIGlzIHNsYXZlX2NvbmZpZyBoZXJlLCBob3cgZG8geW91IGtu b3cgd2hlcmUgdG8KPj4gPiBzZW5kL3JlY2VpdmUgZGF0YSBmb3JtL3RvIChwZXJpcGhlcmFsKQo+ Pgo+Pgo+PiBUaGlzIGRtYWMgaXMgcmVhbGx5IHNpbXBsZSwgYW5kIHVuLWZsZXhpYmxlLgo+Pgo+ PiBUaGUgcGVyaXBoZXJhbCBhZGRyZXNzIHRvIHNlbmQvcmVjZWl2ZSBkYXRhIGZyb20vdG8gaXMg aGFyZC13ZWlyZC4KPj4gY2ZnLT57c3JjX2FkZHIsZHN0X2FkZHJ9IGlzIG5vdCBjb25maWd1cmFi bGUuCj4+Cj4+IExvb2sgYXQgX191bmlwaGllcl9tZG1hY19oYW5kbGUoKS4KPj4gJ2Rlc3RfYWRk cicgYW5kICdzcmNfYWRkcicgbXVzdCBiZSBzZXQgdG8gMCBmb3IgdGhlIHBlcmlwaGVyYWwuCj4K PiBGYWlyIGVub3VnaCwgd2hhdCBhYm91dCBvdGhlciB2YWx1ZXMgbGlrZSBhZGRyX3dpZHRoIGFu ZCBtYXhidXJzdD8KCgpOb25lIG9mIHRoZW0gaXMgY29uZmlndXJhYmxlLgo= 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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS 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 1923CC4646A for ; Wed, 12 Sep 2018 05:26:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B09E720833 for ; Wed, 12 Sep 2018 05:26:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=nifty.com header.i=@nifty.com header.b="2tpfFs1Y" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B09E720833 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=socionext.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 S1726839AbeILK3S (ORCPT ); Wed, 12 Sep 2018 06:29:18 -0400 Received: from conssluserg-02.nifty.com ([210.131.2.81]:37861 "EHLO conssluserg-02.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726149AbeILK3S (ORCPT ); Wed, 12 Sep 2018 06:29:18 -0400 Received: from mail-ua1-f48.google.com (mail-ua1-f48.google.com [209.85.222.48]) (authenticated) by conssluserg-02.nifty.com with ESMTP id w8C5QJe6003121; Wed, 12 Sep 2018 14:26:20 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com w8C5QJe6003121 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1536729980; bh=vxwFZNLJCSXqK3vw/FgAkVmwXu0AACz8wEA5VL7EgLQ=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=2tpfFs1Y3kJ6ssdS9US57o5RA1AX5et/Hf/p5pRGEkNc/M2roiDzSkeeVvnNkngMT owJm69hkRK1+3jlemkR2SpNUmU5JVMWRVIF72I8BLpQ1jJjj7Yg4u/eBM3X1wKoi5T APtpzDVMIS8LbzoTlC/nRxlUXC4b38K7ZpDsBV/mangzZ6PtI0pDNEGRp5B7PNF6Zo IeFjHKbNgf6nXnCSMH77xSVEfzeSh9GhUu24vuUw+OezWyYG2IJptnbIf9t9TcYkXw MNvTyBM76zLg67QCb24Uz4TqQ3EvnL+9fi7aNmAkzwdxZmhiFDu4RIdzBaGrQfkSJ7 t/pZ/MwPqPhyA== X-Nifty-SrcIP: [209.85.222.48] Received: by mail-ua1-f48.google.com with SMTP id m26-v6so670386uap.2; Tue, 11 Sep 2018 22:26:19 -0700 (PDT) X-Gm-Message-State: APzg51Duw9lO3Sr/5VzyZ/9Gko77If7CQlgtiOMpNN8lEwozvgfArGj4 qh+wfQs9PeoZqGrGOxwfNF/Pcm2FZacZa9LqQYk= X-Google-Smtp-Source: ANB0VdYMKfGLdIsXixtCVHTnvaN4XOjAATdjpuuwq1aEPJ77cIViVTXrJSIFZJ4WFhYjml9y8762Z/uw9/BBy2W1UZ4= X-Received: by 2002:ab0:4f17:: with SMTP id n23-v6mr64735uah.135.1536729978695; Tue, 11 Sep 2018 22:26:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:7111:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 22:25:38 -0700 (PDT) In-Reply-To: <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> <20180912043530.GE2766@vkoul-mobl> From: Masahiro Yamada Date: Wed, 12 Sep 2018 14:25:38 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 2/2] dmaengine: uniphier-mdmac: add UniPhier MIO DMAC driver To: Vinod Cc: "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" , DTML , Rob Herring , Linux Kernel Mailing List , Masami Hiramatsu , Jassi Brar , Dan Williams , linux-arm-kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. -- Best Regards Masahiro Yamada From mboxrd@z Thu Jan 1 00:00:00 1970 From: Masahiro Yamada Subject: Re: [PATCH v2 2/2] dmaengine: uniphier-mdmac: add UniPhier MIO DMAC driver Date: Wed, 12 Sep 2018 14:25:38 +0900 Message-ID: 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="UTF-8" Return-path: In-Reply-To: <20180912043530.GE2766@vkoul-mobl> Sender: linux-kernel-owner@vger.kernel.org To: Vinod 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 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. -- Best Regards Masahiro Yamada From mboxrd@z Thu Jan 1 00:00:00 1970 From: yamada.masahiro@socionext.com (Masahiro Yamada) Date: Wed, 12 Sep 2018 14:25:38 +0900 Subject: [PATCH v2 2/2] dmaengine: uniphier-mdmac: add UniPhier MIO DMAC driver In-Reply-To: <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> <20180912043530.GE2766@vkoul-mobl> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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. -- Best Regards Masahiro Yamada