From: Hein_Tibosch <hein_tibosch@yahoo.es>
To: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Cc: Ben Nizette <bn@niasdigital.com>,
linux-mmc@vger.kernel.org, Sascha Hauer <s.hauer@pengutronix.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Chris Ball <cjb@laptop.org>
Subject: Re: [PATCH] mmc: Reduce fOD to 200 kHz if possible
Date: Wed, 15 Sep 2010 22:31:07 +0800 [thread overview]
Message-ID: <4C90D8AB.9030606@yahoo.es> (raw)
In-Reply-To: <20100915125138.1f25e4b1@hskinnemoen-d830>
On 15-9-2010 18:51, Haavard Skinnemoen wrote:
> Ben Nizette <bn@niasdigital.com> wrote:
>> On 15/09/2010, at 6:59 PM, Haavard Skinnemoen wrote:
>>
>>> Since the identification frequency was increased to 400 kHz, my
>>> ATSTK1000 board has not been able to initialize any MMC or SD cards.
>>> Reducing the identification mode frequency to 200 kHz fixes the problem.
>>>
>>> This is definitely a board-specific issue, probably due to weak pull-up
>>> resistor values, but this is the simplest fix I could come up with.
>> I wonder whether there's an Atmel reference schematic around with an
>> incorrect resistor value on it, the only three people I know affected
>> by this are myself, Hein Tibosch and you, all on AVR32.
It was reported by a few more, who wrote me "off-list", but all of them were
using AVR32
> Yes, if you've used the STK1000 schematics as a reference, the resistor
> values are probably a bit on the high side. I can't really suggest any
> better values, as I don't remember what they should be, and the various
> specs are quite inconsistent so it's not straightforward to find the
> best values.
>
> On the other hand, you could argue that the resistor values are fine as
> they are, and that the Linux MMC subsystem is broken because it runs
> the bus faster than what the hardware allows. Replacing the resistors
> with stronger ones might reduce the maximum speed in push-pull mode, so
> I wouldn't necessarily recommend it, especially when it's trivial to fix
> the issue in software.
>
I did find it strange to put the freq at the memory's maximum of 400 Khz
>> We've now submitted one fix each, mine was similar to yours [1] but there's been movement on Hein's more comprehensive patch recently [2]. I don't know who's supposed to be merging MMC patches atm, Chris Ball added on CC on a hunch.
> Thanks for the references. IMO Hein's patch is overkill. There is
> absolutely no reason why 200 kHz should be a problem on any setup, and
> I haven't found any indication in any discussions that it is.
>
I have also seen situations in which the SD will only start up at 180 Khz
or lower.
IMO my patch is indeed a bit of an overkill (the amount of code changed),
I'd rather see a patch like yours or Ben's, but settings fOD at 100 or 50 Khz.
It was Pierre who suggested to try several frequencies[1]: most systems will start
using 400 Khz (so they won't suffer any loss of performance) and in some rare
cases, the SD will only be identified at 100 Khz (which does happen, sometimes)
[1] http://article.gmane.org/gmane.linux.kernel.mmc/994
> The reason why fOD was set to 400 kHz in the first place is that some
> controllers have a very low f_min so running the initialization at that
> frequency causes problems. Which makes sense because the SD standard
> clearly says that the clock can't be slower than 100 kHz.
>
> But I have never seen any reasons why we absolutely _have_ to run the
> clock at the maximum frequency allowed by the spec. In fact, Sascha
> Hauer, who was the one who changed the minimum clock frequency to 400
> kHz, said he would be fine with any frequency between 50 kHz and 400
> kHz
That's right
Hein
next prev parent reply other threads:[~2010-09-15 15:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-15 8:59 [PATCH] mmc: Reduce fOD to 200 kHz if possible Haavard Skinnemoen
2010-09-15 9:50 ` Ben Nizette
2010-09-15 10:51 ` Haavard Skinnemoen
2010-09-15 14:08 ` Chris Ball
2010-09-15 14:31 ` Hein_Tibosch [this message]
2010-09-15 15:10 ` Haavard Skinnemoen
2010-09-15 13:57 ` Chris Ball
2010-09-16 7:55 ` Haavard Skinnemoen
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=4C90D8AB.9030606@yahoo.es \
--to=hein_tibosch@yahoo.es \
--cc=bn@niasdigital.com \
--cc=cjb@laptop.org \
--cc=haavard.skinnemoen@atmel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=s.hauer@pengutronix.de \
/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).