From: Reinhard Meyer <u-boot@emk-elektronik.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mmc: seperate block number into small parts for multi-write cmd
Date: Mon, 06 Sep 2010 12:16:06 +0200 [thread overview]
Message-ID: <4C84BF66.8080704@emk-elektronik.de> (raw)
In-Reply-To: <AANLkTikSrELQqG+vh9tpUHYhkfk31UH7M-OTO+noW-wu@mail.gmail.com>
Lei Wen schrieb:
> On Mon, Sep 6, 2010 at 5:23 PM, Reinhard Meyer <u-boot@emk-elektronik.de> wrote:
>> Dear Lei Wen,
>>> As mmc host limitation, the max number of block in one go
You already write it's a HOST limitation.
>>> should be limited to 65535, and the max buffer size should
>>> not excceed 512k bytes.
Which would limit the #blocks to 1024 (assuming a 512 byte blocks)
>> Where does this limitation supposedly come from?
>
> This limitation comes from the SD/MMC sepc. You could find one and
> check the 0x6 offset register(BLOCK COUNT REGISTER).
This might refer to certain HOST controllers, but not to Cards!
> You could get that register is only 16bit width and only cound contain
> the 65535 block.
>
> This register is only validate for multi-operation, like multi-read or
> multi-write command.
Hmm, CMD25 states: "Continuously writes blocks of data until a
STOP_TRANSMISSION follows."
So the Card itself does not limit the number of blocks written in one go.
I do not mind the transfer to be split into chunks if required by some hosts,
but the "number of blocks in a go" should be configurable.
And you still do not explain why the buffer size shall be limited to 512KB?
Best Regards,
Reinhard
next prev parent reply other threads:[~2010-09-06 10:16 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-06 7:19 [U-Boot] [PATCH] mmc: seperate block number into small parts for multi-write cmd Lei Wen
2010-09-06 8:28 ` Wolfgang Denk
2010-09-06 8:40 ` Lei Wen
2010-09-06 9:23 ` Reinhard Meyer
2010-09-06 9:31 ` Lei Wen
2010-09-06 10:16 ` Reinhard Meyer [this message]
2010-09-06 10:48 ` Lei Wen
2010-09-06 11:50 ` Reinhard Meyer
2010-10-10 4:20 ` Lei Wen
2010-10-10 6:48 ` Wolfgang Denk
2010-10-10 8:49 ` Lei Wen
2010-10-10 9:22 ` Wolfgang Denk
2010-10-10 9:27 ` Lei Wen
2010-10-10 9:39 ` Reinhard Meyer
2010-10-10 9:44 ` Lei Wen
2010-10-10 9:33 ` Reinhard Meyer
2010-10-10 9:42 ` Lei Wen
2010-10-11 3:42 ` [U-Boot] [PATCH V2] " Lei Wen
2010-10-11 9:00 ` Reinhard Meyer
2010-10-11 9:22 ` Wolfgang Denk
2010-10-11 9:27 ` Lei Wen
2010-10-11 10:44 ` [U-Boot] [PATCH] " Reinhard Meyer
2010-10-11 11:35 ` Wolfgang Denk
2010-10-11 15:39 ` [U-Boot] [PATCH V3] " Lei Wen
2010-10-13 19:57 ` Wolfgang Denk
2010-10-14 5:38 ` [U-Boot] [PATCH V4] " Lei Wen
2010-10-25 18:46 ` Steve Sakoman
2010-10-27 18:39 ` Wolfgang Denk
2010-10-27 19:59 ` Steve Sakoman
2010-10-27 6:04 ` [U-Boot] [PATCH V3] " Lei Wen
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=4C84BF66.8080704@emk-elektronik.de \
--to=u-boot@emk-elektronik.de \
--cc=u-boot@lists.denx.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.