[lkml]   [2007]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: sdio: enhance IO_RW_EXTENDED support
On Tue, 07 Aug 2007 13:51:39 +0100
David Vrabel <> wrote:

> In conclusion, the optimum block size is based solely on the card and
> host capabilities and should be limited to at most 512. Hence the
> block size can (and should) only be set once during card
> initialization.

Well, I can hardly argue with that thorough analysis. :)

I still like the idea of having the control in the core as much as
possible though. It allows people to experiment and figure out new and
clever ways of solving this in a way that can benefit all drivers.

So could we do most of what you propose, where we set the block size to
maximum, yet <= 512. Drivers can tweak this further by calling
sdio_force_block_size() (as need e.g. by my marvell card), and keep the
convention of 0 meaning "back to core default"? That way we can modify
the meaning of "core default" if more clever ways are available.

> > + if (size <= 512)
> > + goto byte_remainder;
> The maximum size for a byte mode transfer is the block size set in
> the card.

Right, sorry. It was late when I was hacking on this.

> > + /* avoid changing blksize needlessly */
> > + if (func->cur_blksz && ((blksz % func->cur_blksz)
> > == 0))
> > + blksz = func->cur_blksz;
> If func->blksize == 1024 and we perform transfers in the 512 to 1024
> range, this would set the block size on every transfer.

Quite right. I had no doubts that thing had room for improvement. But I
agree that we might as well select a fixed block size and stick with it
for the general case.

-- Pierre Ossman

Linux kernel, MMC maintainer
PulseAudio, core developer
rdesktop, core developer
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-08-07 15:37    [W:0.231 / U:4.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site