Re: alcor mmc driver slow I/O

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Memonry Technology]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux