Orange Pi5 kernel

^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  1) ========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  2) MMC Asynchronous Request
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  3) ========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  4) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  5) Rationale
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  6) =========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  7) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  8) How significant is the cache maintenance overhead?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  9) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) It depends. Fast eMMC and multiple cache levels with speculative cache
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) pre-fetch makes the cache overhead relatively significant. If the DMA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) preparations for the next request are done in parallel with the current
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) transfer, the DMA preparation overhead would not affect the MMC performance.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) The intention of non-blocking (asynchronous) MMC requests is to minimize the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) time between when an MMC request ends and another MMC request begins.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) Using mmc_wait_for_req(), the MMC controller is idle while dma_map_sg and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) dma_unmap_sg are processing. Using non-blocking MMC requests makes it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) possible to prepare the caches for next job in parallel with an active
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) MMC request.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) MMC block driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) ================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) The mmc_blk_issue_rw_rq() in the MMC block driver is made non-blocking.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) The increase in throughput is proportional to the time it takes to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) prepare (major part of preparations are dma_map_sg() and dma_unmap_sg())
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) a request and how fast the memory is. The faster the MMC/SD is the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) more significant the prepare request time becomes. Roughly the expected
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) performance gain is 5% for large writes and 10% on large reads on a L2 cache
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) platform. In power save mode, when clocks run on a lower frequency, the DMA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) preparation may cost even more. As long as these slower preparations are run
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) in parallel with the transfer performance won't be affected.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) Details on measurements from IOZone and mmc_test
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) ================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) MMC core API extension
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) ======================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) There is one new public function mmc_start_req().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) It starts a new MMC command request for a host. The function isn't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) truly non-blocking. If there is an ongoing async request it waits
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) for completion of that request and starts the new one and returns. It
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) doesn't wait for the new request to complete. If there is no ongoing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) request it starts the new request and returns immediately.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) MMC host extensions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) ===================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) There are two optional members in the mmc_host_ops -- pre_req() and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) post_req() -- that the host driver may implement in order to move work
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) to before and after the actual mmc_host_ops.request() function is called.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) In the DMA case pre_req() may do dma_map_sg() and prepare the DMA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) descriptor, and post_req() runs the dma_unmap_sg().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) Optimize for the first request
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) ==============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) The first request in a series of requests can't be prepared in parallel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) with the previous transfer, since there is no previous request.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) The argument is_first_req in pre_req() indicates that there is no previous
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) request. The host driver may optimize for this scenario to minimize
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) the performance loss. A way to optimize for this is to split the current
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) request in two chunks, prepare the first chunk and start the request,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) and finally prepare the second chunk and start the transfer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) Pseudocode to handle is_first_req scenario with minimal prepare overhead::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77)   if (is_first_req && req->size > threshold)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78)      /* start MMC transfer for the complete transfer size */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79)      mmc_start_command(MMC_CMD_TRANSFER_FULL_SIZE);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81)      /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)       * Begin to prepare DMA while cmd is being processed by MMC.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83)       * The first chunk of the request should take the same time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84)       * to prepare as the "MMC process command time".
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85)       * If prepare time exceeds MMC cmd time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86)       * the transfer is delayed, guesstimate max 4k as first chunk size.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)       */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88)       prepare_1st_chunk_for_dma(req);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89)       /* flush pending desc to the DMAC (dmaengine.h) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90)       dma_issue_pending(req->dma_desc);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92)       prepare_2nd_chunk_for_dma(req);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93)       /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94)        * The second issue_pending should be called before MMC runs out
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95)        * of the first chunk. If the MMC runs out of the first data chunk
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96)        * before this call, the transfer is delayed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97)        */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98)       dma_issue_pending(req->dma_desc);