diff mbox

[v2] mmc: sdhci: fix incorrect command used in tuning

Message ID 1341307669-20834-1-git-send-email-aaron.lu@amd.com (mailing list archive)
State New, archived
Headers show

Commit Message

aaron lu July 3, 2012, 9:27 a.m. UTC
V2:
Fix for SDIO case: both SD and SDIO cards use cmd19 while eMMC use cmd21.

V1:
For SD hosts using retuning mode 1, when retuning timer expired, it will
need to do retuning in sdhci_request before processing the actual
request. But the retuning command is fixed: cmd19 for SD card and cmd21
for eMMC card, so we can't use the original request's command to do the
tuning.

And since the tuning command depends on the card type atteched to the
host, we will need to know the card type to use the correct tuning
command.

Cc: stable <stable@vger.kernel.org> [3.3+]
Signed-off-by: Aaron Lu <aaron.lu@amd.com>
---
 drivers/mmc/host/sdhci.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

Comments

Girish K S July 3, 2012, 9:58 a.m. UTC | #1
On 3 July 2012 14:57, Aaron Lu <aaron.lu@amd.com> wrote:
> V2:
> Fix for SDIO case: both SD and SDIO cards use cmd19 while eMMC use cmd21.
>
> V1:
> For SD hosts using retuning mode 1, when retuning timer expired, it will
> need to do retuning in sdhci_request before processing the actual
> request. But the retuning command is fixed: cmd19 for SD card and cmd21
> for eMMC card, so we can't use the original request's command to do the
> tuning.
>
> And since the tuning command depends on the card type atteched to the
> host, we will need to know the card type to use the correct tuning
> command.
>
> Cc: stable <stable@vger.kernel.org> [3.3+]
> Signed-off-by: Aaron Lu <aaron.lu@amd.com>
> ---
>  drivers/mmc/host/sdhci.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index f76736b..4e53e6b 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -27,6 +27,7 @@
>
>  #include <linux/mmc/mmc.h>
>  #include <linux/mmc/host.h>
> +#include <linux/mmc/card.h>
>
>  #include "sdhci.h"
>
> @@ -1245,6 +1246,7 @@ static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
>         struct sdhci_host *host;
>         bool present;
>         unsigned long flags;
> +       u32 tuning_opcode;
>
>         host = mmc_priv(mmc);
>
> @@ -1292,8 +1294,12 @@ static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
>                  */
>                 if ((host->flags & SDHCI_NEEDS_RETUNING) &&
>                     !(present_state & (SDHCI_DOING_WRITE | SDHCI_DOING_READ))) {
> +                       /* eMMC uses cmd21 while sd and sdio use cmd19 */
> +                       tuning_opcode = mmc->card->type == MMC_TYPE_MMC ?
> +                               MMC_SEND_TUNING_BLOCK_HS200 :
> +                               MMC_SEND_TUNING_BLOCK;
>                         spin_unlock_irqrestore(&host->lock, flags);
> -                       sdhci_execute_tuning(mmc, mrq->cmd->opcode);
> +                       sdhci_execute_tuning(mmc, tuning_opcode);
dont you think the previous implementation does the same. It is
already handled by introducing the 2nd parameter.
>                         spin_lock_irqsave(&host->lock, flags);
>
>                         /* Restore original mmc_request structure */
> --
> 1.7.11.1.3.g4c8a9db
>
>
--
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
aaron lu July 3, 2012, 11:31 a.m. UTC | #2
Hi,

On Tue, Jul 03, 2012 at 03:28:28PM +0530, Girish K S wrote:
> On 3 July 2012 14:57, Aaron Lu <aaron.lu@amd.com> wrote:
> > V2:
> > Fix for SDIO case: both SD and SDIO cards use cmd19 while eMMC use cmd21.
> >
> > V1:
> > For SD hosts using retuning mode 1, when retuning timer expired, it will
> > need to do retuning in sdhci_request before processing the actual
> > request. But the retuning command is fixed: cmd19 for SD card and cmd21
> > for eMMC card, so we can't use the original request's command to do the
> > tuning.
> >
> > And since the tuning command depends on the card type atteched to the
> > host, we will need to know the card type to use the correct tuning
> > command.
> >
> > Cc: stable <stable@vger.kernel.org> [3.3+]
> > Signed-off-by: Aaron Lu <aaron.lu@amd.com>
> > ---
> >  drivers/mmc/host/sdhci.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> > index f76736b..4e53e6b 100644
> > --- a/drivers/mmc/host/sdhci.c
> > +++ b/drivers/mmc/host/sdhci.c
> > @@ -27,6 +27,7 @@
> >
> >  #include <linux/mmc/mmc.h>
> >  #include <linux/mmc/host.h>
> > +#include <linux/mmc/card.h>
> >
> >  #include "sdhci.h"
> >
> > @@ -1245,6 +1246,7 @@ static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
> >         struct sdhci_host *host;
> >         bool present;
> >         unsigned long flags;
> > +       u32 tuning_opcode;
> >
> >         host = mmc_priv(mmc);
> >
> > @@ -1292,8 +1294,12 @@ static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
> >                  */
> >                 if ((host->flags & SDHCI_NEEDS_RETUNING) &&
> >                     !(present_state & (SDHCI_DOING_WRITE | SDHCI_DOING_READ))) {
> > +                       /* eMMC uses cmd21 while sd and sdio use cmd19 */
> > +                       tuning_opcode = mmc->card->type == MMC_TYPE_MMC ?
> > +                               MMC_SEND_TUNING_BLOCK_HS200 :
> > +                               MMC_SEND_TUNING_BLOCK;
> >                         spin_unlock_irqrestore(&host->lock, flags);
> > -                       sdhci_execute_tuning(mmc, mrq->cmd->opcode);
> > +                       sdhci_execute_tuning(mmc, tuning_opcode);
> dont you think the previous implementation does the same. It is
> already handled by introducing the 2nd parameter.

Suppose the following scenario:
mmc_start_request (e.g. mrq->cmd->opcode is 18 for this call)
  -> host->ops->request
  (sdhci's retuning timer expired, the flag SDHCI_NEEDS_RETUNING is set)
    -> sdhci_request
      -> sdhci_execute_tuning will be called before processing the
actual request due to retuning's requirement, but with the wrong command
opcode(cmd18) instead of cmd19 for sd/sdio or cmd21 for emmc.

The problem is with retuning, for normal explicit calls of
sdhci_execute_tuning, there is no problem with the code. But when
retuning is required, sdhci_execute_retuning will be executed implicitly
to the above layer and we have to use the right tuning command instead of
the current processing command, which can be any of the valid sd/sdio/mmc
commands.

-Aaron

> >                         spin_lock_irqsave(&host->lock, flags);
> >
> >                         /* Restore original mmc_request structure */
> > --
> > 1.7.11.1.3.g4c8a9db
> >
> >
--
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
Girish K S July 3, 2012, 11:57 a.m. UTC | #3
On 3 July 2012 17:01, Aaron Lu <aaron.lu@amd.com> wrote:
> Hi,
>
> On Tue, Jul 03, 2012 at 03:28:28PM +0530, Girish K S wrote:
>> On 3 July 2012 14:57, Aaron Lu <aaron.lu@amd.com> wrote:
>> > V2:
>> > Fix for SDIO case: both SD and SDIO cards use cmd19 while eMMC use cmd21.
>> >
>> > V1:
>> > For SD hosts using retuning mode 1, when retuning timer expired, it will
>> > need to do retuning in sdhci_request before processing the actual
>> > request. But the retuning command is fixed: cmd19 for SD card and cmd21
>> > for eMMC card, so we can't use the original request's command to do the
>> > tuning.
>> >
>> > And since the tuning command depends on the card type atteched to the
>> > host, we will need to know the card type to use the correct tuning
>> > command.
>> >
>> > Cc: stable <stable@vger.kernel.org> [3.3+]
>> > Signed-off-by: Aaron Lu <aaron.lu@amd.com>
>> > ---
>> >  drivers/mmc/host/sdhci.c | 8 +++++++-
>> >  1 file changed, 7 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> > index f76736b..4e53e6b 100644
>> > --- a/drivers/mmc/host/sdhci.c
>> > +++ b/drivers/mmc/host/sdhci.c
>> > @@ -27,6 +27,7 @@
>> >
>> >  #include <linux/mmc/mmc.h>
>> >  #include <linux/mmc/host.h>
>> > +#include <linux/mmc/card.h>
>> >
>> >  #include "sdhci.h"
>> >
>> > @@ -1245,6 +1246,7 @@ static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
>> >         struct sdhci_host *host;
>> >         bool present;
>> >         unsigned long flags;
>> > +       u32 tuning_opcode;
>> >
>> >         host = mmc_priv(mmc);
>> >
>> > @@ -1292,8 +1294,12 @@ static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
>> >                  */
>> >                 if ((host->flags & SDHCI_NEEDS_RETUNING) &&
>> >                     !(present_state & (SDHCI_DOING_WRITE | SDHCI_DOING_READ))) {
>> > +                       /* eMMC uses cmd21 while sd and sdio use cmd19 */
>> > +                       tuning_opcode = mmc->card->type == MMC_TYPE_MMC ?
>> > +                               MMC_SEND_TUNING_BLOCK_HS200 :
>> > +                               MMC_SEND_TUNING_BLOCK;
>> >                         spin_unlock_irqrestore(&host->lock, flags);
>> > -                       sdhci_execute_tuning(mmc, mrq->cmd->opcode);
>> > +                       sdhci_execute_tuning(mmc, tuning_opcode);
>> dont you think the previous implementation does the same. It is
>> already handled by introducing the 2nd parameter.
>
> Suppose the following scenario:
> mmc_start_request (e.g. mrq->cmd->opcode is 18 for this call)
>   -> host->ops->request
>   (sdhci's retuning timer expired, the flag SDHCI_NEEDS_RETUNING is set)
>     -> sdhci_request
>       -> sdhci_execute_tuning will be called before processing the
> actual request due to retuning's requirement, but with the wrong command
> opcode(cmd18) instead of cmd19 for sd/sdio or cmd21 for emmc.
>
> The problem is with retuning, for normal explicit calls of
> sdhci_execute_tuning, there is no problem with the code. But when
> retuning is required, sdhci_execute_retuning will be executed implicitly
> to the above layer and we have to use the right tuning command instead of
> the current processing command, which can be any of the valid sd/sdio/mmc
> commands.
Thanks for the explanation. is it possible to make a separate local
function for this. Since mmc_host_ops has a member .execute_tuning
which takes 2 parameters that are called from respective sd/mmc/sdio
card files. there might be conflict
>
> -Aaron
>
>> >                         spin_lock_irqsave(&host->lock, flags);
>> >
>> >                         /* Restore original mmc_request structure */
>> > --
>> > 1.7.11.1.3.g4c8a9db
>> >
>> >
--
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
Girish K S July 3, 2012, noon UTC | #4
On 3 July 2012 17:27, Girish K S <girish.shivananjappa@linaro.org> wrote:
> On 3 July 2012 17:01, Aaron Lu <aaron.lu@amd.com> wrote:
>> Hi,
>>
>> On Tue, Jul 03, 2012 at 03:28:28PM +0530, Girish K S wrote:
>>> On 3 July 2012 14:57, Aaron Lu <aaron.lu@amd.com> wrote:
>>> > V2:
>>> > Fix for SDIO case: both SD and SDIO cards use cmd19 while eMMC use cmd21.
>>> >
>>> > V1:
>>> > For SD hosts using retuning mode 1, when retuning timer expired, it will
>>> > need to do retuning in sdhci_request before processing the actual
>>> > request. But the retuning command is fixed: cmd19 for SD card and cmd21
>>> > for eMMC card, so we can't use the original request's command to do the
>>> > tuning.
>>> >
>>> > And since the tuning command depends on the card type atteched to the
>>> > host, we will need to know the card type to use the correct tuning
>>> > command.
>>> >
>>> > Cc: stable <stable@vger.kernel.org> [3.3+]
>>> > Signed-off-by: Aaron Lu <aaron.lu@amd.com>
>>> > ---
>>> >  drivers/mmc/host/sdhci.c | 8 +++++++-
>>> >  1 file changed, 7 insertions(+), 1 deletion(-)
>>> >
>>> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> > index f76736b..4e53e6b 100644
>>> > --- a/drivers/mmc/host/sdhci.c
>>> > +++ b/drivers/mmc/host/sdhci.c
>>> > @@ -27,6 +27,7 @@
>>> >
>>> >  #include <linux/mmc/mmc.h>
>>> >  #include <linux/mmc/host.h>
>>> > +#include <linux/mmc/card.h>
>>> >
>>> >  #include "sdhci.h"
>>> >
>>> > @@ -1245,6 +1246,7 @@ static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
>>> >         struct sdhci_host *host;
>>> >         bool present;
>>> >         unsigned long flags;
>>> > +       u32 tuning_opcode;
>>> >
>>> >         host = mmc_priv(mmc);
>>> >
>>> > @@ -1292,8 +1294,12 @@ static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
>>> >                  */
>>> >                 if ((host->flags & SDHCI_NEEDS_RETUNING) &&
>>> >                     !(present_state & (SDHCI_DOING_WRITE | SDHCI_DOING_READ))) {
>>> > +                       /* eMMC uses cmd21 while sd and sdio use cmd19 */
>>> > +                       tuning_opcode = mmc->card->type == MMC_TYPE_MMC ?
>>> > +                               MMC_SEND_TUNING_BLOCK_HS200 :
>>> > +                               MMC_SEND_TUNING_BLOCK;
>>> >                         spin_unlock_irqrestore(&host->lock, flags);
>>> > -                       sdhci_execute_tuning(mmc, mrq->cmd->opcode);
>>> > +                       sdhci_execute_tuning(mmc, tuning_opcode);
>>> dont you think the previous implementation does the same. It is
>>> already handled by introducing the 2nd parameter.
>>
>> Suppose the following scenario:
>> mmc_start_request (e.g. mrq->cmd->opcode is 18 for this call)
>>   -> host->ops->request
>>   (sdhci's retuning timer expired, the flag SDHCI_NEEDS_RETUNING is set)
>>     -> sdhci_request
>>       -> sdhci_execute_tuning will be called before processing the
>> actual request due to retuning's requirement, but with the wrong command
>> opcode(cmd18) instead of cmd19 for sd/sdio or cmd21 for emmc.
>>
>> The problem is with retuning, for normal explicit calls of
>> sdhci_execute_tuning, there is no problem with the code. But when
>> retuning is required, sdhci_execute_retuning will be executed implicitly
>> to the above layer and we have to use the right tuning command instead of
>> the current processing command, which can be any of the valid sd/sdio/mmc
>> commands.
> Thanks for the explanation. is it possible to make a separate local
> function for this. Since mmc_host_ops has a member .execute_tuning
> which takes 2 parameters that are called from respective sd/mmc/sdio
> card files. there might be conflict
sorry igonre it

>>
>> -Aaron
>>
>>> >                         spin_lock_irqsave(&host->lock, flags);
>>> >
>>> >                         /* Restore original mmc_request structure */
>>> > --
>>> > 1.7.11.1.3.g4c8a9db
>>> >
>>> >
--
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
Girish K S July 3, 2012, 12:02 p.m. UTC | #5
On 3 July 2012 17:27, Girish K S <girish.shivananjappa@linaro.org> wrote:
> On 3 July 2012 17:01, Aaron Lu <aaron.lu@amd.com> wrote:
>> Hi,
>>
>> On Tue, Jul 03, 2012 at 03:28:28PM +0530, Girish K S wrote:
>>> On 3 July 2012 14:57, Aaron Lu <aaron.lu@amd.com> wrote:
>>> > V2:
>>> > Fix for SDIO case: both SD and SDIO cards use cmd19 while eMMC use cmd21.
>>> >
>>> > V1:
>>> > For SD hosts using retuning mode 1, when retuning timer expired, it will
>>> > need to do retuning in sdhci_request before processing the actual
>>> > request. But the retuning command is fixed: cmd19 for SD card and cmd21
>>> > for eMMC card, so we can't use the original request's command to do the
>>> > tuning.
>>> >
>>> > And since the tuning command depends on the card type atteched to the
>>> > host, we will need to know the card type to use the correct tuning
>>> > command.
>>> >
>>> > Cc: stable <stable@vger.kernel.org> [3.3+]
>>> > Signed-off-by: Aaron Lu <aaron.lu@amd.com>
>>> > ---
>>> >  drivers/mmc/host/sdhci.c | 8 +++++++-
>>> >  1 file changed, 7 insertions(+), 1 deletion(-)
>>> >
>>> > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> > index f76736b..4e53e6b 100644
>>> > --- a/drivers/mmc/host/sdhci.c
>>> > +++ b/drivers/mmc/host/sdhci.c
>>> > @@ -27,6 +27,7 @@
>>> >
>>> >  #include <linux/mmc/mmc.h>
>>> >  #include <linux/mmc/host.h>
>>> > +#include <linux/mmc/card.h>
>>> >
>>> >  #include "sdhci.h"
>>> >
>>> > @@ -1245,6 +1246,7 @@ static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
>>> >         struct sdhci_host *host;
>>> >         bool present;
>>> >         unsigned long flags;
>>> > +       u32 tuning_opcode;
>>> >
>>> >         host = mmc_priv(mmc);
>>> >
>>> > @@ -1292,8 +1294,12 @@ static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
>>> >                  */
>>> >                 if ((host->flags & SDHCI_NEEDS_RETUNING) &&
>>> >                     !(present_state & (SDHCI_DOING_WRITE | SDHCI_DOING_READ))) {
>>> > +                       /* eMMC uses cmd21 while sd and sdio use cmd19 */
>>> > +                       tuning_opcode = mmc->card->type == MMC_TYPE_MMC ?
>>> > +                               MMC_SEND_TUNING_BLOCK_HS200 :
>>> > +                               MMC_SEND_TUNING_BLOCK;
>>> >                         spin_unlock_irqrestore(&host->lock, flags);
>>> > -                       sdhci_execute_tuning(mmc, mrq->cmd->opcode);
>>> > +                       sdhci_execute_tuning(mmc, tuning_opcode);
>>> dont you think the previous implementation does the same. It is
>>> already handled by introducing the 2nd parameter.
>>
>> Suppose the following scenario:
>> mmc_start_request (e.g. mrq->cmd->opcode is 18 for this call)
>>   -> host->ops->request
>>   (sdhci's retuning timer expired, the flag SDHCI_NEEDS_RETUNING is set)
>>     -> sdhci_request
>>       -> sdhci_execute_tuning will be called before processing the
>> actual request due to retuning's requirement, but with the wrong command
>> opcode(cmd18) instead of cmd19 for sd/sdio or cmd21 for emmc.
>>
>> The problem is with retuning, for normal explicit calls of
>> sdhci_execute_tuning, there is no problem with the code. But when
>> retuning is required, sdhci_execute_retuning will be executed implicitly
>> to the above layer and we have to use the right tuning command instead of
>> the current processing command, which can be any of the valid sd/sdio/mmc
>> commands.
> Thanks for the explanation. is it possible to make a separate local
> function for this. Since mmc_host_ops has a member .execute_tuning
> which takes 2 parameters that are called from respective sd/mmc/sdio
> card files. there might be conflict
Sorry i just read it wrongly (function has only 1 param).
>>
>> -Aaron
>>
>>> >                         spin_lock_irqsave(&host->lock, flags);
>>> >
>>> >                         /* Restore original mmc_request structure */
>>> > --
>>> > 1.7.11.1.3.g4c8a9db
>>> >
>>> >
--
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
aaron lu July 3, 2012, 1:52 p.m. UTC | #6
Hi,

On Tue, Jul 03, 2012 at 05:32:36PM +0530, Girish K S wrote:
> >>> > @@ -1292,8 +1294,12 @@ static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
> >>> >                  */
> >>> >                 if ((host->flags & SDHCI_NEEDS_RETUNING) &&
> >>> >                     !(present_state & (SDHCI_DOING_WRITE | SDHCI_DOING_READ))) {
> >>> > +                       /* eMMC uses cmd21 while sd and sdio use cmd19 */
> >>> > +                       tuning_opcode = mmc->card->type == MMC_TYPE_MMC ?
> >>> > +                               MMC_SEND_TUNING_BLOCK_HS200 :
> >>> > +                               MMC_SEND_TUNING_BLOCK;
> >>> >                         spin_unlock_irqrestore(&host->lock, flags);
> >>> > -                       sdhci_execute_tuning(mmc, mrq->cmd->opcode);
> >>> > +                       sdhci_execute_tuning(mmc, tuning_opcode);
> >>> dont you think the previous implementation does the same. It is
> >>> already handled by introducing the 2nd parameter.
> >>
> >> Suppose the following scenario:
> >> mmc_start_request (e.g. mrq->cmd->opcode is 18 for this call)
> >>   -> host->ops->request
> >>   (sdhci's retuning timer expired, the flag SDHCI_NEEDS_RETUNING is set)
> >>     -> sdhci_request
> >>       -> sdhci_execute_tuning will be called before processing the
> >> actual request due to retuning's requirement, but with the wrong command
> >> opcode(cmd18) instead of cmd19 for sd/sdio or cmd21 for emmc.
> >>
> >> The problem is with retuning, for normal explicit calls of
> >> sdhci_execute_tuning, there is no problem with the code. But when
> >> retuning is required, sdhci_execute_retuning will be executed implicitly
> >> to the above layer and we have to use the right tuning command instead of
> >> the current processing command, which can be any of the valid sd/sdio/mmc
> >> commands.
> > Thanks for the explanation. is it possible to make a separate local
> > function for this. Since mmc_host_ops has a member .execute_tuning
> > which takes 2 parameters that are called from respective sd/mmc/sdio
> > card files. there might be conflict
> Sorry i just read it wrongly (function has only 1 param).

So do you have any other problems with this patch?
If not, can I have your ack on this patch?

Thanks,
Aaron

--
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
Chris Ball July 4, 2012, 12:37 a.m. UTC | #7
Hi,

On Tue, Jul 03 2012, Aaron Lu wrote:
> V2:
> Fix for SDIO case: both SD and SDIO cards use cmd19 while eMMC use cmd21.
>
> V1:
> For SD hosts using retuning mode 1, when retuning timer expired, it will
> need to do retuning in sdhci_request before processing the actual
> request. But the retuning command is fixed: cmd19 for SD card and cmd21
> for eMMC card, so we can't use the original request's command to do the
> tuning.
>
> And since the tuning command depends on the card type atteched to the
> host, we will need to know the card type to use the correct tuning
> command.
>
> Cc: stable <stable@vger.kernel.org> [3.3+]
> Signed-off-by: Aaron Lu <aaron.lu@amd.com>
> ---

Thanks, pushed to mmc-next for 3.6 with Philip's Reviewed-by.

For next time, please put the patch changelog at this point in the patch
(after ---) so that it doesn't show up in the recorded commit message.

Also, please don't e-mail the patch to stable@ before it has entered
mainline.  They'll pick it up from the CC in the commit message when
Linus merges it, they don't want a copy of the patch before then.

Thanks!

- Chris.
aaron lu July 4, 2012, 5:11 a.m. UTC | #8
Hi Chris,

On Tue, Jul 03, 2012 at 08:37:33PM -0400, Chris Ball wrote:
> Hi,
> 
> On Tue, Jul 03 2012, Aaron Lu wrote:
> > V2:
> > Fix for SDIO case: both SD and SDIO cards use cmd19 while eMMC use cmd21.
> >
> > V1:
> > For SD hosts using retuning mode 1, when retuning timer expired, it will
> > need to do retuning in sdhci_request before processing the actual
> > request. But the retuning command is fixed: cmd19 for SD card and cmd21
> > for eMMC card, so we can't use the original request's command to do the
> > tuning.
> >
> > And since the tuning command depends on the card type atteched to the
> > host, we will need to know the card type to use the correct tuning
> > command.
> >
> > Cc: stable <stable@vger.kernel.org> [3.3+]
> > Signed-off-by: Aaron Lu <aaron.lu@amd.com>
> > ---
> 
> Thanks, pushed to mmc-next for 3.6 with Philip's Reviewed-by.
> 
> For next time, please put the patch changelog at this point in the patch
> (after ---) so that it doesn't show up in the recorded commit message.
> 
> Also, please don't e-mail the patch to stable@ before it has entered
> mainline.  They'll pick it up from the CC in the commit message when
> Linus merges it, they don't want a copy of the patch before then.

OK, thanks for pointing this out, will follow this in the future.

-Aaron

> 
> Thanks!
> 
> - Chris.
> -- 
> Chris Ball   <cjb@laptop.org>   <http://printf.net/>
> One Laptop Per Child
> --
> 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
> 

--
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
diff mbox

Patch

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index f76736b..4e53e6b 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -27,6 +27,7 @@ 
 
 #include <linux/mmc/mmc.h>
 #include <linux/mmc/host.h>
+#include <linux/mmc/card.h>
 
 #include "sdhci.h"
 
@@ -1245,6 +1246,7 @@  static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
 	struct sdhci_host *host;
 	bool present;
 	unsigned long flags;
+	u32 tuning_opcode;
 
 	host = mmc_priv(mmc);
 
@@ -1292,8 +1294,12 @@  static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
 		 */
 		if ((host->flags & SDHCI_NEEDS_RETUNING) &&
 		    !(present_state & (SDHCI_DOING_WRITE | SDHCI_DOING_READ))) {
+			/* eMMC uses cmd21 while sd and sdio use cmd19 */
+			tuning_opcode = mmc->card->type == MMC_TYPE_MMC ?
+				MMC_SEND_TUNING_BLOCK_HS200 :
+				MMC_SEND_TUNING_BLOCK;
 			spin_unlock_irqrestore(&host->lock, flags);
-			sdhci_execute_tuning(mmc, mrq->cmd->opcode);
+			sdhci_execute_tuning(mmc, tuning_opcode);
 			spin_lock_irqsave(&host->lock, flags);
 
 			/* Restore original mmc_request structure */