Hi Russell!
Not sure when you'll be back from your trip, but I'll leave this hanging
in your inbox until then. :)
I've been getting several complaints about the issue with sector sizes
and large MMC/SD cards. I seem to recall we discussed this earlier, but
I cannot find those mail and I don't remember our conclusions.
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? People have
been reporting that their Palms, cameras and USB readers will not accept
anything else.
Rgds
Pierre
Hi Pierre,
Pierre Ossman wrote:
> Suggested patch included.
What's the status on this patch? A Gentoo user at
http://bugs.gentoo.org/142172 reports that it is required for him to be
able to access his card, so it definitely works in some form.
>
> [MMC] Always use a sector size of 512 bytes
>
> Both MMC and SD specifications specify (although a bit unclearly in the MMC
> case) that a sector size of 512 bytes must always be supported by the card.
>
> Cards can report larger "native" size than this, and cards >= 2 GB even
> must do so. Most other readers use 512 bytes even for these cards. We should
> do the same to be compatible.
>
> Signed-off-by: Pierre Ossman <[email protected]>
> ---
>
> drivers/mmc/mmc_block.c | 49 ++++-------------------------------------------
> 1 files changed, 4 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/mmc/mmc_block.c b/drivers/mmc/mmc_block.c
> index 587458b..96049e2 100644
> --- a/drivers/mmc/mmc_block.c
> +++ b/drivers/mmc/mmc_block.c
> @@ -325,52 +325,11 @@ static struct mmc_blk_data *mmc_blk_allo
> md->read_only = mmc_blk_readonly(card);
>
> /*
> - * Figure out a workable block size. MMC cards have:
> - * - two block sizes, one for read and one for write.
> - * - may support partial reads and/or writes
> - * (allows block sizes smaller than specified)
> + * Both SD and MMC specifications state (although a bit
> + * unclearly in the MMC case) that a block size of 512
> + * bytes must always be supported by the card.
> */
> - md->block_bits = card->csd.read_blkbits;
> - if (card->csd.write_blkbits != card->csd.read_blkbits) {
> - if (card->csd.write_blkbits < card->csd.read_blkbits &&
> - card->csd.read_partial) {
> - /*
> - * write block size is smaller than read block
> - * size, but we support partial reads, so choose
> - * the smaller write block size.
> - */
> - md->block_bits = card->csd.write_blkbits;
> - } else if (card->csd.write_blkbits > card->csd.read_blkbits &&
> - card->csd.write_partial) {
> - /*
> - * read block size is smaller than write block
> - * size, but we support partial writes. Use read
> - * block size.
> - */
> - } else {
> - /*
> - * We don't support this configuration for writes.
> - */
> - printk(KERN_ERR "%s: unable to select block size for "
> - "writing (rb%u wb%u rp%u wp%u)\n",
> - mmc_card_id(card),
> - 1 << card->csd.read_blkbits,
> - 1 << card->csd.write_blkbits,
> - card->csd.read_partial,
> - card->csd.write_partial);
> - md->read_only = 1;
> - }
> - }
> -
> - /*
> - * Refuse to allow block sizes smaller than 512 bytes.
> - */
> - if (md->block_bits < 9) {
> - printk(KERN_ERR "%s: unable to support block size %u\n",
> - mmc_card_id(card), 1 << md->block_bits);
> - ret = -EINVAL;
> - goto err_kfree;
> - }
> + md->block_bits = 9;
>
> md->disk = alloc_disk(1 << MMC_SHIFT);
> if (md->disk == NULL) {
Daniel Drake wrote:
> Hi Pierre,
>
> Pierre Ossman wrote:
>> Suggested patch included.
>
> What's the status on this patch? A Gentoo user at
> http://bugs.gentoo.org/142172 reports that it is required for him to be
> able to access his card, so it definitely works in some form.
I have to pitch in here. This patch is required for some cards to
operate reliably on the Nokia 770, and we've done quite a bit of
interoperability testing already.
Pierre, could you submit it to RMK's patch tracking system?
Cheers,
Juha
On 8/22/06, Juha Yrjola <[email protected]> wrote:
> > What's the status on this patch? A Gentoo user at
> > http://bugs.gentoo.org/142172 reports that it is required for him to be
> > able to access his card, so it definitely works in some form.
>
> I have to pitch in here. This patch is required for some cards to
> operate reliably on the Nokia 770, and we've done quite a bit of
> interoperability testing already.
>
> Pierre, could you submit it to RMK's patch tracking system?
I've tested with 2GB and 4GB SD for 2.6.17 thru 2.6.18-rc4, and this
patch works. Would very much like to see this in the mainstream
2.6.18.
Thanks,
Jeff.
Juha Yrjola wrote:
>
> I have to pitch in here. This patch is required for some cards to
> operate reliably on the Nokia 770, and we've done quite a bit of
> interoperability testing already.
>
> Pierre, could you submit it to RMK's patch tracking system?
>
It's a bit up in the air at the moment, but my ambition is to have it in
before 2.6.18 is out.
Rgds
Pierre
On Tue, Aug 22, 2006 at 06:19:31PM +0300, Juha Yrjola wrote:
> Daniel Drake wrote:
> >Hi Pierre,
> >
> >Pierre Ossman wrote:
> >>Suggested patch included.
> >
> >What's the status on this patch? A Gentoo user at
> >http://bugs.gentoo.org/142172 reports that it is required for him to be
> >able to access his card, so it definitely works in some form.
>
> I have to pitch in here. This patch is required for some cards to
> operate reliably on the Nokia 770, and we've done quite a bit of
> interoperability testing already.
>
> Pierre, could you submit it to RMK's patch tracking system?
Absolutely not.
MMC is a little up in the air at the moment while I decide whether I want
to continue the cherade of being the maintainer of it. It is a cherade
because the person doing 99% of the work is Pierre, and for some strange
reason, he's the one who gets all the bug reports.
This makes it extremely difficult for me to ascertain whether any patch is
correct or not - all I have to go by is the documentation, and as far as
I can see, the majority of the documentation I have says this patch is
wrong.
So I'm considering handing maintainership over to Pierre. If I don't
have the support of the community, which is being voiced pretty loudly
by its actions, this move makes sense.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core