* [U-Boot] [PATCH] mmc: Do not poll using CMD13 when changing timing
2019-02-06 13:11 [U-Boot] [PATCH] mmc: Do not poll using CMD13 when changing timing Marek Vasut
@ 2019-02-06 13:14 ` Jean-Jacques Hiblot
2019-02-11 6:56 ` Lukasz Majewski
2019-06-25 14:13 ` Jean-Jacques Hiblot
2 siblings, 0 replies; 11+ messages in thread
From: Jean-Jacques Hiblot @ 2019-02-06 13:14 UTC (permalink / raw)
To: u-boot
On 06/02/2019 14:11, Marek Vasut wrote:
> When using CMD6 to switch eMMC card timing from HS200/HS400 to HS/legacy,
> do not poll for the completion status using CMD13, but rather wait 50mS.
>
> Once the card receives the CMD6 and starts executing it, the bus is in
> undefined state until both the card finishes executing the command and
> until the controller switches the bus to matching timing configuration.
> During this time, it is not possible to transport any commands or data
> across the bus, which includes the CMD13.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Jaehoon Chung <jh80.chung@samsung.com>
> ---
> NOTE: Linux does the same thing.
> ---
> drivers/mmc/mmc.c | 28 ++++++++++++++++++++--------
> 1 file changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index c7730c9233..ababacf65a 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -720,7 +720,8 @@ static int mmc_send_ext_csd(struct mmc *mmc, u8 *ext_csd)
> return err;
> }
>
> -int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value)
> +static int __mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value,
> + bool send_status)
> {
> struct mmc_cmd cmd;
> int timeout = 1000;
> @@ -736,19 +737,29 @@ int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value)
> while (retries > 0) {
> ret = mmc_send_cmd(mmc, &cmd, NULL);
>
> - /* Waiting for the ready status */
> - if (!ret) {
> - ret = mmc_send_status(mmc, timeout);
> - return ret;
> + if (ret) {
> + retries--;
> + continue;
> + }
> +
> + if (!send_status) {
> + mdelay(50);
> + return 0;
> }
>
> - retries--;
> + /* Waiting for the ready status */
> + return mmc_send_status(mmc, timeout);
> }
>
> return ret;
>
> }
>
> +int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value)
> +{
> + return __mmc_switch(mmc, set, index, value, true);
> +}
> +
> #if !CONFIG_IS_ENABLED(MMC_TINY)
> static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode,
> bool hsdowngrade)
> @@ -780,8 +791,9 @@ static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode,
> default:
> return -EINVAL;
> }
> - err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING,
> - speed_bits);
> +
> + err = __mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING,
> + speed_bits, !hsdowngrade);
> if (err)
> return err;
>
Reviewed-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
^ permalink raw reply [flat|nested] 11+ messages in thread* [U-Boot] [PATCH] mmc: Do not poll using CMD13 when changing timing
2019-02-06 13:11 [U-Boot] [PATCH] mmc: Do not poll using CMD13 when changing timing Marek Vasut
2019-02-06 13:14 ` Jean-Jacques Hiblot
@ 2019-02-11 6:56 ` Lukasz Majewski
2019-06-25 14:13 ` Jean-Jacques Hiblot
2 siblings, 0 replies; 11+ messages in thread
From: Lukasz Majewski @ 2019-02-11 6:56 UTC (permalink / raw)
To: u-boot
Hi Marek,
> When using CMD6 to switch eMMC card timing from HS200/HS400 to
> HS/legacy, do not poll for the completion status using CMD13, but
> rather wait 50mS.
Nit: mS -> ms
>
> Once the card receives the CMD6 and starts executing it, the bus is in
> undefined state until both the card finishes executing the command and
> until the controller switches the bus to matching timing
> configuration. During this time, it is not possible to transport any
> commands or data across the bus, which includes the CMD13.
Just out of curiosity - is this 50ms time written in some spec? Or is
it only specific to Renesas HS200/HS400 ?
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Jaehoon Chung <jh80.chung@samsung.com>
> ---
> NOTE: Linux does the same thing.
> ---
> drivers/mmc/mmc.c | 28 ++++++++++++++++++++--------
> 1 file changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index c7730c9233..ababacf65a 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -720,7 +720,8 @@ static int mmc_send_ext_csd(struct mmc *mmc, u8
> *ext_csd) return err;
> }
>
> -int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value)
> +static int __mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value,
> + bool send_status)
> {
> struct mmc_cmd cmd;
> int timeout = 1000;
> @@ -736,19 +737,29 @@ int mmc_switch(struct mmc *mmc, u8 set, u8
> index, u8 value) while (retries > 0) {
> ret = mmc_send_cmd(mmc, &cmd, NULL);
>
> - /* Waiting for the ready status */
> - if (!ret) {
> - ret = mmc_send_status(mmc, timeout);
> - return ret;
> + if (ret) {
> + retries--;
> + continue;
> + }
> +
> + if (!send_status) {
> + mdelay(50);
> + return 0;
> }
>
> - retries--;
> + /* Waiting for the ready status */
> + return mmc_send_status(mmc, timeout);
> }
>
> return ret;
>
> }
>
> +int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value)
> +{
> + return __mmc_switch(mmc, set, index, value, true);
> +}
> +
> #if !CONFIG_IS_ENABLED(MMC_TINY)
> static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode,
> bool hsdowngrade)
> @@ -780,8 +791,9 @@ static int mmc_set_card_speed(struct mmc *mmc,
> enum bus_mode mode, default:
> return -EINVAL;
> }
> - err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
> EXT_CSD_HS_TIMING,
> - speed_bits);
> +
> + err = __mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
> EXT_CSD_HS_TIMING,
> + speed_bits, !hsdowngrade);
> if (err)
> return err;
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190211/46c2b9f6/attachment.sig>
^ permalink raw reply [flat|nested] 11+ messages in thread* [U-Boot] [PATCH] mmc: Do not poll using CMD13 when changing timing
2019-02-06 13:11 [U-Boot] [PATCH] mmc: Do not poll using CMD13 when changing timing Marek Vasut
2019-02-06 13:14 ` Jean-Jacques Hiblot
2019-02-11 6:56 ` Lukasz Majewski
@ 2019-06-25 14:13 ` Jean-Jacques Hiblot
2019-06-25 15:53 ` Marek Vasut
2 siblings, 1 reply; 11+ messages in thread
From: Jean-Jacques Hiblot @ 2019-06-25 14:13 UTC (permalink / raw)
To: u-boot
Hi Marek,
On 06/02/2019 14:11, Marek Vasut wrote:
> When using CMD6 to switch eMMC card timing from HS200/HS400 to HS/legacy,
> do not poll for the completion status using CMD13, but rather wait 50mS.
>
> Once the card receives the CMD6 and starts executing it, the bus is in
> undefined state until both the card finishes executing the command and
> until the controller switches the bus to matching timing configuration.
> During this time, it is not possible to transport any commands or data
> across the bus, which includes the CMD13.
Is it something that affects all platforms ?
I've been working on this on TI platforms lately and although I've seen
the same kind of problems. But they mostly go away If the code handling
the switch handles the SWITCH_ERROR bit.
JJ
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Jaehoon Chung <jh80.chung@samsung.com>
> ---
> NOTE: Linux does the same thing.
> ---
> drivers/mmc/mmc.c | 28 ++++++++++++++++++++--------
> 1 file changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index c7730c9233..ababacf65a 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -720,7 +720,8 @@ static int mmc_send_ext_csd(struct mmc *mmc, u8 *ext_csd)
> return err;
> }
>
> -int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value)
> +static int __mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value,
> + bool send_status)
> {
> struct mmc_cmd cmd;
> int timeout = 1000;
> @@ -736,19 +737,29 @@ int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value)
> while (retries > 0) {
> ret = mmc_send_cmd(mmc, &cmd, NULL);
>
> - /* Waiting for the ready status */
> - if (!ret) {
> - ret = mmc_send_status(mmc, timeout);
> - return ret;
> + if (ret) {
> + retries--;
> + continue;
> + }
> +
> + if (!send_status) {
> + mdelay(50);
> + return 0;
> }
>
> - retries--;
> + /* Waiting for the ready status */
> + return mmc_send_status(mmc, timeout);
> }
>
> return ret;
>
> }
>
> +int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value)
> +{
> + return __mmc_switch(mmc, set, index, value, true);
> +}
> +
> #if !CONFIG_IS_ENABLED(MMC_TINY)
> static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode,
> bool hsdowngrade)
> @@ -780,8 +791,9 @@ static int mmc_set_card_speed(struct mmc *mmc, enum bus_mode mode,
> default:
> return -EINVAL;
> }
> - err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING,
> - speed_bits);
> +
> + err = __mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING,
> + speed_bits, !hsdowngrade);
> if (err)
> return err;
>
^ permalink raw reply [flat|nested] 11+ messages in thread* [U-Boot] [PATCH] mmc: Do not poll using CMD13 when changing timing
2019-06-25 14:13 ` Jean-Jacques Hiblot
@ 2019-06-25 15:53 ` Marek Vasut
2019-06-25 19:07 ` Jean-Jacques Hiblot
0 siblings, 1 reply; 11+ messages in thread
From: Marek Vasut @ 2019-06-25 15:53 UTC (permalink / raw)
To: u-boot
On 6/25/19 4:13 PM, Jean-Jacques Hiblot wrote:
> Hi Marek,
>
> On 06/02/2019 14:11, Marek Vasut wrote:
>> When using CMD6 to switch eMMC card timing from HS200/HS400 to HS/legacy,
>> do not poll for the completion status using CMD13, but rather wait 50mS.
>>
>> Once the card receives the CMD6 and starts executing it, the bus is in
>> undefined state until both the card finishes executing the command and
>> until the controller switches the bus to matching timing configuration.
>> During this time, it is not possible to transport any commands or data
>> across the bus, which includes the CMD13.
>
> Is it something that affects all platforms ?
>
> I've been working on this on TI platforms lately and although I've seen
> the same kind of problems. But they mostly go away If the code handling
> the switch handles the SWITCH_ERROR bit.
The error probably happens because you send the card a command, but the
command hits the bus that's in some weird intermediate state. Either the
card didn't finish switching the bus properties yet, or it did, or it's
in the middle of it, but you cannot tell.
[...]
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH] mmc: Do not poll using CMD13 when changing timing
2019-06-25 15:53 ` Marek Vasut
@ 2019-06-25 19:07 ` Jean-Jacques Hiblot
2019-06-25 19:47 ` Marek Vasut
0 siblings, 1 reply; 11+ messages in thread
From: Jean-Jacques Hiblot @ 2019-06-25 19:07 UTC (permalink / raw)
To: u-boot
On 25/06/2019 17:53, Marek Vasut wrote:
> On 6/25/19 4:13 PM, Jean-Jacques Hiblot wrote:
>> Hi Marek,
>>
>> On 06/02/2019 14:11, Marek Vasut wrote:
>>> When using CMD6 to switch eMMC card timing from HS200/HS400 to HS/legacy,
>>> do not poll for the completion status using CMD13, but rather wait 50mS.
>>>
>>> Once the card receives the CMD6 and starts executing it, the bus is in
>>> undefined state until both the card finishes executing the command and
>>> until the controller switches the bus to matching timing configuration.
>>> During this time, it is not possible to transport any commands or data
>>> across the bus, which includes the CMD13.
>> Is it something that affects all platforms ?
>>
>> I've been working on this on TI platforms lately and although I've seen
>> the same kind of problems. But they mostly go away If the code handling
>> the switch handles the SWITCH_ERROR bit.
> The error probably happens because you send the card a command, but the
> command hits the bus that's in some weird intermediate state. Either the
> card didn't finish switching the bus properties yet, or it did, or it's
> in the middle of it, but you cannot tell.
OK thanks for the response.
If CMD13 can't be used because the bus is in an undefined state,
shouldn't send_cmd(CMD13) just fail ?
I'm asking because this is a 50ms delay in the hot path of the boot
process.
JJ
>
> [...]
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH] mmc: Do not poll using CMD13 when changing timing
2019-06-25 19:07 ` Jean-Jacques Hiblot
@ 2019-06-25 19:47 ` Marek Vasut
2019-06-26 9:22 ` Jean-Jacques Hiblot
0 siblings, 1 reply; 11+ messages in thread
From: Marek Vasut @ 2019-06-25 19:47 UTC (permalink / raw)
To: u-boot
On 6/25/19 9:07 PM, Jean-Jacques Hiblot wrote:
>
> On 25/06/2019 17:53, Marek Vasut wrote:
>> On 6/25/19 4:13 PM, Jean-Jacques Hiblot wrote:
>>> Hi Marek,
>>>
>>> On 06/02/2019 14:11, Marek Vasut wrote:
>>>> When using CMD6 to switch eMMC card timing from HS200/HS400 to
>>>> HS/legacy,
>>>> do not poll for the completion status using CMD13, but rather wait
>>>> 50mS.
>>>>
>>>> Once the card receives the CMD6 and starts executing it, the bus is in
>>>> undefined state until both the card finishes executing the command and
>>>> until the controller switches the bus to matching timing configuration.
>>>> During this time, it is not possible to transport any commands or data
>>>> across the bus, which includes the CMD13.
>>> Is it something that affects all platforms ?
>>>
>>> I've been working on this on TI platforms lately and although I've seen
>>> the same kind of problems. But they mostly go away If the code handling
>>> the switch handles the SWITCH_ERROR bit.
>> The error probably happens because you send the card a command, but the
>> command hits the bus that's in some weird intermediate state. Either the
>> card didn't finish switching the bus properties yet, or it did, or it's
>> in the middle of it, but you cannot tell.
>
> OK thanks for the response.
>
> If CMD13 can't be used because the bus is in an undefined state,
> shouldn't send_cmd(CMD13) just fail ?
So it would fail, but how do you guarantee the bus/card switched to the
new state and is reliably ready ? You can't, because you cannot
communicate with the card -- which is the entire problem here, you have
no way to communicate with the card while the bus is switching. However,
you can wait the maximum allowed time according to the spec, and then
the bus/card must be ready. If not, all bets are off.
> I'm asking because this is a 50ms delay in the hot path of the boot
> process.
I totally understand that, I have the same issue with HS200/HS400 on
R-Car Gen3, all the calibration shenanigans and this indeed add quite a
bit to the boot time. But I don't have a good answer here.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH] mmc: Do not poll using CMD13 when changing timing
2019-06-25 19:47 ` Marek Vasut
@ 2019-06-26 9:22 ` Jean-Jacques Hiblot
2019-06-26 9:50 ` Marek Vasut
0 siblings, 1 reply; 11+ messages in thread
From: Jean-Jacques Hiblot @ 2019-06-26 9:22 UTC (permalink / raw)
To: u-boot
On 25/06/2019 21:47, Marek Vasut wrote:
> On 6/25/19 9:07 PM, Jean-Jacques Hiblot wrote:
>> On 25/06/2019 17:53, Marek Vasut wrote:
>>> On 6/25/19 4:13 PM, Jean-Jacques Hiblot wrote:
>>>> Hi Marek,
>>>>
>>>> On 06/02/2019 14:11, Marek Vasut wrote:
>>>>> When using CMD6 to switch eMMC card timing from HS200/HS400 to
>>>>> HS/legacy,
>>>>> do not poll for the completion status using CMD13, but rather wait
>>>>> 50mS.
>>>>>
>>>>> Once the card receives the CMD6 and starts executing it, the bus is in
>>>>> undefined state until both the card finishes executing the command and
>>>>> until the controller switches the bus to matching timing configuration.
>>>>> During this time, it is not possible to transport any commands or data
>>>>> across the bus, which includes the CMD13.
>>>> Is it something that affects all platforms ?
>>>>
>>>> I've been working on this on TI platforms lately and although I've seen
>>>> the same kind of problems. But they mostly go away If the code handling
>>>> the switch handles the SWITCH_ERROR bit.
>>> The error probably happens because you send the card a command, but the
>>> command hits the bus that's in some weird intermediate state. Either the
>>> card didn't finish switching the bus properties yet, or it did, or it's
>>> in the middle of it, but you cannot tell.
>> OK thanks for the response.
>>
>> If CMD13 can't be used because the bus is in an undefined state,
>> shouldn't send_cmd(CMD13) just fail ?
> So it would fail, but how do you guarantee the bus/card switched to the
> new state and is reliably ready ? You can't, because you cannot
> communicate with the card -- which is the entire problem here, you have
> no way to communicate with the card while the bus is switching. However,
> you can wait the maximum allowed time according to the spec, and then
> the bus/card must be ready. If not, all bets are off.
>
>> I'm asking because this is a 50ms delay in the hot path of the boot
>> process.
> I totally understand that, I have the same issue with HS200/HS400 on
> R-Car Gen3, all the calibration shenanigans and this indeed add quite a*
> bit to the boot time. But I don't have a good answer here.
I'll post something using the existing wait_dat0() callback. If the
callback is implemented, we can forgo the 50ms delay and poll the dat0 line.
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH] mmc: Do not poll using CMD13 when changing timing
2019-06-26 9:22 ` Jean-Jacques Hiblot
@ 2019-06-26 9:50 ` Marek Vasut
2019-06-26 12:21 ` Jean-Jacques Hiblot
0 siblings, 1 reply; 11+ messages in thread
From: Marek Vasut @ 2019-06-26 9:50 UTC (permalink / raw)
To: u-boot
On 6/26/19 11:22 AM, Jean-Jacques Hiblot wrote:
>
> On 25/06/2019 21:47, Marek Vasut wrote:
>> On 6/25/19 9:07 PM, Jean-Jacques Hiblot wrote:
>>> On 25/06/2019 17:53, Marek Vasut wrote:
>>>> On 6/25/19 4:13 PM, Jean-Jacques Hiblot wrote:
>>>>> Hi Marek,
>>>>>
>>>>> On 06/02/2019 14:11, Marek Vasut wrote:
>>>>>> When using CMD6 to switch eMMC card timing from HS200/HS400 to
>>>>>> HS/legacy,
>>>>>> do not poll for the completion status using CMD13, but rather wait
>>>>>> 50mS.
>>>>>>
>>>>>> Once the card receives the CMD6 and starts executing it, the bus
>>>>>> is in
>>>>>> undefined state until both the card finishes executing the command
>>>>>> and
>>>>>> until the controller switches the bus to matching timing
>>>>>> configuration.
>>>>>> During this time, it is not possible to transport any commands or
>>>>>> data
>>>>>> across the bus, which includes the CMD13.
>>>>> Is it something that affects all platforms ?
>>>>>
>>>>> I've been working on this on TI platforms lately and although I've
>>>>> seen
>>>>> the same kind of problems. But they mostly go away If the code
>>>>> handling
>>>>> the switch handles the SWITCH_ERROR bit.
>>>> The error probably happens because you send the card a command, but the
>>>> command hits the bus that's in some weird intermediate state. Either
>>>> the
>>>> card didn't finish switching the bus properties yet, or it did, or it's
>>>> in the middle of it, but you cannot tell.
>>> OK thanks for the response.
>>>
>>> If CMD13 can't be used because the bus is in an undefined state,
>>> shouldn't send_cmd(CMD13) just fail ?
>> So it would fail, but how do you guarantee the bus/card switched to the
>> new state and is reliably ready ? You can't, because you cannot
>> communicate with the card -- which is the entire problem here, you have
>> no way to communicate with the card while the bus is switching. However,
>> you can wait the maximum allowed time according to the spec, and then
>> the bus/card must be ready. If not, all bets are off.
>>
>>> I'm asking because this is a 50ms delay in the hot path of the boot
>>> process.
>> I totally understand that, I have the same issue with HS200/HS400 on
>> R-Car Gen3, all the calibration shenanigans and this indeed add quite a*
>> bit to the boot time. But I don't have a good answer here.
>
> I'll post something using the existing wait_dat0() callback. If the
> callback is implemented, we can forgo the 50ms delay and poll the dat0
> line.
We can ? Do you have some more details ?
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH] mmc: Do not poll using CMD13 when changing timing
2019-06-26 9:50 ` Marek Vasut
@ 2019-06-26 12:21 ` Jean-Jacques Hiblot
2019-06-26 13:09 ` Marek Vasut
0 siblings, 1 reply; 11+ messages in thread
From: Jean-Jacques Hiblot @ 2019-06-26 12:21 UTC (permalink / raw)
To: u-boot
On 26/06/2019 11:50, Marek Vasut wrote:
> On 6/26/19 11:22 AM, Jean-Jacques Hiblot wrote:
>> On 25/06/2019 21:47, Marek Vasut wrote:
>>> On 6/25/19 9:07 PM, Jean-Jacques Hiblot wrote:
>>>> On 25/06/2019 17:53, Marek Vasut wrote:
>>>>> On 6/25/19 4:13 PM, Jean-Jacques Hiblot wrote:
>>>>>> Hi Marek,
>>>>>>
>>>>>> On 06/02/2019 14:11, Marek Vasut wrote:
>>>>>>> When using CMD6 to switch eMMC card timing from HS200/HS400 to
>>>>>>> HS/legacy,
>>>>>>> do not poll for the completion status using CMD13, but rather wait
>>>>>>> 50mS.
>>>>>>>
>>>>>>> Once the card receives the CMD6 and starts executing it, the bus
>>>>>>> is in
>>>>>>> undefined state until both the card finishes executing the command
>>>>>>> and
>>>>>>> until the controller switches the bus to matching timing
>>>>>>> configuration.
>>>>>>> During this time, it is not possible to transport any commands or
>>>>>>> data
>>>>>>> across the bus, which includes the CMD13.
>>>>>> Is it something that affects all platforms ?
>>>>>>
>>>>>> I've been working on this on TI platforms lately and although I've
>>>>>> seen
>>>>>> the same kind of problems. But they mostly go away If the code
>>>>>> handling
>>>>>> the switch handles the SWITCH_ERROR bit.
>>>>> The error probably happens because you send the card a command, but the
>>>>> command hits the bus that's in some weird intermediate state. Either
>>>>> the
>>>>> card didn't finish switching the bus properties yet, or it did, or it's
>>>>> in the middle of it, but you cannot tell.
>>>> OK thanks for the response.
>>>>
>>>> If CMD13 can't be used because the bus is in an undefined state,
>>>> shouldn't send_cmd(CMD13) just fail ?
>>> So it would fail, but how do you guarantee the bus/card switched to the
>>> new state and is reliably ready ? You can't, because you cannot
>>> communicate with the card -- which is the entire problem here, you have
>>> no way to communicate with the card while the bus is switching. However,
>>> you can wait the maximum allowed time according to the spec, and then
>>> the bus/card must be ready. If not, all bets are off.
>>>
>>>> I'm asking because this is a 50ms delay in the hot path of the boot
>>>> process.
>>> I totally understand that, I have the same issue with HS200/HS400 on
>>> R-Car Gen3, all the calibration shenanigans and this indeed add quite a*
>>> bit to the boot time. But I don't have a good answer here.
>> I'll post something using the existing wait_dat0() callback. If the
>> callback is implemented, we can forgo the 50ms delay and poll the dat0
>> line.
> We can ? Do you have some more details ?
dat0 is a rdy/busy indicator. In the linux driver it is used in the
card_busy() callback (look at sdhci_card_busy() for an example).
In u-boot we have a wait_dat0() that polls on dat0. It is used during
the UHS initialization.
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] [PATCH] mmc: Do not poll using CMD13 when changing timing
2019-06-26 12:21 ` Jean-Jacques Hiblot
@ 2019-06-26 13:09 ` Marek Vasut
0 siblings, 0 replies; 11+ messages in thread
From: Marek Vasut @ 2019-06-26 13:09 UTC (permalink / raw)
To: u-boot
On 6/26/19 2:21 PM, Jean-Jacques Hiblot wrote:
>
> On 26/06/2019 11:50, Marek Vasut wrote:
>> On 6/26/19 11:22 AM, Jean-Jacques Hiblot wrote:
>>> On 25/06/2019 21:47, Marek Vasut wrote:
>>>> On 6/25/19 9:07 PM, Jean-Jacques Hiblot wrote:
>>>>> On 25/06/2019 17:53, Marek Vasut wrote:
>>>>>> On 6/25/19 4:13 PM, Jean-Jacques Hiblot wrote:
>>>>>>> Hi Marek,
>>>>>>>
>>>>>>> On 06/02/2019 14:11, Marek Vasut wrote:
>>>>>>>> When using CMD6 to switch eMMC card timing from HS200/HS400 to
>>>>>>>> HS/legacy,
>>>>>>>> do not poll for the completion status using CMD13, but rather wait
>>>>>>>> 50mS.
>>>>>>>>
>>>>>>>> Once the card receives the CMD6 and starts executing it, the bus
>>>>>>>> is in
>>>>>>>> undefined state until both the card finishes executing the command
>>>>>>>> and
>>>>>>>> until the controller switches the bus to matching timing
>>>>>>>> configuration.
>>>>>>>> During this time, it is not possible to transport any commands or
>>>>>>>> data
>>>>>>>> across the bus, which includes the CMD13.
>>>>>>> Is it something that affects all platforms ?
>>>>>>>
>>>>>>> I've been working on this on TI platforms lately and although I've
>>>>>>> seen
>>>>>>> the same kind of problems. But they mostly go away If the code
>>>>>>> handling
>>>>>>> the switch handles the SWITCH_ERROR bit.
>>>>>> The error probably happens because you send the card a command,
>>>>>> but the
>>>>>> command hits the bus that's in some weird intermediate state. Either
>>>>>> the
>>>>>> card didn't finish switching the bus properties yet, or it did, or
>>>>>> it's
>>>>>> in the middle of it, but you cannot tell.
>>>>> OK thanks for the response.
>>>>>
>>>>> If CMD13 can't be used because the bus is in an undefined state,
>>>>> shouldn't send_cmd(CMD13) just fail ?
>>>> So it would fail, but how do you guarantee the bus/card switched to the
>>>> new state and is reliably ready ? You can't, because you cannot
>>>> communicate with the card -- which is the entire problem here, you have
>>>> no way to communicate with the card while the bus is switching.
>>>> However,
>>>> you can wait the maximum allowed time according to the spec, and then
>>>> the bus/card must be ready. If not, all bets are off.
>>>>
>>>>> I'm asking because this is a 50ms delay in the hot path of the boot
>>>>> process.
>>>> I totally understand that, I have the same issue with HS200/HS400 on
>>>> R-Car Gen3, all the calibration shenanigans and this indeed add
>>>> quite a*
>>>> bit to the boot time. But I don't have a good answer here.
>>> I'll post something using the existing wait_dat0() callback. If the
>>> callback is implemented, we can forgo the 50ms delay and poll the dat0
>>> line.
>> We can ? Do you have some more details ?
>
> dat0 is a rdy/busy indicator. In the linux driver it is used in the
> card_busy() callback (look at sdhci_card_busy() for an example).
>
> In u-boot we have a wait_dat0() that polls on dat0. It is used during
> the UHS initialization.
All right, let's try this.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 11+ messages in thread