All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@csr.com>
To: Pierre Ossman <drzeus-list@drzeus.cx>
Cc: linux-kernel@vger.kernel.org
Subject: Re: sdio: enhance IO_RW_EXTENDED support
Date: Mon, 06 Aug 2007 16:32:40 +0100	[thread overview]
Message-ID: <46B73F18.5030109@csr.com> (raw)
In-Reply-To: <20070806171207.59fafa18@poseidon.drzeus.cx>

Pierre Ossman wrote:
> On Mon, 06 Aug 2007 11:31:19 +0100
> David Vrabel <david.vrabel@csr.com> wrote:
> 
>> I would expect the block size to be set once per card, and never be
>> changed and thus it's not logically a per-transfer operation.  We
>> certainly wouldn't want to change the block size willy-nilly as it's
>> an expensive operation.
>>
> 
> Indeed. It would of course be optimized so that it doesn't change the
> size needlessly.

Drivers may care about the block size though so you can't have it
changing behind their backs. e.g., they may need to pad data to a
multiple of the block size.

>>> I suspect that some transactions might require a certain block size.
>>> But we could satisfy that by stating that any transfer small enough
>>> to fit into one block will not be split up.
>> I consider it unlikely that any card would want to do anything other
>> than always use the largest possible block size.
>>
> 
> I have a counter example. I have here a Marvell wifi card which needs a
> firmware upload. And it seems to be rather picky about parameters
> during that upload.
>
> I'm still experimenting with a clean way to do things for this card.
> I'll get back to you. :)

sdio_set_block_size(func, 64); /* ew, this card is fussy */

download_firmware();

sdio_set_block_size(func, func->max_blksize); /* Ahhh, back to the
card's default */

If a card is fussy about the block size I don't think there's anything
cleaner than specifying directly in the driver.

David
-- 
David Vrabel, Software Engineer, Drivers group  Tel: +44 (0)1223 692562
CSR plc, Churchill House, Cambridge Business Park, Cowley Road, CB4 0WZ


.

  reply	other threads:[~2007-08-06 15:34 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-31 15:36 sdio: enhance IO_RW_EXTENDED support 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 [this message]
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             ` sdio: enhance IO_RW_EXTENDED support Pierre Ossman

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=46B73F18.5030109@csr.com \
    --to=david.vrabel@csr.com \
    --cc=drzeus-list@drzeus.cx \
    --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 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.