linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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>

  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).