From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Pierre Ossman <drzeus-list@drzeus.cx>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2GB MMC/SD cards
Date: Sat, 3 Jun 2006 15:15:48 +0100 [thread overview]
Message-ID: <20060603141548.GA31182@flint.arm.linux.org.uk> (raw)
In-Reply-To: <447AFE7A.3070401@drzeus.cx>
On Mon, May 29, 2006 at 04:00:26PM +0200, Pierre Ossman wrote:
> I do, however, have the following in both the SD and MMC card specs I
> have (both sandisk though):
>
> WRITE_BL_PARTIAL ? defines whether partial block sizes can be used
> in block write commands.
>
> Table 3-25
> WRITE_BL_PARTIAL Definition
> 0 Only the WRITE_BL_LEN block size, and its partial
> derivatives in
> resolution of units of 512 blocks, can be used for
> block oriented data
> write.
> 1 Smaller blocks can be used as well. The minimum
> block size is one
> byte.
>
> So perhaps we should remove all the funky logic that's in mmc_block.c
> right now and just always select a block size of 512 bytes?
The specs I have say the following about WRITE_BL_PARTIAL:
Samsung (csd v1.2 mmc v4.1):
0: means that only the WRITE_BL_LEN block size can be used for block oriented data write.
1: means that smaller blocks can be used as well. The minimum block size is one byte.
Sandisk (csd v1.1 mmc v1.4):
0: means that only the WRITE_BL_LEN block size can be used for block oriented data write.
1: means that smaller blocks can be used as well. The minimum block size is one byte.
The wording is identical from these two differing manufacturers, so I
suspect it comes from the original spec.
> People have been reporting that their Palms, cameras and USB readers
> will not accept anything else.
I am not aware of any bug reports in this area, so I can't comment. In
fact, I see very few reports of MMC problems at all, so I just assume
that it merely works. Unless folk report bugs to me...
I don't know what to do about this since I don't have any cards and
I've not seen any bug reports to investigate what's going on. So I'm
just going to say "the code as it stands is correct as to my best
knowledge, please provide details of it's failings."
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
next prev parent reply other threads:[~2006-06-03 14:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-29 14:00 2GB MMC/SD cards Pierre Ossman
2006-06-03 14:15 ` Russell King [this message]
2006-06-03 15:02 ` Russell King
2006-06-03 18:40 ` Matt Reimer
2006-06-03 21:13 ` Pierre Ossman
2006-06-05 22:29 ` Jordan Crouse
2006-06-06 7:17 ` Richard Purdie
2006-06-05 22:52 ` Pierre Ossman
2006-06-07 9:08 ` Pierre Ossman
2006-06-07 16:58 ` Russell King
2006-06-07 20:36 ` Pierre Ossman
2006-06-08 23:01 ` Pierre Ossman
2006-06-22 15:08 ` Marcin Juszkiewicz
2006-08-13 10:14 ` Daniel Drake
2006-08-22 15:19 ` Juha Yrjola
2006-08-22 17:00 ` Jeff Chua
2006-08-23 18:28 ` Pierre Ossman
2006-08-25 9:07 ` Russell King
2006-06-03 21:11 ` 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=20060603141548.GA31182@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=drzeus-list@drzeus.cx \
--cc=linux-kernel@vger.kernel.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