public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: tony@atomide.com
To: Pierre Ossman <drzeus-list@drzeus.cx>
Cc: omap-linux <linux-omap-open-source@linux.omap.com>,
	ext Philip Langdale <philipl@overt.org>
Subject: Re: [PATCH] SD working on OMAP platforms
Date: Tue, 3 Apr 2007 09:58:08 -0400	[thread overview]
Message-ID: <20070403135804.GA10528@atomide.com> (raw)
In-Reply-To: <4611DA08.7020102@drzeus.cx>

* Pierre Ossman <drzeus-list@drzeus.cx> [070403 00:35]:
> Carlos Aguiar wrote:
> > On CMD3, response type is R6 to SD cards and R1 to MMC cards.
> > This fix ignores the buggy SD handling on CMD3.
> >
> >   
> 
> This is misleading. The problem is the OMAP controller trying to be
> smart with the end result of it doing something completely wrong. The
> controller parses data when it has no idea what we want parsed.
> 
> > +		if (status == 0x4000) {
> > +			dev_dbg(mmc_dev(host->mmc),
> > +				"buggy SD handling, ignoring it\n");
> > +			status = 0x0001;
> > +		}
> > +
> >   
> 
> Some defines for those constants would be nice. And the debug message
> should be more general

Always ignoring CERR seems totally unsafe to me. Also, it would be
best to use the existing #define OMAP_MMC_STAT_CARD_ERR.

To recap, CERR needs to be ignored only with SD cards, and only
with CMD3.

Pierre, what do you have as an alternative for working around hardware
bugs without using opcodes? AFAIK opcodes are needed to work around
some hardware issues, such as this.

Regards,

Tony

  reply	other threads:[~2007-04-03 13:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-30 20:28 [PATCH] SD working on OMAP platforms Carlos Aguiar
2007-03-31  6:16 ` Pierre Ossman
2007-03-31 22:07   ` Carlos Aguiar
2007-04-03  4:37     ` Pierre Ossman
2007-04-03 13:58       ` tony [this message]
2007-04-03 13:12         ` Pierre Ossman
2007-04-03 14:50           ` Tony Lindgren

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=20070403135804.GA10528@atomide.com \
    --to=tony@atomide.com \
    --cc=drzeus-list@drzeus.cx \
    --cc=linux-omap-open-source@linux.omap.com \
    --cc=philipl@overt.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox