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 14:40:49 -0500 [thread overview]
Message-ID: <200801081440.49683.vapier.adi@gmail.com> (raw)
In-Reply-To: <20080108202157.0b8d3393@poseidon.drzeus.cx>
On Tuesday 08 January 2008 14:21:57 Pierre Ossman wrote:
> Mike Frysinger <vapier.adi@gmail.com> wrote:
> > The on-chip Blackfin MMC/SD/SDIO host controller has the ability to do
> > 1-bit MMC, 1-bit/4-bit SD, and 1-bit/4-bit SDIO. Thus the current
> > convention of MMC_CAP_4_BIT_DATA meaning "your host controller can do
> > 1-bit or 4-bit for all modes" is insufficient for our needs. The
> > attached patch splits MMC_CAP_4_BIT_DATA into MMC_CAP_MMC_4_BIT_DATA and
> > MMC_CAP_SD_4_BIT_DATA and updates all host controllers to include these
> > in their caps and then changes existing code to check the new defines.
> > At the moment, SD/SDIO are lumped into MMC_CAP_SD_4_BIT_DATA ... should I
> > bother with splitting that into SD and SDIO as well while I'm doing this
> > ?
> >
> > Signed-off-by: Mike Frysinger <vapier@gentoo.org>
>
> I fail to see why you need to split MMC and SD. Could you elaborate why the
> controller won't work with MMC cards? I haven't seen any differences from
> SD.
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.
-mike
next prev parent reply other threads:[~2008-01-08 19:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-08 18:29 [patch] split MMC_CAP_4_BIT_DATA Mike Frysinger
2008-01-08 19:21 ` Pierre Ossman
2008-01-08 19:40 ` Mike Frysinger [this message]
2008-01-08 20:49 ` Pierre Ossman
2008-01-08 21:44 ` Mike Frysinger
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=200801081440.49683.vapier.adi@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 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.