On Mon, May 15, 2017 at 4:04 PM, Bartlomiej Zolnierkiewicz <b.zolnierkie@xxxxxxxxxxx> wrote: > [ I added Daniel, Marc & Steven to cc: ] >> The option CONFIG_MMC_BLOCK_BOUNCE is default y so the >> majority of platforms in the kernel already have it on, and >> it then gets turned off at runtime since most of these have >> a host->max_segs > 1. The few exceptions that have >> host->max_segs == 1 and still turn off the bounce buffering >> are those that disable it in their defconfig. >> >> Those are the following: >> >> arch/arm/configs/colibri_pxa300_defconfig >> arch/arm/configs/zeus_defconfig >> - Uses MMC_PXA, drivers/mmc/host/pxamci.c >> - Sets host->max_segs = NR_SG, which is 1 >> - This needs its bounce buffer deactivated so we set >> host->disable_bounce to true in the host driver > > [...] > >> arch/mips/configs/cavium_octeon_defconfig >> - Uses MMC_CAVIUM_OCTEON, drivers/mmc/host/cavium.c >> - Sets host->max_segs to 16 or 1 >> - Setting host->disable_bounce to be sure for the 1 case > > From looking at the code it seems that bounce buffering should > be always beneficial to MMC performance when host->max_segs == 1. > > It would be useful to know why these specific defconfigs > disable bounce buffering (to save memory?). Maybe the defaults > should be changed nowadays? I agree. But I can't test on pxamci and cavium so I would appreciate if the driver maintainers try to remove the flag (MMC_CAP_NO_BOUNCE_BUFF in the v2 patch set) and see what happens. I would be happy to cut this special flag altogether, but I am also afraid of screwing up some config :/ Yours, Linus Walleij -- 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
