Hi, I'm investigating on eMMC 4.5 new features and have some concerns on below new features: 1. Large sector size (Native 4KB sector behavior) The eMMC4.5 Spec says 'All devices with capacities higher than 256GB shall have native sector size of 4KB'. And it also requires that in the Native 4KB sector size mode, data transfers still use 512B CC-protected blocks, but data shall be transferred in multiple of 8 such blocks (always multiples of 4KB). Since current kernel block layer uses 512B sector, then we have to pad the eMMC device read/write access to 4KB aligned if the block layer request sectors are not 4KB aligned. For example, if kernel block layer only wants to read 1 sector (512 byte) from the eMMC device, then the mmc driver has to read 8 sectors first and then return only the requested 1 sector. I think this will slow down mmc driver performance. So, I'm not sure whether it makes any sense to implement this feature. Any idea? 2. Packed commands The eMMC 4.5 Spec allows 'Read and write commands can be packed in groups of commands (either all read or all write) that transfer the data for all commands in the group in one transfer on the bus, to reduce overheads.' For both packed read/write command, the driver needs to first issue a CMD23 with the PACKED flag set and then a CMD25 to send a 'packed command header'. Then driver can read/write multiple data blocks with the CMD18/CMD25. To my understanding, in current kernel mmc driver, how many sectors/blocks can be transferred in one request is decided by the kernel block layer. In most of the popular platforms, I believe it will not transfer more than 512K bytes in one request. And there's no problem for transferring 512KB data in one CMD18/CMD25. So, only single CMD18/CMD25 is enough for current MMC driver and I don't see any benefits by implementing the packed commands in current MMC driver. Any comments? Thanks. Regards, Yunpeng -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
