From: Lars-Peter Clausen <lars@metafoo.de>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Chris Ball <cjb@laptop.org>, Shawn Guo <shawn.guo@linaro.org>,
Kevin Liu <kliu5@marvell.com>,
linux-mmc@vger.kernel.org
Subject: Re: [PATCH] mmc: sdhci-pltfm: Add a common clk API based implementation of get_timeout_clock
Date: Tue, 29 Jan 2013 10:22:35 +0100 [thread overview]
Message-ID: <510794DB.3050606@metafoo.de> (raw)
In-Reply-To: <51076205.6040704@wwwdotorg.org>
On 01/29/2013 06:45 AM, Stephen Warren wrote:
> On 01/28/2013 11:27 AM, Lars-Peter Clausen wrote:
>> Quite a few drivers have a implementation of the get_timeout_clock callback
>> which simply returns the result of clk_get_rate on devices clock. This patch
>> adds a common implementation of this to the sdhci-pltfm module and replaces all
>> custom implementations with the common one.
>>
>> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
>> ---
>> I've only runtime tested this patch on a platform which is not yet upstream. For
>> the drivers which are modified in this patch I've only done compile time
>> testing. But I think all changes, but maybe the bcm2835 one, are straight
>> forward.
>
> It seems to work fine for bcm2835. So,
>
> Tested-by: Stephen Warren <swarren@wwwdotorg.org>
>
>> @@ -148,9 +131,9 @@ static struct sdhci_ops bcm2835_sdhci_ops = {
>> .read_l = bcm2835_sdhci_readl,
>> .read_w = bcm2835_sdhci_readw,
>> .read_b = bcm2835_sdhci_readb,
>> - .get_max_clock = bcm2835_sdhci_get_max_clock,
>> + .get_max_clock = sdhci_pltfm_clk_get_max_clock,
>> .get_min_clock = bcm2835_sdhci_get_min_clock,
>> - .get_timeout_clock = bcm2835_sdhci_get_timeout_clock,
>> + .get_timeout_clock = sdhci_pltfm_clk_get_max_clock,
>> };
>
> Rather than requiring .get_max_clock and .get_timeout_clock to be set by
> each driver, perhaps the SDHCI core can call
> sdhci_pltfm_clk_get_max_clock() if the function pointer is NULL?
Yea, this part of the bcm2835 driver confused me a bit. So there is the
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK quirk which causes the sdhci core to use
the max clock as a basis to calculate the timeout clock. But it divides it
by 1000. I don't know the bcm2835 sdhci controller hardware, but is it
possible that the current timeout clock value is too large by a factor of
1000? This wouldn't cause problems with normal transfers, but may increase
the timeout delay for failed transfers.
- Lars
next prev parent reply other threads:[~2013-01-29 9:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-28 18:27 [PATCH] mmc: sdhci-pltfm: Add a common clk API based implementation of get_timeout_clock Lars-Peter Clausen
2013-01-29 5:45 ` Stephen Warren
2013-01-29 9:22 ` Lars-Peter Clausen [this message]
2013-01-30 4:22 ` Stephen Warren
2013-01-29 5:51 ` Shawn Guo
2013-02-11 16:26 ` Chris Ball
[not found] <25B60CDC2F704E4E9D88FFD52780CB4C08B059D3F2@SC-VEXCH1.marvell.com>
2013-01-29 9:06 ` Kevin Liu
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=510794DB.3050606@metafoo.de \
--to=lars@metafoo.de \
--cc=cjb@laptop.org \
--cc=kliu5@marvell.com \
--cc=linux-mmc@vger.kernel.org \
--cc=shawn.guo@linaro.org \
--cc=swarren@wwwdotorg.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).