linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adrian Hunter <adrian.hunter@intel.com>
To: Ritesh Harjani <riteshh@codeaurora.org>,
	ulf.hansson@linaro.org, linux-mmc@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org, alex.lemberg@sandisk.com,
	mateusz.nowak@intel.com, Yuliy.Izrailov@sandisk.com,
	jh80.chung@samsung.com, dongas86@gmail.com,
	asutoshd@codeaurora.org, zhangfei.gao@gmail.com,
	sthumma@codeaurora.org, kdorfman@codeaurora.org,
	david.griego@linaro.org, stummala@codeaurora.org,
	venkatg@codeaurora.org, shawn.lin@rock-chips.com,
	Subhash Jadavani <subhashj@codeaurora.org>
Subject: Re: [PATCH RFCv2 06/10] mmc: host: sdhci: don't set SDMA buffer boundary in ADMA mode
Date: Wed, 29 Jun 2016 13:55:49 +0300	[thread overview]
Message-ID: <5773A935.7050209@intel.com> (raw)
In-Reply-To: <1467033757-32498-7-git-send-email-riteshh@codeaurora.org>

On 27/06/16 16:22, Ritesh Harjani wrote:
> From: Subhash Jadavani <subhashj@codeaurora.org>
> 
> SDMA buffer boundary size parameter in block size register should only be
> programmed if host controller DMA is operating in SDMA mode otherwise its
> better not to set this parameter to avoid any side effect when DMA is
> operating in ADMA mode operation.

Pedantically, the SDHCI specification does not say the SDMA Buffer Boundary
should not be set in ADMA mode.  All it says is that ADMA does not use it.
In fact it is impossible to avoid writing to it because it is part of the
Block Size register.  Unfortunately the value 0 does not mean "not used" but
instead means the boundary is 4K whereas the value presently being written
(7 which is the highest) means 512K.

Given that we have always been writing 7 to it, I don't see any reason to
change.  Murphy's law says if we do change it, someone else's driver will break.

However I presume you have hardware where value 7 doesn't work.  Can you
clarify that?

