All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org,
	Russell King <linux@arm.linux.org.uk>,
	linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Johan Rudholm <jrudholm@gmail.com>
Subject: Re: [PATCH V3 3/4] mmc: mmci: Adapt to register write restrictions
Date: Tue, 03 Sep 2013 11:50:39 +0200	[thread overview]
Message-ID: <5225B0EF.7030006@linaro.org> (raw)
In-Reply-To: <1378200576-13413-4-git-send-email-ulf.hansson@linaro.org>

On 09/03/2013 11:29 AM, Ulf Hansson wrote:
> After a write to the MMCICLOCK register data cannot be written to this
> register for three feedback clock cycles. Writes to the MMCIPOWER
> register must be separated by three MCLK cycles. Previously no issues
> has been observered, but using higher ARM clock frequencies on STE-
> platforms has triggered this problem.
> 
> The MMCICLOCK register is written to in .set_ios and for some data
> transmissions for SDIO. We do not need a delay at the data transmission
> path, because sending and receiving data will require more than three
> clock cycles. Then we use a simple logic to only delay in .set_ios and
> thus we don't affect throughput performance.
> 
> Signed-off-by: Johan Rudholm <jrudholm@gmail.com>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> Acked-by: Rickard Andersson <rickard.andersson@stericsson.com>
> ---

Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>

+ two questions below.

>  drivers/mmc/host/mmci.c |   16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index c550b3e..82afcd3 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -189,6 +189,21 @@ static int mmci_validate_data(struct mmci_host *host,
>  	return 0;
>  }
>  
> +static void mmci_reg_delay(struct mmci_host *host)
> +{
> +	/*
> +	 * According to the spec, at least three feedback clock cycles
> +	 * of max 52 MHz must pass between two writes to the MMCICLOCK reg.
> +	 * Three MCLK clock cycles must pass between two MMCIPOWER reg writes.
> +	 * Worst delay time during card init is at 100 kHz => 30 us.
> +	 * Worst delay time when up and running is at 25 MHz => 120 ns.
> +	 */
> +	if (host->cclk < 20000000)

Shouldn't it be 25000000 ?

What about using macros ?

#define MMC_CLOCK 25000000
#define MMCINIT_DELAY 30
#define MMCUP_DELAY 120

> +		udelay(30);
> +	else
> +		ndelay(120);
> +}
> +
>  /*
>   * This must be called with host->lock held
>   */
> @@ -1264,6 +1279,7 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>  
>  	mmci_set_clkreg(host, ios->clock);
>  	mmci_write_pwrreg(host, pwr);
> +	mmci_reg_delay(host);
>  
>  	spin_unlock_irqrestore(&host->lock, flags);
>  
> 


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog


WARNING: multiple messages have this Message-ID (diff)
From: daniel.lezcano@linaro.org (Daniel Lezcano)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V3 3/4] mmc: mmci: Adapt to register write restrictions
Date: Tue, 03 Sep 2013 11:50:39 +0200	[thread overview]
Message-ID: <5225B0EF.7030006@linaro.org> (raw)
In-Reply-To: <1378200576-13413-4-git-send-email-ulf.hansson@linaro.org>

On 09/03/2013 11:29 AM, Ulf Hansson wrote:
> After a write to the MMCICLOCK register data cannot be written to this
> register for three feedback clock cycles. Writes to the MMCIPOWER
> register must be separated by three MCLK cycles. Previously no issues
> has been observered, but using higher ARM clock frequencies on STE-
> platforms has triggered this problem.
> 
> The MMCICLOCK register is written to in .set_ios and for some data
> transmissions for SDIO. We do not need a delay at the data transmission
> path, because sending and receiving data will require more than three
> clock cycles. Then we use a simple logic to only delay in .set_ios and
> thus we don't affect throughput performance.
> 
> Signed-off-by: Johan Rudholm <jrudholm@gmail.com>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> Acked-by: Rickard Andersson <rickard.andersson@stericsson.com>
> ---

Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>

+ two questions below.

>  drivers/mmc/host/mmci.c |   16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index c550b3e..82afcd3 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -189,6 +189,21 @@ static int mmci_validate_data(struct mmci_host *host,
>  	return 0;
>  }
>  
> +static void mmci_reg_delay(struct mmci_host *host)
> +{
> +	/*
> +	 * According to the spec, at least three feedback clock cycles
> +	 * of max 52 MHz must pass between two writes to the MMCICLOCK reg.
> +	 * Three MCLK clock cycles must pass between two MMCIPOWER reg writes.
> +	 * Worst delay time during card init is at 100 kHz => 30 us.
> +	 * Worst delay time when up and running is at 25 MHz => 120 ns.
> +	 */
> +	if (host->cclk < 20000000)

Shouldn't it be 25000000 ?

What about using macros ?

#define MMC_CLOCK 25000000
#define MMCINIT_DELAY 30
#define MMCUP_DELAY 120

> +		udelay(30);
> +	else
> +		ndelay(120);
> +}
> +
>  /*
>   * This must be called with host->lock held
>   */
> @@ -1264,6 +1279,7 @@ static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>  
>  	mmci_set_clkreg(host, ios->clock);
>  	mmci_write_pwrreg(host, pwr);
> +	mmci_reg_delay(host);
>  
>  	spin_unlock_irqrestore(&host->lock, flags);
>  
> 


-- 
 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

  reply	other threads:[~2013-09-03  9:50 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-03  9:29 [PATCH V3 0/4] mmc: mmci: Support ap_sleep in cpuidle for ux500 Ulf Hansson
2013-09-03  9:29 ` Ulf Hansson
2013-09-03  9:29 ` [PATCH V3 1/4] mmc: mmci: Adapt to new pinctrl handling Ulf Hansson
2013-09-03  9:29   ` Ulf Hansson
2013-09-04  5:42   ` Linus Walleij
2013-09-04  5:42     ` Linus Walleij
2013-09-03  9:29 ` [PATCH V3 2/4] mmc: mmci: Use optional sleep pinctrl state Ulf Hansson
2013-09-03  9:29   ` Ulf Hansson
2013-09-04  5:43   ` Linus Walleij
2013-09-04  5:43     ` Linus Walleij
2013-09-03  9:29 ` [PATCH V3 3/4] mmc: mmci: Adapt to register write restrictions Ulf Hansson
2013-09-03  9:29   ` Ulf Hansson
2013-09-03  9:50   ` Daniel Lezcano [this message]
2013-09-03  9:50     ` Daniel Lezcano
2013-09-03 11:56     ` Ulf Hansson
2013-09-03 11:56       ` Ulf Hansson
2013-09-03  9:29 ` [PATCH V3 4/4] mmc: mmci: Save and restore register context Ulf Hansson
2013-09-03  9:29   ` Ulf Hansson
2013-09-03  9:53   ` Daniel Lezcano
2013-09-03  9:53     ` Daniel Lezcano

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=5225B0EF.7030006@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=cjb@laptop.org \
    --cc=jrudholm@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.