From: "Mike Frysinger" <vapier.adi@gmail.com>
To: "Pierre Ossman" <drzeus-mmc@drzeus.cx>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] split MMC_CAP_4_BIT_DATA
Date: Tue, 8 Jan 2008 16:44:08 -0500 [thread overview]
Message-ID: <8bd0f97a0801081344i55100937qc1ad178dd94c358b@mail.gmail.com> (raw)
In-Reply-To: <20080108214946.03018d95@poseidon.drzeus.cx>
On Jan 8, 2008 3:49 PM, Pierre Ossman <drzeus-mmc@drzeus.cx> wrote:
> On Tue, 8 Jan 2008 14:40:49 -0500
> Mike Frysinger <vapier.adi@gmail.com> wrote:
> > i dont understand what's confusing. the Blackfin on chip host controller only
> > supports 1-bit MMC, but it supports 4-bit SD/SDIO. this is a fact. while it
> > may be a stupid decision, it is what it is, and i need the framework made
> > more flexible in order to get the Blackfin driver merged cleanly. we do
> > software for hardware, we dont do hardware.
>
> Well, since I've seen no _hardware_ differences between 4-bit MMC and 4-bit SD, "support" in this case must me "vendor will guarantee it works". And that is not the kind of "support" that needs a distinction in the code.
regardless of where the limitation is, the change is necessary.
however you wish to classify the issue, it doesnt matter to me. the
Blackfin controller needs to declare the following capabilities:
- 1-bit MMC
- 1-bit SD / 4-bit SD
- 1-bit SDIO / 4-bit SDIO
the existing framework is not flexible enough to account for this,
thus the patch posted.
> So, again, if you feel that there is a hardware difference between 4-bit MMC and 4-bit SD then please elaborate as it is my understanding that they are identical.
you may be 100% correct, i have no idea, i'm not really familiar with
MMC/SD/SDIO at all.
-mike
next prev parent reply other threads:[~2008-01-08 21:44 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-08 18:29 Mike Frysinger
2008-01-08 19:21 ` Pierre Ossman
2008-01-08 19:40 ` Mike Frysinger
2008-01-08 20:49 ` Pierre Ossman
2008-01-08 21:44 ` Mike Frysinger [this message]
2008-01-09 7:21 ` Pierre Ossman
2008-01-09 2:32 ` Bryan Wu
2008-01-09 3:21 ` Cai, Cliff
2008-01-09 7:23 ` Pierre Ossman
2008-01-09 16:45 ` Bryan Wu
2008-01-10 8:54 ` Pierre Ossman
2008-01-10 9:22 ` Bryan Wu
2008-01-10 11:57 ` Pierre Ossman
2008-01-11 6:17 ` Bryan Wu
2008-01-11 6:25 ` Mike Frysinger
2008-01-11 8:40 ` Pierre Ossman
2008-01-11 9:08 ` Mike Frysinger
2008-01-11 9:35 ` Pierre Ossman
2008-01-11 9:47 ` Mike Frysinger
2008-01-11 10:05 ` Pierre Ossman
2008-01-11 10:22 ` Bryan Wu
2008-01-11 11:18 ` Pierre Ossman
2008-01-11 17:52 ` Robin Getz
2008-01-12 13:02 ` Robin Getz
2008-01-12 15:24 ` Bryan Wu
2008-01-12 15:39 ` Pierre Ossman
2008-01-09 4:23 ` Bryan Wu
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=8bd0f97a0801081344i55100937qc1ad178dd94c358b@mail.gmail.com \
--to=vapier.adi@gmail.com \
--cc=drzeus-mmc@drzeus.cx \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®