Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2909976imm; Wed, 16 May 2018 23:30:22 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo7BZAiKF+qaz9qWLX0WeoahRdjDq/f54enD1KylcEmmm6bZUTrWAbwY9ATQmwuEWCHXCKZ X-Received: by 2002:a17:902:6ac6:: with SMTP id i6-v6mr4085840plt.31.1526538622086; Wed, 16 May 2018 23:30:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526538622; cv=none; d=google.com; s=arc-20160816; b=ryhNk2uc7B06R5OA5ExSc1gZZ3HXUKoiQyRV9QPI/pyZg/ON6FwcSo+F8kaEQzh3sC i8l5nuvhlYBo939swp0pqaufZiO4clWRm8eJkB9m6ziVzpedyBEb+PVzm8lAUI4OlTsQ GMk/I48SYmlac19cJWbugHOHLrALWRbbhyIMvY8oyhYCZh1Kt8XddenTCgY0IGnhU7oV CyrrjCX2nKbEHT9qqGNfQ+B06rw7UTPnh7B8PHvN1FLNHVjY38RKMe6jLXKbp7GdwJ4N kD5NAEtXM18TrYg+UoYfE5jCzvM3lH+48e6BSpreoKo3BzkJTIGvdMtRNgFN/Jr10vlT ebfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=hCcmAkqeZD0u1DbZubISzFAiLbEzU4dPkdeuKwx6IzY=; b=ZEZXrXI4Uv7EF+0XE8XhTLupDGxTZwiTmyp68jCdMf2Dd2yrk7q5IfdXIKrIJ147c4 K9i/aYdYxSN1cc0Az9z+KKAZeASWK6N8HGsy7mA88mIMD3X4bnpjlKwVl6/FJUaG6pZH L6s2B19vwR5zIe0YcdUZO0uuM5wNLgZuh7vWhNOZNFD7ti6C2Q3r+NP4ZOjfQzpPkkL9 JMZc5am5LsDgzKr8TWptkn4NN3S3SfZGh+/PgYF0bouKvbjhy+Ii3SuU1F99VUoZb3wc x0Geyqsl6ONb6NjH1cTHRNUUYSJdV+btzY1A2JcnKsE7J1JaFWOGuTKz7/Y0XROhvMQi mHpQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=PKnQE+ws; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v64-v6si3537474pgv.528.2018.05.16.23.30.07; Wed, 16 May 2018 23:30:22 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=PKnQE+ws; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751907AbeEQG2j (ORCPT + 99 others); Thu, 17 May 2018 02:28:39 -0400 Received: from mail-ot0-f193.google.com ([74.125.82.193]:34714 "EHLO mail-ot0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751047AbeEQG2h (ORCPT ); Thu, 17 May 2018 02:28:37 -0400 Received: by mail-ot0-f193.google.com with SMTP id i5-v6so3830585otf.1 for ; Wed, 16 May 2018 23:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hCcmAkqeZD0u1DbZubISzFAiLbEzU4dPkdeuKwx6IzY=; b=PKnQE+wswCwgS14mjTQX7G13hjeSEoE/xX3ygB04vydteknZabCBN5dupE1I0kJYzq DhBJ7Gkyu/LxdWeagBFi+OGv/wlmNTt2Besy3R2wQZi6rNdN9X7DrDwyxI7NzyZJP4cj 2tGrkz3YvIrG+ngVxmSCbN5lbiSGadLX2wYr0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hCcmAkqeZD0u1DbZubISzFAiLbEzU4dPkdeuKwx6IzY=; b=r2aWc0VoipMgXyrpbxfXXqzVVXbm1JBvWAl2nzkBfOYmDzKLcYUtJS2aiyz8WXZRlS Vf5IcuNa313vFKbl/CPDDr73n/YFNiaJVdWkbSO7GNeOs9sFHDMo2BKZqKzimLp/MMYf N57vPZdub3dha9SMHGHwUw1/m1zGG2Wuny0N660VlfaI/XjKKt91CJVr5soG6GFgMJZl COpRUdU35bPekyZ4r7C/dP4VMIyVYCZaQy2CzHEvO2LpFObnHVB+f3EOoMLDFcYXMgtz LbBZETtp9uLXu8pB1Uwxc0Lq1+3mJEHMbbUEzJi/iWOwKSQLC0ejPSBhMl1+8A50SAG5 cH2w== X-Gm-Message-State: ALKqPwe3TZ7LITu/4WRhKTyX7yjHqlkCoJKKE2o4DXphXBAdHP8fgaiQ zleadezSOjLyrXFhvcPRNfbxEVgKhrhAolb8Zyt4kw== X-Received: by 2002:a9d:2fc8:: with SMTP id b8-v6mr2729894otd.177.1526538516610; Wed, 16 May 2018 23:28:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2d77:0:0:0:0:0 with HTTP; Wed, 16 May 2018 23:28:36 -0700 (PDT) In-Reply-To: <20180517061135.GV13271@vkoul-mobl> References: <08819489e52add194fecf2b4b234fff9deecdb4c.1526043689.git.baolin.wang@linaro.org> <85413038c111c58747194dd5736834be9adb0f20.1526043689.git.baolin.wang@linaro.org> <20180517051447.GS13271@vkoul-mobl> <20180517061135.GV13271@vkoul-mobl> From: Baolin Wang Date: Thu, 17 May 2018 14:28:36 +0800 Message-ID: Subject: Re: [PATCH v3 2/2] dmaengine: sprd: Add Spreadtrum DMA configuration To: Vinod Cc: Dan Williams , Eric Long , Mark Brown , dmaengine@vger.kernel.org, LKML 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 On 17 May 2018 at 14:11, Vinod wrote: > On 17-05-18, 14:02, Baolin Wang wrote: >> Hi Vinod, >> >> On 17 May 2018 at 13:14, Vinod wrote: >> > On 11-05-18, 21:06, Baolin Wang wrote: >> >> +struct sprd_dma_config { >> >> + struct dma_slave_config cfg; >> >> + u32 block_len; >> >> + u32 transcation_len; >> > >> > /s/transcation/transaction >> >> OK. >> >> > >> > now in code I see block_len and this filled by len which is sg_dma_len()? >> > So why two varibales when you are using only one. >> >> Like I explained before, we have transaction transfer, block transfer >> and fragment transfer, and we should set the length for each transfer. >> In future, we we will use these two variables in cyclic mode, but for >> prep_sg, we just make them equal to > > Please add them when you have use for it. Sorry linux kernel is not a place for > dumping future use work We now use them, since we have registers to configure, and we just set the same values for them now. >> >> > >> > Second, you are storing parameters programmed thru _prep call into >> > _dma_config. That is not correct. >> > >> > We use these to store channel parameters and NOT transaction parameters which >> > would differ with each txn. No wonder you can only support only 1 txn :) >> >> Fine, we can remove block_len/transcation_len from 'struct >> sprd_dma_config'. Any other issues for the 'struct sprd_dma_config'? > > Yes see the comments on prep_ OK. >> >> > >> > Lastly, if these are same values why not use src/dstn_max_burst? >> >> The fragment length will be filled by src/dstn_max_burst,so we can not >> use it again. >> >> > >> >> +static enum sprd_dma_datawidth >> >> +sprd_dma_get_datawidth(enum dma_slave_buswidth buswidth) >> >> +{ >> >> + switch (buswidth) { >> >> + case DMA_SLAVE_BUSWIDTH_1_BYTE: >> >> + case DMA_SLAVE_BUSWIDTH_2_BYTES: >> >> + case DMA_SLAVE_BUSWIDTH_4_BYTES: >> >> + case DMA_SLAVE_BUSWIDTH_8_BYTES: >> >> + return ffs(buswidth) - 1; >> >> + default: >> >> + return SPRD_DMA_DATAWIDTH_4_BYTES; >> > >> > Does default make sense, should we error out? >> >> Not one error, maybe we can give some warning information. > > well client programmed a wrong value, so I expect this to error out. OK. > >> >> > >> >> +static u32 sprd_dma_get_step(enum dma_slave_buswidth buswidth) >> >> +{ >> >> + switch (buswidth) { >> >> + case DMA_SLAVE_BUSWIDTH_1_BYTE: >> >> + case DMA_SLAVE_BUSWIDTH_2_BYTES: >> >> + case DMA_SLAVE_BUSWIDTH_4_BYTES: >> >> + case DMA_SLAVE_BUSWIDTH_8_BYTES: >> >> + return buswidth; >> >> + >> >> + default: >> >> + return SPRD_DMA_DWORD_STEP; >> > >> > Does default make sense, should we error out? >> >> Ditto. >> >> > >> >> +static int sprd_dma_config(struct dma_chan *chan, struct sprd_dma_desc *sdesc, >> >> + dma_addr_t src, dma_addr_t dst, >> >> + struct sprd_dma_config *slave_cfg) >> >> +{ >> >> + struct sprd_dma_dev *sdev = to_sprd_dma_dev(chan); >> >> + struct sprd_dma_chn *schan = to_sprd_dma_chan(chan); >> >> + struct sprd_dma_chn_hw *hw = &sdesc->chn_hw; >> >> + u32 fix_mode = 0, fix_en = 0, wrap_en = 0, wrap_mode = 0; >> >> + u32 src_datawidth, dst_datawidth, temp; >> >> + >> >> + if (slave_cfg->cfg.slave_id) >> >> + schan->dev_id = slave_cfg->cfg.slave_id; >> >> + >> >> + hw->cfg = SPRD_DMA_DONOT_WAIT_BDONE << SPRD_DMA_WAIT_BDONE_OFFSET; >> >> + >> >> + temp = slave_cfg->wrap_ptr & SPRD_DMA_LOW_ADDR_MASK; >> >> + temp |= (src >> SPRD_DMA_HIGH_ADDR_OFFSET) & SPRD_DMA_HIGH_ADDR_MASK; >> >> + hw->wrap_ptr = temp; >> >> + >> >> + temp = slave_cfg->wrap_to & SPRD_DMA_LOW_ADDR_MASK; >> >> + temp |= (dst >> SPRD_DMA_HIGH_ADDR_OFFSET) & SPRD_DMA_HIGH_ADDR_MASK; >> >> + hw->wrap_to = temp; >> >> + >> >> + hw->src_addr = src & SPRD_DMA_LOW_ADDR_MASK; >> >> + hw->des_addr = dst & SPRD_DMA_LOW_ADDR_MASK; >> >> + >> >> + if ((slave_cfg->src_step != 0 && slave_cfg->dst_step != 0) >> >> + || (slave_cfg->src_step | slave_cfg->dst_step) == 0) { >> > >> > this check doesnt seem right to me, what are you trying here? >> >> This is SPRD DMA internal feature: address-fix transfer. If the src >> step and dst step both are 0 or both are not 0, that means we can not >> enable the fix mode. >> If one is 0 and another one is not, we can enable the fix mode. > > A comment here would help explain this :) Sure. >> >> > >> >> + fix_en = 0; >> >> + } else { >> >> + fix_en = 1; >> >> + if (slave_cfg->src_step) >> >> + fix_mode = 1; >> >> + else >> >> + fix_mode = 0; >> >> + } >> >> + >> >> + if (slave_cfg->wrap_ptr && slave_cfg->wrap_to) { >> >> + wrap_en = 1; >> >> + if (slave_cfg->wrap_to == src) { >> >> + wrap_mode = 0; >> >> + } else if (slave_cfg->wrap_to == dst) { >> >> + wrap_mode = 1; >> >> + } else { >> >> + dev_err(sdev->dma_dev.dev, "invalid wrap mode\n"); >> >> + return -EINVAL; >> >> + } >> >> + } >> >> + >> >> + hw->intc = slave_cfg->int_mode | SPRD_DMA_CFG_ERR_INT_EN; >> >> + >> >> + src_datawidth = sprd_dma_get_datawidth(slave_cfg->cfg.src_addr_width); >> >> + dst_datawidth = sprd_dma_get_datawidth(slave_cfg->cfg.dst_addr_width); >> >> + >> >> + temp = src_datawidth << SPRD_DMA_SRC_DATAWIDTH_OFFSET; >> >> + temp |= dst_datawidth << SPRD_DMA_DES_DATAWIDTH_OFFSET; >> >> + temp |= slave_cfg->req_mode << SPRD_DMA_REQ_MODE_OFFSET; >> >> + temp |= wrap_mode << SPRD_DMA_WRAP_SEL_OFFSET; >> >> + temp |= wrap_en << SPRD_DMA_WRAP_EN_OFFSET; >> >> + temp |= fix_mode << SPRD_DMA_FIX_SEL_OFFSET; >> >> + temp |= fix_en << SPRD_DMA_FIX_EN_OFFSET; >> >> + temp |= slave_cfg->cfg.src_maxburst & SPRD_DMA_FRG_LEN_MASK; >> >> + hw->frg_len = temp; >> >> + >> >> + hw->blk_len = slave_cfg->block_len & SPRD_DMA_BLK_LEN_MASK; >> >> + hw->trsc_len = slave_cfg->transcation_len & SPRD_DMA_TRSC_LEN_MASK; >> >> + >> >> + temp = (slave_cfg->dst_step & SPRD_DMA_TRSF_STEP_MASK) << >> >> + SPRD_DMA_DEST_TRSF_STEP_OFFSET; >> >> + temp |= (slave_cfg->src_step & SPRD_DMA_TRSF_STEP_MASK) << >> >> + SPRD_DMA_SRC_TRSF_STEP_OFFSET; >> >> + hw->trsf_step = temp; >> >> + >> >> + hw->frg_step = 0; >> >> + hw->src_blk_step = 0; >> >> + hw->des_blk_step = 0; >> >> + return 0; >> >> +} >> >> +static struct dma_async_tx_descriptor * >> >> +sprd_dma_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl, >> >> + unsigned int sglen, enum dma_transfer_direction dir, >> >> + unsigned long flags, void *context) >> >> +{ >> >> + struct sprd_dma_chn *schan = to_sprd_dma_chan(chan); >> >> + struct sprd_dma_config *slave_cfg = &schan->slave_cfg; >> >> + u32 src_step = 0, dst_step = 0, len = 0; >> >> + dma_addr_t src = 0, dst = 0; >> >> + struct sprd_dma_desc *sdesc; >> >> + struct scatterlist *sg; >> >> + int ret, i; >> >> + >> >> + /* TODO: now we only support one sg for each DMA configuration. */ >> >> + if (!is_slave_direction(dir) || sglen > 1) >> >> + return NULL; >> >> + >> >> + sdesc = kzalloc(sizeof(*sdesc), GFP_NOWAIT); >> >> + if (!sdesc) >> >> + return NULL; >> >> + >> >> + for_each_sg(sgl, sg, sglen, i) { >> >> + len = sg_dma_len(sg); >> >> + >> >> + if (dir == DMA_MEM_TO_DEV) { >> >> + src = sg_dma_address(sg); >> >> + dst = slave_cfg->cfg.dst_addr; >> >> + src_step = sprd_dma_get_step(slave_cfg->cfg.src_addr_width); >> >> + dst_step = SPRD_DMA_NONE_STEP; >> >> + } else { >> >> + src = slave_cfg->cfg.src_addr; >> >> + dst = sg_dma_address(sg); >> >> + src_step = SPRD_DMA_NONE_STEP; >> >> + dst_step = sprd_dma_get_step(slave_cfg->cfg.dst_addr_width); >> >> + } >> >> + } >> >> + >> >> + sprd_dma_fill_config(slave_cfg, src_step, dst_step, len, flags); >> >> + >> >> + ret = sprd_dma_config(chan, sdesc, src, dst, slave_cfg); >> >> + if (ret) { >> >> + kfree(sdesc); >> >> + return NULL; >> >> + } >> > >> > Am more intrigued here, the above call fills you config struct but you do not >> > use it.. so what is the use of that. >> >> I did not get you here. We have passed the slave_cfg to >> sprd_dma_config() to configure DMA hardware channel. Thanks. > > But you are not using that... So why bother configuring! No, we used it. We use some configuration (src_maxburst, addr_width and slave id) from slave_cfg to configure our DMA hardware channel. > > Again this is a channel specific data structure and not transaction specific. > The values should go into descriptor and not something which is channel specific Make sense. -- Baolin.wang Best Regards