Messages in this thread | | | Date | Wed, 08 Aug 2007 11:19:33 +0100 | From | David Vrabel <> | Subject | Re: [patch 3/4] sdio: extend sdio_readsb() and friends to handle any length of buffer |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |