Pierre Ossman wrote:
> +static int sdio_io_rw_ext_helper(struct sdio_func *func, int write,
> + unsigned addr, int incr_addr, u8 *buf, unsigned size)
> +{
> + unsigned remainder = size;
> + int ret;
> + unsigned short blksz;
> + struct mmc_host *host = func->card->host;
> +
> + if (func->forced_blksz)
> + blksz = func->forced_blksz;
> + else {
> + blksz = func->max_blksz;
> + if (blksz > host->max_blk_size)
> + blksz = host->max_blk_size;
> + if (blksz > 512)
> + blksz = 512;
> + }
> +
> + WARN_ON(blksz > 512);
> +
> + ret = sdio_set_block_size(func, blksz);
> + if (ret)
> + return ret;
We need to know the block size in use /before/ the start of the transfer
as we would like drivers to be able to perform transfers with single
commands as this can result in significantly better performance[1]. The
drivers for our (CSR's) WiFi chips should do this. This isn't some (as
you suggested in a previous post) 'rare' requirement.
Therefore, we should not change the block size here.
We can also support block sizes > 512 and have this function do the
correct thing (as you'll see when I post my final patches).
David
[1] Consider a chip with a block size of 64 that regularly does short
transfers of between 64 - 128 bytes. Without padding, this would
require two commands per transfer instead of just one, cutting
performance by 50%! This scenario could be a WiFi chip doing VoIP.
--
David Vrabel, Software Engineer, Drivers group Tel: +44 (0)1223 692562
CSR plc, Churchill House, Cambridge Business Park, Cowley Road, CB4 0WZ
.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
