From: Peppe CAVALLARO <peppe.cavallaro@st.com>
To: Philip Rakity <prakity@marvell.com>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>
Subject: Re: [RFC] sdhci: 8 bit bus width changes
Date: Fri, 5 Nov 2010 08:13:46 +0100 [thread overview]
Message-ID: <4CD3AEAA.20805@st.com> (raw)
In-Reply-To: <B76798A1-FA3F-4D7D-A22A-52289A4062FB@marvell.com>
Hello Philip,
On 10/2/2010 12:45 AM, Philip Rakity wrote:
>
> From 80c581d354df180a4c2d6aa50c21788e6c7593b9 Mon Sep 17 00:00:00 2001
> From: Philip Rakity <prakity@marvell.com>
> Date: Fri, 1 Oct 2010 13:42:58 -0700
> Subject: [RFC] sdhci: 8 bit bus width changes
>
> Check for v3 controller controller when doing 8 bit bus width
> add support for adaption layer to set 8 bit width.
> controller may support 8 bit bus but NOT board design
> allow non v3 controllers to support 8 bit bus
>
Patches ported and tested on our ST target and it works for me.
Thanks!
>
>
> non v3 controller (platform_8bit_width)
> =======================================
> platform_8bit_width is used to support 8 bit mode using our v2
> sd controller. We have private registers that are used for 8 bit support
>
> v2 - v3 controller and 8 bit support (SDHCI_QUIRK_SLOT_CAN_DO_8_BITS)
> =====================================================================
> The quirk is needed since we support multiple SD controllers and
> on the board sometimes 8 data lines are brought out and sometimes only 4.
> The SD controller indicates it can support 8 bit (v3 controller) via the
> capability field but has no knowledge of how the pins were configured
> in the board design. There are only so many pins and the pins are
> multiplexed.
>
> Signed-off-by: Philip Rakity <prakity@marvell.com>
>
Tested -by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Regards
Peppe
>
> ---
> drivers/mmc/host/sdhci.c | 44
> +++++++++++++++++++++++++++++++++-----------
> drivers/mmc/host/sdhci.h | 7 ++++++-
> 2 files changed, 39 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 73a94fe..ec103c3 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1182,17 +1182,31 @@ static void sdhci_set_ios(struct mmc_host
> *mmc, struct mmc_ios *ios)
> else
> sdhci_set_power(host, ios->vdd);
>
> - ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
>
> - if (ios->bus_width == MMC_BUS_WIDTH_8)
> - ctrl |= SDHCI_CTRL_8BITBUS;
> - else
> - ctrl &= ~SDHCI_CTRL_8BITBUS;
> + /*
> + * use platform_8_bit_width if not v3 controller
> + * or if special hw/board specific processing is needed
> + */
> + if (host->ops->platform_8bit_width)
> + host->ops->platform_8bit_width(host, ios->bus_width);
> + else {
> + ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
> + if (ios->bus_width == MMC_BUS_WIDTH_8) {
> + ctrl &= ~SDHCI_CTRL_4BITBUS;
> + if (host->version >= SDHCI_SPEC_300)
> + ctrl |= SDHCI_CTRL_8BITBUS;
> + } else {
> + if (host->version >= SDHCI_SPEC_300)
> + ctrl &= ~SDHCI_CTRL_8BITBUS;
> + if (ios->bus_width == MMC_BUS_WIDTH_4)
> + ctrl |= SDHCI_CTRL_4BITBUS;
> + else
> + ctrl &= ~SDHCI_CTRL_4BITBUS;
> + }
> + sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
> + }
>
> - if (ios->bus_width == MMC_BUS_WIDTH_4)
> - ctrl |= SDHCI_CTRL_4BITBUS;
> - else
> - ctrl &= ~SDHCI_CTRL_4BITBUS;
> + ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
>
> if (ios->timing == MMC_TIMING_SD_HS &&
> !(host->quirks & SDHCI_QUIRK_NO_HISPD_BIT))
> @@ -1838,11 +1852,19 @@ int sdhci_add_host(struct sdhci_host *host)
> mmc->f_min = host->max_clk / SDHCI_MAX_DIV_SPEC_300;
> else
> mmc->f_min = host->max_clk / SDHCI_MAX_DIV_SPEC_200;
> +
> mmc->f_max = host->max_clk;
> mmc->caps |= MMC_CAP_SDIO_IRQ;
>
> - if (!(host->quirks & SDHCI_QUIRK_FORCE_1_BIT_DATA))
> - mmc->caps |= MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA;
> + /* 8 bit width may be supported by v3 controller but not board
> + * so the safest thing is to let the adaption layer decide
> + * what to do by using the quirk
> + */
> + if (!(host->quirks & SDHCI_QUIRK_FORCE_1_BIT_DATA)) {
> + mmc->caps |= MMC_CAP_4_BIT_DATA;
> + if (host->quirks & SDHCI_QUIRK_SLOT_CAN_DO_8_BITS)
> + mmc->caps |= MMC_CAP_8_BIT_DATA;
> + }
>
> if (caps & SDHCI_CAN_DO_HISPD)
> mmc->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED;
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 112543a..b3288fd 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -72,7 +72,7 @@
> #define SDHCI_CTRL_ADMA1 0x08
> #define SDHCI_CTRL_ADMA32 0x10
> #define SDHCI_CTRL_ADMA64 0x18
> -#define SDHCI_CTRL_8BITBUS 0x20
> +#define SDHCI_CTRL_8BITBUS 0x20
>
> #define SDHCI_POWER_CONTROL 0x29
> #define SDHCI_POWER_ON 0x01
> @@ -148,6 +148,7 @@
> #define SDHCI_CLOCK_BASE_SHIFT 8
> #define SDHCI_MAX_BLOCK_MASK 0x00030000
> #define SDHCI_MAX_BLOCK_SHIFT 16
> +#define SDHCI_CAN_DO_8BIT 0x00040000
> #define SDHCI_CAN_DO_ADMA2 0x00080000
> #define SDHCI_CAN_DO_ADMA1 0x00100000
> #define SDHCI_CAN_DO_HISPD 0x00200000
> @@ -260,6 +261,8 @@ struct sdhci_host {
> #define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 (1<<28)
> /* Controller doesn't have HISPD bit field in HI-SPEED SD card */
> #define SDHCI_QUIRK_NO_HISPD_BIT (1<<29)
> +/* slot has 8 data pins going to eMMC/mmc card */
> +#define SDHCI_QUIRK_SLOT_CAN_DO_8_BITS (1<<30)
>
> int irq; /* Device IRQ */
> void __iomem * ioaddr; /* Mapped address */
> @@ -336,6 +339,8 @@ struct sdhci_ops {
> unsigned int (*get_max_clock)(struct sdhci_host *host);
> unsigned int (*get_min_clock)(struct sdhci_host *host);
> unsigned int (*get_timeout_clock)(struct sdhci_host *host);
> + int (*platform_8bit_width)(struct sdhci_host *host,
> + int width);
> };
>
> #ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
> --
> 1.6.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2010-11-05 7:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-01 22:45 [RFC] sdhci: 8 bit bus width changes Philip Rakity
2010-11-05 7:13 ` Peppe CAVALLARO [this message]
2010-11-19 21:40 ` Chris Ball
2010-11-19 21:53 ` Chris Ball
2010-11-20 12:35 ` Wolfram Sang
2010-11-20 16:37 ` Philip Rakity
2010-11-20 18:24 ` Chris Ball
2010-11-21 19:17 ` Philip Rakity
2010-11-22 10:16 ` zhangfei gao
2010-11-22 10:36 ` zhangfei gao
2010-11-22 16:13 ` Philip Rakity
2010-11-23 2:45 ` zhangfei gao
2010-11-24 17:35 ` Chris Ball
2010-11-20 16:37 ` Philip Rakity
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=4CD3AEAA.20805@st.com \
--to=peppe.cavallaro@st.com \
--cc=linux-mmc@vger.kernel.org \
--cc=prakity@marvell.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox