Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752856AbbBXQJl (ORCPT ); Tue, 24 Feb 2015 11:09:41 -0500 Received: from ns.mm-sol.com ([37.157.136.199]:37083 "EHLO extserv.mm-sol.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752506AbbBXQJj (ORCPT ); Tue, 24 Feb 2015 11:09:39 -0500 Message-ID: <1424794166.2340.17.camel@mm-sol.com> Subject: Re: [PATCH v2] spi: qup: Add DMA capabilities From: "Ivan T. Ivanov" To: Stanimir Varbanov Cc: Mark Brown , linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-spi@vger.kernel.org, Rob Herring , Mark Rutland , Kumar Gala , Andy Gross , Sagar Dharia , Daniel Sneddon Date: Tue, 24 Feb 2015 18:09:26 +0200 In-Reply-To: <1424782803-13103-1-git-send-email-stanimir.varbanov@linaro.org> References: <1424782803-13103-1-git-send-email-stanimir.varbanov@linaro.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.13.7-fta1.2~trusty Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4395 Lines: 171 Hi Stan, On Tue, 2015-02-24 at 15:00 +0200, Stanimir Varbanov wrote: > > #define SPI_MAX_RATE 50000000 > @@ -143,6 +147,11 @@ struct spi_qup { > int tx_bytes; > int rx_bytes; > int qup_v1; > + > + int dma_available; This is more like 'use dma for this transfer", right? > + struct dma_slave_configrx_conf; > + struct dma_slave_configtx_conf; > + atomic_t dma_outstanding; Do we really need this one. See below. > }; > > + > +static int spi_qup_prep_sg(struct spi_master *master, struct spi_transfer *xfer, > + enum dma_transfer_direction dir) > +{ > + struct spi_qup *qup = spi_master_get_devdata(master); > + unsigned long flags = DMA_PREP_INTERRUPT | DMA_PREP_FENCE; > + struct dma_async_tx_descriptor *desc; > + struct scatterlist *sgl; > + dma_cookie_t cookie; > + unsigned int nents; > + struct dma_chan *chan; > + int ret; > + > + if (dir == DMA_MEM_TO_DEV) { > + chan = master->dma_tx; > + nents = xfer->tx_sg.nents; > + sgl = xfer->tx_sg.sgl; > + } else { > + chan = master->dma_rx; > + nents = xfer->rx_sg.nents; > + sgl = xfer->rx_sg.sgl; > + } > + > + desc = dmaengine_prep_slave_sg(chan, sgl, nents, dir, flags); > + if (!desc) > + return -EINVAL; > + > + desc->callback = spi_qup_dma_done; > + desc->callback_param = qup; What if we attach callback only on RX descriptor and use dmaengine_tx_status() for TX channel in wait for completion? > + > + cookie = dmaengine_submit(desc); > + ret = dma_submit_error(cookie); > + if (ret) > + return ret; > + > + atomic_inc(&qup->dma_outstanding); > + > + return 0; > +} > + > +static int spi_qup_do_dma(struct spi_master *master, struct spi_transfer *xfer) > +{ > + struct spi_qup *qup = spi_master_get_devdata(master); > + int ret; > + > + atomic_set(&qup->dma_outstanding, 0); > + > + reinit_completion(&qup->done); Redundant, already done in transfer_one(). > + > + if (xfer->rx_buf) { Always true. > + ret = spi_qup_prep_sg(master, xfer, DMA_DEV_TO_MEM); > + if (ret) > + return ret; > + > + dma_async_issue_pending(master->dma_rx); > + } > + > + if (xfer->tx_buf) { Same. > + ret = spi_qup_prep_sg(master, xfer, DMA_MEM_TO_DEV); > + if (ret) > + goto err_rx; > + > + dma_async_issue_pending(master->dma_tx); > + } > + > + ret = spi_qup_set_state(qup, QUP_STATE_RUN); > + if (ret) { > + dev_warn(qup->dev, "cannot set RUN state\n"); > + goto err_tx; > + } > + > + if (!wait_for_completion_timeout(&qup->done, msecs_to_jiffies(1000))) { transfer_one() calculates timeout dynamically based on transfer length. Transition in state RUN and wait for completion are already coded in transfer_one(). With little rearrangement they could be removed from here. > + ret = -ETIMEDOUT; > + goto err_tx; > + } > + > + return 0; > + > +err_tx: > + if (xfer->tx_buf) Always true. > + dmaengine_terminate_all(master->dma_tx); > +err_rx: > + if (xfer->rx_buf) > Same. > + dmaengine_terminate_all(master->dma_rx); > + > + return ret; > +} I don't see reason for this function, based on comments so far :-). > > @@ -621,10 +881,16 @@ static int spi_qup_probe(struct platform_device *pdev) > writel_relaxed(0, base + SPI_CONFIG); > writel_relaxed(SPI_IO_C_NO_TRI_STATE, base + SPI_IO_CONTROL); > > + ret = spi_qup_init_dma(master, res->start); > + if (ret == -EPROBE_DEFER) > + goto error; Better move resource allocation before touching hardware. Otherwise is looking good and I know that is working :-) Regards, Ivan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/