Hi Stephen, On 03/17/2016 02:23 PM, Stephen Warren wrote: > On 03/16/2016 03:40 PM, Eric Nelson wrote: >> Signed-off-by: Eric Nelson <e...@nelint.com> > > Patch description. > >> --- >> drivers/mmc/mmc.c | 10 +++++++++- >> drivers/mmc/mmc_write.c | 7 +++++++ > > Presumably it makes sense for the cache to work for IDE, SATA, USB, > SCSI, ... too. I wonder if it's possible to put this code somewhere more > central than mmc*.c so it automatically applies to > dev_desc->block_read() (see include/part.h). Perhaps not since each > implementation supplies its own block_read function directly, so the > cache calls do need to be duplicated everywhere. >
Yeah. I haven't found a spot that would allow interception of the various block_read/write functions. The get_dev_hwpart() routine in disk/part.c is close, but it seems to be bypassed by cmd_mmc, cmd_sata, et cetera. I think the best that can be done is to provide a common shim that can easily be inserted from within the various block driver code. >> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c >> * >> * SPDX-License-Identifier: GPL-2.0+ >> */ >> - >> #include <config.h> > > Nit: unrelated change. > > I think there is a missing call to cache_block_invalidate() when the MMC > device gets re-enumerated/re-initialized. The user would do something to > trigger this (e.g. mmc rescan) when they'd swapped an SD card out for > example. > Good catch. > Do you have any stats on how many operations this saves for typical FS > operations such as: > > - Partition table type identification (with various types such as > MBR/DOS, GPT, ...) > - Partition enumeration > - Filesystem identification (with various filesystems such as FAT, ext, > ...) > - File reads > Not yet, but I'm working something up that will allow this to be gathered easily. As soon as we implement a cache, it provides a nice spot for tracing operations. Regards, Eric _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
