[...]
> @@ -3713,6 +3751,43 @@ int sdhci_setup_host(struct sdhci_host *host)
> */
> mmc->max_blk_count = (host->quirks & SDHCI_QUIRK_NO_MULTIBLOCK) ? 1 : 65535;
>
> + if (mmc->max_segs == 1) {
> + unsigned int max_blocks;
> + unsigned int max_seg_size;
> +
> + max_seg_size = mmc->max_req_size;
> + max_blocks = max_seg_size / 512;
> + dev_info(mmc->parent, "host only supports SDMA, activate bounce buffer\n");
> +
> + /*
> + * When we just support one segment, we can get significant speedups
> + * by the help of a bounce buffer to group scattered reads/writes
> + * together.
> + *
> + * TODO: is this too big? Stealing too much memory? The old bounce
> + * buffer is max 64K. This should be the 512K that SDMA can handle
> + * if I read the code above right. Anyways let's try this.
> + * FIXME: use devm_*
> + */
> + host->bounce_buffer = dma_alloc_coherent(mmc->parent, max_seg_size,
> + &host->bounce_addr, GFP_KERNEL);
Why do you need dma_alloc_coherent() - allocated bounce buffer? Isn't
a regular kmalloc-ed buffer fine as a bounce buffer?
I am worried, also according to your above comment, that it's not
always going to work to request a large buffer like this, especially
with dma_alloc_coherent().
> + if (!host->bounce_buffer) {
> + dev_err(mmc->parent,
> + "failed to allocate %u bytes for bounce buffer\n",
> + max_seg_size);
> + return -ENOMEM;
Why not fall back to use the max_segs = 1 here. It may be slow, as
reported, but it works.
> + }
> + host->bounce_buffer_size = max_seg_size;
> +
> + /* Lie about this since we're bouncing */
> + mmc->max_segs = max_blocks;
> + mmc->max_seg_size = max_seg_size;
> +
> + dev_info(mmc->parent,
> + "bounce buffer: bounce up to %u segments into one, max segment size %u bytes\n",
> + max_blocks, max_seg_size);
> + }
> +
> return 0;
>
[...]
Kind regards
Uffe
--
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
