From: w.sang@pengutronix.de (Wolfram Sang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 8/9] esdhc-4 esdhc: fsl esdhc driver based on platform sdhci api
Date: Thu, 9 Sep 2010 18:39:53 +0200 [thread overview]
Message-ID: <20100909163952.GI3773@pengutronix.de> (raw)
In-Reply-To: <A88EF4D64D8447468743DC1503C0B6CA0789F0@zch01exm22.fsl.freescale.net>
Hi Richard,
> BTW, Do you know that how to define and pass the kinds of
> platform_data-struct special to the board to the sdhci_pltfm.c layer
> platform-data struct?
I think we should extend the pdata->init call to also have the
platform_data as an argument. Then, the platform-specific init routine
should have all it needs. Will update that tomorrow.
> [<Zhu Richard-r65037>] The one used in sdhci-of-esdhc.c is better than
> the one listed abov; it's more logical and clear. :)
Good, it seems to be complete, too :)
> > I find that the sdhci.c had been support the 8bits bus_width.
>
> Yes, it was added recently, but it might have issues. See here:
>
> http://thread.gmane.org/gmane.linux.kernel.mmc/3370
> [<Zhu Richard-r65037>] Different IC design may have the different
> definitions of the bus width configuration in the HOST_CONTROL register.
> This is not a big issue; we can handle these differences in the SW.
Yes, my point is that we don't handle this at the generic
sdhci-core, but at the parts which deal with the platform-specific
faul^H^H^H^H... differences ;)
> About the 8bits supports, I had been verified this feature on i.MX
> platforms for a while.
> The MMC cards 8bits mode can work well on some i.MX eSDHC platforms.
Why only some? Are the others not working or not tested?
> One more suggestion, the caps should be handled carefully, because not
> only the caps of the IC design, but also the caps of the board HW design
> should be taken care,
Could you give an example when it is board-dependent?
> [<Zhu Richard-r65037>] I'm checking it, and still trying finding a way
> to pass the board related info (such as the WP pins, and bus width to
> sdhci-platfm.c layer)
See above. And here is my current WIP. I factored out the common stuff
from of and pltfm. Furthermore, I addressed Uwe's comments about adding
MX35-devices. Expect a few updates (platform-data) tomorrow.
http://git.pengutronix.de/?p=wsa/linux-2.6.git;a=shortlog;h=refs/heads/pcm043-wip
(The old branch is still there, just in case you are working with it)
> The host->ops->get_ro should be added into the sdhci.c file although
> following the method provided in the RFC patches. How do you think about
> that?
I agree, that one seems needed. Shall I integrate this into my series
or do you want to place this patch ontop of my series?
Kind regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100909/51c24ec9/attachment.sig>
next prev parent reply other threads:[~2010-09-09 16:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-01 9:48 [PATCH 8/9] esdhc-4 esdhc: fsl esdhc driver based on platform sdhci api Richard Zhu
2010-09-06 10:47 ` Wolfram Sang
2010-09-07 9:32 ` Zhu Richard-R65037
2010-09-07 10:28 ` Wolfram Sang
2010-09-09 8:51 ` Zhu Richard-R65037
2010-09-09 16:39 ` Wolfram Sang [this message]
2010-09-10 8:45 ` Zhu Richard-R65037
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=20100909163952.GI3773@pengutronix.de \
--to=w.sang@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).