Hi Reinhard, On Sun, Oct 10, 2010 at 5:33 PM, Reinhard Meyer <[email protected]> wrote: > 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.
I like this modification. > > 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??? > Yes, the 512KiB is intend to be a dma boudary. The 512 KiB is used by Linux, for it didn't want to handle the DMA interrupt, I guess so. Best regards, Lei _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
