From: "Richard Purdie" <rpurdie@rpsys.net>
To: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Cc: "Ian Molton" <spyro@f2s.com>
Subject: MMC Driver RFC
Date: Wed, 12 Jan 2005 21:10:12 -0000 [thread overview]
Message-ID: <021901c4f8eb$1e9cc4d0$0f01a8c0@max> (raw)
[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]
I've been working on enabling the MMC/SD card slot on the Sharp SL-C7xx
series. I've come across the following issues and would appreciate comments:
1. Card Detection Interrupts
The MMC code completely misses card removals on my test hardware as when the
interrupt triggers electrical contact is still fully functional.
The PXA code calls mmc_detect_change() whenever an interrupt is detected.
The MMC core then does a schedule_work(&host->detect). The problem is that
when the interrupt is generated, the card may not be 100% inserted or 100%
removed. Given the mechanical nature of insertions and removals, electrical
contact is possible for a while after removal has been started (and a while
before insertion is complete).
My proposed solution is to change the above code to
schedule_delayed_work(&host->detect, HZ/4). Waiting 1/4 of a second after an
event for things to stabilise makes my test hardware completely functional.
It also makes a lot of sense in general as far as I can see. Patch attached.
2. Card Initialisation Problems
One of my cards works fine. The other works when I enable debug and doesn't
when I don't. I suspect the delay while it does a printk gives something
time to happen that doesn't normally when running at full speed!
I suspect this is related to the 1ms wait that was added to mmc_setup() as
per comments. Is there any documentation which tells us exactly what timings
we should be aiming for here? Has anyone else has problems like this?
3. SD Support
Ian Molton seems to have added SD support to handhelds.org's kernel. I'm
still trying to contact him to discuss this but the following patch enables
SD cards to work for me:
http://www.rpsys.net/openzaurus/2.6.11-rc1/mmc_sd-r1.patch
Was there a reason why SD support wasn't included in the original driver?
Would something like this patch be accepted into the kernel (I realise it
has some rough edges). I'd probably remove the attempt at 4 bit support
until a mainstream driver supported that...
Richard
[-- Attachment #2: mmc_delay-r0.patch --]
[-- Type: application/octet-stream, Size: 363 bytes --]
#
# Patch managed by http://www.holgerschurig.de/patcher.html
#
--- linux-2.6.11-rc1/drivers/mmc/mmc.c~mmc_delay
+++ linux-2.6.11-rc1/drivers/mmc/mmc.c
@@ -725,7 +725,7 @@
*/
void mmc_detect_change(struct mmc_host *host)
{
- schedule_work(&host->detect);
+ schedule_delayed_work(&host->detect, HZ/4);
}
EXPORT_SYMBOL(mmc_detect_change);
next reply other threads:[~2005-01-12 21:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-12 21:10 Richard Purdie [this message]
2005-01-12 21:43 ` MMC Driver RFC Russell King
2005-01-12 22:07 ` Richard Purdie
2005-01-12 22:17 ` Russell King
2005-01-12 23:23 ` Ian Molton
2005-01-12 23:58 ` Richard Purdie
2005-01-14 11:37 ` Pierre Ossman
2005-01-14 14:55 ` Ian Molton
2005-01-16 12:22 ` Pierre Ossman
2005-01-16 13:19 ` Ian Molton
2005-01-16 19:43 ` Pierre Ossman
2005-01-16 23:17 ` Richard Purdie
2005-01-16 22:33 ` Alan Cox
2005-01-17 6:07 ` Pierre Ossman
2005-01-17 9:53 ` Richard Purdie
2005-01-17 11:59 ` Pierre Ossman
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='021901c4f8eb$1e9cc4d0$0f01a8c0@max' \
--to=rpurdie@rpsys.net \
--cc=linux-kernel@vger.kernel.org \
--cc=spyro@f2s.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