From: Pierre Ossman <drzeus-list@drzeus.cx>
To: David Vrabel <david.vrabel@csr.com>
Cc: linux-kernel@vger.kernel.org, david.vrabel@csr.com
Subject: Re: sdio: enhance IO_RW_EXTENDED support
Date: Tue, 7 Aug 2007 15:33:33 +0200 [thread overview]
Message-ID: <20070807153333.01c22a67@poseidon.drzeus.cx> (raw)
In-Reply-To: <46B86ADB.90000@csr.com>
On Tue, 07 Aug 2007 13:51:39 +0100
David Vrabel <david.vrabel@csr.com> 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.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
prev parent reply other threads:[~2007-08-07 13:33 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-31 15:36 David Vrabel
2007-07-31 15:36 ` sdio: parameterize SDIO FBR register defines David Vrabel
2007-08-04 13:26 ` Pierre Ossman
2007-08-06 10:14 ` David Vrabel
2007-08-06 14:58 ` Pierre Ossman
2007-07-31 15:36 ` sdio: set the functions' block size David Vrabel
2007-08-04 13:30 ` Pierre Ossman
2007-08-06 10:04 ` David Vrabel
2007-07-31 15:36 ` sdio: extend sdio_readsb() and friends to handle any length of buffer David Vrabel
2007-08-04 13:35 ` Pierre Ossman
2007-08-04 13:23 ` sdio: enhance IO_RW_EXTENDED support Pierre Ossman
2007-08-06 10:31 ` David Vrabel
2007-08-06 15:12 ` Pierre Ossman
2007-08-06 15:32 ` David Vrabel
2007-08-06 18:06 ` Pierre Ossman
2007-08-06 20:01 ` Pierre Ossman
2007-08-07 12:51 ` David Vrabel
2007-08-07 12:53 ` [patch 1/4] sdio: parameterize SDIO FBR register defines David Vrabel
2007-08-07 12:54 ` [patch 2/4] sdio: set the functions' block size David Vrabel
2007-08-07 13:38 ` Pierre Ossman
2007-08-07 17:20 ` David Vrabel
2007-08-07 17:54 ` Pierre Ossman
2007-08-08 9:46 ` David Vrabel
2007-08-08 10:06 ` Pierre Ossman
2007-08-08 10:19 ` David Vrabel
2007-08-07 12:55 ` [patch 3/4] sdio: extend sdio_readsb() and friends to handle any length of buffer David Vrabel
2007-08-07 13:42 ` Pierre Ossman
2007-08-07 20:17 ` Pierre Ossman
2007-08-08 10:19 ` David Vrabel
2007-08-08 10:37 ` Pierre Ossman
2007-08-08 13:22 ` David Vrabel
2007-08-08 13:23 ` [patch 1/3] sdio: add SDIO_FBR_BASE(f) macro David Vrabel
2007-08-08 13:23 ` [patch 2/3] sdio: set the functions' block size David Vrabel
2007-08-08 13:24 ` [patch 3/3] sdio: extend sdio_readsb() and friends to handle any length of buffer David Vrabel
2007-08-08 16:55 ` [patch 3/4] " Pierre Ossman
2007-08-07 12:55 ` [patch 4/4] sdio: disable CD resistor David Vrabel
2007-08-07 13:43 ` Pierre Ossman
2007-08-07 14:46 ` David Vrabel
2007-08-07 15:08 ` Pierre Ossman
2007-08-07 13:33 ` Pierre Ossman [this message]
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=20070807153333.01c22a67@poseidon.drzeus.cx \
--to=drzeus-list@drzeus.cx \
--cc=david.vrabel@csr.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome