[RFC PATCH 0/5]mmc: Soft Command queue implementation for eMMC5.1 device

[RFC PATCH 0/5]mmc: Soft Command queue implementation for eMMC5.1 device

[Chuanxiao Dong]

Hello,

Seems community already have some implementation for the eMMC5.1 device command
queue feature, but that require the eMMC host controller to support CMDQ. In my
platform, I don't have this kind of eMMC host controller but I have a
Samsung eMMC5.1 device which can support the Command queue.

With this limitation, I have to let eMMC host controller to manually send the
CMD44/45/13/46/47. So in this way, more commands are needed for an I/O request,
more interrupts/schedule are needed in driver.

Even this way have some more software overhead, but it can still use the eMMC5.1
device Command queue feature. After test with the iozone command:
"iozone -zec -t 4 -i0 -i2 -F iozonefile1 iozonefile2 iozonefile3 iozonefile4 -+n
-I -r 4k -s 500m -O -R -+r -+D" to test random performance, I saw a performance
improvment for random read on my eMMC5.1 device:

		Random read
SW CMDQ:	5544.6
Normal Read:	3993.05

So I want to send this serial patches as RFC patch for reviewing


Chuanxiao Dong (5):
  mmc: replace sbc to precmd and add postcmd
  mmc: host: add runtime PM for host class dev
  mmc: queue: change mqrq_cur and mqrq_pre to mq qdepth
  mmc: core: add support for CMDQ feature in MMC Core stack
  mmc: sdhci: add SW CMDQ support for CHT SDHCI host

 drivers/mmc/card/block.c      |  538 ++++++++++++++++++++++++++++++++++++++---
 drivers/mmc/card/queue.c      |  213 ++++++++--------
 drivers/mmc/card/queue.h      |   14 +-
 drivers/mmc/core/core.c       |   78 +++++-
 drivers/mmc/core/host.c       |   14 ++
 drivers/mmc/core/mmc.c        |   43 +++-
 drivers/mmc/host/dw_mmc.c     |    8 +-
 drivers/mmc/host/mmci.c       |   14 +-
 drivers/mmc/host/omap_hsmmc.c |   18 +-
 drivers/mmc/host/sdhci-acpi.c |    1 -
 drivers/mmc/host/sdhci-pci.c  |    1 -
 drivers/mmc/host/sdhci.c      |  137 +++++++++--
 include/linux/mmc/card.h      |    3 +
 include/linux/mmc/core.h      |    5 +-
 include/linux/mmc/host.h      |    5 +
 include/linux/mmc/mmc.h       |   21 ++
 include/linux/mmc/pm.h        |    1 +
 include/linux/mmc/sdhci.h     |    1 +
 18 files changed, 909 insertions(+), 206 deletions(-)

-- 
1.7.10.4

Re: [RFC PATCH 0/5]mmc: Soft Command queue implementation for eMMC5.1 device

[Ulf Hansson]

On 19 December 2014 at 09:04, Chuanxiao Dong <chuanxiao.dong@intel.com> wrote:
> Hello,
>
> Seems community already have some implementation for the eMMC5.1 device command
> queue feature, but that require the eMMC host controller to support CMDQ. In my
> platform, I don't have this kind of eMMC host controller but I have a
> Samsung eMMC5.1 device which can support the Command queue.
>
> With this limitation, I have to let eMMC host controller to manually send the
> CMD44/45/13/46/47. So in this way, more commands are needed for an I/O request,
> more interrupts/schedule are needed in driver.
>
> Even this way have some more software overhead, but it can still use the eMMC5.1
> device Command queue feature. After test with the iozone command:
> "iozone -zec -t 4 -i0 -i2 -F iozonefile1 iozonefile2 iozonefile3 iozonefile4 -+n
> -I -r 4k -s 500m -O -R -+r -+D" to test random performance, I saw a performance
> improvment for random read on my eMMC5.1 device:
>
>                 Random read
> SW CMDQ:        5544.6
> Normal Read:    3993.05

Thanks for the patchset Chuanxiao! I will spend some time reviewing
this in more detail as soon as I can.

One important point though, before I start reviewing. I would like the
"Normal read" to be performed for a host driver supporting the
asynchronous mmc request feature. Currently sdhci don't support this,
but there is patch suggesting to add this which you might want to
use/review.
https://www.marc.info/?l=linux-mmc&m=141811588607432&w=2

Kind regards
Uffe

>
> So I want to send this serial patches as RFC patch for reviewing
>
>
> Chuanxiao Dong (5):
>   mmc: replace sbc to precmd and add postcmd
>   mmc: host: add runtime PM for host class dev
>   mmc: queue: change mqrq_cur and mqrq_pre to mq qdepth
>   mmc: core: add support for CMDQ feature in MMC Core stack
>   mmc: sdhci: add SW CMDQ support for CHT SDHCI host
>
>  drivers/mmc/card/block.c      |  538 ++++++++++++++++++++++++++++++++++++++---
>  drivers/mmc/card/queue.c      |  213 ++++++++--------
>  drivers/mmc/card/queue.h      |   14 +-
>  drivers/mmc/core/core.c       |   78 +++++-
>  drivers/mmc/core/host.c       |   14 ++
>  drivers/mmc/core/mmc.c        |   43 +++-
>  drivers/mmc/host/dw_mmc.c     |    8 +-
>  drivers/mmc/host/mmci.c       |   14 +-
>  drivers/mmc/host/omap_hsmmc.c |   18 +-
>  drivers/mmc/host/sdhci-acpi.c |    1 -
>  drivers/mmc/host/sdhci-pci.c  |    1 -
>  drivers/mmc/host/sdhci.c      |  137 +++++++++--
>  include/linux/mmc/card.h      |    3 +
>  include/linux/mmc/core.h      |    5 +-
>  include/linux/mmc/host.h      |    5 +
>  include/linux/mmc/mmc.h       |   21 ++
>  include/linux/mmc/pm.h        |    1 +
>  include/linux/mmc/sdhci.h     |    1 +
>  18 files changed, 909 insertions(+), 206 deletions(-)
>
> --
> 1.7.10.4
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC PATCH 0/5]mmc: Soft Command queue implementation for eMMC5.1 device

[Dong, Chuanxiao]

> -----Original Message-----
> From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
> Sent: Friday, December 19, 2014 5:02 PM
> To: Dong, Chuanxiao
> Cc: linux-mmc
> Subject: Re: [RFC PATCH 0/5]mmc: Soft Command queue implementation for
> eMMC5.1 device
> 
> On 19 December 2014 at 09:04, Chuanxiao Dong <chuanxiao.dong@intel.com>
> wrote:
> > Hello,
> >
> > Seems community already have some implementation for the eMMC5.1
> > device command queue feature, but that require the eMMC host
> > controller to support CMDQ. In my platform, I don't have this kind of
> > eMMC host controller but I have a Samsung eMMC5.1 device which can
> support the Command queue.
> >
> > With this limitation, I have to let eMMC host controller to manually
> > send the CMD44/45/13/46/47. So in this way, more commands are needed
> > for an I/O request, more interrupts/schedule are needed in driver.
> >
> > Even this way have some more software overhead, but it can still use
> > the eMMC5.1 device Command queue feature. After test with the iozone
> command:
> > "iozone -zec -t 4 -i0 -i2 -F iozonefile1 iozonefile2 iozonefile3
> > iozonefile4 -+n -I -r 4k -s 500m -O -R -+r -+D" to test random
> > performance, I saw a performance improvment for random read on my
> eMMC5.1 device:
> >
> >                 Random read
> > SW CMDQ:        5544.6
> > Normal Read:    3993.05
> 
> Thanks for the patchset Chuanxiao! I will spend some time reviewing this in
> more detail as soon as I can.
> 
> One important point though, before I start reviewing. I would like the "Normal
> read" to be performed for a host driver supporting the asynchronous mmc
> request feature. Currently sdhci don't support this, but there is patch
> suggesting to add this which you might want to use/review.
> https://www.marc.info/?l=linux-mmc&m=141811588607432&w=2
> 
> Kind regards
> Uffe
Thanks Uffe for the sharing. I will look into this patch and try on my platform.

Thanks
Chuanxiao

> 
> >
> > So I want to send this serial patches as RFC patch for reviewing
> >
> >
> > Chuanxiao Dong (5):
> >   mmc: replace sbc to precmd and add postcmd
> >   mmc: host: add runtime PM for host class dev
> >   mmc: queue: change mqrq_cur and mqrq_pre to mq qdepth
> >   mmc: core: add support for CMDQ feature in MMC Core stack
> >   mmc: sdhci: add SW CMDQ support for CHT SDHCI host
> >
> >  drivers/mmc/card/block.c      |  538
> ++++++++++++++++++++++++++++++++++++++---
> >  drivers/mmc/card/queue.c      |  213 ++++++++--------
> >  drivers/mmc/card/queue.h      |   14 +-
> >  drivers/mmc/core/core.c       |   78 +++++-
> >  drivers/mmc/core/host.c       |   14 ++
> >  drivers/mmc/core/mmc.c        |   43 +++-
> >  drivers/mmc/host/dw_mmc.c     |    8 +-
> >  drivers/mmc/host/mmci.c       |   14 +-
> >  drivers/mmc/host/omap_hsmmc.c |   18 +-
> >  drivers/mmc/host/sdhci-acpi.c |    1 -
> >  drivers/mmc/host/sdhci-pci.c  |    1 -
> >  drivers/mmc/host/sdhci.c      |  137 +++++++++--
> >  include/linux/mmc/card.h      |    3 +
> >  include/linux/mmc/core.h      |    5 +-
> >  include/linux/mmc/host.h      |    5 +
> >  include/linux/mmc/mmc.h       |   21 ++
> >  include/linux/mmc/pm.h        |    1 +
> >  include/linux/mmc/sdhci.h     |    1 +
> >  18 files changed, 909 insertions(+), 206 deletions(-)
> >
> > --
> > 1.7.10.4
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-mmc"
> > in the body of a message to majordomo@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/5]mmc: Soft Command queue implementation for eMMC5.1 device

[Jaehoon Chung]

Hi, Chuanxiao.

Was it published for the eMMC5.1 spec?

Best Regards,
Jaehoon Chung

On 12/19/2014 05:04 PM, Chuanxiao Dong wrote:
> Hello,
> 
> Seems community already have some implementation for the eMMC5.1 device command
> queue feature, but that require the eMMC host controller to support CMDQ. In my
> platform, I don't have this kind of eMMC host controller but I have a
> Samsung eMMC5.1 device which can support the Command queue.
> 
> With this limitation, I have to let eMMC host controller to manually send the
> CMD44/45/13/46/47. So in this way, more commands are needed for an I/O request,
> more interrupts/schedule are needed in driver.
> 
> Even this way have some more software overhead, but it can still use the eMMC5.1
> device Command queue feature. After test with the iozone command:
> "iozone -zec -t 4 -i0 -i2 -F iozonefile1 iozonefile2 iozonefile3 iozonefile4 -+n
> -I -r 4k -s 500m -O -R -+r -+D" to test random performance, I saw a performance
> improvment for random read on my eMMC5.1 device:
> 
> 		Random read
> SW CMDQ:	5544.6
> Normal Read:	3993.05
> 
> So I want to send this serial patches as RFC patch for reviewing
> 
> 
> Chuanxiao Dong (5):
>   mmc: replace sbc to precmd and add postcmd
>   mmc: host: add runtime PM for host class dev
>   mmc: queue: change mqrq_cur and mqrq_pre to mq qdepth
>   mmc: core: add support for CMDQ feature in MMC Core stack
>   mmc: sdhci: add SW CMDQ support for CHT SDHCI host
> 
>  drivers/mmc/card/block.c      |  538 ++++++++++++++++++++++++++++++++++++++---
>  drivers/mmc/card/queue.c      |  213 ++++++++--------
>  drivers/mmc/card/queue.h      |   14 +-
>  drivers/mmc/core/core.c       |   78 +++++-
>  drivers/mmc/core/host.c       |   14 ++
>  drivers/mmc/core/mmc.c        |   43 +++-
>  drivers/mmc/host/dw_mmc.c     |    8 +-
>  drivers/mmc/host/mmci.c       |   14 +-
>  drivers/mmc/host/omap_hsmmc.c |   18 +-
>  drivers/mmc/host/sdhci-acpi.c |    1 -
>  drivers/mmc/host/sdhci-pci.c  |    1 -
>  drivers/mmc/host/sdhci.c      |  137 +++++++++--
>  include/linux/mmc/card.h      |    3 +
>  include/linux/mmc/core.h      |    5 +-
>  include/linux/mmc/host.h      |    5 +
>  include/linux/mmc/mmc.h       |   21 ++
>  include/linux/mmc/pm.h        |    1 +
>  include/linux/mmc/sdhci.h     |    1 +
>  18 files changed, 909 insertions(+), 206 deletions(-)
> 

RE: [RFC PATCH 0/5]mmc: Soft Command queue implementation for eMMC5.1 device

[Dong, Chuanxiao]

Hi Jaehoon,

It is in a draft eMMC5.1 spec. I believe the official eMMC5.1 spec will be released soon.

Thanks
Chuanxiao

> -----Original Message-----
> From: linux-mmc-owner@vger.kernel.org
> [mailto:linux-mmc-owner@vger.kernel.org] On Behalf Of Jaehoon Chung
> Sent: Monday, December 22, 2014 12:56 PM
> To: Dong, Chuanxiao; linux-mmc@vger.kernel.org
> Subject: Re: [RFC PATCH 0/5]mmc: Soft Command queue implementation for
> eMMC5.1 device
> 
> Hi, Chuanxiao.
> 
> Was it published for the eMMC5.1 spec?
> 
> Best Regards,
> Jaehoon Chung
> 
> On 12/19/2014 05:04 PM, Chuanxiao Dong wrote:
> > Hello,
> >
> > Seems community already have some implementation for the eMMC5.1
> > device command queue feature, but that require the eMMC host
> > controller to support CMDQ. In my platform, I don't have this kind of
> > eMMC host controller but I have a Samsung eMMC5.1 device which can
> support the Command queue.
> >
> > With this limitation, I have to let eMMC host controller to manually
> > send the CMD44/45/13/46/47. So in this way, more commands are needed
> > for an I/O request, more interrupts/schedule are needed in driver.
> >
> > Even this way have some more software overhead, but it can still use
> > the eMMC5.1 device Command queue feature. After test with the iozone
> command:
> > "iozone -zec -t 4 -i0 -i2 -F iozonefile1 iozonefile2 iozonefile3
> > iozonefile4 -+n -I -r 4k -s 500m -O -R -+r -+D" to test random
> > performance, I saw a performance improvment for random read on my
> eMMC5.1 device:
> >
> > 		Random read
> > SW CMDQ:	5544.6
> > Normal Read:	3993.05
> >
> > So I want to send this serial patches as RFC patch for reviewing
> >
> >
> > Chuanxiao Dong (5):
> >   mmc: replace sbc to precmd and add postcmd
> >   mmc: host: add runtime PM for host class dev
> >   mmc: queue: change mqrq_cur and mqrq_pre to mq qdepth
> >   mmc: core: add support for CMDQ feature in MMC Core stack
> >   mmc: sdhci: add SW CMDQ support for CHT SDHCI host
> >
> >  drivers/mmc/card/block.c      |  538
> ++++++++++++++++++++++++++++++++++++++---
> >  drivers/mmc/card/queue.c      |  213 ++++++++--------
> >  drivers/mmc/card/queue.h      |   14 +-
> >  drivers/mmc/core/core.c       |   78 +++++-
> >  drivers/mmc/core/host.c       |   14 ++
> >  drivers/mmc/core/mmc.c        |   43 +++-
> >  drivers/mmc/host/dw_mmc.c     |    8 +-
> >  drivers/mmc/host/mmci.c       |   14 +-
> >  drivers/mmc/host/omap_hsmmc.c |   18 +-
> >  drivers/mmc/host/sdhci-acpi.c |    1 -
> >  drivers/mmc/host/sdhci-pci.c  |    1 -
> >  drivers/mmc/host/sdhci.c      |  137 +++++++++--
> >  include/linux/mmc/card.h      |    3 +
> >  include/linux/mmc/core.h      |    5 +-
> >  include/linux/mmc/host.h      |    5 +
> >  include/linux/mmc/mmc.h       |   21 ++
> >  include/linux/mmc/pm.h        |    1 +
> >  include/linux/mmc/sdhci.h     |    1 +
> >  18 files changed, 909 insertions(+), 206 deletions(-)
> >
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body
> of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/5]mmc: Soft Command queue implementation for eMMC5.1 device

[Jaehoon Chung]

Hi, Dong.

On 12/23/2014 11:30 AM, Dong, Chuanxiao wrote:
> Hi Jaehoon,
> 
> It is in a draft eMMC5.1 spec. I believe the official eMMC5.1 spec will be released soon.

Thanks~.I want to see the eMMC5.1 spec. :)
I will test this feature with my board.

Best Regards,
Jaehoon Chung

> 
> Thanks
> Chuanxiao
> 
>> -----Original Message-----
>> From: linux-mmc-owner@vger.kernel.org
>> [mailto:linux-mmc-owner@vger.kernel.org] On Behalf Of Jaehoon Chung
>> Sent: Monday, December 22, 2014 12:56 PM
>> To: Dong, Chuanxiao; linux-mmc@vger.kernel.org
>> Subject: Re: [RFC PATCH 0/5]mmc: Soft Command queue implementation for
>> eMMC5.1 device
>>
>> Hi, Chuanxiao.
>>
>> Was it published for the eMMC5.1 spec?
>>
>> Best Regards,
>> Jaehoon Chung
>>
>> On 12/19/2014 05:04 PM, Chuanxiao Dong wrote:
>>> Hello,
>>>
>>> Seems community already have some implementation for the eMMC5.1
>>> device command queue feature, but that require the eMMC host
>>> controller to support CMDQ. In my platform, I don't have this kind of
>>> eMMC host controller but I have a Samsung eMMC5.1 device which can
>> support the Command queue.
>>>
>>> With this limitation, I have to let eMMC host controller to manually
>>> send the CMD44/45/13/46/47. So in this way, more commands are needed
>>> for an I/O request, more interrupts/schedule are needed in driver.
>>>
>>> Even this way have some more software overhead, but it can still use
>>> the eMMC5.1 device Command queue feature. After test with the iozone
>> command:
>>> "iozone -zec -t 4 -i0 -i2 -F iozonefile1 iozonefile2 iozonefile3
>>> iozonefile4 -+n -I -r 4k -s 500m -O -R -+r -+D" to test random
>>> performance, I saw a performance improvment for random read on my
>> eMMC5.1 device:
>>>
>>> 		Random read
>>> SW CMDQ:	5544.6
>>> Normal Read:	3993.05
>>>
>>> So I want to send this serial patches as RFC patch for reviewing
>>>
>>>
>>> Chuanxiao Dong (5):
>>>   mmc: replace sbc to precmd and add postcmd
>>>   mmc: host: add runtime PM for host class dev
>>>   mmc: queue: change mqrq_cur and mqrq_pre to mq qdepth
>>>   mmc: core: add support for CMDQ feature in MMC Core stack
>>>   mmc: sdhci: add SW CMDQ support for CHT SDHCI host
>>>
>>>  drivers/mmc/card/block.c      |  538
>> ++++++++++++++++++++++++++++++++++++++---
>>>  drivers/mmc/card/queue.c      |  213 ++++++++--------
>>>  drivers/mmc/card/queue.h      |   14 +-
>>>  drivers/mmc/core/core.c       |   78 +++++-
>>>  drivers/mmc/core/host.c       |   14 ++
>>>  drivers/mmc/core/mmc.c        |   43 +++-
>>>  drivers/mmc/host/dw_mmc.c     |    8 +-
>>>  drivers/mmc/host/mmci.c       |   14 +-
>>>  drivers/mmc/host/omap_hsmmc.c |   18 +-
>>>  drivers/mmc/host/sdhci-acpi.c |    1 -
>>>  drivers/mmc/host/sdhci-pci.c  |    1 -
>>>  drivers/mmc/host/sdhci.c      |  137 +++++++++--
>>>  include/linux/mmc/card.h      |    3 +
>>>  include/linux/mmc/core.h      |    5 +-
>>>  include/linux/mmc/host.h      |    5 +
>>>  include/linux/mmc/mmc.h       |   21 ++
>>>  include/linux/mmc/pm.h        |    1 +
>>>  include/linux/mmc/sdhci.h     |    1 +
>>>  18 files changed, 909 insertions(+), 206 deletions(-)
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body
>> of a message to majordomo@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
> 

RE: [RFC PATCH 0/5]mmc: Soft Command queue implementation for eMMC5.1 device

[Alex Lemberg]

Hi Chuanxiao,

I have a question from the review of your SW CMDQ driver code.

>From the eMMC5.1 spec, the  "ready for execution" for each task should be cleared by the device only when the last data block has been fully transferred over the eMMC bus. 

However, from the code, I can recognize the following suspected case:

1. Host sends CMD44/45 commands for TID#0
2. Host sends CMD13 (QSR)  -> returned TID#0 ready for execution
3. Host sends CMD46 for TID#0
4. During the data transfer, host may send CMD13 (QSR)  -> returned TID#0 ready for execution (which is true since data is still in transfer)
5. Host sends CMD46 for TID#0 (same as sent in bullet#3) - which is a problem.

Please advise if my assumption above is correct.

Thanks,
Alex


> -----Original Message-----
> From: linux-mmc-owner@vger.kernel.org [mailto:linux-mmc-
> owner@vger.kernel.org] On Behalf Of Chuanxiao Dong
> Sent: Friday, December 19, 2014 10:05 AM
> To: linux-mmc@vger.kernel.org
> Subject: [RFC PATCH 0/5]mmc: Soft Command queue implementation for
> eMMC5.1 device
> 
> Hello,
> 
> Seems community already have some implementation for the eMMC5.1 device
> command queue feature, but that require the eMMC host controller to support
> CMDQ. In my platform, I don't have this kind of eMMC host controller but I
> have a Samsung eMMC5.1 device which can support the Command queue.
> 
> With this limitation, I have to let eMMC host controller to manually send the
> CMD44/45/13/46/47. So in this way, more commands are needed for an I/O
> request, more interrupts/schedule are needed in driver.
> 
> Even this way have some more software overhead, but it can still use the
> eMMC5.1 device Command queue feature. After test with the iozone
> command:
> "iozone -zec -t 4 -i0 -i2 -F iozonefile1 iozonefile2 iozonefile3 iozonefile4 -+n -I -r
> 4k -s 500m -O -R -+r -+D" to test random performance, I saw a performance
> improvment for random read on my eMMC5.1 device:
> 
> 		Random read
> SW CMDQ:	5544.6
> Normal Read:	3993.05
> 
> So I want to send this serial patches as RFC patch for reviewing
> 
> 
> Chuanxiao Dong (5):
>   mmc: replace sbc to precmd and add postcmd
>   mmc: host: add runtime PM for host class dev
>   mmc: queue: change mqrq_cur and mqrq_pre to mq qdepth
>   mmc: core: add support for CMDQ feature in MMC Core stack
>   mmc: sdhci: add SW CMDQ support for CHT SDHCI host
> 
>  drivers/mmc/card/block.c      |  538
> ++++++++++++++++++++++++++++++++++++++---
>  drivers/mmc/card/queue.c      |  213 ++++++++--------
>  drivers/mmc/card/queue.h      |   14 +-
>  drivers/mmc/core/core.c       |   78 +++++-
>  drivers/mmc/core/host.c       |   14 ++
>  drivers/mmc/core/mmc.c        |   43 +++-
>  drivers/mmc/host/dw_mmc.c     |    8 +-
>  drivers/mmc/host/mmci.c       |   14 +-
>  drivers/mmc/host/omap_hsmmc.c |   18 +-
>  drivers/mmc/host/sdhci-acpi.c |    1 -
>  drivers/mmc/host/sdhci-pci.c  |    1 -
>  drivers/mmc/host/sdhci.c      |  137 +++++++++--
>  include/linux/mmc/card.h      |    3 +
>  include/linux/mmc/core.h      |    5 +-
>  include/linux/mmc/host.h      |    5 +
>  include/linux/mmc/mmc.h       |   21 ++
>  include/linux/mmc/pm.h        |    1 +
>  include/linux/mmc/sdhci.h     |    1 +
>  18 files changed, 909 insertions(+), 206 deletions(-)
> 
> --
> 1.7.10.4
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body
> of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

RE: [RFC PATCH 0/5]mmc: Soft Command queue implementation for eMMC5.1 device

[Dong, Chuanxiao]

Hi Alex,

Can you please point me to the 5.1 spec which has the description of "" ready for execution" for each task should be cleared by the device only when the last data block has been fully transferred over the eMMC bus."? From my side, I have a draft version which I didn't find the similar description.

The current logical in driver is after receiving the command complete interrupt of CMD46/47, driver will send another CMD13 to check the ready for execution task without waiting for any data transfer complete interrupt. If it is as you mentioned, the ready for execution bit won't be cleared until the data transfer complete interrupt is received, right?

So far with the Samsung eMMC which is the only one I have, I didn't see issue with this logical.

Thanks
Chuanxiao

> -----Original Message-----
> From: Alex Lemberg [mailto:Alex.Lemberg@sandisk.com]
> Sent: Wednesday, February 11, 2015 10:01 PM
> To: Dong, Chuanxiao
> Cc: linux-mmc@vger.kernel.org; Yuliy Izrailov
> Subject: RE: [RFC PATCH 0/5]mmc: Soft Command queue implementation for
> eMMC5.1 device
> 
> Hi Chuanxiao,
> 
> I have a question from the review of your SW CMDQ driver code.
> 
> From the eMMC5.1 spec, the  "ready for execution" for each task should be
> cleared by the device only when the last data block has been fully transferred
> over the eMMC bus.
> 
> However, from the code, I can recognize the following suspected case:
> 
> 1. Host sends CMD44/45 commands for TID#0 2. Host sends CMD13 (QSR)  ->
> returned TID#0 ready for execution 3. Host sends CMD46 for TID#0 4. During
> the data transfer, host may send CMD13 (QSR)  -> returned TID#0 ready for
> execution (which is true since data is still in transfer) 5. Host sends CMD46 for
> TID#0 (same as sent in bullet#3) - which is a problem.
> 
> Please advise if my assumption above is correct.
> 
> Thanks,
> Alex
> 
> 
> > -----Original Message-----
> > From: linux-mmc-owner@vger.kernel.org [mailto:linux-mmc-
> > owner@vger.kernel.org] On Behalf Of Chuanxiao Dong
> > Sent: Friday, December 19, 2014 10:05 AM
> > To: linux-mmc@vger.kernel.org
> > Subject: [RFC PATCH 0/5]mmc: Soft Command queue implementation for
> > eMMC5.1 device
> >
> > Hello,
> >
> > Seems community already have some implementation for the eMMC5.1
> > device command queue feature, but that require the eMMC host
> > controller to support CMDQ. In my platform, I don't have this kind of
> > eMMC host controller but I have a Samsung eMMC5.1 device which can
> support the Command queue.
> >
> > With this limitation, I have to let eMMC host controller to manually
> > send the CMD44/45/13/46/47. So in this way, more commands are needed
> > for an I/O request, more interrupts/schedule are needed in driver.
> >
> > Even this way have some more software overhead, but it can still use
> > the
> > eMMC5.1 device Command queue feature. After test with the iozone
> > command:
> > "iozone -zec -t 4 -i0 -i2 -F iozonefile1 iozonefile2 iozonefile3
> > iozonefile4 -+n -I -r 4k -s 500m -O -R -+r -+D" to test random
> > performance, I saw a performance improvment for random read on my
> eMMC5.1 device:
> >
> > 		Random read
> > SW CMDQ:	5544.6
> > Normal Read:	3993.05
> >
> > So I want to send this serial patches as RFC patch for reviewing
> >
> >
> > Chuanxiao Dong (5):
> >   mmc: replace sbc to precmd and add postcmd
> >   mmc: host: add runtime PM for host class dev
> >   mmc: queue: change mqrq_cur and mqrq_pre to mq qdepth
> >   mmc: core: add support for CMDQ feature in MMC Core stack
> >   mmc: sdhci: add SW CMDQ support for CHT SDHCI host
> >
> >  drivers/mmc/card/block.c      |  538
> > ++++++++++++++++++++++++++++++++++++++---
> >  drivers/mmc/card/queue.c      |  213 ++++++++--------
> >  drivers/mmc/card/queue.h      |   14 +-
> >  drivers/mmc/core/core.c       |   78 +++++-
> >  drivers/mmc/core/host.c       |   14 ++
> >  drivers/mmc/core/mmc.c        |   43 +++-
> >  drivers/mmc/host/dw_mmc.c     |    8 +-
> >  drivers/mmc/host/mmci.c       |   14 +-
> >  drivers/mmc/host/omap_hsmmc.c |   18 +-
> >  drivers/mmc/host/sdhci-acpi.c |    1 -
> >  drivers/mmc/host/sdhci-pci.c  |    1 -
> >  drivers/mmc/host/sdhci.c      |  137 +++++++++--
> >  include/linux/mmc/card.h      |    3 +
> >  include/linux/mmc/core.h      |    5 +-
> >  include/linux/mmc/host.h      |    5 +
> >  include/linux/mmc/mmc.h       |   21 ++
> >  include/linux/mmc/pm.h        |    1 +
> >  include/linux/mmc/sdhci.h     |    1 +
> >  18 files changed, 909 insertions(+), 206 deletions(-)
> >
> > --
> > 1.7.10.4
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-mmc"
> > in the body of a message to majordomo@vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html

RE: [RFC PATCH 0/5]mmc: Soft Command queue implementation for eMMC5.1 device

[Alex Lemberg]

Hi Chuanxiao,

> -----Original Message-----
> From: Dong, Chuanxiao [mailto:chuanxiao.dong@intel.com]
> Sent: Friday, February 13, 2015 2:33 AM
> To: Alex Lemberg
> Cc: linux-mmc@vger.kernel.org; Yuliy Izrailov
> Subject: RE: [RFC PATCH 0/5]mmc: Soft Command queue implementation for
> eMMC5.1 device
> 
> Hi Alex,
> 
> Can you please point me to the 5.1 spec which has the description of "" ready
> for execution" for each task should be cleared by the device only when the last
> data block has been fully transferred over the eMMC bus."? From my side, I
> have a draft version which I didn't find the similar description.

We also use a draft version of the spec.
Since March 2014, all drafts contain that "ready for execution" description,
including the last draft that was approved.
For CMD46: "When the last data block has been fully transferred over the e*MMC bus,
the device should clear "ready for execution" for the task."
For CMD47: "When the busy signal following the last data block is released,
the device should clear "ready for execution" for the task."

> 
> The current logical in driver is after receiving the command complete interrupt
> of CMD46/47, driver will send another CMD13 to check the ready for execution
> task without waiting for any data transfer complete interrupt. If it is as you
> mentioned, the ready for execution bit won't be cleared until the data transfer
> complete interrupt is received, right?

Right. 

> 
> So far with the Samsung eMMC which is the only one I have, I didn't see issue
> with this logical.
> 
> Thanks
> Chuanxiao
> 
> > -----Original Message-----
> > From: Alex Lemberg [mailto:Alex.Lemberg@sandisk.com]
> > Sent: Wednesday, February 11, 2015 10:01 PM
> > To: Dong, Chuanxiao
> > Cc: linux-mmc@vger.kernel.org; Yuliy Izrailov
> > Subject: RE: [RFC PATCH 0/5]mmc: Soft Command queue implementation for
> > eMMC5.1 device
> >
> > Hi Chuanxiao,
> >
> > I have a question from the review of your SW CMDQ driver code.
> >
> > From the eMMC5.1 spec, the  "ready for execution" for each task should
> > be cleared by the device only when the last data block has been fully
> > transferred over the eMMC bus.
> >
> > However, from the code, I can recognize the following suspected case:
> >
> > 1. Host sends CMD44/45 commands for TID#0 2. Host sends CMD13 (QSR)
> > -> returned TID#0 ready for execution 3. Host sends CMD46 for TID#0 4.
> > During the data transfer, host may send CMD13 (QSR)  -> returned TID#0
> > ready for execution (which is true since data is still in transfer) 5.
> > Host sends CMD46 for
> > TID#0 (same as sent in bullet#3) - which is a problem.
> >
> > Please advise if my assumption above is correct.
> >
> > Thanks,
> > Alex
> >
> >
> > > -----Original Message-----
> > > From: linux-mmc-owner@vger.kernel.org [mailto:linux-mmc-
> > > owner@vger.kernel.org] On Behalf Of Chuanxiao Dong
> > > Sent: Friday, December 19, 2014 10:05 AM
> > > To: linux-mmc@vger.kernel.org
> > > Subject: [RFC PATCH 0/5]mmc: Soft Command queue implementation for
> > > eMMC5.1 device
> > >
> > > Hello,
> > >
> > > Seems community already have some implementation for the eMMC5.1
> > > device command queue feature, but that require the eMMC host
> > > controller to support CMDQ. In my platform, I don't have this kind
> > > of eMMC host controller but I have a Samsung eMMC5.1 device which
> > > can
> > support the Command queue.
> > >
> > > With this limitation, I have to let eMMC host controller to manually
> > > send the CMD44/45/13/46/47. So in this way, more commands are needed
> > > for an I/O request, more interrupts/schedule are needed in driver.
> > >
> > > Even this way have some more software overhead, but it can still use
> > > the
> > > eMMC5.1 device Command queue feature. After test with the iozone
> > > command:
> > > "iozone -zec -t 4 -i0 -i2 -F iozonefile1 iozonefile2 iozonefile3
> > > iozonefile4 -+n -I -r 4k -s 500m -O -R -+r -+D" to test random
> > > performance, I saw a performance improvment for random read on my
> > eMMC5.1 device:
> > >
> > > 		Random read
> > > SW CMDQ:	5544.6
> > > Normal Read:	3993.05
> > >
> > > So I want to send this serial patches as RFC patch for reviewing
> > >
> > >
> > > Chuanxiao Dong (5):
> > >   mmc: replace sbc to precmd and add postcmd
> > >   mmc: host: add runtime PM for host class dev
> > >   mmc: queue: change mqrq_cur and mqrq_pre to mq qdepth
> > >   mmc: core: add support for CMDQ feature in MMC Core stack
> > >   mmc: sdhci: add SW CMDQ support for CHT SDHCI host
> > >
> > >  drivers/mmc/card/block.c      |  538
> > > ++++++++++++++++++++++++++++++++++++++---
> > >  drivers/mmc/card/queue.c      |  213 ++++++++--------
> > >  drivers/mmc/card/queue.h      |   14 +-
> > >  drivers/mmc/core/core.c       |   78 +++++-
> > >  drivers/mmc/core/host.c       |   14 ++
> > >  drivers/mmc/core/mmc.c        |   43 +++-
> > >  drivers/mmc/host/dw_mmc.c     |    8 +-
> > >  drivers/mmc/host/mmci.c       |   14 +-
> > >  drivers/mmc/host/omap_hsmmc.c |   18 +-
> > >  drivers/mmc/host/sdhci-acpi.c |    1 -
> > >  drivers/mmc/host/sdhci-pci.c  |    1 -
> > >  drivers/mmc/host/sdhci.c      |  137 +++++++++--
> > >  include/linux/mmc/card.h      |    3 +
> > >  include/linux/mmc/core.h      |    5 +-
> > >  include/linux/mmc/host.h      |    5 +
> > >  include/linux/mmc/mmc.h       |   21 ++
> > >  include/linux/mmc/pm.h        |    1 +
> > >  include/linux/mmc/sdhci.h     |    1 +
> > >  18 files changed, 909 insertions(+), 206 deletions(-)
> > >
> > > --
> > > 1.7.10.4
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-mmc"
> > > in the body of a message to majordomo@vger.kernel.org More majordomo
> > > info at http://vger.kernel.org/majordomo-info.html

RE: [RFC PATCH 0/5]mmc: Soft Command queue implementation for eMMC5.1 device

[Dong, Chuanxiao]

> -----Original Message-----
> From: Alex Lemberg [mailto:Alex.Lemberg@sandisk.com]
> Sent: Monday, February 16, 2015 4:55 PM
> To: Dong, Chuanxiao
> Cc: linux-mmc@vger.kernel.org; Yuliy Izrailov
> Subject: RE: [RFC PATCH 0/5]mmc: Soft Command queue implementation for
> eMMC5.1 device
> 
> Hi Chuanxiao,
> 
> > -----Original Message-----
> > From: Dong, Chuanxiao [mailto:chuanxiao.dong@intel.com]
> > Sent: Friday, February 13, 2015 2:33 AM
> > To: Alex Lemberg
> > Cc: linux-mmc@vger.kernel.org; Yuliy Izrailov
> > Subject: RE: [RFC PATCH 0/5]mmc: Soft Command queue implementation for
> > eMMC5.1 device
> >
> > Hi Alex,
> >
> > Can you please point me to the 5.1 spec which has the description of
> > "" ready for execution" for each task should be cleared by the device
> > only when the last data block has been fully transferred over the eMMC
> > bus."? From my side, I have a draft version which I didn't find the similar
> description.
> 
> We also use a draft version of the spec.
> Since March 2014, all drafts contain that "ready for execution" description,
> including the last draft that was approved.
> For CMD46: "When the last data block has been fully transferred over the
> e*MMC bus, the device should clear "ready for execution" for the task."
> For CMD47: "When the busy signal following the last data block is released, the
> device should clear "ready for execution" for the task."

I see. My draft doesn't have these two sentences in the CMD46/47 session. I will follow up with latest version to update my source code.

BTW, why eMMC device cannot clear the "ready for execution" until CMD46/47 completed totally? Any restriction of this implementation?

Thanks
Chuanxiao

> 
> >
> > The current logical in driver is after receiving the command complete
> > interrupt of CMD46/47, driver will send another CMD13 to check the
> > ready for execution task without waiting for any data transfer
> > complete interrupt. If it is as you mentioned, the ready for execution
> > bit won't be cleared until the data transfer complete interrupt is received,
> right?
> 
> Right.
> 
> >
> > So far with the Samsung eMMC which is the only one I have, I didn't
> > see issue with this logical.
> >
> > Thanks
> > Chuanxiao
> >
> > > -----Original Message-----
> > > From: Alex Lemberg [mailto:Alex.Lemberg@sandisk.com]
> > > Sent: Wednesday, February 11, 2015 10:01 PM
> > > To: Dong, Chuanxiao
> > > Cc: linux-mmc@vger.kernel.org; Yuliy Izrailov
> > > Subject: RE: [RFC PATCH 0/5]mmc: Soft Command queue implementation
> > > for
> > > eMMC5.1 device
> > >
> > > Hi Chuanxiao,
> > >
> > > I have a question from the review of your SW CMDQ driver code.
> > >
> > > From the eMMC5.1 spec, the  "ready for execution" for each task
> > > should be cleared by the device only when the last data block has
> > > been fully transferred over the eMMC bus.
> > >
> > > However, from the code, I can recognize the following suspected case:
> > >
> > > 1. Host sends CMD44/45 commands for TID#0 2. Host sends CMD13 (QSR)
> > > -> returned TID#0 ready for execution 3. Host sends CMD46 for TID#0 4.
> > > During the data transfer, host may send CMD13 (QSR)  -> returned
> > > TID#0 ready for execution (which is true since data is still in transfer) 5.
> > > Host sends CMD46 for
> > > TID#0 (same as sent in bullet#3) - which is a problem.
> > >
> > > Please advise if my assumption above is correct.
> > >
> > > Thanks,
> > > Alex
> > >
> > >
> > > > -----Original Message-----
> > > > From: linux-mmc-owner@vger.kernel.org [mailto:linux-mmc-
> > > > owner@vger.kernel.org] On Behalf Of Chuanxiao Dong
> > > > Sent: Friday, December 19, 2014 10:05 AM
> > > > To: linux-mmc@vger.kernel.org
> > > > Subject: [RFC PATCH 0/5]mmc: Soft Command queue implementation for
> > > > eMMC5.1 device
> > > >
> > > > Hello,
> > > >
> > > > Seems community already have some implementation for the eMMC5.1
> > > > device command queue feature, but that require the eMMC host
> > > > controller to support CMDQ. In my platform, I don't have this kind
> > > > of eMMC host controller but I have a Samsung eMMC5.1 device which
> > > > can
> > > support the Command queue.
> > > >
> > > > With this limitation, I have to let eMMC host controller to
> > > > manually send the CMD44/45/13/46/47. So in this way, more commands
> > > > are needed for an I/O request, more interrupts/schedule are needed in
> driver.
> > > >
> > > > Even this way have some more software overhead, but it can still
> > > > use the
> > > > eMMC5.1 device Command queue feature. After test with the iozone
> > > > command:
> > > > "iozone -zec -t 4 -i0 -i2 -F iozonefile1 iozonefile2 iozonefile3
> > > > iozonefile4 -+n -I -r 4k -s 500m -O -R -+r -+D" to test random
> > > > performance, I saw a performance improvment for random read on my
> > > eMMC5.1 device:
> > > >
> > > > 		Random read
> > > > SW CMDQ:	5544.6
> > > > Normal Read:	3993.05
> > > >
> > > > So I want to send this serial patches as RFC patch for reviewing
> > > >
> > > >
> > > > Chuanxiao Dong (5):
> > > >   mmc: replace sbc to precmd and add postcmd
> > > >   mmc: host: add runtime PM for host class dev
> > > >   mmc: queue: change mqrq_cur and mqrq_pre to mq qdepth
> > > >   mmc: core: add support for CMDQ feature in MMC Core stack
> > > >   mmc: sdhci: add SW CMDQ support for CHT SDHCI host
> > > >
> > > >  drivers/mmc/card/block.c      |  538
> > > > ++++++++++++++++++++++++++++++++++++++---
> > > >  drivers/mmc/card/queue.c      |  213 ++++++++--------
> > > >  drivers/mmc/card/queue.h      |   14 +-
> > > >  drivers/mmc/core/core.c       |   78 +++++-
> > > >  drivers/mmc/core/host.c       |   14 ++
> > > >  drivers/mmc/core/mmc.c        |   43 +++-
> > > >  drivers/mmc/host/dw_mmc.c     |    8 +-
> > > >  drivers/mmc/host/mmci.c       |   14 +-
> > > >  drivers/mmc/host/omap_hsmmc.c |   18 +-
> > > >  drivers/mmc/host/sdhci-acpi.c |    1 -
> > > >  drivers/mmc/host/sdhci-pci.c  |    1 -
> > > >  drivers/mmc/host/sdhci.c      |  137 +++++++++--
> > > >  include/linux/mmc/card.h      |    3 +
> > > >  include/linux/mmc/core.h      |    5 +-
> > > >  include/linux/mmc/host.h      |    5 +
> > > >  include/linux/mmc/mmc.h       |   21 ++
> > > >  include/linux/mmc/pm.h        |    1 +
> > > >  include/linux/mmc/sdhci.h     |    1 +
> > > >  18 files changed, 909 insertions(+), 206 deletions(-)
> > > >
> > > > --
> > > > 1.7.10.4
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-mmc"
> > > > in the body of a message to majordomo@vger.kernel.org More
> > > > majordomo info at http://vger.kernel.org/majordomo-info.html

RE: [RFC PATCH 0/5]mmc: Soft Command queue implementation for eMMC5.1 device

[Alex Lemberg]

Hi Chuanxiao,

> -----Original Message-----
> From: Dong, Chuanxiao [mailto:chuanxiao.dong@intel.com]
> Sent: Monday, February 16, 2015 11:04 AM
> To: Alex Lemberg
> Cc: linux-mmc@vger.kernel.org; Yuliy Izrailov
> Subject: RE: [RFC PATCH 0/5]mmc: Soft Command queue implementation for
> eMMC5.1 device
> 
> 
> > -----Original Message-----
> > From: Alex Lemberg [mailto:Alex.Lemberg@sandisk.com]
> > Sent: Monday, February 16, 2015 4:55 PM
> > To: Dong, Chuanxiao
> > Cc: linux-mmc@vger.kernel.org; Yuliy Izrailov
> > Subject: RE: [RFC PATCH 0/5]mmc: Soft Command queue implementation for
> > eMMC5.1 device
> >
> > Hi Chuanxiao,
> >
> > > -----Original Message-----
> > > From: Dong, Chuanxiao [mailto:chuanxiao.dong@intel.com]
> > > Sent: Friday, February 13, 2015 2:33 AM
> > > To: Alex Lemberg
> > > Cc: linux-mmc@vger.kernel.org; Yuliy Izrailov
> > > Subject: RE: [RFC PATCH 0/5]mmc: Soft Command queue implementation
> > > for
> > > eMMC5.1 device
> > >
> > > Hi Alex,
> > >
> > > Can you please point me to the 5.1 spec which has the description of
> > > "" ready for execution" for each task should be cleared by the
> > > device only when the last data block has been fully transferred over
> > > the eMMC bus."? From my side, I have a draft version which I didn't
> > > find the similar
> > description.
> >
> > We also use a draft version of the spec.
> > Since March 2014, all drafts contain that "ready for execution"
> > description, including the last draft that was approved.
> > For CMD46: "When the last data block has been fully transferred over
> > the e*MMC bus, the device should clear "ready for execution" for the task."
> > For CMD47: "When the busy signal following the last data block is
> > released, the device should clear "ready for execution" for the task."
> 
> I see. My draft doesn't have these two sentences in the CMD46/47 session. I
> will follow up with latest version to update my source code.

Thank you!

> 
> BTW, why eMMC device cannot clear the "ready for execution" until
> CMD46/47 completed totally? Any restriction of this implementation?

This is how the spec is defining this feature. 
I believe it was done to prevent host from sending new command with same TaskID
while that TaskID executed.

> 
> Thanks
> Chuanxiao
> 
> >
> > >
> > > The current logical in driver is after receiving the command
> > > complete interrupt of CMD46/47, driver will send another CMD13 to
> > > check the ready for execution task without waiting for any data
> > > transfer complete interrupt. If it is as you mentioned, the ready
> > > for execution bit won't be cleared until the data transfer complete
> > > interrupt is received,
> > right?
> >
> > Right.
> >
> > >
> > > So far with the Samsung eMMC which is the only one I have, I didn't
> > > see issue with this logical.
> > >
> > > Thanks
> > > Chuanxiao
> > >
> > > > -----Original Message-----
> > > > From: Alex Lemberg [mailto:Alex.Lemberg@sandisk.com]
> > > > Sent: Wednesday, February 11, 2015 10:01 PM
> > > > To: Dong, Chuanxiao
> > > > Cc: linux-mmc@vger.kernel.org; Yuliy Izrailov
> > > > Subject: RE: [RFC PATCH 0/5]mmc: Soft Command queue implementation
> > > > for
> > > > eMMC5.1 device
> > > >
> > > > Hi Chuanxiao,
> > > >
> > > > I have a question from the review of your SW CMDQ driver code.
> > > >
> > > > From the eMMC5.1 spec, the  "ready for execution" for each task
> > > > should be cleared by the device only when the last data block has
> > > > been fully transferred over the eMMC bus.
> > > >
> > > > However, from the code, I can recognize the following suspected case:
> > > >
> > > > 1. Host sends CMD44/45 commands for TID#0 2. Host sends CMD13
> > > > (QSR)
> > > > -> returned TID#0 ready for execution 3. Host sends CMD46 for TID#0 4.
> > > > During the data transfer, host may send CMD13 (QSR)  -> returned
> > > > TID#0 ready for execution (which is true since data is still in transfer) 5.
> > > > Host sends CMD46 for
> > > > TID#0 (same as sent in bullet#3) - which is a problem.
> > > >
> > > > Please advise if my assumption above is correct.
> > > >
> > > > Thanks,
> > > > Alex
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: linux-mmc-owner@vger.kernel.org [mailto:linux-mmc-
> > > > > owner@vger.kernel.org] On Behalf Of Chuanxiao Dong
> > > > > Sent: Friday, December 19, 2014 10:05 AM
> > > > > To: linux-mmc@vger.kernel.org
> > > > > Subject: [RFC PATCH 0/5]mmc: Soft Command queue implementation
> > > > > for
> > > > > eMMC5.1 device
> > > > >
> > > > > Hello,
> > > > >
> > > > > Seems community already have some implementation for the eMMC5.1
> > > > > device command queue feature, but that require the eMMC host
> > > > > controller to support CMDQ. In my platform, I don't have this
> > > > > kind of eMMC host controller but I have a Samsung eMMC5.1 device
> > > > > which can
> > > > support the Command queue.
> > > > >
> > > > > With this limitation, I have to let eMMC host controller to
> > > > > manually send the CMD44/45/13/46/47. So in this way, more
> > > > > commands are needed for an I/O request, more interrupts/schedule
> > > > > are needed in
> > driver.
> > > > >
> > > > > Even this way have some more software overhead, but it can still
> > > > > use the
> > > > > eMMC5.1 device Command queue feature. After test with the iozone
> > > > > command:
> > > > > "iozone -zec -t 4 -i0 -i2 -F iozonefile1 iozonefile2 iozonefile3
> > > > > iozonefile4 -+n -I -r 4k -s 500m -O -R -+r -+D" to test random
> > > > > performance, I saw a performance improvment for random read on
> > > > > my
> > > > eMMC5.1 device:
> > > > >
> > > > > 		Random read
> > > > > SW CMDQ:	5544.6
> > > > > Normal Read:	3993.05
> > > > >
> > > > > So I want to send this serial patches as RFC patch for reviewing
> > > > >
> > > > >
> > > > > Chuanxiao Dong (5):
> > > > >   mmc: replace sbc to precmd and add postcmd
> > > > >   mmc: host: add runtime PM for host class dev
> > > > >   mmc: queue: change mqrq_cur and mqrq_pre to mq qdepth
> > > > >   mmc: core: add support for CMDQ feature in MMC Core stack
> > > > >   mmc: sdhci: add SW CMDQ support for CHT SDHCI host
> > > > >
> > > > >  drivers/mmc/card/block.c      |  538
> > > > > ++++++++++++++++++++++++++++++++++++++---
> > > > >  drivers/mmc/card/queue.c      |  213 ++++++++--------
> > > > >  drivers/mmc/card/queue.h      |   14 +-
> > > > >  drivers/mmc/core/core.c       |   78 +++++-
> > > > >  drivers/mmc/core/host.c       |   14 ++
> > > > >  drivers/mmc/core/mmc.c        |   43 +++-
> > > > >  drivers/mmc/host/dw_mmc.c     |    8 +-
> > > > >  drivers/mmc/host/mmci.c       |   14 +-
> > > > >  drivers/mmc/host/omap_hsmmc.c |   18 +-
> > > > >  drivers/mmc/host/sdhci-acpi.c |    1 -
> > > > >  drivers/mmc/host/sdhci-pci.c  |    1 -
> > > > >  drivers/mmc/host/sdhci.c      |  137 +++++++++--
> > > > >  include/linux/mmc/card.h      |    3 +
> > > > >  include/linux/mmc/core.h      |    5 +-
> > > > >  include/linux/mmc/host.h      |    5 +
> > > > >  include/linux/mmc/mmc.h       |   21 ++
> > > > >  include/linux/mmc/pm.h        |    1 +
> > > > >  include/linux/mmc/sdhci.h     |    1 +
> > > > >  18 files changed, 909 insertions(+), 206 deletions(-)
> > > > >
> > > > > --
> > > > > 1.7.10.4
> > > > > --
> > > > > To unsubscribe from this list: send the line "unsubscribe linux-mmc"
> > > > > in the body of a message to majordomo@vger.kernel.org More
> > > > > majordomo info at http://vger.kernel.org/majordomo-info.html