All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mitsyanko <i.mitsyanko@gmail.com>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Cc: Igor Mitsyanko <i.mitsyanko@gmail.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	qemu-devel@nongnu.org,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Subject: Re: [Qemu-devel] [PATCH arm-devs v1 1/5] sd/sd.c: Fix "inquiry" ACMD41
Date: Thu, 23 May 2013 14:31:29 +0400	[thread overview]
Message-ID: <CA+x0pt7fvuhRpH5miA5qkjU0159ooOePvGZf_FRArwm9br+HHw@mail.gmail.com> (raw)
In-Reply-To: <CAEgOgz4gS-S6wS0FiK-1CTRERjjjUg_WZxzs+ds_-xTkKruMuA@mail.gmail.com>

On 05/23/2013 03:42 AM, Peter Crosthwaite wrote:
> Hi Igor,
>
> On Wed, May 22, 2013 at 11:37 PM, Igor Mitsyanko <i.mitsyanko@gmail.com> wrote:
>>
>> On 05/21/2013 10:50 AM, peter.crosthwaite@xilinx.com wrote:
>>
>> From: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>>
>> the SD command ACMD41 can be used in a read only mode to query device
>> state without doing the SD card initialisation. This is valid even
>> which the device is already initialised. Fix the command to be
>> responsive when in the ready state accordingly.
>>
>> Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
>> ---
>>
>>   hw/sd/sd.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/hw/sd/sd.c b/hw/sd/sd.c
>> index 2e0ef3e..89bfb7a 100644
>> --- a/hw/sd/sd.c
>> +++ b/hw/sd/sd.c
>> @@ -1277,6 +1277,7 @@ static sd_rsp_type_t sd_app_command(SDState *sd,
>>           }
>>           switch (sd->state) {
>>           case sd_idle_state:
>> +        case sd_ready_state:
>>               /* We accept any voltage.  10000 V is nothing.  */
>>               if (req.arg)
>>                   sd->state = sd_ready_state;
>>
>>
>> I couldn't find any info in SD specification that would confirm this change
>> correctness, what about
>> table "Table 4-29: Card State Transition Table" which states that ACMD41 is
>> illegal in "ready" state?
>>
>
> By the letter of the spec I think you are right. Although this patch
> is needed to make my QEMU consistent with my real hardware. I'll dig
> deeper.
>

Hello, Peter, after thinking some more about this, I assume that table
4-29 might be incorrect. It depends on when idle->ready state transition
occurs, its not clear from specification.

Controller issues first ACMD41 to start card's initialisation. Spec
states that this process could take up to 1sec, and all this time
controller should query card's busy state in a loop with ACMD41. After
response to ACMD41 has busy flag deasserted, card is considered to be
"ready". But this means that card was already in ready state when it
received last ACMD41 command, right? Unless card transitions to ready
state only after a response to last ACMD41 was sent.

If that's how real SD card behaves in your tests, then I think this
patch is OK, but it could benefit from a short comment explaining that
this behaviour is not covered by specification.


Reviewed-by: Igor Mitsyanko <i.mitsyanko@gmail.com>


> Regards,
> Peter
>
>> --
>> Best wishes,
>> Igor Mitsyanko
>> email: i.mitsyanko@gmail.com
>
>


--
Best wishes,
Igor Mitsyanko
email: i.mitsyanko@gmail.com

  reply	other threads:[~2013-05-23 10:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-22 13:37 [Qemu-devel] [PATCH arm-devs v1 1/5] sd/sd.c: Fix "inquiry" ACMD41 Igor Mitsyanko
2013-05-22 23:42 ` Peter Crosthwaite
2013-05-23 10:31   ` Igor Mitsyanko [this message]
2013-05-24  5:07     ` Peter Crosthwaite
2013-05-27 18:20       ` [Qemu-devel] [PATCH arm-devs v3 1/1] " Igor Mitsyanko
  -- strict thread matches above, loose matches on Subject: below --
2013-05-21  6:49 [Qemu-devel] [PATCH arm-devs v1 0/5] SD and SDHCI Fixes peter.crosthwaite
2013-05-21  6:50 ` [Qemu-devel] [PATCH arm-devs v1 1/5] sd/sd.c: Fix "inquiry" ACMD41 peter.crosthwaite
2013-05-21  9:46   ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+x0pt7fvuhRpH5miA5qkjU0159ooOePvGZf_FRArwm9br+HHw@mail.gmail.com \
    --to=i.mitsyanko@gmail.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=peter.crosthwaite@xilinx.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.