From: "Richard Purdie" <rpurdie@rpsys.net>
To: "Russell King" <rmk+lkml@arm.linux.org.uk>, "Ian Molton" <spyro@f2s.com>
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Pierre Ossman" <drzeus-list@drzeus.cx>
Subject: Re: MMC Driver RFC
Date: Sun, 16 Jan 2005 23:17:59 -0000 [thread overview]
Message-ID: <047701c4fc21$a1579b50$0f01a8c0@max> (raw)
In-Reply-To: 41EAC3FD.1070001@drzeus.cx
Russell King:
> > 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!
>
> Different cards behave differently. I suspect you have yet another
> quirky card.
For reference, I got the 512MB SD card working by adding an mdelay(3) into
the middle of mmc_send_op_cond(). Anything shorter and it marks the card as
bad...
http://www.rpsys.net/openzaurus/2.6.11-rc1/mmc_sd-r2.patch shows the updated
SD code that works for me on the Sharp SL-C760 with the mdelay included.
Pierre Ossman:
> The patch can be found at:
> http://projects.drzeus.cx/wbsd/sd.php
Now I've got both my cards working, I plan to test this code and compare
soon. The added features look good.
> That page also contains the legal issues as I've understood them.
I don't see the problems you mention there. Yes companies may have signed
agreements with the SD card association and yes, that may possibly mean they
can't distribute Linux with SD support but that would be *their* problem and
not a reason against including SD support in the kernel. If they remove any
SD code from Linux then they would still be able to distribute it. I suspect
that they would be able to distribute SD code already in the public domain
anyway.
On the subject of patents, the whole idea behind SD is that there aren't
patents as for a patent to exist, we'd have some publicly available
information on how SD works. We're not breaking any copyrights as I nobody
involved with this code has see any code to copy from.
So in short, I can't see any reason we can't put the code we have into the
kernel...
Richard
next prev parent reply other threads:[~2005-01-16 23:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-12 21:10 MMC Driver RFC Richard Purdie
2005-01-12 21:43 ` 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 [this message]
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='047701c4fc21$a1579b50$0f01a8c0@max' \
--to=rpurdie@rpsys.net \
--cc=drzeus-list@drzeus.cx \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk+lkml@arm.linux.org.uk \
--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