From: Anderson Briglia <anderson.briglia@indt.org.br>
To: Tony Lindgren <tony@atomide.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch 1/5] MMC OMAP driver
Date: Thu, 02 Feb 2006 15:34:35 -0400 [thread overview]
Message-ID: <43E25ECB.5010104@indt.org.br> (raw)
In-Reply-To: <20060201194724.GD15939@atomide.com>
Tony Lindgren wrote:
> * Russell King <rmk+lkml@arm.linux.org.uk> [060201 04:44]:
>>>+static inline int is_broken_card(struct mmc_card *card)
>>>+{
>>>+ int i;
>>>+ struct mmc_cid *c = &card->cid;
>>>+ static const struct broken_card_cid {
>>>+ unsigned int manfid;
>>>+ char prod_name[8];
>>>+ unsigned char hwrev;
>>>+ unsigned char fwrev;
>>>+ } broken_cards[] = {
>>>+ { 0x00150000, "\x30\x30\x30\x30\x30\x30\x15\x00", 0x06, 0x03 },
>>>+ };
>>>+
>>>+ for (i = 0; i < sizeof(broken_cards)/sizeof(broken_cards[0]); i++) {
>>>+ const struct broken_card_cid *b = broken_cards + i;
>>>+
>>>+ if (b->manfid != c->manfid)
>>>+ continue;
>>>+ if (memcmp(b->prod_name, c->prod_name, sizeof(b->prod_name)) != 0)
>>>+ continue;
>>>+ if (b->hwrev != c->hwrev || b->fwrev != c->fwrev)
>>>+ continue;
>>>+ return 1;
>>>+ }
>>>+ return 0;
>>>+}
>>
>>I've already mentioned this to the OMAP folk... What problem is this
>>trying to work around? If it's a card problem, it's at the wrong
>>level. If it's a problem with the host not waiting the mandatory
>>80 cycles before starting a command, that could be the upper layers
>>or a host problem.
>>
>>Either way, the right place to fix this is _not_ in the request
>>function but in the set_ios function. The request function does
>>not know if the card has just been powered up.
>
>
> Anderson, can you pull out the broken card check from omap.c, and put
> it into a separate patch? Let's fix the omap.c issues first, and have
> that integrated. Then we can start working on the additional patches
> and test them one at a time.
>
Ok. It's already done. I'll wait the omap clock framework fix to post another patch for
omap.c, ok?
Regards,
Anderson Briglia
INdT - Manaus - Brazil
prev parent reply other threads:[~2006-02-02 21:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-31 13:34 [patch 1/5] MMC OMAP driver Anderson Briglia
2006-01-31 15:29 ` Pierre Ossman
2006-02-01 12:44 ` Russell King
2006-02-01 19:47 ` Tony Lindgren
2006-02-02 10:40 ` Russell King
2006-02-02 11:45 ` Pierre Ossman
2006-02-02 12:24 ` Russell King
2006-02-17 19:53 ` Carlos Aguiar
2006-02-17 20:08 ` Russell King
2006-02-02 19:34 ` Anderson Briglia [this message]
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=43E25ECB.5010104@indt.org.br \
--to=anderson.briglia@indt.org.br \
--cc=linux-kernel@vger.kernel.org \
--cc=tony@atomide.com \
/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