On Mon, Mar 18, 2019 at 7:01 PM Oleksij Rempel <linux@xxxxxxxxxxxxxxxx> wrote: > First of all, I would suggest to investigate if DMA is working. It's not. This looks like a good starting point. alcor_pre_req() has: if (cmd->opcode != 18) return; cmd18 is MMC_READ_MULTIPLE_BLOCK. However in this case (my dd read test), it is using cmd17 (MMC_READ_SINGLE_BLOCK). I believe the 17 vs 18 choice is made in mmc_blk_rw_rq_prep(): if (brq->data.blocks > 1 || do_rel_wr) { readcmd = MMC_READ_MULTIPLE_BLOCK; writecmd = MMC_WRITE_MULTIPLE_BLOCK; } else { brq->mrq.stop = NULL; readcmd = MMC_READ_SINGLE_BLOCK; writecmd = MMC_WRITE_BLOCK; } So it's only requesting a single block of data. I found another hint in mmc_blk_data_prep() which lead me to alcor_init_mmc(): mmc->max_segs = AU6601_MAX_DMA_SEGMENTS; mmc->max_seg_size = AU6601_MAX_DMA_BLOCK_SIZE; mmc->max_blk_size = mmc->max_seg_size; mmc->max_blk_count = mmc->max_segs; and AU6601_MAX_DMA_SEGMENTS is 1. So max_blk_count is 1 and this means block.c will always choose a single block read, which alcor.c does not DMA-accelerate. I'll come back to look in more detail, but if you have any quick comments at this stage that would be handy. Thanks! Daniel