linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	Chris Ball <chris@printf.net>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Russell King <linux@arm.linux.org.uk>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] mmc: mmci: Add qcom dml support to the driver.
Date: Fri, 11 Jul 2014 15:49:34 +0200	[thread overview]
Message-ID: <CACRpkdZdU3PBt+tCqhtWutjwaqdM9yWQi-3bzELV1Xnd9w_EEw@mail.gmail.com> (raw)
In-Reply-To: <1405079306-1406-1-git-send-email-srinivas.kandagatla@linaro.org>

On Fri, Jul 11, 2014 at 1:48 PM, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:

> On Qualcomm APQ8064 SOCs, SD card controller has an additional glue
> called DML (Data Mover Local/Lite) to assist dma transfers.
> This hardware needs to be setup before any dma transfer is requested.
> DML itself is not a DMA engine, its just a gule between the SD card
> controller and dma controller.
>
> Most of this code has been ported from qualcomm's 3.4 kernel.
>
> This patch adds the code necessary to intialize the hardware and setup
> before doing any dma transfers.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>

Pretty cool :-)

>  drivers/mmc/host/mmci.c     |  19 ++++-
>  drivers/mmc/host/qcom_dml.c | 171 ++++++++++++++++++++++++++++++++++++++++++++
>  drivers/mmc/host/qcom_dml.h |  17 +++++

Please call this file mmci-qcom-dml.c/h so we know that these files
have a strong
dependence.

> +config MMC_QCOM_DML
> +       tristate "Qualcomm Data Mover for SD Card Controller"
> +       depends on MMC_ARMMMCI && ARCH_QCOM

The way I get it is that this only makes sense when the qualcomm
DMA engine is used so should it not be

depends on MMC_ARMMMCI && QCOM_BAM_DMA

?

Or maybe we should be less specific?

depends on MMC_ARMMMCI && DMA_ENGINE

?

>  /*
> @@ -569,6 +579,7 @@ static int __mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
>         struct dma_async_tx_descriptor *desc;
>         enum dma_data_direction buffer_dirn;
>         int nr_sg;
> +       u32 flags = DMA_CTRL_ACK;
>
>         if (data->flags & MMC_DATA_READ) {
>                 conf.direction = DMA_DEV_TO_MEM;
> @@ -593,9 +604,12 @@ static int __mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
>         if (nr_sg == 0)
>                 return -EINVAL;
>
> +       if (host->variant->qcom_dml)
> +               flags |= DMA_PREP_INTERRUPT;

Is this correct? That augments every incoming DMA request to try to
do an interrupt callback. Why is that necessary? The interrupt
callback still isn't registered, so this isn't used for anything?

If it's still needed it would be a bug in the DMA engine I think.

Yours,
Linus Walleij

  reply	other threads:[~2014-07-11 13:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-11 11:48 [RFC PATCH] mmc: mmci: Add qcom dml support to the driver Srinivas Kandagatla
2014-07-11 13:49 ` Linus Walleij [this message]
2014-07-11 19:36   ` Srinivas Kandagatla
2014-07-17 19:36 ` [PATCH v1] " Srinivas Kandagatla
2014-07-17 19:41   ` Srinivas Kandagatla
2014-07-17 23:06   ` Stephen Boyd
2014-07-18  6:42     ` Srinivas Kandagatla
2014-07-18 20:53   ` [PATCH v2] " Srinivas Kandagatla
2014-07-23 14:52     ` Linus Walleij
2014-07-23 22:58     ` Stephen Boyd
2014-07-25  4:07       ` Srinivas Kandagatla
2014-07-28  6:22     ` [PATCH v3] " Srinivas Kandagatla
2014-07-29  2:50       ` [PATCH v4] " Srinivas Kandagatla
2014-07-29 17:55         ` Stephen Boyd
2014-07-30  4:12         ` Srinivas Kandagatla
2014-08-12  8:40         ` Ulf Hansson

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=CACRpkdZdU3PBt+tCqhtWutjwaqdM9yWQi-3bzELV1Xnd9w_EEw@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=chris@printf.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=ulf.hansson@linaro.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).