public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Andrew Gabbasov <andrew_gabbasov@mentor.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mmc: fix OCR Polling
Date: Mon, 30 Mar 2015 14:15:31 +0300	[thread overview]
Message-ID: <000001d06ada$d6252e00$826f8a00$@mentor.com> (raw)
In-Reply-To: <7F19964E-04B9-4626-945C-869B3A268D3B@gmail.com>

Hi Pantelis,

> From: Pantelis Antoniou [mailto:pantelis.antoniou at gmail.com]
> Sent: Friday, March 27, 2015 9:32 PM
> To: Gabbasov, Andrew
> Cc: Peng Fan; u-boot at lists.denx.de
> Subject: Re: [U-Boot] [PATCH] mmc: fix OCR Polling
> 
> Hi Andrew, Peng,
> 
> > On Mar 23, 2015, at 01:23 , Andrew Gabbasov
> <andrew_gabbasov@mentor.com> wrote:
> >
> > Hi Peng,
> >
> >> From: Peng Fan [mailto:Peng.Fan at freescale.com]
> >> Sent: Saturday, March 21, 2015 1:34 PM
> >> To: Gabbasov, Andrew; u-boot at lists.denx.de
> >> Subject: Re: [U-Boot] [PATCH] mmc: fix OCR Polling
> >>
> >> [skipped]
> >>
> >>> After this patch, if the busy flag is indeed already set (so that the
> >>> loop body is not executed), and it is not an SPI case
> >>> (mmc_host_is_spi(mmc) is false), the "cmd" structure (which is local
> >>> to mmc_complete_op_cond() function) is left uninitialized, and using
> >>> cmd.response[0] later in the function becomes incorrect. And the OCR
> >>> register value and the high capacity flag may be set incorrectly.
> >> Yeah. you are right.
> >> Maybe the following piece of code should be added to replace mmc->ocr =
> >> cmd.response[0]:
> >> "
> >> if (mmc_host_is_spi(mmc))
> >>     mmc->ocr = cmd.response[0];
> >> else
> >>     mmc->ocr = mmc->op_cond_response;
> >> "
> >> Thanks for correcting me.
> >
> > Well, there can be several ways to correct that. The easiest would be
> > something
> > similar to what you propose, but, just to avoid extra "if", we could add
> >    mmc->op_cond_response = cmd.response[0];
> > to the end of existing "if(mmc_host_is_spi(mmc))" and change
> >    mmc->ocr = cmd.response[0];
> > to
> >    mmc->ocr = mmc->op_cond_response;
> > at the end of function. Since op_cond_response should be already set from
> > the function beginning, this can be used immediately.
> >
> > And, going further, since op_cond_response is actually the same contents
> > as mmc->ocr, we could combine them and use mmc->ocr at once, from
> > the beginning of polling loops. This is a little more complex, but makes
> > the code cleaner. This is what is done in one of other patches in my series
> > ;-)
> >
> 
> This does seem like a case where a simple accessor structure would help until
> we figure out how to process.
> 
> Something like mmc_get_ocr() as a private API perhaps?

Actually I don't see any need to introduce a new accessor or any other API here.
Currently the 2 fields are used to store exactly the same data (OCR, which
is a response to send_op_cond command). But the 'op_cond_response' is used
while OCR polling and 'ocr' is filled in after its completion.
The correct solution from my point of view is to just use a single field (ocr)
from the very beginning. I have already submitted this solution in one
of my patches ("[PATCH 2/6] mmc: Avoid extra duplicate entry in mmc device structure"
in "[PATCH 0/6] mmc: Fix OCR polling and splitted initialization" series).

Thanks.

Best regards,
Andrew

  reply	other threads:[~2015-03-30 11:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-20  7:19 [U-Boot] [PATCH] mmc: fix OCR Polling Andrew Gabbasov
2015-03-21 10:33 ` Peng Fan
2015-03-23  8:23   ` Andrew Gabbasov
2015-03-27 18:31     ` Pantelis Antoniou
2015-03-30 11:15       ` Andrew Gabbasov [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-03-19  8:22 Peng Fan
2015-05-05  9:00 ` Pantelis Antoniou

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='000001d06ada$d6252e00$826f8a00$@mentor.com' \
    --to=andrew_gabbasov@mentor.com \
    --cc=u-boot@lists.denx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox