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