linux-mmc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Subhash Jadavani <subhashj@codeaurora.org>
To: Vinit Shenoy <vinit.shenoy@st.com>
Cc: cjb@laptop.org, per.forlin@linaro.org, andy.shevchenko@gmail.com,
	viresh.kumar@linaro.org, linux-mmc@vger.kernel.org,
	spear-devel@list.st.com
Subject: Re: [PATCH 1/1] mmc: debugfs: Set frequency to maximum possible on higher request
Date: Mon, 03 Sep 2012 17:20:02 +0530	[thread overview]
Message-ID: <5044996A.2050502@codeaurora.org> (raw)
In-Reply-To: <1346670519-13097-1-git-send-email-vinit.shenoy@st.com>

On 9/3/2012 4:38 PM, Vinit Shenoy wrote:
> Currently if we enter a frequency greater than maximum supported,
> -EINVAL is returned. Due to this clock is not switched to maximum
> supported frequency.
>
> For example consider the max supported frequency to be 48MHz
>
> echo 20000000 > /sys/kernel/debug/mmc0/clock Here clock is switched to 20Mhz.
>
> echo 80000000 > /sys/kernel/debug/mmc0/clock
> Ideally clock should be set back to 48MHz, but it is still set to 20MHz.
>
> This patch sets value to f_max when the requested frequency is greater
> than f_max
>
> Signed-off-by: Vinit Shenoy <vinit.shenoy@st.com>
> ---
>   drivers/mmc/core/debugfs.c |    2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
> index 9ab5b17..c71d3eb 100644
> --- a/drivers/mmc/core/debugfs.c
> +++ b/drivers/mmc/core/debugfs.c
> @@ -174,7 +174,7 @@ static int mmc_clock_opt_set(void *data, u64 val)
>   
>   	/* We need this check due to input value is u64 */
>   	if (val > host->f_max)
> -		return -EINVAL;
> +		val = host->f_max;

As such this is ok if you want this behaviour. But i see other issue 
which is not related to your patch.

Let's say if the host supports 400KHz, 25 MHz,  50MHz, 100MHz and 
currently card is operating in HS (High Speed) mode@50MHz. and now if 
someone tries to change the frequency to 100MHz, then we should just 
don't let the clock change to 100MHz before we put the card in 
appropriate bus speed mode (in SD cards case, it would be SDR50 and eMMC 
case it would be HS200). Although this is anyway not an issue created by 
your patch but this is just to let you know that frequency can't be 
changed indepently without informing the card beforehand.

As far as this patch is concerned, it looks good to me.
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>

>   
>   	mmc_claim_host(host);
>   	mmc_set_clock(host, (unsigned int) val);


  parent reply	other threads:[~2012-09-03 11:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-03 11:08 [PATCH 1/1] mmc: debugfs: Set frequency to maximum possible on higher request Vinit Shenoy
2012-09-03 11:36 ` Andy Shevchenko
2012-09-03 11:50 ` Subhash Jadavani [this message]
2012-09-03 12:30   ` Andy Shevchenko
2012-09-03 12:35     ` Subhash Jadavani

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=5044996A.2050502@codeaurora.org \
    --to=subhashj@codeaurora.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=cjb@laptop.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=per.forlin@linaro.org \
    --cc=spear-devel@list.st.com \
    --cc=vinit.shenoy@st.com \
    --cc=viresh.kumar@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).