From: Olof Johansson <olof@lixom.net>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: Chris Ball <cjb@laptop.org>,
linux-mmc@vger.kernel.org, linux-tegra@vger.kernel.org,
Yvonne Yip <y@palm.com>, Gary King <gking@nvidia.com>,
Todd Poynor <toddpoynor@google.com>,
Dmitry Shmidt <dimitrysh@google.com>,
Rhyland Klein <rklein@nvidia.com>
Subject: Re: [PATCH 4/4] mmc: add sdhci-tegra driver for Tegra SoCs
Date: Wed, 15 Dec 2010 07:03:55 -0600 [thread overview]
Message-ID: <20101215130355.GA4124@lixom.net> (raw)
In-Reply-To: <20101215115911.GH3515@pengutronix.de>
On Wed, Dec 15, 2010 at 12:59:11PM +0100, Wolfram Sang wrote:
>
> > > If there is something yet missing in sdhci-pltfm which you need, it
> > > probably is worth adding it there. Chances are good that other
> > > pltfm-users might want that, too.
> >
> > Taking that to an extreme, any sdhci driver should plug into sdhci-pltfm and
> > just add the hooks needed. It will result in just one more abstraction layer that
> > makes following code flow harder.
>
> Yes, of course. SDHCI is pretty well defined, so a good core on a SOC
> should just need sdhci-pltfm and some pltfm-data (and we got rid of a
> complete driver that way recently). If the core has quirks (as most
> sadly do), a bit of extension is needed. I'd prefer to have those
> extensions in one place rather than hidden in various drivers. I have
> the assumption they will be reusable, maybe this is a core point where
> we disagree?
Actually, I was of the impression that you wanted to hide the per-platform
hooks away from drivers/mmc/host. I see now that other drivers still add it
there. That's acceptable to me.
I'll whip up the changes and see how invasive it gets as a -pltfm
driver. It shouldn't be too bad. I'll repost the series that way, but
I will still keep the quirks for now and do a pass reworking these as
well as others separately (see below).
> > Especially if you want some of the quirk code to be moved from sdhci.c
> > to the driver.
>
> Please elaborate. Why is sdhci-pltfm complicating things here?
Well, doing post-host_add-modifications of host->mmc->caps would add yet
another hook for the various platforms. :(
Anyway, I wonder if it does makes some sense to add a sdhci_ops callback
for fixing up the mmc settings after setting the defaults in host_add,
and for not just -pltfm. A handful of quirks are already only used for
overriding defaults, and they could be freed up. There's a few more that
are only used by a single driver and are suitable for handling through
overloaded register read/write functions.
I'll do a first pass, but it might take me a week or two due to other
more pressing things.
-Olof
next prev parent reply other threads:[~2010-12-15 13:03 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-15 4:49 [PATCH 0/4] Add SDHCI driver for Tegra Olof Johansson
2010-12-15 4:49 ` [PATCH 1/4] sdhci: add quirk for max len ADMA descriptors Olof Johansson
2010-12-15 4:49 ` [PATCH 2/4] sdhci: add quirk for broken sdio irq Olof Johansson
2010-12-15 10:42 ` zhangfei gao
2010-12-15 10:54 ` Olof Johansson
2010-12-15 11:03 ` Wolfram Sang
2010-12-15 11:24 ` Olof Johansson
2010-12-15 11:44 ` Wolfram Sang
2010-12-15 10:57 ` Wolfram Sang
2010-12-15 11:34 ` Olof Johansson
2010-12-15 4:49 ` [PATCH 3/4] sdhci: don't finish commands in flight Olof Johansson
2010-12-15 4:49 ` [PATCH 4/4] mmc: add sdhci-tegra driver for Tegra SoCs Olof Johansson
2010-12-15 8:35 ` Wolfram Sang
2010-12-15 8:43 ` Olof Johansson
2010-12-15 8:46 ` Olof Johansson
2010-12-15 10:37 ` Wolfram Sang
2010-12-15 11:40 ` Olof Johansson
2010-12-15 11:59 ` Wolfram Sang
2010-12-15 13:03 ` Olof Johansson [this message]
2010-12-15 13:40 ` Wolfram Sang
2010-12-15 11:23 ` Mike Rapoport
2010-12-15 11:31 ` Olof Johansson
2010-12-15 11:33 ` Pavan Kondeti
2010-12-15 11:35 ` Olof Johansson
2010-12-15 11:37 ` Wolfram Sang
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=20101215130355.GA4124@lixom.net \
--to=olof@lixom.net \
--cc=cjb@laptop.org \
--cc=dimitrysh@google.com \
--cc=gking@nvidia.com \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=rklein@nvidia.com \
--cc=toddpoynor@google.com \
--cc=w.sang@pengutronix.de \
--cc=y@palm.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 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.