[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAVeFuJKxY36BpA_dYhNnhH0v8ERaRYK9Be_hQNtG0H898U8EQ@mail.gmail.com>
Date: Wed, 28 Jan 2015 15:06:27 +0900
From: Alexandre Courbot <gnurou@...il.com>
To: Rhyland Klein <rklein@...dia.com>
Cc: Ulf Hansson <ulf.hansson@...aro.org>,
Chris Ball <chris@...ntf.net>,
Stephen Warren <swarren@...dotorg.org>,
Thierry Reding <thierry.reding@...il.com>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
pkunapuli@...dia.com
Subject: Re: [PATCH] mmc: tegra: Write xfer_mode, CMD regs in together
On Wed, Jan 28, 2015 at 2:23 AM, Rhyland Klein <rklein@...dia.com> wrote:
> From: Pavan Kunapuli <pkunapuli@...dia.com>
>
> If there is a gap between xfer mode and command register writes,
> tegra SDMMC controller can sometimes issue a spurious command before
> the CMD register is written. To avoid this, these two registers need
> to be written together in a single write operation.
>
> Signed-off-by: Pavan Kunapuli <pkunapuli@...dia.com>
> Signed-off-by: Rhyland Klein <rklein@...dia.com>
> ---
> drivers/mmc/host/sdhci-tegra.c | 31 ++++++++++++++++++++++++++++++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
> index 59797106af93..3d34de47e57e 100644
> --- a/drivers/mmc/host/sdhci-tegra.c
> +++ b/drivers/mmc/host/sdhci-tegra.c
> @@ -41,6 +41,7 @@
> #define NVQUIRK_DISABLE_SDR50 BIT(3)
> #define NVQUIRK_DISABLE_SDR104 BIT(4)
> #define NVQUIRK_DISABLE_DDR50 BIT(5)
> +#define NVQUIRK_SHADOW_XFER_MODE_REG BIT(6)
>
> struct sdhci_tegra_soc_data {
> const struct sdhci_pltfm_data *pdata;
> @@ -67,6 +68,32 @@ static u16 tegra_sdhci_readw(struct sdhci_host *host, int reg)
> return readw(host->ioaddr + reg);
> }
>
> +static void tegra_sdhci_writew(struct sdhci_host *host, u16 val, int reg)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_tegra *tegra_host = pltfm_host->priv;
> + const struct sdhci_tegra_soc_data *soc_data = tegra_host->soc_data;
> +
> + if (soc_data->nvquirks * NVQUIRK_SHADOW_XFER_MODE_REG) {
Isn't the '*' supposed to be a '&' here?
> + switch (reg) {
> + case SDHCI_TRANSFER_MODE:
> + /*
> + * Postpone this write, we must do it together with a
> + * command write that is down below.
> + */
> + pltfm_host->xfer_mode_shadow = val;
> + return;
> + case SDHCI_COMMAND:
> + writel((val << 16) | pltfm_host->xfer_mode_shadow,
> + host->ioaddr + SDHCI_TRANSFER_MODE);
> + pltfm_host->xfer_mode_shadow = 0;
That last line is probably not needed and could actually be harmful -
if we try to write SDHCI_COMMAND twice in a raw without a write to
SDHCI_TRANSFER_MODE in between, the zero will overwrite the previous
value of SDHCI_TRANSFER_MODE.
> + return;
> + }
> + }
> +
> + writew(val, host->ioaddr + reg);
> +}
> +
> static void tegra_sdhci_writel(struct sdhci_host *host, u32 val, int reg)
> {
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> @@ -147,6 +174,7 @@ static void tegra_sdhci_set_bus_width(struct sdhci_host *host, int bus_width)
> static const struct sdhci_ops tegra_sdhci_ops = {
> .get_ro = tegra_sdhci_get_ro,
> .read_w = tegra_sdhci_readw,
> + .write_w = tegra_sdhci_writew,
> .write_l = tegra_sdhci_writel,
> .set_clock = sdhci_set_clock,
> .set_bus_width = tegra_sdhci_set_bus_width,
> @@ -201,7 +229,8 @@ static struct sdhci_tegra_soc_data soc_data_tegra114 = {
> .pdata = &sdhci_tegra114_pdata,
> .nvquirks = NVQUIRK_DISABLE_SDR50 |
> NVQUIRK_DISABLE_DDR50 |
> - NVQUIRK_DISABLE_SDR104,
> + NVQUIRK_DISABLE_SDR104 |
> + NVQUIRK_SHADOW_XFER_MODE_REG,
> };
Since this only applies to Tegra114 (?), I wonder whether it would not
be better to have a dedicated tegra114_sdhci_ops that implements
tegra_sdhci_writew, and use it only in tegra_sdhci_writew. That way
you could get rid of the NVQUIRK_SHADOW_XFER_MODE_REG and the test for
it in tegra_sdhci_writew(), and chips prior to Tegra114 will not have
to needlessly check for it every time they write a register.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists