From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 6/7] spi/s3c64xx: Add support DMA engine API
Date: Tue, 5 Jul 2011 08:48:06 +0100 [thread overview]
Message-ID: <20110705074806.GN8286@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1309781915-31549-7-git-send-email-kgene.kim@samsung.com>
On Mon, Jul 04, 2011 at 09:18:34PM +0900, Kukjin Kim wrote:
> static void enable_datapath(struct s3c64xx_spi_driver_data *sdd,
> struct spi_device *spi,
> struct spi_transfer *xfer, int dma_mode)
> @@ -236,6 +322,11 @@ static void enable_datapath(struct s3c64xx_spi_driver_data *sdd,
> struct s3c64xx_spi_info *sci = sdd->cntrlr_info;
> void __iomem *regs = sdd->regs;
> u32 modecfg, chcfg;
> +#if defined(CONFIG_DMADEV_PL330)
> + struct dma_slave_config slave_config;
> + struct scatterlist tx_sg;
> + struct scatterlist rx_sg;
> +#endif
>
> modecfg = readl(regs + S3C64XX_SPI_MODE_CFG);
> modecfg &= ~(S3C64XX_SPI_MODE_TXDMA_ON | S3C64XX_SPI_MODE_RXDMA_ON);
> @@ -261,10 +352,34 @@ static void enable_datapath(struct s3c64xx_spi_driver_data *sdd,
> chcfg |= S3C64XX_SPI_CH_TXCH_ON;
> if (dma_mode) {
> modecfg |= S3C64XX_SPI_MODE_TXDMA_ON;
> +#if defined(CONFIG_DMADEV_PL330)
> + memset(&slave_config, 0, sizeof(slave_config));
> + slave_config.direction = DMA_TO_DEVICE;
> + slave_config.src_addr = xfer->tx_dma;
If you're doing DMA to the device, you should not set src_addr here.
That comes from the SG list passed in via the prep function.
> + slave_config.dst_addr =
> + sdd->sfr_start + S3C64XX_SPI_TX_DATA;
> + slave_config.dst_addr_width = sdd->cur_bpw / 8;
> + dmaengine_slave_config(sdd->tx_chan, &slave_config);
> +
> + sg_init_table(&tx_sg, 1);
> + sg_set_page(&tx_sg, pfn_to_page(PFN_DOWN(xfer->tx_dma)),
> + xfer->len, offset_in_page(xfer->tx_dma));
> + sg_dma_len(&tx_sg) = xfer->len;
> + sg_dma_address(&tx_sg) = xfer->tx_dma;
> + sdd->tx_desc =
> + sdd->tx_chan->device->device_prep_slave_sg(
> + sdd->tx_chan, &tx_sg, 1, DMA_TO_DEVICE,
> + DMA_PREP_INTERRUPT);
> + sdd->tx_desc->callback = s3c64xx_spi_dma_txcb;
> + sdd->tx_desc->callback_param = sdd;
> + dmaengine_submit(sdd->tx_desc);
> + dma_async_issue_pending(sdd->tx_chan);
> +#else
> s3c2410_dma_config(sdd->tx_dmach, sdd->cur_bpw / 8);
> s3c2410_dma_enqueue(sdd->tx_dmach, (void *)sdd,
> xfer->tx_dma, xfer->len);
> s3c2410_dma_ctrl(sdd->tx_dmach, S3C2410_DMAOP_START);
> +#endif
> } else {
> switch (sdd->cur_bpw) {
> case 32:
> @@ -296,10 +411,33 @@ static void enable_datapath(struct s3c64xx_spi_driver_data *sdd,
> writel(((xfer->len * 8 / sdd->cur_bpw) & 0xffff)
> | S3C64XX_SPI_PACKET_CNT_EN,
> regs + S3C64XX_SPI_PACKET_CNT);
> +#if defined(CONFIG_DMADEV_PL330)
> + slave_config.direction = DMA_FROM_DEVICE;
> + slave_config.dst_addr = xfer->rx_dma;
If you're doing DMA from the device, you should not set dst_addr here.
That comes from the SG list passed in via the prep function.
> + slave_config.src_addr =
> + sdd->sfr_start + S3C64XX_SPI_RX_DATA;
> + slave_config.src_addr_width = sdd->cur_bpw / 8;
> + dmaengine_slave_config(sdd->rx_chan, &slave_config);
> +
> + sg_init_table(&rx_sg, 1);
> + sg_set_page(&rx_sg, pfn_to_page(PFN_DOWN(xfer->rx_dma)),
> + xfer->len, offset_in_page(xfer->rx_dma));
> + sg_dma_len(&rx_sg) = xfer->len;
> + sg_dma_address(&rx_sg) = xfer->rx_dma;
> + sdd->rx_desc =
> + sdd->rx_chan->device->device_prep_slave_sg(
> + sdd->rx_chan, &rx_sg, 1, DMA_FROM_DEVICE,
> + DMA_PREP_INTERRUPT);
> + sdd->rx_desc->callback = s3c64xx_spi_dma_rxcb;
> + sdd->rx_desc->callback_param = sdd;
> + dmaengine_submit(sdd->rx_desc);
> + dma_async_issue_pending(sdd->rx_chan);
> +#else
> s3c2410_dma_config(sdd->rx_dmach, sdd->cur_bpw / 8);
> s3c2410_dma_enqueue(sdd->rx_dmach, (void *)sdd,
> xfer->rx_dma, xfer->len);
> s3c2410_dma_ctrl(sdd->rx_dmach, S3C2410_DMAOP_START);
> +#endif
> }
> }
>
> @@ -742,8 +848,50 @@ out:
> msg->complete(msg->context);
> }
>
> +#if defined(CONFIG_DMADEV_PL330)
> +static bool rxfilter(struct dma_chan *chan, void *param)
> +{
> + struct s3c64xx_spi_driver_data *sdd
> + = (struct s3c64xx_spi_driver_data *)param;
> + struct dma_pl330_peri *peri = (struct dma_pl330_peri *)chan->private;
> +
> + if (peri->peri_id != sdd->rx_dmach)
> + return false;
> +
> + return true;
> +}
Blank line here please.
> +static bool txfilter(struct dma_chan *chan, void *param)
> +{
> + struct s3c64xx_spi_driver_data *sdd
> + = (struct s3c64xx_spi_driver_data *)param;
> + struct dma_pl330_peri *peri = (struct dma_pl330_peri *)chan->private;
> +
> + if (peri->peri_id != sdd->tx_dmach)
> + return false;
> +
> + return true;
> +}
> +#endif
> +
> static int acquire_dma(struct s3c64xx_spi_driver_data *sdd)
> {
> +#if defined(CONFIG_DMADEV_PL330)
> + dma_cap_mask_t mask;
> + dma_cap_zero(mask);
> + dma_cap_set(DMA_SLAVE, mask);
> + sdd->rx_chan =
> + dma_request_channel(mask, rxfilter, (void *)sdd);
No need to split this line.
> + if (!sdd->rx_chan) {
> + dev_err(&sdd->pdev->dev, "cannot get RxDMA\n");
> + return 0;
> + }
> + sdd->tx_chan =
> + dma_request_channel(mask, txfilter, (void *)sdd);
Nor this one.
> + if (!sdd->tx_chan) {
> + dev_err(&sdd->pdev->dev, "cannot get TxDMA\n");
> + return 0;
> + }
As you have separate DMA channels for TX and RX, you should be able to
configure the channels once here, and avoid making the
dmaengine_slave_config calls during normal operation.
> +#else
> if (s3c2410_dma_request(sdd->rx_dmach,
> &s3c64xx_spi_dma_client, NULL) < 0) {
> dev_err(&sdd->pdev->dev, "cannot get RxDMA\n");
Last point - for correctness, the struct device which should be used
when mapping and unmapping buffers for the DMA engine is the DMA
engine's struct device.
In other words, sdd->tx_chan->device->dev for TX transfers, and
sdd->rx_chan->device->dev for RX transfers.
The DMA engine device is the struct device which actually performs the
reading/writing of memory, and has the limitations on SG geometry, not
the peripheral device.
next prev parent reply other threads:[~2011-07-05 7:48 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-04 12:18 [PATCH 0/7] ARM: S5P: Use generic DMA APIs Kukjin Kim
2011-07-04 12:18 ` [PATCH 1/7] DMA: PL330: Add support runtime PM for PL330 DMAC Kukjin Kim
2011-07-05 6:11 ` Alim Akhtar
2011-07-05 7:26 ` Kukjin Kim
2011-07-05 8:04 ` Russell King - ARM Linux
2011-07-08 10:18 ` Kukjin Kim
2011-07-04 12:18 ` [PATCH 2/7] DMA: PL330: Update PL330 DMA API driver Kukjin Kim
2011-07-05 7:36 ` Russell King - ARM Linux
2011-07-08 7:57 ` Kukjin Kim
2011-07-04 12:18 ` [PATCH 3/7] DMA: PL330: Add DMA capabilities Kukjin Kim
2011-07-05 6:33 ` Chanho Park
2011-07-05 7:10 ` Kukjin Kim
2011-07-05 8:08 ` Chanho Park
2011-07-12 8:32 ` Jassi Brar
2011-07-14 0:57 ` boojin
2011-07-14 3:53 ` Jassi Brar
2011-07-14 9:04 ` boojin
2011-07-04 12:18 ` [PATCH 4/7] ARM: SAMSUNG: Update to use PL330-DMA driver Kukjin Kim
2011-07-04 12:18 ` [PATCH 5/7] ARM: EXYNOS4: Use generic DMA PL330 driver Kukjin Kim
2011-07-05 6:07 ` Alim Akhtar
2011-07-05 8:30 ` Sangwook Lee
2011-07-04 12:18 ` [PATCH 6/7] spi/s3c64xx: Add support DMA engine API Kukjin Kim
2011-07-04 16:42 ` Grant Likely
2011-07-04 16:56 ` Mark Brown
2011-07-04 16:59 ` Heiko Stübner
2011-07-04 17:02 ` Grant Likely
2011-07-04 19:51 ` Heiko Stübner
2011-07-04 23:27 ` Grant Likely
2011-07-05 7:05 ` Kukjin Kim
2011-07-05 7:53 ` Russell King - ARM Linux
2011-07-05 10:51 ` Heiko Stübner
2011-07-05 11:16 ` Jassi Brar
2011-07-05 11:27 ` Russell King - ARM Linux
2011-07-05 11:45 ` Jassi Brar
2011-07-08 9:26 ` Kukjin Kim
2011-07-05 7:48 ` Russell King - ARM Linux [this message]
2011-07-05 8:39 ` Chanho Park
2011-07-04 12:18 ` [PATCH 7/7] ASoC: Samsung: Update DMA interface Kukjin Kim
2011-07-04 17:03 ` Mark Brown
2011-07-05 7:19 ` Kukjin Kim
2011-07-05 18:04 ` Grant Likely
2011-07-05 7:45 ` Seungwhan Youn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110705074806.GN8286@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).