From: Peppe CAVALLARO <peppe.cavallaro@st.com>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"matt@console-pimps.org" <matt@console-pimps.org>
Subject: Re: [PATCH] mmc: add SDHCI driver for STM platforms (V2)
Date: Wed, 22 Sep 2010 15:31:04 +0200 [thread overview]
Message-ID: <4C9A0518.3090904@st.com> (raw)
In-Reply-To: <20100921094457.GD3168@pengutronix.de>
On 09/21/2010 11:44 AM, Wolfram Sang wrote:
> On Tue, Sep 21, 2010 at 11:21:48AM +0200, Peppe CAVALLARO wrote:
>> On 09/20/2010 10:38 AM, Wolfram Sang wrote:
>>> On Mon, Sep 20, 2010 at 10:20:17AM +0200, Giuseppe CAVALLARO wrote:
>>>> This patch adds the Arasan MMC/SD/SDIO driver
>>>> for the STM ST40 platforms. It is based on the
>>>> SDHCI driver.
>>>> It has been tested on the STx7106/STx7108/STx5289
>>>> platforms.
>>>>
>>>> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>>>
>>> Looks to me that you could just use the sdhci-pltfm driver?
>>>
>>
>> Hello Wolfram,
>> some weeks ago I discussed about this driver and I reworked it according
>> to the changes required. This is the meaning of this patch.
>>
>> At any rate, I can look at the sdhci-pltfm driver: at first glance, it
>> could actually help on our platforms. This could take a while.
>
> Sorry, I didn't spot the first version of your patch. I would have said
> the same then, simply to avoid the code duplication. Oh, and no need to
> hurry from my side :)
Hi Wolfran,
I agree that it's a good idea to reduce duplicated code when possible
(i.e. the probe function that, at first glance, is almost equal for
several sdhci drivers based).
Maybe, I could use on our ST boxes the sdhci_pltfm but I have the
following questions and ideas. Welcome advice and feedback.
1) I've already a patch to add the suspend/resume in the sdhci_pltfm
driver. Please note this is mandatory for me.
Note: I'd like to look at the wake-up on card that should be nice to
have in the future. IIUC, it is missing in the sdhci. Please correct
me if I'm wrong.
2) sdhci_pltfm_data has a "quirk" flag but IMO the quirk macros, that
currently are in linux-2.6/drivers/mmc/host/sdhci.h, should be
moved in a separate file:
include/linux/mmc/sdhci.h or
include/linux/mmc/sdhci-quirk.h or ...
I don't know if it has been already done but I could create a patch
for this too. Let me know the name convention you like, eventually.
Otherwise, in my platforms, where I need to set this flag (e.g. the
sdhci-stm needs: SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC), I should include
drivers/mmc/host/sdhci.h?!? I don't like it :-(
Please, correct me if I've missed something.
3) In the end, another hook could be added in the sdhci_pltfm_data to
invoke specific own functions for claiming resources etc.
For example, I need an extra callback to invoke the STM pad manager
that's used for managing clocks, PIO lines and syscfg registers.
I'm thinking about something like this:
struct sdhci_pltfm_data {
struct sdhci_ops *ops;
unsigned int quirks;
int (*init)(struct sdhci_host *host);
void (*exit)(struct sdhci_host *host);
int (*claim_resource)(struct platform_device *pdev);
|
|_ we can use another name.
};
What do you think?
Regards
Peppe
next prev parent reply other threads:[~2010-09-22 13:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-20 8:20 [PATCH] mmc: add SDHCI driver for STM platforms (V2) Giuseppe CAVALLARO
2010-09-20 8:38 ` Wolfram Sang
2010-09-21 9:21 ` Peppe CAVALLARO
2010-09-21 9:44 ` Wolfram Sang
2010-09-22 13:31 ` Peppe CAVALLARO [this message]
2010-09-22 14:12 ` Wolfram Sang
2010-09-22 14:35 ` Peppe CAVALLARO
2010-09-23 6:48 ` Peppe CAVALLARO
2010-09-23 8:48 ` Wolfram Sang
2010-09-23 9:30 ` Peppe CAVALLARO
2010-09-23 9:51 ` Wolfram Sang
2010-09-23 10:05 ` Peppe CAVALLARO
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=4C9A0518.3090904@st.com \
--to=peppe.cavallaro@st.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mmc@vger.kernel.org \
--cc=matt@console-pimps.org \
--cc=w.sang@pengutronix.de \
/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.