On Mon, Oct 16, 2017 at 2:07 PM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > On Mon, Oct 16, 2017 at 1:41 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >> On Mon, Oct 16, 2017 at 11:02 AM, Geert Uytterhoeven >> <geert@xxxxxxxxxxxxxx> wrote: >>>> IIUC, >>>> - Since the MMC_BOUNCE disappeared in v4.14-rc1, the MMC core will request a command with 64kbyte+ size. >>>> - So, swiotlb will got request 64kbyte+ size. This is different with previous version. >> >> Other people reported problems with that. Sorry about this... >> >> This problem should be solved by upstream >> commit de3ee99b097dd51938276e3af388cd4ad0f2750a >> "mmc: Delete bounce buffer handling" >> >> I just killed off the bounce buffers so they can't hurt anyone anymore. >> >> Can you check that you have this patch in your tree? > > Given Dirk saw the issue with v4.14-rc4, I'm afraid that patch is already > included :-( So the first issue is definately gone. Then it seems the driver is specifying to high ->max_seg_size since the buffer cannot be mapped? Unless you're using ADMA drivers/mmc/host/sdhci.c sets it as: mmc->max_seg_size = mmc->max_req_size; And: mmc->max_req_size = 524288; >> renesas_sdhi_internal_dmac ee100000.sd: swiotlb_tbl_map_single: test: >> size modified to 524288 bytes >> renesas_sdhi_internal_dmac ee100000.sd: swiotlb buffer is full (sz: >> 524288 bytes) So if your driver cannot handle 524288 bytes, why is it saying it can handle 524288 bytes? The MMC core will believe the claim is true, I guess maybe something in the current tree (such as coalesced blocks or whatever) is finally making this size of requests hit the driver (which is a good thing...) just that it was never doing that before and now it turns out it can't really handle that because of how the memory architecture or something works. I guess you need to figure out how big requests/segments this hardware can really handle and pass that to mmc->mas_req_size, mmc->max_seg_size. Sorry if my reasoning is dumb... need more coffee. Yours, Linus Walleij
