Command Queueing Support in eMMC
Subsystems (2)
cover Command Queueing Support in eMMC
In this patch series, we propose a method to add support for Command Queueing(CQ) feature added to eMMC-5.1 specification. This feature includes new commands for issuing tasks to the device and orders the execution of tasks to the device. It also has task management functions.
The initialization of CQ is decided based on the underlying driver capability and the capability advertised by the card through ext_csd.
We have selectively adopted the scsi design of pulling in requests from kernel block layer.
In order to support queueing of multiple requests, we have added a new issue function to mmc-queue. This selectively pulls the requests and prepares and issues it to the underlying driver. We have used the inherent tagging mechanism of kernel block layer to keep track and map tags to the slots of underlying driver. The current design doesn't block for the request to complete. We have separated the issuing and completion path of the request and tracking is done using the tag assigned to the request.
We have introduced a number of APIs to mmc block layer to facilitate servicing of requests.
The completion of requests is handled in a softirq registered with the kernel block layer during initialization. The error handling however would be done using a workqueue and is under development.
We have separated the legacy eMMC code from CQ code, so as to make it more manageable.
A new layer has been introduced to serve the CQ compliant drivers. This layer (cq_hci) has all the standard functionality implemented. It also has necessary hooks for convenience of platform drivers.
Asutosh Das (4):
mmc: queue: initialization of command-queue support
mmc: card: Add eMMC command queuing support in mmc block layer
mmc: cmdq: support for command queue enabled host
mmc: sdhci: add command queue support to sdhci
Sujit Reddy Thumma (1):
mmc: core: Add support to read command queue parameters
drivers/mmc/card/block.c | 378 ++++++++++++++++++++++++++++++++++++++++++++- drivers/mmc/card/queue.c | 160 ++++++++++++++++++- drivers/mmc/card/queue.h | 9 +- drivers/mmc/core/core.c | 87 +++++++++++ drivers/mmc/core/mmc.c | 19 +++ drivers/mmc/core/mmc_ops.c | 45 ++++-- drivers/mmc/host/Kconfig | 12 ++ drivers/mmc/host/Makefile | 1 + drivers/mmc/host/sdhci.c | 89 +++++++++++ drivers/mmc/host/sdhci.h | 2 + include/linux/mmc/card.h | 10 +- include/linux/mmc/core.h | 14 ++ include/linux/mmc/host.h | 72 +++++++++ include/linux/mmc/mmc.h | 9 ++ include/linux/mmc/sdhci.h | 1 + 15 files changed, 887 insertions(+), 21 deletions(-)
Signature · 4 lines
1.8.2.1 The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Quoted 31 lines · Asutosh Das
In this patch series, we propose a method to add support for Command Queueing(CQ) feature added to eMMC-5.1 specification. This feature includes new commands for issuing tasks to the device and orders the execution of tasks to the device. It also has task management functions.
The initialization of CQ is decided based on the underlying driver capability and the capability advertised by the card through
ext_csd.We have selectively adopted the scsi design of pulling in requests from kernel block layer.
In order to support queueing of multiple requests, we have added a new issue function to mmc-queue. This selectively pulls the requests and prepares and issues it to the underlying driver. We have used the inherent tagging mechanism of kernel block layer to keep track and map tags to the slots of underlying driver. The current design doesn't block for the request to complete. We have separated the issuing and completion path of the request and tracking is done using the tag assigned to the request.
We have introduced a number of APIs to mmc block layer to facilitate servicing of requests.
The completion of requests is handled in a softirq registered with the kernel block layer during initialization. The error handling however would be done using a workqueue and is under development.
Quoted 6 lines
We have separated the legacy eMMC code from CQ code, so as to make it more manageable.
A new layer has been introduced to serve the CQ compliant drivers. This layer (
cq_hci) has all the standard functionality implemented. It also has necessary hooks for convenience of platform drivers.
Hi Asutosh,
Thanks for posting this patchset! It's an interesting feature eMMC 5.1 has adopted. I also hope to get some input from several other reviewers around this patchset.
Let me start by give some generic initial feedback:
1) I think we have earlier merged/reviewed code for new eMMC/SD features, without demanding excellent code quality. I will not let that happen again, just so you guys know. Nothing said about this patchset as such!
2) Earlier we have accepted to add new features without these being properly validated on HW. The result is that we might have dead code, since it's hard to tell whether is actually used and thus working. I will demand all features to be tested on HW before I merge them. I guess that won't be an issue here, right?
3) Adding new big features shall be thoroughly justified. In this case, showed by improved performance. Such performance statistics shall in this case have the reference from a host driver that supports the asynchronous request mechanism. So, if your host driver doesn't support that currently, that's the first thing you should be looking into.
I will get back to review the actual patches as soon as I can.
Kind regards
Uffe
Hi Ulf
Quoted 52 lines · Ulf Hansson
Quoted 31 lines · Asutosh Das
In this patch series, we propose a method to add support for Command Queueing(CQ) feature added to eMMC-5.1 specification. This feature includes new commands for issuing tasks to the device and orders the execution of tasks to the device. It also has task management functions.
The initialization of CQ is decided based on the underlying driver capability and the capability advertised by the card through
ext_csd.We have selectively adopted the scsi design of pulling in requests from kernel block layer.
In order to support queueing of multiple requests, we have added a new issue function to mmc-queue. This selectively pulls the requests and prepares and issues it to the underlying driver. We have used the inherent tagging mechanism of kernel block layer to keep track and map tags to the slots of underlying driver. The current design doesn't block for the request to complete. We have separated the issuing and completion path of the request and tracking is done using the tag assigned to the request.
We have introduced a number of APIs to mmc block layer to facilitate servicing of requests.
The completion of requests is handled in a softirq registered with the kernel block layer during initialization. The error handling however would be done using a workqueue and is under development.
Quoted 6 lines
We have separated the legacy eMMC code from CQ code, so as to make it more manageable.
A new layer has been introduced to serve the CQ compliant drivers. This layer (
cq_hci) has all the standard functionality implemented. It also has necessary hooks for convenience of platform drivers.Hi Asutosh,
Thanks for posting this patchset! It's an interesting feature eMMC 5.1 has adopted. I also hope to get some input from several other reviewers around this patchset.
Let me start by give some generic initial feedback:
1) I think we have earlier merged/reviewed code for new eMMC/SD features, without demanding excellent code quality. I will not let that happen again, just so you guys know. Nothing said about this patchset as such!
Quoted 5 lines
2) Earlier we have accepted to add new features without these being properly validated on HW. The result is that we might have dead code, since it's hard to tell whether is actually used and thus working. I will demand all features to be tested on HW before I merge them. I guess that won't be an issue here, right?
I understand. Testing it on HW won't be an issue.
Quoted 7 lines
3) Adding new big features shall be thoroughly justified. In this case, showed by improved performance. Such performance statistics shall in this case have the reference from a host driver that supports the asynchronous request mechanism. So, if your host driver doesn't support that currently, that's the first thing you should be looking into.
Currently, it does support asynchronous request and the performance would be compared with that.
Quoted 6 lines
I will get back to review the actual patches as soon as I can.
Kind regards
Uffe
Signature · 2 lines
Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
Hi, Asutosh
Quoted 38 lines · Asutosh Das
In this patch series, we propose a method to add support for Command Queueing(CQ) feature added to eMMC-5.1 specification. This feature includes new commands for issuing tasks to the device and orders the execution of tasks to the device. It also has task management functions.
The initialization of CQ is decided based on the underlying driver capability and the capability advertised by the card through
ext_csd.We have selectively adopted the scsi design of pulling in requests from kernel block layer.
In order to support queueing of multiple requests, we have added a new issue function to mmc-queue. This selectively pulls the requests and prepares and issues it to the underlying driver. We have used the inherent tagging mechanism of kernel block layer to keep track and map tags to the slots of underlying driver. The current design doesn't block for the request to complete. We have separated the issuing and completion path of the request and tracking is done using the tag assigned to the request.
We have introduced a number of APIs to mmc block layer to facilitate servicing of requests.
The completion of requests is handled in a softirq registered with the kernel block layer during initialization. The error handling however would be done using a workqueue and is under development.
We have separated the legacy eMMC code from CQ code, so as to make it more manageable.
A new layer has been introduced to serve the CQ compliant drivers. This layer (
cq_hci) has all the standard functionality implemented. It also has necessary hooks for convenience of platform drivers.
Quoted 8 lines
Asutosh Das (4):
mmc: queue: initialization of command-queue support
mmc: card: Add eMMC command queuing support in mmc block layer
mmc: cmdq: support for command queue enabled host
mmc: sdhci: add command queue support to sdhciSujit Reddy Thumma (1):
mmc: core: Add support to read command queue parameters
Do you have any updated version of this patch set, which have been verified on your platform?
Thanks
Hi Asutosh,
Quoted 47 lines · Asutosh Das
In this patch series, we propose a method to add support for Command Queueing(CQ) feature added to eMMC-5.1 specification. This feature includes new commands for issuing tasks to the device and orders the execution of tasks to the device. It also has task management functions.
The initialization of CQ is decided based on the underlying driver capability and the capability advertised by the card through
ext_csd.We have selectively adopted the scsi design of pulling in requests from kernel block layer.
In order to support queueing of multiple requests, we have added a new issue function to mmc-queue. This selectively pulls the requests and prepares and issues it to the underlying driver. We have used the inherent tagging mechanism of kernel block layer to keep track and map tags to the slots of underlying driver. The current design doesn't block for the request to complete. We have separated the issuing and completion path of the request and tracking is done using the tag assigned to the request.
We have introduced a number of APIs to mmc block layer to facilitate servicing of requests.
The completion of requests is handled in a softirq registered with the kernel block layer during initialization. The error handling however would be done using a workqueue and is under development.
We have separated the legacy eMMC code from CQ code, so as to make it more manageable.
A new layer has been introduced to serve the CQ compliant drivers. This layer (
cq_hci) has all the standard functionality implemented. It also has necessary hooks for convenience of platform drivers.Asutosh Das (4):
mmc: queue: initialization of command-queue support
mmc: card: Add eMMC command queuing support in mmc block layer
mmc: cmdq: support for command queue enabled host
mmc: sdhci: add command queue support to sdhciSujit Reddy Thumma (1):
mmc: core: Add support to read command queue parameters
Quoted 17 lines
drivers/mmc/card/block.c | 378 ++++++++++++++++++++++++++++++++++++++++++++- drivers/mmc/card/queue.c | 160 ++++++++++++++++++- drivers/mmc/card/queue.h | 9 +- drivers/mmc/core/core.c | 87 +++++++++++ drivers/mmc/core/mmc.c | 19 +++ drivers/mmc/core/mmc_ops.c | 45 ++++-- drivers/mmc/host/Kconfig | 12 ++ drivers/mmc/host/Makefile | 1 + drivers/mmc/host/sdhci.c | 89 +++++++++++ drivers/mmc/host/sdhci.h | 2 + include/linux/mmc/card.h | 10 +- include/linux/mmc/core.h | 14 ++ include/linux/mmc/host.h | 72 +++++++++ include/linux/mmc/mmc.h | 9 ++ include/linux/mmc/sdhci.h | 1 + 15 files changed, 887 insertions(+), 21 deletions(-)
Are you still working on this?
Is there a updated version and any upstream plan?
I'm going to verify it.
Regards
Dong Aisheng
Quoted 9 lines
--
1.8.2.1The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
+ Kostya
Hi Aisheng,
Yes, a colleague of mine is working on upstreaming it. It should be done within a week or so.
Quoted 87 lines · Dong Aisheng
Hi Asutosh,
Quoted 47 lines · Asutosh Das
In this patch series, we propose a method to add support for Command Queueing(CQ) feature added to eMMC-5.1 specification. This feature includes new commands for issuing tasks to the device and orders the execution of tasks to the device. It also has task management functions.
The initialization of CQ is decided based on the underlying driver capability and the capability advertised by the card through
ext_csd.We have selectively adopted the scsi design of pulling in requests from kernel block layer.
In order to support queueing of multiple requests, we have added a new issue function to mmc-queue. This selectively pulls the requests and prepares and issues it to the underlying driver. We have used the inherent tagging mechanism of kernel block layer to keep track and map tags to the slots of underlying driver. The current design doesn't block for the request to complete. We have separated the issuing and completion path of the request and tracking is done using the tag assigned to the request.
We have introduced a number of APIs to mmc block layer to facilitate servicing of requests.
The completion of requests is handled in a softirq registered with the kernel block layer during initialization. The error handling however would be done using a workqueue and is under development.
We have separated the legacy eMMC code from CQ code, so as to make it more manageable.
A new layer has been introduced to serve the CQ compliant drivers. This layer (
cq_hci) has all the standard functionality implemented. It also has necessary hooks for convenience of platform drivers.Asutosh Das (4):
mmc: queue: initialization of command-queue support
mmc: card: Add eMMC command queuing support in mmc block layer
mmc: cmdq: support for command queue enabled host
mmc: sdhci: add command queue support to sdhciSujit Reddy Thumma (1):
mmc: core: Add support to read command queue parametersQuoted 17 lines
drivers/mmc/card/block.c | 378 ++++++++++++++++++++++++++++++++++++++++++++- drivers/mmc/card/queue.c | 160 ++++++++++++++++++- drivers/mmc/card/queue.h | 9 +- drivers/mmc/core/core.c | 87 +++++++++++ drivers/mmc/core/mmc.c | 19 +++ drivers/mmc/core/mmc_ops.c | 45 ++++-- drivers/mmc/host/Kconfig | 12 ++ drivers/mmc/host/Makefile | 1 + drivers/mmc/host/sdhci.c | 89 +++++++++++ drivers/mmc/host/sdhci.h | 2 + include/linux/mmc/card.h | 10 +- include/linux/mmc/core.h | 14 ++ include/linux/mmc/host.h | 72 +++++++++ include/linux/mmc/mmc.h | 9 ++ include/linux/mmc/sdhci.h | 1 + 15 files changed, 887 insertions(+), 21 deletions(-)Are you still working on this?
Is there a updated version and any upstream plan?
I'm going to verify it.Regards
Dong AishengQuoted 9 lines
--
1.8.2.1The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · Asutosh (asd)
+ Kostya
Hi Aisheng,
Yes, a colleague of mine is working on upstreaming it. It should be done within a week or so.
Great! Thanks!
Looking forward to it.
Regards
Dong Aisheng
Quoted 96 lines · Dong Aisheng
Quoted 92 lines
Hi Asutosh,
Quoted 57 lines · Asutosh Das
In this patch series, we propose a method to add support for Command Queueing(CQ) feature added to eMMC-5.1 specification. This feature includes new commands for issuing tasks to the device and orders the execution of tasks to the device. It also has task management functions.
The initialization of CQ is decided based on the underlying driver capability and the capability advertised by the card through
ext_csd.We have selectively adopted the scsi design of pulling in requests from kernel block layer.
In order to support queueing of multiple requests, we have added a new issue function to mmc-queue. This selectively pulls the requests and prepares and issues it to the underlying driver. We have used the inherent tagging mechanism of kernel block layer to keep track and map tags to the slots of underlying driver. The current design doesn't block for the request to complete. We have separated the issuing and completion path of the request and tracking is done using the tag assigned to the request.
We have introduced a number of APIs to mmc block layer to facilitate servicing of requests.
The completion of requests is handled in a softirq registered with the kernel block layer during initialization. The error handling however would be done using a workqueue and is under development.
We have separated the legacy eMMC code from CQ code, so as to make it more manageable.
A new layer has been introduced to serve the CQ compliant drivers. This layer (
cq_hci) has all the standard functionality implemented. It also has necessary hooks for convenience of platform drivers.Asutosh Das (4):
mmc: queue: initialization of command-queue support
mmc: card: Add eMMC command queuing support in mmc block layer
mmc: cmdq: support for command queue enabled host
mmc: sdhci: add command queue support to sdhciSujit Reddy Thumma (1):
mmc: core: Add support to read command queue parametersdrivers/mmc/card/block.c | 378 ++++++++++++++++++++++++++++++++++++++++++++- drivers/mmc/card/queue.c | 160 ++++++++++++++++++- drivers/mmc/card/queue.h | 9 +- drivers/mmc/core/core.c | 87 +++++++++++ drivers/mmc/core/mmc.c | 19 +++ drivers/mmc/core/mmc_ops.c | 45 ++++-- drivers/mmc/host/Kconfig | 12 ++ drivers/mmc/host/Makefile | 1 +Quoted 9 lines
drivers/mmc/host/sdhci.c | 89 +++++++++++ drivers/mmc/host/sdhci.h | 2 + include/linux/mmc/card.h | 10 +- include/linux/mmc/core.h | 14 ++ include/linux/mmc/host.h | 72 +++++++++ include/linux/mmc/mmc.h | 9 ++ include/linux/mmc/sdhci.h | 1 + 15 files changed, 887 insertions(+), 21 deletions(-)Are you still working on this?
Is there a updated version and any upstream plan?
I'm going to verify it.Regards
Dong AishengQuoted 9 lines
--
1.8.2.1The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html