Re: [patch 3/4] sdio: extend sdio_readsb() and friends to handle any length of buffer

[David Vrabel <david.vrabel@csr.com>]

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


.