On 11/05/17 15:39, Ulf Hansson wrote: > The current mmc block device implementation is tricky when it comes to > claim and release of the host, while processing I/O requests. In principle > we need to claim the host at the first request entering the queue and then > we need to release the host, as soon as the queue becomes empty. This > complexity relates to the asynchronous request mechanism that the mmc block > device driver implements. > > For the legacy block interface that we currently implements, the above > issue can be addressed, as we can find out when the queue really becomes > empty. > > However, to find out whether the queue is empty, isn't really an applicable > method when using the new blk-mq interface, as requests are instead pushed > to us via the struct struct blk_mq_ops and its function pointers. That is not entirely true. We can pull requests by running the queue i.e. blk_mq_run_hw_queues(q, false), returning BLK_MQ_RQ_QUEUE_BUSY and stopping / starting the queue as needed. But, as I have written before, we could start with the most trivial implementation. ->queue_rq() puts the requests in a list and then the thread removes them from the list. That would be a good start because it would avoid having to deal with other issues at the same time. > > Being able to support the asynchronous request method using the blk-mq > interface, means we have to allow the mmc block device driver to re-claim > the host from different tasks/contexts, as we may have > 1 request to > operate upon. > > Therefore, let's extend the mmc_claim_host() API to support reference > counting for the mmc block device. Aren't you overlooking the possibility that there are many block devices per host. i.e. one per eMMC internal partition. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
