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: Sun, 10 Oct 2010 11:33:31 +0200 [thread overview]
Message-ID: <4CB1886B.8090209@emk-elektronik.de> (raw)
In-Reply-To: <20101010092257.154CE1508A2@gemini.denx.de>
Dear all concerned,
> But my (limited!) understanding is that it's not a platform problem
> you are solving, but one of this special kind of controller, which
> nobody else would ever run into.
I would vouch to extend
struct mmc {
struct list_head link;
char name[32];
void *priv;
uint voltages;
uint version;
uint f_min;
uint f_max;
int high_capacity;
uint bus_width;
uint clock;
uint card_caps;
uint host_caps;
+ uint host_maxblk;
+ uint host_maxdmalen;
uint ocr;
uint scr[2];
uint csd[4];
uint cid[4];
ushort rca;
uint tran_speed;
uint read_bl_len;
uint write_bl_len;
u64 capacity;
block_dev_desc_t block_dev;
int (*send_cmd)(struct mmc *mmc,
struct mmc_cmd *cmd, struct mmc_data *data);
void (*set_ios)(struct mmc *mmc);
int (*init)(struct mmc *mmc);
};
have the driver fill those values and the common mmc part act upon them,
provided they are non-zero. Zero means no limitation on the host side.
This should not break existing code.
I fail, however, to understand the 512 KiB limit on that hardware. It
would allow for only 1024 blocks, despite the 65535 allowed by the register.
Also I assume that limit is about a 512k boundary, not a 512k length???
Reinhard
next prev parent reply other threads:[~2010-10-10 9:33 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
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 [this message]
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=4CB1886B.8090209@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.