> 
> Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
> [venkatg@codeaurora.org: fix trivial merge conflict]
> Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
> ---
>  drivers/mmc/host/sdhci.c | 23 +++++++++++++++--------
>  1 file changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 0e3d7c0..9f5cdaa 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -742,6 +742,17 @@ static void sdhci_set_timeout(struct sdhci_host *host, struct mmc_command *cmd)
>  	}
>  }
>  
> +static void sdhci_set_blk_size_reg(struct sdhci_host *host, unsigned int blksz,
> +				   unsigned int sdma_boundary)
> +{
> +	if (host->flags & SDHCI_USE_ADMA)
> +		sdhci_writew(host, SDHCI_MAKE_BLKSZ(0, blksz),
> +			     SDHCI_BLOCK_SIZE);
> +	else
> +		sdhci_writew(host, SDHCI_MAKE_BLKSZ(sdma_boundary, blksz),
> +			     SDHCI_BLOCK_SIZE);
> +}
> +
>  static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command *cmd)
>  {
>  	u8 ctrl;
> @@ -874,8 +885,7 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command *cmd)
>  	sdhci_set_transfer_irqs(host);
>  
>  	/* Set the DMA boundary value and block size */
> -	sdhci_writew(host, SDHCI_MAKE_BLKSZ(SDHCI_DEFAULT_BOUNDARY_ARG,
> -		data->blksz), SDHCI_BLOCK_SIZE);
> +	sdhci_set_blk_size_reg(host, data->blksz, SDHCI_DEFAULT_BOUNDARY_ARG);
>  	sdhci_writew(host, data->blocks, SDHCI_BLOCK_COUNT);
>  }
>  
> @@ -1935,14 +1945,11 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
>  		 */
>  		if (cmd.opcode == MMC_SEND_TUNING_BLOCK_HS200) {
>  			if (mmc->ios.bus_width == MMC_BUS_WIDTH_8)
> -				sdhci_writew(host, SDHCI_MAKE_BLKSZ(7, 128),
> -					     SDHCI_BLOCK_SIZE);
> +				sdhci_set_blk_size_reg(host, 128, 7);
>  			else if (mmc->ios.bus_width == MMC_BUS_WIDTH_4)
> -				sdhci_writew(host, SDHCI_MAKE_BLKSZ(7, 64),
> -					     SDHCI_BLOCK_SIZE);
> +				sdhci_set_blk_size_reg(host, 64, 7);
>  		} else {
> -			sdhci_writew(host, SDHCI_MAKE_BLKSZ(7, 64),
> -				     SDHCI_BLOCK_SIZE);
> +			sdhci_set_blk_size_reg(host, 64, 7);
>  		}
>  
>  		/*
> 


  reply	other threads:[~2016-06-29 10:55 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-27 13:22 [PATCH RFCv2 00/10] mmc: Add HW Command Queuing Support Ritesh Harjani
2016-06-27 13:22 ` [PATCH RFCv2 01/10] mmc: core: Add support to read command queue parameters Ritesh Harjani
2016-11-21 15:34   ` Linus Walleij
2016-11-22  7:58     ` Adrian Hunter
2016-11-22 10:20       ` Linus Walleij
2016-11-22 10:31         ` Adrian Hunter
2016-11-22 12:30           ` Linus Walleij
2016-11-22 12:37             ` Linus Walleij
2016-06-27 13:22 ` [PATCH RFCv2 02/10] mmc: queue: initialization of command queue Ritesh Harjani
2016-06-27 13:22 ` [PATCH RFCv2 03/10] mmc: core: Add command queue initialzation support Ritesh Harjani
2016-06-27 13:22 ` [PATCH RFCv2 04/10] mmc: card: add read/write support in command queue mode Ritesh Harjani
2016-06-27 13:22 ` [PATCH RFCv2 05/10] mmc: core: add flush request support to command queue Ritesh Harjani
2016-06-27 13:22 ` [PATCH RFCv2 06/10] mmc: host: sdhci: don't set SDMA buffer boundary in ADMA mode Ritesh Harjani
2016-06-29 10:55   ` Adrian Hunter [this message]
2016-06-30 12:57     ` Ritesh Harjani
2016-06-27 13:22 ` [PATCH RFCv2 07/10] mmc: cmdq: support for command queue enabled host Ritesh Harjani
2016-06-27 13:22 ` [PATCH RFCv2 08/10] mmc: core: Add halt support Ritesh Harjani
2016-06-27 13:22 ` [PATCH RFCv2 09/10] mmc: cmdq-host: add halt support to command queue host Ritesh Harjani
2016-06-27 13:22 ` [PATCH RFCv2 10/10] mmc: sdhci: add command queue support to sdhci Ritesh Harjani
2016-07-05 11:15   ` Adrian Hunter
2016-07-06 10:01     ` Adrian Hunter
2016-07-25 10:24     ` Ritesh Harjani
2016-08-10 11:28       ` Adrian Hunter
2016-08-16  4:10         ` Ritesh Harjani
2016-11-21 15:52 ` [PATCH RFCv2 00/10] mmc: Add HW Command Queuing Support Linus Walleij
2016-11-21 16:05   ` Arnd Bergmann

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=5773A935.7050209@intel.com \
    --to=adrian.hunter@intel.com \
    --cc=Yuliy.Izrailov@sandisk.com \
    --cc=alex.lemberg@sandisk.com \
    --cc=asutoshd@codeaurora.org \
    --cc=david.griego@linaro.org \
    --cc=dongas86@gmail.com \
    --cc=jh80.chung@samsung.com \
    --cc=kdorfman@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=mateusz.nowak@intel.com \
    --cc=riteshh@codeaurora.org \
    --cc=shawn.lin@rock-chips.com \
    --cc=sthumma@codeaurora.org \
    --cc=stummala@codeaurora.org \
    --cc=subhashj@codeaurora.org \
    --cc=ulf.hansson@linaro.org \
    --cc=venkatg@codeaurora.org \
    --cc=zhangfei.gao@gmail.com \
    /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).