Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2897504imm; Wed, 16 May 2018 23:13:27 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoVF9zVJ6OtyTy1w/qRQUcVk6c7OG3hz7yGwmxOb6TnCsd9Hr/iMBZUOT3avg5MsZHJ4p/T X-Received: by 2002:a17:902:6b45:: with SMTP id g5-v6mr3993486plt.67.1526537607898; Wed, 16 May 2018 23:13:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526537607; cv=none; d=google.com; s=arc-20160816; b=cFIEhUFr2A9P7OT6xaNLvPgcyU9JqkDHgsZG4VhzMlFx/bXfaZrvpheFWDRUcnAwoL 6U1owrzSJnvxDYN/oXLNd+9FyT0x4KouCjQAdFiFM5/4r9CHJytfetO6M7K7cMZ3f/Yg uscLkUT5bERc3DurbwDBcg/yr7ANkOXR3Ygzm6KEAcYh1ChkIkBFlc3hb4oV7gUTE89Z KG6nWeNXktA8HvtL92rBdDtR9cy8XhA1e6QyYAPyadmFmJs7bqKauIyYLG9B6xbsy0dq eidoMzWHmFClt4aT1/APw7rnMM1sxbi9lOni3H9zkisC3XIW2fTnJV07FbyVge4Hmdp/ E7Yw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=/QygqS1OzcS4gHcqE5tPqdrR/cgRYpHYwXz726BDTfg=; b=QSnKPIF+O6l/YipYACzb8eSMlbJ+w6pozFe+4D0Sjvo+gZIdbuJ6WCGiuxSeEGSSWW 6TpcDg5tbtaNMs6ioKyN0T9qpenVkx+FGsn92zQE4drC4CxVYDALxnr68xr/CfKafZWQ 3ifLtuUNDaeZRt5ypoAyxQOggGoQ7igoLwO+XQ4ohNEgSQU03sETkc+sUfvNUVRzViVV vdWA3PMOB2CBpc7UBH7ATv8ci6TvALO8KMPhEZqsE095+YQmZZhK4J9U06IY6o/rAIHf OMEz0yJIYZoGRqFQIEge0QH3ureB2OQPfMnfsRPETjmaPuw3TVQ/RCgZaxXFWr4TfOf3 a1CQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=KTMJnzK5; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a1-v6si4254729pls.523.2018.05.16.23.13.13; Wed, 16 May 2018 23:13:27 -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=@kernel.org header.s=default header.b=KTMJnzK5; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751850AbeEQGLq (ORCPT + 99 others); Thu, 17 May 2018 02:11:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:55596 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751396AbeEQGLo (ORCPT ); Thu, 17 May 2018 02:11:44 -0400 Received: from localhost (unknown [106.200.239.118]) (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 4BACF20657; Thu, 17 May 2018 06:11:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1526537504; bh=lknjWKEmhXnX2AxE9aBksZdQaZAvNdU3yPTJhroqtaI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KTMJnzK5+zAYcuNQDBfhUt0ALC6ZgDhmRlZFL5tPfGBINM4li/X7qdkHIKZ/0+2/l BxLAVpvMOPSoBzT0Bxzn6DJ62v6kPda+dtIZvfGmV1AN+WJlH584C2uFqmyOAtHswE lARJ9oWFIL9M5ZUZiplqKmYW8Kt2NIIHEID8I3jE= Date: Thu, 17 May 2018 11:41:35 +0530 From: Vinod To: Baolin Wang Cc: Dan Williams , Eric Long , Mark Brown , dmaengine@vger.kernel.org, LKML Subject: Re: [PATCH v3 2/2] dmaengine: sprd: Add Spreadtrum DMA configuration Message-ID: <20180517061135.GV13271@vkoul-mobl> References: <08819489e52add194fecf2b4b234fff9deecdb4c.1526043689.git.baolin.wang@linaro.org> <85413038c111c58747194dd5736834be9adb0f20.1526043689.git.baolin.wang@linaro.org> <20180517051447.GS13271@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 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 > > > > > 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_ > > > > > 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. > > > > >> +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 :) > > > > >> + 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! 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 -- ~Vinod