@marius : Are you working on adding ADMA support for sdhci(4) or planning to do so in the near future? If not, I might make an attempt to add ADMA2 support. I was not aware of the MAXPHYS limitation, increasing MAXPHYS to 1MB, I was able to get a further increase in throughput values. I got this idea from this thread (https://lists.freebsd.org/pipermail/freebsd-arch/2010-March/010022.html), where this seems to be a viable option for amd64 platforms.

In D17865#382016, @marius wrote:

It probably makes sense and is safe to bump DMA_BLOCK_SIZE and DMA_BOUNDARY. However, in order to not waste considerable amounts of the static buffer, they should be based on MAXPHYS (which defaults to 128 KiB) as FreeBSD simply won't do transfers larger than that. The 512 KiB maximum SDMA buffer boundary also needs to be taken into account with these, though, as MAXPHYS is configurable.
That said, I'm not sure bumping DMA_BLOCK_SIZE and DMA_BOUNDARY is worth the trouble; the SDHCI controllers of the SDMA-only era are known to be very quirky, which is why sdhci(4) e. g. implements its own variant of bounce buffering in order to deal with their problematic DMA engines. So I'd rather focus on implementing support for ADMA up to 64-bit ADMA3 and be done with the limitations of SDMA on newer gear and the fallout such a bump may cause with older.

FWIW, we run MAXPHYS of 8MB at Netflix. There's been talk of bumping MAXPHYS to 1MB from 128k since it helps a lot on more modern devices.

@marius : Don't mean to badger, is there an alternate acceptable way I could go about increasing sdhci performance without increasing the DMA_BLOCK_SIZE. Or if you're planning to add ADMA support, can you maybe let us know when it might become available?